From florin at andrei.myip.org Sat Jan 1 00:01:08 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 31 Dec 2004 16:01:08 -0800 Subject: "vanilla" kernel closest to Fedora kernel In-Reply-To: <1104529091.9057.1.camel@ua2-124.cust.blixtvik.net> References: <1104522835.12925.2.camel@rivendell.home.local> <1104529091.9057.1.camel@ua2-124.cust.blixtvik.net> Message-ID: <1104537668.4066.2.camel@scout.home.local> On Fri, 2004-12-31 at 22:38 +0100, Peter Backlund wrote: > fre 2004-12-31 klockan 11:53 -0800 skrev Florin Andrei: > > > > So here's my question: what is the best way to configure a vanilla > > kernel so that it is as close to the Fedora kernel as possible? > > Run the kernel src.rpm through the rpmbuild -bp stage, and try your > patch. If it doesn't apply, comment out patches in the spec until it > does. Also, you'll see what base kernel is used in the spec file. Yeap, i thought about that, but the problem is that the developers of the patch (driver) may ignore bug reports from people not using the vanilla kernel. I know that the Fedora kernel is not too bastardized (it's pretty close to vanilla, like Arjan said) but... -- Florin Andrei http://florin.myip.org/ From geisj at pagestation.com Sat Jan 1 01:15:09 2005 From: geisj at pagestation.com (Jerry Geis) Date: Fri, 31 Dec 2004 20:15:09 -0500 Subject: Fedora core 3 FC3 only supporting 4 serial ports Oversite or BUG In-Reply-To: <41D5F86F.2020401@messagenetsystems.com> References: <41D5F86F.2020401@messagenetsystems.com> Message-ID: <41D5F99D.30209@pagestation.com> All I just installed FC3 from Redhat 9. I have a quatech multiport card with 8 ports. Under redhat 9 there was no problem card was detect and I had ports 4 - 11. Under FC3 the card is detected but the order of the ports is ALL messed up. I am attempt to change the CONFIG_SERIAL_8250_NR_UARTS to 24. I am recompiling the kernel now. I chose 24 to support 3 - 8 port serial cards. Is this a configuration bug or oversite or what is going on that my 8 port multiport card is not supported that worked fine under redhat 9. THanks, Jerry From dcbw at redhat.com Sat Jan 1 02:34:33 2005 From: dcbw at redhat.com (Dan Williams) Date: Fri, 31 Dec 2004 21:34:33 -0500 (EST) Subject: Compiling src OpenOffice.org 1.1.4 on FC3 In-Reply-To: <41D5576E.8070102@os.lv> References: <41D5576E.8070102@os.lv> Message-ID: Hi, OpenOffice.org 1.1.x is only buildable with gcc 3.3 and lower. gcc 3.4 is not supported. The Fedora RPMs have gross hacks to allow compilation with gcc 3.3 using the compat-gcc-* packages. The ooo-build intrastructure has patches that allow OOo 1.1.x to build with gcc 3.4 (http://ooo.ximian.com), which is what Fedora uses as a base for its OOo packages. Future versions of the Fedora OOo packages will be compiled with gcc 3.4. Dan On Fri, 31 Dec 2004, Kaspars wrote: > > Hi, > > I try to compile on FC3 lates OpenOffice.org, but without success. > Maybe somebody have better lack with it? Know what I`m doing wrong. > > I`m doing: > $cd OOo_src/config_office/ > $./configure --prefix=/opt/OOo --with-jdk-home=/opt/java/ \ > --with-x --enable-libart > $tcsh -c "source LinuxIntelEnv.Set; ./bootstrap" > $tcsh -c "source LinuxIntelEnv.Set; dmake" > > and thats the error: > STLport-4.5/doc/doc.css > make writeable... > echo dummy > ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0.mak > touch ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0.mak > echo dummy > ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0-macosx.mak > touch ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0-macosx.mak > echo dummy > ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0-freebsd.mak > touch ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0-freebsd.mak > echo dummy > ./unxlngi4.pro/misc/build/STLport-4.5/src/sunpro8.mak > touch ./unxlngi4.pro/misc/build/STLport-4.5/src/sunpro8.mak > cd ./unxlngi4.pro/misc/build && cat ../../../STLport-4.5.patch | patch > -b -p2 && touch so_patched_so_stlport > patching file STLport-4.5/src/dll_main.cpp > patching file STLport-4.5/src/gcc-3.0-freebsd.mak > patching file STLport-4.5/src/gcc-3.0-macosx.mak > patching file STLport-4.5/src/gcc-3.0.mak > patching file STLport-4.5/src/gcc-freebsd.mak > patching file STLport-4.5/stlport/config/stl_gcc.h > patching file STLport-4.5/stlport/cwchar > patching file STLport-4.5/stlport/stdexcept > patching file STLport-4.5/stlport/stl/_threads.h > touch ./unxlngi4.pro/misc/build/so_addfiles_so_stlport > touch ./unxlngi4.pro/misc/build/so_patched_so_stlport > touch ./unxlngi4.pro/misc/build/so_configured_so_stlport > mkdir ./unxlngi4.pro/misc/build/STLport-4.5/src > mkdir: cannot create directory > `./unxlngi4.pro/misc/build/STLport-4.5/src': File exists > cd ./unxlngi4.pro/misc/build/STLport-4.5/src && make -f gcc-3.0.mak -j1 > && touch so_built_so_stlport > mkdir -p ../lib/obj/GCC/ReleaseD > g++ -D_REENTRANT > -DGXX_INCLUDE_PATH=/usr/lib/gcc/i386-redhat-linux/3.4.2/../../. > ./../include/c++/3.4.2 -fexceptions -I../stlport -Wall -W > -Wno-sign-compare -Wno -unused -Wno-uninitialized -ftemplate-depth-32 > -O2 -fPIC dll_main.cpp -c -o ../l ib/obj/GCC/ReleaseD/dll_main.o > In file included from stlport_prefix.h:28, > from dll_main.cpp:34: > ../stlport/ctime:25:44: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c++ /3.4.2/ctime: > No such file or directory > In file included from stlport_prefix.h:28, > from dll_main.cpp:34: > ../stlport/ctime:32: error: `__std_alias::size_t' has not been declared > ../stlport/ctime:33: error: `__std_alias::clock_t' has not been declared > ../stlport/ctime:34: error: `__std_alias::time_t' has not been declared > ../stlport/ctime:35: error: `__std_alias::tm' has not been declared > ../stlport/ctime:37: error: `__std_alias::clock' has not been declared > ../stlport/ctime:38: error: `__std_alias::asctime' has not been declared > ../stlport/ctime:39: error: `__std_alias::ctime' has not been declared > ../stlport/ctime:40: error: `__std_alias::gmtime' has not been declared > ../stlport/ctime:41: error: `__std_alias::difftime' has not been declared > ../stlport/ctime:42: error: `__std_alias::mktime' has not been declared > ../stlport/ctime:43: error: `__std_alias::localtime' has not been declared > ../stlport/ctime:44: error: `__std_alias::strftime' has not been declared > ../stlport/ctime:45: error: `__std_alias::time' has not been declared > In file included from dll_main.cpp:34: > stlport_prefix.h:30: error: `__std_alias::time_t' has not been declared > In file included from ../stlport/stl/debug/_debug.c:160, > from ../stlport/stl/debug/_debug.h:418, > from ../stlport/utility:36, > from dll_main.cpp:36: > ../stlport/cstdlib:25:46: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c ++/3.4.2/cstdlib: > No such file or directory > In file included from ../stlport/stl/debug/_debug.c:160, > from ../stlport/stl/debug/_debug.h:418, > from ../stlport/utility:36, > from dll_main.cpp:36: > ../stlport/cstdlib:42: error: `__std_alias::div_t' has not been declared > ../stlport/cstdlib:43: error: `__std_alias::ldiv_t' has not been declared > ../stlport/cstdlib:44: error: `__std_alias::size_t' has not been declared > ../stlport/cstdlib:47: error: `__std_alias::abort' has not been declared > ../stlport/cstdlib:48: error: `__std_alias::atexit' has not been declared > ../stlport/cstdlib:49: error: `__std_alias::exit' has not been declared > ../stlport/cstdlib:50: error: `__std_alias::getenv' has not been declared > ../stlport/cstdlib:51: error: `__std_alias::calloc' has not been declared > ../stlport/cstdlib:52: error: `__std_alias::free' has not been declared > ../stlport/cstdlib:53: error: `__std_alias::malloc' has not been declared > ../stlport/cstdlib:54: error: `__std_alias::realloc' has not been declared > ../stlport/cstdlib:55: error: `__std_alias::atof' has not been declared > ../stlport/cstdlib:56: error: `__std_alias::atoi' has not been declared > ../stlport/cstdlib:57: error: `__std_alias::atol' has not been declared > ../stlport/cstdlib:58: error: `__std_alias::mblen' has not been declared > ../stlport/cstdlib:59: error: `__std_alias::mbstowcs' has not been declared > ../stlport/cstdlib:60: error: `__std_alias::mbtowc' has not been declared > ../stlport/cstdlib:61: error: `__std_alias::strtod' has not been declared > ../stlport/cstdlib:62: error: `__std_alias::strtol' has not been declared > ../stlport/cstdlib:63: error: `__std_alias::strtoul' has not been declared > ../stlport/cstdlib:64: error: `__std_alias::system' has not been declared > ../stlport/cstdlib:70: error: `__std_alias::bsearch' has not been declared > ../stlport/cstdlib:71: error: `__std_alias::qsort' has not been declared > ../stlport/cstdlib:74: error: `__std_alias::abs' has not been declared > ../stlport/cstdlib:76: error: `__std_alias::div' has not been declared > ../stlport/cstdlib:77: error: `__std_alias::labs' has not been declared > ../stlport/cstdlib:78: error: `__std_alias::ldiv' has not been declared > ../stlport/cstdlib:79: error: `__std_alias::rand' has not been declared > ../stlport/cstdlib:80: error: `__std_alias::srand' has not been declared > In file included from ../stlport/stl/debug/_debug.c:236, > from ../stlport/stl/debug/_debug.h:418, > from ../stlport/utility:36, > from dll_main.cpp:36: > ../stlport/cstdarg:25:46: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c ++/3.4.2/cstdarg: > No such file or directory > In file included from ../stlport/stl/debug/_debug.c:236, > from ../stlport/stl/debug/_debug.h:418, > from ../stlport/utility:36, > from dll_main.cpp:36: > ../stlport/cstdarg:32: error: `__std_alias::va_list' has not been declared > In file included from ../stlport/stl/debug/_debug.c:237, > from ../stlport/stl/debug/_debug.h:418, > from ../stlport/utility:36, > from dll_main.cpp:36: > ../stlport/cstdio:27:45: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c+ +/3.4.2/cstdio: > No such file or directory > In file included from ../stlport/stl/debug/_debug.c:237, > from ../stlport/stl/debug/_debug.h:418, > from ../stlport/utility:36, > from dll_main.cpp:36: > ../stlport/cstdio:51: error: `__std_alias::FILE' has not been declared > ../stlport/cstdio:52: error: `__std_alias::fpos_t' has not been declared > ../stlport/cstdio:53: error: `__std_alias::size_t' has not been declared > ../stlport/cstdio:64: error: `__std_alias::clearerr' has not been declared > ../stlport/cstdio:65: error: `__std_alias::fclose' has not been declared > ../stlport/cstdio:66: error: `__std_alias::feof' has not been declared > ../stlport/cstdio:67: error: `__std_alias::ferror' has not been declared > ../stlport/cstdio:68: error: `__std_alias::fflush' has not been declared > ../stlport/cstdio:69: error: `__std_alias::fgetc' has not been declared > ../stlport/cstdio:70: error: `__std_alias::fgetpos' has not been declared > ../stlport/cstdio:71: error: `__std_alias::fgets' has not been declared > ../stlport/cstdio:72: error: `__std_alias::fopen' has not been declared > ../stlport/cstdio:73: error: `__std_alias::fprintf' has not been declared > ../stlport/cstdio:74: error: `__std_alias::fputc' has not been declared > ../stlport/cstdio:75: error: `__std_alias::fputs' has not been declared > ../stlport/cstdio:76: error: `__std_alias::fread' has not been declared > ../stlport/cstdio:77: error: `__std_alias::freopen' has not been declared > ../stlport/cstdio:78: error: `__std_alias::fscanf' has not been declared > ../stlport/cstdio:79: error: `__std_alias::fseek' has not been declared > ../stlport/cstdio:80: error: `__std_alias::fsetpos' has not been declared > ../stlport/cstdio:81: error: `__std_alias::ftell' has not been declared > ../stlport/cstdio:82: error: `__std_alias::fwrite' has not been declared > ../stlport/cstdio:85: error: `__std_alias::getc' has not been declared > ../stlport/cstdio:86: error: `__std_alias::getchar' has not been declared > ../stlport/cstdio:87: error: `__std_alias::putc' has not been declared > ../stlport/cstdio:88: error: `__std_alias::putchar' has not been declared > ../stlport/cstdio:91: error: `__std_alias::gets' has not been declared > ../stlport/cstdio:92: error: `__std_alias::perror' has not been declared > ../stlport/cstdio:93: error: `__std_alias::printf' has not been declared > ../stlport/cstdio:94: error: `__std_alias::puts' has not been declared > ../stlport/cstdio:95: error: `__std_alias::remove' has not been declared > ../stlport/cstdio:96: error: `__std_alias::rename' has not been declared > ../stlport/cstdio:97: error: `__std_alias::rewind' has not been declared > ../stlport/cstdio:98: error: `__std_alias::scanf' has not been declared > ../stlport/cstdio:99: error: `__std_alias::setbuf' has not been declared > ../stlport/cstdio:100: error: `__std_alias::setvbuf' has not been declared > ../stlport/cstdio:101: error: `__std_alias::sprintf' has not been declared > ../stlport/cstdio:102: error: `__std_alias::sscanf' has not been declared > ../stlport/cstdio:103: error: `__std_alias::tmpfile' has not been declared > ../stlport/cstdio:104: error: `__std_alias::tmpnam' has not been declared > ../stlport/cstdio:105: error: `__std_alias::ungetc' has not been declared > ../stlport/cstdio:106: error: `__std_alias::vfprintf' has not been declared > ../stlport/cstdio:107: error: `__std_alias::vprintf' has not been declared > ../stlport/cstdio:108: error: `__std_alias::vsprintf' has not been declared > ../stlport/cstdio:111: error: `__std_alias::vsnprintf' has not been declared > In file included from ../stlport/stl/debug/_debug.h:418, > from ../stlport/utility:36, > from dll_main.cpp:36: > ../stlport/stl/debug/_debug.c: In static member function `static void > _STL::__st l_debug_engine<_Dummy>::_Message(const char*, ...)': > ../stlport/stl/debug/_debug.c:245: error: `va_list' is not a member of > `__std_al ias' > ../stlport/stl/debug/_debug.c:245: error: expected `;' before "__args" > ../stlport/stl/debug/_debug.c:246: error: `__args' undeclared (first use > this fu nction) > ../stlport/stl/debug/_debug.c:246: error: (Each undeclared identifier is > reporte d only once for each function it appears in.) > ../stlport/stl/debug/_debug.c:246: error: there are no arguments to > `va_start' t hat depend on a template parameter, so a declaration of > `va_start' must be avail able > ../stlport/stl/debug/_debug.c:246: error: (if you use `-fpermissive', > G++ will a ccept your code, but allowing the use of an undeclared name > is deprecated) > ../stlport/stl/debug/_debug.c:263: error: `vfprintf' is not a member of > `__std_a lias' > ../stlport/stl/debug/_debug.c:263: error: `stderr' undeclared (first use > this fu nction) > ../stlport/stl/debug/_debug.c:270: error: there are no arguments to > `va_end' tha t depend on a template parameter, so a declaration of > `va_end' must be available > ../stlport/stl/debug/_debug.c: In static member function `static void > _STL::__st l_debug_engine<_Dummy>::_Terminate()': > ../stlport/stl/debug/_debug.c:319: error: there are no arguments to > `abort' that depend on a template parameter, so a declaration of > `abort' must be available > In file included from ../stlport/stl/_alloc.h:31, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/cstddef:35:46: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c ++/3.4.2/cstddef: > No such file or directory > In file included from ../stlport/stl/_alloc.h:31, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/cstddef: At global scope: > ../stlport/cstddef:42: error: `__std_alias::ptrdiff_t' has not been declared > ../stlport/cstddef:43: error: `__std_alias::size_t' has not been declared > In file included from ../stlport/stl/_alloc.h:42, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/cstring:25:46: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c ++/3.4.2/cstring: > No such file or directory > In file included from ../stlport/cstring:32, > from ../stlport/stl/_alloc.h:42, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/using/cstring:1: error: `__std_alias::size_t' has not been > declared > ../stlport/using/cstring:17: error: `__std_alias::memmove' has not been > declared > ../stlport/using/cstring:18: error: `__std_alias::memcpy' has not been > declared > ../stlport/using/cstring:23: error: `__std_alias::memchr' has not been > declared > ../stlport/using/cstring:24: error: `__std_alias::strchr' has not been > declared > ../stlport/using/cstring:25: error: `__std_alias::strpbrk' has not been > declared > ../stlport/using/cstring:26: error: `__std_alias::strrchr' has not been > declared > ../stlport/using/cstring:27: error: `__std_alias::strstr' has not been > declared > ../stlport/using/cstring:30: error: `__std_alias::memcmp' has not been > declared > ../stlport/using/cstring:31: error: `__std_alias::memset' has not been > declared > ../stlport/using/cstring:33: error: `__std_alias::strcat' has not been > declared > ../stlport/using/cstring:36: error: `__std_alias::strcmp' has not been > declared > ../stlport/using/cstring:39: error: `__std_alias::strcoll' has not been > declared > ../stlport/using/cstring:41: error: `__std_alias::strcpy' has not been > declared > ../stlport/using/cstring:43: error: `__std_alias::strcspn' has not been > declared > ../stlport/using/cstring:44: error: `__std_alias::strerror' has not been > declare d > ../stlport/using/cstring:45: error: `__std_alias::strlen' has not been > declared > ../stlport/using/cstring:46: error: `__std_alias::strncat' has not been > declared > ../stlport/using/cstring:47: error: `__std_alias::strncmp' has not been > declared > ../stlport/using/cstring:49: error: `__std_alias::strncpy' has not been > declared > ../stlport/using/cstring:50: error: `__std_alias::strspn' has not been > declared > ../stlport/using/cstring:52: error: `__std_alias::strtok' has not been > declared > ../stlport/using/cstring:53: error: `__std_alias::strxfrm' has not been > declared > In file included from ../stlport/stl/_alloc.h:60, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/new:50:49: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c++/3 .4.2/new: No > such file or directory > In file included from ../stlport/stl/_alloc.h:60, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/new:58: error: `__std_alias::bad_alloc' has not been declared > ../stlport/new:59: error: `__std_alias::nothrow_t' has not been declared > ../stlport/new:60: error: `__std_alias::nothrow' has not been declared > ../stlport/new:66: error: `__std_alias::new_handler' has not been declared > ../stlport/new:67: error: `__std_alias::set_new_handler' has not been > declared > ../stlport/new:112: error: `_STL::__stl_new' declared as an `inline' > variable > ../stlport/new:112: error: `size_t' was not declared in this scope > ../stlport/new:112: error: expected `,' or `;' before '{' token > In file included from ../stlport/stl/_alloc.h:64, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/stl/_threads.h:53: error: `size_t' does not name a type > In file included from ../stlport/stl/_alloc.h:64, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/stl/_threads.h:207: error: expected `,' or `...' before '*' token > ../stlport/stl/_threads.h:207: error: ISO C++ forbids declaration of > `__stl_atom ic_t' with no type > ../stlport/stl/_threads.h: In member function `void > _STL::_STLP_mutex_indirect:: _M_initialize()': > ../stlport/stl/_threads.h:340: error: `calloc' is not a member of > `__std_alias' > ../stlport/stl/_threads.h: In member function `void > _STL::_STLP_mutex_indirect:: _M_destroy()': > ../stlport/stl/_threads.h:345: error: `free' undeclared (first use this > function ) > ../stlport/stl/_threads.h: At global scope: > ../stlport/stl/_threads.h:409: error: `__stl_atomic_t' does not name a type > ../stlport/stl/_threads.h:416: error: expected `)' before "__n" > ../stlport/stl/_threads.h: In member function `void > _STL::_Refcount_Base::_M_inc r()': > ../stlport/stl/_threads.h:425: error: `_M_ref_count' undeclared (first > use this function) > ../stlport/stl/_threads.h: In member function `void > _STL::_Refcount_Base::_M_dec r()': > ../stlport/stl/_threads.h:430: error: `_M_ref_count' undeclared (first > use this function) > ../stlport/stl/_threads.h: At global scope: > ../stlport/stl/_threads.h:458: error: `__stl_atomic_t' does not name a type > In file included from ../stlport/stl/_threads.h:552, > from ../stlport/stl/_alloc.h:64, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/stl/_threads.c:36: error: `__std_alias::time_t' has not been > declared > In file included from ../stlport/stl/_threads.h:552, > from ../stlport/stl/_alloc.h:64, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/stl/_threads.c:98: error: expected `,' or `...' before '*' token > ../stlport/stl/_threads.c:99: error: ISO C++ forbids declaration of > `__stl_atomi c_t' with no type > In file included from ../stlport/stl/_construct.h:43, > from ../stlport/stl/_alloc.h:68, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/stl/_iterator_base.h:50: error: `ptrdiff_t' has not been declared > ../stlport/stl/_iterator_base.h:113: error: `ptrdiff_t' does not name a type > ../stlport/stl/_iterator_base.h:122: error: `ptrdiff_t' does not name a type > In file included from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/stl/_alloc.h: In static member function `static void* > _STL::__malloc_ alloc<__inst>::allocate(size_t)': > ../stlport/stl/_alloc.h:110: error: there are no arguments to `malloc' > that depe nd on a template parameter, so a declaration of `malloc' must > be available > ../stlport/stl/_alloc.h: In static member function `static void > _STL::__malloc_a lloc<__inst>::deallocate(void*, size_t)': > ../stlport/stl/_alloc.h:114: error: there are no arguments to `free' > that depend on a template parameter, so a declaration of `free' must be > available > ../stlport/stl/_alloc.h: In static member function `static void* > _STL::__new_all oc::allocate(size_t)': > ../stlport/stl/_alloc.h:134: error: `_STL::__stl_new' cannot be used as > a functi on > ../stlport/stl/_alloc.h: In static member function `static void* > _STL::__node_al loc<__threads, __inst>::allocate(size_t)': > ../stlport/stl/_alloc.h:251: error: `_STL::__stl_new' cannot be used as > a functi on > ../stlport/stl/_alloc.h: At global scope: > ../stlport/stl/_alloc.h:339: error: `ptrdiff_t' does not name a type > ../stlport/stl/_alloc.h:377: error: `ptrdiff_t' does not name a type > ../stlport/stl/_alloc.h:416: error: non-template `rebind' used as template > ../stlport/stl/_alloc.h:416: note: use `_Allocator::template rebind' to > indicate that it is a template > ../stlport/stl/_alloc.h:416: error: declaration does not declare anything > ../stlport/stl/_alloc.h:417: error: `_Rebind_type' has not been declared > ../stlport/stl/_alloc.h:417: error: expected nested-name-specifier > before "other " > ../stlport/stl/_alloc.h:417: error: `other' does not name a type > ../stlport/stl/_alloc.h:418: error: `allocator_type' does not name a type > ../stlport/stl/_alloc.h: In function `typename _STL::_Alloc_traits<_Tp, > _Allocat or>::allocator_type _STL::__stl_alloc_create(const _Alloc&, > const _Tp*)': > ../stlport/stl/_alloc.h:460: error: non-template `rebind' used as template > ../stlport/stl/_alloc.h:460: note: use `_Alloc::template rebind' to > indicate tha t it is a template > ../stlport/stl/_alloc.h:460: error: declaration does not declare anything > In file included from ../stlport/stl/_alloc.h:517, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/stl/_alloc.c: In static member function `static void* > _STL::__malloc_ alloc<__inst>::_S_oom_malloc(size_t)': > ../stlport/stl/_alloc.c:69: error: `bad_alloc' is not a member of `_STL' > ../stlport/stl/_alloc.c:71: error: there are no arguments to `malloc' > that depen d on a template parameter, so a declaration of `malloc' must > be available > ../stlport/stl/_alloc.c: In static member function `static char* > _STL::__node_al loc<__threads, __inst>::_S_chunk_alloc(size_t, int&)': > ../stlport/stl/_alloc.c:218: error: `_STL::__stl_new' cannot be used as > a functi on > ../stlport/stl/_alloc.c:239: error: `_STL::__stl_new' cannot be used as > a functi on > In file included from ../stlport/stl/_tempbuf.h:34, > from ../stlport/memory:32, > from dll_main.cpp:38: > ../stlport/climits:27:46: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c ++/3.4.2/climits: > No such file or directory > In file included from ../stlport/stl/_uninitialized.h:38, > from ../stlport/stl/_tempbuf.h:40, > from ../stlport/memory:32, > from dll_main.cpp:38: > ../stlport/stl/_algobase.h: In function `void* > _STL::__copy_trivial(const void*, const void*, void*)': > ../stlport/stl/_algobase.h:149: error: `memmove' undeclared (first use > this func tion) > ../stlport/stl/_algobase.h: In function `void* > _STL::__copy_trivial_backward(con st void*, const void*, void*)': > ../stlport/stl/_algobase.h:183: error: `ptrdiff_t' does not name a type > ../stlport/stl/_algobase.h:184: error: `_Num' undeclared (first use this > functio n) > ../stlport/stl/_algobase.h:184: error: `memmove' undeclared (first use > this func tion) > ../stlport/stl/_algobase.h: In function `void _STL::fill(unsigned char*, > unsigne d char*, const unsigned char&)': > ../stlport/stl/_algobase.h:345: error: `memset' undeclared (first use > this funct ion) > ../stlport/stl/_algobase.h: In function `void _STL::fill(signed char*, > signed ch ar*, const signed char&)': > ../stlport/stl/_algobase.h:351: error: `memset' undeclared (first use > this funct ion) > ../stlport/stl/_algobase.h: In function `void _STL::fill(char*, char*, > const cha r&)': > ../stlport/stl/_algobase.h:356: error: `memset' undeclared (first use > this funct ion) > ../stlport/stl/_algobase.h: In function `bool > _STL::lexicographical_compare(cons t unsigned char*, const unsigned > char*, const unsigned char*, const unsigned cha r*)': > ../stlport/stl/_algobase.h:464: error: `memcmp' undeclared (first use > this funct ion) > ../stlport/stl/_algobase.h: In function `int > _STL::__lexicographical_compare_3wa y(const unsigned char*, const > unsigned char*, const unsigned char*, const unsign ed char*)': > ../stlport/stl/_algobase.h:493: error: `ptrdiff_t' does not name a type > ../stlport/stl/_algobase.h:494: error: `ptrdiff_t' does not name a type > ../stlport/stl/_algobase.h:495: error: `__len1' undeclared (first use > this funct ion) > ../stlport/stl/_algobase.h:495: error: `__len2' undeclared (first use > this funct ion) > ../stlport/stl/_algobase.h:495: error: `memcmp' undeclared (first use > this funct ion) > In file included from ../stlport/memory:32, > from dll_main.cpp:38: > ../stlport/stl/_tempbuf.h: At global scope: > ../stlport/stl/_tempbuf.h:46: error: `ptrdiff_t' was not declared in > this scope > ../stlport/stl/_tempbuf.h:47: error: template argument 2 is invalid > ../stlport/stl/_tempbuf.h:47: error: invalid type in declaration before > '(' toke n > ../stlport/stl/_tempbuf.h:47: error: template declaration of `int > _STL::__get_te mporary_buffer' > ../stlport/stl/_tempbuf.h:47: error: `ptrdiff_t' was not declared in > this scope > ../stlport/stl/_tempbuf.h:47: error: expected primary-expression before > '*' toke n > ../stlport/stl/_tempbuf.h:47: error: expected primary-expression before > ')' toke n > ../stlport/stl/_tempbuf.h:47: confused by earlier errors, bailing out > make: *** [../lib/obj/GCC/ReleaseD/dll_main.o] Error 1 > dmake: Error code 2, while making > './unxlngi4.pro/misc/build/so_built_so_stlpor t' > ---* TG_SLO.MK *--- > > ERROR: Error 65280 occurred while making > /home/kaspars/install/ooo/OOo/stlport > dmake: Error code 1, while making 'build_all' > ---* TG_SLO.MK *--- > > > thanks, > > Casper > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From dcbw at redhat.com Sat Jan 1 02:38:31 2005 From: dcbw at redhat.com (Dan Williams) Date: Fri, 31 Dec 2004 21:38:31 -0500 (EST) Subject: Compiling src OpenOffice.org 1.1.4 on FC3 In-Reply-To: <41D5576E.8070102@os.lv> References: <41D5576E.8070102@os.lv> Message-ID: I might also add the we added gcc 3.4 support for the OpenOffice.org 2.0 builds, as well as the current 1.9.x pre-release builds that are distributed by openoffice.org. Anything higher than 1.1.x should build with gcc 3.4 out of the box. Dan On Fri, 31 Dec 2004, Kaspars wrote: > > Hi, > > I try to compile on FC3 lates OpenOffice.org, but without success. > Maybe somebody have better lack with it? Know what I`m doing wrong. > > I`m doing: > $cd OOo_src/config_office/ > $./configure --prefix=/opt/OOo --with-jdk-home=/opt/java/ \ > --with-x --enable-libart > $tcsh -c "source LinuxIntelEnv.Set; ./bootstrap" > $tcsh -c "source LinuxIntelEnv.Set; dmake" > > and thats the error: > STLport-4.5/doc/doc.css > make writeable... > echo dummy > ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0.mak > touch ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0.mak > echo dummy > ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0-macosx.mak > touch ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0-macosx.mak > echo dummy > ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0-freebsd.mak > touch ./unxlngi4.pro/misc/build/STLport-4.5/src/gcc-3.0-freebsd.mak > echo dummy > ./unxlngi4.pro/misc/build/STLport-4.5/src/sunpro8.mak > touch ./unxlngi4.pro/misc/build/STLport-4.5/src/sunpro8.mak > cd ./unxlngi4.pro/misc/build && cat ../../../STLport-4.5.patch | patch > -b -p2 && touch so_patched_so_stlport > patching file STLport-4.5/src/dll_main.cpp > patching file STLport-4.5/src/gcc-3.0-freebsd.mak > patching file STLport-4.5/src/gcc-3.0-macosx.mak > patching file STLport-4.5/src/gcc-3.0.mak > patching file STLport-4.5/src/gcc-freebsd.mak > patching file STLport-4.5/stlport/config/stl_gcc.h > patching file STLport-4.5/stlport/cwchar > patching file STLport-4.5/stlport/stdexcept > patching file STLport-4.5/stlport/stl/_threads.h > touch ./unxlngi4.pro/misc/build/so_addfiles_so_stlport > touch ./unxlngi4.pro/misc/build/so_patched_so_stlport > touch ./unxlngi4.pro/misc/build/so_configured_so_stlport > mkdir ./unxlngi4.pro/misc/build/STLport-4.5/src > mkdir: cannot create directory > `./unxlngi4.pro/misc/build/STLport-4.5/src': File exists > cd ./unxlngi4.pro/misc/build/STLport-4.5/src && make -f gcc-3.0.mak -j1 > && touch so_built_so_stlport > mkdir -p ../lib/obj/GCC/ReleaseD > g++ -D_REENTRANT > -DGXX_INCLUDE_PATH=/usr/lib/gcc/i386-redhat-linux/3.4.2/../../. > ./../include/c++/3.4.2 -fexceptions -I../stlport -Wall -W > -Wno-sign-compare -Wno -unused -Wno-uninitialized -ftemplate-depth-32 > -O2 -fPIC dll_main.cpp -c -o ../l ib/obj/GCC/ReleaseD/dll_main.o > In file included from stlport_prefix.h:28, > from dll_main.cpp:34: > ../stlport/ctime:25:44: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c++ /3.4.2/ctime: > No such file or directory > In file included from stlport_prefix.h:28, > from dll_main.cpp:34: > ../stlport/ctime:32: error: `__std_alias::size_t' has not been declared > ../stlport/ctime:33: error: `__std_alias::clock_t' has not been declared > ../stlport/ctime:34: error: `__std_alias::time_t' has not been declared > ../stlport/ctime:35: error: `__std_alias::tm' has not been declared > ../stlport/ctime:37: error: `__std_alias::clock' has not been declared > ../stlport/ctime:38: error: `__std_alias::asctime' has not been declared > ../stlport/ctime:39: error: `__std_alias::ctime' has not been declared > ../stlport/ctime:40: error: `__std_alias::gmtime' has not been declared > ../stlport/ctime:41: error: `__std_alias::difftime' has not been declared > ../stlport/ctime:42: error: `__std_alias::mktime' has not been declared > ../stlport/ctime:43: error: `__std_alias::localtime' has not been declared > ../stlport/ctime:44: error: `__std_alias::strftime' has not been declared > ../stlport/ctime:45: error: `__std_alias::time' has not been declared > In file included from dll_main.cpp:34: > stlport_prefix.h:30: error: `__std_alias::time_t' has not been declared > In file included from ../stlport/stl/debug/_debug.c:160, > from ../stlport/stl/debug/_debug.h:418, > from ../stlport/utility:36, > from dll_main.cpp:36: > ../stlport/cstdlib:25:46: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c ++/3.4.2/cstdlib: > No such file or directory > In file included from ../stlport/stl/debug/_debug.c:160, > from ../stlport/stl/debug/_debug.h:418, > from ../stlport/utility:36, > from dll_main.cpp:36: > ../stlport/cstdlib:42: error: `__std_alias::div_t' has not been declared > ../stlport/cstdlib:43: error: `__std_alias::ldiv_t' has not been declared > ../stlport/cstdlib:44: error: `__std_alias::size_t' has not been declared > ../stlport/cstdlib:47: error: `__std_alias::abort' has not been declared > ../stlport/cstdlib:48: error: `__std_alias::atexit' has not been declared > ../stlport/cstdlib:49: error: `__std_alias::exit' has not been declared > ../stlport/cstdlib:50: error: `__std_alias::getenv' has not been declared > ../stlport/cstdlib:51: error: `__std_alias::calloc' has not been declared > ../stlport/cstdlib:52: error: `__std_alias::free' has not been declared > ../stlport/cstdlib:53: error: `__std_alias::malloc' has not been declared > ../stlport/cstdlib:54: error: `__std_alias::realloc' has not been declared > ../stlport/cstdlib:55: error: `__std_alias::atof' has not been declared > ../stlport/cstdlib:56: error: `__std_alias::atoi' has not been declared > ../stlport/cstdlib:57: error: `__std_alias::atol' has not been declared > ../stlport/cstdlib:58: error: `__std_alias::mblen' has not been declared > ../stlport/cstdlib:59: error: `__std_alias::mbstowcs' has not been declared > ../stlport/cstdlib:60: error: `__std_alias::mbtowc' has not been declared > ../stlport/cstdlib:61: error: `__std_alias::strtod' has not been declared > ../stlport/cstdlib:62: error: `__std_alias::strtol' has not been declared > ../stlport/cstdlib:63: error: `__std_alias::strtoul' has not been declared > ../stlport/cstdlib:64: error: `__std_alias::system' has not been declared > ../stlport/cstdlib:70: error: `__std_alias::bsearch' has not been declared > ../stlport/cstdlib:71: error: `__std_alias::qsort' has not been declared > ../stlport/cstdlib:74: error: `__std_alias::abs' has not been declared > ../stlport/cstdlib:76: error: `__std_alias::div' has not been declared > ../stlport/cstdlib:77: error: `__std_alias::labs' has not been declared > ../stlport/cstdlib:78: error: `__std_alias::ldiv' has not been declared > ../stlport/cstdlib:79: error: `__std_alias::rand' has not been declared > ../stlport/cstdlib:80: error: `__std_alias::srand' has not been declared > In file included from ../stlport/stl/debug/_debug.c:236, > from ../stlport/stl/debug/_debug.h:418, > from ../stlport/utility:36, > from dll_main.cpp:36: > ../stlport/cstdarg:25:46: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c ++/3.4.2/cstdarg: > No such file or directory > In file included from ../stlport/stl/debug/_debug.c:236, > from ../stlport/stl/debug/_debug.h:418, > from ../stlport/utility:36, > from dll_main.cpp:36: > ../stlport/cstdarg:32: error: `__std_alias::va_list' has not been declared > In file included from ../stlport/stl/debug/_debug.c:237, > from ../stlport/stl/debug/_debug.h:418, > from ../stlport/utility:36, > from dll_main.cpp:36: > ../stlport/cstdio:27:45: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c+ +/3.4.2/cstdio: > No such file or directory > In file included from ../stlport/stl/debug/_debug.c:237, > from ../stlport/stl/debug/_debug.h:418, > from ../stlport/utility:36, > from dll_main.cpp:36: > ../stlport/cstdio:51: error: `__std_alias::FILE' has not been declared > ../stlport/cstdio:52: error: `__std_alias::fpos_t' has not been declared > ../stlport/cstdio:53: error: `__std_alias::size_t' has not been declared > ../stlport/cstdio:64: error: `__std_alias::clearerr' has not been declared > ../stlport/cstdio:65: error: `__std_alias::fclose' has not been declared > ../stlport/cstdio:66: error: `__std_alias::feof' has not been declared > ../stlport/cstdio:67: error: `__std_alias::ferror' has not been declared > ../stlport/cstdio:68: error: `__std_alias::fflush' has not been declared > ../stlport/cstdio:69: error: `__std_alias::fgetc' has not been declared > ../stlport/cstdio:70: error: `__std_alias::fgetpos' has not been declared > ../stlport/cstdio:71: error: `__std_alias::fgets' has not been declared > ../stlport/cstdio:72: error: `__std_alias::fopen' has not been declared > ../stlport/cstdio:73: error: `__std_alias::fprintf' has not been declared > ../stlport/cstdio:74: error: `__std_alias::fputc' has not been declared > ../stlport/cstdio:75: error: `__std_alias::fputs' has not been declared > ../stlport/cstdio:76: error: `__std_alias::fread' has not been declared > ../stlport/cstdio:77: error: `__std_alias::freopen' has not been declared > ../stlport/cstdio:78: error: `__std_alias::fscanf' has not been declared > ../stlport/cstdio:79: error: `__std_alias::fseek' has not been declared > ../stlport/cstdio:80: error: `__std_alias::fsetpos' has not been declared > ../stlport/cstdio:81: error: `__std_alias::ftell' has not been declared > ../stlport/cstdio:82: error: `__std_alias::fwrite' has not been declared > ../stlport/cstdio:85: error: `__std_alias::getc' has not been declared > ../stlport/cstdio:86: error: `__std_alias::getchar' has not been declared > ../stlport/cstdio:87: error: `__std_alias::putc' has not been declared > ../stlport/cstdio:88: error: `__std_alias::putchar' has not been declared > ../stlport/cstdio:91: error: `__std_alias::gets' has not been declared > ../stlport/cstdio:92: error: `__std_alias::perror' has not been declared > ../stlport/cstdio:93: error: `__std_alias::printf' has not been declared > ../stlport/cstdio:94: error: `__std_alias::puts' has not been declared > ../stlport/cstdio:95: error: `__std_alias::remove' has not been declared > ../stlport/cstdio:96: error: `__std_alias::rename' has not been declared > ../stlport/cstdio:97: error: `__std_alias::rewind' has not been declared > ../stlport/cstdio:98: error: `__std_alias::scanf' has not been declared > ../stlport/cstdio:99: error: `__std_alias::setbuf' has not been declared > ../stlport/cstdio:100: error: `__std_alias::setvbuf' has not been declared > ../stlport/cstdio:101: error: `__std_alias::sprintf' has not been declared > ../stlport/cstdio:102: error: `__std_alias::sscanf' has not been declared > ../stlport/cstdio:103: error: `__std_alias::tmpfile' has not been declared > ../stlport/cstdio:104: error: `__std_alias::tmpnam' has not been declared > ../stlport/cstdio:105: error: `__std_alias::ungetc' has not been declared > ../stlport/cstdio:106: error: `__std_alias::vfprintf' has not been declared > ../stlport/cstdio:107: error: `__std_alias::vprintf' has not been declared > ../stlport/cstdio:108: error: `__std_alias::vsprintf' has not been declared > ../stlport/cstdio:111: error: `__std_alias::vsnprintf' has not been declared > In file included from ../stlport/stl/debug/_debug.h:418, > from ../stlport/utility:36, > from dll_main.cpp:36: > ../stlport/stl/debug/_debug.c: In static member function `static void > _STL::__st l_debug_engine<_Dummy>::_Message(const char*, ...)': > ../stlport/stl/debug/_debug.c:245: error: `va_list' is not a member of > `__std_al ias' > ../stlport/stl/debug/_debug.c:245: error: expected `;' before "__args" > ../stlport/stl/debug/_debug.c:246: error: `__args' undeclared (first use > this fu nction) > ../stlport/stl/debug/_debug.c:246: error: (Each undeclared identifier is > reporte d only once for each function it appears in.) > ../stlport/stl/debug/_debug.c:246: error: there are no arguments to > `va_start' t hat depend on a template parameter, so a declaration of > `va_start' must be avail able > ../stlport/stl/debug/_debug.c:246: error: (if you use `-fpermissive', > G++ will a ccept your code, but allowing the use of an undeclared name > is deprecated) > ../stlport/stl/debug/_debug.c:263: error: `vfprintf' is not a member of > `__std_a lias' > ../stlport/stl/debug/_debug.c:263: error: `stderr' undeclared (first use > this fu nction) > ../stlport/stl/debug/_debug.c:270: error: there are no arguments to > `va_end' tha t depend on a template parameter, so a declaration of > `va_end' must be available > ../stlport/stl/debug/_debug.c: In static member function `static void > _STL::__st l_debug_engine<_Dummy>::_Terminate()': > ../stlport/stl/debug/_debug.c:319: error: there are no arguments to > `abort' that depend on a template parameter, so a declaration of > `abort' must be available > In file included from ../stlport/stl/_alloc.h:31, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/cstddef:35:46: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c ++/3.4.2/cstddef: > No such file or directory > In file included from ../stlport/stl/_alloc.h:31, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/cstddef: At global scope: > ../stlport/cstddef:42: error: `__std_alias::ptrdiff_t' has not been declared > ../stlport/cstddef:43: error: `__std_alias::size_t' has not been declared > In file included from ../stlport/stl/_alloc.h:42, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/cstring:25:46: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c ++/3.4.2/cstring: > No such file or directory > In file included from ../stlport/cstring:32, > from ../stlport/stl/_alloc.h:42, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/using/cstring:1: error: `__std_alias::size_t' has not been > declared > ../stlport/using/cstring:17: error: `__std_alias::memmove' has not been > declared > ../stlport/using/cstring:18: error: `__std_alias::memcpy' has not been > declared > ../stlport/using/cstring:23: error: `__std_alias::memchr' has not been > declared > ../stlport/using/cstring:24: error: `__std_alias::strchr' has not been > declared > ../stlport/using/cstring:25: error: `__std_alias::strpbrk' has not been > declared > ../stlport/using/cstring:26: error: `__std_alias::strrchr' has not been > declared > ../stlport/using/cstring:27: error: `__std_alias::strstr' has not been > declared > ../stlport/using/cstring:30: error: `__std_alias::memcmp' has not been > declared > ../stlport/using/cstring:31: error: `__std_alias::memset' has not been > declared > ../stlport/using/cstring:33: error: `__std_alias::strcat' has not been > declared > ../stlport/using/cstring:36: error: `__std_alias::strcmp' has not been > declared > ../stlport/using/cstring:39: error: `__std_alias::strcoll' has not been > declared > ../stlport/using/cstring:41: error: `__std_alias::strcpy' has not been > declared > ../stlport/using/cstring:43: error: `__std_alias::strcspn' has not been > declared > ../stlport/using/cstring:44: error: `__std_alias::strerror' has not been > declare d > ../stlport/using/cstring:45: error: `__std_alias::strlen' has not been > declared > ../stlport/using/cstring:46: error: `__std_alias::strncat' has not been > declared > ../stlport/using/cstring:47: error: `__std_alias::strncmp' has not been > declared > ../stlport/using/cstring:49: error: `__std_alias::strncpy' has not been > declared > ../stlport/using/cstring:50: error: `__std_alias::strspn' has not been > declared > ../stlport/using/cstring:52: error: `__std_alias::strtok' has not been > declared > ../stlport/using/cstring:53: error: `__std_alias::strxfrm' has not been > declared > In file included from ../stlport/stl/_alloc.h:60, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/new:50:49: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c++/3 .4.2/new: No > such file or directory > In file included from ../stlport/stl/_alloc.h:60, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/new:58: error: `__std_alias::bad_alloc' has not been declared > ../stlport/new:59: error: `__std_alias::nothrow_t' has not been declared > ../stlport/new:60: error: `__std_alias::nothrow' has not been declared > ../stlport/new:66: error: `__std_alias::new_handler' has not been declared > ../stlport/new:67: error: `__std_alias::set_new_handler' has not been > declared > ../stlport/new:112: error: `_STL::__stl_new' declared as an `inline' > variable > ../stlport/new:112: error: `size_t' was not declared in this scope > ../stlport/new:112: error: expected `,' or `;' before '{' token > In file included from ../stlport/stl/_alloc.h:64, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/stl/_threads.h:53: error: `size_t' does not name a type > In file included from ../stlport/stl/_alloc.h:64, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/stl/_threads.h:207: error: expected `,' or `...' before '*' token > ../stlport/stl/_threads.h:207: error: ISO C++ forbids declaration of > `__stl_atom ic_t' with no type > ../stlport/stl/_threads.h: In member function `void > _STL::_STLP_mutex_indirect:: _M_initialize()': > ../stlport/stl/_threads.h:340: error: `calloc' is not a member of > `__std_alias' > ../stlport/stl/_threads.h: In member function `void > _STL::_STLP_mutex_indirect:: _M_destroy()': > ../stlport/stl/_threads.h:345: error: `free' undeclared (first use this > function ) > ../stlport/stl/_threads.h: At global scope: > ../stlport/stl/_threads.h:409: error: `__stl_atomic_t' does not name a type > ../stlport/stl/_threads.h:416: error: expected `)' before "__n" > ../stlport/stl/_threads.h: In member function `void > _STL::_Refcount_Base::_M_inc r()': > ../stlport/stl/_threads.h:425: error: `_M_ref_count' undeclared (first > use this function) > ../stlport/stl/_threads.h: In member function `void > _STL::_Refcount_Base::_M_dec r()': > ../stlport/stl/_threads.h:430: error: `_M_ref_count' undeclared (first > use this function) > ../stlport/stl/_threads.h: At global scope: > ../stlport/stl/_threads.h:458: error: `__stl_atomic_t' does not name a type > In file included from ../stlport/stl/_threads.h:552, > from ../stlport/stl/_alloc.h:64, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/stl/_threads.c:36: error: `__std_alias::time_t' has not been > declared > In file included from ../stlport/stl/_threads.h:552, > from ../stlport/stl/_alloc.h:64, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/stl/_threads.c:98: error: expected `,' or `...' before '*' token > ../stlport/stl/_threads.c:99: error: ISO C++ forbids declaration of > `__stl_atomi c_t' with no type > In file included from ../stlport/stl/_construct.h:43, > from ../stlport/stl/_alloc.h:68, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/stl/_iterator_base.h:50: error: `ptrdiff_t' has not been declared > ../stlport/stl/_iterator_base.h:113: error: `ptrdiff_t' does not name a type > ../stlport/stl/_iterator_base.h:122: error: `ptrdiff_t' does not name a type > In file included from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/stl/_alloc.h: In static member function `static void* > _STL::__malloc_ alloc<__inst>::allocate(size_t)': > ../stlport/stl/_alloc.h:110: error: there are no arguments to `malloc' > that depe nd on a template parameter, so a declaration of `malloc' must > be available > ../stlport/stl/_alloc.h: In static member function `static void > _STL::__malloc_a lloc<__inst>::deallocate(void*, size_t)': > ../stlport/stl/_alloc.h:114: error: there are no arguments to `free' > that depend on a template parameter, so a declaration of `free' must be > available > ../stlport/stl/_alloc.h: In static member function `static void* > _STL::__new_all oc::allocate(size_t)': > ../stlport/stl/_alloc.h:134: error: `_STL::__stl_new' cannot be used as > a functi on > ../stlport/stl/_alloc.h: In static member function `static void* > _STL::__node_al loc<__threads, __inst>::allocate(size_t)': > ../stlport/stl/_alloc.h:251: error: `_STL::__stl_new' cannot be used as > a functi on > ../stlport/stl/_alloc.h: At global scope: > ../stlport/stl/_alloc.h:339: error: `ptrdiff_t' does not name a type > ../stlport/stl/_alloc.h:377: error: `ptrdiff_t' does not name a type > ../stlport/stl/_alloc.h:416: error: non-template `rebind' used as template > ../stlport/stl/_alloc.h:416: note: use `_Allocator::template rebind' to > indicate that it is a template > ../stlport/stl/_alloc.h:416: error: declaration does not declare anything > ../stlport/stl/_alloc.h:417: error: `_Rebind_type' has not been declared > ../stlport/stl/_alloc.h:417: error: expected nested-name-specifier > before "other " > ../stlport/stl/_alloc.h:417: error: `other' does not name a type > ../stlport/stl/_alloc.h:418: error: `allocator_type' does not name a type > ../stlport/stl/_alloc.h: In function `typename _STL::_Alloc_traits<_Tp, > _Allocat or>::allocator_type _STL::__stl_alloc_create(const _Alloc&, > const _Tp*)': > ../stlport/stl/_alloc.h:460: error: non-template `rebind' used as template > ../stlport/stl/_alloc.h:460: note: use `_Alloc::template rebind' to > indicate tha t it is a template > ../stlport/stl/_alloc.h:460: error: declaration does not declare anything > In file included from ../stlport/stl/_alloc.h:517, > from ../stlport/memory:28, > from dll_main.cpp:38: > ../stlport/stl/_alloc.c: In static member function `static void* > _STL::__malloc_ alloc<__inst>::_S_oom_malloc(size_t)': > ../stlport/stl/_alloc.c:69: error: `bad_alloc' is not a member of `_STL' > ../stlport/stl/_alloc.c:71: error: there are no arguments to `malloc' > that depen d on a template parameter, so a declaration of `malloc' must > be available > ../stlport/stl/_alloc.c: In static member function `static char* > _STL::__node_al loc<__threads, __inst>::_S_chunk_alloc(size_t, int&)': > ../stlport/stl/_alloc.c:218: error: `_STL::__stl_new' cannot be used as > a functi on > ../stlport/stl/_alloc.c:239: error: `_STL::__stl_new' cannot be used as > a functi on > In file included from ../stlport/stl/_tempbuf.h:34, > from ../stlport/memory:32, > from dll_main.cpp:38: > ../stlport/climits:27:46: > /usr/lib/gcc/i386-redhat-1/3.4.2/../../../../include/c ++/3.4.2/climits: > No such file or directory > In file included from ../stlport/stl/_uninitialized.h:38, > from ../stlport/stl/_tempbuf.h:40, > from ../stlport/memory:32, > from dll_main.cpp:38: > ../stlport/stl/_algobase.h: In function `void* > _STL::__copy_trivial(const void*, const void*, void*)': > ../stlport/stl/_algobase.h:149: error: `memmove' undeclared (first use > this func tion) > ../stlport/stl/_algobase.h: In function `void* > _STL::__copy_trivial_backward(con st void*, const void*, void*)': > ../stlport/stl/_algobase.h:183: error: `ptrdiff_t' does not name a type > ../stlport/stl/_algobase.h:184: error: `_Num' undeclared (first use this > functio n) > ../stlport/stl/_algobase.h:184: error: `memmove' undeclared (first use > this func tion) > ../stlport/stl/_algobase.h: In function `void _STL::fill(unsigned char*, > unsigne d char*, const unsigned char&)': > ../stlport/stl/_algobase.h:345: error: `memset' undeclared (first use > this funct ion) > ../stlport/stl/_algobase.h: In function `void _STL::fill(signed char*, > signed ch ar*, const signed char&)': > ../stlport/stl/_algobase.h:351: error: `memset' undeclared (first use > this funct ion) > ../stlport/stl/_algobase.h: In function `void _STL::fill(char*, char*, > const cha r&)': > ../stlport/stl/_algobase.h:356: error: `memset' undeclared (first use > this funct ion) > ../stlport/stl/_algobase.h: In function `bool > _STL::lexicographical_compare(cons t unsigned char*, const unsigned > char*, const unsigned char*, const unsigned cha r*)': > ../stlport/stl/_algobase.h:464: error: `memcmp' undeclared (first use > this funct ion) > ../stlport/stl/_algobase.h: In function `int > _STL::__lexicographical_compare_3wa y(const unsigned char*, const > unsigned char*, const unsigned char*, const unsign ed char*)': > ../stlport/stl/_algobase.h:493: error: `ptrdiff_t' does not name a type > ../stlport/stl/_algobase.h:494: error: `ptrdiff_t' does not name a type > ../stlport/stl/_algobase.h:495: error: `__len1' undeclared (first use > this funct ion) > ../stlport/stl/_algobase.h:495: error: `__len2' undeclared (first use > this funct ion) > ../stlport/stl/_algobase.h:495: error: `memcmp' undeclared (first use > this funct ion) > In file included from ../stlport/memory:32, > from dll_main.cpp:38: > ../stlport/stl/_tempbuf.h: At global scope: > ../stlport/stl/_tempbuf.h:46: error: `ptrdiff_t' was not declared in > this scope > ../stlport/stl/_tempbuf.h:47: error: template argument 2 is invalid > ../stlport/stl/_tempbuf.h:47: error: invalid type in declaration before > '(' toke n > ../stlport/stl/_tempbuf.h:47: error: template declaration of `int > _STL::__get_te mporary_buffer' > ../stlport/stl/_tempbuf.h:47: error: `ptrdiff_t' was not declared in > this scope > ../stlport/stl/_tempbuf.h:47: error: expected primary-expression before > '*' toke n > ../stlport/stl/_tempbuf.h:47: error: expected primary-expression before > ')' toke n > ../stlport/stl/_tempbuf.h:47: confused by earlier errors, bailing out > make: *** [../lib/obj/GCC/ReleaseD/dll_main.o] Error 1 > dmake: Error code 2, while making > './unxlngi4.pro/misc/build/so_built_so_stlpor t' > ---* TG_SLO.MK *--- > > ERROR: Error 65280 occurred while making > /home/kaspars/install/ooo/OOo/stlport > dmake: Error code 1, while making 'build_all' > ---* TG_SLO.MK *--- > > > thanks, > > Casper > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From paul at all-the-johnsons.co.uk Sat Jan 1 02:52:36 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 01 Jan 2005 02:52:36 +0000 Subject: Compiling src OpenOffice.org 1.1.4 on FC3 In-Reply-To: References: <41D5576E.8070102@os.lv> Message-ID: <1104547956.3973.29.camel@localhost.localdomain> Hi, > I might also add the we added gcc 3.4 support for the OpenOffice.org 2.0 > builds, as well as the current 1.9.x pre-release builds that are > distributed by openoffice.org. Anything higher than 1.1.x should build > with gcc 3.4 out of the box. Any chance of OOo 1.9.x as a new package in rawhide? It totally kicks ass! TTFN Paul -- "He's not the Messiah, he's a very naughty boy!" - Life of Brian, Monty Python -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nbargnesi at gmail.com Sat Jan 1 06:22:46 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Sat, 1 Jan 2005 01:22:46 -0500 Subject: Fedora core 3 FC3 only supporting 4 serial ports Oversite or BUG In-Reply-To: <41D5F99D.30209@pagestation.com> References: <41D5F86F.2020401@messagenetsystems.com> <41D5F99D.30209@pagestation.com> Message-ID: <3077b8a0041231222252ab12b9@mail.gmail.com> I would suggest a configuration issue, not a bug. The kernel config for 2.6.9 - 681 shows: CONFIG_SERIAL_8250=y ... CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y ... CONFIG_SERIAL-8250_MULTIPORT=y The default configuration between Red Hat 9 and Fedora Core 3 at the kernel level has changed. Your configuration is a bit different than what is normally used in other words. On Fri, 31 Dec 2004 20:15:09 -0500, Jerry Geis wrote: > All > > I just installed FC3 from Redhat 9. I have a quatech multiport card with > 8 ports. > Under redhat 9 there was no problem card was detect and I had ports 4 - 11. > Under FC3 the card is detected but the order of the ports is ALL messed up. > I am attempt to change the CONFIG_SERIAL_8250_NR_UARTS to 24. > I am recompiling the kernel now. I chose 24 to support 3 - 8 port serial > cards. > > Is this a configuration bug or oversite or what is going on that my 8 > port multiport > card is not supported that worked fine under redhat 9. > > THanks, > > Jerry > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 From barryn at pobox.com Sat Jan 1 06:47:40 2005 From: barryn at pobox.com (Barry K. Nathan) Date: Fri, 31 Dec 2004 22:47:40 -0800 Subject: "vanilla" kernel closest to Fedora kernel In-Reply-To: <1104537668.4066.2.camel@scout.home.local> References: <1104522835.12925.2.camel@rivendell.home.local> <1104529091.9057.1.camel@ua2-124.cust.blixtvik.net> <1104537668.4066.2.camel@scout.home.local> Message-ID: <20050101064740.GA933@ip68-4-98-123.oc.oc.cox.net> On Fri, Dec 31, 2004 at 04:01:08PM -0800, Florin Andrei wrote: > Yeap, i thought about that, but the problem is that the developers of > the patch (driver) may ignore bug reports from people not using the > vanilla kernel. I know that the Fedora kernel is not too bastardized > (it's pretty close to vanilla, like Arjan said) but... IME the vanilla kernel (2.6.9 anyway; I haven't tried 2.6.10 yet) works well enough with Fedora. FWIW, if you end up going with 2.6.9, then after you get vanilla 2.6.9 working, you may want to try a 2.6.9-ac kernel (e.g. 2.6.9-ac16). IIRC 2.6.9-ac is more up-to-date in terms of security fixes than vanilla 2.6.9, and the ac patches are less invasive than the Fedora ones so it's easier to merge them with 3rd-party patches. (At least, that's my experience.) -Barry K. Nathan From nphilipp at redhat.com Sat Jan 1 12:00:25 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 01 Jan 2005 13:00:25 +0100 Subject: why doesn't yum cache anything? In-Reply-To: <1104511292.3441.8.camel@cutter> References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <20041231105527.GA24292@devserv.devel.redhat.com> <1104511292.3441.8.camel@cutter> Message-ID: <1104580826.27982.7.camel@gibraltar.stuttgart.redhat.com> On Fri, 2004-12-31 at 11:41 -0500, seth vidal wrote: > To be clear. The part I _think_ Jamie is complaining about is just > importing the metadata. And I agree with Daniel, it's all tied up in the > python interning of the strings. > > There are a few ways to 'solve' the problem: > 1. use a python xml library that does it all internal to python which > should remove the translation issue. > 2. thin out the metadata (reduce the number of nodes). > 2a. alternatively, reorganize some of the metadata so it's faster to > get to specific information. > 3. write the xml importing layer in C. Since this would require that I > learn how to adequately program in C before going on I think this part > is unlikely. > 4. ignore it for long enough and machines will just speed up. :) As Levente has mentioned, perhaps this could be a bit speedier: 5. pickling/unpickling the yum internal data structures instead of storing/reading XML; depending on how efficient (un)pickling is, this might be faster though maybe at the cost of that we can't reuse yum caches between architectures (I think we can live with that if python doesn't pickle/unpickle portably) Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Sat Jan 1 12:10:27 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Sat, 01 Jan 2005 13:10:27 +0100 Subject: why doesn't yum cache anything? In-Reply-To: References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104511893.3441.19.camel@cutter> Message-ID: <1104581427.27982.17.camel@gibraltar.stuttgart.redhat.com> On Fri, 2004-12-31 at 14:06 -0500, Konstantin Ryabitsev wrote: > On Fri, 31 Dec 2004 11:51:33 -0500, seth vidal wrote: > > are you using mirrorlists or are you using baseurls? > > There is a rather annoying side-effect of mirrorlists -- mirrors may > not always be in sync, so quite often I issue "yum list updates" and > see that there are updates, but when I run "yum update" it hits a > different mirror, where these updates are not yet available. As a > side-effect, it has to download and parse primary.xml.gz for updates > each time the mirrors are not in sync, which depending on the > connection and processor can take a significant amount of time. I get > around it by forcing -C (cache-only mode) after initially running yum > to get the repomd.xml, but others may not know about it. We could use timestamps (either implicit on specific repomd files or explicit (generated at repo creation, then stored _in_ a file -- if we don't trust timestamps on mirrors). Yum would remember the timestamp and would refuse to use mirrors with older timestamps than already seen. Of course this wouldn't quite solve the problem of primary.xml.gz being loaded regularly -- in the case where "check-update" used a mirror with an older timestamp than "update" -- but I'd say that is intentional then. We could even have an (undocumented ;-) option ("--use-latest" ?) that forced yum to check the timestamp against the original repository rather than what it remembered, just for us people who always need the latest stuff and can't live with mirror latency ;-). Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From buildsys at redhat.com Sat Jan 1 12:54:26 2005 From: buildsys at redhat.com (Build System) Date: Sat, 1 Jan 2005 07:54:26 -0500 Subject: rawhide report: 20050101 changes Message-ID: <200501011254.j01CsQF28477@porkchop.devel.redhat.com> Updated Packages: gcc4-4.0.0-0.17 --------------- * Fri Dec 31 2004 Jakub Jelinek 4.0.0-0.17 - fix build of libgij.so (#143862) - remove libgcj.pc - fix ICE in reshape_init_array (#143034, PRs c++/18384, c++/18327) grep-2.5.1-45 ------------- * Fri Dec 31 2004 Tim Waugh 2.5.1-45 - More tests (Jakub Jelinek). - Jakub Jelinek's much improved -Fi algorithm. - Removed bogus part of grep-2.5.1-fgrep patch. nss_ldap-227-1 -------------- * Fri Dec 31 2004 Nalin Dahyabhai 227-1 - update to version 227 - force nss_ldap to mimic pam_ldap's behavior when the tls_checkpeer setting is unconfigured in ldap.conf * Fri Dec 31 2004 Nalin Dahyabhai 226-3 - fix misleading doc comment in /etc/ldap.conf -- the checkpeer setting follows libldap's default, which is dependent on the version of OpenLDAP which which this package is linked (part of #143622) rpmdb-fedora-1:4-0.20050101 --------------------------- From cpedersen at c-note.dk Sat Jan 1 13:02:15 2005 From: cpedersen at c-note.dk (Casper Pedersen) Date: Sat, 01 Jan 2005 14:02:15 +0100 Subject: Major problems ripping CD's Message-ID: <41D69F57.40300@c-note.dk> Hi, I'm sure if this is caused by me, or it's a bug, or something else. I upgraded my hardware last week, and suddenly I'm no longer able to rip cd's with Grip, dekagen, etc. The new HW is Asus P4R800-VM (ATI 9100 chipset), a P4 3GhZ, and 2 GB Ram. If I try with Grip or Sound Juicer the sustem locks up immidialty, if I use dekagen I can rip 1 CD, and then if I try with another one cdparanoia lock's up the system after 'verifying CDDA command set...' I'm running FC3 with all updates installed. Any idea? Thanks. Regards/Casper -- GPG Public key is available from: http://www.keyserver.net/ Fingerprint = 56ED 74A4 7B00 20E2 B493 0C1A 6B4E BF8F A086 FE57 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From arjanv at redhat.com Sat Jan 1 13:18:26 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 01 Jan 2005 14:18:26 +0100 Subject: Major problems ripping CD's In-Reply-To: <41D69F57.40300@c-note.dk> References: <41D69F57.40300@c-note.dk> Message-ID: <1104585506.4186.3.camel@laptopd505.fenrus.org> On Sat, 2005-01-01 at 14:02 +0100, Casper Pedersen wrote: > Hi, > > I'm sure if this is caused by me, or it's a bug, or something else. > > I upgraded my hardware last week, and suddenly I'm no longer able to rip > cd's with Grip, dekagen, etc. > The new HW is Asus P4R800-VM (ATI 9100 chipset), a P4 3GhZ, and 2 GB Ram. > > If I try with Grip or Sound Juicer the sustem locks up immidialty, if I > use dekagen I can rip 1 CD, and then if I try with another one > cdparanoia lock's up the system after 'verifying CDDA command set...' > > I'm running FC3 with all updates installed. I don't want to be rude or anything, but I think this is somewhat offtopic for this list.... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cpedersen at c-note.dk Sat Jan 1 13:29:03 2005 From: cpedersen at c-note.dk (Casper Pedersen) Date: Sat, 01 Jan 2005 14:29:03 +0100 Subject: Major problems ripping CD's In-Reply-To: <1104585506.4186.3.camel@laptopd505.fenrus.org> References: <41D69F57.40300@c-note.dk> <1104585506.4186.3.camel@laptopd505.fenrus.org> Message-ID: <41D6A59F.1070000@c-note.dk> Arjan van de Ven wrote: >On Sat, 2005-01-01 at 14:02 +0100, Casper Pedersen wrote: > > >>Hi, >> >>I'm sure if this is caused by me, or it's a bug, or something else. >> >>I upgraded my hardware last week, and suddenly I'm no longer able to rip >>cd's with Grip, dekagen, etc. >>The new HW is Asus P4R800-VM (ATI 9100 chipset), a P4 3GhZ, and 2 GB Ram. >> >>If I try with Grip or Sound Juicer the sustem locks up immidialty, if I >>use dekagen I can rip 1 CD, and then if I try with another one >>cdparanoia lock's up the system after 'verifying CDDA command set...' >> >>I'm running FC3 with all updates installed. >> >> >I don't want to be rude or anything, but I think this is somewhat >offtopic for this list.... > > > You're probably right, but I found a bug (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134558) which kind of resembles this problem, but not quite. If you're right I will humbly go away..... BTW: The chipset is a IXP200. Regards/Casper -- GPG Public key is available from: http://www.keyserver.net/ Fingerprint = 56ED 74A4 7B00 20E2 B493 0C1A 6B4E BF8F A086 FE57 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From geisj at pagestation.com Sat Jan 1 14:17:47 2005 From: geisj at pagestation.com (Jerry Geis) Date: Sat, 01 Jan 2005 09:17:47 -0500 Subject: Search fedora-devel-list for: Results per page: Output format: Match: Search for: in: in: Search all lists... [Date Prev][Date Next] [Thread Prev][Thread Next] [Thread Index] [Date Index] [Author Index] Message-ID: <41D6B10B.2010002@pagestation.com> Re: Fedora core 3 FC3 only supporting 4 serial ports Oversite or BUG - request CONFIG_SERIAL_NR_UARTS=24 NOT 4. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit What then is the process to request that a change be made in the default configuration to have CONFIG_SERIAL_NR_UARTS=24 and not the present default of 4. THanks, jerry ----------------------- I would suggest a configuration issue, not a bug. The kernel config for 2.6.9 - 681 shows: CONFIG_SERIAL_8250=y ... CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y ... CONFIG_SERIAL-8250_MULTIPORT=y The default configuration between Red Hat 9 and Fedora Core 3 at the kernel level has changed. Your configuration is a bit different than what is normally used in other words. On Fri, 31 Dec 2004 20:15:09 -0500, Jerry Geis wrote: > All > > I just installed FC3 from Redhat 9. I have a quatech multiport card with > 8 ports. > Under redhat 9 there was no problem card was detect and I had ports 4 - 11. > Under FC3 the card is detected but the order of the ports is ALL messed up. > I am attempt to change the CONFIG_SERIAL_8250_NR_UARTS to 24. > I am recompiling the kernel now. I chose 24 to support 3 - 8 port serial > cards. > > Is this a configuration bug or oversite or what is going on that my 8 > port multiport > card is not supported that worked fine under redhat 9. > > THanks, > > Jerry From kyrre at solution-forge.net Sat Jan 1 14:15:42 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 01 Jan 2005 15:15:42 +0100 Subject: Installation HDD Capacity In-Reply-To: <20041229223328.GA2618@jadzia.bu.edu> References: <522542BB9F49DC448A94F871EA58DCA51A567C@ihs-mx01.iec.inventec> <20041229223328.GA2618@jadzia.bu.edu> Message-ID: <1104588942.2973.27.camel@kyrre> ons, 29.12.2004 kl. 23.33 skrev Matthew Miller: > On Wed, Dec 29, 2004 at 04:04:37PM -0600, Atchley.Van at inventec.com wrote: > > Does anyone know how to install Fedora Core 2 on a whole 1,600 Gig HDD > > not just 1,000 Gig? > > This isn't right for thie -devel mailing list -- try again on the regular > one. (Also, when you post there -- is the "," a thousands separator or a > decimal point? That is, do you mean one point six terabytes, or one point > six gigabytes?) > Does 1.6 TB drives *exist*??!? Some kind of raid array? > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> From geisj at pagestation.com Sat Jan 1 14:23:32 2005 From: geisj at pagestation.com (Jerry Geis) Date: Sat, 01 Jan 2005 09:23:32 -0500 Subject: process to changing default of CONFIG_SERIAL_8250_NR_UARTS=4 to 24 Message-ID: <41D6B264.4090005@pagestation.com> What then is the process to request that a change be made in the default configuration to have CONFIG_SERIAL_NR_UARTS=24 and not the present default of 4. THanks, jerry ----------------------- I would suggest a configuration issue, not a bug. The kernel config for 2.6.9 - 681 shows: CONFIG_SERIAL_8250=y .. CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y .. CONFIG_SERIAL-8250_MULTIPORT=y The default configuration between Red Hat 9 and Fedora Core 3 at the kernel level has changed. Your configuration is a bit different than what is normally used in other words. On Fri, 31 Dec 2004 20:15:09 -0500, Jerry Geis wrote: >> All >> >> I just installed FC3 from Redhat 9. I have a quatech multiport card with >> 8 ports. >> Under redhat 9 there was no problem card was detect and I had ports 4 - 11. >> Under FC3 the card is detected but the order of the ports is ALL messed up. >> I am attempt to change the CONFIG_SERIAL_8250_NR_UARTS to 24. >> I am recompiling the kernel now. I chose 24 to support 3 - 8 port serial >> cards. >> >> Is this a configuration bug or oversite or what is going on that my 8 >> port multiport >> card is not supported that worked fine under redhat 9. >> >> THanks, >> >> Jerry > > -- fedora-devel-list mailing list fedora-devel-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list -- This message was scanned for spam and viruses by BitDefender. For more information please visit http://linux.bitdefender.com/ ******************************* This message has been blocked because it scored over the maximum spam threshold. The reason your message was denied was because of the following: Yes, score=5.0 required=5.0 tests=USERNAME_IN_SUBJECT autolearn=no version=3.0.0 Your message contained an instance of the previously mentioned tests (see test= above) If you did not send the original message then please ignore this e-mail. Sat Jan 1 09:18:02 EST 2005 From kyrre at solution-forge.net Sat Jan 1 14:29:55 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 01 Jan 2005 15:29:55 +0100 Subject: why doesn't yum cache anything? In-Reply-To: <41D509E5.5576F2E9@jwz.org> References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104477645.3324.7.camel@stargrazer.home.awesomeplay.com> <41D509E5.5576F2E9@jwz.org> Message-ID: <1104589794.2973.29.camel@kyrre> fre, 31.12.2004 kl. 09.12 skrev Jamie Zawinski: > Sean Middleditch wrote: > > > > It only takes a handful of seconds on my machine, which is only 1.5ghz. > > Yum is *very* RAM intensive, so if you're low there, that might be the > > slow down...? > > By "a handful of seconds" do you mean "20"? I think an acceptable > number would be, like, "3", but I'm seeing anywhere from 19 to 64, > on four different FC3 machines on two different networks: > > > 500MB RAM, 1.4GHz -- 1:04 > > time yum list '*mtr*' > Setting up Repo: base > repomd.xml 100% |=========================| 1.1 kB 00:00 > Setting up Repo: updates-released > repomd.xml 100% |=========================| 951 B 00:00 > Reading repository metadata in from local files > base : ################################################## 2622/2622 > primary.xml.gz 100% |=========================| 180 kB 00:24 > MD Read : ################################################## 408/408 > updates-re: ################################################## 408/408 > Installed Packages > mtr.i386 2:0.54-10 installed > mtr-gtk.i386 2:0.54-10 installed > 8.405u 0.860s 1:04.81 14.2% 0+0k 0+0io 9pf+0w > > 500MB RAM, 1GHz -- 0:28 > > time yum list '*mtr*' > Setting up Repo: base > Setting up Repo: updates-released > Reading repository metadata in from local files > base : ################################################## 2622/2622 > updates-re: ################################################## 405/405 > Installed Packages > mtr.i386 2:0.54-10 installed > mtr-gtk.i386 2:0.54-10 installed > 8.363u 1.310s 0:28.44 34.0% 0+0k 0+0io 60pf+0w > > 1GB RAM, 2GHz -- 0:28 > > time yum list '*mtr*' > Setting up Repo: base > repomd.xml 100% |=========================| 1.1 kB 00:00 > Setting up Repo: updates-released > repomd.xml 100% |=========================| 951 B 00:00 > Reading repository metadata in from local files > base : ################################################## 2622/2622 > primary.xml.gz 100% |=========================| 180 kB 00:01 > MD Read : ################################################## 408/408 > updates-re: ################################################## 408/408 > Installed Packages > mtr.i386 2:0.54-10 installed > Available Packages > mtr-gtk.i386 2:0.54-10 base > 5.836u 0.798s 0:28.18 23.4% 0+0k 0+0io 56pf+0w > > 1GB RAM, 2.2GHz -- 0:19 > > time yum list '*mtr*' > Setting up Repo: livna-stable > repomd.xml 100% |=========================| 951 B 00:00 > Setting up Repo: base > repomd.xml 100% |=========================| 1.1 kB 00:00 > Setting up Repo: updates-released > repomd.xml 100% |=========================| 951 B 00:00 > Setting up Repo: livna-testing > repomd.xml 100% |=========================| 951 B 00:00 > Reading repository metadata in from local files > livna-stab: ################################################## 117/117 > base : ################################################## 2622/2622 > updates-re: ################################################## 408/408 > livna-test: ################################################## 18/18 > Installed Packages > mtr.i386 2:0.54-10 installed > mtr-gtk.i386 2:0.54-10 installed > 3.639u 0.409s 0:19.88 20.2% 0+0k 0+0io 0pf+0w > You are comparing apples and oranges - those machines has different sets of repos. From arjanv at redhat.com Sat Jan 1 14:39:07 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 01 Jan 2005 15:39:07 +0100 Subject: process to changing default of CONFIG_SERIAL_8250_NR_UARTS=4 to 24 In-Reply-To: <41D6B264.4090005@pagestation.com> References: <41D6B264.4090005@pagestation.com> Message-ID: <1104590347.4186.5.camel@laptopd505.fenrus.org> On Sat, 2005-01-01 at 09:23 -0500, Jerry Geis wrote: > What then is the process to request that a change be made in the default configuration > to have CONFIG_SERIAL_NR_UARTS=24 and not the present default of 4. file a bugzilla explaining why you need this ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wrrhdev at riede.org Sat Jan 1 14:40:15 2005 From: wrrhdev at riede.org (Willem Riede) Date: Sat, 01 Jan 2005 14:40:15 +0000 Subject: process to changing default of CONFIG_SERIAL_8250_NR_UARTS=4 to 24 In-Reply-To: <41D6B264.4090005@pagestation.com> (from geisj@pagestation.com on Sat Jan 1 09:23:32 2005) References: <41D6B264.4090005@pagestation.com> Message-ID: <1104590415l.8732l.5l@serve.riede.org> On 01/01/2005 09:23:32 AM, Jerry Geis wrote: > What then is the process to request that a change be made in the default > configuration > to have CONFIG_SERIAL_NR_UARTS=24 and not the present default of 4. Create a Request For Enhancement bug entry against the kernel rpm on https://bugzilla.redhat.com/bugzilla/index.cgi Success, Willem Riede. From mricon at gmail.com Sat Jan 1 15:03:08 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Sat, 1 Jan 2005 10:03:08 -0500 Subject: why doesn't yum cache anything? In-Reply-To: <1104580826.27982.7.camel@gibraltar.stuttgart.redhat.com> References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <20041231105527.GA24292@devserv.devel.redhat.com> <1104511292.3441.8.camel@cutter> <1104580826.27982.7.camel@gibraltar.stuttgart.redhat.com> Message-ID: On Sat, 01 Jan 2005 13:00:25 +0100, Nils Philippsen wrote: > As Levente has mentioned, perhaps this could be a bit speedier: > > 5. pickling/unpickling the yum internal data structures instead of > storing/reading XML; depending on how efficient (un)pickling is, this > might be faster though maybe at the cost of that we can't reuse yum > caches between architectures (I think we can live with that if python > doesn't pickle/unpickle portably) It already does that. It only parses XML when you see "MD Read". The rest of the time it loads pickled data. The downside is that loading pickles is very memory-hungry. -- Konstantin Ryabitsev Zlotniks, INC From technojoecoolusa at charter.net Sat Jan 1 16:05:57 2005 From: technojoecoolusa at charter.net (Joseph D. Wagner) Date: Sat, 1 Jan 2005 10:05:57 -0600 Subject: Kernel 2.6.10 Can't Open Initial Console on FC3 Message-ID: <3k77vr$fs05t3@mxip08a.cluster1.charter.net> RESOLVED. I enabled support for hotplug devices and installed an initrd; then it works. They tell me there's a way to make it work without initrd, but it's ugly, messy, and not recommended: http://fedora.redhat.com/docs/udev/ I haven't yet tested to see if it works with initrd and without support for hotplug devices, but from the documentation I've read my money is on no. Joseph D. Wagner From veillard at redhat.com Sat Jan 1 16:31:10 2005 From: veillard at redhat.com (Daniel Veillard) Date: Sat, 1 Jan 2005 11:31:10 -0500 Subject: why doesn't yum cache anything? In-Reply-To: <1104511699.3441.15.camel@cutter> References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <20041231093645.GH31887@redhat.com> <41D545C5.6010305@bppiac.hu> <20041231130459.GI31887@redhat.com> <1104511699.3441.15.camel@cutter> Message-ID: <20050101163109.GL31887@redhat.com> On Fri, Dec 31, 2004 at 11:48:19AM -0500, seth vidal wrote: > > > using the reader at the C level, this include decompressing the archive > > and walking though all nodes. The main cost is to turn the parsed data into > > Python's internal representation as I said. > > > > > than wouldn't be useful to > > > implement that small portion in C? or it isn't so small part? > > > > The string interning is in the Python lib, probably in C as it's a C API > > as far as I can tell. And no I din't looked at python internal code. > > I'm talking from ignorance here: > Would it be possible to speed up the string interning by providing your > own __repr__ methods in the libxml2 python module? Unfortunately that's not where the problem lies assuming I understand what you suggest, __repr__ is used to make a string representation from a python object, while the problem we have is about building that python object (which happen to be a string) based on the C string. We should double-check where time is actually spent. Using (k)cachegrind is very useful to make such an analysis. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From alan at redhat.com Sat Jan 1 19:48:43 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 1 Jan 2005 14:48:43 -0500 Subject: "vanilla" kernel closest to Fedora kernel In-Reply-To: <20041231202409.GB12487@rogers.com> References: <1104522835.12925.2.camel@rivendell.home.local> <20041231202409.GB12487@rogers.com> Message-ID: <20050101194843.GB14963@devserv.devel.redhat.com> On Fri, Dec 31, 2004 at 03:24:09PM -0500, Dimitrie O. Paun wrote: > Thing is, Fedora's kernel is heavily patched, so just twicking the > .config file may not give you a close enough kernel. There is not a lot of patching in the Fedora kernel. 2.6.10 will run happily in the FC environment unpatched as the tmpfs selinux patchesare now in From grmoc at yahoo.com Sat Jan 1 21:30:54 2005 From: grmoc at yahoo.com (Roberto Peon) Date: Sat, 1 Jan 2005 13:30:54 -0800 (PST) Subject: Installation HDD Capacity In-Reply-To: <1104588942.2973.27.camel@kyrre> Message-ID: <20050101213054.82857.qmail@web41523.mail.yahoo.com> The original author mentioned, sometime, that this is a H/W RAID array. -Roberto JP --- Kyrre Ness Sjobak wrote: > ons, 29.12.2004 kl. 23.33 skrev Matthew Miller: > > On Wed, Dec 29, 2004 at 04:04:37PM -0600, Atchley.Van at inventec.com wrote: > > > Does anyone know how to install Fedora Core 2 on a whole 1,600 Gig HDD > > > not just 1,000 Gig? > > > > This isn't right for thie -devel mailing list -- try again on the regular > > one. (Also, when you post there -- is the "," a thousands separator or a > > decimal point? That is, do you mean one point six terabytes, or one point > > six gigabytes?) > > > > Does 1.6 TB drives *exist*??!? > > Some kind of raid array? > > -- > > Matthew Miller mattdm at mattdm.org > > Boston University Linux ------> > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From kevymac at yahoo.com Sat Jan 1 22:07:23 2005 From: kevymac at yahoo.com (Kevin McConnell) Date: Sat, 1 Jan 2005 14:07:23 -0800 (PST) Subject: building own RPMs In-Reply-To: <20041231101006.7f3d6df4.fedora@wir-sind-cool.org> Message-ID: <20050101220723.63525.qmail@web50506.mail.yahoo.com> --- Michael Schwendt wrote: > Well, consider the possibility that I used the > $(foo) command > substitution notation deliberately. That decision is > not due to > personal preference alone, but it's based on the > long-time experience > that it's rather newbie-safe and avoids read errors > and type > errors. Depending on what font [or font size] the > reader of my message > uses, the difference between a single quote > character and the > backquote may not be obvious for everyone. Thanks for the tip. I never really thought about newer users and font sizes affecting the readability of the commands. I guess it's been quite awhile since I've had to think of things like that. Thanks for giving me a new perspective when helping newbies. :) > > Btw, I should have typed > > $ which fedora-buildrpmtree > /usr/bin/fedora-buildrpmtree > $ rpm --query --file $(which fedora-buildrpmtree) > fedora-rpmdevtools-0.2.0-1 > > for increased readability and to save even less > space. ;) You're right though, that really does seem like it would help show a newbie how it works rather than just giving the answer. ===== Kevin C. McConnell --RHCE # 805299480800193 since July 2, 1999-- Freedom in software, now freedom in life. http://www.freestateproject.org/ __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 From meetkaustubhghosh at vsnl.net Sun Jan 2 07:09:06 2005 From: meetkaustubhghosh at vsnl.net (Kaustubh Ghosh) Date: Sun, 02 Jan 2005 12:39:06 +0530 Subject: Problems with kernel compilation Message-ID: <41D79E12.1030508@vsnl.net> I was trying to install a custom kernel in RH7.2. I downloaded kernel 3.4.27 from kernel.org , compiled it made 'make bzImage' , then made the appropriate changes to GRUB to boot it (just added a new line to grub.onf , with '/usr/src/linux2.4.27/boot/bzImage' in place of default vmlinuz. It booted OK.Then I added an integer array to stuct inode and struct ext2_inode(my fs is ext2) , again compiled it and tried to boot it.(The compilations were done in the default kernel and certainly not the new one).But now the kernel just does not boot.(compilation was OK).On selecting the new kernel from grub ,the system just reboots.Is this behaviour very expected? How can I remedy the situation?PLease help.Thanks in advance. Kaustubh Ghosh. From symbiont at berlios.de Sun Jan 2 08:08:28 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sun, 2 Jan 2005 16:08:28 +0800 Subject: Tarball Location For Upstream Redhat Message-ID: <200501021608.28872.symbiont@berlios.de> Just curious on this: In most cases, a spec can be defined such that a proper URL can be put in place of "Source:" such that a build system could download the tarball from the upstream source. However, there are a number of source packages in the distribution where Redhat is the upstream provider for that software. Is there currently a location where the source tarball can be downloaded? Or does the source RPM constitute the official release? Maybe this is something a build system should handle: SRPM URLs in the Source: tag. thanks, -- -jeff From shiva at sewingwitch.com Sun Jan 2 09:56:57 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sun, 02 Jan 2005 01:56:57 -0800 Subject: "vanilla" kernel closest to Fedora kernel In-Reply-To: <20050101194843.GB14963@devserv.devel.redhat.com> References: <1104522835.12925.2.camel@rivendell.home.local> <20041231202409.GB12487@rogers.com> <20050101194843.GB14963@devserv.devel.redhat.com> Message-ID: <222772E6BED6ACFEC655D0DD@[10.0.0.4]> --On Saturday, January 01, 2005 2:48 PM -0500 Alan Cox wrote: > There is not a lot of patching in the Fedora kernel. 2.6.10 will run > happily in the FC environment unpatched as the tmpfs selinux patchesare > now in It would be nice if each of the patches in the kernel spec file had a comment explaining what it was for and why it was needed. (Pointers to bugzillas for each would be adequate.) I've been afraid to use vanilla kernels because I didn't know what those patches did and what would break if I didn't have them. From arjanv at redhat.com Sun Jan 2 10:23:02 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 02 Jan 2005 11:23:02 +0100 Subject: "vanilla" kernel closest to Fedora kernel In-Reply-To: <222772E6BED6ACFEC655D0DD@[10.0.0.4]> References: <1104522835.12925.2.camel@rivendell.home.local> <20041231202409.GB12487@rogers.com> <20050101194843.GB14963@devserv.devel.redhat.com> <222772E6BED6ACFEC655D0DD@[10.0.0.4]> Message-ID: <1104661382.4185.7.camel@laptopd505.fenrus.org> On Sun, 2005-01-02 at 01:56 -0800, Kenneth Porter wrote: > --On Saturday, January 01, 2005 2:48 PM -0500 Alan Cox > wrote: > > > There is not a lot of patching in the Fedora kernel. 2.6.10 will run > > happily in the FC environment unpatched as the tmpfs selinux patchesare > > now in > > It would be nice if each of the patches in the kernel spec file had a > comment explaining what it was for and why it was needed. (Pointers to > bugzillas for each would be adequate.) I've been afraid to use vanilla > kernels because I didn't know what those patches did and what would break > if I didn't have them. there is such a comment for each patch. I put them at the place where the patch got applied; I'm not sure where Dave puts them. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From shiva at sewingwitch.com Sun Jan 2 12:38:22 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sun, 02 Jan 2005 04:38:22 -0800 Subject: "vanilla" kernel closest to Fedora kernel In-Reply-To: <1104661382.4185.7.camel@laptopd505.fenrus.org> References: <1104522835.12925.2.camel@rivendell.home.local> <20041231202409.GB12487@rogers.com> <20050101194843.GB14963@devserv.devel.redhat.com> <222772E6BED6ACFEC655D0DD@[10.0.0.4]> <1104661382.4185.7.camel@laptopd505.fenrus.org> Message-ID: <8ED1E2802364A210EE7E15EA@[10.0.0.4]> --On Sunday, January 02, 2005 11:23 AM +0100 Arjan van de Ven wrote: > there is such a comment for each patch. > I put them at the place where the patch got applied; I'm not sure where > Dave puts them. Ah, thanks. I've been using RH since 5.2 and haven't inspected a recent spec file to see this. I'll have to go check it out. From buildsys at redhat.com Sun Jan 2 12:58:09 2005 From: buildsys at redhat.com (Build System) Date: Sun, 2 Jan 2005 07:58:09 -0500 Subject: rawhide report: 20050102 changes Message-ID: <200501021258.j02Cw9A20594@porkchop.devel.redhat.com> Updated Packages: rpmdb-fedora-1:4-0.20050102 --------------------------- system-config-samba-1.2.23-1 ---------------------------- * Sat Jan 01 2005 Nils Philippsen - 1.2.23-1 - totally revamp how parsed smb.conf is handled internally (class SambaSection), among other things to not screw up smb.conf when editing share names (#143291) - don't assume all users selected == "guest ok" - make About/Copyright easily extensible without screwing up translations - admit complicity - remove tab indentation - some more code consolidation - pick up updated translations From hp at redhat.com Sun Jan 2 19:52:35 2005 From: hp at redhat.com (Havoc Pennington) Date: Sun, 02 Jan 2005 14:52:35 -0500 Subject: why doesn't yum cache anything? In-Reply-To: <20050101163109.GL31887@redhat.com> References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <20041231093645.GH31887@redhat.com> <41D545C5.6010305@bppiac.hu> <20041231130459.GI31887@redhat.com> <1104511699.3441.15.camel@cutter> <20050101163109.GL31887@redhat.com> Message-ID: <1104695556.6913.43.camel@localhost.localdomain> On Sat, 2005-01-01 at 11:31 -0500, Daniel Veillard wrote: > We should double-check where time is actually spent. Using (k)cachegrind > is very useful to make such an analysis. I'd recommend starting with sysprof instead - kcachegrind only counts number of instructions, not how long they take, which can often be very misleading about the big picture. If sysprof says that most of the time is in a CPU-bound function, that's when I like to break out kcachegrind to optimize that function. I mention this because kcachegrind sent me down a few wild goose chases until I got out sysprof also ... Havoc From lfarkas at bppiac.hu Sun Jan 2 20:59:58 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Sun, 02 Jan 2005 21:59:58 +0100 Subject: why doesn't yum cache anything? In-Reply-To: References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104511893.3441.19.camel@cutter> Message-ID: <41D860CE.9020306@bppiac.hu> Konstantin Ryabitsev wrote: > On Fri, 31 Dec 2004 11:51:33 -0500, seth vidal wrote: > >>are you using mirrorlists or are you using baseurls? > > > There is a rather annoying side-effect of mirrorlists -- mirrors may > not always be in sync, so quite often I issue "yum list updates" and > see that there are updates, but when I run "yum update" it hits a > different mirror, where these updates are not yet available. As a > side-effect, it has to download and parse primary.xml.gz for updates > each time the mirrors are not in sync, which depending on the > connection and processor can take a significant amount of time. I get > around it by forcing -C (cache-only mode) after initially running yum > to get the repomd.xml, but others may not know about it. > > I don't have any solutions to propose, unfortunately, other than > mirroring an admittedly confusing behavior of apt, which requires > specifically issuing "apt update" to get new repository medatada. > > However, especially in the cases where domain resolution takes forever > (some ISPs, in a vain attempt to combat spamming from zombie clients, > throttle down DNS responses to take 10-15 seconds), non-cache > operations with mirrorlists take quite some time more than -C. just try out a: time yum -C list mtr it has nothing to do with the network and the speed is almost the same! it seems there are two place where yum is very slow: - loading the local metadata (even if using the pickle files) - the dependencie resolution probably it needs to investigate further what is the real reason and how can be solve. if yum be so slow for a long time, there will be someone who create another package using a better/more clever local cache file format and and may be reimplement it in a faster language (may be a better/faster server side metadata format). and even if it has less features more people will use it. currently everyone use yum since most people hate up2date and apt's (rpm -U --force) feature is not sounds good. but that won't take forever... -- Levente "Si vis pacem para bellum!" From mricon at gmail.com Sun Jan 2 22:57:19 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Sun, 2 Jan 2005 17:57:19 -0500 Subject: why doesn't yum cache anything? In-Reply-To: <41D860CE.9020306@bppiac.hu> References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104511893.3441.19.camel@cutter> <41D860CE.9020306@bppiac.hu> Message-ID: On Sun, 02 Jan 2005 21:59:58 +0100, Farkas Levente wrote: > just try out a: > time yum -C list mtr > it has nothing to do with the network and the speed is almost the same! In my experience it isn't, but then again, doing "yum list \*mtr\*" only takes 8 seconds on my laptop. If it takes longer on other machines, considering mine is certainly not the fastest of the bunch, my suspicion is that the slowdown is not dependent on the processor. Memory and network would be my suspects. > it seems there are two place where yum is very slow: > - loading the local metadata (even if using the pickle files) > - the dependencie resolution > probably it needs to investigate further what is the real reason and how > can be solve. if yum be so slow for a long time, there will be someone > who create another package using a better/more clever local cache file > format and and may be reimplement it in a faster language (may be a > better/faster server side metadata format). I'm not sure such a tool can ever be achieved with RPM. The reason Apt-RPM is fast is because it does not involve RPM libs to do anything: as you said yourself, the only time rpm is invoked is during the final system call to "/bin/rpm --force --nodeps". This is inherently unsafe, but if you go the way of using RPM libs for this, things slow down significantly, and this is not in any way the fault of yum, but of the underlying libraries. All yum does, effectively, is pass data to rpmlib and wait for it. If any slowness is to blame on yum, it's XML parsing, which takes a very long time, and even then it's the problem of how C strings become Python strings. With pickling in place things speed up significantly, as all the system has to do is read the (very large) .pickle file into memory and then convert it into python objects. However, even then these objects must be converted into package classes, as it is very tricky to pickle live package objects due to their underlying connection to librpm and the RPM database. XML parsing occurs when you see "MD Read" as the identification string, and it is relatively slow. When you see "updates-released" or somesuch in the identification field, with ###'s moving faster, that's Yum converting simple package metadata classes into live rpm package objects. On my machine, a speed-stepped P4M 1200, loading primary metadata for base, updates-released, and freshrpms takes about 3 seconds, and that's about 3500 packages. If someone can speed this up further, they will be a better person than I am, since I'm to blame for the XML parsing and pickling code. However, like I said, I do not believe this is where we should look for to speed up the performance of the package management system. The slowness is not in yum, it's in the systems it relies on to function. Let me be the one who voices a popular opinion among anyone who has to deal with RPM (beyond simply packaging) -- it's not the best imaginable packaging system out there. In fact, it lacks in many ways. That is the reason why in the past year or two we saw the emergence of two new alternatives to the existing implementation -- the one proposed by Specifix, and now by SmartPM. And, of course, there is Debian with its promising offshoot, the Ubuntu. () Feel free to encourage anyone to come up with a system better than yum that doesn't do things the apt way, i.e. doing everything outside of RPM and then just making a system call to the binary. I believe anyone attempting to re-implement yum will soon run into exactly the same problems as those faced by Seth et al. If someone does come up with an application that functions speedily and covers the same robust set of features that yum provides, then I'm sure Seth will have no problem stepping aside and letting the poor bastard who replaces him to take all the abuse. In fact, as someone for whom Seth is a direct supervisor, I'll downright encourage that development. :) However, I believe that until RPM is replaced with an able enough alternative, things will not dramatically improve, however much you desire them to, and however many times you rewrite yum. Feel free to prove me incorrect. Regards, -- Konstantin Ryabitsev Zlotniks, INC From strange at nsk.no-ip.org Sun Jan 2 23:27:50 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Sun, 2 Jan 2005 23:27:50 +0000 Subject: why doesn't yum cache anything? In-Reply-To: References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104511893.3441.19.camel@cutter> <41D860CE.9020306@bppiac.hu> Message-ID: <20050102232750.GA6021@nsk.no-ip.org> On Sun, Jan 02, 2005 at 05:57:19PM -0500, Konstantin Ryabitsev wrote: > On Sun, 02 Jan 2005 21:59:58 +0100, Farkas Levente wrote: > > just try out a: > > time yum -C list mtr > > it has nothing to do with the network and the speed is almost the same! > > In my experience it isn't, but then again, doing "yum list \*mtr\*" > only takes 8 seconds on my laptop. If it takes longer on other > machines, considering mine is certainly not the fastest of the bunch, > my suspicion is that the slowdown is not dependent on the processor. > Memory and network would be my suspects. > > > it seems there are two place where yum is very slow: > > - loading the local metadata (even if using the pickle files) > > - the dependencie resolution > > probably it needs to investigate further what is the real reason and how > > can be solve. if yum be so slow for a long time, there will be someone > > who create another package using a better/more clever local cache file > > format and and may be reimplement it in a faster language (may be a > > better/faster server side metadata format). > > I'm not sure such a tool can ever be achieved with RPM. The reason > Apt-RPM is fast is because it does not involve RPM libs to do > anything: as you said yourself, the only time rpm is invoked is during > the final system call to "/bin/rpm --force --nodeps". This is > inherently unsafe, but if you go the way of using RPM libs for this, > things slow down significantly, and this is not in any way the fault > of yum, but of the underlying libraries. Not for quite some time: https://moin.conectiva.com.br/AptRpm Version 0.5.15cnc3 (circa Nov 2003) Integrated and extended patch by Panu Matilainen adding support for internal committing of changes using the RPM API! Now changes will be committed to the system in a single transaction. Using the ancient scheme is still possible by setting RPM::PM to external. Regards, Luciano Rocha From jwz at jwz.org Sun Jan 2 23:42:16 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Sun, 02 Jan 2005 15:42:16 -0800 Subject: why doesn't yum cache anything? References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104511893.3441.19.camel@cutter> <41D860CE.9020306@bppiac.hu> Message-ID: <41D886D8.63057629@jwz.org> Three points: It seems that using "-C" speeds things up *a lot* on all of my systems, which are all using "mirrorlist" (as is the default in FC3.) From discussion here, I gather that that means they're going to hit the net each time, and get a randomly-different server each time. I'd suggest that the current mirrorlist behavior should be changed to be more stateful: yum should remember the last mirror that it used, and just stick with that for a while. In other words, always behave as if -C was specified unless: A) it's been more than N hours; or B) an error occurred trying to download something from the currently-selected mirror. Second: everyone keeps talking about dependency resolution and how that's bound to be slow, but as far as I can tell, there's no reason to resolve dependencies at all when I'm just doing "list". So either there's dependency resolution going on when there shouldn't be, or it's not relevant at all. Third: Konstantin Ryabitsev wrote: > > I do not believe this is where we should look for to speed up the > performance of the package management system. The slowness is not in > yum, it's in the systems it relies on to function. I think the theory that "yum is fine, it's the RPM libs that are slow" is pretty well debunked by this: % time rpm -qa '*mtr*' >/dev/null 3.576u 0.121s 0:05.93 62.2% 0+0k 0+0io 0pf+0w % time yum -C list '*mtr*' >/dev/null 5.474u 0.539s 0:16.41 36.5% 0+0k 0+0io 8pf+0w I don't think "three times longer" is exactly negligible. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From mricon at gmail.com Sun Jan 2 23:48:58 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Sun, 2 Jan 2005 18:48:58 -0500 Subject: why doesn't yum cache anything? In-Reply-To: <41D886D8.63057629@jwz.org> References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104511893.3441.19.camel@cutter> <41D860CE.9020306@bppiac.hu> <41D886D8.63057629@jwz.org> Message-ID: On Sun, 02 Jan 2005 15:42:16 -0800, Jamie Zawinski wrote: > I think the theory that "yum is fine, it's the RPM libs that are slow" > is pretty well debunked by this: > > % time rpm -qa '*mtr*' >/dev/null > 3.576u 0.121s 0:05.93 62.2% 0+0k 0+0io 0pf+0w > % time yum -C list '*mtr*' >/dev/null > 5.474u 0.539s 0:16.41 36.5% 0+0k 0+0io 8pf+0w No it isn't. When you are doing "rpm -qa" you are only querying the database of installed packages. When doing "yum list" you are querying installed, AND available packages, for which the metadata must be parsed and loaded. That's a significant difference, if only because the number of packages goes up from a few hundred to several thousands. Regards, -- Konstantin Ryabitsev Zlotniks, INC From mricon at gmail.com Mon Jan 3 00:02:56 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Sun, 2 Jan 2005 19:02:56 -0500 Subject: why doesn't yum cache anything? In-Reply-To: References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104511893.3441.19.camel@cutter> <41D860CE.9020306@bppiac.hu> <41D886D8.63057629@jwz.org> Message-ID: On Sun, 2 Jan 2005 18:48:58 -0500, Konstantin Ryabitsev wrote: > No it isn't. When you are doing "rpm -qa" you are only querying the > database of installed packages. When doing "yum list" you are querying > installed, AND available packages, for which the metadata must be > parsed and loaded. That's a significant difference, if only because > the number of packages goes up from a few hundred to several > thousands. In fact: icon at protee:[~]$ rpm -qa | wc -l 645 so, 645 packages installed icon at protee:[~]$ time rpm -qa '*mtr*' mtr-2:0.54-10.i386 real 0m5.006s user 0m4.760s sys 0m0.135s so, 5 seconds icon at protee:[~]$ time yum -C list '*mtr*' Setting up Repo: updates-released Setting up Repo: base Setting up Repo: freshrpms Reading repository metadata in from local files updates-re: ################################################## 407/407 base : ################################################## 2622/2622 freshrpms : ################################################## 456/456 Excluding Packages from Fedora Core 3 - i386 - Released Updates Finished Installed Packages mtr.i386 2:0.54-10 installed Available Packages mtr-gtk.i386 2:0.54-10 base real 0m8.215s user 0m5.585s sys 0m0.435s so, 3485 packages in 8.2 seconds. By golly, yum is, actually *faster* then rpm -qa, taking less than twice as long for 5 times as many packages. Regards, -- Konstantin Ryabitsev Zlotniks, INC From jwz at jwz.org Mon Jan 3 00:09:50 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Sun, 02 Jan 2005 16:09:50 -0800 Subject: why doesn't yum cache anything? References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104511893.3441.19.camel@cutter> <41D860CE.9020306@bppiac.hu> <41D886D8.63057629@jwz.org> Message-ID: <41D88D4E.6475929F@jwz.org> Konstantin Ryabitsev wrote: > >> % time rpm -qa '*mtr*' >/dev/null >> 3.576u 0.121s 0:05.93 62.2% 0+0k 0+0io 0pf+0w >> % time yum -C list '*mtr*' >/dev/null >> 5.474u 0.539s 0:16.41 36.5% 0+0k 0+0io 8pf+0w > > No it isn't. When you are doing "rpm -qa" you are only querying the > database of installed packages. When doing "yum list" you are querying > installed, AND available packages, Ok, fair enough, those speeds are almost exactly proportional: rpm -qa | wc -l => 654 yum -C list '*' | wc -l => 1798 (5.93 / 16.41) / (654.0 / 1798.0) => 0.9934 Is there any kind of reasonable GUI for yum yet? A lot of these problems wouldn't matter if the "session" was longer, and it was only doing all of this parsing once at startup, letting you do multiple queries and installs without it needing to start over from scratch each time. I thought Ximian Red Carpet was fantastic and I really miss it. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From mattdm at mattdm.org Mon Jan 3 00:24:54 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 2 Jan 2005 19:24:54 -0500 Subject: why doesn't yum cache anything? In-Reply-To: <41D88D4E.6475929F@jwz.org> References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104511893.3441.19.camel@cutter> <41D860CE.9020306@bppiac.hu> <41D886D8.63057629@jwz.org> <41D88D4E.6475929F@jwz.org> Message-ID: <20050103002454.GA31031@jadzia.bu.edu> On Sun, Jan 02, 2005 at 04:09:50PM -0800, Jamie Zawinski wrote: > Is there any kind of reasonable GUI for yum yet? A lot of these Not yet. But see this post from a couple of weeks ago: where RH developer Paul Nasrat talks about extending system-config-packages to work with yum. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From stevelist at silverorange.com Mon Jan 3 00:25:21 2005 From: stevelist at silverorange.com (Steven Garrity) Date: Sun, 02 Jan 2005 20:25:21 -0400 Subject: why doesn't yum cache anything? In-Reply-To: <41D88D4E.6475929F@jwz.org> References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104511893.3441.19.camel@cutter> <41D860CE.9020306@bppiac.hu> <41D886D8.63057629@jwz.org> <41D88D4E.6475929F@jwz.org> Message-ID: <41D890F1.3030707@silverorange.com> Jamie Zawinski wrote: > Is there any kind of reasonable GUI for yum yet? A lot of these > problems wouldn't matter if the "session" was longer, and it was only > doing all of this parsing once at startup, letting you do multiple > queries and installs without it needing to start over from scratch each > time. I thought Ximian Red Carpet was fantastic and I really miss it. The fedoranews.org server where it is hosted is down as I write this, but there is GYUM - I think it's new and I haven't tried it yet, so I can't vouch it: http://www.fedoraforum.org/forum/showthread.php?t=29014 Steven Garrity From n3npq at nc.rr.com Mon Jan 3 01:20:10 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sun, 02 Jan 2005 20:20:10 -0500 Subject: why doesn't yum cache anything? In-Reply-To: References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104511893.3441.19.camel@cutter> <41D860CE.9020306@bppiac.hu> <41D886D8.63057629@jwz.org> Message-ID: <41D89DCA.8050008@nc.rr.com> Konstantin Ryabitsev wrote: > >so, 3485 packages in 8.2 seconds. By golly, yum is, actually *faster* >then rpm -qa, taking less than twice as long for 5 times as many >packages. > yum is not faster than rpm -qa. 73 de Jeff From byte at aeon.com.my Mon Jan 3 03:09:28 2005 From: byte at aeon.com.my (Colin Charles) Date: Mon, 03 Jan 2005 11:09:28 +0800 Subject: Kernel 2.6.10 Can't Open Initial Console on FC3 In-Reply-To: <3k77vr$fs05t3@mxip08a.cluster1.charter.net> References: <3k77vr$fs05t3@mxip08a.cluster1.charter.net> Message-ID: <1104721768.32006.180.camel@localhost.localdomain> On Sat, 2005-01-01 at 10:05 -0600, Joseph D. Wagner wrote: > They tell me there's a way to make it work without initrd, but it's > ugly, messy, and not recommended: > > http://fedora.redhat.com/docs/udev/ > > I haven't yet tested to see if it works with initrd and without > support for hotplug devices, but from the documentation I've read my > money is on no. It does work. For quite a while on the PPC tree, we ended up doing some manual MAKEDEVs to make it work. IIRC, booting with selinux=0 might have been required as well (this was in the pre-FC-3 rawhide days) -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From g.hollestelle at gmail.com Mon Jan 3 08:40:49 2005 From: g.hollestelle at gmail.com (Gijs Hollestelle) Date: Mon, 3 Jan 2005 09:40:49 +0100 Subject: why doesn't yum cache anything? In-Reply-To: <41D886D8.63057629@jwz.org> References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104511893.3441.19.camel@cutter> <41D860CE.9020306@bppiac.hu> <41D886D8.63057629@jwz.org> Message-ID: <95da2d2905010300407e8ca9fe@mail.gmail.com> On Sun, 02 Jan 2005 15:42:16 -0800, Jamie Zawinski wrote: > Second: everyone keeps talking about dependency resolution and how > that's bound to be slow, but as far as I can tell, there's no reason to > resolve dependencies at all when I'm just doing "list". So either > there's dependency resolution going on when there shouldn't be, or it's > not relevant at all. You raise a very valid point here. Even if there is no dependency resolving required yum parses all package headers (file lists, requirements, obsoletes, etc) and builds the dependecny resolving indexes which is not necessary at all. I did a quick test yesterday, by changing the importFromDict, which translates the loaded pickle cache into the internat data structures used by yum, function so that it only reads nevra (name and version information) and optionaly obsoletes information (in case a list obsoletes is performed). These changes speeded up things considerably. >From about 6 seconds to 4 seconds. So it might be worth implementing a listonly flag to importFromDict which is set when the user only requested a list action. This won't speed up actual upgrades or installs, but will make things that users expect to be fast (i.e. listing available packages or updates) faster. Kind regards, Gijs Hollestelle From kyrre at solution-forge.net Mon Jan 3 12:21:52 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 03 Jan 2005 13:21:52 +0100 Subject: why doesn't yum cache anything? In-Reply-To: <41D890F1.3030707@silverorange.com> References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104511893.3441.19.camel@cutter> <41D860CE.9020306@bppiac.hu> <41D886D8.63057629@jwz.org> <41D88D4E.6475929F@jwz.org> <41D890F1.3030707@silverorange.com> Message-ID: <1104744410.2689.1.camel@kyrre> man, 03.01.2005 kl. 01.25 skrev Steven Garrity: > Jamie Zawinski wrote: > > Is there any kind of reasonable GUI for yum yet? A lot of these > > problems wouldn't matter if the "session" was longer, and it was only > > doing all of this parsing once at startup, letting you do multiple > > queries and installs without it needing to start over from scratch each > > time. I thought Ximian Red Carpet was fantastic and I really miss it. > > The fedoranews.org server where it is hosted is down as I write this, > but there is GYUM - I think it's new and I haven't tried it yet, so I > can't vouch it: > > http://www.fedoraforum.org/forum/showthread.php?t=29014 > > Steven Garrity It is promising, but needs some work (and some of the gui touch of synaptic). Main problem is that it appears to hang while yum is loading... (which can take a while), and lacking of nice sorting functions seen in synaptic. From buildsys at redhat.com Mon Jan 3 13:05:08 2005 From: buildsys at redhat.com (Build System) Date: Mon, 3 Jan 2005 08:05:08 -0500 Subject: rawhide report: 20050103 changes Message-ID: <200501031305.j03D58j09638@porkchop.devel.redhat.com> Updated Packages: file-4.12-2 ----------- * Mon Jan 03 2005 Radek Vokal - 4.12-2 - fixed crashes in threaded environment (#143871) jwhois-3.2.2-9 -------------- * Sun Jan 02 2005 Miloslav Trmac - 3.2.2-9 - Add IPv6 address ranges, fix .pro, 223.0.0.0/8 (#143682, patch by Robert Scheck) kernel-2.6.10-1.1063_FC4 ------------------------ * Sun Jan 02 2005 Dave Jones - Rebase to 2.6.10-bk5 * Sat Jan 01 2005 Dave Jones - Fix probing of vesafb. (#125890) - Reenable EDD. - Don't assume existance of ~/.gnupg (#142201) * Fri Dec 31 2004 Dave Jones - Rebase to 2.6.10-bk4 rpmdb-fedora-1:4-0.20050103 --------------------------- system-config-samba-1.2.24-1 ---------------------------- * Sun Jan 02 2005 Nils Philippsen - 1.2.24-1 - revamp BasicPreferencesWin.readFile() (#143951) - remove stray debugging statement - pick up new strings to be translated From alan at balclutha.org Mon Jan 3 14:01:21 2005 From: alan at balclutha.org (Alan Milligan) Date: Tue, 04 Jan 2005 01:01:21 +1100 Subject: perl INSTALLDIRS=vendor Message-ID: <41D95031.2060903@balclutha.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 People, I'm having a few problems source compiling a number of perl modules. I don't really like this vendor concept, whats wrong with site_perl?? But the problem I face is that the %files is inconsistent. For example, in perl-HTML-Parser, the line is as follows: %dir %{_libdir}/perl5/%(perl -MConfig -le 'print "$Config{version}/$Config{archname}"')/HTML but of course the files have been placed in vendor_perl/5.8.5. The correct line in this case is: %dir %(perl -MConfig -le 'print "$Config{vendorarch}"')/HTML There are a number of other modules similarly broken. Comments please. Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB2VAwCfroLk4EZpkRAvwbAKCTqyw6VfkfKIfTnYJOXRNjycUnswCfXi1c AsQmAB0RKyvZTNBf2I+hGpA= =Qw+6 -----END PGP SIGNATURE----- From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jan 3 15:29:48 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 3 Jan 2005 16:29:48 +0100 Subject: Behavior differences between anaconda and "real" boot? (sata_nv problem) Message-ID: <20050103162948.505bb6c3@python2> Hi, I own a neat little AMD64 Shuttle SN85G4 (V1) which works great with FC3, so I recommended buying the same to my dad. He bought the same, but it's V3 now, which apparently features a newer nForce3 250 chipset, and possibly some other minor changes. I only had an i386 FC3 install DVD handy when he got it, and with only a modem connection, it really was my only option, so I installed that... things went fine (except the Radeon 9200 through the DVI output, the display went all black all the time after a few seconds, VGA works fine though). My problem here is that it installed flawlessly on the Serial-ATA hard drive attached to that nForce3 250 chipset (sata_nv module), but the machine was never able to boot from the installed system. I tried all that I could and came to these conclusions : - It's not an IRQ problem (it shares IRQ11 with the firewire, but also does at install time and I tried with another IRQ and firewire disabled, same thing). - It's not an ACPI or APIC issue (or at least isn't fixed by disabling them). I actually really don't know what the problem can be. I tried with the latest updated kernel, same thing. I also tried creating an initrd which preloads all the same modules anaconda loads before loading sata_nv (usb, firewire, scsi, forcedeth) in case the reverse engineered eth driver did something weird that helped, or in case the delay in loading them gave enough time to the drive to spin up or something, but no go. Booting the install CD in rescue more _always_ works at getting the Serial-ATA drive detected, whereas booting the installed system _never_ does (grub is there, and the initrd is loaded fine). The error on google only shows LKML reports about problems with sata_via back in the 2.4 days. The exact error is this : ata1 is slow to respond, please be patient ata1 failed to respond (30 secs) All the kernel messages above (about detecting the chipset and both ata1 and ata2) are identical for the kernel used in anaconda and the one installed. The kernel version, as well as the libata and sata_nv versions reported are identical too... So I was wondering what the issue could be. Some anaconda magic that the installed system doesn't perform? Having an i686 kernel on that x86-64 machine and anaconda having yet another one? For now I've put a good old parallel ATA drive, but still can't access the Serial-ATA drive from that installed and booting system :-( Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.9-1.681_FC3.r300 Load : 0.13 0.21 0.45 From lfarkas at bppiac.hu Mon Jan 3 15:43:00 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Mon, 03 Jan 2005 16:43:00 +0100 Subject: why doesn't yum cache anything? In-Reply-To: References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104511893.3441.19.camel@cutter> <41D860CE.9020306@bppiac.hu> Message-ID: <41D96804.6050506@bppiac.hu> Konstantin Ryabitsev wrote: > On Sun, 02 Jan 2005 21:59:58 +0100, Farkas Levente wrote: > >>just try out a: >>time yum -C list mtr >>it has nothing to do with the network and the speed is almost the same! > > > In my experience it isn't, but then again, doing "yum list \*mtr\*" > only takes 8 seconds on my laptop. If it takes longer on other > machines, considering mine is certainly not the fastest of the bunch, > my suspicion is that the slowdown is not dependent on the processor. > Memory and network would be my suspects. > > >>it seems there are two place where yum is very slow: >>- loading the local metadata (even if using the pickle files) >>- the dependencie resolution >>probably it needs to investigate further what is the real reason and how >>can be solve. if yum be so slow for a long time, there will be someone >>who create another package using a better/more clever local cache file >>format and and may be reimplement it in a faster language (may be a >>better/faster server side metadata format). [skip] > Feel free to encourage anyone to come up with a system better than yum > that doesn't do things the apt way, i.e. doing everything outside of > RPM and then just making a system call to the binary. I believe anyone > attempting to re-implement yum will soon run into exactly the same > problems as those faced by Seth et al. If someone does come up with an > application that functions speedily and covers the same robust set of > features that yum provides, then I'm sure Seth will have no problem > stepping aside and letting the poor bastard who replaces him to take > all the abuse. In fact, as someone for whom Seth is a direct > supervisor, I'll downright encourage that development. :) > > However, I believe that until RPM is replaced with an able enough > alternative, things will not dramatically improve, however much you > desire them to, and however many times you rewrite yum. Feel free to > prove me incorrect. first of all i do NOT like to blame anyone especially not seth since i like yum as the only usable tool. but that doesn't mean i can't tell my point of view and my critics. in short: - yum is slow (rather slow) and it can (and i hope will) be faster! imho it's better to not show any kind of exmaples, but - even if nothing changed on the system (add/remove) like in case of list it takes a long time to get the result. - even when only package name, version, release, epoc information will be enough (which is the most usualy case!!!! ie. yum install/erase/update/check-update/list) it load, parse and build python's object from all data which is about 95-99% is waste of resources (time and memory). this is just my estimation based on that the rpm filename is longer than the EVR string and only the pickle file is loaded: ----------------------------------- # ls /mnt/download/mirror/fedora/3/i386/os/Fedora/RPMS/|wc -c 48537 # ls -l /var/cache/yum/os/ total 6252 drwxr-xr-x 2 root root 4096 Dec 20 18:48 headers/ drwxr-xr-x 2 root root 4096 Nov 12 10:06 packages/ -rw-r--r-- 1 root root 816171 Nov 4 00:22 primary.xml.gz -rw-r--r-- 1 root root 5532228 Nov 12 10:06 primary.xml.gz.ce7bdfd5a6066a4f18c498b693faa16597a0733c.pickle -rw-r--r-- 1 root root 1140 Nov 4 00:22 repomd.xml ----------------------------------- and to show a much slower case when someone use more repos: --------------------------------------------- # cat /proc/cpuinfo /proc/meminfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 2.20GHz stepping : 4 cpu MHz : 2222.143 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips : 4374.52 MemTotal: 1035124 kB MemFree: 108180 kB Buffers: 98368 kB Cached: 589540 kB SwapCached: 12 kB Active: 687336 kB Inactive: 185700 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 1035124 kB LowFree: 108180 kB SwapTotal: 2008084 kB SwapFree: 2006912 kB Dirty: 63892 kB Writeback: 0 kB Mapped: 430524 kB Slab: 26996 kB Committed_AS: 831304 kB PageTables: 6096 kB VmallocTotal: 3088376 kB VmallocUsed: 3672 kB VmallocChunk: 3084504 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 4096 kB # time yum -C list mtr Setting up Repo: dag Setting up Repo: freshrpms Setting up Repo: jpackage16-generic Setting up Repo: jpackage16-fc3 Setting up Repo: updates Setting up Repo: Newrpms Setting up Repo: addons Setting up Repo: os Setting up Repo: pre-extras Reading repository metadata in from local files dag : ################################################## 1531/1531 freshrpms : ################################################## 456/456 jpackage16: ################################################## 1277/1277 jpackage16: ################################################## 19/19 updates : ################################################## 407/407 Newrpms : ################################################## 374/374 addons : ################################################## 10/10 os : ################################################## 2622/2622 pre-extras: ################################################## 630/630 Excluding Packages in global exclude list Finished Installed Packages mtr.i386 2:0.65-1.1.fc3.rf installed real 0m39.976s user 0m11.271s sys 0m1.030s --------------------------------------------- -- Levente "Si vis pacem para bellum!" From fedora-devel at camperquake.de Mon Jan 3 15:43:31 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Mon, 3 Jan 2005 16:43:31 +0100 Subject: Behavior differences between anaconda and "real" boot? (sata_nv problem) In-Reply-To: <20050103162948.505bb6c3@python2>; from thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net on Mon, Jan 03, 2005 at 04:29:48PM +0100 References: <20050103162948.505bb6c3@python2> Message-ID: <20050103164331.B10725@ryoko.camperquake.de> On Mon, Jan 03, 2005 at 04:29:48PM +0100, Matthias Saou wrote: > So I was wondering what the issue could be. Some anaconda magic that the > installed system doesn't perform? Having an i686 kernel on that x86-64 > machine and anaconda having yet another one? I seem to recall that anaconda boots an i586 kernel. From cmadams at hiwaay.net Mon Jan 3 15:44:30 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 3 Jan 2005 09:44:30 -0600 Subject: Behavior differences between anaconda and "real" boot? (sata_nv problem) In-Reply-To: <20050103164331.B10725@ryoko.camperquake.de> References: <20050103162948.505bb6c3@python2> <20050103164331.B10725@ryoko.camperquake.de> Message-ID: <20050103154430.GC1380086@hiwaay.net> Once upon a time, Ralf Ertzinger said: > On Mon, Jan 03, 2005 at 04:29:48PM +0100, Matthias Saou wrote: > > So I was wondering what the issue could be. Some anaconda magic that the > > installed system doesn't perform? Having an i686 kernel on that x86-64 > > machine and anaconda having yet another one? > > I seem to recall that anaconda boots an i586 kernel. Not for FC3; I can't boot the installer on an AMD K6-III (sigh). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From shahms at shahms.com Mon Jan 3 15:48:44 2005 From: shahms at shahms.com (Shahms King) Date: Mon, 03 Jan 2005 07:48:44 -0800 Subject: Behavior differences between anaconda and "real" boot? (sata_nv problem) In-Reply-To: <20050103162948.505bb6c3@python2> References: <20050103162948.505bb6c3@python2> Message-ID: <1104767324.20319.15.camel@shahms.mesd.k12.or.us> It sounds like your problem is *nearly* identical to mine on the Shuttle SN95G5, except you can actually get the installer to boot: https://bugzilla.redhat.com/beta/show_bug.cgi?id=135302 There is also another SATA-related installer bug that might be related. One of the comments in #135302 points to an OSDL kernel bugzilla entry with more information. You wouldn't happen to be using a Seagate SATA drive would you? The kernel bugzilla entry has a small workaround (that has been included in 2.6.10) that fixes the problem for me. I ended up having to do a two-drive monte from a spare PATA drive to get it installed: 1. Install on PATA hard-drive 2. Compile src.rpm with patched sata_nv.c 3. Create a boot disk (this *should* have been step 3, but wasn't) 4. Reboot with new kernel 5. Migrate data from PATA hard-drive (LVM2 makes this much easier) 6. Run grub-install on the SATA hard-drive and hope it gets everything correct. 7. Remove the old hard-drive. 8. Don't update to anything less than a 2.6.10 kernel. Note that you might want to reboot between step 5 and 6 to make sure the data migrated correctly as well as between 6 and 7. I know I had to do some extra work to get grub-install working correctly (this was why making the boot disk should have been step 3). Since you don't have any problem getting it installed, it doesn't sound like you'll have to go through all of those machinations, but I hope this helps. -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mlauterbach at mail.wtamu.edu Mon Jan 3 15:51:18 2005 From: mlauterbach at mail.wtamu.edu (Matthew E. Lauterbach) Date: Mon, 3 Jan 2005 09:51:18 -0600 Subject: Behavior differences between anaconda and "real" boot? (sata_nv problem) In-Reply-To: <20050103162948.505bb6c3@python2> Message-ID: <20050103155118.4839A3E6334@mail.wtamu.edu> On Monday, January 03, 2005 9:30 AM, Matthias Saou wrote: > Hi, > > I own a neat little AMD64 Shuttle SN85G4 (V1) which works > great with FC3, > so I recommended buying the same to my dad. He bought the > same, but it's V3 > now, which apparently features a newer nForce3 250 chipset, > and possibly > some other minor changes. > I only had an i386 FC3 install DVD handy when he got it, and > with only a > modem connection, it really was my only option, so I installed that... > things went fine (except the Radeon 9200 through the DVI output, the > display went all black all the time after a few seconds, VGA > works fine > though). > My problem here is that it installed flawlessly on the Serial-ATA hard > drive attached to that nForce3 250 chipset (sata_nv module), but the > machine was never able to boot from the installed system. > Sounds a lot like: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140367 Is the serial ata drive by any chance a Seagate? If so, you may want to try this kernel: http://www.wtamu.edu/~mlauterbach/kernel-2.6.9-1.681_FC3_SATA.root.i686.rpm All that is changed in this kernel is a line or two commented out. I have yet to get around to making and verifying that this will fix the x86_64 version of FC3 yet. x86_64 and i386 versions of FC3 both behaved exactly the same for me. Matthew E. Lauterbach From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Jan 3 16:25:23 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 3 Jan 2005 17:25:23 +0100 Subject: Behavior differences between anaconda and "real" boot? (sata_nv problem) In-Reply-To: <1104767324.20319.15.camel@shahms.mesd.k12.or.us> References: <20050103162948.505bb6c3@python2> <1104767324.20319.15.camel@shahms.mesd.k12.or.us> Message-ID: <20050103172523.7505ba40@python2> Shahms King wrote : > It sounds like your problem is *nearly* identical to mine on the Shuttle > SN95G5, except you can actually get the installer to boot: > > https://bugzilla.redhat.com/beta/show_bug.cgi?id=135302 > > There is also another SATA-related installer bug that might be related. > One of the comments in #135302 points to an OSDL kernel bugzilla entry > with more information. OK... bugzilla.redhat.com was down when I was struggling with all this a few days ago, so I hadn't found all that info since google doesn't seem to index all of it. Nor does it seem to have indexed the OSDL bug for that matter. > You wouldn't happen to be using a Seagate SATA drive would you? Nope, Maxtor DiamondMax 10 (IIRC, the "10" I'm sure of) 200GB. > The kernel bugzilla entry has a small workaround (that has been included > in 2.6.10) that fixes the problem for me. [...] Thanks for the pointer and tip. Unfortunately, downloading a kernel source rpm simply wasn't an option, and I only had the install DVD (which doesn't contain the .src.rpms anymore), so I would have been stuck anyway without a single kernel to recompile. What _really_ puzzles me is that the FC3 install works fine for me. Booting the DVD in rescue mode too. But no installed system is able to see the SATA drive again... Thanks for all the pointers! Now I just need to figure out how to explain all this to a non-expert over the phone... *sigh* Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.9-1.681_FC3.r300 Load : 0.41 0.23 0.34 From shahms at shahms.com Mon Jan 3 16:30:54 2005 From: shahms at shahms.com (Shahms King) Date: Mon, 03 Jan 2005 08:30:54 -0800 Subject: Behavior differences between anaconda and "real" boot? (sata_nv problem) In-Reply-To: <20050103172523.7505ba40@python2> References: <20050103162948.505bb6c3@python2> <1104767324.20319.15.camel@shahms.mesd.k12.or.us> <20050103172523.7505ba40@python2> Message-ID: <1104769854.20319.19.camel@shahms.mesd.k12.or.us> On Mon, 2005-01-03 at 17:25 +0100, Matthias Saou wrote: > Thanks for the pointer and tip. Unfortunately, downloading a kernel source > rpm simply wasn't an option, and I only had the install DVD (which doesn't > contain the .src.rpms anymore), so I would have been stuck anyway without a > single kernel to recompile. > > What _really_ puzzles me is that the FC3 install works fine for me. Booting > the DVD in rescue mode too. But no installed system is able to see the SATA > drive again... > > Thanks for all the pointers! Now I just need to figure out how to explain > all this to a non-expert over the phone... *sigh* It looks like Rawhide has a 2.6.10 kernel in it finally, so if you can explain updating to a Rawhide kernel over the phone you might be set. It should be as simple as: # yum --enablerepo=development install kernel -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ndbecker2 at verizon.net Mon Jan 3 16:43:06 2005 From: ndbecker2 at verizon.net (Neal D. Becker) Date: Mon, 03 Jan 2005 11:43:06 -0500 Subject: teTeX 3.0 release soon Message-ID: Just a note that teTeX 3.0 will be out soon. http://freshmeat.net/projects/tetex/?branch_id=48942&release_id=183471 From tibbs at math.uh.edu Mon Jan 3 17:14:52 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Mon, 03 Jan 2005 11:14:52 -0600 Subject: ATI RS350 chipset Message-ID: I just put together a system with a Gigabyte GA-8TRS350MT board; this has what it calls the ATI RS350 chipset. It's a pretty nice board and (so I thought) not particularly new, but it seems to be a bit ahead of current kernel support. I figured I'd post a note in case anything is searching Here's an lspci: 00:00.0 Host bridge: ATI Technologies Inc: Unknown device 7833 00:01.0 PCI bridge: ATI Technologies Inc: Unknown device 7838 00:13.0 USB Controller: ATI Technologies Inc: Unknown device 4367 (rev 01) 00:13.1 USB Controller: ATI Technologies Inc: Unknown device 4368 (rev 01) 00:13.2 USB Controller: ATI Technologies Inc: Unknown device 4365 (rev 01) 00:14.0 SMBus: ATI Technologies Inc: Unknown device 4363 (rev 03) 00:14.1 IDE interface: ATI Technologies Inc: Unknown device 4369 (rev 01) 00:14.2 IDE interface: ATI Technologies Inc: Unknown device 436e (rev 01) 00:14.3 ISA bridge: ATI Technologies Inc: Unknown device 436c (rev 01) 00:14.4 PCI bridge: ATI Technologies Inc: Unknown device 4362 (rev 01) 00:14.5 Multimedia audio controller: ATI Technologies Inc: Unknown device 4361 (rev 03) 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon 9100 PRO IGP 02:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) I checked the curent PCI ID list on sourceforge and these aren't listed; I'd add them myself but I have no idea what to call them. FC2 (which I currently have rolled out on 200 machines) didn't install it all. FC3 did install, but the IDE was dog slow and required a little kernel patch for chipset recognition. kernel-2.6.10-1.1056_FC4 added support for that. (This is bug 142647.) Graphics seem to work under FC3 well enough. I haven't tried 3D stuff yet. I can switch to text consoles but when I do a shutdown (with X running) the screen goes completely dark until the machine reboots. USB support works for mice but when I use a plain USB2 memory thingy (any of several models I have laying around) things don't work so well. Upon inserting the device (with this morning's kernel-2.6.10-1.1063_FC4) I see: usb 3-3: new low speed USB device using ohci_hcd and address 2 ohci_hcd 0000:00:13.1: Unlink after no-IRQ? Different ACPI or APIC settings may help. which is a bit more helpful than earlier kernels. lsusb at this point hangs. Booting with noapic doesn't help; then I get this: usb 3-3: new full speed USB device using ohci_hcd and address 2 usb 3-3: device descriptor read/64, error -110 usb 3-3: device descriptor read/64, error -110 usb 3-3: new full speed USB device using ohci_hcd and address 3 usb 3-3: device descriptor read/64, error -110 usb 3-3: device descriptor read/64, error -110 usb 3-4: new low speed USB device using ohci_hcd and address 4 and lsusb still hangs. acpi=off gives the same. This is not yet in bugzilla; I'll keep experimenting and file a complete bug once I've trolled through the BIOS settings. I haven't tried sound yet. If anyone has any suggestions, I'd sure appreciate them. - J< From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 3 18:02:58 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 03 Jan 2005 19:02:58 +0100 Subject: Kernel 2.6.10 Can't Open Initial Console on FC3 In-Reply-To: <3k789p$kn0fji@mxip11a.cluster1.charter.net> (Joseph D. Wagner's message of "Fri, 31 Dec 2004 01:11:13 -0600") References: <3k789p$kn0fji@mxip11a.cluster1.charter.net> Message-ID: <87is6e9yr1.fsf@kosh.ultra.csn.tu-chemnitz.de> technojoecoolusa at charter.net ("Joseph D. Wagner") writes: > The newly compiled kernel gets through everything OK including mounting > the root file system as read-only EXT3. However, it freezes on the > very last line, it should not freeze; just wait a little bit... > which says: > > Warning: unable to open an initial console /dev is empty without udev. When you do not need initrd, execute: | # mount --bind / /mnt | # cp -a /dev/console /dev/null /mnt/dev/ | # mkdir /mnt/dev/pts Enrico From alan at balclutha.org Mon Jan 3 18:39:08 2005 From: alan at balclutha.org (Alan Milligan) Date: Tue, 04 Jan 2005 05:39:08 +1100 Subject: rpmbuild python bindings Message-ID: <41D9914C.20808@balclutha.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Do any python bindings exist for rpmbuild?? Specifically, I'd like to be able to detect broken build dependencies and recursively build and install these as part of an automated python/Makefile script. I could of course just scrape the output :( but it would be excellent if there were wrappers for rpmbuild. Ideally, these would allow one to parse the spec file into a python structure and to explicitly call %prep, %build, %install etc etc Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFB2ZFLCfroLk4EZpkRAvNrAJ9WqvkRPKRLaDDQQpASIywzA/q/IwCbBvkE zly4dBKN2cJEum4w0d/cQUk= =/U1c -----END PGP SIGNATURE----- From sopwith at redhat.com Mon Jan 3 18:44:23 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 3 Jan 2005 13:44:23 -0500 (EST) Subject: rpmbuild python bindings In-Reply-To: <41D9914C.20808@balclutha.org> References: <41D9914C.20808@balclutha.org> Message-ID: On Tue, 4 Jan 2005, Alan Milligan wrote: > Do any python bindings exist for rpmbuild?? AFAIK there are no python wrappers for rpmbuild. > Specifically, I'd like to be able to detect broken build dependencies > and recursively build and install these as part of an automated > python/Makefile script. You can find the dependencies with the existing rpm python bindings by doing a depcheck on a transactionset that includes the .src.rpm. The package building is not hard to do from python just by running rpmbuild, and installing them is done through the existing python rpm bindings. Cheers, -- Elliot From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 3 19:36:07 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 03 Jan 2005 20:36:07 +0100 Subject: rpmbuild python bindings In-Reply-To: (Elliot Lee's message of "Mon, 3 Jan 2005 13:44:23 -0500 (EST)") References: <41D9914C.20808@balclutha.org> Message-ID: <87d5wm71aw.fsf@kosh.ultra.csn.tu-chemnitz.de> sopwith at redhat.com (Elliot Lee) writes: >> Specifically, I'd like to be able to detect broken build dependencies >> and recursively build and install these as part of an automated >> python/Makefile script. > > You can find the dependencies with the existing rpm python bindings by > doing a depcheck on a transactionset that includes the .src.rpm. This will not work. With this method you determine the deps which were used to generate the existing .src.rpm. But you want to know the deps which will be needed to build the new packages. E.g. the src.rpm from 'rpmbuild -bs ... --target=i386' with | %ifarch %ix86 | BuildRequires: dietlibc | %endif will have other deps than the build for the x86_64 arch. Enrico From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 3 19:38:32 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 03 Jan 2005 20:38:32 +0100 Subject: rpmbuild python bindings In-Reply-To: <41D9914C.20808@balclutha.org> (Alan Milligan's message of "Tue, 04 Jan 2005 05:39:08 +1100") References: <41D9914C.20808@balclutha.org> Message-ID: <878y7a716v.fsf@kosh.ultra.csn.tu-chemnitz.de> alan at balclutha.org (Alan Milligan) writes: > Do any python bindings exist for rpmbuild?? > > Specifically, I'd like to be able to detect broken build dependencies and > recursively build and install these as part of an automated python/Makefile > script. Sorry; no python bindings. But getdeps.c from [1] shows a way to do this in a native C way and with formatted output. Perhaps a simple python module can be generated out of this. Enrico Footnotes: [1] http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/files/fedora.us-build-0.9.14-0.src.rpm From sopwith at redhat.com Mon Jan 3 19:39:37 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 3 Jan 2005 14:39:37 -0500 (EST) Subject: rpmbuild python bindings In-Reply-To: <87d5wm71aw.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <41D9914C.20808@balclutha.org> <87d5wm71aw.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: On Mon, 3 Jan 2005, Enrico Scholz wrote: > E.g. the src.rpm from 'rpmbuild -bs ... --target=i386' with > > | %ifarch %ix86 > | BuildRequires: dietlibc > | %endif > > will have other deps than the build for the x86_64 arch. This is a reason why rpm needs proper per-arch buildrequires. -- Elliot From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 3 19:52:49 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 03 Jan 2005 20:52:49 +0100 Subject: rpmbuild python bindings In-Reply-To: (Elliot Lee's message of "Mon, 3 Jan 2005 14:39:37 -0500 (EST)") References: <41D9914C.20808@balclutha.org> <87d5wm71aw.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <87wtuu47e6.fsf@kosh.ultra.csn.tu-chemnitz.de> sopwith at redhat.com (Elliot Lee) writes: >> E.g. the src.rpm from 'rpmbuild -bs ... --target=i386' with >> >> | %ifarch %ix86 >> | BuildRequires: dietlibc >> | %endif >> >> will have other deps than the build for the x86_64 arch. > > This is a reason why rpm needs proper per-arch buildrequires. A .src.rpm is usually architecture-independent and you generate binaries for all possible architectures out of a single src.rpm. '--define' options or '%(execute-a-dirty-script)' statements must be handled also since they can influence the buildrequires. Enrico From notting at redhat.com Mon Jan 3 22:48:13 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 3 Jan 2005 17:48:13 -0500 Subject: some changes for (slightly) faster boot Message-ID: <20050103224813.GA23361@nostromo.devel.redhat.com> In tomorrow's rawhide should be kudzu-1.105-1 and initscripts-8.02-1. These implement various changes for speeding up bootup some: - removal of initlog and minilogd Basically, the things that were logged before syslog started were generally uninteresting, and it added a surprising amount of delay to the bootup. There should/will be a better mechanism for recording whether services start succesfully added at some point later. - hack to allow kudzu to read the devices from a socket from kmodule This allows hardware probing to be done only once; the specifics of where/how kudzu is run in this setup may be tweaked slightly - the initscript may be moved. kudzu also runs without interaction now, and just does the configuration of whatever it finds. The combination of these should speed up the boot a somewhat noticeable amount of time compared to stock FC3. Currently, there are the following issues: - text boot is now more noisy initlog did hide some spew from various services; this needs cleaned up. - things that try to call initlog will simply fail openssh and Canna should be fixed. Other things will need fixed. I suppose a initlog wrapper that accepts the same syntax and just 'execs' may be useful, but it's probably best to do a clean break and see what happens. Bill From jspaleta at gmail.com Mon Jan 3 22:55:26 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 3 Jan 2005 17:55:26 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050103224813.GA23361@nostromo.devel.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> Message-ID: <604aa791050103145520d9424a@mail.gmail.com> On Mon, 3 Jan 2005 17:48:13 -0500, Bill Nottingham wrote: > - hack to allow kudzu to read the devices from a socket from kmodule > > This allows hardware probing to be done only once; the specifics of > where/how kudzu is run in this setup may be tweaked slightly - the > initscript may be moved. kudzu also runs without interaction > now, and just does the configuration of whatever it finds. Does this mean kudzu will remove and unconfigure whatever it doesnt find without interaction as well? -jef From notting at redhat.com Mon Jan 3 22:57:09 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 3 Jan 2005 17:57:09 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <604aa791050103145520d9424a@mail.gmail.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> Message-ID: <20050103225709.GA23700@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > > This allows hardware probing to be done only once; the specifics of > > where/how kudzu is run in this setup may be tweaked slightly - the > > initscript may be moved. kudzu also runs without interaction > > now, and just does the configuration of whatever it finds. > > Does this mean kudzu will remove and unconfigure whatever it doesnt > find without interaction as well? Yes. Hence, a large shaking out period. Bill From paul at all-the-johnsons.co.uk Mon Jan 3 23:07:20 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 03 Jan 2005 23:07:20 +0000 Subject: some changes for (slightly) faster boot In-Reply-To: <20050103225709.GA23700@nostromo.devel.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> Message-ID: <1104793640.3581.0.camel@localhost.localdomain> Hi, > > Does this mean kudzu will remove and unconfigure whatever it doesnt > > find without interaction as well? > > Yes. Hence, a large shaking out period. Excellent. Now to get my system to actually allow me to install rpms without constantly giving me preun and postun errors! rpm --vv isn't being very helpful... TTFN Paul -- "He's not the Messiah, he's a very naughty boy!" - Life of Brian, Monty Python -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pnasrat at redhat.com Mon Jan 3 23:09:49 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Mon, 3 Jan 2005 18:09:49 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104793640.3581.0.camel@localhost.localdomain> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <1104793640.3581.0.camel@localhost.localdomain> Message-ID: <20050103230948.GD9027@minimumble.lab.boston.redhat.com> On Mon, Jan 03, 2005 at 11:07:20PM +0000, Paul wrote: > Hi, > > > > Does this mean kudzu will remove and unconfigure whatever it doesnt > > > find without interaction as well? > > > > Yes. Hence, a large shaking out period. > > Excellent. Now to get my system to actually allow me to install rpms > without constantly giving me preun and postun errors! > > rpm --vv isn't being very helpful... Have you addressed this in bugzilla, rpm HEAD on rawhide is fine here? Paul From fedora at wir-sind-cool.org Mon Jan 3 23:21:01 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 4 Jan 2005 00:21:01 +0100 Subject: some changes for (slightly) faster boot In-Reply-To: <1104793640.3581.0.camel@localhost.localdomain> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <1104793640.3581.0.camel@localhost.localdomain> Message-ID: <20050104002101.1bab7f97.fedora@wir-sind-cool.org> On Mon, 03 Jan 2005 23:07:20 +0000, Paul wrote: > Hi, > > > > Does this mean kudzu will remove and unconfigure whatever it doesnt > > > find without interaction as well? > > > > Yes. Hence, a large shaking out period. > > Excellent. Now to get my system to actually allow me to install rpms > without constantly giving me preun and postun errors! > > rpm --vv isn't being very helpful... "rpm --query --scripts" on the package might be more helpful. Many scriptlets are executed in /bin/sh, so first make sure your /bin/sh works completely, then look what script contents fail. From paul at all-the-johnsons.co.uk Mon Jan 3 23:21:37 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 03 Jan 2005 23:21:37 +0000 Subject: some changes for (slightly) faster boot In-Reply-To: <20050103230948.GD9027@minimumble.lab.boston.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <1104793640.3581.0.camel@localhost.localdomain> <20050103230948.GD9027@minimumble.lab.boston.redhat.com> Message-ID: <1104794497.3581.7.camel@localhost.localdomain> Hi, > > Excellent. Now to get my system to actually allow me to install rpms > > without constantly giving me preun and postun errors! > > > > rpm --vv isn't being very helpful... > > Have you addressed this in bugzilla, rpm HEAD on rawhide is fine here? As I can't reproduce it on any other rawhide box, I'm putting it down to this box until I can prove otherwise. TTFN Paul -- "He's not the Messiah, he's a very naughty boy!" - Life of Brian, Monty Python -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at all-the-johnsons.co.uk Mon Jan 3 23:34:28 2005 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 03 Jan 2005 23:34:28 +0000 Subject: some changes for (slightly) faster boot In-Reply-To: <20050104002101.1bab7f97.fedora@wir-sind-cool.org> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <1104793640.3581.0.camel@localhost.localdomain> <20050104002101.1bab7f97.fedora@wir-sind-cool.org> Message-ID: <1104795268.3581.16.camel@localhost.localdomain> Hi, > "rpm --query --scripts" on the package might be more helpful. Okay... preinstall scriptlet (using /bin/sh): /sbin/modprobe loop 2> /dev/null > /dev/null || : exit 0 postinstall scriptlet (using /bin/sh): [ -x /sbin/new-kernel-pkg ] && /sbin/new-kernel-pkg --package kernel -- mkinitrd --depmod --install 2.6.10-1.1056_FC4 if [ -x /usr/sbin/hardlink ] ; then pushd /lib/modules/2.6.10-1.1056_FC4/build > /dev/null ; { cd /lib/modules/2.6.10-1.1056_FC4/build find . -type f | while read f; do hardlink -c /lib/modules/*/build/$f $f ; done } popd > /dev/null fi preuninstall scriptlet (using /bin/sh): /sbin/modprobe loop 2> /dev/null > /dev/null || : [ -x /sbin/new-kernel-pkg ] && /sbin/new-kernel-pkg --rminitrd -- rmmoddep --remove 2.6.10-1.1056_FC4 > Many scriptlets are executed in /bin/sh, so first make sure your > /bin/sh works completely, then look what script contents fail. I can start /bin/sh from the command line. Is there any way to test everything is functioning under it? Installing a kernel always fails on pre. I can run the preinstall script happily within /bin/sh TTFN Paul -- "He's not the Messiah, he's a very naughty boy!" - Life of Brian, Monty Python -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From roland at redhat.com Mon Jan 3 23:36:53 2005 From: roland at redhat.com (Roland McGrath) Date: Mon, 3 Jan 2005 15:36:53 -0800 Subject: some changes for (slightly) faster boot In-Reply-To: Bill Nottingham's message of Monday, 3 January 2005 17:57:09 -0500 <20050103225709.GA23700@nostromo.devel.redhat.com> Message-ID: <200501032336.j03NaruY023023@magilla.sf.frob.com> > Jeff Spaleta (jspaleta at gmail.com) said: > > > This allows hardware probing to be done only once; the specifics of > > > where/how kudzu is run in this setup may be tweaked slightly - the > > > initscript may be moved. kudzu also runs without interaction > > > now, and just does the configuration of whatever it finds. > > > > Does this mean kudzu will remove and unconfigure whatever it doesnt > > find without interaction as well? > > Yes. Hence, a large shaking out period. This is never what I want. I was damn annoyed the other day when someone with less clue accidentally hit return and let it remove some configuration. That is, it's never what I want when there is actual software configuration involved, not just presence-and-flavor-of-the-hardware configuration. It would be great if it corrected the modprobe aliases for the new NIC without me thinking about it. It really sucked some hindparts that it removed ifcfg-eth0 without a trace and then asked me how I wanted to configure the fresh one from scratch after it had added the different eth0 alias to modprobe.conf for me. When the sequence of questions was "Shall I remove your hand-tweaked configuration and leave no backup record of it?" followed by "Would you like to tweak this new configuration by hand from memory, or else have it not work at all if you do nothing special right now?", this was suboptimal. When those questions are answered "yes" by default with no interacton, this is unacceptable. From dax at gurulabs.com Mon Jan 3 23:51:50 2005 From: dax at gurulabs.com (Dax Kelson) Date: Mon, 03 Jan 2005 16:51:50 -0700 Subject: some changes for (slightly) faster boot In-Reply-To: <20050103225709.GA23700@nostromo.devel.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> Message-ID: <1104796310.4030.29.camel@mentorng.gurulabs.com> On Mon, 2005-01-03 at 17:57 -0500, Bill Nottingham wrote: > Jeff Spaleta (jspaleta at gmail.com) said: > > > This allows hardware probing to be done only once; the specifics of > > > where/how kudzu is run in this setup may be tweaked slightly - the > > > initscript may be moved. kudzu also runs without interaction > > > now, and just does the configuration of whatever it finds. > > > > Does this mean kudzu will remove and unconfigure whatever it doesnt > > find without interaction as well? > > Yes. Hence, a large shaking out period. Not good for many situations. For example: Currently my wireless NIC (Intel 2200BG) uses a out-of-kernel driver. Whenever Fedora releases an updated kernel and I reboot kudzu wants to remove my wireless NIC as I haven't recompiled my driver yet. I DO NOT want kudzu removing the configuration (very very long WEP keys, and other hand entered wireless settings). The behavior, as described, is unacceptable IMHO. Dax Kelson Guru Labs From alan at redhat.com Tue Jan 4 00:02:02 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 3 Jan 2005 19:02:02 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <200501032336.j03NaruY023023@magilla.sf.frob.com> References: <20050103225709.GA23700@nostromo.devel.redhat.com> <200501032336.j03NaruY023023@magilla.sf.frob.com> Message-ID: <20050104000202.GA29062@devserv.devel.redhat.com> On Mon, Jan 03, 2005 at 03:36:53PM -0800, Roland McGrath wrote: > with less clue accidentally hit return and let it remove some configuration. > That is, it's never what I want when there is actual software configuration > involved, not just presence-and-flavor-of-the-hardware configuration. Ditto. My laptop has a docking station that kudzu simply doesn't grok. The fact I can tell kudzu to just leave all existing configuration behind is pretty essential since every boot docked or undocked it discovers new hardware or removed hardware. Alan From jspaleta at gmail.com Tue Jan 4 00:06:50 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 3 Jan 2005 19:06:50 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050103225709.GA23700@nostromo.devel.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> Message-ID: <604aa79105010316065139aebc@mail.gmail.com> On Mon, 3 Jan 2005 17:57:09 -0500, Bill Nottingham wrote: > Yes. Hence, a large shaking out period. fun! I hope that shaking out period includes an effort to make kudzu aware of local changes so that local configurations can be restored instead of kudzu defaults when the hardware is found again. Auto removal isn't a bad thing... as long as there is a way to save and restore state information so kudzu's defaults are not relied on over and over again. As people have already pointed again in this thread... there is a communication gap in what kudzu wants as a configuration for some devices.. and what local admin/user wants. Is the hal/network-manager software stack suppose to provide the missing piece of the puzzle so that kudzu doesn't have to deal with site specific configs? -jef"as much fun as a dental visit"spaleta From michael.favia at insitesinc.com Tue Jan 4 00:08:29 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Mon, 03 Jan 2005 18:08:29 -0600 Subject: some changes for (slightly) faster boot In-Reply-To: <20050103225709.GA23700@nostromo.devel.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> Message-ID: <41D9DE7D.4040707@insitesinc.com> Bill Nottingham wrote: > Jeff Spaleta (jspaleta at gmail.com) said: > >>> This allows hardware probing to be done only once; the specifics of >>> where/how kudzu is run in this setup may be tweaked slightly - the >>> initscript may be moved. kudzu also runs without interaction >>> now, and just does the configuration of whatever it finds. >> >>Does this mean kudzu will remove and unconfigure whatever it doesnt >>find without interaction as well? > > > Yes. Hence, a large shaking out period. > While the addition and removal of the hardware that is present makes sense, the unconfiguration (read: data loss) of that hardware's profile does not. Is there not (or shouldn't there be) a mechanism to cache the configuration of the devices so that the customizations made to them is retained when they are plugged back in? This system would provide the benefits of both models (speed, statefulness) without the draw back of either (boot speed, digital decay) IMO. Should the user really want the device to "reset" when it is unplugged/poweredoff at restart and then reinstalled later would be to somehow manually clear the cache. Which is a much less frequent activity i hope. -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com From mrsam at courier-mta.com Tue Jan 4 00:22:43 2005 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Mon, 03 Jan 2005 19:22:43 -0500 Subject: some changes for (slightly) faster boot References: <20050103225709.GA23700@nostromo.devel.redhat.com> <200501032336.j03NaruY023023@magilla.sf.frob.com> <20050104000202.GA29062@devserv.devel.redhat.com> Message-ID: Alan Cox writes: > On Mon, Jan 03, 2005 at 03:36:53PM -0800, Roland McGrath wrote: >> with less clue accidentally hit return and let it remove some configuration. >> That is, it's never what I want when there is actual software configuration >> involved, not just presence-and-flavor-of-the-hardware configuration. > > Ditto. My laptop has a docking station that kudzu simply doesn't grok. The > fact I can tell kudzu to just leave all existing configuration behind is > pretty essential since every boot docked or undocked it discovers new > hardware or removed hardware. Same thing happens with garden-variety PCMCIA cards or anything attached to the USB port, if you change run levels. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hp at redhat.com Tue Jan 4 03:20:44 2005 From: hp at redhat.com (Havoc Pennington) Date: Mon, 03 Jan 2005 22:20:44 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104796310.4030.29.camel@mentorng.gurulabs.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <1104796310.4030.29.camel@mentorng.gurulabs.com> Message-ID: <1104808844.22762.23.camel@localhost.localdomain> IMO the root problem if this breaks is mixing of autoprobe data with user configuration. We need to fix it by unmixing those things, not by breaking autoprobe or losing people's config files. Here is the basic flow you want: autoprobe and write out automated data about devices and drivers -> apply user-provided overrides and edits to autoprobed information -> autodetermine reasonable behavior in light of device details -> apply user-provided overrides and edits to default behavior -> invoke behavior So a concrete example: autoprobe ethernet card model Foo with details blah blah -> user wants to use alternate driver or work around hardware bug, said override data loaded -> autodetermine that if a link is present device should be brought up with dhcp -> user has specified that device should only be brought up manually -> device is now configured to come up manually with alternate driver Or whatever, you see the point. It's easy enough to see that we can have whitelists/blacklists inserted into the flow, so e.g. OS vendors or OEMs can provide overrides as well. The same basic idea is where we want to be going with X server configuration: the config file should contain only a delta from the default behavior. Or for that matter, something like "profile.d" is the same basic idea. Don't mix the automatically-created data, the vendor-provided data, and the site local data. I think it's fine to switch the default to autoprobe always in rawhide, it will encourage someone to fix the root problem ;-) but we probably can't ship with autoprobe until we unmix data from distinct sources. Havoc From notting at redhat.com Tue Jan 4 03:45:34 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 3 Jan 2005 22:45:34 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <604aa79105010316065139aebc@mail.gmail.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> Message-ID: <20050104034534.GA26184@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > As people have already pointed again in this thread... there is a > communication gap in what kudzu wants as a configuration for some > devices.. and what local admin/user wants. Is the hal/network-manager > software stack suppose to provide the missing piece of the puzzle so > that kudzu doesn't have to deal with site specific configs? It's part of it. Realistically, the only sort of device that has a lot of site-local configuration is a network card; for most other things you don't care. Hence, where we're probably going to end up is that kudzu will, at most, handle things like modprobe.conf aliases for networking; actual config will be handled by something like NetworkManager, and system-config-network. Bill From notting at redhat.com Tue Jan 4 03:54:55 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 3 Jan 2005 22:54:55 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050103225709.GA23700@nostromo.devel.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> Message-ID: <20050104035455.GA26334@nostromo.devel.redhat.com> Bill Nottingham (notting at redhat.com) said: > > Does this mean kudzu will remove and unconfigure whatever it doesnt > > find without interaction as well? > > Yes. Hence, a large shaking out period. Note that *this* part has actually been in rawhide since the middle of December... Bill From grmoc at yahoo.com Tue Jan 4 05:05:18 2005 From: grmoc at yahoo.com (Roberto Peon) Date: Mon, 3 Jan 2005 21:05:18 -0800 (PST) Subject: some changes for (slightly) faster boot In-Reply-To: <41D9DE7D.4040707@insitesinc.com> Message-ID: <20050104050518.37482.qmail@web41525.mail.yahoo.com> This sounds good.. And generally, configuration is tiny, so keeping it around isn't generally a problem from that end. -Roberto JP --- Michael Favia wrote: > Bill Nottingham wrote: > > Jeff Spaleta (jspaleta at gmail.com) said: > > > >>> This allows hardware probing to be done only once; the specifics of > >>> where/how kudzu is run in this setup may be tweaked slightly - the > >>> initscript may be moved. kudzu also runs without interaction > >>> now, and just does the configuration of whatever it finds. > >> > >>Does this mean kudzu will remove and unconfigure whatever it doesnt > >>find without interaction as well? > > > > > > Yes. Hence, a large shaking out period. > > > > While the addition and removal of the hardware that is present makes > sense, the unconfiguration (read: data loss) of that hardware's profile > does not. Is there not (or shouldn't there be) a mechanism to cache the > configuration of the devices so that the customizations made to them is > retained when they are plugged back in? This system would provide the > benefits of both models (speed, statefulness) without the draw back of > either (boot speed, digital decay) IMO. > > Should the user really want the device to "reset" when it is > unplugged/poweredoff at restart and then reinstalled later would be to > somehow manually clear the cache. Which is a much less frequent activity > i hope. > > > -- > Michael Favia michael.favia at insitesinc.com > Insites Incorporated http://michael.insitesinc.com > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From grmoc at yahoo.com Tue Jan 4 05:07:05 2005 From: grmoc at yahoo.com (Roberto Peon) Date: Mon, 3 Jan 2005 21:07:05 -0800 (PST) Subject: some changes for (slightly) faster boot In-Reply-To: <20050104034534.GA26184@nostromo.devel.redhat.com> Message-ID: <20050104050705.69694.qmail@web41501.mail.yahoo.com> Disagreement. I have custom configuration for my audio card (custom alsa config), and my video capture card (have to specify tuner and firmware location) as well. -Roberto JP --- Bill Nottingham wrote: > Jeff Spaleta (jspaleta at gmail.com) said: > > As people have already pointed again in this thread... there is a > > communication gap in what kudzu wants as a configuration for some > > devices.. and what local admin/user wants. Is the hal/network-manager > > software stack suppose to provide the missing piece of the puzzle so > > that kudzu doesn't have to deal with site specific configs? > > It's part of it. > > Realistically, the only sort of device that has a lot of site-local > configuration is a network card; for most other things you don't care. > > Hence, where we're probably going to end up is that kudzu will, at > most, handle things like modprobe.conf aliases for networking; > actual config will be handled by something like NetworkManager, > and system-config-network. > > Bill > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From notting at redhat.com Tue Jan 4 05:36:23 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 4 Jan 2005 00:36:23 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050104050705.69694.qmail@web41501.mail.yahoo.com> References: <20050104034534.GA26184@nostromo.devel.redhat.com> <20050104050705.69694.qmail@web41501.mail.yahoo.com> Message-ID: <20050104053623.GA26872@nostromo.devel.redhat.com> Roberto Peon (grmoc at yahoo.com) said: > Disagreement. > > I have custom configuration for my audio card (custom alsa config), and my > video capture card (have to specify tuner and firmware location) as well. kudzu doesn't touch these, unless I'm missing something. Bill From mattdm at mattdm.org Tue Jan 4 06:08:39 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 4 Jan 2005 01:08:39 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050104000202.GA29062@devserv.devel.redhat.com> References: <20050103225709.GA23700@nostromo.devel.redhat.com> <200501032336.j03NaruY023023@magilla.sf.frob.com> <20050104000202.GA29062@devserv.devel.redhat.com> Message-ID: <20050104060839.GA17819@jadzia.bu.edu> On Mon, Jan 03, 2005 at 07:02:02PM -0500, Alan Cox wrote: > Ditto. My laptop has a docking station that kudzu simply doesn't grok. The > fact I can tell kudzu to just leave all existing configuration behind is > pretty essential since every boot docked or undocked it discovers new > hardware or removed hardware. rpm -e kudzu :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From roland at redhat.com Tue Jan 4 06:50:13 2005 From: roland at redhat.com (Roland McGrath) Date: Mon, 3 Jan 2005 22:50:13 -0800 Subject: some changes for (slightly) faster boot In-Reply-To: Havoc Pennington's message of Monday, 3 January 2005 22:20:44 -0500 <1104808844.22762.23.camel@localhost.localdomain> Message-ID: <200501040650.j046oDSF025800@magilla.sf.frob.com> > IMO the root problem if this breaks is mixing of autoprobe data with > user configuration. We need to fix it by unmixing those things, not by > breaking autoprobe or losing people's config files. Sure. But actually my problem doesn't need this sort of general solution. Rather, it needs the separation of what's kudzu's bidness and what ain't, which has already been mentioned. That is, for the case of network cards, I want to have custom configuration for "eth0" and when I swap out the motherboard and there is a different NIC flavor now, kudzu is damn helpful in updating the idea of what driver "eth0" means and I need it for that. So if that part of it is separated out into network-manager or whatever, I would just have that configured not to change anything automagically and be happy (disable network-manager, I guess, since I don't know what it is). From fedora at wir-sind-cool.org Tue Jan 4 08:01:48 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 4 Jan 2005 09:01:48 +0100 Subject: some changes for (slightly) faster boot In-Reply-To: <1104795268.3581.16.camel@localhost.localdomain> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <1104793640.3581.0.camel@localhost.localdomain> <20050104002101.1bab7f97.fedora@wir-sind-cool.org> <1104795268.3581.16.camel@localhost.localdomain> Message-ID: <20050104090148.0d50a2dc.fedora@wir-sind-cool.org> On Mon, 03 Jan 2005 23:34:28 +0000, Paul wrote: > Hi, > > > "rpm --query --scripts" on the package might be more helpful. > > Okay... > > preinstall scriptlet (using /bin/sh): > /sbin/modprobe loop 2> /dev/null > /dev/null || : > exit 0 As one observation, the scriptlet itself always returns exit code 0 (true), so that raises the question why rpm sees exit code 255? What does an strace say at that part? D: install: kernel-2.6.10-1.1056_FC4 has 8380 files, test = 0 D: install: %pre(kernel-2.6.10-1.1056_FC4.i686) asynchronous scriptlet start D: install: %pre(kernel-2.6.10-1.1056_FC4.i686) execv(/bin/sh) pid 5058 D: install: waitpid(5058) rc 5058 status ff00 secs 0.002 error: %pre(kernel-2.6.10-1.1056_FC4.i686) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping kernel-2.6.10-1.1056_FC4 > > Many scriptlets are executed in /bin/sh, so first make sure your > > /bin/sh works completely, then look what script contents fail. > > I can start /bin/sh from the command line. Is there any way to test > everything is functioning under it? Installing a kernel always fails on > pre. > > I can run the preinstall script happily within /bin/sh From david.paeme at belbone.net Tue Jan 4 08:33:17 2005 From: david.paeme at belbone.net (david paeme) Date: Tue, 04 Jan 2005 09:33:17 +0100 Subject: kernel cpufreq dothan support -- kernel patch proposal Message-ID: <41DA54CD.4080203@belbone.net> /* i've also submitted this into bugzilla, bug #144060) */ Hello, The kernels distributed with FC3 (up to the 2.6.9.715 version in updates/testing) seem to be missing support for intel's Dothan Pentium-M. The processors are recognized, but the speedstep-centrino module only has support for acpi frequency scaling on them. This compared to the older Banias model's 'table' support, which means that cpufreq knows more than max/min speeds, and is able to scale fluently between them. Here's a patch wich adds support for all Dothan cpu's up to the 755 version (2.0 Ghz). http://localhost.ruhr.de/~stefan/acerTM292/patches/cpufreq-speedstep-dothan-3.patch Applying this patch to the latest FC3 kernels seem to work for me (dothan 1.6ghz, stepping b0), and it also patches into the official 2.9.10 kernels. The patch also seems to stop the gnome cpufreq applet to spot complaining... What do you people think about this? useful? good for inclusion? It certainly is nice to have this stuff working... bye, David. From grmoc at yahoo.com Tue Jan 4 09:08:24 2005 From: grmoc at yahoo.com (Roberto Peon) Date: Tue, 4 Jan 2005 01:08:24 -0800 (PST) Subject: some changes for (slightly) faster boot In-Reply-To: <20050104053623.GA26872@nostromo.devel.redhat.com> Message-ID: <20050104090824.66986.qmail@web41529.mail.yahoo.com> My point is/was simply that there is custom configuration of/for modules and hardware that is not ethernet related. -Roberto --- Bill Nottingham wrote: > Roberto Peon (grmoc at yahoo.com) said: > > Disagreement. > > > > I have custom configuration for my audio card (custom alsa config), and my > > video capture card (have to specify tuner and firmware location) as well. > > kudzu doesn't touch these, unless I'm missing something. > > Bill > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From wtogami at redhat.com Tue Jan 4 09:35:05 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 03 Jan 2005 23:35:05 -1000 Subject: kernel cpufreq dothan support -- kernel patch proposal In-Reply-To: <41DA54CD.4080203@belbone.net> References: <41DA54CD.4080203@belbone.net> Message-ID: <41DA6349.2070503@redhat.com> david paeme wrote: > /* i've also submitted this into bugzilla, bug #144060) */ > > > Hello, > > The kernels distributed with FC3 (up to the 2.6.9.715 version in > updates/testing) seem to be missing support for intel's Dothan Pentium-M. > SNIP > > What do you people think about this? useful? good for inclusion? It > certainly is nice to have this stuff working... > > Thank you for your submission, but as the case with any kernel patch, it would greatly simplify software maintenance for both us and upstream kernel.org if it is merged into the upstream kernel. Please focus your merging efforts there. Warren Togami wtogami at redhat.com From david.paeme at belbone.net Tue Jan 4 09:58:45 2005 From: david.paeme at belbone.net (david paeme) Date: Tue, 04 Jan 2005 10:58:45 +0100 Subject: kernel cpufreq dothan support -- kernel patch proposal In-Reply-To: <41DA6349.2070503@redhat.com> References: <41DA54CD.4080203@belbone.net> <41DA6349.2070503@redhat.com> Message-ID: <41DA68D5.9090002@belbone.net> I forgot to mention this: The patch isn't mine at all, I found it on Stefan Tomanek's site, and it's written by Michael Clark (as far as I can see) my apologies for the missing credits... bye, d. Warren Togami wrote: > david paeme wrote: > >> /* i've also submitted this into bugzilla, bug #144060) */ >> >> >> Hello, >> >> The kernels distributed with FC3 (up to the 2.6.9.715 version in >> updates/testing) seem to be missing support for intel's Dothan Pentium-M. >> > SNIP > >> >> What do you people think about this? useful? good for inclusion? It >> certainly is nice to have this stuff working... >> >> > > Thank you for your submission, but as the case with any kernel patch, it > would greatly simplify software maintenance for both us and upstream > kernel.org if it is merged into the upstream kernel. Please focus your > merging efforts there. > > Warren Togami > wtogami at redhat.com > From shiva at sewingwitch.com Tue Jan 4 12:11:53 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Tue, 04 Jan 2005 04:11:53 -0800 Subject: 4G/4G kernel patch dropped Message-ID: <1460C4B716A20B689FE0BD75@[10.0.0.4]> I just saw the announcement of a new Fedora kernel with this change note: > A large change over previous kernels has been made. The 4G:4G memory > split patch has been dropped, and Fedora kernels now revert back to > the upstream 3G:1G kernel/userspace split. A bit of googling indicates that the 4G:4G patch is needed for systems with a lot of RAM (eg. 32 GB or more) because the kernel memory tables scale with the size of physical memory and a 32 GB system uses 0.5 GB for the table, half the kernel space available to a 3G:1G system. A 64 GB system won't boot because all of kernel memory is needed for the table. Was this reversion done for performance or for some other reason? I'd guess most consumer systems won't need 4G:4G as they won't have anything like that much memory, and it only makes sense for an enterprise class server. From arjanv at redhat.com Tue Jan 4 12:24:52 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 04 Jan 2005 13:24:52 +0100 Subject: 4G/4G kernel patch dropped In-Reply-To: <1460C4B716A20B689FE0BD75@[10.0.0.4]> References: <1460C4B716A20B689FE0BD75@[10.0.0.4]> Message-ID: <1104841492.4215.29.camel@laptopd505.fenrus.org> On Tue, 2005-01-04 at 04:11 -0800, Kenneth Porter wrote: > I just saw the announcement of a new Fedora kernel with this change note: > > > A large change over previous kernels has been made. The 4G:4G memory > > split patch has been dropped, and Fedora kernels now revert back to > > the upstream 3G:1G kernel/userspace split. > > A bit of googling indicates that the 4G:4G patch is needed for systems with > a lot of RAM (eg. 32 GB or more) and for people with less ram but who want to run java with lots of threads... in that case you care a lot about the extra 1Gb of userspace address space. Even with a moderate amount of threads this makes the java garbage collector run less frequently -> nicer performance ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From felipe_alfaro at linuxmail.org Tue Jan 4 12:36:57 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Tue, 4 Jan 2005 13:36:57 +0100 Subject: 4G/4G kernel patch dropped In-Reply-To: <1460C4B716A20B689FE0BD75@[10.0.0.4]> References: <1460C4B716A20B689FE0BD75@[10.0.0.4]> Message-ID: <529221D2-5E4D-11D9-A816-000D9352858E@linuxmail.org> On 4 Jan 2005, at 13:11, Kenneth Porter wrote: > I just saw the announcement of a new Fedora kernel with this change > note: > >> A large change over previous kernels has been made. The 4G:4G memory >> split patch has been dropped, and Fedora kernels now revert back to >> the upstream 3G:1G kernel/userspace split. > > A bit of googling indicates that the 4G:4G patch is needed for systems > with a lot of RAM (eg. 32 GB or more) because the kernel memory tables > scale with the size of physical memory and a 32 GB system uses 0.5 GB > for the table, half the kernel space available to a 3G:1G system. A 64 > GB system won't boot because all of kernel memory is needed for the > table. > > > > Was this reversion done for performance or for some other reason? I'd > guess most consumer systems won't need 4G:4G as they won't have > anything like that much memory, and it only makes sense for an > enterprise class server. Maybe the 4-level Pagetable changes Andrea Arcangeli introduced into 2.6.10 are related? From buildsys at redhat.com Tue Jan 4 12:55:56 2005 From: buildsys at redhat.com (Build System) Date: Tue, 4 Jan 2005 07:55:56 -0500 Subject: rawhide report: 20050104 changes Message-ID: <200501041255.j04Ctu629122@porkchop.devel.redhat.com> Updated Packages: Canna-3.7p3-10 -------------- * Mon Jan 03 2005 Bill Nottingham - 3.7p3-10 - don't use initlog HelixPlayer-1:1.0.2-1 --------------------- * Mon Jan 03 2005 Colin Walters 1:1.0.2-1 - New upstream version 1.0.2 - Switch to hxplay_gtk_stable branch cracklib-2.7-30 --------------- * Mon Jan 03 2005 Nalin Dahyabhai 2.7-30 - rebuild * Mon Jan 03 2005 Nalin Dahyabhai 2.7-29 - correctly build on 64-bit systems (part of #143417) - patch so that 32- and 64-bit libcrack can read dictionaries which were incorrectly generated on 64-bit systems of the same endianness (more #143417) - include a sample cracklib magic file - stop using /usr/dict/* when building the dictionary - list words as a build requirement, which it is, instead of a run-time requirement - provide a virtual arch-specific dep in cracklib-dicts, require it in cracklib (part of #143417) db4-4.3.27-1 ------------ * Sat Jan 01 2005 Jeff Johnson 4.3.27-1 - upgrade to 4.3.27. dhcp-7:3.0.1-16 --------------- * Sun Jan 02 2005 Jason Vas Dias 7:3.0.1-16 - fix bug 143704: dhclient -r does not work if lease held by - dhclient run from ifup . dhclient will now look for the pid - files created by ifup . ed-0.2-37 --------- * Mon Jan 03 2005 Karsten Hopp 0.2-37 - spec file fix from Marcin Garski (#143723) gaim-1:1.1.1-2 -------------- * Mon Jan 03 2005 Warren Togami 1.1.1-2 - force required glib2 version grub-0.95-6 ----------- * Mon Jan 03 2005 Peter Jones 0.95-6 - reworked much of how the RAID1 support in grub-install works. This version does not require all the devices in the raid to be listed in device.map, as long as you specify a physical device or partition rather than an md device. It should also work with a windows dual-boot on the first partition. gstreamer-0.8.8-1 ----------------- * Mon Jan 03 2005 Colin Walters 0.8.8-1 - Update to 0.8.8 - Remove upstreamed escape-uris patch - Readd redirection of register output to /dev/null gstreamer-plugins-0.8.6-1 ------------------------- * Tue Dec 21 2004 Colin Walters - 0.8.6-1 - New upstream version - Remove obsoleted gstreamer-plugins-0.8.4-vorbis-seek-workaround.patch - BR latest libavc1394-devel - Add libgstequalizer.so hdparm-5.8-2 ------------ * Mon Jan 03 2005 Karsten Hopp 5.8-2 - add --help option (#143916) * Fri Nov 26 2004 Karsten Hopp 5.8-1 - update initscripts-8.02-1 ------------------ * Mon Jan 03 2005 Bill Nottingham 8.02-1 - remove initlog, minilogd - add a flag to kmodule for use with kudzu's socket mode, use it - change setting of IPv6 default route (#142308, ) - netfs: don't unmount NFS root FS (#142169) iprutils-2.0.13.5-1 ------------------- * Mon Jan 03 2005 Paul Nasrat - 2.0.13.5-1 - Update to 2.0.13.5 (#143593) * Wed Dec 08 2004 Jeremy Katz - 2.0.13.4-2 - link dynamically to sysfsutils instead of statically (#142310) * Wed Dec 08 2004 Paul Nasrat 2.0.13.4-1 - update to 2.0.13.4 (#142164) kudzu-1.1.106-1 --------------- * Mon Jan 03 2005 Bill Nottingham - 1.1.106-1 - fix a fd leak in the sx8/i2o probe - add a method for reading probed devices from a socket - attempt to use that method by default - don't tweak network configurations for now libavc1394-0.4.1-5 ------------------ * Mon Jan 03 2005 Colin Walters 0.4.1-5 - Rerun autotools in attempt to get package to link to -lm - Add patch libavc1394-0.4.1-kill-configure-insanity.patch libtheora-0:1.0alpha4-1 ----------------------- * Mon Jan 03 2005 Colin Walters - 1.0alpha4-1 - New upstream version 1.0alpha4 - Remove upstreamed patch libtheora-1.0alpha3-include.patch - Use Theora_I_spec.pdf for spec - Add in .pc file (yay! another library sees the light) openssh-3.9p1-9 --------------- * Mon Jan 03 2005 Bill Nottingham 3.9p1-9 - don't use initlog policycoreutils-1.19.2-4 ------------------------ * Mon Jan 03 2005 Dan Walsh 1.19.2-4 - Fix fixfiles handling of rpm - Fix restorecon to not warn on symlinks unless -v -v - Fix output of verbose to show old context as well as new context rpmdb-fedora-1:4-0.20050104 --------------------------- selinux-policy-strict-1.19.15-14 -------------------------------- * Mon Jan 03 2005 Dan Walsh 1.19-15-14 - Have cups_config_t create files with the right context - Allow all file_types to be associated with noexettr file systems - Allow apache scripts to read fonts_t - dontaudit squid trying to read / - Allow httpd_suexec_t to read home directories * Tue Dec 28 2004 Dan Walsh 1.19-15-11 - Change sshd, xdm, crond, sendmail to run under different context - in targeted policy selinux-policy-targeted-1.19.15-14 ---------------------------------- * Mon Jan 03 2005 Dan Walsh 1.19-15-14 - Have cups_config_t create files with the right context - Allow all file_types to be associated with noexettr file systems - Allow apache scripts to read fonts_t - dontaudit squid trying to read / system-config-securitylevel-1.4.21-1 ------------------------------------ * Mon Jan 03 2005 Chris Lumens 1.4.21-1 - Fixed import of scs_checklist module (#143776). totem-0.100-1 ------------- * Mon Jan 03 2005 Colin Walters - 0.100-1 - New upstream version 0.100 zlib-1.2.2.2-1 -------------- * Sat Jan 01 2005 Jeff Johnson 1.2.2.2-1 - upgrade to 1.2.2.2. zsh-4.2.1-1 ----------- * Mon Jan 03 2005 Colin Walters - 4.2.1-1 - New upstream version 4.2.1 - FEATURES, MACHINES, and NEWS moved to toplevel dir - Update zsh-4.0.6-make-test-fail.patch, but do not apply it for now - Remove upstreamed zsh-4.2.0-jobtable-125452.patch From pbruna at linuxcenterla.com Tue Jan 4 13:20:38 2005 From: pbruna at linuxcenterla.com (Patricio Bruna V) Date: Tue, 04 Jan 2005 10:20:38 -0300 Subject: souncard and alsa Message-ID: <1104844838.2754.2.camel@p.linuxcenter.cl> has alsa compiled with dmix support? -- Patricio Bruna http://www.linuxcenterla.com Ingeniero de Proyectos Mariano S?nchez Fontecilla 310 Red Hat Certified Engineer Las Condes, Santiago - CHILE Linux Center Latinoamerica Fono: 2745000 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From fedora-devel at camperquake.de Tue Jan 4 13:14:09 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Tue, 4 Jan 2005 14:14:09 +0100 Subject: souncard and alsa In-Reply-To: <1104844838.2754.2.camel@p.linuxcenter.cl> References: <1104844838.2754.2.camel@p.linuxcenter.cl> Message-ID: <20050104141409.16227cf6@nausicaa.camperquake.de> Hi. Patricio Bruna V wrote: > has alsa compiled with dmix support? Yes. -- "Anonymous CVS heisst: Kein Einchecken, nur Auschecken. So eine Art inverses Hotel California." -- Kristian Koehntopp From kyrre at solution-forge.net Tue Jan 4 16:27:44 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 04 Jan 2005 17:27:44 +0100 Subject: Trying to build the adm8211 kernel module Message-ID: <1104856064.7207.14.camel@localhost.localdomain> I am trying to build the driver for my admtec 8211 based wlan card (SMC2635W), but i am having some difficulties due to the removal of the kernel-source rpm. (an otherwise perfectly sensible choice.) I was just about to make my own exploded source three, when i came over this notice in the release notes: """ An exploded source tree is not required to build kernel modules against the currently in-use kernel. For example, to build the foo.ko module, create the following file (named Makefile) in the directory containing the foo.c file: obj-m := foo.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) default: $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules Issue the make command to build the foo.ko module. """ Now, those drivers already has a makefile - and it is a bit more complicated. It does among other thing build a number of .c files into this module... Can anybody help? The driver shall after what i heard be a part of the official kernel (first, the -mm series), but it isn't "ready" yet. When that is said, the driver has served me well, and is still rapidly improving. The driver can be found here: http://aluminum.sourmilk.net/adm8211/ If somebody can help me create a working makefile, i shall ofcource send the changes back so that it can be a part of the main distro of the driver (i would guess a separate fedora makefile would be the easiest...) Kyrre From jspaleta at gmail.com Tue Jan 4 16:51:38 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 4 Jan 2005 11:51:38 -0500 Subject: Trying to build the adm8211 kernel module In-Reply-To: <1104856064.7207.14.camel@localhost.localdomain> References: <1104856064.7207.14.camel@localhost.localdomain> Message-ID: <604aa79105010408516b408c51@mail.gmail.com> On Tue, 04 Jan 2005 17:27:44 +0100, Kyrre Ness Sjobak wrote: > If somebody can help me create a working makefile, i shall ofcource send > the changes back so that it can be a part of the main distro of the > driver (i would guess a separate fedora makefile would be the > easiest...) Uhm..... adm8211-20041227.tar.bz2 on my fc2 and fc3 system without a kernel-source(code) rpm installed works just fine. The make file in the 20041222 has the correct KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) running make inside /tmp/adm8211/ and i get a adm8211.ko created. Seems to work just as one would expect. and make install tries to place the created module in /lib/modules/2.6.9-1.11_FC2/kernel/drivers/net/wireless/adm8211.ko on my fc2 system for example. The 20041227 tarball has fixes for the 2.6.10 kernel and doesnt compile correctly on the lastest fc2 or fc3 2.6.9 kernel.. but it has nothing to do with the makefile. -jef From jspaleta at gmail.com Tue Jan 4 16:53:31 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 4 Jan 2005 11:53:31 -0500 Subject: Trying to build the adm8211 kernel module In-Reply-To: <604aa79105010408516b408c51@mail.gmail.com> References: <1104856064.7207.14.camel@localhost.localdomain> <604aa79105010408516b408c51@mail.gmail.com> Message-ID: <604aa791050104085365e89b62@mail.gmail.com> On Tue, 4 Jan 2005 11:51:38 -0500, Jeff Spaleta wrote: > Uhm..... adm8211-20041227.tar.bz2 on my fc2 and fc3 system without a > kernel-source(code) rpm installed works just fine. The make file in > the 20041222 has the correct oops... that should read as adm8211-20041222.tar.bz2 in the first line. the 20041122 works on fc2 and fc3 2.6.9 kernels. -jef From otaylor at redhat.com Tue Jan 4 17:05:00 2005 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 04 Jan 2005 12:05:00 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050104000202.GA29062@devserv.devel.redhat.com> References: <20050103225709.GA23700@nostromo.devel.redhat.com> <200501032336.j03NaruY023023@magilla.sf.frob.com> <20050104000202.GA29062@devserv.devel.redhat.com> Message-ID: <1104858300.4316.9.camel@localhost.localdomain> On Mon, 2005-01-03 at 19:02 -0500, Alan Cox wrote: > On Mon, Jan 03, 2005 at 03:36:53PM -0800, Roland McGrath wrote: > > with less clue accidentally hit return and let it remove some configuration. > > That is, it's never what I want when there is actual software configuration > > involved, not just presence-and-flavor-of-the-hardware configuration. > > Ditto. My laptop has a docking station that kudzu simply doesn't grok. The > fact I can tell kudzu to just leave all existing configuration behind is > pretty essential since every boot docked or undocked it discovers new > hardware or removed hardware. But you can't possibly believe that this is the right behavior??? To have to manually interact with the startup every time to keep it from deleting useful information? If there is information that needs to be kept around per-device, then it should be stored keyed to the device even when the device isn't there. (WEP key isn't one of those... that's per-network not per network-device and shouldn't be in the device configuration at all; I think NetworkManager handles it correctly.) Regards, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kyrre at solution-forge.net Tue Jan 4 17:23:49 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 04 Jan 2005 18:23:49 +0100 Subject: Trying to build the adm8211 kernel module In-Reply-To: <604aa791050104085365e89b62@mail.gmail.com> References: <1104856064.7207.14.camel@localhost.localdomain> <604aa79105010408516b408c51@mail.gmail.com> <604aa791050104085365e89b62@mail.gmail.com> Message-ID: <1104859428.7207.17.camel@localhost.localdomain> tir, 04.01.2005 kl. 17.53 skrev Jeff Spaleta: > On Tue, 4 Jan 2005 11:51:38 -0500, Jeff Spaleta wrote: > > Uhm..... adm8211-20041227.tar.bz2 on my fc2 and fc3 system without a > > kernel-source(code) rpm installed works just fine. The make file in > > the 20041222 has the correct > > oops... that should read as adm8211-20041222.tar.bz2 in the first > line. the 20041122 works > on fc2 and fc3 2.6.9 kernels. > > -jef Oh! That was fast! Thanks a lot :) I think i'll better mail the author of the driver - the doc says "2.6.9 minimum" - should be 2.6.10 minimum... But ill guess ill just use the older version then. BTW. anybody knows when the 2.6.10 kernel is due for fc? From walters at redhat.com Tue Jan 4 17:34:21 2005 From: walters at redhat.com (Colin Walters) Date: Tue, 04 Jan 2005 12:34:21 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050104050705.69694.qmail@web41501.mail.yahoo.com> References: <20050104050705.69694.qmail@web41501.mail.yahoo.com> Message-ID: <1104860062.7071.2.camel@nexus.verbum.private> On Mon, 2005-01-03 at 21:07 -0800, Roberto Peon wrote: > Disagreement. > > I have custom configuration for my audio card (custom alsa config), What do you configure? Or are you just working around bugs? > and my > video capture card (have to specify tuner and firmware location) as well. That just sounds like you're working around a bug. Doesn't it work to put the firmware in /lib/firmware? From fedora-devel at tlarson.com Tue Jan 4 18:01:20 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Tue, 04 Jan 2005 11:01:20 -0700 Subject: kernel 2.6.9-1.724_FC3 and gdb Message-ID: <41DAD9F0.3010309@tlarson.com> When attempting to debug any program while using the newest kernel (2.6.9-1.724) under FC3, I invariably get the following error immediately upon executing the program: warning: Child process unexpectedly missing: No child processes Program terminated with signal ?, Unknown signal. The program no longer exists. I'm no kernel hacker and have no idea where the problem might lie, or what package needs to be fixed. But I've tested this problem with the same result on two boxes with very different hardware configurations. Below is a transcript of replicating this problem, just in case there's some detail you can spot that I missed. -------------------------------------------------------------- [tylerl at tyler2 ~]$ cat >test.c< int main(int argc,char *argv[]) { > return 0; > } > END [tylerl at tyler2 ~]$ gcc -g test.c -o test [tylerl at tyler2 ~]$ gdb test GNU gdb Red Hat Linux (6.1post-1.20040607.43rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /home/tylerl/test warning: Child process unexpectedly missing: No child processes Program terminated with signal ?, Unknown signal. The program no longer exists. You can't do that without a process to debug. (gdb) From grmoc at yahoo.com Tue Jan 4 18:04:14 2005 From: grmoc at yahoo.com (Roberto Peon) Date: Tue, 4 Jan 2005 10:04:14 -0800 (PST) Subject: some changes for (slightly) faster boot In-Reply-To: <1104860062.7071.2.camel@nexus.verbum.private> Message-ID: <20050104180414.92173.qmail@web41506.mail.yahoo.com> I honestly don't remember what the alsa config does anymore, since it has been humming along nicely for a while now. The capture card came out with a new tuner, and the module authors took a bit to get autodetecting support for it into the module. The firmware comes from a different party (i.e. the hardware manufacturer who doesn't provide a linux driver-- suprise suprise), and so I have an init-script extract it from the latest available driver (i.e. out of an self-extracting (win32) archive). Since I tend towards the bleeding edge of hardware and software, working around bugs is just something I often do. -Roberto JP --- Colin Walters wrote: > On Mon, 2005-01-03 at 21:07 -0800, Roberto Peon wrote: > > Disagreement. > > > > I have custom configuration for my audio card (custom alsa config), > > What do you configure? Or are you just working around bugs? > > > and my > > video capture card (have to specify tuner and firmware location) as well. > > That just sounds like you're working around a bug. Doesn't it work to > put the firmware in /lib/firmware? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From balay at fastmail.fm Tue Jan 4 18:14:47 2005 From: balay at fastmail.fm (Satish Balay) Date: Tue, 4 Jan 2005 12:14:47 -0600 (CST) Subject: kernel 2.6.9-1.724_FC3 and gdb In-Reply-To: <41DAD9F0.3010309@tlarson.com> References: <41DAD9F0.3010309@tlarson.com> Message-ID: On Tue, 4 Jan 2005, Tyler Larson wrote: > When attempting to debug any program while using the newest kernel > (2.6.9-1.724) under FC3, I invariably get the following error > immediately upon executing the program: > warning: Child process unexpectedly missing: No child processes > Program terminated with signal ?, Unknown signal. > The program no longer exists. https://bugzilla.redhat.com/beta/show_bug.cgi?id=144021 Also check: https://bugzilla.redhat.com/beta/show_bug.cgi?id=144070 Satish From pbruna at linuxcenterla.com Tue Jan 4 18:28:25 2005 From: pbruna at linuxcenterla.com (Patricio Bruna V) Date: Tue, 04 Jan 2005 15:28:25 -0300 Subject: soundcard access Message-ID: <1104863305.2732.8.camel@p.linuxcenter.cl> hi, i have the following trouble. My apps can't access the soundcard at the same time. I guess its probably because my soundcard does not have this hw avility. So i look and do some research on the subject and find dmix, but i need to configure the apps to use it. So the question is, can i enable this software based option globally for the system? PS: Im posting here because im using fedora-devel, and i'm think this ist an important feature. -- Patricio Bruna http://www.linuxcenterla.com Ingeniero de Proyectos Mariano S?nchez Fontecilla 310 Red Hat Certified Engineer Las Condes, Santiago - CHILE Linux Center Latinoamerica Fono: 2745000 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From walters at redhat.com Tue Jan 4 18:21:38 2005 From: walters at redhat.com (Colin Walters) Date: Tue, 04 Jan 2005 13:21:38 -0500 Subject: soundcard access In-Reply-To: <1104863305.2732.8.camel@p.linuxcenter.cl> References: <1104863305.2732.8.camel@p.linuxcenter.cl> Message-ID: <1104862898.21468.25.camel@nexus.verbum.private> On Tue, 2005-01-04 at 15:28 -0300, Patricio Bruna V wrote: > hi, > i have the following trouble. My apps can't access the soundcard at > the same time. I guess its probably because my soundcard does not have > this hw avility. So i look and do some research on the subject and find > dmix, but i need to configure the apps to use it. > > So the question is, can i enable this software based option globally for > the system? Basically our OS is broken, you don't want an option to unbreak it. You want it to work automatically. > PS: Im posting here because im using fedora-devel, and i'm think this > ist an important feature. It is a very important bug to fix, I agree. Here's the Bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130593 I hope to get some time soon to work on it. From alan at redhat.com Tue Jan 4 19:47:21 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 4 Jan 2005 14:47:21 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104858300.4316.9.camel@localhost.localdomain> References: <20050103225709.GA23700@nostromo.devel.redhat.com> <200501032336.j03NaruY023023@magilla.sf.frob.com> <20050104000202.GA29062@devserv.devel.redhat.com> <1104858300.4316.9.camel@localhost.localdomain> Message-ID: <20050104194721.GA26181@devserv.devel.redhat.com> On Tue, Jan 04, 2005 at 12:05:00PM -0500, Owen Taylor wrote: > But you can't possibly believe that this is the right behavior??? To > have to manually interact with the startup every time to keep it from > deleting useful information? Its definitely not right, it needs to keep the stuff. > If there is information that needs to be kept around per-device, then it > should be stored keyed to the device even when the device isn't there. Agreed. That would clean up a lot of the mess I see. > (WEP key isn't one of those... that's per-network not per network-device > and shouldn't > be in the device configuration at all; I think NetworkManager handles it > correctly.) Except when it isn't. Think about wireless in docking stations, wireless USB ports in hotels .. From mike at navi.cx Tue Jan 4 19:58:44 2005 From: mike at navi.cx (Mike Hearn) Date: Tue, 04 Jan 2005 19:58:44 +0000 Subject: soundcard access References: <1104863305.2732.8.camel@p.linuxcenter.cl> <1104862898.21468.25.camel@nexus.verbum.private> Message-ID: On Tue, 04 Jan 2005 13:21:38 -0500, Colin Walters wrote: > It is a very important bug to fix, I agree. Here's the Bugzilla: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130593 > > I hope to get some time soon to work on it. There are some serious bugs in the FC3 version of dmix/alsalib, a new version would need to be pulled from upstream and tested heavily before it can be enabled for everyone IMHO. It also leaves the problem of what to do about apps that don't use alsalib. There is an "aoss" wrapper but the user has to know to use it, which isn't very user friendly. That's a variation on a theme though: we may need to develop some equivalent to the Windows shimming mechanism in the future, ugly as it is :/ I believe the ALSA guys are looking at how to enable kernel OSS emulation -> userspace routing actually so there may be hope here still. Final note is that it'd be wonderful if distro practice didn't splinter over this. Ubuntu seems to be leaning towards not using dmix and instead using polypaudio for everything. I don't really care what happens here as long as it's fairly consistent ... ie dmix + polypaudio would be fine by me :) thanks -mike From aoliva at redhat.com Tue Jan 4 19:54:26 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 04 Jan 2005 17:54:26 -0200 Subject: some changes for (slightly) faster boot In-Reply-To: <20050104034534.GA26184@nostromo.devel.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> Message-ID: On Jan 4, 2005, Bill Nottingham wrote: > Realistically, the only sort of device that has a lot of site-local > configuration is a network card; for most other things you don't care. Hmm, let's see... - Printer: probably want to keep customizations such as default page size, paper tray, etc - Mouse: emulate the middle button or not. - Keyboard: what's the key layout - Display: what depth, resolution to use - Hard disks: where to mount So what other kinds of devices whose local configurations didn't matter did you have in mind anyway? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From arjanv at redhat.com Tue Jan 4 19:59:56 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 04 Jan 2005 20:59:56 +0100 Subject: some changes for (slightly) faster boot In-Reply-To: <20050104194721.GA26181@devserv.devel.redhat.com> References: <20050103225709.GA23700@nostromo.devel.redhat.com> <200501032336.j03NaruY023023@magilla.sf.frob.com> <20050104000202.GA29062@devserv.devel.redhat.com> <1104858300.4316.9.camel@localhost.localdomain> <20050104194721.GA26181@devserv.devel.redhat.com> Message-ID: <1104868797.4215.38.camel@laptopd505.fenrus.org> > Except when it isn't. Think about wireless in docking stations, wireless USB > ports in hotels .. it's a per *network* (well ESSID I guess) property for sure. Not per card... I think the word "network" is a bit ambigious :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mike at navi.cx Tue Jan 4 20:01:08 2005 From: mike at navi.cx (Mike Hearn) Date: Tue, 04 Jan 2005 20:01:08 +0000 Subject: kernel 2.6.9-1.724_FC3 and gdb References: <41DAD9F0.3010309@tlarson.com> Message-ID: On Tue, 04 Jan 2005 11:01:20 -0700, Tyler Larson wrote: > I'm no kernel hacker and have no idea where the problem might lie, > or what package needs to be fixed. But I've tested this problem with > the same result on two boxes with very different hardware configurations. I think it's the ptrace changes that have been going in lately. The kernel guys allowed ptrace to single-step into signal handlers, which broke Wine pretty badly and in the ensuing discussions a lot of different patches were tried. I'm not sure what is in upstream kernel right now but it should be sorted out soon enough. From notting at redhat.com Tue Jan 4 20:00:52 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 4 Jan 2005 15:00:52 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> Message-ID: <20050104200052.GA3327@nostromo.devel.redhat.com> Alexandre Oliva (aoliva at redhat.com) said: > > Realistically, the only sort of device that has a lot of site-local > > configuration is a network card; for most other things you don't care. > > Hmm, let's see... > > - Printer: probably want to keep customizations such as default page > size, paper tray, etc > > - Mouse: emulate the middle button or not. > > - Keyboard: what's the key layout > > - Display: what depth, resolution to use > > - Hard disks: where to mount > > > So what other kinds of devices whose local configurations didn't > matter did you have in mind anyway? Let me rephrase... 'local configuration that the tool currently touches'. Bill From Nicolas.Mailhot at laPoste.net Tue Jan 4 20:05:06 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 04 Jan 2005 21:05:06 +0100 Subject: some changes for (slightly) faster boot In-Reply-To: References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> Message-ID: <1104869106.2659.6.camel@rousalka.dyndns.org> Le mardi 04 janvier 2005 ? 17:54 -0200, Alexandre Oliva a ?crit : > On Jan 4, 2005, Bill Nottingham wrote: > > > Realistically, the only sort of device that has a lot of site-local > > configuration is a network card; for most other things you don't care. > > Hmm, let's see... > > - Printer: probably want to keep customizations such as default page > size, paper tray, etc resolution... > - Mouse: emulate the middle button or not. button order, acceleration... > - Keyboard: what's the key layout special keys... > - Display: what depth, resolution to use xinerama, tv-out... > - Hard disks: where to mount (or not) > So what other kinds of devices whose local configurations didn't > matter did you have in mind anyway? - Sound: output to use (analog or spdif) - Flash reader: where to mount, treat as ro or rw... (and that's about all the devices I own. I'm pretty sure if I bought another one I *would* find some user customization to save since I'm a compulsive tweaker) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fedora-devel at camperquake.de Tue Jan 4 20:09:20 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Tue, 4 Jan 2005 21:09:20 +0100 Subject: soundcard access In-Reply-To: References: <1104863305.2732.8.camel@p.linuxcenter.cl> <1104862898.21468.25.camel@nexus.verbum.private> Message-ID: <20050104210920.11a12753@nausicaa.camperquake.de> Hi. Mike Hearn wrote: > There are some serious bugs in the FC3 version of dmix/alsalib, a new > version would need to be pulled from upstream and tested heavily before > it can be enabled for everyone IMHO. Would some of these bugs explain crackling sound when the system becomes busy? Raw processor load does not trigger it, switching applications or scrolling in Mozilla/Firefox does... -- "The fact that the Web now allows you to realise anything your imagination can come up with, has simply served to highlight how many people were lacking in imagination in the first place." -- Nick Fitch From walters at redhat.com Tue Jan 4 20:11:36 2005 From: walters at redhat.com (Colin Walters) Date: Tue, 04 Jan 2005 15:11:36 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> Message-ID: <1104869496.21468.39.camel@nexus.verbum.private> On Tue, 2005-01-04 at 17:54 -0200, Alexandre Oliva wrote: > On Jan 4, 2005, Bill Nottingham wrote: > > > Realistically, the only sort of device that has a lot of site-local > > configuration is a network card; for most other things you don't care. > > Hmm, let's see... > > - Printer: probably want to keep customizations such as default page > size, paper tray, etc > > - Mouse: emulate the middle button or not. > > - Keyboard: what's the key layout > > - Display: what depth, resolution to use These all look like per-user preferences to me. So they should be stored in GConf. > - Hard disks: where to mount How do you configure this now? From skvidal at phy.duke.edu Tue Jan 4 20:17:23 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 04 Jan 2005 15:17:23 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104869496.21468.39.camel@nexus.verbum.private> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> Message-ID: <1104869843.32465.38.camel@opus.phy.duke.edu> > > > > - Display: what depth, resolution to use > > These all look like per-user preferences to me. So they should be > stored in GConf. not for the default X configuration. -sv From Nicolas.Mailhot at laPoste.net Tue Jan 4 20:36:55 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 04 Jan 2005 21:36:55 +0100 Subject: some changes for (slightly) faster boot In-Reply-To: <1104869496.21468.39.camel@nexus.verbum.private> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> Message-ID: <1104871015.2925.12.camel@rousalka.dyndns.org> Le mardi 04 janvier 2005 ? 15:11 -0500, Colin Walters a ?crit : > On Tue, 2005-01-04 at 17:54 -0200, Alexandre Oliva wrote: > > On Jan 4, 2005, Bill Nottingham wrote: > > > > > Realistically, the only sort of device that has a lot of site-local > > > configuration is a network card; for most other things you don't care. > > > > Hmm, let's see... > > > > - Printer: probably want to keep customizations such as default page > > size, paper tray, etc > > > > - Mouse: emulate the middle button or not. > > > > - Keyboard: what's the key layout > > > > - Display: what depth, resolution to use > > These all look like per-user preferences to me. So they should be > stored in GConf. Not all of them : - some printers accept extensions (memory, supplementary trays, duplexing unit...) that are not detectable and must be specified manually by the admin somewhere - mouse : physical setup (wheel...) will almost always be shared among users (even if modern devices make this less a problem than before) - keyboard : again different users may use different layouts but some characteristics like key number are shared Sure you can have every user redefine every single parameter - but even if users with different tastes do happen very frequently, the vast majority of cases will be users sharing the same customisations (because of the site/corporate policy, or there is only one computer-addict in the family, etc). This is BTW one of GConf biggest weaknesses right now - it's easy to change things on a per-user basis, but much less so on a per-system (or per-group) one, unless you want to dig into GConf internals and fight your distribution idea of what the defaults should be. > > - Hard disks: where to mount > > How do you configure this now? Crazy udev manual rules;) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dcbw at redhat.com Tue Jan 4 20:45:19 2005 From: dcbw at redhat.com (Dan Williams) Date: Tue, 04 Jan 2005 15:45:19 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050104194721.GA26181@devserv.devel.redhat.com> References: <20050103225709.GA23700@nostromo.devel.redhat.com> <200501032336.j03NaruY023023@magilla.sf.frob.com> <20050104000202.GA29062@devserv.devel.redhat.com> <1104858300.4316.9.camel@localhost.localdomain> <20050104194721.GA26181@devserv.devel.redhat.com> Message-ID: <1104871519.4822.1.camel@dcbw.boston.redhat.com> On Tue, 2005-01-04 at 14:47 -0500, Alan Cox wrote: > Except when it isn't. Think about wireless in docking stations, wireless USB > ports in hotels .. If the kernel recognizes it as a wireless device, and its exposed sanely in sysfs (*cough* PCMCIA-hates-sysfs-somebody-needs-to-integrate-adams- patches *cough*) then NetworkManager can use it without configuration. This is purely a kernel+driver+udev problem. Dan From katzj at redhat.com Tue Jan 4 20:45:19 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 04 Jan 2005 15:45:19 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104869843.32465.38.camel@opus.phy.duke.edu> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104869843.32465.38.camel@opus.phy.duke.edu> Message-ID: <1104871519.3010.28.camel@bree.local.net> On Tue, 2005-01-04 at 15:17 -0500, seth vidal wrote: > > > - Display: what depth, resolution to use > > > > These all look like per-user preferences to me. So they should be > > stored in GConf. > > not for the default X configuration. But if switching this stuff is easy (yes, I know you can't switch depths right now so this can't 100% apply), then why not have the default X configuration just be something sane given the monitor. ie, if it's a flat panel, you want the native resolution of the panel, otherwise you want just a basic resolution. It's not like logging in requires a lot of screen real estate. Jeremy From skvidal at phy.duke.edu Tue Jan 4 20:50:37 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 04 Jan 2005 15:50:37 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104871519.3010.28.camel@bree.local.net> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104869843.32465.38.camel@opus.phy.duke.edu> <1104871519.3010.28.camel@bree.local.net> Message-ID: <1104871837.32465.42.camel@opus.phy.duke.edu> > But if switching this stuff is easy (yes, I know you can't switch depths > right now so this can't 100% apply), then why not have the default X > configuration just be something sane given the monitor. ie, if it's a > flat panel, you want the native resolution of the panel, otherwise you > want just a basic resolution. It's not like logging in requires a lot > of screen real estate. > Only if you're not visually impaired, or don't want to change from the default session. native resolution on most lcds is way too small for folks with various eyesight problems. -sv From bclark at redhat.com Tue Jan 4 21:01:40 2005 From: bclark at redhat.com (Bryan Clark) Date: Tue, 04 Jan 2005 16:01:40 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104871015.2925.12.camel@rousalka.dyndns.org> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104871015.2925.12.camel@rousalka.dyndns.org> Message-ID: <1104872500.4078.2.camel@rhbw.boston.redhat.com> Your logic across all of this weighs on the fact that it is difficult for admins to setup defaults or for users to share defaults among machines. Say we were to change that problem, then these would all be per-user preferences again, yes? :-) Cheers, ~ Bryan On Tue, 2005-01-04 at 21:36 +0100, Nicolas Mailhot wrote: > > These all look like per-user preferences to me. So they should be > > stored in GConf. > > Not all of them : > > - some printers accept extensions (memory, supplementary trays, > duplexing unit...) that are not detectable and must be specified > manually by the admin somewhere > > - mouse : physical setup (wheel...) will almost always be shared among > users (even if modern devices make this less a problem than before) > > - keyboard : again different users may use different layouts but some > characteristics like key number are shared > > Sure you can have every user redefine every single parameter - but even > if users with different tastes do happen very frequently, the vast > majority of cases will be users sharing the same customisations (because > of the site/corporate policy, or there is only one computer-addict in > the family, etc). This is BTW one of GConf biggest weaknesses right now > - it's easy to change things on a per-user basis, but much less so on a > per-system (or per-group) one, unless you want to dig into GConf > internals and fight your distribution idea of what the defaults should > be. From alan at redhat.com Tue Jan 4 21:04:35 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 4 Jan 2005 16:04:35 -0500 Subject: soundcard access In-Reply-To: <20050104210920.11a12753@nausicaa.camperquake.de> References: <1104863305.2732.8.camel@p.linuxcenter.cl> <1104862898.21468.25.camel@nexus.verbum.private> <20050104210920.11a12753@nausicaa.camperquake.de> Message-ID: <20050104210435.GA6262@devserv.devel.redhat.com> On Tue, Jan 04, 2005 at 09:09:20PM +0100, Ralf Ertzinger wrote: > Would some of these bugs explain crackling sound when the system becomes > busy? Raw processor load does not trigger it, switching applications or > scrolling in Mozilla/Firefox does... What video ? From alan at redhat.com Tue Jan 4 21:08:30 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 4 Jan 2005 16:08:30 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104869496.21468.39.camel@nexus.verbum.private> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> Message-ID: <20050104210830.GB6262@devserv.devel.redhat.com> On Tue, Jan 04, 2005 at 03:11:36PM -0500, Colin Walters wrote: > > - Keyboard: what's the key layout > > > These all look like per-user preferences to me. So they should be > stored in GConf. So you don't believe people should be able to log in. Let me set your box to default to gdm with an azerty keyboard and left handed mouse and then see if you still think its a per user preference. Oh and perhaps with the video at a resolution your monitor can't handle. Lots of these are both system preferences and user ones with the user able to configure some properties or properties within a constraint set by the system (eg video mode). Alan From fedora-devel at camperquake.de Tue Jan 4 21:09:22 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Tue, 4 Jan 2005 22:09:22 +0100 Subject: soundcard access In-Reply-To: <20050104210435.GA6262@devserv.devel.redhat.com> References: <1104863305.2732.8.camel@p.linuxcenter.cl> <1104862898.21468.25.camel@nexus.verbum.private> <20050104210920.11a12753@nausicaa.camperquake.de> <20050104210435.GA6262@devserv.devel.redhat.com> Message-ID: <20050104220922.1b5d25eb@nausicaa.camperquake.de> Hi. Alan Cox wrote: > On Tue, Jan 04, 2005 at 09:09:20PM +0100, Ralf Ertzinger wrote: > > Would some of these bugs explain crackling sound when the system > > becomes busy? Raw processor load does not trigger it, switching > > applications or scrolling in Mozilla/Firefox does... > > What video ? nvidia gf2mx, agp port, on a VIA KT133A chipset, plain xorg drivers, system is running the latest rawhide. -- "Chocolatey space cadet reporting! Space support down to zero cocoa! ... feeling spacey ..." -- Cocoapuffs commercial From alan at redhat.com Tue Jan 4 21:14:51 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 4 Jan 2005 16:14:51 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104871519.3010.28.camel@bree.local.net> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104869843.32465.38.camel@opus.phy.duke.edu> <1104871519.3010.28.camel@bree.local.net> Message-ID: <20050104211451.GE6262@devserv.devel.redhat.com> On Tue, Jan 04, 2005 at 03:45:19PM -0500, Jeremy Katz wrote: > right now so this can't 100% apply), then why not have the default X > configuration just be something sane given the monitor. ie, if it's a > flat panel, you want the native resolution of the panel, otherwise you > want just a basic resolution. It's not like logging in requires a lot > of screen real estate. The only "safe" resolution without DDC is 640x480 at 60Hz 31.5Khz (ie VGA) unless it is a panel. gdm doesn't work at 640x480 in our setup (bugzilla'd about RH8, never fixed). (TV out is an exception but we don't really handle TV out sanely yet anyway so its not a revert) From walters at redhat.com Tue Jan 4 21:20:25 2005 From: walters at redhat.com (Colin Walters) Date: Tue, 04 Jan 2005 16:20:25 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050104210830.GB6262@devserv.devel.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <20050104210830.GB6262@devserv.devel.redhat.com> Message-ID: <1104873626.21468.56.camel@nexus.verbum.private> On Tue, 2005-01-04 at 16:08 -0500, Alan Cox wrote: > On Tue, Jan 04, 2005 at 03:11:36PM -0500, Colin Walters wrote: > > > - Keyboard: what's the key layout > > > > > These all look like per-user preferences to me. So they should be > > stored in GConf. > > So you don't believe people should be able to log in. Let me set your box > to default to gdm with an azerty keyboard and left handed mouse and then see > if you still think its a per user preference. I don't understand this; clearly if I have to use an azerty keyboard layout I'm screwed whether or not you set it on the system or just for my user. How is this different from you setting azerty as the default in the Xorg conf file? > Oh and perhaps with the video at a resolution your monitor can't handle. At least with modern monitors it's my understanding the X server knows what the monitor supports (DDC or something?). So the system could prevent a user from changing their preference to something invalid. Thus it becomes a preference rather than a setting. > Lots of these are both system preferences GConf does have an idea of a default preference. > and user ones with the user able > to configure some properties or properties within a constraint set by the > system (eg video mode). Sure, I agree the system should only accept valid input from the user. From alan at redhat.com Tue Jan 4 21:25:43 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 4 Jan 2005 16:25:43 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104872500.4078.2.camel@rhbw.boston.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104871015.2925.12.camel@rousalka.dyndns.org> <1104872500.4078.2.camel@rhbw.boston.redhat.com> Message-ID: <20050104212543.GI6262@devserv.devel.redhat.com> On Tue, Jan 04, 2005 at 04:01:40PM -0500, Bryan Clark wrote: > Your logic across all of this weighs on the fact that it is difficult > for admins to setup defaults or for users to share defaults among > machines. Say we were to change that problem, then these would all be > per-user preferences again, yes? :-) per-user per-system in some cases. I use the same /home from US and UK keyboards and 3 different display sizes. I'm sure that isn't too unusual From david at fubar.dk Tue Jan 4 21:42:47 2005 From: david at fubar.dk (David Zeuthen) Date: Tue, 04 Jan 2005 16:42:47 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050104034534.GA26184@nostromo.devel.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> Message-ID: <1104874967.12415.22.camel@daxter.boston.redhat.com> On Mon, 2005-01-03 at 22:45 -0500, Bill Nottingham wrote: > Hence, where we're probably going to end up is that kudzu will, at > most, handle things like modprobe.conf aliases for networking; And when user space can finally control driver binding / per-device driver options we can go ahead and kill that cruft which is modprobe.conf and aliases. The way it works today, with the kernel automatically binding drivers, is in my view rather flawed. It even looks like people are working on this http://lkml.org/lkml/2004/11/9/330 David From katzj at redhat.com Tue Jan 4 21:41:44 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 04 Jan 2005 16:41:44 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050104211451.GE6262@devserv.devel.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104869843.32465.38.camel@opus.phy.duke.edu> <1104871519.3010.28.camel@bree.local.net> <20050104211451.GE6262@devserv.devel.redhat.com> Message-ID: <1104874904.3010.31.camel@bree.local.net> On Tue, 2005-01-04 at 16:14 -0500, Alan Cox wrote: > On Tue, Jan 04, 2005 at 03:45:19PM -0500, Jeremy Katz wrote: > > right now so this can't 100% apply), then why not have the default X > > configuration just be something sane given the monitor. ie, if it's a > > flat panel, you want the native resolution of the panel, otherwise you > > want just a basic resolution. It's not like logging in requires a lot > > of screen real estate. > > The only "safe" resolution without DDC is 640x480 at 60Hz 31.5Khz (ie VGA) > unless it is a panel. gdm doesn't work at 640x480 in our setup (bugzilla'd > about RH8, never fixed). (TV out is an exception but we don't really handle > TV out sanely yet anyway so its not a revert) One nice thing about having X set the defaults is that (in general) the X drivers know the card-specific probing routines for what monitor is attached and so we don't have to rely on the admittedly crappy information you can get with real mode monitor probing. And then a lot more becomes "safe" Jeremy From alan at redhat.com Tue Jan 4 21:56:14 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 4 Jan 2005 16:56:14 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104873626.21468.56.camel@nexus.verbum.private> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <20050104210830.GB6262@devserv.devel.redhat.com> <1104873626.21468.56.camel@nexus.verbum.private> Message-ID: <20050104215614.GN6262@devserv.devel.redhat.com> On Tue, Jan 04, 2005 at 04:20:25PM -0500, Colin Walters wrote: > I don't understand this; clearly if I have to use an azerty keyboard > layout I'm screwed whether or not you set it on the system or just for > my user. How is this different from you setting azerty as the default > in the Xorg conf file? It proves that keyboard is a system setting. > > Oh and perhaps with the video at a resolution your monitor can't handle. > > At least with modern monitors it's my understanding the X server knows > what the monitor supports (DDC or something?). So the system could > prevent a user from changing their preference to something invalid. > Thus it becomes a preference rather than a setting. It remains a system setting (or the range does), and that needs to be kept by Kudzu attached to the hardware even when the hardware vanishes for a while. From notting at redhat.com Tue Jan 4 23:01:49 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 4 Jan 2005 18:01:49 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104874967.12415.22.camel@daxter.boston.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104874967.12415.22.camel@daxter.boston.redhat.com> Message-ID: <20050104230149.GD18254@nostromo.devel.redhat.com> David Zeuthen (david at fubar.dk) said: > It even looks like people are working on this > > http://lkml.org/lkml/2004/11/9/330 This is fundamentally uninteresting without userspace policy support. Of course, foisting complication on userspace from the kernel seems to be the way to go these days, judging by udev. :) Bill From max_list at fedorafaq.org Tue Jan 4 23:06:51 2005 From: max_list at fedorafaq.org (Max Kanat-Alexander) Date: Tue, 04 Jan 2005 15:06:51 -0800 Subject: soundcard access In-Reply-To: <20050104220922.1b5d25eb@nausicaa.camperquake.de> References: <1104863305.2732.8.camel@p.linuxcenter.cl> <1104862898.21468.25.camel@nexus.verbum.private> <20050104210920.11a12753@nausicaa.camperquake.de> <20050104210435.GA6262@devserv.devel.redhat.com> <20050104220922.1b5d25eb@nausicaa.camperquake.de> Message-ID: <1104880012.3866.7.camel@max.localdomain> On Tue, 2005-01-04 at 22:09 +0100, Ralf Ertzinger wrote: > > On Tue, Jan 04, 2005 at 09:09:20PM +0100, Ralf Ertzinger wrote: > > > Would some of these bugs explain crackling sound when the system > > > becomes busy? Raw processor load does not trigger it, switching > > > applications or scrolling in Mozilla/Firefox does... > > > > What video ? > > nvidia gf2mx, agp port, on a VIA KT133A chipset, I think that KT133A is your problem. I have a KT133, and they have a famous interrupt problem. That is, at least with my M-Audio Delta 44, unless I set the PCI Latency to 0 and turn off PCI Delayed Transaction in the BIOS, I get crackle, crackle, crackle. And sometimes, even if I do all that, I still get the crackle. It happened in Windows 2000, too. -Max From dax at gurulabs.com Wed Jan 5 00:28:36 2005 From: dax at gurulabs.com (Dax Kelson) Date: Tue, 04 Jan 2005 17:28:36 -0700 Subject: some changes for (slightly) faster boot In-Reply-To: <1104858300.4316.9.camel@localhost.localdomain> References: <20050103225709.GA23700@nostromo.devel.redhat.com> <200501032336.j03NaruY023023@magilla.sf.frob.com> <20050104000202.GA29062@devserv.devel.redhat.com> <1104858300.4316.9.camel@localhost.localdomain> Message-ID: <1104884917.4519.10.camel@mentorng.gurulabs.com> On Tue, 2005-01-04 at 12:05 -0500, Owen Taylor wrote: > (WEP key isn't one of those... that's per-network not per network-device > and shouldn't > be in the device configuration at all; I think NetworkManager handles it > correctly.) Does NetworkManager handle non-ESSID broadcasting access points yet? When I last looked (awhile ago) it didn't, making it not usable for me. Dax From lux at diesel-research.com Wed Jan 5 00:32:57 2005 From: lux at diesel-research.com (Kim Lux) Date: Tue, 04 Jan 2005 17:32:57 -0700 Subject: Heads up: can't build ndiswrapper with kernel 2.6.9-1.724_FC3 Message-ID: <1104885177.4376.4.camel@localhost.localdomain> I can't run ndiswrapper-0.11 or -0.12 with the x.724 kernel. I get a warning during the build about "task_nice". It completes the build. When I try to start networking (/etc/ini.d/networking) I get an error concerning "task_nice". I've built ndiswrapper for lots of kernels without any problems. Is there a way to solve this problem without getting kernel source and manually fixing it ? (ie any chance of a -1.725 kernel to save a bunch of us a bunch of headaches ?) I'm not alone with this problem: http://ndiswrapper.sourceforge.net/forums/viewtopic.php?t=198 http://fedoraforum.org/forum/showthread.php?t=30416 -- Kim Lux, Diesel Research Inc. From alan at redhat.com Wed Jan 5 00:44:17 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 4 Jan 2005 19:44:17 -0500 Subject: Heads up: can't build ndiswrapper with kernel 2.6.9-1.724_FC3 In-Reply-To: <1104885177.4376.4.camel@localhost.localdomain> References: <1104885177.4376.4.camel@localhost.localdomain> Message-ID: <20050105004417.GA20133@devserv.devel.redhat.com> On Tue, Jan 04, 2005 at 05:32:57PM -0700, Kim Lux wrote: > Is there a way to solve this problem without getting kernel source and > manually fixing it ? (ie any chance of a -1.725 kernel to save a bunch > of us a bunch of headaches ?) The 2.6.10 kernel folks went systematically through a lot of exports and removed those not being used by in kernel code that were not obviously relevant. If they should be put back then it wants the ndiswrapper and other users to take it upstream From david at fubar.dk Wed Jan 5 00:59:34 2005 From: david at fubar.dk (David Zeuthen) Date: Tue, 04 Jan 2005 19:59:34 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050104230149.GD18254@nostromo.devel.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104874967.12415.22.camel@daxter.boston.redhat.com> <20050104230149.GD18254@nostromo.devel.redhat.com> Message-ID: <1104886775.4318.23.camel@daxter.boston.redhat.com> On Tue, 2005-01-04 at 18:01 -0500, Bill Nottingham wrote: > David Zeuthen (david at fubar.dk) said: > > It even looks like people are working on this > > > > http://lkml.org/lkml/2004/11/9/330 > > This is fundamentally uninteresting without userspace policy support. > Which is planned to be added upstream in hal - in a nutshell, what is needed for auto configuration of hardware is some mechanism to store configuration data about physical and logical devices in a persistent manner [1] accessible through a unified interface [2]. Once you have that, it's not really hard to replace existing or write new policy agents. > Of course, foisting complication on userspace from the kernel seems > to be the way to go these days, judging by udev. :) > Heh, actually one thing I like about udev is the fact that it made a lot of *existing* bugs and hacks like inserting "sleep 2" visible. Oh wait, Greg KH already explained this here http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0769.html and in surrounding messages :-) Cheers, David [1] : Including the ability to tie configuration to specific device instances, e.g. if a physical devices lacks a serial number we need to track the data by connection. [2] : Meaning that we shouldn't have 1000 different configuration files in various formats. With a unified interface it becomes almost trivial to write a "real" device manager, e.g. hal-device- manager just with real management, for example, "Select MAC Address", "Select Interface Name" or "Select Driver" buttons for configuring networking hardware. It's just a simple SetProperty() method call over D-BUS. From jon at jonshouse.co.uk Wed Jan 5 00:59:40 2005 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 05 Jan 2005 00:59:40 +0000 Subject: some changes for (slightly) faster boot In-Reply-To: <1104874904.3010.31.camel@bree.local.net> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104869843.32465.38.camel@opus.phy.duke.edu> <1104871519.3010.28.camel@bree.local.net> <20050104211451.GE6262@devserv.devel.redhat.com> <1104874904.3010.31.camel@bree.local.net> Message-ID: <1104886779.22117.4.camel@jonspc> On Tue, 2005-01-04 at 21:41, Jeremy Katz wrote: > On Tue, 2005-01-04 at 16:14 -0500, Alan Cox wrote: > > On Tue, Jan 04, 2005 at 03:45:19PM -0500, Jeremy Katz wrote: > > > right now so this can't 100% apply), then why not have the default X > > > configuration just be something sane given the monitor. ie, if it's a > > > flat panel, you want the native resolution of the panel, otherwise you > > > want just a basic resolution. It's not like logging in requires a lot > > > of screen real estate. > > > > The only "safe" resolution without DDC is 640x480 at 60Hz 31.5Khz (ie VGA) > > unless it is a panel. gdm doesn't work at 640x480 in our setup (bugzilla'd > > about RH8, never fixed). (TV out is an exception but we don't really handle > > TV out sanely yet anyway so its not a revert) ^^ I would just like to stick my foot in and say that redhat break TV-out installs on most hardware with "setsysfont". This seems to render most ATI based cards black in way that even starting X doesnt recover from. Anyone know if this is fixed in core3 ? Thanks, Jon From alan at redhat.com Wed Jan 5 01:05:43 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 4 Jan 2005 20:05:43 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104886779.22117.4.camel@jonspc> References: <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104869843.32465.38.camel@opus.phy.duke.edu> <1104871519.3010.28.camel@bree.local.net> <20050104211451.GE6262@devserv.devel.redhat.com> <1104874904.3010.31.camel@bree.local.net> <1104886779.22117.4.camel@jonspc> Message-ID: <20050105010543.GA28145@devserv.devel.redhat.com> On Wed, Jan 05, 2005 at 12:59:40AM +0000, Jonathan Andrews wrote: > ^^ I would just like to stick my foot in and say that redhat break > TV-out installs on most hardware with "setsysfont". This seems to render > most ATI based cards black in way that even starting X doesnt recover > from. New one on me - is this in bugzilla ? From jon at jonshouse.co.uk Wed Jan 5 01:35:18 2005 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 05 Jan 2005 01:35:18 +0000 Subject: some changes for (slightly) faster boot In-Reply-To: <20050105010543.GA28145@devserv.devel.redhat.com> References: <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104869843.32465.38.camel@opus.phy.duke.edu> <1104871519.3010.28.camel@bree.local.net> <20050104211451.GE6262@devserv.devel.redhat.com> <1104874904.3010.31.camel@bree.local.net> <1104886779.22117.4.camel@jonspc> <20050105010543.GA28145@devserv.devel.redhat.com> Message-ID: <1104888917.22117.36.camel@jonspc> On Wed, 2005-01-05 at 01:05, Alan Cox wrote: > On Wed, Jan 05, 2005 at 12:59:40AM +0000, Jonathan Andrews wrote: > > ^^ I would just like to stick my foot in and say that redhat break > > TV-out installs on most hardware with "setsysfont". This seems to render > > most ATI based cards black in way that even starting X doesnt recover > > from. > > New one on me - is this in bugzilla ? I cant find in fedora bugzilla - but I also cant find much reference to setsysfont. I mentioned it on a developers list about a year ago and was told no simple work around was possible, but ive long since lost/forgotten the details. "setsysfont" is part of what component ? Its easy to reproduce, stick any TV out ATI card in a machine, connect the TV output only (the ATI card defaults to TV only in this case) then boot the CD .... The kernel comes up all nice then goes black early on during startup. I had problems with the epia machines and TV out in the same way, its easy to fix on an installed copy by commenting setsysfont out - but less easy to work around with the installers ! Annoyingly even the text install runs setsysfont :-( Its a shame, because other than this issue the fb mode works fine with tv out, you could say I watch X on the telly ;-) Jon From alan at redhat.com Wed Jan 5 01:39:06 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 4 Jan 2005 20:39:06 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104888917.22117.36.camel@jonspc> References: <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104869843.32465.38.camel@opus.phy.duke.edu> <1104871519.3010.28.camel@bree.local.net> <20050104211451.GE6262@devserv.devel.redhat.com> <1104874904.3010.31.camel@bree.local.net> <1104886779.22117.4.camel@jonspc> <20050105010543.GA28145@devserv.devel.redhat.com> <1104888917.22117.36.camel@jonspc> Message-ID: <20050105013906.GA5281@devserv.devel.redhat.com> On Wed, Jan 05, 2005 at 01:35:18AM +0000, Jonathan Andrews wrote: > "setsysfont" is part of what component ? rpm -qf /sbin/setsysfont (initscripts) From jon at jonshouse.co.uk Wed Jan 5 01:49:53 2005 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 05 Jan 2005 01:49:53 +0000 Subject: some changes for (slightly) faster boot In-Reply-To: <20050105013906.GA5281@devserv.devel.redhat.com> References: <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104869843.32465.38.camel@opus.phy.duke.edu> <1104871519.3010.28.camel@bree.local.net> <20050104211451.GE6262@devserv.devel.redhat.com> <1104874904.3010.31.camel@bree.local.net> <1104886779.22117.4.camel@jonspc> <20050105010543.GA28145@devserv.devel.redhat.com> <1104888917.22117.36.camel@jonspc> <20050105013906.GA5281@devserv.devel.redhat.com> Message-ID: <1104889793.22117.38.camel@jonspc> On Wed, 2005-01-05 at 01:39, Alan Cox wrote: > On Wed, Jan 05, 2005 at 01:35:18AM +0000, Jonathan Andrews wrote: > > "setsysfont" is part of what component ? > > rpm -qf /sbin/setsysfont > > (initscripts) Ta! https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144206 From rahulsundaram at yahoo.co.in Wed Jan 5 00:59:11 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Tue, 4 Jan 2005 16:59:11 -0800 (PST) Subject: some changes for (slightly) faster boot In-Reply-To: <20050104230149.GD18254@nostromo.devel.redhat.com> Message-ID: <20050105005911.49255.qmail@web8507.mail.in.yahoo.com> Hi > Of course, foisting complication on userspace from > the kernel seems > to be the way to go these days, judging by udev. :) well, the alternative called devfs in the kernel see,s to be totally broken and unmaintained. ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 From pboy at barkhof.uni-bremen.de Wed Jan 5 02:01:03 2005 From: pboy at barkhof.uni-bremen.de (Peter Boy) Date: Wed, 05 Jan 2005 03:01:03 +0100 Subject: 4G/4G kernel patch dropped In-Reply-To: <1104841492.4215.29.camel@laptopd505.fenrus.org> References: <1460C4B716A20B689FE0BD75@[10.0.0.4]> <1104841492.4215.29.camel@laptopd505.fenrus.org> Message-ID: <1104890463.13268.3.camel@littlePiet> Am Dienstag, den 04.01.2005, 13:24 +0100 schrieb Arjan van de Ven: > On Tue, 2005-01-04 at 04:11 -0800, Kenneth Porter wrote: > > A bit of googling indicates that the 4G:4G patch is needed for systems with > > a lot of RAM (eg. 32 GB or more) > > and for people with less ram but who want to run java with lots of > threads... in that case you care a lot about the extra 1Gb of userspace > address space. Even with a moderate amount of threads this makes the > java garbage collector run less frequently -> nicer performance ;) Well, remains the question, why the 4G:4G patch has been dropped now. Would be quite interesting to know (after all the pain that patch caused in some circumstances but which are mostly resolved now) Peter From notting at redhat.com Wed Jan 5 02:58:43 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 4 Jan 2005 21:58:43 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104886775.4318.23.camel@daxter.boston.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104874967.12415.22.camel@daxter.boston.redhat.com> <20050104230149.GD18254@nostromo.devel.redhat.com> <1104886775.4318.23.camel@daxter.boston.redhat.com> Message-ID: <20050105025843.GA22419@nostromo.devel.redhat.com> David Zeuthen (david at fubar.dk) said: > Which is planned to be added upstream in hal - in a nutshell, what is > needed for auto configuration of hardware is some mechanism to store > configuration data about physical and logical devices in a persistent > manner [1] accessible through a unified interface [2]. Once you have > that, it's not really hard to replace existing or write new policy > agents. A good chunk of this is per-system, not per device. The main purpose of most of the aliases these days is to enforce some sort of reasonable ordering, which is needed in lieu of persistent device naming [1]. Realistically, all the aliases written by kudzu these days are for is: a) enforcing ordering among scsi devices b) enforcing ordering among sound devices c) allowing network devices to be brought up if the driver isn't already loaded (which usually means it's been manually removed) d) parport_serial (its own weirdness) e) allowing video devices to be loaded on demand c) and e) could conceivably go away right now. If you're looking per-device, you can add this sort of ordering/indexing there, but I'm not sure that's the most efficent. > > Of course, foisting complication on userspace from the kernel seems > > to be the way to go these days, judging by udev. :) > > > > Heh, actually one thing I like about udev is the fact that it made > a lot of *existing* bugs and hacks like inserting "sleep 2" visible. > Oh wait, Greg KH already explained this here > > http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0769.html > > and in surrounding messages :-) Oh my goodness. OK, first. 'sleep 2'? Part of the udev stack still is userspace busy waiting on the kernel. It's not making the hack more visible, it's just moving it somewhere else. That's the majority of what udev does... it just merely moves all the races and oddness to userspace. It's a case of the kernel saying 'here, I don't want to deal with these problems, I'm going to break your access model based on the deficiences of some buses, have fun reorienting to fix it.' And then leaves userspace to clean up the mess. For example, because of the wonders of udev: - Take the example of a sound card. You want to restore the volume on startup. Under previous configurations, you needed to know the name of the command to restore sound. You then added it to modules.conf. Under udev you need to create a dev.d script to run, which means: - your script needs to know the sysfs layout of the device, which of course never changes (to avoid running extraneously) - because you never get a 'this driver is done creating devices' signal, you need to either a) sleep a random amount of time b) run the restore command multiple times Repeat this scenario for other devices. How is this progress? - Say an app wants to use some sort of random device, not really tied to a piece of hardware. Under previous configurations, they opened the device, and either got ENODEV, or continued successfully. [2] Under udev, either: a) it works. This means that the driver has been loaded and udev has already run, hopefully. This means that some other process: - has loaded all the device modules. Ergo, every user has floppy, loop, nvram, etc loaded in nonswappable kernel memory. - has made random device nodes for them and trusted that kmod works. So, what exactly was the point of a dynamic /dev then? b) it fails with -ENOENT Hopefully, that means there's no device. But if someone decided to remove a module like nvram earlier...? Then the *app* needs to know what driver to load, and create its own dev.d script to notify itself that the device is ready. I'm sure there can be more examples. It's true that there are many classes of devices that require an asynchronous framework to work correctly. I'm not convinced that adding the same handicaps to all the device types, Harrison Bergeron-style, is a well thought out design. It's akin to making apps that use dlopen() or apps that link library dependencies parse text files for every link libraries because some platforms' linkers are deficient. Bill [1] Yes, I've seen the examples in udev or the stuff proposed by OSDL. Next joke. [2] Yeah, I know the device name can change with udev. Doesn't solve this aspect without patching your apps either..... From alan at redhat.com Wed Jan 5 03:03:49 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 4 Jan 2005 22:03:49 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050105025843.GA22419@nostromo.devel.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104874967.12415.22.camel@daxter.boston.redhat.com> <20050104230149.GD18254@nostromo.devel.redhat.com> <1104886775.4318.23.camel@daxter.boston.redhat.com> <20050105025843.GA22419@nostromo.devel.redhat.com> Message-ID: <20050105030349.GA31726@devserv.devel.redhat.com> On Tue, Jan 04, 2005 at 09:58:43PM -0500, Bill Nottingham wrote: > - because you never get a 'this driver is done creating devices' > signal, you need to either > a) sleep a random amount of time > b) run the restore command multiple times A driver is never done, this is hotplug. I can plug in USB audio any time I like. Now what could be done if this would help (you tell me as guru of initscripting) is to tell the userspace "the initial device enumeration is done". In fact in most cases this would be in the standard pci_foo code. > - has made random device nodes for them and trusted > that kmod works. So, what exactly was the point of a dynamic > /dev then? Nobody in the kernel world ever thought of udev as a "solely dynamic" world to my knowledge but as a partially dynamic one. > [1] Yes, I've seen the examples in udev or the stuff proposed by > OSDL. Next joke. Propose a "Carrier grade udev" project ;) Alan From hp at redhat.com Wed Jan 5 03:38:31 2005 From: hp at redhat.com (Havoc Pennington) Date: Tue, 04 Jan 2005 22:38:31 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050104212543.GI6262@devserv.devel.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104871015.2925.12.camel@rousalka.dyndns.org> <1104872500.4078.2.camel@rhbw.boston.redhat.com> <20050104212543.GI6262@devserv.devel.redhat.com> Message-ID: <1104896312.30868.8.camel@localhost.localdomain> On Tue, 2005-01-04 at 16:25 -0500, Alan Cox wrote: > On Tue, Jan 04, 2005 at 04:01:40PM -0500, Bryan Clark wrote: > > Your logic across all of this weighs on the fact that it is difficult > > for admins to setup defaults or for users to share defaults among > > machines. Say we were to change that problem, then these would all be > > per-user preferences again, yes? :-) > > per-user per-system in some cases. I use the same /home from US and UK > keyboards and 3 different display sizes. I'm sure that isn't too unusual > You can actually convince gconf to deal with that (if you want to go command line) by adding a ~/.gconf., setting systemid in some env variable, adding ~/.gconf.path to include ~/.gconf.$(ENV_) A bit hacky but it does the job. I don't really have a clue how we'd expose this in the GUI, anyhow, other than just automatically saving things keyed by screen size or other hardware attributes. Havoc From notting at redhat.com Wed Jan 5 03:46:40 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 4 Jan 2005 22:46:40 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050105030349.GA31726@devserv.devel.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104874967.12415.22.camel@daxter.boston.redhat.com> <20050104230149.GD18254@nostromo.devel.redhat.com> <1104886775.4318.23.camel@daxter.boston.redhat.com> <20050105025843.GA22419@nostromo.devel.redhat.com> <20050105030349.GA31726@devserv.devel.redhat.com> Message-ID: <20050105034640.GA24566@nostromo.devel.redhat.com> Alan Cox (alan at redhat.com) said: > On Tue, Jan 04, 2005 at 09:58:43PM -0500, Bill Nottingham wrote: > > - because you never get a 'this driver is done creating devices' > > signal, you need to either > > a) sleep a random amount of time > > b) run the restore command multiple times > > A driver is never done, this is hotplug. I can plug in USB audio any time I > like. Now what could be done if this would help (you tell me as guru of > initscripting) is to tell the userspace "the initial device enumeration > is done". In fact in most cases this would be in the standard pci_foo code. Basically, for any ALSA driver, it creates various device nodes; control nodes, PCM nodes, etc. These device nodes appear to be created in a different order depending on the driver (or perhaps the udev events are getting reordered). While the device you use to set the mixer is the control device, the device isn't actually available until some point later after various other device nodes are created. So, some sort of "i'm done with device nodes for this one physical device" signal would be nice. > > - has made random device nodes for them and trusted > > that kmod works. So, what exactly was the point of a dynamic > > /dev then? > > Nobody in the kernel world ever thought of udev as a "solely dynamic" world > to my knowledge but as a partially dynamic one. I've seen rumblings that kmod was slated for removal, though, which means that the only other option would be to load all non-physical devices unilaterally. This seems subpar. Bill From hp at redhat.com Wed Jan 5 03:47:58 2005 From: hp at redhat.com (Havoc Pennington) Date: Tue, 04 Jan 2005 22:47:58 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104871015.2925.12.camel@rousalka.dyndns.org> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104871015.2925.12.camel@rousalka.dyndns.org> Message-ID: <1104896878.30868.17.camel@localhost.localdomain> On Tue, 2005-01-04 at 21:36 +0100, Nicolas Mailhot wrote: > Sure you can have every user redefine every single parameter - but even > if users with different tastes do happen very frequently, the vast > majority of cases will be users sharing the same customisations (because > of the site/corporate policy, or there is only one computer-addict in > the family, etc). This is BTW one of GConf biggest weaknesses right now > - it's easy to change things on a per-user basis, but much less so on a > per-system (or per-group) one, unless you want to dig into GConf > internals and fight your distribution idea of what the defaults should > be. You shouldn't have to fight the distribution if you do it properly (granted "properly" isn't necessarily obvious); the distribution defaults are in the schemas and the site-local defaults should be set as the values themselves. There are plans to make it simpler: http://www.gnome.org/projects/gconf/plans.html but I believe it works fine now once you figure it out. To set a default do something like: gconftool-2 --direct --config-source=xml:readwrite:/etc/gconf/gconf.xml.defaults --set /apps/metacity/general/reduced_resources true all users should then get reduced_resources=true by default and AFAIK Red Hat packages will never overwrite this. If you run gconf-editor as root and choose "New Defaults Window" and change stuff there, in principle that's the same as the above command line. Making this a bit worse, gnome-panel specifically (which I realize is the app most people want to set up defaults for) is harder than other apps. http://mail.gnome.org/archives/gconf-list/2003-December/msg00007.html http://mail.gnome.org/archives/gconf-list/2003-December/msg00012.html Havoc From rahulsundaram at yahoo.co.in Wed Jan 5 03:51:51 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Tue, 4 Jan 2005 19:51:51 -0800 (PST) Subject: some changes for (slightly) faster boot In-Reply-To: <1104896878.30868.17.camel@localhost.localdomain> Message-ID: <20050105035151.9688.qmail@web8502.mail.in.yahoo.com> Hi > There are plans to make it simpler: > http://www.gnome.org/projects/gconf/plans.html > but I believe it works fine now once you figure it > out. I see you throw up that link on many discussions related to gconf but is someone working on that or plans to? I have also heard discussions about a fd.o system to replace this one (newconf?). has there been any progress in that front ? ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? All your favorites on one personal page ? Try My Yahoo! http://my.yahoo.com From hp at redhat.com Wed Jan 5 04:07:43 2005 From: hp at redhat.com (Havoc Pennington) Date: Tue, 04 Jan 2005 23:07:43 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050104210830.GB6262@devserv.devel.redhat.com> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <20050104210830.GB6262@devserv.devel.redhat.com> Message-ID: <1104898063.30868.29.camel@localhost.localdomain> On Tue, 2005-01-04 at 16:08 -0500, Alan Cox wrote: > > Lots of these are both system preferences and user ones with the user able > to configure some properties or properties within a constraint set by the > system (eg video mode). Keep in mind that "user preference" implies a search path (the default search path is: - systemwide mandatory - per-user - systemwide defaults - factory defaults) Normally we want the "driver layer" (in the sense of http://mail.gnome.org/archives/desktop-devel-list/2004-November/msg00693.html, i.e. the layer insulating apps from the specific hardware) to define the capabilities and constraints, and user preferences to choose something within those constraints. This can be confusing to think about because files like xorg.conf currently mix the two. But the difference is between setting up the available resolutions (and perhaps the autoguessed-best resolution for the current card-monitor pair); and choosing the current resolution from among those options. Within the "driver layer" you then want the merge from multiple data sources (querying the hardware itself, autodetection logic, factory/oem/local-site overrides) as we were discussing in the earlier branch of the thread. It's important to keep distinct these different *kinds* of configuration or preference. They aren't the same thing. In effect, the historical situation with the X config file was that you had to change your video driver to only export one resolution and then the display would use that resolution. With xrandr, we can export all possible resolutions from the driver, and then let users choose the one they want. Anyhow, so the overall situation is quite complex, as we have the chain of driver setup: hardware query -> vendor overrides -> oem overrides -> autoprobe logic -> site overrides -> whatever else and the chain of user prefs lookup: site defaults -> user's settings -> site mandatory Havoc From hp at redhat.com Wed Jan 5 04:10:32 2005 From: hp at redhat.com (Havoc Pennington) Date: Tue, 04 Jan 2005 23:10:32 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <20050105035151.9688.qmail@web8502.mail.in.yahoo.com> References: <20050105035151.9688.qmail@web8502.mail.in.yahoo.com> Message-ID: <1104898232.30868.31.camel@localhost.localdomain> On Tue, 2005-01-04 at 19:51 -0800, Rahul Sundaram wrote: > > I see you throw up that link on many discussions > related to gconf but is someone working on that or > plans to? Not that I know of. That's why I keep posting the link ;-) Someday someone will read it and say "oh, I should do that" > I have also heard discussions about a fd.o system to > replace this one > (newconf?). has there been any progress in that front ? D-BUS is moving along nicely, which would give you the basic building block. The "future gconf" described at the link I posted *should* be a fair bit easier to implement than current gconf is, and less code in the end. Havoc From rahulsundaram at yahoo.co.in Wed Jan 5 04:23:13 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Tue, 4 Jan 2005 20:23:13 -0800 (PST) Subject: FD.o subsystems (was:Re: some changes for (slightly) faster boot) In-Reply-To: <1104898232.30868.31.camel@localhost.localdomain> Message-ID: <20050105042313.79469.qmail@web8501.mail.in.yahoo.com> Hi > Not that I know of. That's why I keep posting the > link ;-) > Someday someone will read it and say "oh, I should > do that" I believe the current one is written by you. In that case you are probably the most suitable person to do it if you have the time.. > D-BUS is moving along nicely, which would give you > the basic building > block. I dont see how a more universal registry of settings is going to use an IPC mechanism as a building block. Would you please care to expand on that. is this future plan documented somewhere just like the gconf link :-). > The "future gconf" described at the link I posted > *should* be a fair bit > easier to implement than current gconf is, and less > code in the end. I guess that means you expect a complete rewrite. I believe a newer version of KDE and gnome which breaks binary compatibility is the crucial point to push thru fundamental sub systems like dbus and gstreamer for example. I would love to see a universal gconf like system being adopted by next major versions of the DE's Also useful would be a discussion to create a fd.o system as kparts/bonobo replacement. would dbus fit the basic needs here? Since KDE versions are released in sync with QT, the next major version of KDE is likely to be released before Gnome (QT 4 beta 1 has already been released) and hence this has to taken into consideration for all such discussions ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From hp at redhat.com Wed Jan 5 06:13:08 2005 From: hp at redhat.com (Havoc Pennington) Date: Wed, 05 Jan 2005 01:13:08 -0500 Subject: FD.o subsystems (was:Re: some changes for (slightly) faster boot) In-Reply-To: <20050105042313.79469.qmail@web8501.mail.in.yahoo.com> References: <20050105042313.79469.qmail@web8501.mail.in.yahoo.com> Message-ID: <1104905589.30868.137.camel@localhost.localdomain> On Tue, 2005-01-04 at 20:23 -0800, Rahul Sundaram wrote: > I believe the current one is written by you. In that > case you are probably the most suitable person to do > it if you have the time.. Sure, but I don't. ;-) Someone at Red Hat might eventually, but it just depends on the priority queue. > > D-BUS is moving along nicely, which would give you > > the basic building > > block. > > I dont see how a more universal registry of settings > is going to use an IPC mechanism as a building block. > Would you please care to expand on that. is this > future plan documented somewhere just like the gconf > link :-). It's at the gconf link, gconf is IPC-based. There are two basic parts to config system of the future in my view, one is a client library that manages schemas on the client side (loading fallbacks from them, locating the schema for a particular setting). The other is a daemon that provides the current settings, but has nothing to do with schemas. This removes the major reasons that gconfd is complicated internally and the major reasons that admins and programmers get confused about it. Also gets rid of the RPM %post scriptlets that run gconftool. In short we make schemas something that are dealt with transparently inside the prefs library by not having the idea of "installing" them. > > The "future gconf" described at the link I posted > > *should* be a fair bit > > easier to implement than current gconf is, and less > > code in the end. > > I guess that means you expect a complete rewrite. Maybe eventually but it's not strictly required in the short term; you could recycle a bunch of code from current gconf. In fact you may want to recycle the file format parsers so people don't lose their settings. Though the file format sucks, it most likely isn't worth fixing since nobody reads/writes it directly anyhow. > believe a newer version of KDE and gnome which breaks > binary compatibility is the crucial point to push thru > fundamental sub systems like dbus and gstreamer for > example. I would love to see a universal gconf like > system being adopted by next major versions of the > DE's You don't have to break ABI really since you can add a new ABI and keep but deprecate the old one. I'm not really optimistic that a config system spanning GNOME/KDE can be done; that's why I phrase the goal as writing a "shareable" config system. The reason is that KConfig and GConf are just a little bit too different. So to me it will be hard to get up-front agreement on what the system should be like, the only real possibility is to write a system that everyone could use in principle, and then let it compete de facto. > Also useful would be a discussion to create a fd.o > system as kparts/bonobo replacement. would dbus fit > the basic needs here? You have to separate three things: - IPC - component system - widget/control embedding A problem with Bonobo was trying to do all three of those at once and being fuzzy about the use cases for each one and how the three things are different. D-BUS is IPC only. Component systems look like they are going away in favor of plugin systems (as in Eclipse) and sufficiently powerful object systems (as in C#). You really want to be able to use multiple IPC systems (SOAP, D-BUS, XML-RPC, or whatever) depending on your needs, so you want to keep that orthogonal to the object/plugin system. Widget embedding is something we could implement over any IPC system, really the hard parts have nothing to do with the IPC system and everything to do with what you send over it. i.e. reconciling the semantics of Qt vs. GTK+ and what they expect from an embedded control. The more capabilities you have (such as menu merge) the more potential for semantic mismatch. Havoc From aoliva at redhat.com Wed Jan 5 06:54:05 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 05 Jan 2005 04:54:05 -0200 Subject: some changes for (slightly) faster boot In-Reply-To: <1104896312.30868.8.camel@localhost.localdomain> References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104871015.2925.12.camel@rousalka.dyndns.org> <1104872500.4078.2.camel@rhbw.boston.redhat.com> <20050104212543.GI6262@devserv.devel.redhat.com> <1104896312.30868.8.camel@localhost.localdomain> Message-ID: On Jan 5, 2005, Havoc Pennington wrote: > A bit hacky but it does the job. I don't really have a clue how we'd > expose this in the GUI, anyhow Let the user create desktop profiles, and do per-profile configurations? Then let the user choose which profile to use for a session, and remember the last profile used on a host and use that as default? For bonus points, introduce profile inheritance, and let the user choose in which point of the profile inheritance to store some specific setting. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From fedora-devel at camperquake.de Wed Jan 5 11:22:33 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Wed, 5 Jan 2005 12:22:33 +0100 Subject: soundcard access In-Reply-To: <1104880012.3866.7.camel@max.localdomain> References: <1104863305.2732.8.camel@p.linuxcenter.cl> <1104862898.21468.25.camel@nexus.verbum.private> <20050104210920.11a12753@nausicaa.camperquake.de> <20050104210435.GA6262@devserv.devel.redhat.com> <20050104220922.1b5d25eb@nausicaa.camperquake.de> <1104880012.3866.7.camel@max.localdomain> Message-ID: <20050105122233.689b4198@nausicaa.camperquake.de> Hi. Max Kanat-Alexander wrote: > I think that KT133A is your problem. I have a KT133, and they have > a famous interrupt problem. That is, at least with my M-Audio Delta 44, > unless I set the PCI Latency to 0 and turn off PCI Delayed Transaction > in the BIOS, I get crackle, crackle, crackle. Can these parameters be set from a running system in some way, or must this be done on powerup/reset? > And sometimes, even if I do all that, I still get the crackle. Yes, I had that too, with my SB16 (ISA! Yay!) under Win2k (and Linux), if the card was using 16bit DMA. 8bit DMA fixed that. The current card is an "Ensoniq 5880 AudioPCI" (Soundblaster 128 or something like that), and it worked just fine with win2k (while I had that), and with Linux, too, as long as the OSS drivers were used. ALSA inevitably starts to crackle after a while. -- The only substitute for good manners is fast reflexes. From remco at beryllium.net Wed Jan 5 11:54:31 2005 From: remco at beryllium.net (Remco Poelstra) Date: Wed, 05 Jan 2005 12:54:31 +0100 Subject: Using consolehelper/userhelper Message-ID: <41DBD577.2080309@beryllium.net> Hi, I asked the following question on fedora-list, but didn't receive an answer. I hope someone here can help me. I was looking for a system-install-packages sort of program that could resolve dependencies via yum. I couldn't find any, but since I believe Fedora/Redhat will provide one eventually, I thought of making a quick hack to get it done. I wrote a python script, which calls yum in a gnome-terminal. I then copied the configuration from system-install-packages. When I now run my program, all I get is a 'The password you typed is invalid. Please try again'. It didn't even ask me a password.... What did I do wrong? When I start system-install-packages, it works all perfect. So more info: -------------- $ ls -lh /usr/bin/ lrwxrwxrwx 1 root root 13 Jan 2 23:10 /usr/bin/system-install-packages -> consolehelper lrwxrwxrwx 1 root root 13 Jan 3 20:54 /usr/bin/uniXp-install-packages -> consolehelper -------------- $ ls -lh /usr/sbin/ -rwxr-xr-x 1 root root 83 Nov 15 18:29 /usr/sbin/system-install-packages -rwxr-xr-x 1 root root 233 Jan 4 00:16 /usr/sbin/uniXp-install-packages -------------- $ ls -lh /etc/security/console.apps/ -rw-r--r-- 1 root root 65 Nov 15 18:29 system-install-packages -rw-r--r-- 1 root root 64 Jan 3 20:50 uniXp-install-packages -------------- $ ls -lh /etc/pam.d/ -rw-r--r-- 1 root root 276 Nov 15 18:29 system-install-packages -rw-r--r-- 1 root root 276 Jan 3 20:50 uniXp-install-packages -------------- $ cat /usr/sbin/uniXp-install-packages #!/usr/bin/python import os os.execvp('gnome-terminal',['gnome-terminal','-x','sh','-c','yum install test; sleep 5']) -------------- Of course the script doesn't do anything usefull at the moment, but I like to get it working this way first.... Does anybody have any idea what I did wrong? Thanks in advance, Remco Poelstra From jnovy at redhat.com Wed Jan 5 12:29:41 2005 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 05 Jan 2005 13:29:41 +0100 Subject: Using consolehelper/userhelper In-Reply-To: <41DBD577.2080309@beryllium.net> References: <41DBD577.2080309@beryllium.net> Message-ID: <1104928181.3694.10.camel@obelix.redhat.usu> Hello Remco, On Wed, 2005-01-05 at 12:54 +0100, Remco Poelstra wrote: > Hi, > > I asked the following question on fedora-list, but didn't receive an > answer. I hope someone here can help me. > > I was looking for a system-install-packages sort of program that could > resolve dependencies via yum. I couldn't find any, but since I believe > Fedora/Redhat will provide one eventually, I thought of making a quick > hack to get it done. > I wrote a python script, which calls yum in a gnome-terminal. I then > copied the configuration from system-install-packages. When I now run my > program, all I get is a 'The password you typed is invalid. Please try > again'. It didn't even ask me a password.... > What did I do wrong? When I start system-install-packages, it works all > perfect. > So more info: > -------------- > $ ls -lh /usr/bin/ > lrwxrwxrwx 1 root root 13 Jan 2 23:10 /usr/bin/system-install-packages > -> consolehelper > lrwxrwxrwx 1 root root 13 Jan 3 20:54 /usr/bin/uniXp-install-packages > -> consolehelper Recent usermode has problems with uppercase characters in the name of executables, please try it with lowercase and it should solve your problem. I'll try to fix usermode to get rid of this issue. Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ From fedora-devel at camperquake.de Wed Jan 5 12:43:12 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Wed, 5 Jan 2005 13:43:12 +0100 Subject: soundcard access In-Reply-To: <20050105122233.689b4198@nausicaa.camperquake.de> References: <1104863305.2732.8.camel@p.linuxcenter.cl> <1104862898.21468.25.camel@nexus.verbum.private> <20050104210920.11a12753@nausicaa.camperquake.de> <20050104210435.GA6262@devserv.devel.redhat.com> <20050104220922.1b5d25eb@nausicaa.camperquake.de> <1104880012.3866.7.camel@max.localdomain> <20050105122233.689b4198@nausicaa.camperquake.de> Message-ID: <20050105134312.1b3e2207@nausicaa.camperquake.de> Hi. Ralf Ertzinger wrote: > Can these parameters be set from a running system in some way, or must > this be done on powerup/reset? Seems like you can. Anyway, I went into the BIOS and disabled "PCI delayed transactions". So far the sound card seems happy. If not I found this: http://www-106.ibm.com/developerworks/library/l-hw2.html Max, maybe this helps you. -- Confucius say, "A bird in hand makes hard to blow nose." From buildsys at redhat.com Wed Jan 5 13:02:57 2005 From: buildsys at redhat.com (Build System) Date: Wed, 5 Jan 2005 08:02:57 -0500 Subject: rawhide report: 20050105 changes Message-ID: <200501051302.j05D2vj13209@porkchop.devel.redhat.com> Updated Packages: bison-2.0-1 ----------- * Tue Jan 04 2005 Roland McGrath - 2.0-1 - new upstream version cups-1:1.1.23-1 --------------- * Tue Jan 04 2005 Tim Waugh 1.1.23-1 - 1.1.23. ethereal-0.10.8-2 ----------------- * Tue Jan 04 2005 Radek Vokal 0.10.8-2 - fixed linking for libethereal.so exim-4.43-4 ----------- * Tue Jan 04 2005 David Woodhouse 4.43-4 - Fix buffer overflows in host_aton() and SPA authentication gnome-speech-0.3.5-5 -------------------- * Tue Jan 04 2005 Colin Walters 0.3.5-5 - New patch gnome-speech-0.3.5-java-configure.patch to allow to explicitly disable Java - Use it - New patch gnome-speech-0.3.5-no-gnome-common.patch gnutls-1.0.20-5 --------------- * Tue Jan 04 2005 Ivana Varekova 1.0.20-5 - add gnutls Requires zlib-devel (#144069) rpmdb-fedora-1:4-0.20050105 --------------------------- ruby-1.8.2-1 ------------ * Wed Jan 05 2005 Akira TAGOH - 1.8.2-1 - New upstream release. - ruby-1.8.1-ia64-stack-limit.patch: removed - it's no longer needed. - ruby-1.8.1-cgi_session_perms.patch: likewise. - ruby-1.8.1-cgi-dos.patch: likewise. - generated Ruby interactive documentation - senarated package. it's now provided as ri package. (#141806) selinux-policy-strict-1.19.16-1 ------------------------------- * Tue Jan 04 2005 Dan Walsh 1.19-16-1 - Update to latest from NSA selinux-policy-targeted-1.19.16-1 --------------------------------- * Tue Jan 04 2005 Dan Walsh 1.19-16-1 - Update to latest from NSA sylpheed-1.0.0-1 ---------------- * Wed Jan 05 2005 Akira TAGOH - 1.0.0-1 - New upstream release. system-config-display-1.0.25-1 ------------------------------ * Tue Jan 04 2005 Paul Nasrat 1.0.25-1 - Only merge hardware_state if defined (#143944) - Only print card if verbose (#143271) system-config-services-0.8.17-1 ------------------------------- * Tue Jan 04 2005 Nils Philippsen 0.8.17-1 - throw away stderr to not be confused by error messages (#142983) totem-0.100-2 ------------- * Mon Jan 03 2005 Colin Walters - 0.100-2 - Grab patch totem-0.100-desktopfile.patch from CVS to fix missing menu entry (144088) - Remove workaround for desktop file being misinstalled, fixed by above patch xchat-1:2.4.1-2 --------------- * Tue Jan 04 2005 Christopher Aillon 1:2.4.1-2 - Add Dan Reed's CTCP patch to support multiline messages (#136545) xscreensaver-1:4.18-16 ---------------------- * Tue Jan 04 2005 Ray Strode 1:4.18-16 - Add patch to spec file to change defaults * Tue Jan 04 2005 Ray Strode 1:4.18-15 - Remove xscreensaver-config-tool after some discussions with jwz. - Take out some additional screensavers From fedora-devel at camperquake.de Wed Jan 5 13:19:30 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Wed, 5 Jan 2005 14:19:30 +0100 Subject: soundcard access In-Reply-To: <20050105134312.1b3e2207@nausicaa.camperquake.de> References: <1104863305.2732.8.camel@p.linuxcenter.cl> <1104862898.21468.25.camel@nexus.verbum.private> <20050104210920.11a12753@nausicaa.camperquake.de> <20050104210435.GA6262@devserv.devel.redhat.com> <20050104220922.1b5d25eb@nausicaa.camperquake.de> <1104880012.3866.7.camel@max.localdomain> <20050105122233.689b4198@nausicaa.camperquake.de> <20050105134312.1b3e2207@nausicaa.camperquake.de> Message-ID: <20050105141930.11f2bb94@nausicaa.camperquake.de> Hi. Ralf Ertzinger wrote: > Seems like you can. > Anyway, I went into the BIOS and disabled "PCI delayed transactions". So > far the sound card seems happy. If not I found this: > http://www-106.ibm.com/developerworks/library/l-hw2.html OK, neither of them solves the problem. Back to square 1 :) -- "We turn the Cube and it twists us." -- Erno Rubik From riel at redhat.com Wed Jan 5 13:30:37 2005 From: riel at redhat.com (Rik van Riel) Date: Wed, 5 Jan 2005 08:30:37 -0500 (EST) Subject: 4G/4G kernel patch dropped In-Reply-To: <529221D2-5E4D-11D9-A816-000D9352858E@linuxmail.org> References: <1460C4B716A20B689FE0BD75@[10.0.0.4]> <529221D2-5E4D-11D9-A816-000D9352858E@linuxmail.org> Message-ID: On Tue, 4 Jan 2005, Felipe Alfaro Solana wrote: > Maybe the 4-level Pagetable changes Andrea Arcangeli introduced into > 2.6.10 are related? Not really, Andi Kleen's 4-level page tables are mostly relevant on x86-64, where they can be used to have more than 512MB of virtual memory per process. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From retracile at gmail.com Wed Jan 5 14:10:17 2005 From: retracile at gmail.com (Eli) Date: Wed, 5 Jan 2005 08:10:17 -0600 Subject: some changes for (slightly) faster boot In-Reply-To: <20050104194721.GA26181@devserv.devel.redhat.com> References: <20050103225709.GA23700@nostromo.devel.redhat.com> <1104858300.4316.9.camel@localhost.localdomain> <20050104194721.GA26181@devserv.devel.redhat.com> Message-ID: <200501050810.17759.retracile@gmail.com> On Tuesday 04 January 2005 13:47, Alan Cox wrote: > On Tue, Jan 04, 2005 at 12:05:00PM -0500, Owen Taylor wrote: > > But you can't possibly believe that this is the right behavior??? To > > have to manually interact with the startup every time to keep it from > > deleting useful information? > > Its definitely not right, it needs to keep the stuff. Definitely. I have a Toshiba notebook that seems to detect a different video card about the time I upgrade the kernel... and then sets the resolution to 800x600, despite this being a 1024x768 screen. Grrr. Eli From dcbw at redhat.com Wed Jan 5 14:13:36 2005 From: dcbw at redhat.com (Dan Williams) Date: Wed, 05 Jan 2005 09:13:36 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104884917.4519.10.camel@mentorng.gurulabs.com> References: <20050103225709.GA23700@nostromo.devel.redhat.com> <200501032336.j03NaruY023023@magilla.sf.frob.com> <20050104000202.GA29062@devserv.devel.redhat.com> <1104858300.4316.9.camel@localhost.localdomain> <1104884917.4519.10.camel@mentorng.gurulabs.com> Message-ID: <1104934416.15759.0.camel@dcbw.boston.redhat.com> On Tue, 2005-01-04 at 17:28 -0700, Dax Kelson wrote: > On Tue, 2005-01-04 at 12:05 -0500, Owen Taylor wrote: > > > (WEP key isn't one of those... that's per-network not per network-device > > and shouldn't > > be in the device configuration at all; I think NetworkManager handles it > > correctly.) > > Does NetworkManager handle non-ESSID broadcasting access points yet? Yes, look for the "Other Wireless Network..." item in the applet's menu. After you connect the first time, it will cache the MAC address of the access point and recognize it (thereby putting it in the menu) from then on. Dan From remco at beryllium.net Wed Jan 5 16:29:56 2005 From: remco at beryllium.net (Remco Poelstra) Date: Wed, 05 Jan 2005 17:29:56 +0100 Subject: Using consolehelper/userhelper In-Reply-To: <1104928181.3694.10.camel@obelix.redhat.usu> References: <41DBD577.2080309@beryllium.net> <1104928181.3694.10.camel@obelix.redhat.usu> Message-ID: <41DC1604.2050307@beryllium.net> Jindrich Novy wrote: > Recent usermode has problems with uppercase characters in the name of > executables, please try it with lowercase and it should solve your > problem. I'll try to fix usermode to get rid of this issue. Works fine now, thank you! Does anybody here have an idea as when a yum-enabled system-install-packages will be available? Remco Poelstra From notting at redhat.com Wed Jan 5 18:55:14 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 5 Jan 2005 13:55:14 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <200501050810.17759.retracile@gmail.com> References: <20050103225709.GA23700@nostromo.devel.redhat.com> <1104858300.4316.9.camel@localhost.localdomain> <20050104194721.GA26181@devserv.devel.redhat.com> <200501050810.17759.retracile@gmail.com> Message-ID: <20050105185514.GE30048@nostromo.devel.redhat.com> Eli (retracile at gmail.com) said: > > Its definitely not right, it needs to keep the stuff. > > Definitely. I have a Toshiba notebook that seems to detect a different video > card about the time I upgrade the kernel... and then sets the resolution to > 800x600, despite this being a 1024x768 screen. OK, I believe this is because when s-c-display is told to change the card, it tries to probe for the monitor too, and if that fails, it defaults to something generic. This can be solved by: a) only changing the card b) fixing X to do something sane with the monitor definition Bill From kyrre at solution-forge.net Wed Jan 5 19:39:11 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 05 Jan 2005 20:39:11 +0100 Subject: NetworkManager borks at my wlan card... Message-ID: <1104953951.6507.8.camel@localhost.localdomain> I am using a laptop where i have one wired ethernet interface (eth0), and an adm8211 cardbus WLAN interface (eth1) - which is correctly set up by kudzu as a wlan interface. It all works - as long as i disable NetworkManager (netplugd works)... If i start the NetworkManager service, the whole computer seems to freeze about one secound, and then its fine for about a secound... Something which makes the laptop unusable. "top" shows "NetworkManager" running with 50% CPU. Hmm.. I smell a bug... I also can't find any way to start that nifty little tray applet... Kyrre From hp at redhat.com Wed Jan 5 20:23:53 2005 From: hp at redhat.com (Havoc Pennington) Date: Wed, 05 Jan 2005 15:23:53 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: References: <20050103224813.GA23361@nostromo.devel.redhat.com> <604aa791050103145520d9424a@mail.gmail.com> <20050103225709.GA23700@nostromo.devel.redhat.com> <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104871015.2925.12.camel@rousalka.dyndns.org> <1104872500.4078.2.camel@rhbw.boston.redhat.com> <20050104212543.GI6262@devserv.devel.redhat.com> <1104896312.30868.8.camel@localhost.localdomain> Message-ID: <1104956633.20592.27.camel@localhost.localdomain> On Wed, 2005-01-05 at 04:54 -0200, Alexandre Oliva wrote: > On Jan 5, 2005, Havoc Pennington wrote: > > > A bit hacky but it does the job. I don't really have a clue how we'd > > expose this in the GUI, anyhow > > Let the user create desktop profiles, and do per-profile > configurations? Then let the user choose which profile to use for a > session, and remember the last profile used on a host and use that as > default? For bonus points, introduce profile inheritance, and let the > user choose in which point of the profile inheritance to store some > specific setting. > We started doing this years ago, but it basically sucked because most of the time you want a profile to cover only a couple of settings, not all of them. Plus profiles as a concept are pretty complex (especially with inheritance). Another way to put it, once you have inheritance and limit profiles to particular keys, your tool for manipulating profiles is going to be on the level of gconf-editor, not on the level of control center. So to me we're better off just saying "the desktop should dynamically adapt to various resolutions" for example (we really need to do that anyhow, for the default configuration). Havoc From michael.favia at insitesinc.com Wed Jan 5 21:11:59 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Wed, 05 Jan 2005 15:11:59 -0600 Subject: NetworkManager borks at my wlan card... In-Reply-To: <1104953951.6507.8.camel@localhost.localdomain> References: <1104953951.6507.8.camel@localhost.localdomain> Message-ID: <41DC581F.3070007@insitesinc.com> Kyrre Ness Sjobak wrote: > Hmm.. I smell a bug... I smell a seemingly off-topic post. > > I also can't find any way to start that nifty little tray applet... NetworkManagerInfo Bon chance. -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com From pnasrat at redhat.com Wed Jan 5 22:14:24 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Wed, 05 Jan 2005 17:14:24 -0500 Subject: Using consolehelper/userhelper In-Reply-To: <41DC1604.2050307@beryllium.net> References: <41DBD577.2080309@beryllium.net> <1104928181.3694.10.camel@obelix.redhat.usu> <41DC1604.2050307@beryllium.net> Message-ID: <1104963264.26563.22.camel@minimumble.lab.boston.redhat.com> On Wed, 2005-01-05 at 17:29 +0100, Remco Poelstra wrote: > Jindrich Novy wrote: > > Recent usermode has problems with uppercase characters in the name of > > executables, please try it with lowercase and it should solve your > > problem. I'll try to fix usermode to get rid of this issue. > > Works fine now, thank you! > > Does anybody here have an idea as when a yum-enabled > system-install-packages will be available? See fedora-config-list, fc4 timescale. Hope to have some early versions out shortly... Paul From kyrre at solution-forge.net Wed Jan 5 22:31:06 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 05 Jan 2005 23:31:06 +0100 Subject: NetworkManager borks at my wlan card... In-Reply-To: <41DC581F.3070007@insitesinc.com> References: <1104953951.6507.8.camel@localhost.localdomain> <41DC581F.3070007@insitesinc.com> Message-ID: <1104964265.2641.1.camel@localhost.localdomain> ons, 05.01.2005 kl. 22.11 skrev Michael Favia: > Kyrre Ness Sjobak wrote: > > Hmm.. I smell a bug... > I smell a seemingly off-topic post. Just tought ill ask before i go bitching in bugzilla... It isn't like NetworkManager is really documented anywhere - it doesn't even have a man page... > > > > I also can't find any way to start that nifty little tray applet... > NetworkManagerInfo > Tried to start that app, from a terminal. It just takes a secound, and it returns. No messages etc. > Bon chance. > -- > Michael Favia michael.favia at insitesinc.com > Insites Incorporated http://michael.insitesinc.com From johnp at redhat.com Wed Jan 5 23:23:56 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Wed, 05 Jan 2005 18:23:56 -0500 Subject: NetworkManager borks at my wlan card... In-Reply-To: <1104964265.2641.1.camel@localhost.localdomain> References: <1104953951.6507.8.camel@localhost.localdomain> <41DC581F.3070007@insitesinc.com> <1104964265.2641.1.camel@localhost.localdomain> Message-ID: <1104967436.7486.26.camel@localhost.localdomain> On Wed, 2005-01-05 at 17:31, Kyrre Ness Sjobak wrote: > ons, 05.01.2005 kl. 22.11 skrev Michael Favia: > > Kyrre Ness Sjobak wrote: > > > Hmm.. I smell a bug... > > I smell a seemingly off-topic post. > > Just tought ill ask before i go bitching in bugzilla... > It isn't like NetworkManager is really documented anywhere - it doesn't > even have a man page... NetworkManager is not final yet and is under heavy development. The documentation is the code and Dan's web page at http://people.redhat.com/dcbw/NetworkManager. The previous poster was trying to inform you that this is a development list. Support questions should go to one of the other user lists. > > > > > > I also can't find any way to start that nifty little tray applet... > > NetworkManagerInfo > > > > Tried to start that app, from a terminal. It just takes a secound, and > it returns. No messages etc. If NetworkManager is not running NetworkManagerInfo will quit. -- J5 From lux at diesel-research.com Wed Jan 5 23:48:51 2005 From: lux at diesel-research.com (Kim Lux) Date: Wed, 05 Jan 2005 16:48:51 -0700 Subject: Heads up: can't build ndiswrapper with kernel 2.6.9-1.724_FC3 In-Reply-To: <1104885177.4376.4.camel@localhost.localdomain> References: <1104885177.4376.4.camel@localhost.localdomain> Message-ID: <1104968931.9168.3.camel@localhost.localdomain> I installed 2.6.10-1.727_FC3 from x86 rpms. I was then able to build ndiswrapper-0.12 and also install nvidia video drivers without problems. On Tue, 2005-01-04 at 17:32 -0700, Kim Lux wrote: > I can't run ndiswrapper-0.11 or -0.12 with the x.724 kernel. I get a > warning during the build about "task_nice". It completes the build. > > When I try to start networking (/etc/ini.d/networking) I get an error > concerning "task_nice". > > I've built ndiswrapper for lots of kernels without any problems. > > Is there a way to solve this problem without getting kernel source and > manually fixing it ? (ie any chance of a -1.725 kernel to save a bunch > of us a bunch of headaches ?) > > I'm not alone with this problem: > > http://ndiswrapper.sourceforge.net/forums/viewtopic.php?t=198 > > http://fedoraforum.org/forum/showthread.php?t=30416 > > -- Kim Lux, Diesel Research Inc. From toshio at tiki-lounge.com Thu Jan 6 02:13:54 2005 From: toshio at tiki-lounge.com (Toshio) Date: Wed, 05 Jan 2005 21:13:54 -0500 Subject: Reopen a request for gpgme in Core Message-ID: <1104977635.10350.17.camel@Madison.badger.com> Hi -- I made a request for gpgme in Core a while back but it was closed until some Core apps used it [1]. I've confirmed that Balsa works with gpgme 1.0.1. Rex Dieter has confirmed that kmail works as well. I've created a patch for sylpheed that gets it to use gpgme 1.0.1 as well. (Just introduced it upstream so I haven't heard if it's acceptable there yet.) So that's two and a half Core packages that would be significantly enhanced with the inclusion of gpgme 1.0.x. Should I open a new enhancement request or can someone reopen the old one? Also, should I post my sylpheed patch into the redhat bugzilla somewhere (For instance, [2]) or just follow the upstream mantra? (It's currently 1618 lines so it's not a trivial fix.) [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140168 [2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=80978 -Toshio -- Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rodd at clarkson.id.au Thu Jan 6 03:33:19 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Thu, 06 Jan 2005 14:33:19 +1100 Subject: NetworkManager and PCMCIA (WAS: some changes for (slightly) faster boot) In-Reply-To: <1104871519.4822.1.camel@dcbw.boston.redhat.com> References: <20050103225709.GA23700@nostromo.devel.redhat.com> <200501032336.j03NaruY023023@magilla.sf.frob.com> <20050104000202.GA29062@devserv.devel.redhat.com> <1104858300.4316.9.camel@localhost.localdomain> <20050104194721.GA26181@devserv.devel.redhat.com> <1104871519.4822.1.camel@dcbw.boston.redhat.com> Message-ID: <1104982399.3389.20.camel@trevally.redfishdemo.com> On Tue, 2005-01-04 at 15:45 -0500, Dan Williams wrote: > If the kernel recognizes it as a wireless device, and its exposed sanely > in sysfs (*cough* PCMCIA-hates-sysfs-somebody-needs-to-integrate-adams- > patches *cough*) then NetworkManager can use it without configuration. Dan, Does this mean there is a patch to get hal to set the capabilities of PCMCIA wireless cards so they work with NetworkManager? Can I help test it ;-] Rodd PS. You may recall doing to work (to help me) regarding this pre FC3. -- >From the pain come the dream >From the dream come the vision >From the vision come the people >From the people come the power >From this power come the change - Peter Gabriel From rdieter at math.unl.edu Thu Jan 6 05:06:59 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 05 Jan 2005 23:06:59 -0600 Subject: Reopen a request for gpgme in Core In-Reply-To: <1104977635.10350.17.camel@Madison.badger.com> References: <1104977635.10350.17.camel@Madison.badger.com> Message-ID: <41DCC773.3080100@math.unl.edu> Toshio wrote: > Hi -- I made a request for gpgme in Core a while back but it was closed > until some Core apps used it [1]. ... > Rex Dieter has confirmed that kmail works as well. Yep, http://bugzilla.redhat.com/bugzilla/136533 -- Rex From mattdm at mattdm.org Thu Jan 6 04:50:56 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 5 Jan 2005 23:50:56 -0500 Subject: festival 1.95 anyone? Message-ID: <20050106045056.GA11568@jadzia.bu.edu> I don't know anything about the science behind this, but text-to-speech is, y'know, cool. Festival 2.0 was supposed to be out a few months ago, but it seems to be late. In the meantime, 1.9.5 is out there, and has a few nice things -- particularly, the CMU_ARCTIC voices sound really good. Is anyone working on updating this? If not, I'll look, although it's way outside of areas where I know what I'm doing. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at wir-sind-cool.org Thu Jan 6 06:24:25 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 6 Jan 2005 07:24:25 +0100 Subject: Reopen a request for gpgme in Core In-Reply-To: <1104977635.10350.17.camel@Madison.badger.com> References: <1104977635.10350.17.camel@Madison.badger.com> Message-ID: <20050106072425.437a2395.fedora@wir-sind-cool.org> On Wed, 05 Jan 2005 21:13:54 -0500, Toshio wrote: > Hi -- I made a request for gpgme in Core a while back but it was closed > until some Core apps used it [1]. > > I've confirmed that Balsa works with gpgme 1.0.1. > > Rex Dieter has confirmed that kmail works as well. > > I've created a patch for sylpheed that gets it to use gpgme 1.0.1 as > well. (Just introduced it upstream so I haven't heard if it's > acceptable there yet.) Two observations: Where's the patch to be found? And shouldn't you use Sylpheed rather than Evolution? ;) From buildsys at redhat.com Thu Jan 6 13:37:03 2005 From: buildsys at redhat.com (Build System) Date: Thu, 6 Jan 2005 08:37:03 -0500 Subject: rawhide report: 20050106 changes Message-ID: <200501061337.j06Db3207369@porkchop.devel.redhat.com> Updated Packages: HelixPlayer-1:1.0.2-2 --------------------- * Wed Jan 05 2005 Colin Walters 1:1.0.2-2 - Apply patch from ville.skytta at iki.fi to avoid owning /usr/lib/mozilla (144237) anaconda-10.2.0.9-1 ------------------- * Wed Jan 05 2005 Jeremy Katz - 10.2.0.9-1 - Fix some typos (#143257, #144006) - Fix from Matthew Miller for multiple dns servers (#84409) - Fix formatting of fcp disks (#144199) - Include a README for x86_64 images (clumens, #143366) - Make an x86_64 rescue image (clumens, #143366) - Add libXfixes for new gtk2 audit-0.6-1 ----------- * Wed Jan 05 2005 Steve Grubb 0.6-1 - New version - Split package up to libs, libs-devel, and audit. * Mon Dec 13 2004 Steve Grubb 0.5.6-1 - New version * Fri Dec 10 2004 Steve Grubb 0.5.5-1 - New version findutils-1:4.1.20-8 -------------------- * Tue Jan 04 2005 Dan Walsh 1:4.1.20-8 - Change --context to use fnmatch instead of strcmp * Tue Dec 07 2004 Tim Waugh - Removed "G" and "M" size qualifiers from man page, since support for those is not in the stable branch (bug #141987). gcc-3.4.3-12 ------------ * Wed Jan 05 2005 Jakub Jelinek 3.4.3-12 - update from gcc-3_4-branch - PRs c++/14607, middle-end/19175, rtl-optimization/12092, target/17643 - fix ICE in same_translation_unit_p (#144166) * Mon Dec 27 2004 Jakub Jelinek 3.4.3-11 - update from gcc-3_4-branch - PRs c++/17972, c++/18962, c++/18975, java/14104, libobjc/12035, middle-end/17930, middle-end/18424, middle-end/18493, middle-end/18590, middle-end/18730, middle-end/18882, middle-end/19068, other/18508, other/18665, other/19093, preprocessor/15167, rtl-optimization/16968, target/16819, target/17990, target/18002, target/18153, target/19005, target/19010, target/19028, target/19102, target/19147 - fix ICE in dwarf2out (Devang Patel, Eric Botcazou, #143719, PR debug/16261) - fix ICE in reshape_init_array (#143034, PRs c++/18384, c++/18327) * Mon Dec 13 2004 Jakub Jelinek 3.4.3-10 - update from gcc-3_4-branch - PRs target/18932, target/17025, c++/18731 - fix _Jv_{Start,End}OfInterpreter computation (Andrew Haley, #142611, PRs java/18036, java/13468) - avoid multiple evaluation of sqrt and other math builtins when not -ffast-math (#142603, PR middle-end/18951) - remove leading underscore from /usr/libexec/getconf/default symlink target gpdf-2.8.1-1 ------------ * Wed Jan 05 2005 Marco Pesenti Gritti 2.8.1-1 - Update - Remove CAN-2004-0888, it's upstream now - Remove gnome-vfs-error-checking patch, upstream * Wed Jan 05 2005 Dan Williams 2.8.0-8.1 - Applied patch to fix CAN-2004-1125 (bug #144210) gstreamer-plugins-0.8.7-2 ------------------------- * Wed Jan 05 2005 Colin Walters - 0.8.7-2 - BR gtk2-devel (139151) * Wed Jan 05 2005 Colin Walters - 0.8.7-1 - New upstream version - Add new patch gstreamer-plugins-0.8.7-alsa.patch which obsoletes gstreamer-plugins-0.7.5-alsa.patch - Add in speex, tta, apetag plugins libtiff-3.7.1-3 --------------- * Wed Jan 05 2005 Matthias Clasen - 3.7.1-3 - Drop the largefile patch again - Fix a problem with the handling of alpha channels - Fix an integer overflow in tiffdump (#143576) man-pages-ja-20041215-2 ----------------------- * Wed Jan 05 2005 Akira TAGOH - 20041215-2 - prefer GNU fileutils's chown(1) rather than gnumaniak's. (#142077) netpbm-10.26-1 -------------- * Wed Jan 05 2005 Jindrich Novy 10.26-1 - update to netpbm-10.26-1, remove jbig, hpcd - regenerate man pages, remove man pages for non existent binaries - update security patch, additional fixes - drop upstreamed misc patch, merge malloc patch with security patch pam-0.78-3 ---------- * Mon Jan 03 2005 Jeff Johnson 0.78-3 - depend on db-4.3.27, not db-4.3.21. policycoreutils-1.19.3-1 ------------------------ * Mon Jan 03 2005 Dan Walsh 1.19.3-1 - Update to latest from NSA * Merged fixfiles and restorecon patches from Dan Walsh. * Don't display change if only user part changed. redhat-artwork-0.120-2 ---------------------- * Wed Jan 05 2005 Jeremy Katz - 0.120-2 - rebuild so that gtk engine ends up in the right place for gtk+ 2.6.x rpmdb-fedora-1:4-0.20050106 --------------------------- selinux-policy-strict-1.19.17-2 ------------------------------- * Wed Jan 05 2005 Dan Walsh 1.19-17-3 - Change to use typeattribute - Update to latest from NSA selinux-policy-targeted-1.19.17-3 --------------------------------- * Wed Jan 05 2005 Dan Walsh 1.19-17-3 - change to require checkpolicy >= 1.19.2 - Change to use typeattribute - Update list of booleans - Update to latest from NSA syslinux-3.02-2 --------------- * Tue Jan 04 2005 Peter Jones - 3.02-2 - Beehive doesn't let you build in scratch and then build someplace else, arrrrgh. * Tue Jan 04 2005 Peter Jones - 3.02-1 - 3.02 - Make the spec a little closer to hpa's. * Mon Jan 03 2005 Peter Jones - 3.00-2 - make tag says the tag is there, make build says it's not. Bump release, try again. vnc-4.0-12 ---------- * Wed Jan 05 2005 Tim Waugh 4.0-12 - Don't use initlog in the initscript. * Fri Dec 31 2004 Tim Waugh - Cookie generation improvement from Jon Peatfield. xmms-1:1.2.10-11 ---------------- * Wed Jan 05 2005 Colin Walters 1:1.2.10-11 - Change BR on mikmod to mikmod-devel (138057) From alan at redhat.com Thu Jan 6 14:01:01 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 6 Jan 2005 09:01:01 -0500 Subject: some changes for (slightly) faster boot In-Reply-To: <1104956633.20592.27.camel@localhost.localdomain> References: <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104871015.2925.12.camel@rousalka.dyndns.org> <1104872500.4078.2.camel@rhbw.boston.redhat.com> <20050104212543.GI6262@devserv.devel.redhat.com> <1104896312.30868.8.camel@localhost.localdomain> <1104956633.20592.27.camel@localhost.localdomain> Message-ID: <20050106140101.GC32537@devserv.devel.redhat.com> On Wed, Jan 05, 2005 at 03:23:53PM -0500, Havoc Pennington wrote: > So to me we're better off just saying "the desktop should dynamically > adapt to various resolutions" for example (we really need to do that > anyhow, for the default configuration). SGI had per desktop profiles on IRIX as an option. In most respects I'd second Havoc that if the desktop would just mind its own business the world will be happy. That will need tools like metacity to grow up and start behaving better. It would also need smarter awareness of resolution and dpi - eg if I move from 1600x1200 analog to 1024x768 on the laptop tft the right move for gnome-terminal is smaller fonts not 40x16 windows. The advantages of the SGI setup moving from very big to small displays was you got a sane desktop. The disadvantage was that you had to keep them in sync by hand and it got to be a real PITA. From Nicolas.Mailhot at laPoste.net Thu Jan 6 14:30:31 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 06 Jan 2005 15:30:31 +0100 Subject: some changes for (slightly) faster boot In-Reply-To: <20050106140101.GC32537@devserv.devel.redhat.com> References: <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104871015.2925.12.camel@rousalka.dyndns.org> <1104872500.4078.2.camel@rhbw.boston.redhat.com> <20050104212543.GI6262@devserv.devel.redhat.com> <1104896312.30868.8.camel@localhost.localdomain> <1104956633.20592.27.camel@localhost.localdomain> <20050106140101.GC32537@devserv.devel.redhat.com> Message-ID: <1105021831.2244.12.camel@ulysse.olympe.o2t> Le jeudi 06 janvier 2005 ? 09:01 -0500, Alan Cox a ?crit : > On Wed, Jan 05, 2005 at 03:23:53PM -0500, Havoc Pennington wrote: > > So to me we're better off just saying "the desktop should dynamically > > adapt to various resolutions" for example (we really need to do that > > anyhow, for the default configuration). > > SGI had per desktop profiles on IRIX as an option. In most respects I'd second > Havoc that if the desktop would just mind its own business the world will be > happy. That will need tools like metacity to grow up and start behaving > better. It would also need smarter awareness of resolution and dpi - eg if > I move from 1600x1200 analog to 1024x768 on the laptop tft the right move > for gnome-terminal is smaller fonts not 40x16 windows. ie use the real dpi setting as provided by xorg instead of forcing 96 dpi everywhere to match windows (and add a user-side relative zoom factor to take into account people with bad eyes) With modern screens you get nicer display with the highest dpi available instead of limiting yourself to 96 anyway. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dcbw at redhat.com Thu Jan 6 14:39:08 2005 From: dcbw at redhat.com (Dan Williams) Date: Thu, 06 Jan 2005 09:39:08 -0500 Subject: NetworkManager and PCMCIA (WAS: some changes for (slightly) faster boot) In-Reply-To: <1104982399.3389.20.camel@trevally.redfishdemo.com> References: <20050103225709.GA23700@nostromo.devel.redhat.com> <200501032336.j03NaruY023023@magilla.sf.frob.com> <20050104000202.GA29062@devserv.devel.redhat.com> <1104858300.4316.9.camel@localhost.localdomain> <20050104194721.GA26181@devserv.devel.redhat.com> <1104871519.4822.1.camel@dcbw.boston.redhat.com> <1104982399.3389.20.camel@trevally.redfishdemo.com> Message-ID: <1105022348.19939.0.camel@dcbw.boston.redhat.com> On Thu, 2005-01-06 at 14:33 +1100, Rodd Clarkson wrote: > On Tue, 2005-01-04 at 15:45 -0500, Dan Williams wrote: > > > If the kernel recognizes it as a wireless device, and its exposed sanely > > in sysfs (*cough* PCMCIA-hates-sysfs-somebody-needs-to-integrate-adams- > > patches *cough*) then NetworkManager can use it without configuration. > > Dan, > > Does this mean there is a patch to get hal to set the capabilities of > PCMCIA wireless cards so they work with NetworkManager? > > Can I help test it ;-] Hi Rodd! Well, the patch has been there for a while, but I'm still not sure it fixes your problem of the PCMCIA-card-on-PCI-card thingy... Dan From bpm at ec-group.com Thu Jan 6 14:42:23 2005 From: bpm at ec-group.com (Brian Millett) Date: Thu, 06 Jan 2005 08:42:23 -0600 Subject: rawhide report: 20050106 changes In-Reply-To: <200501061337.j06Db3207369@porkchop.devel.redhat.com> References: <200501061337.j06Db3207369@porkchop.devel.redhat.com> Message-ID: <1105022543.4441.9.camel@localhost.localdomain> On Thu, 2005-01-06 at 08:37 -0500, Build System wrote: > > Updated Packages: > > HelixPlayer-1:1.0.2-2 > --------------------- > * Wed Jan 05 2005 Colin Walters 1:1.0.2-2 > - Apply patch from ville.skytta at iki.fi to avoid > owning /usr/lib/mozilla (144237) . . . . [snip of email] WHAT!!! I'm sorry, but in evolution this message was blank. I looked at the email source and this is what I see: --BEGIN-- Received: via dmail-2002(12) for bpm+RedHat; Thu, 6 Jan 2005 07:36:21 -0600 (CST) Received: from esafe.ec-group.com (esafe.ec-group.com [192.168.250.47]) by exchange.ec-group.com (8.12.8+Sun/8.12.2) with SMTP id j06DZjat018703 for ; Thu, 6 Jan 2005 07:35:45 -0600 (CST) Received: from tiny.ec-group.com ([IP=192.168.0.201]) by eSafe SMTP Relay 1104839720; Thu Jan 6 07:43:48 2005 Received: from Unknown [209.132.177.30] by tiny.ec-group.com - SurfControl E-mail Filter (5.0); Thu, 06 Jan 2005 07:35:04 -0600 Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com [10.8.4.110]) by hormel.redhat.com (Postfix) with ESMTP id E2D8973430; Thu, 6 Jan 2005 08:37:06 -0500 (EST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by listman.util.phx.redhat.com (8.12.11/8.12.10) with ESMTP id j06Db4WX023021 for ; Thu, 6 Jan 2005 08:37:04 -0500 Received: from porkchop.devel.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j06Db3r02324 for ; Thu, 6 Jan 2005 08:37:03 -0500 Received: (from buildsys at localhost) by porkchop.devel.redhat.com (8.11.6/8.11.6) id j06Db3207369 for fedora-devel- list at redhat.com; Thu, 6 Jan 2005 08:37:03 -0500 Date: Thu, 6 Jan 2005 08:37:03 -0500 From: Build System Message-Id: <200501061337.j06Db3207369 at porkchop.devel.redhat.com> To: fedora-devel-list at redhat.com X-loop: fedora-devel-list at redhat.com Subject: rawhide report: 20050106 changes X-BeenThere: fedora-devel-list at redhat.com X-Mailman-Version: 2.1.5 Precedence: junk Reply-To: Development discussions related to Fedora Core List-Id: Development discussions related to Fedora Core List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: fedora-devel-list-bounces at redhat.com Errors-To: fedora-devel-list-bounces at redhat.com X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on exchange.ec-group.com X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.0.2 X-Spam-Level: X-Evolution-Source: imap://bpm at mail.ec-group.com/ Mime-Version: 1.0 --END-- So I think, "I'll reply to ask why this is blank" and here it is!!. Am I insane? I'm running rawhide with the evolution rev at evolution-data-server-1.0.3-2 evolution-data-server-devel-1.0.3-2 evolution-2.0.3-2 Thanks. -- Brian Millett - [ Londo, "Chrysalis"] "This is like being nibbled to death by cats." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From toshio at tiki-lounge.com Thu Jan 6 16:06:59 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 6 Jan 2005 11:06:59 -0500 Subject: Reopen a request for gpgme in Core In-Reply-To: <20050106072425.437a2395.fedora@wir-sind-cool.org> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106072425.437a2395.fedora@wir-sind-cool.org> Message-ID: <20050106110659.17f329f0.toshio@tiki-lounge.com> On Thu, 6 Jan 2005 07:24:25 +0100 Michael Schwendt wrote: > Two observations: Where's the patch to be found? And shouldn't you use > Sylpheed rather than Evolution? ;) > Heh heh now that it does gpg signing/verification on my box I might start using it :-) Truth to tell, there are some features of Evolution I'm somewhat loathe to lose so I might have to bounce between the two mailers for a while depending on what I'm doing. The current version of the patch can be found here: http://www.tiki-lounge.com/~toshio/fedora/sylpheed-gpgme1.0-12.patch I've been posting announcements about it to the sylpheed mailing list. -toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dhollis at davehollis.com Thu Jan 6 17:09:26 2005 From: dhollis at davehollis.com (David Hollis) Date: Thu, 06 Jan 2005 12:09:26 -0500 Subject: rawhide report: 20050106 changes In-Reply-To: <1105022543.4441.9.camel@localhost.localdomain> References: <200501061337.j06Db3207369@porkchop.devel.redhat.com> <1105022543.4441.9.camel@localhost.localdomain> Message-ID: <1105031367.3885.4.camel@dhollis-lnx.centricconsulting.com> On Thu, 2005-01-06 at 08:42 -0600, Brian Millett wrote: > . > [snip of email] > > WHAT!!! I'm sorry, but in evolution this message was blank. I looked > at the email source and this is what I see: > > So I think, "I'll reply to ask why this is blank" and here it is!!. > > Am I insane? I've seen that a few times in Evolution. The message appears to be empty, but if you select a different message and then re-select the original, the body content is there. I can't reproduce it manually, it's just one of those things that sometimes happens. -- David Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From shahms at shahms.com Thu Jan 6 15:16:28 2005 From: shahms at shahms.com (Shahms King) Date: Thu, 06 Jan 2005 07:16:28 -0800 Subject: some changes for (slightly) faster boot In-Reply-To: <1105021831.2244.12.camel@ulysse.olympe.o2t> References: <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104871015.2925.12.camel@rousalka.dyndns.org> <1104872500.4078.2.camel@rhbw.boston.redhat.com> <20050104212543.GI6262@devserv.devel.redhat.com> <1104896312.30868.8.camel@localhost.localdomain> <1104956633.20592.27.camel@localhost.localdomain> <20050106140101.GC32537@devserv.devel.redhat.com> <1105021831.2244.12.camel@ulysse.olympe.o2t> Message-ID: <1105024588.20319.33.camel@shahms.mesd.k12.or.us> On Thu, 2005-01-06 at 15:30 +0100, Nicolas Mailhot wrote: > Le jeudi 06 janvier 2005 ? 09:01 -0500, Alan Cox a ?crit : > > On Wed, Jan 05, 2005 at 03:23:53PM -0500, Havoc Pennington wrote: > > > So to me we're better off just saying "the desktop should dynamically > > > adapt to various resolutions" for example (we really need to do that > > > anyhow, for the default configuration). > > > > SGI had per desktop profiles on IRIX as an option. In most respects I'd second > > Havoc that if the desktop would just mind its own business the world will be > > happy. That will need tools like metacity to grow up and start behaving > > better. It would also need smarter awareness of resolution and dpi - eg if > > I move from 1600x1200 analog to 1024x768 on the laptop tft the right move > > for gnome-terminal is smaller fonts not 40x16 windows. > > ie use the real dpi setting as provided by xorg instead of forcing 96 > dpi everywhere to match windows (and add a user-side relative zoom > factor to take into account people with bad eyes) > > With modern screens you get nicer display with the highest dpi available > instead of limiting yourself to 96 anyway. > > Regards, Sometimes the DPI returned from the DDC probe isn't accurate, however . . . As a side note and "me too!" though, my SGI 1600SW flat panel *does* report DPI correctly at 108 (or 106, I can't remember) and unless I manually change this, the sub-pixel anti-aliasing produces very visible green and red outlines. -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B From dmalcolm at redhat.com Thu Jan 6 17:22:03 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Thu, 06 Jan 2005 12:22:03 -0500 Subject: rawhide report: 20050106 changes In-Reply-To: <1105031367.3885.4.camel@dhollis-lnx.centricconsulting.com> References: <200501061337.j06Db3207369@porkchop.devel.redhat.com> <1105022543.4441.9.camel@localhost.localdomain> <1105031367.3885.4.camel@dhollis-lnx.centricconsulting.com> Message-ID: <1105032123.3799.41.camel@cassandra.boston.redhat.com> On Thu, 2005-01-06 at 12:09 -0500, David Hollis wrote: > On Thu, 2005-01-06 at 08:42 -0600, Brian Millett wrote: > > > . > > [snip of email] > > > > WHAT!!! I'm sorry, but in evolution this message was blank. I looked > > at the email source and this is what I see: > > > > > So I think, "I'll reply to ask why this is blank" and here it is!!. > > > > Am I insane? > > I've seen that a few times in Evolution. The message appears to be > empty, but if you select a different message and then re-select the > original, the body content is there. I can't reproduce it manually, > it's just one of those things that sometimes happens. I see this occasionally too. I've filed a bug report about it here: https://bugzilla.redhat.com/beta/show_bug.cgi?id=144378 Is this what you're seeing, or did the message actually fail to download properly? From fedora at wir-sind-cool.org Thu Jan 6 17:30:45 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 6 Jan 2005 18:30:45 +0100 Subject: Reopen a request for gpgme in Core In-Reply-To: <20050106110659.17f329f0.toshio@tiki-lounge.com> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106072425.437a2395.fedora@wir-sind-cool.org> <20050106110659.17f329f0.toshio@tiki-lounge.com> Message-ID: <20050106183045.1991bdbb.fedora@wir-sind-cool.org> On Thu, 6 Jan 2005 11:06:59 -0500, Toshio Kuratomi wrote: > > Two observations: Where's the patch to be found? And shouldn't you use > > Sylpheed rather than Evolution? ;) > > > Heh heh now that it does gpg signing/verification on my box I might start using > it :-) Truth to tell, there are some features of Evolution I'm somewhat loathe > to lose so I might have to bounce between the two mailers for a while depending > on what I'm doing. > > The current version of the patch can be found here: > http://www.tiki-lounge.com/~toshio/fedora/sylpheed-gpgme1.0-12.patch Thanks. I'm going to apply this and also serve as a guinea pig, because currently I still use a GPGME 0.3.x enabled Sylpheed. GPGME 1.0 and dependencies are in the fedora.us submission list already. Bugs: 2178 -> 2179 -> 2180 <- 2185 Among the things to examine are: * Dependencies on GPGME 0.4.x: gpa, elmo * Dependencies on GPGME 0.3.x: cryptplug, seahorse, sylpheed-claws (seahorse is very old, but pcomptom said maybe he will continue it) * In which way or whether cryptplug uses gpgsm? * Is cryptplug of any use in FC3? * How are gpa and elmo affected by an upgrade from gpgme 0.4.x? From P at draigBrady.com Thu Jan 6 17:47:39 2005 From: P at draigBrady.com (P at draigBrady.com) Date: Thu, 06 Jan 2005 17:47:39 +0000 Subject: ssh X forwarding change in FC3 Message-ID: <41DD79BB.30304@draigBrady.com> The FC3 release notes say: "The behavior of ssh clients that are invoked with the -X flag has changed. In OpenSSH 3.8 and later, X11 forwarding is performed in a way that applications run as untrusted clients by default. Previously, X11 forwarding was performed so that applications always ran as trusted clients. Some applications may not function properly when run as untrusted clients. To forward X11 so that applications are run as trusted clients, invoke ssh with the -Y flag instead of the -X flag, or set ForwardX11Trusted in the ~/.ssh/config file." See also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141515 Essentially what this means is that most X applications will break if forwarded back to a FC3 system with default config. Now it wouldn't be so bad if they just wouldn't work. They break in subtle ways usually related to mouse events. This is just silly IMHO and will cause no end of hassles for users trying to figure out what's going on and also be a waste of time for developers of those X apps who will receive bogus bug reports. So can we change the upstream default back to what it used to be? cheers. -- P?draig Brady - http://www.pixelbeat.org -- From stephen_pollei at comcast.net Thu Jan 6 17:55:25 2005 From: stephen_pollei at comcast.net (Stephen Pollei) Date: 06 Jan 2005 09:55:25 -0800 Subject: festival 1.95 anyone? In-Reply-To: <20050106045056.GA11568@jadzia.bu.edu> References: <20050106045056.GA11568@jadzia.bu.edu> Message-ID: <1105034127.976.9.camel@fury> On Wed, 2005-01-05 at 20:50, Matthew Miller wrote: > text-to-speech is, > y'know, cool. Festival 2.0 was supposed to be out a few months ago, but it > seems to be late. In the meantime, 1.9.5 is out there, Yes tts is kind of neat. I wonder how festival compares to http://freetts.sourceforge.net/docs/index.php ? Also while you are talking about speech, what about http://www.digium.com/ and http://cmusphinx.sourceforge.net/sphinx4/ . I at least think(guess) that http://www.asterisk.org/ from digium , might fit as a nice feature for some of Red Hat's target market fairly well. -- http://dmoz.org/profiles/pollei.html http://sourceforge.net/users/stephen_pollei/ http://www.orkut.com/Profile.aspx?uid=2455954990164098214 http://stephen_pollei.home.comcast.net/ GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1 3C01 910F 6BB5 4A7D 9677 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From stfn at gmx.net Thu Jan 6 17:52:34 2005 From: stfn at gmx.net (Stefan Hoelldampf) Date: Thu, 06 Jan 2005 18:52:34 +0100 Subject: Updates on the Fedora CVS server In-Reply-To: References: Message-ID: <41DD7AE2.6070005@gmx.net> Cristian Gafton wrote: > There are also CVS-related mailing lists that you can subscribe to. these > mailing lists publish the CVS commits as they happen. If you are curious, > you can sign up for the mailing lists at the following links: > - Fedora Core: > http://www.redhat.com/mailman/listinfo/fedora-cvs-commits Is it correct that no CVS-mail has reached this mailing list yet? Regards, Stefan From rdieter at math.unl.edu Thu Jan 6 18:04:48 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 06 Jan 2005 12:04:48 -0600 Subject: Reopen a request for gpgme in Core In-Reply-To: <20050106183045.1991bdbb.fedora@wir-sind-cool.org> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106072425.437a2395.fedora@wir-sind-cool.org> <20050106110659.17f329f0.toshio@tiki-lounge.com> <20050106183045.1991bdbb.fedora@wir-sind-cool.org> Message-ID: <41DD7DC0.4050906@math.unl.edu> Michael Schwendt wrote: > GPGME 1.0 and dependencies are in the fedora.us submission list > already. Bugs: 2178 -> 2179 -> 2180 <- 2185 > > Among the things to examine are: > > * Dependencies on GPGME 0.4.x: gpa, elmo > * How are gpa and elmo affected by an upgrade from gpgme 0.4.x? AFAIK, gpgme-1.0.0 is binary/api compatible with gpgme-0.4.x (I think the 0.4.x versions were simply used to denote preleases before 1.0 was done) > * In which way or whether cryptplug uses gpgsm? AFAIK, It doesn't. Only gpgme >= 0.4 does. (I could be wrong here). > * Is cryptplug of any use in FC3? IMO, no, I *think* it was only used for older kde (kde-3.(1.2)?) -- Rex From shiva at sewingwitch.com Thu Jan 6 18:22:18 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Thu, 06 Jan 2005 10:22:18 -0800 Subject: rawhide report: 20050106 changes In-Reply-To: <1105031367.3885.4.camel@dhollis-lnx.centricconsulting.com> References: <200501061337.j06Db3207369@porkchop.devel.redhat.com> <1105022543.4441.9.camel@localhost.localdomain> <1105031367.3885.4.camel@dhollis-lnx.centricconsulting.com> Message-ID: <16C90C7679492B221376C670@[10.169.6.246]> --On Thursday, January 06, 2005 12:09 PM -0500 David Hollis wrote: > I've seen that a few times in Evolution. The message appears to be > empty, but if you select a different message and then re-select the > original, the body content is there. I can't reproduce it manually, > it's just one of those things that sometimes happens. What kind of message store? I'm using dovecot-0.99.10.9-1.FC3.2 for the server (Mulberry for client) and dovecot sometimes "loses" message parts, but selecting another IMAP folder and then the original will sometimes cure it. Or I may need to drag the message to another folder. It's intermittent so I've been unable to get a reproducible test case to debug it. I'm pretty sure it's dovecot's failure as evidenced by logging the IMAP protocol from Mulberry. From bpm at ec-group.com Thu Jan 6 18:29:35 2005 From: bpm at ec-group.com (Brian Millett) Date: Thu, 06 Jan 2005 12:29:35 -0600 Subject: rawhide report: 20050106 changes In-Reply-To: <1105032123.3799.41.camel@cassandra.boston.redhat.com> References: <200501061337.j06Db3207369@porkchop.devel.redhat.com> <1105022543.4441.9.camel@localhost.localdomain> <1105031367.3885.4.camel@dhollis-lnx.centricconsulting.com> <1105032123.3799.41.camel@cassandra.boston.redhat.com> Message-ID: <1105036175.4441.12.camel@localhost.localdomain> On Thu, 2005-01-06 at 12:22 -0500, David Malcolm wrote: > On Thu, 2005-01-06 at 12:09 -0500, David Hollis wrote: > > On Thu, 2005-01-06 at 08:42 -0600, Brian Millett wrote: > > > > > . > > > [snip of email] > > > > > > WHAT!!! I'm sorry, but in evolution this message was blank. I looked > > > at the email source and this is what I see: > > > > > > > > So I think, "I'll reply to ask why this is blank" and here it is!!. > > > > > > Am I insane? > > > > I've seen that a few times in Evolution. The message appears to be > > empty, but if you select a different message and then re-select the > > original, the body content is there. I can't reproduce it manually, > > it's just one of those things that sometimes happens. > > I see this occasionally too. I've filed a bug report about it here: > https://bugzilla.redhat.com/beta/show_bug.cgi?id=144378 > > Is this what you're seeing, or did the message actually fail to download > properly? It looks like it just did did not download properly. I'll check tomorrows update-report to see if it will be OK when I select other messages, but iirc that was not the case. Thanks. I'm glad I'm not alone. If it is still there manana, then I'll file a bug. -- Brian Millett - [ Derek Mobotabwe, ISN News, "A Voice in the Wilderness I"] "The guerrillas, whose ancestors migrated to Mars from Earth over the past hundred years, have demanded independence for the Mars Colony or, and I quote, 'The sand will run red with Earther blood.'" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From bpm at ec-group.com Thu Jan 6 18:44:45 2005 From: bpm at ec-group.com (Brian Millett) Date: Thu, 06 Jan 2005 12:44:45 -0600 Subject: rawhide report: 20050106 changes In-Reply-To: <16C90C7679492B221376C670@[10.169.6.246]> References: <200501061337.j06Db3207369@porkchop.devel.redhat.com> <1105022543.4441.9.camel@localhost.localdomain> <1105031367.3885.4.camel@dhollis-lnx.centricconsulting.com> <16C90C7679492B221376C670@[10.169.6.246]> Message-ID: <1105037085.4441.15.camel@localhost.localdomain> On Thu, 2005-01-06 at 10:22 -0800, Kenneth Porter wrote: > --On Thursday, January 06, 2005 12:09 PM -0500 David Hollis > wrote: > > > I've seen that a few times in Evolution. The message appears to be > > empty, but if you select a different message and then re-select the > > original, the body content is there. I can't reproduce it manually, > > it's just one of those things that sometimes happens. > > What kind of message store? > > I'm using dovecot-0.99.10.9-1.FC3.2 for the server (Mulberry for client) > and dovecot sometimes "loses" message parts, but selecting another IMAP > folder and then the original will sometimes cure it. Or I may need to drag > the message to another folder. It's intermittent so I've been unable to get > a reproducible test case to debug it. I'm pretty sure it's dovecot's > failure as evidenced by logging the IMAP protocol from Mulberry. Ok, it us UW imapd 2004a I believe. It is using dmail to deliver with procmail. -- Brian Millett - [ Dr. Franklin and Ivanova, "Soul Hunter"] "It's all so brief, isn't it? Typical human life span is almost a hundred years, but it's barely a second compared to what's out there. Wouldn't be so bad if life didn't take so long to figure out. Seems you just start to get it right and then...it's over." 'Doesn't matter. If we lived two hundred years, we'd still be human. We'd still make the same mistakes.' -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Thu Jan 6 18:25:02 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 6 Jan 2005 13:25:02 -0500 Subject: festival 1.95 anyone? In-Reply-To: <1105034127.976.9.camel@fury> References: <20050106045056.GA11568@jadzia.bu.edu> <1105034127.976.9.camel@fury> Message-ID: <20050106182502.GA3018@jadzia.bu.edu> On Thu, Jan 06, 2005 at 09:55:25AM -0800, Stephen Pollei wrote: > Yes tts is kind of neat. I wonder how festival compares to > http://freetts.sourceforge.net/docs/index.php ? > Also while you are talking about speech, what about > http://www.digium.com/ and http://cmusphinx.sourceforge.net/sphinx4/ . FreeTTS and Sphinx4 are both Java, so they're out. And it actually looks like FreeTTS is derived from "Flite", which is "festival-light". Hmmm. Flite may actually be what I want. My whole goal in updating is to get the "arctic" voices from -- they're way better than the "kal" and "ked" voices that are pretty much the only option with the current package. Wonder if Flite can do that.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From pbruna at linuxcenterla.com Thu Jan 6 19:15:01 2005 From: pbruna at linuxcenterla.com (Patricio Bruna V) Date: Thu, 06 Jan 2005 16:15:01 -0300 Subject: festival 1.95 anyone? In-Reply-To: <20050106182502.GA3018@jadzia.bu.edu> References: <20050106045056.GA11568@jadzia.bu.edu> <1105034127.976.9.camel@fury> <20050106182502.GA3018@jadzia.bu.edu> Message-ID: <1105038901.3036.0.camel@p.linuxcenter.cl> El jue, 06-01-2005 a las 13:25 -0500, Matthew Miller escribi?: > On Thu, Jan 06, 2005 at 09:55:25AM -0800, Stephen Pollei wrote: > > Yes tts is kind of neat. I wonder how festival compares to > > http://freetts.sourceforge.net/docs/index.php ? > > Also while you are talking about speech, what about > > http://www.digium.com/ and http://cmusphinx.sourceforge.net/sphinx4/ . > > FreeTTS and Sphinx4 are both Java, so they're out. > > And it actually looks like FreeTTS is derived from "Flite", which is > "festival-light". > > Hmmm. Flite may actually be what I want. My whole goal in updating is to get > the "arctic" voices from -- they're way > better than the "kal" and "ked" voices that are pretty much the only option > with the current package. Wonder if Flite can do that.... > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > For default Festival only comes with english voice, how can i get the others, spanish per se -- Patricio Bruna http://www.linuxcenterla.com Ingeniero de Proyectos Mariano S?nchez Fontecilla 310 Red Hat Certified Engineer Las Condes, Santiago - CHILE Linux Center Latinoamerica Fono: 2745000 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From fedora-devel at camperquake.de Thu Jan 6 19:08:11 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 6 Jan 2005 20:08:11 +0100 Subject: rawhide report: 20050106 changes In-Reply-To: <1105022543.4441.9.camel@localhost.localdomain> References: <200501061337.j06Db3207369@porkchop.devel.redhat.com> <1105022543.4441.9.camel@localhost.localdomain> Message-ID: <20050106200811.3b31fc7e@nausicaa.camperquake.de> Hi. Brian Millett wrote: > WHAT!!! I'm sorry, but in evolution this message was blank. I looked > at the email source and this is what I see: Sometimes I am getting empty mails from the buildsystem, too. The last one was from 20041224. This came though normally. sylpheed-claws talking to a pop3 server, in case this matters :) -- "Life here in Cambridge is normal. That is to say, it's at 90 degrees to everybody else's plane of reality." -- Ross Younger From fedora-devel at camperquake.de Thu Jan 6 19:10:06 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 6 Jan 2005 20:10:06 +0100 Subject: ssh X forwarding change in FC3 In-Reply-To: <41DD79BB.30304@draigBrady.com> References: <41DD79BB.30304@draigBrady.com> Message-ID: <20050106201006.48579d4c@nausicaa.camperquake.de> Hi. P at draigBrady.com wrote: > as untrusted clients. To forward X11 so that applications are run as > trusted clients, invoke ssh with the -Y flag instead of the -X flag, > or set ForwardX11Trusted in the ~/.ssh/config file." Thanks for the head up, I missed that one, and wondered why X forwarding behaved strangely sometimes. -- "Here's a warning for all motorists travelling West on the M4. You're heading towards Wales!" From Nicolas.Mailhot at laPoste.net Thu Jan 6 19:13:03 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 06 Jan 2005 20:13:03 +0100 Subject: some changes for (slightly) faster boot In-Reply-To: <1105024588.20319.33.camel@shahms.mesd.k12.or.us> References: <604aa79105010316065139aebc@mail.gmail.com> <20050104034534.GA26184@nostromo.devel.redhat.com> <1104869496.21468.39.camel@nexus.verbum.private> <1104871015.2925.12.camel@rousalka.dyndns.org> <1104872500.4078.2.camel@rhbw.boston.redhat.com> <20050104212543.GI6262@devserv.devel.redhat.com> <1104896312.30868.8.camel@localhost.localdomain> <1104956633.20592.27.camel@localhost.localdomain> <20050106140101.GC32537@devserv.devel.redhat.com> <1105021831.2244.12.camel@ulysse.olympe.o2t> <1105024588.20319.33.camel@shahms.mesd.k12.or.us> Message-ID: <1105038783.11406.0.camel@rousalka.dyndns.org> Le jeudi 06 janvier 2005 ? 07:16 -0800, Shahms King a ?crit : > On Thu, 2005-01-06 at 15:30 +0100, Nicolas Mailhot wrote: > > Le jeudi 06 janvier 2005 ? 09:01 -0500, Alan Cox a ?crit : > > > On Wed, Jan 05, 2005 at 03:23:53PM -0500, Havoc Pennington wrote: > > > > So to me we're better off just saying "the desktop should dynamically > > > > adapt to various resolutions" for example (we really need to do that > > > > anyhow, for the default configuration). > > > > > > SGI had per desktop profiles on IRIX as an option. In most respects I'd second > > > Havoc that if the desktop would just mind its own business the world will be > > > happy. That will need tools like metacity to grow up and start behaving > > > better. It would also need smarter awareness of resolution and dpi - eg if > > > I move from 1600x1200 analog to 1024x768 on the laptop tft the right move > > > for gnome-terminal is smaller fonts not 40x16 windows. > > > > ie use the real dpi setting as provided by xorg instead of forcing 96 > > dpi everywhere to match windows (and add a user-side relative zoom > > factor to take into account people with bad eyes) > > > > With modern screens you get nicer display with the highest dpi available > > instead of limiting yourself to 96 anyway. > > > > Regards, > > Sometimes the DPI returned from the DDC probe isn't accurate, > however . . . But you can always force a screen size in xorg.conf... -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From stephen_pollei at comcast.net Thu Jan 6 19:43:00 2005 From: stephen_pollei at comcast.net (Stephen Pollei) Date: 06 Jan 2005 11:43:00 -0800 Subject: festival 1.95 anyone? In-Reply-To: <20050106182502.GA3018@jadzia.bu.edu> References: <20050106045056.GA11568@jadzia.bu.edu> <1105034127.976.9.camel@fury> <20050106182502.GA3018@jadzia.bu.edu> Message-ID: <1105040590.970.31.camel@fury> On Thu, 2005-01-06 at 10:25, Matthew Miller wrote: > FreeTTS and Sphinx4 are both Java, so they're out. Yes but I thought FC4 might have Java built-in . http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00352.html has Thomas Fitzsimmons say that ecj, gij, and Java-Gnome binding are planned to be included. I don't know java myself, but many good things seem to be available in it. I usually stick to c, c++, perl, and python. I think I'd need either groovy or java1.5 features to make some things with java easier to swallow before I look into it some more. > And it actually looks like FreeTTS is derived from "Flite", which is > "festival-light". Yes I seemed to recall that freetts had festival roots, Thats why I was wondering how much they compare. I've used neither actually; It's interesting, but I've been to busy. > Hmmm. Flite may actually be what I want. Yes flite might be what you want. I haven't evaluated any of them myself. I do seem to recall that for making new voices that freetts needed some other software or something. It's been a few months since I read through their web-pages. I also don't know what the availability of other voices is. So I couldn't help Patricio find a Spanish voice. -- http://dmoz.org/profiles/pollei.html http://sourceforge.net/users/stephen_pollei/ http://www.orkut.com/Profile.aspx?uid=2455954990164098214 http://stephen_pollei.home.comcast.net/ GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1 3C01 910F 6BB5 4A7D 9677 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mike at navi.cx Thu Jan 6 19:50:01 2005 From: mike at navi.cx (Mike Hearn) Date: Thu, 06 Jan 2005 19:50:01 +0000 Subject: ssh X forwarding change in FC3 References: <41DD79BB.30304@draigBrady.com> Message-ID: See here for why: http://docs.hp.com/en/T1471-90011/ch01s02.html#babifija > So can we change the upstream default back to what it used to be? I'd like that, this change essentially breaks X11 forwarding entirely ... if you're connecting to a server where root is untrusted then you're at risk without this change, but the flip side is how many people will know/remember to use the magic -Y switch and how often do you forward X connections from places where root is untrusted? Surely if root on the remote box is a bad guy they could hijack X anyway by taking over whatever app you're forwarding? From kewley at gps.caltech.edu Thu Jan 6 19:46:05 2005 From: kewley at gps.caltech.edu (David Kewley) Date: Thu, 6 Jan 2005 11:46:05 -0800 Subject: ssh X forwarding change in FC3 In-Reply-To: <41DD79BB.30304@draigBrady.com> References: <41DD79BB.30304@draigBrady.com> Message-ID: <200501061146.05066.kewley@gps.caltech.edu> P at draigBrady.com wrote on Thursday 06 January 2005 09:47: > The FC3 release notes say: > > "The behavior of ssh clients that are invoked with the -X flag has > changed. In OpenSSH 3.8 and later, X11 forwarding is performed in a > way that applications run as untrusted clients by default. > Previously, X11 forwarding was performed so that applications always > ran as trusted clients. Some applications may not function properly > when run as untrusted clients. To forward X11 so that applications > are run as trusted clients, invoke ssh with the -Y flag instead of > the -X flag, or set ForwardX11Trusted in the ~/.ssh/config file." > > See also: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141515 > > Essentially what this means is that most X applications will > break if forwarded back to a FC3 system with default config. > Now it wouldn't be so bad if they just wouldn't work. > They break in subtle ways usually related to mouse events. > This is just silly IMHO and will cause no end of hassles > for users trying to figure out what's going on and > also be a waste of time for developers of those X apps > who will receive bogus bug reports. > > So can we change the upstream default back to what it used to be? It's not just silly -- it reduces the size of a security hole. If X apps can be fixed to deal with running as an untrusted X client, then they should be fixed. If a given X app can't be run untrusted, I don't know what to suggest. Here's the security problem with running as a trusted client. If I ssh -Y (or ssh with old defaults) into a machine where someone else can use my xauth cookie (e.g. the remote machine has a compromise of my account or of root), then the compromiser can read not only my keystrokes on the remote machine, but my keystrokes on my desktop. That's bad. If I tell ssh to treat tunneled X clients as untrusted (the new default behavior), on the other hand, then remote intruders cannot read my local, trusted-client keystrokes. They can still read my keystrokes on other untrusted clients (e.g. an xterm on a different remote ssh-accessed machine), but that's not quite as bad as the old default. X only has this untrusted/trusted distinction; it probably really needs a widely-used, more featureful security model. All this is *my understanding* of X security, based on reading rather than direct testing; if I got something wrong, please correct me. :) David From jwz at jwz.org Thu Jan 6 19:53:48 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Thu, 06 Jan 2005 11:53:48 -0800 Subject: ssh X forwarding change in FC3 References: <41DD79BB.30304@draigBrady.com> Message-ID: <41DD974C.3BDD4E8B@jwz.org> P at draigBrady.com wrote: > > Essentially what this means is that most X applications will > break if forwarded back to a FC3 system with default config. > Now it wouldn't be so bad if they just wouldn't work. > They break in subtle ways usually related to mouse events. It really is an *extremely* confusing failure mode -- what I was seeing was that tunnelled X programs were mostly working fine, except that XInternAtom was failing at random, causing middle-button paste to stop working between windows, so it was acting like some kind of obscure X server bug! > This is just silly IMHO and will cause no end of hassles > for users trying to figure out what's going on and > also be a waste of time for developers of those X apps > who will receive bogus bug reports. > > So can we change the upstream default back to what it used to be? I do think it's a lame change that should be reverted, but even if not, it absolutely needs better diagnostics. A total failure to forward X connections would be clearer than the current behavior. (For the record, the way to make things work again is to put "ForwardX11Trusted yes" in "~/.ssh/config") -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From ad+lists at uni-x.org Thu Jan 6 20:04:00 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Thu, 06 Jan 2005 21:04:00 +0100 Subject: ssh X forwarding change in FC3 In-Reply-To: <41DD79BB.30304@draigBrady.com> References: <41DD79BB.30304@draigBrady.com> Message-ID: <1105041840.914.370.camel@serendipity.dogma.lan> Am Do, den 06.01.2005 schrieb P at draigBrady.com um 18:47: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141515 > > Essentially what this means is that most X applications will > break if forwarded back to a FC3 system with default config. > Now it wouldn't be so bad if they just wouldn't work. > They break in subtle ways usually related to mouse events. > This is just silly IMHO and will cause no end of hassles > for users trying to figure out what's going on and > also be a waste of time for developers of those X apps > who will receive bogus bug reports. > > So can we change the upstream default back to what it used to be? No, that would be silly. Reverting a security improvement just because users do not RTFM? As commented too in the bugzilla entry the change is made long ago in the upstream OpenSSH. See the FAQ http://www.openssh.org/faq.html#3.12 http://www.openssh.org/faq.html#3.123 > P?draig Brady - http://www.pixelbeat.org Use OpenSSH properly and as documented and all is well. Alexander -- Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.9-1.6_FC2smp Serendipity 21:01:02 up 14 days, 22:45, load average: 1.04, 0.72, 0.54 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From kyrre at solution-forge.net Thu Jan 6 19:22:23 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 06 Jan 2005 20:22:23 +0100 Subject: ssh X forwarding change in FC3 In-Reply-To: <20050106201006.48579d4c@nausicaa.camperquake.de> References: <41DD79BB.30304@draigBrady.com> <20050106201006.48579d4c@nausicaa.camperquake.de> Message-ID: <1105039342.6594.22.camel@localhost.localdomain> tor, 06.01.2005 kl. 20.10 skrev Ralf Ertzinger: > Hi. > > P at draigBrady.com wrote: > > > as untrusted clients. To forward X11 so that applications are run as > > trusted clients, invoke ssh with the -Y flag instead of the -X flag, > > or set ForwardX11Trusted in the ~/.ssh/config file." > > Thanks for the head up, I missed that one, and wondered why X forwarding > behaved strangely sometimes. > > -- > "Here's a warning for all motorists travelling West on the M4. > You're heading towards Wales!" Just add the -Y flag as well, to enable "thrusted" X forwarding. From mattdm at mattdm.org Thu Jan 6 20:03:07 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 6 Jan 2005 15:03:07 -0500 Subject: mkinitrd troubles -- needs "sync"? Message-ID: <20050106200307.GA6887@jadzia.bu.edu> I am fairly frequently running into a problem where mkinitrd generates empty images. (They're about 12k, with no contents.) I can find no rhyme or reason to when this fails, and if you give -v, everything _looks_ to be fine -- but sometimes it isn't. And it's not just mkinitrd -- I experienced the same thing the other day trying to rebuild anaconda on FC3 -- that initrd was ending up empty (even though its tree seemed to be created fine, and the log of the build _says_ everything is copied in -- when the actual file is made, it's empty. But sometimes it works just fine. Rebooting seems to usually make it work for a while too, but that may be a red herring. I'm seeing this _a lot_, yet I can't really find it in bugzilla. Am I going crazy, here? Out of superstition, I'm going to add a "sync; sleep 3" before the umount in the mkinitrd script... that shouldn't be necessary, should it? ... time passes .... HEY! It seems to work fine _every time_ so far once I've done that!!! Anyone care to comment? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dhollis at davehollis.com Thu Jan 6 20:36:24 2005 From: dhollis at davehollis.com (David Hollis) Date: Thu, 06 Jan 2005 15:36:24 -0500 Subject: rawhide report: 20050106 changes In-Reply-To: <1105032123.3799.41.camel@cassandra.boston.redhat.com> References: <200501061337.j06Db3207369@porkchop.devel.redhat.com> <1105022543.4441.9.camel@localhost.localdomain> <1105031367.3885.4.camel@dhollis-lnx.centricconsulting.com> <1105032123.3799.41.camel@cassandra.boston.redhat.com> Message-ID: <1105043785.3885.17.camel@dhollis-lnx.centricconsulting.com> On Thu, 2005-01-06 at 12:22 -0500, David Malcolm wrote: > I see this occasionally too. I've filed a bug report about it here: > https://bugzilla.redhat.com/beta/show_bug.cgi?id=144378 > > Is this what you're seeing, or did the message actually fail to download > properly? > In my cases, it appears that the message downloaded properly since when I click off of it, then click back on it, it appears instantly, there is no delay while it is retrieving the message, etc. My backend is FC3 dovecot as well, fwiw. -- David Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rahulsundaram at yahoo.co.in Thu Jan 6 18:53:10 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Thu, 6 Jan 2005 10:53:10 -0800 (PST) Subject: festival 1.95 anyone? In-Reply-To: <20050106182502.GA3018@jadzia.bu.edu> Message-ID: <20050106185310.21869.qmail@web8504.mail.in.yahoo.com> Hi > FreeTTS and Sphinx4 are both Java, so they're out. not necessarily if they can be made to work with gcj ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From dhollis at davehollis.com Thu Jan 6 20:40:33 2005 From: dhollis at davehollis.com (David Hollis) Date: Thu, 06 Jan 2005 15:40:33 -0500 Subject: ssh X forwarding change in FC3 In-Reply-To: <1105041840.914.370.camel@serendipity.dogma.lan> References: <41DD79BB.30304@draigBrady.com> <1105041840.914.370.camel@serendipity.dogma.lan> Message-ID: <1105044033.3885.20.camel@dhollis-lnx.centricconsulting.com> On Thu, 2005-01-06 at 21:04 +0100, Alexander Dalloz wrote: > > No, that would be silly. Reverting a security improvement just because > users do not RTFM? > > As commented too in the bugzilla entry the change is made long ago in > the upstream OpenSSH. See the FAQ > > http://www.openssh.org/faq.html#3.12 > http://www.openssh.org/faq.html#3.123 > > > P?draig Brady - http://www.pixelbeat.org > > Use OpenSSH properly and as documented and all is well. > I would like to see PermitRootLogin=no in the sshd_config file by default. If I'm not mistaken, that is the default for openssh out of the box, but the installed config (indicates anyway) that PermitRootLogin=yes. With things like the SSH password guessing worm running around, not allowing bad things to get in just because someones root password is weak is not a good thing. -- David Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Thu Jan 6 20:18:13 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 6 Jan 2005 15:18:13 -0500 Subject: festival 1.95 anyone? In-Reply-To: <1105038901.3036.0.camel@p.linuxcenter.cl> References: <20050106045056.GA11568@jadzia.bu.edu> <1105034127.976.9.camel@fury> <20050106182502.GA3018@jadzia.bu.edu> <1105038901.3036.0.camel@p.linuxcenter.cl> Message-ID: <20050106201813.GB7709@jadzia.bu.edu> On Thu, Jan 06, 2005 at 04:15:01PM -0300, Patricio Bruna V wrote: > For default Festival only comes with english voice, how can i get the > others, spanish per se -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rahulsundaram at yahoo.co.in Thu Jan 6 19:47:17 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Thu, 6 Jan 2005 11:47:17 -0800 (PST) Subject: festival 1.95 anyone? In-Reply-To: <1105040590.970.31.camel@fury> Message-ID: <20050106194717.15776.qmail@web8507.mail.in.yahoo.com> --- Stephen Pollei wrote: > On Thu, 2005-01-06 at 10:25, Matthew Miller wrote: > > FreeTTS and Sphinx4 are both Java, so they're out. > Yes but I thought FC4 might have Java built-in . > http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00352.html > has Thomas Fitzsimmons say that > ecj, gij, and Java-Gnome binding are planned to be > included. > > I don't know java myself, but many good things seem > to be available in > it. I usually stick to c, c++, perl, and python. I > think I'd need either > groovy or java1.5 features to make some things with > java easier to > swallow before I look into it some more. the importance here is not specific features or personal preferences. the effort is targetted towards making several open source projects in the java language more widely deployed without adding proprietary java restrictions within it. by enabling a solid free java base fedora and other distros can easily use the important projects like eclipse, openoffice java parts, tomcat etc ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From mattdm at mattdm.org Thu Jan 6 20:17:30 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 6 Jan 2005 15:17:30 -0500 Subject: festival 1.95 anyone? In-Reply-To: <1105040590.970.31.camel@fury> References: <20050106045056.GA11568@jadzia.bu.edu> <1105034127.976.9.camel@fury> <20050106182502.GA3018@jadzia.bu.edu> <1105040590.970.31.camel@fury> Message-ID: <20050106201730.GA7709@jadzia.bu.edu> On Thu, Jan 06, 2005 at 11:43:00AM -0800, Stephen Pollei wrote: > > FreeTTS and Sphinx4 are both Java, so they're out. > Yes but I thought FC4 might have Java built-in . > http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00352.html has Thomas Fitzsimmons say that ecj, gij, and Java-Gnome binding are planned to be included. It'll be interesting to see how well that works. > Yes flite might be what you want. I haven't evaluated any of them > myself. I do seem to recall that for making new voices that freetts > needed some other software or something. It's been a few months since I Sadly, from the docs: As of 1.2 initial scripts have been added to aid the conversion of FestVox voices to Flite. In general the conversion cannot be automatic. For example all specific Scheme code written for a voice needs to be hand converted to C to work in Flite, this can be a major task. I ain't got time for a major task like that. Wish I did, though! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From toshio at tiki-lounge.com Thu Jan 6 21:26:48 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 6 Jan 2005 13:26:48 -0800 Subject: Reopen a request for gpgme in Core In-Reply-To: <41DD7DC0.4050906@math.unl.edu>; from rdieter@math.unl.edu on Thu, Jan 06, 2005 at 12:04:48PM -0600 References: <1104977635.10350.17.camel@Madison.badger.com> <20050106072425.437a2395.fedora@wir-sind-cool.org> <20050106110659.17f329f0.toshio@tiki-lounge.com> <20050106183045.1991bdbb.fedora@wir-sind-cool.org> <41DD7DC0.4050906@math.unl.edu> Message-ID: <20050106132648.A13938@tiki-lounge.com> On Thu, Jan 06, 2005 at 12:04:48PM -0600, Rex Dieter wrote: > Michael Schwendt wrote: > > > GPGME 1.0 and dependencies are in the fedora.us submission list > > already. Bugs: 2178 -> 2179 -> 2180 <- 2185 > > > > Among the things to examine are: > > > > * Dependencies on GPGME 0.4.x: gpa, elmo > > * How are gpa and elmo affected by an upgrade from gpgme 0.4.x? > > AFAIK, gpgme-1.0.0 is binary/api compatible with gpgme-0.4.x (I think > the 0.4.x versions were simply used to denote preleases before 1.0 was done) > gpgme-0.4.x releases aren't entirely ABI/API compatible. So it may depend on the version of 0.4 that they were designed for. Notably, 0.4.0 and 0.4.1 had some major API revisions. While porting sylpheed from 0.3 the documented changes indicated I would need 0.4.5 or above. At that point the ABI changed subtly as the library defaulted to being compiled with large file support. Requires a change to configure.in if you're using certain functions. Also, there are many deprecated functions and structures that may still be present in the code that the gpgme authors aren't guaranteeing will be available through the entire 1.0.x release cycle. Moving from 0.4 to 1.0 will be much easier than moving from 0.3 to 1.0, though as the changes are small and well documented in the info pages and the NEWS file. -Toshio From toshio at tiki-lounge.com Thu Jan 6 21:43:03 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Thu, 6 Jan 2005 13:43:03 -0800 Subject: Reopen a request for gpgme in Core In-Reply-To: <20050106183045.1991bdbb.fedora@wir-sind-cool.org>; from fedora@wir-sind-cool.org on Thu, Jan 06, 2005 at 06:30:45PM +0100 References: <1104977635.10350.17.camel@Madison.badger.com> <20050106072425.437a2395.fedora@wir-sind-cool.org> <20050106110659.17f329f0.toshio@tiki-lounge.com> <20050106183045.1991bdbb.fedora@wir-sind-cool.org> Message-ID: <20050106134303.B13938@tiki-lounge.com> On Thu, Jan 06, 2005 at 06:30:45PM +0100, Michael Schwendt wrote: > On Thu, 6 Jan 2005 11:06:59 -0500, Toshio Kuratomi wrote: > > The current version of the patch can be found here: > > http://www.tiki-lounge.com/~toshio/fedora/sylpheed-gpgme1.0-12.patch > > Thanks. I'm going to apply this and also serve as a guinea pig, because > currently I still use a GPGME 0.3.x enabled Sylpheed. > Thanks for trying to break it... it needs a lot more testing than I can give it :-) Notes on compiling with this: * You'll need to do autoheader; autoconf as the configure.in script has been patched. * Configure needs to be manually prodded with --enable-gpgme I'm attaching my specfile diff against the current fedora cvs sylpheed/devel/sylpheed.spec in case it helps. -Toshio -------------- next part -------------- Index: sylpheed.spec =================================================================== RCS file: /cvs/dist/rpms/sylpheed/devel/sylpheed.spec,v retrieving revision 1.19 diff -u -r1.19 sylpheed.spec --- sylpheed.spec 5 Jan 2005 09:03:58 -0000 1.19 +++ sylpheed.spec 6 Jan 2005 21:38:26 -0000 @@ -1,6 +1,8 @@ +%define _with_gpgme 1 + Name: sylpheed Version: 1.0.0 -Release: 1 +Release: 1.tek.1 License: GPL URL: http://sylpheed.good-day.net/ Group: Applications/Internet @@ -13,6 +15,7 @@ Patch: %{name}-0.8.9-ck.patch Patch1: %{name}-0.8.9-ssl.patch Patch2: sylpheed-default-browser.patch +Patch3: sylpheed-gpgme1.0-12.patch Summary: A GTK+ based, lightweight, and fast email client. %description @@ -35,8 +38,10 @@ %patch -p1 -b .ck %patch1 -p1 -b .ssl %patch2 -p1 -b .default-browser +%patch3 -p0 -b .gpgme %build +autoheader autoconf %configure --enable-ssl %{?_with_gpgme:--enable-gpgme} make @@ -71,6 +76,9 @@ %{_mandir}/man1 %changelog +* Thu Jan 6 2005 Toshio Kuratomi - 1.0.0-1.tek.1 +- Patch to port sylpheed to gpgme 1.0 + * Wed Jan 5 2005 Akira TAGOH - 1.0.0-1 - New upstream release. From stephen_pollei at comcast.net Thu Jan 6 22:01:38 2005 From: stephen_pollei at comcast.net (Stephen Pollei) Date: 06 Jan 2005 14:01:38 -0800 Subject: festival 1.95 anyone? In-Reply-To: <20050106194717.15776.qmail@web8507.mail.in.yahoo.com> References: <20050106194717.15776.qmail@web8507.mail.in.yahoo.com> Message-ID: <1105048899.970.88.camel@fury> On Thu, 2005-01-06 at 11:47, Rahul Sundaram wrote: > the importance here is not specific features or > personal preferences. the effort is targetted towards > making several open source projects in the java > language more widely deployed without adding > proprietary java restrictions within it. True thats why I mentioned that "many good things are available in it", I was merely mentioning that I probably won't personally be writing or editing in Java too soon from now. I obviously think that ignoring FreeTTS and Sphinx4 because they are written in Java is premature. Especially since it seems even a RH8.0 I have laying around seems to include gcj and gij . gij (GNU libgcj) version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) gcj (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) > by enabling a solid free java base fedora and other > distros can easily use the important projects like > eclipse, openoffice java parts, tomcat etc I agree 110% with this. -- http://dmoz.org/profiles/pollei.html http://sourceforge.net/users/stephen_pollei/ http://www.orkut.com/Profile.aspx?uid=2455954990164098214 http://stephen_pollei.home.comcast.net/ GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1 3C01 910F 6BB5 4A7D 9677 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Thu Jan 6 19:47:38 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 6 Jan 2005 14:47:38 -0500 Subject: ssh X forwarding change in FC3 In-Reply-To: <41DD79BB.30304@draigBrady.com> References: <41DD79BB.30304@draigBrady.com> Message-ID: <604aa79105010611476003189@mail.gmail.com> On Thu, 06 Jan 2005 17:47:39 +0000, P at draigbrady.com

wrote: > So can we change the upstream default back to what it used to be? How about you convince the upstream developers at the openssh to switch the default back, instead of laying the burden at the distributor level to customize this. I don't think its reasonable to ask for a security feature to be turned off at the distribution level without a clear understanding as to why the upstream developers decided to enable the extra security layer by default. Have you looked yet to see why the upstream developers decided to make this the default? Whatever reasons you can think of that would be a convincing argument to change this inside Fedora, should be equally convincing to the upstream project developers to get the default changed upstream for greatest benefit and least amount of overall maintaince hassle by each and every distributor. Before seeing if its worth it to change inside Fedora, there has to be an understanding of why the upstream change was made. Even if you don't agree with the change the upstream developers did it for a reason and any discussion that tries to balance the tradeoff between security and functionality must include a rational presentation of both sides. the bugreport you have shown and the mailinglist post you made show one side of the argument, but thats not really enough. if you want to have a constructive dialog about changing this feature, you must be able to point to the upstream developer's rationale for making the default and pinpoint where their reasons are faulty. -jef"i find it somewhat ironic that a tool that describes itself as 'secure shell' can be defaulted too securely"spaleta From florin at andrei.myip.org Thu Jan 6 22:36:09 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 06 Jan 2005 14:36:09 -0800 Subject: rpm --import Message-ID: <1105050969.13497.19.camel@stantz.corp.sgi.com> One thing that i noticed the newbies get confused with is the "rpm -- import (blah)GPG-KEY" trick that has to be done after installing a new system. Please put that info in a more prominent place in the Release Notes or something. Or let yum spew it out if needed. -- Florin Andrei http://florin.myip.org/ From mattdm at mattdm.org Thu Jan 6 23:21:47 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 6 Jan 2005 18:21:47 -0500 Subject: rpm --import In-Reply-To: <1105050969.13497.19.camel@stantz.corp.sgi.com> References: <1105050969.13497.19.camel@stantz.corp.sgi.com> Message-ID: <20050106232147.GA14138@jadzia.bu.edu> On Thu, Jan 06, 2005 at 02:36:09PM -0800, Florin Andrei wrote: > One thing that i noticed the newbies get confused with is the "rpm -- > import (blah)GPG-KEY" trick that has to be done after installing a new > system. > Please put that info in a more prominent place in the Release Notes or > something. Or let yum spew it out if needed. yum *does* spew it out if needed. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dwmw2 at infradead.org Thu Jan 6 23:26:01 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 06 Jan 2005 23:26:01 +0000 Subject: Reopen a request for gpgme in Core In-Reply-To: <20050106072425.437a2395.fedora@wir-sind-cool.org> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106072425.437a2395.fedora@wir-sind-cool.org> Message-ID: <1105053961.5547.83.camel@baythorne.infradead.org> On Thu, 2005-01-06 at 07:24 +0100, Michael Schwendt wrote: > And shouldn't you use Sylpheed rather than Evolution? ;) Does Sylpheed do IMAP over SSH yet? -- dwmw2 From mark at harddata.com Thu Jan 6 23:27:50 2005 From: mark at harddata.com (Mark Lane) Date: Thu, 6 Jan 2005 16:27:50 -0700 Subject: rpm --import In-Reply-To: <20050106232147.GA14138@jadzia.bu.edu> References: <1105050969.13497.19.camel@stantz.corp.sgi.com> <20050106232147.GA14138@jadzia.bu.edu> Message-ID: <200501061627.50187.mark@harddata.com> On January 6, 2005 04:21 pm, Matthew Miller wrote: > On Thu, Jan 06, 2005 at 02:36:09PM -0800, Florin Andrei wrote: > > One thing that i noticed the newbies get confused with is the "rpm -- > > import (blah)GPG-KEY" trick that has to be done after installing a new > > system. > > Please put that info in a more prominent place in the Release Notes or > > something. Or let yum spew it out if needed. > > yum *does* spew it out if needed. yum just tells you that there's no GPG key for the package. It does not tell you how to fix the problem. -- Mark Lane, CET -- mailto:mark at harddata.com Sales Manager -- Hard Data Ltd -- http://www.harddata.com T: 01-780-456-9771 -- F: 01-780-456-9772 11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3 --> Ask me about our New Dual and 4 Way Blade Servers <-- From pnasrat at redhat.com Thu Jan 6 23:40:45 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Thu, 6 Jan 2005 18:40:45 -0500 Subject: rpm --import In-Reply-To: <200501061627.50187.mark@harddata.com> References: <1105050969.13497.19.camel@stantz.corp.sgi.com> <20050106232147.GA14138@jadzia.bu.edu> <200501061627.50187.mark@harddata.com> Message-ID: <20050106234045.GD14042@minimumble.lab.boston.redhat.com> On Thu, Jan 06, 2005 at 04:27:50PM -0700, Mark Lane wrote: > On January 6, 2005 04:21 pm, Matthew Miller wrote: > > On Thu, Jan 06, 2005 at 02:36:09PM -0800, Florin Andrei wrote: > > > One thing that i noticed the newbies get confused with is the "rpm -- > > > import (blah)GPG-KEY" trick that has to be done after installing a new > > > system. > > > Please put that info in a more prominent place in the Release Notes or > > > something. Or let yum spew it out if needed. > > > > yum *does* spew it out if needed. > > yum just tells you that there's no GPG key for the package. It does not tell > you how to fix the problem. See yum-devel for discussion on key retrieval. Paul From jwboyer at jdub.homelinux.org Thu Jan 6 23:28:47 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 06 Jan 2005 17:28:47 -0600 Subject: CVS kernel compile In-Reply-To: <1103720744.8764.10.camel@jdub.homelinux.org> References: <1103594563.6919.2.camel@jdub.homelinux.org> <20041222070134.GB28113@redhat.com> <1103720744.8764.10.camel@jdub.homelinux.org> Message-ID: <1105054127.16242.3.camel@jdub.homelinux.org> On Wed, 2004-12-22 at 07:05 -0600, Josh Boyer wrote: > On Wed, 2004-12-22 at 02:01 -0500, Dave Jones wrote: > > On Mon, Dec 20, 2004 at 08:02:43PM -0600, Josh Boyer wrote: > > > > > > make: *** No rule to make target `download', needed by `sources'. Stop. > > > > > > I can't find the download target anywhere. Am I the only one to see > > > > Its defined in common/Makefile.common. Do you have the common dir checked out too? > > Yes, I do. And I think the fact that it's _not_ defined in > Makefile.common is the problem. But since I have no idea what that > target is supposed to do, I can't fix it :). At least in my cursory > glance I couldn't find a download target or figure out what it does. > > Below is the output from running a 'make sources' done in the devel dir, > on a fresh checkout of the kernel from this morning. Colin saw the same > problem I think, so it's not just me. Well, I am still seeing the above problem after a fresh checkout of kernel from CVS as of 15 minutes ago. I did some poking around with view CVS, and it seems that Arjan added the 'download' target to the TARGETS list in kernel/devel/Makefile (version 1.21). Arjan, can you tell me what the download target is supposed to do, and why it doesn't work? josh From mattdm at mattdm.org Thu Jan 6 23:44:20 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 6 Jan 2005 18:44:20 -0500 Subject: rpm --import In-Reply-To: <200501061627.50187.mark@harddata.com> References: <1105050969.13497.19.camel@stantz.corp.sgi.com> <20050106232147.GA14138@jadzia.bu.edu> <200501061627.50187.mark@harddata.com> Message-ID: <20050106234420.GA15140@jadzia.bu.edu> On Thu, Jan 06, 2005 at 04:27:50PM -0700, Mark Lane wrote: > > yum *does* spew it out if needed. > yum just tells you that there's no GPG key for the package. It does not tell > you how to fix the problem. It told me yesterday, on FC3. Maybe it's a new thing. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From skvidal at phy.duke.edu Fri Jan 7 00:24:24 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 06 Jan 2005 19:24:24 -0500 Subject: rpm --import In-Reply-To: <20050106234045.GD14042@minimumble.lab.boston.redhat.com> References: <1105050969.13497.19.camel@stantz.corp.sgi.com> <20050106232147.GA14138@jadzia.bu.edu> <200501061627.50187.mark@harddata.com> <20050106234045.GD14042@minimumble.lab.boston.redhat.com> Message-ID: <1105057464.18874.4.camel@cutter> > See yum-devel for discussion on key retrieval. > Short version of the plan for this list: Menno Smits has been so kind as to write code that does this: if you have gpgcheck=1 set to on in your repo config it looks for a path to a gpg key in the global settings and/or the repo configuration. If it finds the key and you've not already imported the key into your rpmdb, it will confirm that you want to import it and do so. if you don't choose to import it then, well, that's your problem. -sv From pcompton at proteinmedia.com Fri Jan 7 02:27:57 2005 From: pcompton at proteinmedia.com (Phillip Compton) Date: Thu, 06 Jan 2005 21:27:57 -0500 Subject: Reopen a request for gpgme in Core In-Reply-To: <20050106183045.1991bdbb.fedora@wir-sind-cool.org> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106072425.437a2395.fedora@wir-sind-cool.org> <20050106110659.17f329f0.toshio@tiki-lounge.com> <20050106183045.1991bdbb.fedora@wir-sind-cool.org> Message-ID: <1105064877.3652.3.camel@earlgrey.compton.net> On Thu, 2005-01-06 at 18:30 +0100, Michael Schwendt wrote: > On Thu, 6 Jan 2005 11:06:59 -0500, Toshio Kuratomi wrote: > > > > Two observations: Where's the patch to be found? And shouldn't you use > > > Sylpheed rather than Evolution? ;) > > > > > Heh heh now that it does gpg signing/verification on my box I might start using > > it :-) Truth to tell, there are some features of Evolution I'm somewhat loathe > > to lose so I might have to bounce between the two mailers for a while depending > > on what I'm doing. > > > > The current version of the patch can be found here: > > http://www.tiki-lounge.com/~toshio/fedora/sylpheed-gpgme1.0-12.patch > > Thanks. I'm going to apply this and also serve as a guinea pig, because > currently I still use a GPGME 0.3.x enabled Sylpheed. > > GPGME 1.0 and dependencies are in the fedora.us submission list > already. Bugs: 2178 -> 2179 -> 2180 <- 2185 > > Among the things to examine are: > > * Dependencies on GPGME 0.4.x: gpa, elmo > * Dependencies on GPGME 0.3.x: cryptplug, seahorse, sylpheed-claws > (seahorse is very old, but pcomptom said maybe he will continue it) Actually, newer seahorse requires gpgme-1.0.x as well Phil From mattdm at mattdm.org Fri Jan 7 02:22:17 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 6 Jan 2005 21:22:17 -0500 Subject: mkinitrd troubles -- needs "sync"? In-Reply-To: <20050106200307.GA6887@jadzia.bu.edu> References: <20050106200307.GA6887@jadzia.bu.edu> Message-ID: <20050107022217.GA19612@jadzia.bu.edu> Well, don't all jump on this at once. Is no one else seeing this problem? I guess it's possible it's something in our local configuration, but it seems highly unlikely since we don't really touch anything relevant to this. Anyway, filed in Bugzilla: -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at wir-sind-cool.org Fri Jan 7 03:31:49 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 7 Jan 2005 04:31:49 +0100 Subject: Reopen a request for gpgme in Core In-Reply-To: <1105053961.5547.83.camel@baythorne.infradead.org> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106072425.437a2395.fedora@wir-sind-cool.org> <1105053961.5547.83.camel@baythorne.infradead.org> Message-ID: <20050107043149.7fe1feba.fedora@wir-sind-cool.org> On Thu, 06 Jan 2005 23:26:01 +0000, David Woodhouse wrote: > Does Sylpheed do IMAP over SSH yet? Typo? Or do you really mean SSH? Because IMAP over SSL is supported for a long time. From dennis at ausil.us Fri Jan 7 03:48:44 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 6 Jan 2005 21:48:44 -0600 Subject: Reopen a request for gpgme in Core In-Reply-To: <20050106183045.1991bdbb.fedora@wir-sind-cool.org> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106110659.17f329f0.toshio@tiki-lounge.com> <20050106183045.1991bdbb.fedora@wir-sind-cool.org> Message-ID: <200501062148.50705.dennis@ausil.us> Once upon a time Thursday 06 January 2005 11:30 am, Michael Schwendt wrote: > On Thu, 6 Jan 2005 11:06:59 -0500, Toshio Kuratomi wrote: > > > Two observations: Where's the patch to be found? And shouldn't you use > Among the things to examine are: > > * Dependencies on GPGME 0.4.x: gpa, elmo > * Dependencies on GPGME 0.3.x: cryptplug, seahorse, sylpheed-claws > (seahorse is very old, but pcomptom said maybe he will continue it) > * In which way or whether cryptplug uses gpgsm? > * Is cryptplug of any use in FC3? AFAIK cryptplug is no longer of use in FC3 kmail in kde 3.3 has the functionality added i think mutt may have used it to sign mails also but i dont think there was ever a client patch to take advantage it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From byte at aeon.com.my Fri Jan 7 05:14:43 2005 From: byte at aeon.com.my (Colin Charles) Date: Fri, 07 Jan 2005 13:14:43 +0800 Subject: Updates on the Fedora CVS server In-Reply-To: <41DD7AE2.6070005@gmx.net> References: <41DD7AE2.6070005@gmx.net> Message-ID: <1105074883.3872.176.camel@localhost.localdomain> On Thu, 2005-01-06 at 18:52 +0100, Stefan Hoelldampf wrote: > > - Fedora Core: > > http://www.redhat.com/mailman/listinfo/fedora-cvs-commits > > Is it correct that no CVS-mail has reached this mailing list yet? Yes. Mail has been steadily flowing for fedora-extras-commits though -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From fedora at wir-sind-cool.org Fri Jan 7 07:48:10 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 7 Jan 2005 08:48:10 +0100 Subject: Reopen a request for gpgme in Core In-Reply-To: <200501062148.50705.dennis@ausil.us> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106110659.17f329f0.toshio@tiki-lounge.com> <20050106183045.1991bdbb.fedora@wir-sind-cool.org> <200501062148.50705.dennis@ausil.us> Message-ID: <20050107084810.09c3aa38.fedora@wir-sind-cool.org> On Thu, 6 Jan 2005 21:48:44 -0600, Dennis Gilmore wrote: > > Among the things to examine are: > > > > * Dependencies on GPGME 0.4.x: gpa, elmo > > * Dependencies on GPGME 0.3.x: cryptplug, seahorse, sylpheed-claws > > (seahorse is very old, but pcomptom said maybe he will continue it) > > * In which way or whether cryptplug uses gpgsm? > > * Is cryptplug of any use in FC3? > > AFAIK cryptplug is no longer of use in FC3 kmail in kde 3.3 has the > functionality added i think mutt may have used it to sign mails also but i > dont think there was ever a client patch to take advantage it. Good. Then the only dependency on gpgme 0.3.x is Sylpheed-claws (well, and Sylpheed in Fedora Core for people like me who rebuild it with GPGME privately). Has anyone any objections against rebuilding GPGME 0.3.x without support for GPGSM? That would enable us to get rid of the dependency on newpg (via /usr/bin/gpgsm). It would also make libksba 0.4.x obsolete, and upgradable to libksba 0.9.x as needed by GNUPG 2. The build dependency on gpgsm could be dropped anyway, and the install-time dependency would no longer be needed. Does any package exist which would use GPGME 0.3.x + GPGSM and is not included in Extras? Left would be GPGME 0.4.x as used by elmo and gpa. Neither one uses GPGSM either, so GPGME 0.4.x could also be rebuilt without gpgsm dependency. Then, both gpa and elmo build against GPGME 1.0.x, so no urgent need to keep GPGME 0.4.x, not even as gpgme04 package. Still to check: gpa and elmo build with GPGME 1.0.x, but do they work correctly? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nphilipp at redhat.com Fri Jan 7 09:16:01 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 07 Jan 2005 10:16:01 +0100 Subject: ssh X forwarding change in FC3 In-Reply-To: <1105044033.3885.20.camel@dhollis-lnx.centricconsulting.com> References: <41DD79BB.30304@draigBrady.com> <1105041840.914.370.camel@serendipity.dogma.lan> <1105044033.3885.20.camel@dhollis-lnx.centricconsulting.com> Message-ID: <1105089361.19192.15.camel@wombat.tiptoe.de> On Thu, 2005-01-06 at 15:40 -0500, David Hollis wrote: > On Thu, 2005-01-06 at 21:04 +0100, Alexander Dalloz wrote: > > > > > No, that would be silly. Reverting a security improvement just because > > users do not RTFM? > > > > As commented too in the bugzilla entry the change is made long ago in > > the upstream OpenSSH. See the FAQ > > > > http://www.openssh.org/faq.html#3.12 > > http://www.openssh.org/faq.html#3.123 > > > > > P?draig Brady - http://www.pixelbeat.org > > > > Use OpenSSH properly and as documented and all is well. > > > > I would like to see PermitRootLogin=no in the sshd_config file by > default. If I'm not mistaken, that is the default for openssh out of > the box, but the installed config (indicates anyway) that > PermitRootLogin=yes. With things like the SSH password guessing worm > running around, not allowing bad things to get in just because someones > root password is weak is not a good thing. Unfortunately this completely breaks remote installs (e.g. via VNC) because you can install the machine but cannot log into it after installation because you don't have a normal user to start with (that is created in firstboot which didn't work over say serial console last I checked). IMO it'd be better to do some quality checks on the password assigned to root during the installation and if it fails some dialog similar to the one you get when you disable the firewall (which let's you proceed anyway after a warning). Perhaps there could be a switch "Allow remote root logins over SSH" in the same dialog where the root password is specified. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From smooge at gmail.com Thu Jan 6 19:47:34 2005 From: smooge at gmail.com (Stephen J. Smoogen) Date: Thu, 6 Jan 2005 12:47:34 -0700 Subject: Compiling code that uses kernel headers Message-ID: <80d7e4090501061147250fc3fb@mail.gmail.com> I am working with the libpcap + ringbuffer and trying to get it moved from Debian to Red Hat. The Debian/Slackware code depends upon /usr/include/linux/system.h which has the kernel version of asm.h linked to if for the platform. For i386 this is asm-i386.h which has the macro mb(); that the pcap ringbuffer code relies on to make sure some obscure race conditions are taken of. [I do not know what the race condition is beyond it talking to the kernel half of the ringbuffer.] Anyway it compiles well on the other Linux versions we have because it can find the call to mb() without problems. On Fecore Core 3 (and most likely RHEL4) it does not work at all because of kernel system.h now in /lib/modules/.... What is the best way of dealing with items like this? -- Stephen J Smoogen. CSIRT/Linux System Administrator From pbrobinson at gmail.com Fri Jan 7 09:28:52 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 7 Jan 2005 17:28:52 +0800 Subject: Compiling code that uses kernel headers In-Reply-To: <80d7e4090501061147250fc3fb@mail.gmail.com> References: <80d7e4090501061147250fc3fb@mail.gmail.com> Message-ID: <5256d0b050107012856da4a91@mail.gmail.com> > I am working with the libpcap + ringbuffer and trying to get it moved > from Debian to Red Hat. The Debian/Slackware code depends upon > /usr/include/linux/system.h which has the kernel version of asm.h > linked to if for the platform. For i386 this is asm-i386.h which has > the macro mb(); that the pcap ringbuffer code relies on to make sure > some obscure race conditions are taken of. [I do not know what the > race condition is beyond it talking to the kernel half of the > ringbuffer.] > > Anyway it compiles well on the other Linux versions we have because it > can find the call to mb() without problems. On Fecore Core 3 (and most > likely RHEL4) it does not work at all because of kernel system.h now > in /lib/modules/.... > > What is the best way of dealing with items like this? There is an bugzilla item filed under devel for the glibc-kernheaders package with a request to update them from 2.4 to 2.6 headers. There are a number of packages that have issues with compiling using the 2.4 headers, especially things that rely on new features like v4l2 etc. To work around it I've justsym linked /usr/include/linux to the /lib/modules/... directory. Not sure if this is the right way or will cause any problems but its seems to be working allright to date. Pete From arjanv at redhat.com Fri Jan 7 11:04:02 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 07 Jan 2005 12:04:02 +0100 Subject: Compiling code that uses kernel headers In-Reply-To: <80d7e4090501061147250fc3fb@mail.gmail.com> References: <80d7e4090501061147250fc3fb@mail.gmail.com> Message-ID: <1105095842.4179.23.camel@laptopd505.fenrus.org> On Thu, 2005-01-06 at 12:47 -0700, Stephen J. Smoogen wrote: > I am working with the libpcap + ringbuffer and trying to get it moved > from Debian to Red Hat. The Debian/Slackware code depends upon > /usr/include/linux/system.h which has the kernel version of asm.h > linked to if for the platform. For i386 this is asm-i386.h which has > the macro mb(); that the pcap ringbuffer code relies on to make sure > some obscure race conditions are taken of. [I do not know what the > race condition is beyond it talking to the kernel half of the > ringbuffer.] fix the app. mb() is not an exported feature from the kernel (headers) to userspace, the way the kernel implements that is *INTERNAL* and may be privileged to ring 0. Applications need to do their own barriers, and I suspect glibc provides functionality for this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Fri Jan 7 10:59:13 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 07 Jan 2005 10:59:13 +0000 Subject: Reopen a request for gpgme in Core In-Reply-To: <20050107043149.7fe1feba.fedora@wir-sind-cool.org> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106072425.437a2395.fedora@wir-sind-cool.org> <1105053961.5547.83.camel@baythorne.infradead.org> <20050107043149.7fe1feba.fedora@wir-sind-cool.org> Message-ID: <1105095553.5547.105.camel@baythorne.infradead.org> On Fri, 2005-01-07 at 04:31 +0100, Michael Schwendt wrote: > On Thu, 06 Jan 2005 23:26:01 +0000, David Woodhouse wrote: > > > Does Sylpheed do IMAP over SSH yet? > > Typo? Or do you really mean SSH? > Because IMAP over SSL is supported for a long time. No, I mean SSH. SSH uses keys from ssh-agent and doesn't want to store my password for itself. SSH does compression. SSH lets me in to machines which don't have a public-facing IMAP d?mon. For that matter, SSH lets me in to machines which don't even have a public IP address, because it can be configured with a 'ProxyCommand' for certain hosts -- so for hosts in '*.baythorne.internal' it knows it shouldn't try a DNS lookup and direct connection; instead it should run "ssh baythorne.infradead.org exec netcat $host $port" Evolution, just like pine, mutt, etc., can get at its IMAP folders by running "ssh -C mail.baythorne.internal exec /usr/sbin/imapd". Can Sylpheed? -- dwmw2 From fedora-devel at camperquake.de Fri Jan 7 11:08:19 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Fri, 7 Jan 2005 12:08:19 +0100 Subject: mkinitrd troubles -- needs "sync"? In-Reply-To: <20050106200307.GA6887@jadzia.bu.edu> References: <20050106200307.GA6887@jadzia.bu.edu> Message-ID: <20050107120819.72660d8e@nausicaa.camperquake.de> Hi. Matthew Miller wrote: > I am fairly frequently running into a problem where mkinitrd generates > empty images. (They're about 12k, with no contents.) I can find no rhyme > or reason to when this fails, and if you give -v, everything _looks_ to > be fine -- but sometimes it isn't. Would that be ext2 style initrd files or cpio style initrd files? -- Leichen sind Menschen wie Du und ich, nur tot. From fedora-devel at camperquake.de Fri Jan 7 11:09:52 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Fri, 7 Jan 2005 12:09:52 +0100 Subject: rpm --import In-Reply-To: <1105050969.13497.19.camel@stantz.corp.sgi.com> References: <1105050969.13497.19.camel@stantz.corp.sgi.com> Message-ID: <20050107120952.615cb1bb@nausicaa.camperquake.de> Hi. Florin Andrei wrote: > One thing that i noticed the newbies get confused with is the "rpm -- > import (blah)GPG-KEY" trick that has to be done after installing a new > system. I'm sure there is a good reason why the keys are not imported by the installer by default, would someone be so kind to tell me why? -- University degrees are a bit like adultery: you may not want to get involved with that sort of thing, but you don't want to be thought incapable. -- Sir Peter Imbert From jkt at redhat.com Fri Jan 7 12:21:11 2005 From: jkt at redhat.com (Jay Turner) Date: Fri, 7 Jan 2005 07:21:11 -0500 Subject: rpm --import In-Reply-To: <20050107120952.615cb1bb@nausicaa.camperquake.de> References: <1105050969.13497.19.camel@stantz.corp.sgi.com> <20050107120952.615cb1bb@nausicaa.camperquake.de> Message-ID: <20050107122111.GA3972@redhat.com> On Fri, Jan 07, 2005 at 12:09:52PM +0100, Ralf Ertzinger wrote: > Florin Andrei wrote: > > > One thing that i noticed the newbies get confused with is the "rpm -- > > import (blah)GPG-KEY" trick that has to be done after installing a new > > system. > > I'm sure there is a good reason why the keys are not imported by the installer > by default, would someone be so kind to tell me why? Security. It's generally a good idea to validate that the key you're adding to the keyring is really the one that you think it is, and if this keyring addition were done automatically, then someone could switch out the keys, thus a malicious key would be automatically added to the keyring. Things start to go downhill from that point. - jkt -- --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--* Jay Turner, QA Technical Lead jkt at redhat.com Red Hat, Inc. If I had only known, I would have been a locksmith. - Albert Einstein From fedora-devel at camperquake.de Fri Jan 7 12:25:25 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Fri, 7 Jan 2005 13:25:25 +0100 Subject: rpm --import In-Reply-To: <20050107122111.GA3972@redhat.com> References: <1105050969.13497.19.camel@stantz.corp.sgi.com> <20050107120952.615cb1bb@nausicaa.camperquake.de> <20050107122111.GA3972@redhat.com> Message-ID: <20050107132525.7c575f19@nausicaa.camperquake.de> Hi. Jay Turner wrote: > Security. It's generally a good idea to validate that the key you're > adding to the keyring is really the one that you think it is, and if > this keyring addition were done automatically, then someone could switch > out the keys, thus a malicious key would be automatically added to the > keyring. Things start to go downhill from that point. Well, I generally have to trust the media I install from anyway, so what is the point in treating a single file different from all the others? From hk at isphuset.no Fri Jan 7 12:31:36 2005 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Fri, 07 Jan 2005 13:31:36 +0100 Subject: rpm --import In-Reply-To: <20050107132525.7c575f19@nausicaa.camperquake.de> References: <1105050969.13497.19.camel@stantz.corp.sgi.com> <20050107120952.615cb1bb@nausicaa.camperquake.de> <20050107122111.GA3972@redhat.com> <20050107132525.7c575f19@nausicaa.camperquake.de> Message-ID: <1105101096.29187.20.camel@linux.local> On Fri, 2005-01-07 at 13:25, Ralf Ertzinger wrote: > Hi. > > Jay Turner wrote: > > > Security. It's generally a good idea to validate that the key you're > > adding to the keyring is really the one that you think it is, and if > > this keyring addition were done automatically, then someone could switch > > out the keys, thus a malicious key would be automatically added to the > > keyring. Things start to go downhill from that point. > > Well, I generally have to trust the media I install from anyway, so what > is the point in treating a single file different from all the others? I also trust the media I install from. Someone with access to replace the key in the first place would also be able to add the key to the keyring automagically. But the result that I have seen because of the need to manually add the key to the keyring is that people tend to just disable gpg checking in the yum config. Btw, is the key even installed in minimal config? I couldn't find it. Thus becoming vulnerable if some mirror site gets hacked. -HK From symbiont at berlios.de Fri Jan 7 12:35:27 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Fri, 7 Jan 2005 20:35:27 +0800 Subject: Requesting for Blockers Message-ID: <200501072035.28622.symbiont@berlios.de> How do we go about requested for FC4 blocker status on a bug? >From kernel 2.6.8, the default codepage for utf8, cp437.ko has been left out of the config. This causes kernel oopses when listing a vfat directory which uses unicode characters (chinese in my case). Maybe if this code page is so critical as to cause an oops, maybe it should be statically compiled. I dunno. If it's an upstream deal, I hope someone kind enough can pass on the word. Bug in question: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129966 thanks, -- -jeff From jkt at redhat.com Fri Jan 7 12:43:00 2005 From: jkt at redhat.com (Jay Turner) Date: Fri, 7 Jan 2005 07:43:00 -0500 Subject: rpm --import In-Reply-To: <20050107132525.7c575f19@nausicaa.camperquake.de> References: <1105050969.13497.19.camel@stantz.corp.sgi.com> <20050107120952.615cb1bb@nausicaa.camperquake.de> <20050107122111.GA3972@redhat.com> <20050107132525.7c575f19@nausicaa.camperquake.de> Message-ID: <20050107124300.GC3972@redhat.com> On Fri, Jan 07, 2005 at 01:25:25PM +0100, Ralf Ertzinger wrote: > Hi. > > Jay Turner wrote: > > > Security. It's generally a good idea to validate that the key you're > > adding to the keyring is really the one that you think it is, and if > > this keyring addition were done automatically, then someone could switch > > out the keys, thus a malicious key would be automatically added to the > > keyring. Things start to go downhill from that point. > > Well, I generally have to trust the media I install from anyway, so what > is the point in treating a single file different from all the others? There's a hierarchy there. Step 1 is validating that the signing key you have indeed came from the source you think it did (in this case Red Hat.) Once you establish that it's a known entity, then all of the packages on the Red Hat media (be it RHEL or Fedora) are signed with that key, so at that point you know that all of the packages originated from Red Hat as well (or the Fedora project in the case of Fedora.) So you don't "have to trust the media [you] install from anyway" as the that content can be verified just as the key itself can. A good analogy would be your house/apartment/flat. In order to be secure, you more than likely make sure that the windows and exterior doors of the place are secure, and not bother to secure all of the interior doors as well. That's because if a thief can't get through the exterior protection, there's no reason to worry about him getting through the interior protection. Same thing with the software. If you know that the key that signed all of the packages is "good", and you know that all of the packages are signed with the "good" key, then you know that all of the software resulting from that install is also "good" (from a trusted standpoint.) - jkt -- --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--* Jay Turner, QA Technical Lead jkt at redhat.com Red Hat, Inc. If I had only known, I would have been a locksmith. - Albert Einstein From fedora-devel at camperquake.de Fri Jan 7 13:17:22 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Fri, 7 Jan 2005 14:17:22 +0100 Subject: rpm --import In-Reply-To: <20050107124300.GC3972@redhat.com> References: <1105050969.13497.19.camel@stantz.corp.sgi.com> <20050107120952.615cb1bb@nausicaa.camperquake.de> <20050107122111.GA3972@redhat.com> <20050107132525.7c575f19@nausicaa.camperquake.de> <20050107124300.GC3972@redhat.com> Message-ID: <20050107141722.084b8b1e@nausicaa.camperquake.de> Hi. Jay Turner wrote: > There's a hierarchy there. Step 1 is validating that the signing key > you have indeed came from the source you think it did (in this case Red > Hat.) Once you establish that it's a known entity, then all of the > packages on the Red Hat media (be it RHEL or Fedora) are signed with > that key, so at that point you know that all of the packages originated > from Red Hat as well (or the Fedora project in the case of Fedora.) So > you don't "have to trust the media [you] install from anyway" as the > that content can be verified just as the key itself can. OK, I think there is a slight misunderstanding. I did not mean to say that I will swallow everything that says "Fedora Core 3 DVD" (or whatever) on it and treat it as genuine. I can download it from anywhere, and check the published checksums (which are signed) against my image. Leaving discussions about hashing algorithms aside, I have thus established that my media is good. So is the key, which is included on the media. So we have two cases: 1) People who check that the media is genuine (signed checksums), and thus trust the media, and trust the keys on it, so the keys can be imported by the installer. 2) People who do not check the media (or have it checked by their admin or another knowledgeable person), and can so be persuaded to install almost anything. If the media is compromised, all bets are off, anyway. If the media is genuine nonetheless, they get the keys they need to trust the automatic updates (which is a good thing, in my book). Maybe I am missing something here. PS: the above just holds for media based installations. -- "Wie? Man kann einen Computer auch ausschalten ?" Kasuga in AnimeGer From buildsys at redhat.com Fri Jan 7 13:40:06 2005 From: buildsys at redhat.com (Build System) Date: Fri, 7 Jan 2005 08:40:06 -0500 Subject: rawhide report: 20050107 changes Message-ID: <200501071340.j07De6X29432@porkchop.devel.redhat.com> Updated Packages: alsa-lib-1.0.7-1 ---------------- * Thu Jan 06 2005 Colin Walters 1.0.7-1 - New upstream version bison-2.0-4 ----------- * Thu Jan 06 2005 Roland McGrath - 2.0-4 - update upstream URLs, add doc files (#144346) * Thu Jan 06 2005 Roland McGrath - 2.0-3 - missing %defattr for subpackage * Thu Jan 06 2005 Roland McGrath - 2.0-2 - split liby.a into bison-devel package cups-1:1.1.23-2 --------------- * Thu Jan 06 2005 Tim Waugh 1.1.23-2 - Fixed patch from STR #1023. device-mapper-1.00.20-1 ----------------------- * Thu Jan 06 2005 Alasdair Kergon - 1.00.20-1 - Minor fixes and updates - see WHATS_NEW. dhcp-8:3.0.2rc3-1 ----------------- * Thu Jan 06 2005 Jason Vas Dias 8:3.0.2rc3.1 - still need an epoch to get past nvre test * Thu Jan 06 2005 Jason Vas Dias 3.0.2rc3-1 - fix bug 144417: much improved dhclient-script * Thu Jan 06 2005 Jason Vas Dias 3.0.2rc3-1 - Upgrade to latest release from ISC, which includes most of our - recent patches anyway. dovecot-0.99.11-10.devel ------------------------ * Thu Jan 06 2005 John Dennis 0.99.11-10.devel - fix bug #133618, removed LITERAL+ capability from capability string * Wed Jan 05 2005 John Dennis 0.99.11-9.devel - fix bug #134325, stop dovecot during installation * Wed Jan 05 2005 John Dennis 0.99.11-8.devel - fix bug #129539, dovecot starts too early, set chkconfig to 65 35 to match cyrus-imapd - also delete some old commented out code from SSL certificate creation gamin-0.0.20-1 -------------- * Thu Jan 06 2005 Daniel Veillard 0.0.20-1 - Frederic Crozat seems to have found the GList corruption which may fix - Frederic Crozat also fixed poll only mode gcc4-4.0.0-0.18 --------------- * Thu Jan 06 2005 Jakub Jelinek 4.0.0-0.18 - update from trunk - fix PRs tree-optimization/19060, rtl-optimization/18861, tree-optimization/18828, rtl-optimization/19012, tree-optimization/19283 gsl-1.6-1 --------- * Thu Jan 06 2005 Ivana Varekova - update to 1.6 kernel-2.6.10-1.1069_FC4 ------------------------ * Thu Jan 06 2005 Rik van Riel - update to latest xen-unstable tree - fix up Xen compile with -bk9, mostly pudding * Thu Jan 06 2005 Dave Jones - Rebase to 2.6.10-bk9 * Tue Jan 04 2005 Dave Jones - Rebase to 2.6.10-bk7 - Add periodic slab debug checker. lvm2-2.00.32-2.0 ---------------- * Thu Jan 06 2005 Alasdair Kergon - 2.00.32-2.0 - Remove temporary /sbin symlinks no longer needed. - Include read-only pool support in the build. lynx-2.8.5-21 ------------- * Thu Jan 06 2005 Tim Waugh 2.8.5-21 - Fixed

wrote: > > So can we change the upstream default back to what it used to be? > > How about you convince the upstream developers at the openssh to > switch the default back, instead of laying the burden at the > distributor level to customize this. I don't think its reasonable to Though generally I agree it's a good idea to push stuff like this upstream, based on the last discussion on this list with one of the OpenSSH developers, I have to wonder if it's going to do any good in this case. And based on Havoc Pennington's recent response to this thread, if he's correct, then it's a silly default which should be reverted. A security measure which nearly *everybody* will need to disable is no security measure at all. -Paul "here's to hoping lsh will soon become functionally equivalent enough to replace openssh soon" Iadonisi (With apologies to Jeff ;-)) -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From fedora at wir-sind-cool.org Fri Jan 7 21:23:18 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 7 Jan 2005 22:23:18 +0100 Subject: Reopen a request for gpgme in Core In-Reply-To: <20050107130154.A6528@tiki-lounge.com> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106072425.437a2395.fedora@wir-sind-cool.org> <20050106110659.17f329f0.toshio@tiki-lounge.com> <20050107181533.1d5d28ea.fedora@wir-sind-cool.org> <20050107130154.A6528@tiki-lounge.com> Message-ID: <20050107222318.6bb3bf61.fedora@wir-sind-cool.org> On Fri, 7 Jan 2005 13:01:54 -0800, Toshio Kuratomi wrote: > > > The current version of the patch can be found here: > > > http://www.tiki-lounge.com/~toshio/fedora/sylpheed-gpgme1.0-12.patch > > > > First attempt at getting the entire suite built, has been unsuccessful. > > Trying to sign a message gives an error dialog: > > > > Error Could not find any key associated with currently selected > > key id `mschwendt'. > > > > Should I go back to GPGME 0.4.x? Without having looked into it at > > all, what has gone wrong? > > > Is gpgme-1.0 using gnupg2 as its backend or gpg-1.x? Uninstalling GnuPG 1.9.11 fixed it. The gpgme-1.0.2 package is built against gnupg >= 1.2.2, but $ rpm -qR gpgme | grep gnupg gnupg >= 0:1.2.2 gnupg2 >= 0:1.9.6 which means I had to install the gnupg2 package. And with that one installed, Sylpheed breaks. > Is your mschwendt key > available to the version of gpg being used? Of course. Both gpg and gpg2. From jspaar at myrealbox.com Fri Jan 7 22:28:36 2005 From: jspaar at myrealbox.com (Jack Spaar) Date: Fri, 07 Jan 2005 14:28:36 -0800 Subject: festival 1.95 anyone? References: <20050106045056.GA11568@jadzia.bu.edu> Message-ID: On Wed, 05 Jan 2005 23:50:56 -0500, Matthew Miller wrote: > I don't know anything about the science behind this, but text-to-speech > is, y'know, cool. Festival 2.0 was supposed to be out a few months ago, > but it seems to be late. In the meantime, 1.9.5 is out there, and has a > few nice things -- particularly, the CMU_ARCTIC voices sound really good. > Is anyone working on updating this? If not, I'll look, although it's way > outside of areas where I know what I'm doing. :) > An active shepherd of Festival packages for Fedora would be much appreciated by folks who use gnopernicus (the screenreader component of gnome's assistive technology support). --Jack From alan at redhat.com Fri Jan 7 22:30:35 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 7 Jan 2005 17:30:35 -0500 Subject: ssh X forwarding change in FC3 In-Reply-To: <1105123735.4464.5.camel@localhost.localdomain> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> Message-ID: <20050107223035.GA11186@devserv.devel.redhat.com> On Fri, Jan 07, 2005 at 01:48:55PM -0500, Havoc Pennington wrote: > So, anyone who claims that "trusted X" is more secure is basically > making a "concrete blocks not connected to the Internet are secure" > argument. I'm not so sure. ssh Xnest's work well From jspaleta at gmail.com Fri Jan 7 21:48:35 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 7 Jan 2005 16:48:35 -0500 Subject: ssh X forwarding change in FC3 In-Reply-To: <1105132719.12083.5.camel@va.local.linuxlobbyist.org> References: <41DD79BB.30304@draigBrady.com> <604aa79105010611476003189@mail.gmail.com> <1105132719.12083.5.camel@va.local.linuxlobbyist.org> Message-ID: <604aa791050107134867f6cc3d@mail.gmail.com> On Fri, 07 Jan 2005 16:18:39 -0500, Paul Iadonisi wrote: > Though generally I agree it's a good idea to push stuff like this > upstream, based on the last discussion on this list with one of the > OpenSSH developers, I have to wonder if it's going to do any good in > this case. Oh i didnt say it would do any good ultimately. My point is upstream's perspective should be presented as early on in the discussion as possible if there are rational reasons upstream used to justify the change. If there aren't rational reasons, a reference to an upstream discussion where the developers were told they are on-crack would suffice. Either upstream has a rational reason or they don't, either way the discussion should happen upstream first and that discussion cited as reference for downstream discussions. > And based on Havoc Pennington's recent response to this thread, if > he's correct, then it's a silly default which should be reverted. if.... I saw some assumption making about upstream's motivation.. i didn't see a citation reference to an upstream discussion. I'd like to see some effort to present upstream's point of view...fairly...before we starting etching our guesses of their intentions in stone. Maybe they are actually crazy.... but i'd much rather see a reference to previous upstream discussion that gives perspective, than watch a one-sided argument. -jef From eli.carter at inet.com Fri Jan 7 23:05:00 2005 From: eli.carter at inet.com (Eli Carter) Date: Fri, 07 Jan 2005 17:05:00 -0600 Subject: ssh X forwarding change in FC3 In-Reply-To: <20050107223035.GA11186@devserv.devel.redhat.com> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> <20050107223035.GA11186@devserv.devel.redhat.com> Message-ID: <41DF159C.5010700@inet.com> Alan Cox wrote: > On Fri, Jan 07, 2005 at 01:48:55PM -0500, Havoc Pennington wrote: > >>So, anyone who claims that "trusted X" is more secure is basically >>making a "concrete blocks not connected to the Internet are secure" >>argument. > > > I'm not so sure. ssh Xnest's work well That piques my interest... but I'm not sure I follow. Can you elaborate a little? How does xnest relate to the security concerns? Thanks, Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- ------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Tektronix Texas, LLC formerly Inet Technologies, Inc. ------------------------------------------------------------------------ From pri.rhl3 at iadonisi.to Fri Jan 7 23:19:26 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Fri, 07 Jan 2005 18:19:26 -0500 Subject: ssh X forwarding change in FC3 In-Reply-To: <604aa791050107134867f6cc3d@mail.gmail.com> References: <41DD79BB.30304@draigBrady.com> <604aa79105010611476003189@mail.gmail.com> <1105132719.12083.5.camel@va.local.linuxlobbyist.org> <604aa791050107134867f6cc3d@mail.gmail.com> Message-ID: <1105139966.12083.14.camel@va.local.linuxlobbyist.org> On Fri, 2005-01-07 at 16:48 -0500, Jeff Spaleta wrote: > On Fri, 07 Jan 2005 16:18:39 -0500, Paul Iadonisi wrote: > > Though generally I agree it's a good idea to push stuff like this > > upstream, based on the last discussion on this list with one of the > > OpenSSH developers, I have to wonder if it's going to do any good in > > this case. > > Oh i didnt say it would do any good ultimately. My point is > upstream's perspective should be presented as early on in the > discussion as possible if there are rational reasons upstream used to > justify the change. Yeah, I know. I just wasn't looking forward to that discussion. > If there aren't rational reasons, a reference to > an upstream discussion where the developers were told they are > on-crack would suffice. Looks like the beginning of one such discussion starts here: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=108544011109065&w=2 I'm in the middle of reading it now. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From alan at redhat.com Fri Jan 7 23:36:32 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 7 Jan 2005 18:36:32 -0500 Subject: ssh X forwarding change in FC3 In-Reply-To: <41DF159C.5010700@inet.com> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> <20050107223035.GA11186@devserv.devel.redhat.com> <41DF159C.5010700@inet.com> Message-ID: <20050107233632.GB16534@devserv.devel.redhat.com> On Fri, Jan 07, 2005 at 05:05:00PM -0600, Eli Carter wrote: > >I'm not so sure. ssh Xnest's work well > > That piques my interest... but I'm not sure I follow. Can you elaborate > a little? How does xnest relate to the security concerns? Its the standard way to isolate untrusted desktops From eli.carter at inet.com Fri Jan 7 23:51:06 2005 From: eli.carter at inet.com (Eli Carter) Date: Fri, 07 Jan 2005 17:51:06 -0600 Subject: ssh X forwarding change in FC3 In-Reply-To: <20050107233632.GB16534@devserv.devel.redhat.com> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> <20050107223035.GA11186@devserv.devel.redhat.com> <41DF159C.5010700@inet.com> <20050107233632.GB16534@devserv.devel.redhat.com> Message-ID: <41DF206A.7030300@inet.com> Alan Cox wrote: > On Fri, Jan 07, 2005 at 05:05:00PM -0600, Eli Carter wrote: > >>>I'm not so sure. ssh Xnest's work well >> >>That piques my interest... but I'm not sure I follow. Can you elaborate >>a little? How does xnest relate to the security concerns? > > > Its the standard way to isolate untrusted desktops Thanks. That got me enough to Google with. :) Of interest to this discussion, I found this document: http://www.giac.org/practical/GCIH/Holger_Van_Lengerich_GCIH.pdf I have not read this through yet, but I found this comment in the introductory information intriguing: "Today X11 forwarding is disabled in most default configurations of SSH. As X11 forwarding is a very convenient feature, there always will be a temptation for operating system distributors, system administrators and user to enable it per default." Hoping I'm adding signal and not noise, Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- ------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Tektronix Texas, LLC formerly Inet Technologies, Inc. ------------------------------------------------------------------------ From michael.favia at insitesinc.com Sat Jan 8 01:11:33 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Fri, 07 Jan 2005 19:11:33 -0600 Subject: rpm --import In-Reply-To: <1105050969.13497.19.camel@stantz.corp.sgi.com> References: <1105050969.13497.19.camel@stantz.corp.sgi.com> Message-ID: <41DF3345.1040400@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florin Andrei wrote: | One thing that i noticed the newbies get confused with is the "rpm -- | import (blah)GPG-KEY" trick that has to be done after installing a new | system. | | Please put that info in a more prominent place in the Release Notes or | something. Or let yum spew it out if needed. | Is there a reason that we can't import the fedora projects GPG key with by default on initial install? I realize the others should be added but the system is as safe as the original install image anyways no? It would save a lot of people (everyone) a little trouble and a few people (new users) a lot of trouble. They can learn to import a key if they need to add a new repo. Perhaps im missing a security issue here though. - -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB3zNEBVsNYjF2rDYRAs8cAJ9tI7AdE8yqlVNiErS9e3XlQf4xOwCfUFWs 2c66CBivHuvPY27Zo/9P/os= =DYKB -----END PGP SIGNATURE----- From michael.favia at insitesinc.com Sat Jan 8 01:18:32 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Fri, 07 Jan 2005 19:18:32 -0600 Subject: rpm --import In-Reply-To: <41DEA125.4000402@nc.rr.com> References: <1105050969.13497.19.camel@stantz.corp.sgi.com> <20050107120952.615cb1bb@nausicaa.camperquake.de> <20050107122111.GA3972@redhat.com> <20050107132525.7c575f19@nausicaa.camperquake.de> <20050107124300.GC3972@redhat.com> <20050107141722.084b8b1e@nausicaa.camperquake.de> <41DEA125.4000402@nc.rr.com> Message-ID: <41DF34E8.7090402@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeff Johnson wrote: | In general, public keys cannot be automagically imported without violating | some user's definition of "trust", and hence the --import procedure is | manual, or asks | "Ok to import(Y/n)?", in order for the end-user to confirm that the | mechanism of | signed packages is consistent with the end-user's definition of "trust". The can we automate this confirmation on installation or at least on first invocation? Save everyone the headache. - -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB3zToBVsNYjF2rDYRAhToAJ0QYD+KcA4LZGbFSFjHO0cmzDlsZACfeXrj ap1S5R6eJFpEJz8/DkXFBDc= =IK/p -----END PGP SIGNATURE----- From jspaleta at gmail.com Fri Jan 7 21:20:59 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 7 Jan 2005 16:20:59 -0500 Subject: Stand-alone kernel module packages now in rawhide.. the dawn of a new era In-Reply-To: <200412221250.iBMCoDr02816@porkchop.devel.redhat.com> References: <200412221250.iBMCoDr02816@porkchop.devel.redhat.com> Message-ID: <604aa7910501071320172b0162@mail.gmail.com> On Wed, 22 Dec 2004 07:50:13 -0500, Build System wrote: > New package GFS-kernel > GFS-kernel - The Global File System kernel modules > New package cman-kernel > cman-kernel - The Cluster Manager kernel modules > New package dlm-kernel > dlm-kernel - The Distributed Lock Manager kernel modules. > New package gnbd-kernel > gnbd-kernel - The kernel module for GFS's Network Block Device My understanding is these package are pretty much the first packages inside Fedora Core to provide kernel modules outside the actual kernel package. I'm looking at the package-naming and they don't follow the kernel module package naming conventions at fedora.us or livna use to ease some of the upgrade problems associated with stand-alone kernel modules. I'm not qualified to comment as to whether or not the package in development are going to have problems upgrading cleanly or not.. but I don't think i've seen a discussion about the approach these packages are taking constrasted to what the addon repositories have been doing. I think we would all benefit if there was a discussion about a consistent way to handle kernel-module packages inside and outside Core. I refer to the fedora.us package naming guidelines http://fedoraproject.org/wiki/PackageNamingGuidelines section C-5 but other 3rd party use similar naming schemes to deal with the stand-alone kernel module issue Are the standalone kernel module packages in development parallel installable? Is yum and up2date as configured in the development tree prepared to treat these packages as parallel installable? If the FC packager has found a way to solve the problems the fedora.us naming scheme tries to address, i think everyone would benifit by seeing a discussion of the merits in the -devel-list sooner rather than later, so we can have a consistent way to deal with kernel-module packaging moving forward. -jef From cs at zip.com.au Sat Jan 8 04:27:46 2005 From: cs at zip.com.au (Cameron Simpson) Date: Sat, 8 Jan 2005 15:27:46 +1100 Subject: Reopen a request for gpgme in Core In-Reply-To: <1105095553.5547.105.camel@baythorne.infradead.org> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106072425.437a2395.fedora@wir-sind-cool.org> <1105053961.5547.83.camel@baythorne.infradead.org> <20050107043149.7fe1feba.fedora@wir-sind-cool.org> <1105095553.5547.105.camel@baythorne.infradead.org> Message-ID: <20050108042746.GC18246@cskk.homeip.net> On 10:59 07 Jan 2005, David Woodhouse wrote: | On Fri, 2005-01-07 at 04:31 +0100, Michael Schwendt wrote: | > On Thu, 06 Jan 2005 23:26:01 +0000, David Woodhouse wrote: | > | > > Does Sylpheed do IMAP over SSH yet? | > | > Typo? Or do you really mean SSH? | > Because IMAP over SSL is supported for a long time. | | No, I mean SSH. SSH uses keys from ssh-agent and doesn't want to store | my password for itself. SSH does compression. SSH lets me in to machines | which don't have a public-facing IMAP d??mon. [...] You don't need your mail reader to be extended. I do IMAP over SSH as described here: http://www.cskk.ezoshosting.com/cs/css/ssh.html#rnc__remote_netcat In short, I bring up a local interface (lo:1, lo:2, etc) for each remote site whose services I desire via ssh and establish tcpio/ssh/netcat tunnels to each service at boot. Then connecting to the imap port on my "local.zip" interface tunnels via ssh to zip and connects to their IMAP service. in this way _no_ mail reader needs extending because each remote service is apparently a local ordinary service. I find it extremely convenient. Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ We're supposed to be the guys with Freedom and Democracy right? Well, how come the Russians get to shell their Parliament and we don't get to do it to ours? Mike Holmes, fofp at festival.ed.ac.uk From mattdm at mattdm.org Sat Jan 8 03:44:11 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 7 Jan 2005 22:44:11 -0500 Subject: festival 1.95 anyone? In-Reply-To: References: <20050106045056.GA11568@jadzia.bu.edu> Message-ID: <20050108034411.GA2060@jadzia.bu.edu> On Fri, Jan 07, 2005 at 02:28:36PM -0800, Jack Spaar wrote: > > I don't know anything about the science behind this, but text-to-speech > > is, y'know, cool. Festival 2.0 was supposed to be out a few months ago, > > but it seems to be late. In the meantime, 1.9.5 is out there, and has a > > few nice things -- particularly, the CMU_ARCTIC voices sound really good. > > Is anyone working on updating this? If not, I'll look, although it's way > > outside of areas where I know what I'm doing. :) > An active shepherd of Festival packages for Fedora would be much > appreciated by folks who use gnopernicus (the screenreader component of > gnome's assistive technology support). Well, my first attempt at a 1.95 package results in a bunch of this sorta thing: festival> (help) SIOD ERROR: unbound variable : help which is as far as I got before having to work on other things. (There's also a problem with linking to (unnumbered) libestbase.so and libeststring.so -- need to get that straightened out.) You can get what I made so far at , if you're interested in further work. I'll probably poke at it more eventually if no one more qualified shows interest. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From hp at redhat.com Sat Jan 8 06:45:39 2005 From: hp at redhat.com (Havoc Pennington) Date: Sat, 08 Jan 2005 01:45:39 -0500 Subject: ssh X forwarding change in FC3 In-Reply-To: <20050107223035.GA11186@devserv.devel.redhat.com> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> <20050107223035.GA11186@devserv.devel.redhat.com> Message-ID: <1105166739.5141.21.camel@localhost.localdomain> On Fri, 2005-01-07 at 17:30 -0500, Alan Cox wrote: > On Fri, Jan 07, 2005 at 01:48:55PM -0500, Havoc Pennington wrote: > > So, anyone who claims that "trusted X" is more secure is basically > > making a "concrete blocks not connected to the Internet are secure" > > argument. > > I'm not so sure. ssh Xnest's work well > True, I can imagine that working since Xnest presumably wouldn't access anything outside of the Xnest window. I'd still argue that the feature should be something like: Panel -> Actions -> Log In to Remote Machine Dialog asks for password if no authorized_keys Xnest is launched on remote machine containing a desktop session And the "trusted X" behavior should be turned on specifically for that feature since we know it works, but still not by default. Same idea as targeted SELinux policy. Havoc From meetkaustubhghosh at vsnl.net Sat Jan 8 05:22:02 2005 From: meetkaustubhghosh at vsnl.net (Kaustubh Ghosh) Date: Sat, 08 Jan 2005 10:52:02 +0530 Subject: Just dial "1902424500500" from your BSNL, MTNL phones ifyou are in INDIA Message-ID: <41DF6DFA.9040000@vsnl.net> `Dear Sirs/Madams/Friends, Hope many of you are already in the pipeline of contribution for the Tsunami Victims. This notification is for those who have missed the column in the daily newspaper mentioning that the BSNL, MTNL have opened up new service by which you can contribute at least Re.1 (INR) by just dialing *1902424500500*. You will also get thanks for your contribution. It's my request to you all those in India to dial this number and ask your fellow relatives or neighbors to dial the no. Imagine India being a country with such a large population contributing Re.1 by every single individual by just dialing a number would definitely raise a considerable amount. *Kindly pass on this mail to every single individual staying in India* With regards, Kaustubh Ghosh Kolkata -------------- next part -------------- An HTML attachment was scrubbed... URL: From walters at redhat.com Sat Jan 8 10:14:41 2005 From: walters at redhat.com (Colin Walters) Date: Sat, 08 Jan 2005 05:14:41 -0500 Subject: ssh X forwarding change in FC3 In-Reply-To: <20050107223035.GA11186@devserv.devel.redhat.com> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> <20050107223035.GA11186@devserv.devel.redhat.com> Message-ID: <1105179281.10578.5.camel@nexus.verbum.private> On Fri, 2005-01-07 at 17:30 -0500, Alan Cox wrote: > On Fri, Jan 07, 2005 at 01:48:55PM -0500, Havoc Pennington wrote: > > So, anyone who claims that "trusted X" is more secure is basically > > making a "concrete blocks not connected to the Internet are secure" > > argument. > > I'm not so sure. ssh Xnest's work well Interesting. Might this make a good default when you forward with -X? ssh sets up a new Xnest and runs the app inside there? From fedora-devel at camperquake.de Sat Jan 8 12:06:48 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Sat, 8 Jan 2005 13:06:48 +0100 Subject: ssh X forwarding change in FC3 In-Reply-To: <20050107223035.GA11186@devserv.devel.redhat.com>; from alan@redhat.com on Fri, Jan 07, 2005 at 05:30:35PM -0500 References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> <20050107223035.GA11186@devserv.devel.redhat.com> Message-ID: <20050108130648.A9897@ryoko.camperquake.de> On Fri, Jan 07, 2005 at 05:30:35PM -0500, Alan Cox wrote: > I'm not so sure. ssh Xnest's work well The only problem with that is that Xnest is rarely installed in my experience, even if the "normal" X environment is there. From dwmw2 at infradead.org Sat Jan 8 12:04:35 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 08 Jan 2005 12:04:35 +0000 Subject: Reopen a request for gpgme in Core In-Reply-To: <20050108042746.GC18246@cskk.homeip.net> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106072425.437a2395.fedora@wir-sind-cool.org> <1105053961.5547.83.camel@baythorne.infradead.org> <20050107043149.7fe1feba.fedora@wir-sind-cool.org> <1105095553.5547.105.camel@baythorne.infradead.org> <20050108042746.GC18246@cskk.homeip.net> Message-ID: <1105185875.6500.33.camel@localhost.localdomain> On Sat, 2005-01-08 at 15:27 +1100, Cameron Simpson wrote: > in this way _no_ mail reader needs extending because each remote service is > apparently a local ordinary service. > > I find it extremely convenient. It's a cute hack, but it doesn't seem to be as convenient as the way that Evolution, pine and mutt do it for me transparently. Especially as the mail servers I use tend not to have an IMAP d?mon listening at all, and as it still doesn't perform the authentication for you in the way that using SSH directly does -- your IMAP client would still need to store a password. -- dwmw2 From arjanv at redhat.com Sat Jan 8 12:07:42 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 08 Jan 2005 13:07:42 +0100 Subject: Stand-alone kernel module packages now in rawhide.. the dawn of a new era In-Reply-To: <604aa7910501071320172b0162@mail.gmail.com> References: <200412221250.iBMCoDr02816@porkchop.devel.redhat.com> <604aa7910501071320172b0162@mail.gmail.com> Message-ID: <1105186062.4196.16.camel@laptopd505.fenrus.org> On Fri, 2005-01-07 at 16:20 -0500, Jeff Spaleta wrote: > On Wed, 22 Dec 2004 07:50:13 -0500, Build System wrote: > > New package GFS-kernel > > GFS-kernel - The Global File System kernel modules > > New package cman-kernel > > cman-kernel - The Cluster Manager kernel modules > > New package dlm-kernel > > dlm-kernel - The Distributed Lock Manager kernel modules. > > New package gnbd-kernel > > gnbd-kernel - The kernel module for GFS's Network Block Device > > > My understanding is these package are pretty much the first packages > inside Fedora Core > to provide kernel modules outside the actual kernel package. I do wonder though why they aren't just patched into the regular kernel rpm... Would make a lot more sense for something provided in the core distro.... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Sat Jan 8 12:36:13 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 8 Jan 2005 07:36:13 -0500 Subject: ssh X forwarding change in FC3 In-Reply-To: <1105179281.10578.5.camel@nexus.verbum.private> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> <20050107223035.GA11186@devserv.devel.redhat.com> <1105179281.10578.5.camel@nexus.verbum.private> Message-ID: <20050108123613.GA15233@jadzia.bu.edu> On Sat, Jan 08, 2005 at 05:14:41AM -0500, Colin Walters wrote: > > I'm not so sure. ssh Xnest's work well > Interesting. Might this make a good default when you forward with -X? > ssh sets up a new Xnest and runs the app inside there? I don't think so. That's way too much running of things you didn't ask for for ssh to be doing. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jwz at jwz.org Sat Jan 8 12:45:58 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Sat, 08 Jan 2005 04:45:58 -0800 Subject: what USB-2 CF reader is alleged to work? Message-ID: <41DFD606.6F35FCAA@jwz.org> I'm sorry for asking what you may think is a total newbie question, but my inability to reliably get pictures off my camera has reached comical proportions at this point. In the last few years, I've gone through permutations of three different motherboards, three different CF readers, and some subset of RH8, RH9, FC2, and FC3, and to this day, the best way I've found to get pictures off my camera's card has been "plug it into my girlfriend's mac, and use scp." So here is my question: Are any of you running FC3 and able to get pictures off of a CompactFlash card at USB-2 speeds? If so, what CF reader are you using? Because I want to go out and buy one of those. The set of readers I have tried recently are: - Dazzle USB 2.0 reader, no model number apparent; - SanDisk ImageMate SDDR-31 USB 1.0 reader; - (another USB 1.0 reader that I don't have here at the moment, but that came with my Canon 10-D camera). All of them do this when I plug them in (card present or not): usb 5-1: new full speed USB device using address 52 usb 5-1: device not accepting address 52, error -71 usb 5-1: new full speed USB device using address 53 usb 5-1: device not accepting address 53, error -71 Both ehci-hcd and uhci_hcd get loaded. This is after installing davidz's newly-non-broken version of hald (bug 142183). The Dazzle doesn't work at all on an OSX Mac, but the other two do. I have, at various times, seen all three of these work eratically on previous versions of Linux, though I think the last time was FC2. I have, in fact, seen the Dazzle work at USB-2 speeds, but not lately. "Eratically" means that generally they would work immediately after I rebooted the machine, and I could plug/unplug them right after that, and they'd continue working; but if I tried to use them again a few hours later, the only way to make them work would be to reboot again. No amount of rmmod would bring joy (though some would bring complete wedgedness.) -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From buildsys at redhat.com Sat Jan 8 13:22:58 2005 From: buildsys at redhat.com (Build System) Date: Sat, 8 Jan 2005 08:22:58 -0500 Subject: rawhide report: 20050108 changes Message-ID: <200501081322.j08DMwW20729@porkchop.devel.redhat.com> Updated Packages: alsa-lib-1.0.7-2 ---------------- * Sat Jan 08 2005 Colin Walters 1.0.7-2 - New patch alsa-lib-1.0.7-asym-config.patch, sets up asym in the default config file and makes it easy to make it the default via an environment variable. Also increases the default dmix buffer variables. - Mark /etc/alsa/alsa.conf as a config file, and use sysconfdir variable alsa-utils-1.0.7-2 ------------------ * Sat Jan 08 2005 Colin Walters 1.0.7-2 - New patch alsa-utils-1.0.7-alsa-launch.patch, adds the alsa-launch command. - New source file xinit-alsa-launch.sh, integrates alsa-launch into X startup - BR xorg-x11-devel * Thu Jan 06 2005 Colin Walters 1.0.7-1 - New upstream version bitstream-vera-fonts-1.10-5 --------------------------- * Sat Jan 08 2005 Florian La Roche - rebuilt to get rid of legacy selinux filecontexts checkpolicy-1.20.1-1 -------------------- * Fri Jan 07 2005 Dan Walsh 1.20.1-1 - Update for version increase at NSA device-mapper-1.00.21-1 ----------------------- * Fri Jan 07 2005 Alasdair Kergon - 1.00.21-1 - Fix (harmless) unintended warning messages. dhcpv6-0.10-9 ------------- dovecot-0.99.13-1.devel ----------------------- * Thu Jan 06 2005 John Dennis 0.99.13-1.devel - bring up to date with latest upstream, 0.99.13, bug #143707 also fix bug #14462, bad dovecot-uid macro name grep-2.5.1-47 ------------- * Fri Jan 07 2005 Tim Waugh 2.5.1-47 - Run 'make check'. - Fixed -w handling for EGexecute. Now 'make check' passes. - Cache MB_CUR_MAX value in egf-speedup patch. - Fixed variable shadowing in egf-speedup patch. - Removed redundant (and incorrect) code in prline. * Fri Jan 07 2005 Tim Waugh 2.5.1-46 - More -w tests from Jakub Jelinek. - Rebased on 2.5.1a. kernel-2.6.10-1.1074_FC4 ------------------------ * Fri Jan 07 2005 Dave Jones - Santa came to Notting's house too. (another new card reader) - Rebase to 2.6.10-bk10 libselinux-1.20.1-1 ------------------- * Fri Jan 07 2005 Dan Walsh 1.20.1-1 - Update to latest from upstream * Just changing version number to match upstream libusb-0.1.8-5 -------------- * Sat Jan 08 2005 Florian La Roche - rebuilt to get rid of legacy selinux filecontexts * Tue Jun 15 2004 Elliot Lee - rebuilt lvm2-2.00.33-1.0 ---------------- * Fri Jan 07 2005 Alasdair Kergon - 2.00.33-1.0 - pvcreate wipes ext label - several clvm fixes parted-1.6.20-1 --------------- * Fri Jan 07 2005 Chris Lumens 1.6.20-1 - Updated to 1.6.20 (#139257, #142100). - Updated DASD and AIX patches for 1.6.20. policycoreutils-1.20.1-1 ------------------------ * Mon Jan 03 2005 Dan Walsh 1.20.1-1 - Update to latest from NSA * Merged fixfiles rewrite from Dan Walsh. * Merged restorecon patch from Dan Walsh. procps-3.2.4-2 -------------- * Fri Jan 07 2005 Karel Zak 3.2.4-2 - fix sysctl errno usage (#144459) * Wed Dec 01 2004 Karel Zak 3.2.4-1 - update to new upstream release * Mon Nov 01 2004 Karel Zak 3.2.3-6 - update FAQ - update spec description - fix text in .noproc patch - fix segv fault if cpu number exceeding 38 (#137159) pydict-0.3.0-8 -------------- * Sat Jan 08 2005 Florian La Roche - rebuild to get rid of legacy selinux filecontexts rpmdb-fedora-1:4-0.20050108 --------------------------- selinux-doc-1.16.1-1 -------------------- * Fri Jan 07 2005 Dan Walsh 1.16-1 - Upgrade to match NSA * Updated more sections of module report. system-logviewer-0.9.13-1 ------------------------- * Fri Jan 07 2005 Chris Lumens 0.9.13-1 - Don't crash if there's no $LANG environment variable (#144370). tetex-2.0.2-28 -------------- * Fri Jan 07 2005 Jindrich Novy 2.0.2-28 - update texi2html to 1.72 (#143854) - update makej patch to fix parallel builds (#143354) From christof at damian.net Sat Jan 8 13:47:00 2005 From: christof at damian.net (Christof Damian) Date: Sat, 8 Jan 2005 14:47:00 +0100 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: <41DFD606.6F35FCAA@jwz.org> References: <41DFD606.6F35FCAA@jwz.org> Message-ID: <20050108134700.GF22280@batman.gotham.krass.com> On Sat, 08 Jan 2005, Jamie Zawinski wrote: > I'm sorry for asking what you may think is a total newbie question, but > my inability to reliably get pictures off my camera has reached comical > proportions at this point. In the last few years, I've gone through > permutations of three different motherboards, three different CF > readers, and some subset of RH8, RH9, FC2, and FC3, and to this day, the > best way I've found to get pictures off my camera's card has been "plug > it into my girlfriend's mac, and use scp." This is exactly the same experience I have, even including the "girlfriend's mac" bit. I have an lexar usb-2 reader and a nikon coolpix 5400. I always blamed it on the motherboard, but it seems i am not alone. christof -- Christof Damian christof at damian.net From thuforuk at yahoo.co.uk Sat Jan 8 14:39:54 2005 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Sat, 08 Jan 2005 14:39:54 +0000 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: <41DFD606.6F35FCAA@jwz.org> References: <41DFD606.6F35FCAA@jwz.org> Message-ID: <41DFF0BA.6090708@yahoo.co.uk> Jamie Zawinski wrote: > I'm sorry for asking what you may think is a total newbie question, but > my inability to reliably get pictures off my camera has reached comical > proportions at this point. In the last few years, I've gone through > permutations of three different motherboards, three different CF > readers, and some subset of RH8, RH9, FC2, and FC3, and to this day, the > best way I've found to get pictures off my camera's card has been "plug > it into my girlfriend's mac, and use scp." > > So here is my question: > > Are any of you running FC3 and able to get pictures off of a > CompactFlash card at USB-2 speeds? If so, what CF reader are you using? Because I want to go out and buy one of those. Hi Jamie, I happen to have Belkin CF card reader (http://catalog.belkin.com/IWCatProductPage.process?Merchant_Id=&Section_Id=200516&pcount=&Product_Id=122859&Section.Section_Path=%2FROOT%2FUSB%2FMediaReaders%2Fct_Id%3E#) that works without problems. It's USB 1.1 so not too fast. Works with RH 9, Fedora Core 2 and 3. My motherboard is Epox 8KHA+ with latest BIOS -- I had to update BIOS because when the card reader was plugged in during reboot and a CF card was in, BIOS hanged. Had to remove flash card and reboot again. No problem after BIOS upgrade. Regards, Dariusz -- Dariusz J. Garbowski From shiva at sewingwitch.com Sat Jan 8 14:47:10 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 08 Jan 2005 06:47:10 -0800 Subject: Stand-alone kernel module packages now in rawhide.. the dawn of a new era In-Reply-To: <604aa7910501071320172b0162@mail.gmail.com> References: <200412221250.iBMCoDr02816@porkchop.devel.redhat.com> <604aa7910501071320172b0162@mail.gmail.com> Message-ID: <44478C3117FB0435325D0507@[10.0.0.4]> --On Friday, January 07, 2005 4:20 PM -0500 Jeff Spaleta wrote: > I think we would all benefit if there was a discussion about a > consistent way to handle kernel-module packages inside and outside > Core. This sounds like it would be nice for supporting "experimental" features. I've been wanting to try some of the interesting and more esoteric iptables modules that won't make it into the upstream kernel, such as U32 (classification) and TARPIT (disposition), and it seems like they'd be good candidates for this kind of packaging. (The userspace part already supports dynamic loading of modules.) From alan at redhat.com Sat Jan 8 14:57:43 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 8 Jan 2005 09:57:43 -0500 Subject: ssh X forwarding change in FC3 In-Reply-To: <1105166739.5141.21.camel@localhost.localdomain> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> <20050107223035.GA11186@devserv.devel.redhat.com> <1105166739.5141.21.camel@localhost.localdomain> Message-ID: <20050108145743.GB24206@devserv.devel.redhat.com> On Sat, Jan 08, 2005 at 01:45:39AM -0500, Havoc Pennington wrote: > Panel -> Actions -> Log In to Remote Machine ssh does not require Gnome. > And the "trusted X" behavior should be turned on specifically for that > feature since we know it works, but still not by default. Same idea as > targeted SELinux policy. I think the policy you need for -X is tricky to do without ssh and gnome co-operation (or local patching as the realistic version). That is to have the first security blocked operation stick up a dialogue for the user. I don't see how that gets done with openssh base however From alan at redhat.com Sat Jan 8 14:59:09 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 8 Jan 2005 09:59:09 -0500 Subject: ssh X forwarding change in FC3 In-Reply-To: <20050108130648.A9897@ryoko.camperquake.de> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> <20050107223035.GA11186@devserv.devel.redhat.com> <20050108130648.A9897@ryoko.camperquake.de> Message-ID: <20050108145909.GC24206@devserv.devel.redhat.com> On Sat, Jan 08, 2005 at 01:06:48PM +0100, Ralf Ertzinger wrote: > On Fri, Jan 07, 2005 at 05:30:35PM -0500, Alan Cox wrote: > > > I'm not so sure. ssh Xnest's work well > > The only problem with that is that Xnest is rarely installed in my > experience, even if the "normal" X environment is there. So install it 8) emacs is regularly installed on my systems but I fix that with rpm -e. From symbiont at berlios.de Sat Jan 8 15:03:01 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sat, 8 Jan 2005 23:03:01 +0800 Subject: Stand-alone kernel module packages now in rawhide.. the dawn of a new era In-Reply-To: <1105186062.4196.16.camel@laptopd505.fenrus.org> References: <200412221250.iBMCoDr02816@porkchop.devel.redhat.com> <604aa7910501071320172b0162@mail.gmail.com> <1105186062.4196.16.camel@laptopd505.fenrus.org> Message-ID: <200501082303.01888.symbiont@berlios.de> On Saturday 08 January 2005 20:07, Arjan van de Ven wrote: > I do wonder though why they aren't just patched into the regular > kernel rpm... Would make a lot more sense for something provided in > the core distro.... I agree. (For whatever amount of weight that means.) The kernel-module packages should be in Extras if anything. Modules should just be patched into kernel for Core. thanks, -- -jeff From alan at redhat.com Sat Jan 8 15:08:37 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 8 Jan 2005 10:08:37 -0500 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: <41DFF0BA.6090708@yahoo.co.uk> References: <41DFD606.6F35FCAA@jwz.org> <41DFF0BA.6090708@yahoo.co.uk> Message-ID: <20050108150837.GE24206@devserv.devel.redhat.com> On Sat, Jan 08, 2005 at 02:39:54PM +0000, Dariusz J. Garbowski wrote: > I happen to have Belkin CF card reader I'm using a mix of Scan (ie no-name Chinese import) and a couple of other USB readers without problems. > My motherboard is Epox 8KHA+ with latest BIOS -- I had to update BIOS > because when the card reader was plugged in during reboot and a CF card > was in, BIOS hanged. Had to remove flash card and reboot again. No > problem after BIOS upgrade. Very common, especially with USB2 capable devices and older boards. One to beware of before buying a USB keyboard with "neat" MMC/SD or CF slot in it From jspaleta at gmail.com Sat Jan 8 15:49:30 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 8 Jan 2005 10:49:30 -0500 Subject: Stand-alone kernel module packages now in rawhide.. the dawn of a new era In-Reply-To: <1105186062.4196.16.camel@laptopd505.fenrus.org> References: <200412221250.iBMCoDr02816@porkchop.devel.redhat.com> <604aa7910501071320172b0162@mail.gmail.com> <1105186062.4196.16.camel@laptopd505.fenrus.org> Message-ID: <604aa79105010807497f0037fc@mail.gmail.com> On Sat, 08 Jan 2005 13:07:42 +0100, Arjan van de Ven wrote: > I do wonder though why they aren't just patched into the regular kernel > rpm... Would make a lot more sense for something provided in the core > distro.... I disagree. I think having at least one stand alone kernel-module package in Core that serves as an example of how to package stand-alone modules serves a significant purpose. I realize you're not fond of the concept of stand-alone module packages in general. But the fact remains that addon packagers do have to deal with it, and I think the community benefits at large if how to deal with stand-alone kernel packages equitably became a concern inside Core, so that can we hammer out a standard way to do this as part of the the Core development tree testing process. I also find the idea of putting every non-standard module for Core that is not in the upstream kernel inside the kernel package contrary to the 'upstream upstream upstream' mantra fedora project seems to project. I can understand patching in functionality that has to be patched in because it can't be modularized. But for downstream module additions inside Core, why shouldn't they be packaged as standalone? When we finally have to start talking about moving stuff between Core and Extras to change the size of the Core, keep these kernel modules as stand-alone leaves the clustering functionality on the table as something to be moved into Extras. -jef From arjanv at redhat.com Sat Jan 8 16:06:06 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 08 Jan 2005 17:06:06 +0100 Subject: Stand-alone kernel module packages now in rawhide.. the dawn of a new era In-Reply-To: <604aa79105010807497f0037fc@mail.gmail.com> References: <200412221250.iBMCoDr02816@porkchop.devel.redhat.com> <604aa7910501071320172b0162@mail.gmail.com> <1105186062.4196.16.camel@laptopd505.fenrus.org> <604aa79105010807497f0037fc@mail.gmail.com> Message-ID: <1105200367.4196.25.camel@laptopd505.fenrus.org> On Sat, 2005-01-08 at 10:49 -0500, Jeff Spaleta wrote: > On Sat, 08 Jan 2005 13:07:42 +0100, Arjan van de Ven wrote: > > I do wonder though why they aren't just patched into the regular kernel > > rpm... Would make a lot more sense for something provided in the core > > distro.... > > I disagree. I think having at least one stand alone kernel-module > package in Core that serves as an example of how to package > stand-alone modules serves a significant purpose. I don't see why Extras can't do this > I also find the idea of putting every non-standard module for Core > that is not in the upstream kernel inside the kernel package contrary > to the 'upstream upstream upstream' mantra fedora project seems to > project. I can understand patching in functionality that has to be > patched in because it can't be modularized. But for downstream module > additions inside Core, why shouldn't they be packaged as standalone? Because it's a major logistical pain when doing an security erratum, especially when it's an urgent one. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Sat Jan 8 16:19:04 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 8 Jan 2005 11:19:04 -0500 Subject: Stand-alone kernel module packages now in rawhide.. the dawn of a new era In-Reply-To: <1105200367.4196.25.camel@laptopd505.fenrus.org> References: <200412221250.iBMCoDr02816@porkchop.devel.redhat.com> <604aa7910501071320172b0162@mail.gmail.com> <1105186062.4196.16.camel@laptopd505.fenrus.org> <604aa79105010807497f0037fc@mail.gmail.com> <1105200367.4196.25.camel@laptopd505.fenrus.org> Message-ID: <604aa791050108081938e4cc9e@mail.gmail.com> On Sat, 08 Jan 2005 17:06:06 +0100, Arjan van de Ven wrote: > Because it's a major logistical pain when doing an security erratum, > especially when it's an urgent one. And the logistics of this will be less for Extras? If the logistical cost of stand-alone modules inside Core is too burdensome, I'm fine with fedora project stating that stand alone kernel modules wont be allow even in Extras and all modules will be included in the Core kernel as a matter of policy. But i think its not equitable to push a deep logistical problem out of Core into Extras, especially since some of the work to make stand-alone kernel modules easier to package are probably going to require changes to how the kernel is packaged inside Core. And i want to see that dialog as part of the development tree testing process instead of push outside of Core to languish. -jef From hp at redhat.com Sat Jan 8 16:54:05 2005 From: hp at redhat.com (Havoc Pennington) Date: Sat, 08 Jan 2005 11:54:05 -0500 Subject: ssh X forwarding change in FC3 In-Reply-To: <20050108145743.GB24206@devserv.devel.redhat.com> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> <20050107223035.GA11186@devserv.devel.redhat.com> <1105166739.5141.21.camel@localhost.localdomain> <20050108145743.GB24206@devserv.devel.redhat.com> Message-ID: <1105203245.5141.33.camel@localhost.localdomain> On Sat, 2005-01-08 at 09:57 -0500, Alan Cox wrote: > On Sat, Jan 08, 2005 at 01:45:39AM -0500, Havoc Pennington wrote: > > Panel -> Actions -> Log In to Remote Machine > > ssh does not require Gnome. > People can use it without GNOME if they want, sure. We still have to provide a good default system. ssh already has a way to do this with pluggable GUI dependency (ssh- askpass-gnome etc.) Havoc From hp at redhat.com Sat Jan 8 16:59:58 2005 From: hp at redhat.com (Havoc Pennington) Date: Sat, 08 Jan 2005 11:59:58 -0500 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: <41DFD606.6F35FCAA@jwz.org> References: <41DFD606.6F35FCAA@jwz.org> Message-ID: <1105203598.5141.38.camel@localhost.localdomain> On Sat, 2005-01-08 at 04:45 -0800, Jamie Zawinski wrote: > "Eratically" means that generally they would work immediately after > I rebooted the machine, and I could plug/unplug them right after > that, and they'd continue working; but if I tried to use them again > a few hours later, the only way to make them work would be to reboot > again. No amount of rmmod would bring joy (though some would bring > complete wedgedness.) USB devices definitely have flaky drivers. 2.6.9-1.1049_FC4 (running on FC3) is going a bit better for me but I still got it to oops. However, FC3 kernels would reliably oops every time you unplugged a CD drive. Now it seems I have to do something trickier (like unplug a mounted hard drive). I'm hoping that since all the stuff is there now for people to easily plug and unplug and have things work automatically, the driver bugs will get more visibility and fixage. Havoc From alan at redhat.com Sat Jan 8 17:10:47 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 8 Jan 2005 12:10:47 -0500 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: <1105203598.5141.38.camel@localhost.localdomain> References: <41DFD606.6F35FCAA@jwz.org> <1105203598.5141.38.camel@localhost.localdomain> Message-ID: <20050108171047.GA27556@devserv.devel.redhat.com> On Sat, Jan 08, 2005 at 11:59:58AM -0500, Havoc Pennington wrote: > USB devices definitely have flaky drivers. 2.6.9-1.1049_FC4 (running on > FC3) is going a bit better for me but I still got it to oops. However, > FC3 kernels would reliably oops every time you unplugged a CD drive. Now > it seems I have to do something trickier (like unplug a mounted hard > drive). 2.6.10 is much much better. The changes were rather tricky to backport in full however. From barryn at pobox.com Sat Jan 8 17:34:28 2005 From: barryn at pobox.com (Barry K. Nathan) Date: Sat, 8 Jan 2005 09:34:28 -0800 Subject: Stand-alone kernel module packages now in rawhide.. the dawn of a new era In-Reply-To: <604aa79105010807497f0037fc@mail.gmail.com> References: <200412221250.iBMCoDr02816@porkchop.devel.redhat.com> <604aa7910501071320172b0162@mail.gmail.com> <1105186062.4196.16.camel@laptopd505.fenrus.org> <604aa79105010807497f0037fc@mail.gmail.com> Message-ID: <20050108173428.GA4388@ip68-4-98-123.oc.oc.cox.net> On Sat, Jan 08, 2005 at 10:49:30AM -0500, Jeff Spaleta wrote: > fond of the concept of stand-alone module packages in general. But the > fact remains that addon packagers do have to deal with it, and I think > the community benefits at large if how to deal with stand-alone kernel > packages equitably became a concern inside Core, so that can we hammer > out a standard way to do this as part of the the Core development tree > testing process. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123351 If DKMS gets added to either Core or Extras, then I think it would make it easier to have addon module packages. Dell has used it in the past to make ALSA RPMs for 2.4-based Red Hat distributions and that sort of thing. (I don't think I'll be able to make DKMS packages for Extras or anything like that right now, however; right now I'm up to my eyeballs in kernel stuff.) -Barry K. Nathan From Axel.Thimm at ATrpms.net Sat Jan 8 17:44:32 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 8 Jan 2005 18:44:32 +0100 Subject: Stand-alone kernel module packages now in rawhide.. the dawn of a new era In-Reply-To: <1105186062.4196.16.camel@laptopd505.fenrus.org> References: <200412221250.iBMCoDr02816@porkchop.devel.redhat.com> <604aa7910501071320172b0162@mail.gmail.com> <1105186062.4196.16.camel@laptopd505.fenrus.org> Message-ID: <20050108174432.GH17126@neu.nirvana> On Sat, Jan 08, 2005 at 01:07:42PM +0100, Arjan van de Ven wrote: > On Fri, 2005-01-07 at 16:20 -0500, Jeff Spaleta wrote: > > On Wed, 22 Dec 2004 07:50:13 -0500, Build System wrote: > > > New package GFS-kernel > > > GFS-kernel - The Global File System kernel modules > > > New package cman-kernel > > > cman-kernel - The Cluster Manager kernel modules > > > New package dlm-kernel > > > dlm-kernel - The Distributed Lock Manager kernel modules. > > > New package gnbd-kernel > > > gnbd-kernel - The kernel module for GFS's Network Block Device > > > > > > My understanding is these package are pretty much the first packages > > inside Fedora Core > > to provide kernel modules outside the actual kernel package. > > I do wonder though why they aren't just patched into the regular kernel > rpm... Would make a lot more sense for something provided in the core > distro.... Probably because RHEL4 will have GFS as a separate add-on product to buy. It's not a direct argument for FC, but after all for RH it's a bigger PITA to have FC with patched in GFS and RHEL with externally maintained GFS bits. Too bad we couldn't get a proper external kernel module building mechanism into Fedora Core half a year ago. ... At the very least the packages should contain the kernel version/release they are built for in the name of the package, though. Anyway, as Jeff writes, it's a first step. :) What I find muxh more appealing is the use of foo-kernheaders in analogy to glibc-kernheaders, which was something that didn't have a proper method to be packaged until now. Already applied to two packages at ATrpms (i2c and ivtv :). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From felipe_alfaro at linuxmail.org Sat Jan 8 18:02:03 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sat, 8 Jan 2005 19:02:03 +0100 Subject: Xen Grub configuration Message-ID: <66ED2EF2-619F-11D9-BB26-000D9352858E@linuxmail.org> Hi! After installing kernel-xen0 from RawHide, the following lines were added to my /boot/grub/menu.lst: title Fedora Core (2.6.10-1.1074_FC4xen0) root (hdX,X) kernel /vmlinuz-2.6.10-1.1074_FC4xen0 ro root=/dev/XXX initrd /initrd-2.6.10-1.1074_FC4xen0.img However, this is incorrect, as vmlinuz-2.6.10-1.1074-FC4xen0 cannot be booted by GRUB directly (must be ran under the control of the XEN hypervisor). Instead, GRUB *must* boot /boot/xen.gz which is the XEN hypervisor kernel. Thus, /boot/grub/menu.lst should look like this: title Fedora Core (2.6.10-1.1074_FC4xen0) root (hdX,X) kernel /xen.gz dom0_mem=400000 noreboot module /vmlinuz-2.6.10-1.1074_FC4xen0 ro root=/dev/XXX module /initrd-2.6.10-1.1074_FC4xen0.img Note how now xen.gz is the kernel, and take note of the "dom0_mem" kernel parameter which is needed for XEN to allocate physical memory for XEN's domain 0, Omitting the "dom0_mem" parameter makes XEN allocate too little memory for the domain 0 kernel which, as result, will crash with an Out of Memory error. "dom0_mem=400000" could default to "dom0_mem=130000" instead. This shouldn't be much of a problem since if we try to allocate more memory than the maximum available RAM, XEN hypervisor will complain. However, omitting "dom0_mem" will make the Linux kernel crash and reboot, which is much worse. Should I fill in a bug report for this? Thanks. From fedora-devel at camperquake.de Sat Jan 8 18:30:35 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Sat, 8 Jan 2005 19:30:35 +0100 Subject: ssh X forwarding change in FC3 In-Reply-To: <1105123735.4464.5.camel@localhost.localdomain> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> Message-ID: <20050108193035.5430851a@nausicaa.camperquake.de> Hi. Havoc Pennington wrote: > The openssh change is totally broken, because none of the clients people > use work with "trusted X" and they could not reasonably be modified to > do so, without an effort on the scale of SELinux or even larger. The > fact that the X server even supports "trusted X" is probably total > nonsense. Just for the record: this change also breaks consolehelper. -- "Don't fool yourself, everyone in this room is wearing a uniform." -- Frank Zappa From zaitcev at redhat.com Sat Jan 8 22:15:51 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 8 Jan 2005 14:15:51 -0800 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: References: Message-ID: <20050108141551.47d3180f@lembas.zaitcev.lan> On Sat, 08 Jan 2005 04:45:58 -0800, Jamie Zawinski wrote: > Are any of you running FC3 and able to get pictures off of a > CompactFlash card at USB-2 speeds? If so, what CF reader are > you using? Because I want to go out and buy one of those. > > The set of readers I have tried recently are: > - SanDisk ImageMate SDDR-31 USB 1.0 reader; I use SDDR-31 successfuly since 2001, it's a great device with [almost] no serious firmware problems which plague this kind of peripherals. > All of them do this when I plug them in (card present or not): > > usb 5-1: new full speed USB device using address 52 > usb 5-1: device not accepting address 52, error -71 > usb 5-1: new full speed USB device using address 53 > usb 5-1: device not accepting address 53, error -71 This is not good, because -71 is a low-level protocol error. Usually it is called by things like a bitstuffing violation, a missing token, etc. I cannot speculate what causes it, but every component has to be excluded by replacement. We can exclude readers now, so it leaves motherboard chips and traces, cables, possibly a hub, and most especially any power supplies involved. Sometimes it happens when people connect external VGA to a laptop, go figure! (I am not saying this is your problem, obviously). I know who I am dealing with, Jamie, but for the list archives: DO NOT exclude two articles at a time. If you replace the laptop, leave all cabling, hubs, and the reader, in place. To be frank, it is possible for the software to report -71 for a bad reason, when it is confused. Once we excluded everything else, with the computer itself, it's time to look at UHCI root hub handling. We'll take it from there. > "Eratically" means that generally they would work immediately after > I rebooted the machine, and I could plug/unplug them right after > that, and they'd continue working; but if I tried to use them again > a few hours later, the only way to make them work would be to reboot > again. No amount of rmmod would bring joy (though some would bring > complete wedgedness.) This is very interesting, but I don't think I can act upon this section of your report, especially that it appears to relate a past experience. Let's concentrate on -71s. BTW, I should note that it is possible to use a passive PCMCIA-CF adapter. I have one of those as well, and it works great. The only reason I used SDDR-31 is that my only PC Card slot was often used by a wireless card. Eventually I got used to it. Also, in older distros and kernels it was required to stop and start pcmcia services when you plug the thing, and USB always was 100% hotplug, at least in theory. -- Pete From jwz at jwz.org Sat Jan 8 22:56:22 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Sat, 08 Jan 2005 14:56:22 -0800 Subject: what USB-2 CF reader is alleged to work? References: <20050108141551.47d3180f@lembas.zaitcev.lan> Message-ID: <41E06516.5BAB1145@jwz.org> Pete Zaitcev wrote: > > I use SDDR-31 successfuly since 2001, it's a great device with > [almost] no serious firmware problems which plague this kind of > peripherals. As I can't use the SDDR-31 either, it would be a dramatic improvement if I could get that working. But I'd most like to find a USB-2 reader that works, because the files my camera writes are huge... > This is not good, because -71 is a low-level protocol error. Usually it > is called by things like a bitstuffing violation, a missing token, etc. > I cannot speculate what causes it, but every component has to be excluded > by replacement. We can exclude readers now, so it leaves motherboard > chips and traces, cables, possibly a hub, and most especially any power > supplies involved. Sometimes it happens when people connect external VGA > to a laptop, go figure! (I am not saying this is your problem, obviously). > I know who I am dealing with, Jamie, but for the list archives: DO NOT > exclude two articles at a time. If you replace the laptop, leave all cabling, > hubs, and the reader, in place. It's a desktop, not a laptop. My current (brand new) mobo is an ASUS A7V880 VIA KT880. It also has a brand new AMD 3200/400 CPU and brand new RAM. And I've tried two different power supplies, just for kicks. There are no hubs involved, I plug the CF readers directly into the onboard USB. So yeah, I've already run so far out of ideas that I've gone down the "replace absolutely everything" path. Hell, the *disks* are only a few months older than the rest of the machine. The only other peripheral plugged into the machine at all is the video card (Nvidia 5700 Ultra). > To be frank, it is possible for the software to report -71 for a bad > reason, when it is confused. Once we excluded everything else, with > the computer itself, it's time to look at UHCI root hub handling. > We'll take it from there. Ok, what other info would help? > BTW, I should note that it is possible to use a passive PCMCIA-CF adapter. I've used those succesfully in laptops, and consequently (a few years ago) I tried to get two different models of PCMCIA bay installed in my desktop machine to avoid USB entirely, but that was an even bigger disaster. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From mbneto at gmail.com Sat Jan 8 23:06:34 2005 From: mbneto at gmail.com (mbneto) Date: Sat, 8 Jan 2005 19:06:34 -0400 Subject: goals for fc4? Message-ID: <5cf776b8050108150644336d04@mail.gmail.com> hi, i was wondering where can i find the current goals for fc4 ? I 've checked fedora.redhat.com with no luck. - mb From pri.rhl3 at iadonisi.to Sat Jan 8 23:18:34 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Sat, 08 Jan 2005 18:18:34 -0500 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: <41DFD606.6F35FCAA@jwz.org> References: <41DFD606.6F35FCAA@jwz.org> Message-ID: <1105226314.30554.11.camel@va.local.linuxlobbyist.org> On Sat, 2005-01-08 at 04:45 -0800, Jamie Zawinski wrote: [snip] > So here is my question: > > Are any of you running FC3 and able to get pictures off of a > CompactFlash card at USB-2 speeds? If so, what CF reader are > you using? Because I want to go out and buy one of those. Okay, I just did a quick test since I don't use mine that often. I'm getting about 2.6MBytes/sec with my 7-in-1 reader which probably does mean I'm getting USB 2.0 speeds. The brand is Syntax, model number is UCR-61. I got it at http://www.allstarshop.com/ probably about a year ago. Sadly, I don't see it there anymore. If I find it anywhere else (I'm looking to buy one of those 7-in-1/floppy combos soon, so I'll keep an eye out for it) I'll let you know. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From barryn at pobox.com Sat Jan 8 23:37:08 2005 From: barryn at pobox.com (Barry K. Nathan) Date: Sat, 8 Jan 2005 15:37:08 -0800 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: <41DFD606.6F35FCAA@jwz.org> References: <41DFD606.6F35FCAA@jwz.org> Message-ID: <20050108233708.GB4388@ip68-4-98-123.oc.oc.cox.net> On Sat, Jan 08, 2005 at 04:45:58AM -0800, Jamie Zawinski wrote: > All of them do this when I plug them in (card present or not): > > usb 5-1: new full speed USB device using address 52 > usb 5-1: device not accepting address 52, error -71 > usb 5-1: new full speed USB device using address 53 > usb 5-1: device not accepting address 53, error -71 Trivia for the day: If you trigger enough -71 errors (I think a little over 100, if memory serves), the kernel that ships with Fedora Core 2 oopses. It got fixed in one of the update kernels. I have no idea whether it was fixed accidentally or on purpose, however. [snip] > "Eratically" means that generally they would work immediately after > I rebooted the machine, and I could plug/unplug them right after > that, and they'd continue working; but if I tried to use them again > a few hours later, the only way to make them work would be to reboot > again. No amount of rmmod would bring joy (though some would bring > complete wedgedness.) What happens if you run Windows XP instead of Linux? WinXP has a weird little message that pops up near the lower-right corner of the screen, when it runs into the equivalent of Linux's -71 errors (something about device failure or something like that, I think). In fact, if you're consistently getting two -71 errors under Linux, you might see the message appear, quickly disappear, then quickly reappear again under Windows. If you're getting a stream of -71 errors, then the Windows error may appear and disappear intermittently, perhaps in an attempt to drive you mad. ;) BTW, even if the card readers seem to work initially under Windows, the same falls-apart-after-a-few-hours behavior that you're seeing under Linux could also happen under Windows. (I've only seen a -71 error situation once. In that case, the Windows equivalent happened too, and IIRC the computer's manufacturer decided to replace the motherboard.) -Barry K. Nathan From jwz at jwz.org Sun Jan 9 00:01:06 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Sat, 08 Jan 2005 16:01:06 -0800 Subject: what USB-2 CF reader is alleged to work? References: <41DFD606.6F35FCAA@jwz.org> <20050108233708.GB4388@ip68-4-98-123.oc.oc.cox.net> Message-ID: <41E07442.78C7858F@jwz.org> Barry K. Nathan wrote: > > What happens if you run Windows XP instead of Linux? I dunno, my head explodes? None of my machines have ever had Windows on them. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From jcornett at insight.rr.com Sun Jan 9 04:00:57 2005 From: jcornett at insight.rr.com (Jim Cornette) Date: Sat, 08 Jan 2005 23:00:57 -0500 Subject: goals for fc4? In-Reply-To: <5cf776b8050108150644336d04@mail.gmail.com> References: <5cf776b8050108150644336d04@mail.gmail.com> Message-ID: <41E0AC79.90605@insight.rr.com> mbneto wrote: > hi, > i was wondering where can i find the current goals for fc4 ? > > I 've checked fedora.redhat.com with no luck. > > - mb > There waa some discussion about what to make of FC4. Some of the discussion centered around making the cycle shorter and FC4 a cleaner installation. The discussion was shortly after the release of FC3. I believe that nothing ever was really decided as for the makeup of FC4. I'd like to see a less buggy release and a release that is as close to upstream programs as possible. Both goals seem to not fit together, but are probably alright to consider as. The lowest bug count with the most stable program versions. I cannot recall if the discussion was on the development list or on the test list. Jim -- I sometimes think that God, in creating man, somewhat overestimated his ability. -- Oscar Wilde From barryn at pobox.com Sun Jan 9 09:48:23 2005 From: barryn at pobox.com (Barry K. Nathan) Date: Sun, 9 Jan 2005 01:48:23 -0800 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: <41E07442.78C7858F@jwz.org> References: <41DFD606.6F35FCAA@jwz.org> <20050108233708.GB4388@ip68-4-98-123.oc.oc.cox.net> <41E07442.78C7858F@jwz.org> Message-ID: <20050109094823.GA4467@ip68-4-98-123.oc.oc.cox.net> On Sat, Jan 08, 2005 at 04:01:06PM -0800, Jamie Zawinski wrote: > Barry K. Nathan wrote: > > > > What happens if you run Windows XP instead of Linux? > > I dunno, my head explodes? None of my machines have ever had > Windows on them. Oh, ok... In that case, what happens if you try one of the *BSD's? (That way you would at least be able to tell whether the problem is Linux-specific.) -Barry K. Nathan From buildsys at redhat.com Sun Jan 9 13:23:44 2005 From: buildsys at redhat.com (Build System) Date: Sun, 9 Jan 2005 08:23:44 -0500 Subject: rawhide report: 20050109 changes Message-ID: <200501091323.j09DNig17193@porkchop.devel.redhat.com> Updated Packages: audit-0.6.1-1 ------------- * Sat Jan 08 2005 Steve Grubb 0.6.1-1 - New version: rework auditctl and its man pages. - Added admin_space_left config option as last chance before running out of disk space. gcc-3.4.3-13 ------------ * Fri Jan 07 2005 Jakub Jelinek 3.4.3-13 - fix memory attribute computation for addqi_1_slp (PR target/19012) - fix TYPE_MODE of enum with __attribute__ ((mode ())) (#144358) * Wed Jan 05 2005 Jakub Jelinek 3.4.3-12 - update from gcc-3_4-branch - PRs c++/14607, middle-end/19175, rtl-optimization/12092, target/17643 - fix ICE in same_translation_unit_p (#144166) * Mon Dec 27 2004 Jakub Jelinek 3.4.3-11 - update from gcc-3_4-branch - PRs c++/17972, c++/18962, c++/18975, java/14104, libobjc/12035, middle-end/17930, middle-end/18424, middle-end/18493, middle-end/18590, middle-end/18730, middle-end/18882, middle-end/19068, other/18508, other/18665, other/19093, preprocessor/15167, rtl-optimization/16968, target/16819, target/17990, target/18002, target/18153, target/19005, target/19010, target/19028, target/19102, target/19147 - fix ICE in dwarf2out (Devang Patel, Eric Botcazou, #143719, PR debug/16261) - fix ICE in reshape_init_array (#143034, PRs c++/18384, c++/18327) kernel-2.6.10-1.1075_FC4 ------------------------ * Sat Jan 08 2005 Dave Jones - Periodic slab debug is incompatable with pagealloc debug. Disable the latter. rpmdb-fedora-1:4-0.20050109 --------------------------- From phantom at phantom.kicks-ass.net Sun Jan 9 13:19:35 2005 From: phantom at phantom.kicks-ass.net (Phantom) Date: Mon, 10 Jan 2005 00:19:35 +1100 Subject: /etc/hotplug/usb/usbcam - console.lock In-Reply-To: <20050109094823.GA4467@ip68-4-98-123.oc.oc.cox.net> References: <41DFD606.6F35FCAA@jwz.org> <20050108233708.GB4388@ip68-4-98-123.oc.oc.cox.net> <41E07442.78C7858F@jwz.org> <20050109094823.GA4467@ip68-4-98-123.oc.oc.cox.net> Message-ID: <1105276775.18920.20.camel@phantom.kicks-ass.net> Couldn't find if anyone had posted this in the devel list but thought it was worth a mention if someone wants to fix it ( if it is indeed an oversight in the usbcam file ? ) I had been experiencing problems retrieving files off a digital camera ( kodak 3400 ) as a normal user, tried root which worked fine. Turns out a minor change in the usbcam file fixes it. ( thanks to someone on the gphoto2-devel list ) if [ -f /var/run/console.lock ] then CONSOLEOWNER=`cat /var/run/console.lock` elif [ -f /var/lock/console.lock ] then CONSOLEOWNER=`cat /var/lock/console.lock` else CONSOLEOWNER= fi Changes to if [ -f /var/run/console.lock ] then CONSOLEOWNER=`cat /var/run/console.lock` elif [ -f /var/run/console/console.lock ] then CONSOLEOWNER=`cat /var/run/console/console.lock` elif [ -f /var/lock/console.lock ] then CONSOLEOWNER=`cat /var/lock/console.lock` else CONSOLEOWNER= fi From mpeters at mac.com Sun Jan 9 14:13:10 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 09 Jan 2005 14:13:10 +0000 Subject: HAL policies for port. music players Message-ID: <1105279990l.30286l.0l@devel.mpeters.us> I do not like the default behaviour of hal with respect to my iPod. Regardless of who is logged in at the console, if the iPod is docked - it wanted mounted rw for the user, with a nice pretty tempting icon on the desktop. Since it can take considerable time to reload one of these devices (about 20 to 30 minutes for my mini - which is as small as they come) - it's an accident waiting to happen like that. I much prefer the autofs way - where it is not mounted on the desktop, only mounts for users in the group specified in the auto.master file, only mounts when it is needed, and unmounts when it is no longer needed. After some searching and a tip from someone on the hal list, I was able to stop hal from mounting my iPod without having to turn of auto mounting of all ieee1394 devices (created an iPod specific policy in 95userpolicy) Now that I have it working the way I want it with autofs - I want to know if hal is currently capable of the autofs behaviour - mounting only for users in specified group, only when needed, and auto unmounting when no longer in use. If it is capable of this, then I suggest for FC4 that such policies for large capacity portable music/ video players either be the default, or easily configured as the default through a sysconfig gui. I'm tempted to add that as a RFE bug to hal, but don't want to if hal isn't capable of it, and wanted to hear other thoughts first. From barryn at pobox.com Sun Jan 9 17:42:10 2005 From: barryn at pobox.com (Barry K. Nathan) Date: Sun, 9 Jan 2005 09:42:10 -0800 Subject: Requesting for Blockers In-Reply-To: <20050107144824.GB28130@devserv.devel.redhat.com> References: <200501072035.28622.symbiont@berlios.de> <20050107144824.GB28130@devserv.devel.redhat.com> Message-ID: <20050109174210.GB4467@ip68-4-98-123.oc.oc.cox.net> On Fri, Jan 07, 2005 at 09:48:24AM -0500, Alan Cox wrote: > It shouldn;t be missing that much is true but it also shouldnt oops and > 2.6.10 appears to be behaving properly Don Hardaway reproduced the oops on 2.6.10-1.736_FC3 (and attached it to bug 129966). So, it doesn't appear to be fixed yet. (Of course that doesn't yet answer the question of whether it's an upstream bug or a Fedora bug.) -Barry K. Nathan From david at fubar.dk Sun Jan 9 17:56:59 2005 From: david at fubar.dk (David Zeuthen) Date: Sun, 09 Jan 2005 12:56:59 -0500 Subject: HAL policies for port. music players In-Reply-To: <1105279990l.30286l.0l@devel.mpeters.us> References: <1105279990l.30286l.0l@devel.mpeters.us> Message-ID: <1105293419.3134.27.camel@daxter.boston.redhat.com> Hi, For reference, the thread mentioned from hal at fd.o is here http://lists.freedesktop.org/archives/hal/2005-January/001541.html On Sun, 2005-01-09 at 14:13 +0000, Michael A. Peters wrote: > I do not like the default behaviour of hal with respect to my iPod. > Regardless of who is logged in at the console, if the iPod is docked - > it wanted mounted rw for the user, with a nice pretty tempting icon on > the desktop. Since it can take considerable time to reload one of these > devices (about 20 to 30 minutes for my mini - which is as small as they > come) - it's an accident waiting to happen like that. This sounds more like a physical security problem to me: If you care about the contents of your iPod you shouldn't leave it attached to a machine that untrusted users (your kids :-), judging from the thread at the hal mailing list) can physically access. > I much prefer the autofs way - where it is not mounted on the desktop, > only mounts for users in the group specified in the auto.master file, > only mounts when it is needed, and unmounts when it is no longer > needed. > > After some searching and a tip from someone on the hal list, I was able > to stop hal from mounting my iPod without having to turn of auto > mounting of all ieee1394 devices (created an iPod specific policy in > 95userpolicy) > You can just use a device information much like this my_mount_point true true This means: For a specific device (USB vendor_id 0x0d7d, USB product_id 0x1600), HAL/fstab-sync will attempt to use the mount point /media/my_mount_point (if it's not taken already!) and add the mount options uid=555 and gid=555, which of course only applies to vfat. Replace the UID and GID of yourself. You will have to adapt to make it work for Firewire; use hal-device-manager to look at what properties you may need - email me personally if you cannot get this to work. > Now that I have it working the way I want it with autofs - I want to > know if hal is currently capable of the autofs behaviour - mounting > only for users in specified group, only when needed, and auto > unmounting when no longer in use. If it is capable of this, then I > suggest for FC4 that such policies for large capacity portable music/ > video players either be the default, or easily configured as the > default through a sysconfig gui. > > I'm tempted to add that as a RFE bug to hal, but don't want to if hal > isn't capable of it, and wanted to hear other thoughts first. > No, HAL is not capable of automatically unmounting file systems when they are not in use - I also think that the whole UI with gnome-vfs and Nautilus would have to be reworked to support that (icons appearing and disappearing from the desktop for once). What HAL tries to do is to fit most users needs (without using the evil shell) and you cannot please 100% of people 100% of the time. Sorry. What I do want to do for FC4 or FC5 (difficult to plan without the schedule http://fedora.redhat.com/participate/schedule/ being up to date :-/), is some UI a'la hal-device-manager where all sorts of options, maybe even the cracktastic ones above, can be configured on a per-device-basis. I do realize that it may asking users too much to fiddle around with hal device information files. Hope this helps, David From jspaleta at gmail.com Sun Jan 9 18:15:13 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 9 Jan 2005 13:15:13 -0500 Subject: HAL policies for port. music players In-Reply-To: <1105293419.3134.27.camel@daxter.boston.redhat.com> References: <1105279990l.30286l.0l@devel.mpeters.us> <1105293419.3134.27.camel@daxter.boston.redhat.com> Message-ID: <604aa79105010910157f51fceb@mail.gmail.com> On Sun, 09 Jan 2005 12:56:59 -0500, David Zeuthen wrote: > This means: For a specific device (USB vendor_id 0x0d7d, USB > product_id 0x1600), HAL/fstab-sync will attempt to use the mount > point /media/my_mount_point (if it's not taken already!) and > add the mount options uid=555 and gid=555, which of course only > applies to vfat. Is there any way inside hal policy to build logic based on which user is console user at the time? Console user is a special desgination after all, and it seems perfectly reasonable to me that you can run into multi-user networks where the competent administrator wants to have the device appear differently based on who the console user is. Mundane example... I have two users Dick and Jane. If did is on the system as the 'console' user can i have a specific device mounted readonly under the mountpoint /media/Dick's Drive and when Jane is console user have the specific device be mounted read-write under mount point /media/Jane's Drive. Is hal policy flexible enough to deal with different users in different ways? Or to create a mount point based not just on device information but on 'console user' information as well? I realize that the default hal policy tries to target the most common single user needs... but once you start considering multi-users systems local admins might want to create policy that works differently depending on who is logged in at the console. -jef From mpeters at mac.com Sun Jan 9 18:56:49 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 09 Jan 2005 18:56:49 +0000 Subject: HAL policies for port. music players In-Reply-To: <1105293419.3134.27.camel@daxter.boston.redhat.com> (from david@fubar.dk on Sun Jan 9 09:56:59 2005) References: <1105279990l.30286l.0l@devel.mpeters.us> <1105293419.3134.27.camel@daxter.boston.redhat.com> Message-ID: <1105297009l.4843l.0l@devel.mpeters.us> On 01/09/2005 09:56:59 AM, David Zeuthen wrote: > . > > This sounds more like a physical security problem to me: If you care > about the contents of your iPod you shouldn't leave it attached to a > machine that untrusted users (your kids :-), judging from the thread > at > the hal mailing list) can physically access. If the kids mess with the iPod while it is charging, that's one thing. I can lay the iPod out of sight and out of mind. They generally leave my belongings alone anyway. These kids are my little brothers (10 to 15) that come to visit about once a month or so, and have learning disabilities due to drug use of their birth mothers (victimless crime my arse ...) They like to play tux racer, look up PS2 cheat codes, etc. And they are a testimony to how easy Linux is as a desktop for those who don't think it is suppose to be hard to use ;) A mounted fat32 (no *nix file permissions) that mounts rw for any user - I'm not sure I like that - not for something like a media player that is most likely to contain data specific to a particular user. Anyone want to hack the iPod to support ext2? ;) I'll just use autofs for the time being, I prefer the app to mount/ unmount on demand anyway - if hal does not yet do that and it would be troublesome to add it before FC{4,5}, then autofs is the right tool for me at the moment. I won't file a RFE bug. I get the impression though that hal is intended to replace it. From david at fubar.dk Sun Jan 9 19:10:29 2005 From: david at fubar.dk (David Zeuthen) Date: Sun, 09 Jan 2005 14:10:29 -0500 Subject: HAL policies for port. music players In-Reply-To: <604aa79105010910157f51fceb@mail.gmail.com> References: <1105279990l.30286l.0l@devel.mpeters.us> <1105293419.3134.27.camel@daxter.boston.redhat.com> <604aa79105010910157f51fceb@mail.gmail.com> Message-ID: <1105297829.3134.51.camel@daxter.boston.redhat.com> On Sun, 2005-01-09 at 13:15 -0500, Jeff Spaleta wrote: > On Sun, 09 Jan 2005 12:56:59 -0500, David Zeuthen wrote: > > This means: For a specific device (USB vendor_id 0x0d7d, USB > > product_id 0x1600), HAL/fstab-sync will attempt to use the mount > > point /media/my_mount_point (if it's not taken already!) and > > add the mount options uid=555 and gid=555, which of course only > > applies to vfat. > > Is there any way inside hal policy to build logic based on which user > is console user at the time? Console user is a special desgination > after all, and it seems perfectly reasonable to me that you can run > into multi-user networks where the competent administrator wants to > have the device appear differently based on who the console user is. > Mundane example... I have two users Dick and Jane. If did is on the > system as the 'console' user can i have a specific device mounted > readonly under the mountpoint /media/Dick's Drive and when Jane is > console user have the specific device be mounted read-write under > mount point /media/Jane's Drive. > > Is hal policy flexible enough to deal with different users in > different ways? Or to create a mount point based not just on device > information but on 'console user' information as well? I realize that > the default hal policy tries to target the most common single user > needs... but once you start considering multi-users systems local > admins might want to create policy that works differently depending on > who is logged in at the console. > No, this is not currently possible. I think the direction we should take involves killing fstab-sync and moving to using mount wrappers much like pmount that Ubuntu uses. E.g. the desktop stack would call hmount-gtk (KDE could use hmount-qt) to do the mounting and said programs would read both HAL policy as well as the users setting from e.g. gconf. Patching GNOME to do this is easy; one just needs small patches for gnome-vfs and gnome-volume-manager. IIRC Ubuntu does this. 1. We can have per-user policy and build the UI to modify it, e.g. it would be easy to extend the Nautilus property page for a volume with options "Select mount point", "Optimize for fast removal (options sync, noatime)" or "Optimize for performance". This would be per-user. 2. We wouldn't touch /etc/fstab at all which is good for so many obvious reasons 3. Mount points for optical discs (and other volumes not using partitioned media) would be more sane. E.g. if today the mount point for my FC3 install media is /media/cdrecorder; it would be more natural using the volume label e.g. /media/FC3\ i386\ disc3 4. The mount wrapper could interact with the desktop and ask the user for the root password if the system is configured to not allow the user to mount removable and hotpluggable media by default (would be an install option). Even though this sounds like an useless example, keep this article in mind (look for the paragraph mentioning epoxy glue): http://www.pbs.org/cringely/pulpit/pulpit20040916.html Actually, some time ago, someone proposed this to me: Click "You must be root to mount the volume 'Dave's USB key'" [grr] Password Would you also like to automatically allow - This user to mount Dave's USB key - Any user to mount Dave's USB key - This user to mount a USB device - Any user to mount a USB device [happy] Personally, I think 1, 2 and 3 is nice. 4 might be nice as well although I think we generally want to move in a direction where we don't ask the user for the root password. Sure, there will be proponents of ditching fstab-sync, people will scream "oh, so how do you expect I mount by cdrom from the command line, gimme back my /etc/fstab line for /dev/cdrom", but personally, I think the trade off of improved desktop UI versus command line users is worth that. Command line users probably know how to an entry themselves, otherwise they wouldn't be using the command line in the first place :-) I don't run this show though, so it's still an open question if we should move away from fstab-sync :-) Cheers, David From mpeters at mac.com Sun Jan 9 20:43:33 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 09 Jan 2005 20:43:33 +0000 Subject: HAL policies for port. music players In-Reply-To: <1105297829.3134.51.camel@daxter.boston.redhat.com> (from david@fubar.dk on Sun Jan 9 11:10:29 2005) References: <1105279990l.30286l.0l@devel.mpeters.us> <1105293419.3134.27.camel@daxter.boston.redhat.com> <604aa79105010910157f51fceb@mail.gmail.com> <1105297829.3134.51.camel@daxter.boston.redhat.com> Message-ID: <1105303413l.4843l.4l@devel.mpeters.us> On 01/09/2005 11:10:29 AM, David Zeuthen wrote: > Click > "You must be root to mount the volume 'Dave's USB key'" > [grr] > Password > Would you also like to automatically allow > - This user to mount Dave's USB key > - Any user to mount Dave's USB key > - This user to mount a USB device > - Any user to mount a USB device > [happy] What might be better than that is by default they mount for anyone, but you can right click to bring up an administrator option of restricting the device. IE (in my example) iPod mounts first time used, I right click and choose "Mount Options" and can assign who the device can mount for. I can then specify the permissions/options for future mounting. Passwd isn't necessarily needed if you only allow members of wheel group to modify mount options for new volumes. That could be a configuration option itself (always require root or allow any admin) From zaitcev at redhat.com Sun Jan 9 21:21:52 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sun, 9 Jan 2005 13:21:52 -0800 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: References: <20050108141551.47d3180f@lembas.zaitcev.lan> Message-ID: <20050109132152.0ddba098@lembas.zaitcev.lan> On Sat, 08 Jan 2005 14:56:22 -0800, Jamie Zawinski wrote: > So yeah, I've already run so far out of ideas that I've gone down the > "replace absolutely everything" path. [...] > Ok, what other info would help? Please let me know what kernel you are running first. But I have to admit I do not have good ideas currently. At a minimum this is likely to take retries with instrumented kernels. Sorry about that. I'll get back to you about it. -- Pete From jwz at jwz.org Sun Jan 9 21:30:47 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Sun, 09 Jan 2005 13:30:47 -0800 Subject: what USB-2 CF reader is alleged to work? References: <20050108141551.47d3180f@lembas.zaitcev.lan> <20050109132152.0ddba098@lembas.zaitcev.lan> Message-ID: <41E1A287.722C2CC2@jwz.org> Pete Zaitcev wrote: > > Please let me know what kernel you are running first. But I have to admit > I do not have good ideas currently. At a minimum this is likely to take > retries with instrumented kernels. Sorry about that. I'll get back to > you about it. Sure, I'll try anything at this point. I'm currently running 2.6.9-1.681_FC3. I generally run whatever "yum update" hands me. I'm surprised at the small number of responses to the "what CF reader do you use" question! I guess people on this list don't have cameras? -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From barryn at pobox.com Sun Jan 9 21:56:15 2005 From: barryn at pobox.com (Barry K. Nathan) Date: Sun, 9 Jan 2005 13:56:15 -0800 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: <41E1A287.722C2CC2@jwz.org> References: <20050108141551.47d3180f@lembas.zaitcev.lan> <20050109132152.0ddba098@lembas.zaitcev.lan> <41E1A287.722C2CC2@jwz.org> Message-ID: <20050109215615.GC4467@ip68-4-98-123.oc.oc.cox.net> On Sun, Jan 09, 2005 at 01:30:47PM -0800, Jamie Zawinski wrote: > I'm surprised at the small number of responses to the "what CF reader do > you use" question! I guess people on this list don't have cameras? In my case my only USB 2.0 card reader is an AVB UC-28. Data transfers to/from it kept freezing up on me (the computer itself wouldn't freeze but data transfer to/from the card reader would halt and stop making progress). However, not long after that, two of the electrolytic capacitors on that computer's motherboard burst, so maybe that was the real source of the problems. (BTW, I still haven't fixed that computer yet. I plan to, soon, but I haven't yet.) Now that I think about it, this reader seems to work fine with Linux on every other computer I've used it on -- but that's not enough usage for me to be confident in recommending it to other people yet. -Barry K. Nathan From hp at redhat.com Sun Jan 9 22:50:52 2005 From: hp at redhat.com (Havoc Pennington) Date: Sun, 09 Jan 2005 17:50:52 -0500 Subject: HAL policies for port. music players In-Reply-To: <1105279990l.30286l.0l@devel.mpeters.us> References: <1105279990l.30286l.0l@devel.mpeters.us> Message-ID: <1105311052.5141.149.camel@localhost.localdomain> On Sun, 2005-01-09 at 14:13 +0000, Michael A. Peters wrote: > > Now that I have it working the way I want it with autofs - I want to > know if hal is currently capable of the autofs behaviour - mounting > only for users in specified group, only when needed, and auto > unmounting when no longer in use. If it is capable of this, then I > suggest for FC4 that such policies for large capacity portable music/ > video players either be the default, or easily configured as the > default through a sysconfig gui. My prediction is that mounting it by default is what virtually everyone wants. I'm not sure I understand your situation; you are in an environment where you can safely leave the iPod sitting out by the computer, but you are worried someone will erase it? Havoc From hp at redhat.com Sun Jan 9 22:52:36 2005 From: hp at redhat.com (Havoc Pennington) Date: Sun, 09 Jan 2005 17:52:36 -0500 Subject: HAL policies for port. music players In-Reply-To: <1105311052.5141.149.camel@localhost.localdomain> References: <1105279990l.30286l.0l@devel.mpeters.us> <1105311052.5141.149.camel@localhost.localdomain> Message-ID: <1105311156.5141.150.camel@localhost.localdomain> On Sun, 2005-01-09 at 17:50 -0500, Havoc Pennington wrote: > > My prediction is that mounting it by default is what virtually everyone > wants. I'm not sure I understand your situation; you are in an > environment where you can safely leave the iPod sitting out by the > computer, but you are worried someone will erase it? Sorry, I hadn't downloaded the whole thread ;-) Havoc From jspaleta at gmail.com Sun Jan 9 23:07:42 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 9 Jan 2005 18:07:42 -0500 Subject: HAL policies for port. music players In-Reply-To: <1105297829.3134.51.camel@daxter.boston.redhat.com> References: <1105279990l.30286l.0l@devel.mpeters.us> <1105293419.3134.27.camel@daxter.boston.redhat.com> <604aa79105010910157f51fceb@mail.gmail.com> <1105297829.3134.51.camel@daxter.boston.redhat.com> Message-ID: <604aa791050109150748674412@mail.gmail.com> On Sun, 09 Jan 2005 14:10:29 -0500, David Zeuthen wrote: > Sure, there will be proponents of ditching fstab-sync, people > will scream "oh, so how do you expect I mount by cdrom from the > command line, gimme back my /etc/fstab line for /dev/cdrom", > but personally, I think the trade off of improved desktop UI > versus command line users is worth that. Command line users > probably know how to an entry themselves, otherwise they > wouldn't be using the command line in the first place :-) I personally like the idea of removing the dynamically controlled mountpoint from /etc/fstab completely. autofs controlled mountpoints already don't use fstab so its not like moving hal facilitated mounts out of fstab sets a new precedent. If the non-fstab future can be encoded into desktop ui.. im sure it can be encoded into some sort of cli tool for cli usage to interact with hal in a similar way. -jef From alan at redhat.com Sun Jan 9 23:55:43 2005 From: alan at redhat.com (Alan Cox) Date: Sun, 9 Jan 2005 18:55:43 -0500 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: <41E1A287.722C2CC2@jwz.org> References: <20050108141551.47d3180f@lembas.zaitcev.lan> <20050109132152.0ddba098@lembas.zaitcev.lan> <41E1A287.722C2CC2@jwz.org> Message-ID: <20050109235543.GA3973@devserv.devel.redhat.com> On Sun, Jan 09, 2005 at 01:30:47PM -0800, Jamie Zawinski wrote: > I'm surprised at the small number of responses to the "what CF reader do > you use" question! I guess people on this list don't have cameras? I've got a camera, I've got several CF readers both USB and PCMCIA and they all just work From mpeters at mac.com Mon Jan 10 00:14:59 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 10 Jan 2005 00:14:59 +0000 Subject: HAL policies for port. music players In-Reply-To: <1105311052.5141.149.camel@localhost.localdomain> (from hp@redhat.com on Sun Jan 9 14:50:52 2005) References: <1105279990l.30286l.0l@devel.mpeters.us> <1105311052.5141.149.camel@localhost.localdomain> Message-ID: <1105316099l.4843l.7l@devel.mpeters.us> On 01/09/2005 02:50:52 PM, Havoc Pennington wrote: > > My prediction is that mounting it by default is what virtually > everyone > wants. I don't know that I would necessarily agree with that. If they are using it for a general data drive, sure. If they are using it for its intended purpose, a storage facility for media files to be played later, then there is no purpose in mounting it until an application needs it, and no purpose for an icon to appear on the desktop. What I'm guessing most users want to do is add and remove files for use on the device itself later, which needs to be done with a front end that speaks to the devices library database. Thus I would think most users want an _application_ to be able to talk to it, which can be accomplished by mounting the device when the application wants it. This is what gtkpod does when used with autofs. It's not mounted until you click the button to read from the iTunesDB. Then it mounts via autofs and the iTunesDB is read (or written). When gtkpod exits, the volume soon unmounts, as nothing is accessing it. I suppose some users might want the interface application launched when they connect the device. That's the default behaviour in Windows (which I find annoying but that may just be me). But unless they plan to manually move files to and from the volume, then the user has no need for it to automount unless an application wants to interface with it. From feliciano.matias at free.fr Mon Jan 10 03:39:47 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 10 Jan 2005 04:39:47 +0100 Subject: goals for fc4? In-Reply-To: <5cf776b8050108150644336d04@mail.gmail.com> References: <5cf776b8050108150644336d04@mail.gmail.com> Message-ID: <1105328387.5866.4.camel@one.myworld> Le samedi 08 janvier 2005 ? 19:06 -0400, mbneto a ?crit : > hi, > i was wondering where can i find the current goals for fc4 ? I want more visibility for the futur "official" Fedora Extra. Perhaps a /etc/yum.repo.d/extra.repo . -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ejprinz at austin.rr.com Mon Jan 10 03:39:52 2005 From: ejprinz at austin.rr.com (Erwin J. Prinz) Date: Sun, 09 Jan 2005 21:39:52 -0600 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: <41E1A287.722C2CC2@jwz.org> References: <20050108141551.47d3180f@lembas.zaitcev.lan> <20050109132152.0ddba098@lembas.zaitcev.lan> <41E1A287.722C2CC2@jwz.org> Message-ID: <41E1F908.5010407@austin.rr.com> I have a CR-V7-UC compact Flash card reader which shows up as T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=05e3 ProdID=0700 Rev= 1.13 S: Product=USB Storage Device C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr= 96mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms in /proc/bus/usb/devices. It works very well with FC3. Best regards, Erwin From pbrobinson at gmail.com Mon Jan 10 04:28:03 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 10 Jan 2005 12:28:03 +0800 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: <20050109235543.GA3973@devserv.devel.redhat.com> References: <20050108141551.47d3180f@lembas.zaitcev.lan> <20050109132152.0ddba098@lembas.zaitcev.lan> <41E1A287.722C2CC2@jwz.org> <20050109235543.GA3973@devserv.devel.redhat.com> Message-ID: <5256d0b0501092028551280a3@mail.gmail.com> > > I'm surprised at the small number of responses to the "what CF reader do > > you use" question! I guess people on this list don't have cameras? > > I've got a camera, I've got several CF readers both USB and PCMCIA and they > all just work Same here. I have a Belkin 8 in 1 USB2 reader and it work on my clunky old laptop, dektop and just about every computer I plug it into USB 1 or 2. Its worked fine since FC1. I seem to remember there was an issue with RH9 where it would only see the CF slot and none of the others. But RH9 is old so I don't really care. From jerone at gmail.com Mon Jan 10 04:45:24 2005 From: jerone at gmail.com (Jerone Young) Date: Sun, 9 Jan 2005 22:45:24 -0600 Subject: Xen Grub configuration In-Reply-To: <66ED2EF2-619F-11D9-BB26-000D9352858E@linuxmail.org> References: <66ED2EF2-619F-11D9-BB26-000D9352858E@linuxmail.org> Message-ID: <9f50a7a0050109204535c8c45@mail.gmail.com> Yes you should. You cannot load up a domain 0 Xen kernel with the parameters you first mentioned. Or maybe they just havn't gotten to updating stuff to added entries correctly, still best to file a bug. On Sat, 8 Jan 2005 19:02:03 +0100, Felipe Alfaro Solana wrote: > Hi! > > After installing kernel-xen0 from RawHide, the following lines were > added to my /boot/grub/menu.lst: > > title Fedora Core (2.6.10-1.1074_FC4xen0) > root (hdX,X) > kernel /vmlinuz-2.6.10-1.1074_FC4xen0 ro root=/dev/XXX > initrd /initrd-2.6.10-1.1074_FC4xen0.img > > However, this is incorrect, as vmlinuz-2.6.10-1.1074-FC4xen0 cannot be > booted by GRUB directly (must be ran under the control of the XEN > hypervisor). Instead, GRUB *must* boot /boot/xen.gz which is the XEN > hypervisor kernel. Thus, /boot/grub/menu.lst should look like this: > > title Fedora Core (2.6.10-1.1074_FC4xen0) > root (hdX,X) > kernel /xen.gz dom0_mem=400000 noreboot > module /vmlinuz-2.6.10-1.1074_FC4xen0 ro root=/dev/XXX > module /initrd-2.6.10-1.1074_FC4xen0.img > > Note how now xen.gz is the kernel, and take note of the "dom0_mem" > kernel parameter which is needed for XEN to allocate physical memory > for XEN's domain 0, Omitting the "dom0_mem" parameter makes XEN > allocate too little memory for the domain 0 kernel which, as result, > will crash with an Out of Memory error. > > "dom0_mem=400000" could default to "dom0_mem=130000" instead. This > shouldn't be much of a problem since if we try to allocate more memory > than the maximum available RAM, XEN hypervisor will complain. However, > omitting "dom0_mem" will make the Linux kernel crash and reboot, which > is much worse. > > Should I fill in a bug report for this? > Thanks. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From jerone at gmail.com Mon Jan 10 05:17:39 2005 From: jerone at gmail.com (Jerone Young) Date: Sun, 9 Jan 2005 23:17:39 -0600 Subject: Xen Grub configuration In-Reply-To: <66ED2EF2-619F-11D9-BB26-000D9352858E@linuxmail.org> References: <66ED2EF2-619F-11D9-BB26-000D9352858E@linuxmail.org> Message-ID: <9f50a7a005010921172e9f5b81@mail.gmail.com> Yes you should. You cannot load up a domain 0 Xen kernel with the parameters you first mentioned. Or maybe they just havn't gotten to updating stuff to added entries correctly, still best to file a bug. Jerone On Sat, 8 Jan 2005 19:02:03 +0100, Felipe Alfaro Solana wrote: > Hi! > > After installing kernel-xen0 from RawHide, the following lines were > added to my /boot/grub/menu.lst: > > title Fedora Core (2.6.10-1.1074_FC4xen0) > root (hdX,X) > kernel /vmlinuz-2.6.10-1.1074_FC4xen0 ro root=/dev/XXX > initrd /initrd-2.6.10-1.1074_FC4xen0.img > > However, this is incorrect, as vmlinuz-2.6.10-1.1074-FC4xen0 cannot be > booted by GRUB directly (must be ran under the control of the XEN > hypervisor). Instead, GRUB *must* boot /boot/xen.gz which is the XEN > hypervisor kernel. Thus, /boot/grub/menu.lst should look like this: > > title Fedora Core (2.6.10-1.1074_FC4xen0) > root (hdX,X) > kernel /xen.gz dom0_mem=400000 noreboot > module /vmlinuz-2.6.10-1.1074_FC4xen0 ro root=/dev/XXX > module /initrd-2.6.10-1.1074_FC4xen0.img > > Note how now xen.gz is the kernel, and take note of the "dom0_mem" > kernel parameter which is needed for XEN to allocate physical memory > for XEN's domain 0, Omitting the "dom0_mem" parameter makes XEN > allocate too little memory for the domain 0 kernel which, as result, > will crash with an Out of Memory error. > > "dom0_mem=400000" could default to "dom0_mem=130000" instead. This > shouldn't be much of a problem since if we try to allocate more memory > than the maximum available RAM, XEN hypervisor will complain. However, > omitting "dom0_mem" will make the Linux kernel crash and reboot, which > is much worse. > > Should I fill in a bug report for this? > Thanks. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From michael.favia at insitesinc.com Mon Jan 10 07:57:55 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Mon, 10 Jan 2005 01:57:55 -0600 Subject: HAL policies for port. music players In-Reply-To: <1105316099l.4843l.7l@devel.mpeters.us> References: <1105279990l.30286l.0l@devel.mpeters.us> <1105311052.5141.149.camel@localhost.localdomain> <1105316099l.4843l.7l@devel.mpeters.us> Message-ID: <41E23583.6070606@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael A. Peters wrote: | On 01/09/2005 02:50:52 PM, Havoc Pennington wrote: | |> |> My prediction is that mounting it by default is what virtually |> everyone |> wants. | What I'm guessing most users want to do is add and remove files for use | on the device itself later, which needs to be done with a front end | that speaks to the devices library database. Thus I would think most | users want an _application_ to be able to talk to it, which can be | accomplished by mounting the device when the application wants it. | This is a lot of guessing. It all seems to be centered around how should we interact with newly attached [storage] devices. I've seen the discussion numbers of times on this and the other lists and as many crazy ideas as how to solve the dilemma. I dont believe the answer is that simple. Advanced users often prefer to work at the file system level and interact with storage/mp3/digicams with a file manager and normal/basic users like to be walked through the process of doing whatever it is they need to do (normally by an application front-end of some sort). I dont particularly like the idea of device connection as an interrupting UI event nor do i like the idea of auto mounting it without approval or notification (but i dont think asking the user to jump through hoops to mount/configure the device is an acceptable solution either). This also seems to be an issue with network interfaces and virtually any other connected (hot-plug) device. My proposed solution is a system tray based utility that discreetly notifies users when new devices are detected and provides them with an opportunity to mount/configure the device. This way we dont interrupt the user interface but instead provide them with information to make the decision with the added benefit of allowing them to make their selected action permanent in the future. Devices need not be handled immediately upon notification but can be delayed until the user has finished the task at hand. Devices would probably remain in the systray utility until they are configured or detached from the system again. Perhaps we leave them in there the whole time and have 3 states of device existence (Newly Attached, Configured, Removed). I'd be happy to write up a full mock up of this process if there is any interest. There are a number of ways i believe we can make the device initialization and configuration process simpler, unified, elegant and more powerful at the same time. This is one of the single most important issues for desktop migration in my opinion. People are ok using whatever applications as long as they "Just work" the way they want them to but they are very unwilling to get into the midst of a device configuration debacle. Best wishes, - -mf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB4jWCBVsNYjF2rDYRAi+0AJ9VJFYcQ4nswqCBqJxkwBwpZrNZKwCeLARw RgOxPSllI0G4DAC39Hk479o= =oYRB -----END PGP SIGNATURE----- From laroche at redhat.com Mon Jan 10 08:55:29 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 10 Jan 2005 09:55:29 +0100 Subject: why doesn't yum cache anything? In-Reply-To: <41D5448A.5030602@bppiac.hu> References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104477645.3324.7.camel@stargrazer.home.awesomeplay.com> <41D509E5.5576F2E9@jwz.org> <1104482872.3441.2.camel@cutter> <41D5448A.5030602@bppiac.hu> Message-ID: <20050110085528.GA6442@dudweiler.stuttgart.redhat.com> > on the other side i understand seth's position, that first create a > feature rich complete and bug-free version somewhere 2.1 or 2.2. but > it's clear to everyone that the most anoying think with you it's speed, > both at startup/load time and both at dependencie resolution time. so > imho it'd be nice to look into this problems soon. something like the > bootchart challenge would be useful in case of yum speed. Reading all deps (provides,requires,obsoletes,conflicts) plus also a list of all files in the rpm packages is a lot of data. The actual dep resolution time can be pretty fast. Improving the python awareness within rpmlib would be helpful IMNSHO. greetings, Florian La Roche From jorton at redhat.com Mon Jan 10 10:28:33 2005 From: jorton at redhat.com (Joe Orton) Date: Mon, 10 Jan 2005 10:28:33 +0000 Subject: Python vs multilib module packaging question Message-ID: <20050110102833.GA3361@redhat.com> In subversion.spec I used: %define pydir %(python -c 'from distutils import sysconfig; print sysconfig.get_python_lib()') to find the directory in which to package Python modules, but on x86_64 this produces /usr/lib/python2.3/site-packages rather than /usr/lib64, which is presumably wrong. Is that a Python bug, or is there some other sysconfig.* thing which should be used to make this work properly? Regards, joe From harald at redhat.com Mon Jan 10 10:53:49 2005 From: harald at redhat.com (Harald Hoyer) Date: Mon, 10 Jan 2005 11:53:49 +0100 Subject: udev: Directory for custom device nodes. Message-ID: <41E25EBD.3040800@redhat.com> Due to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144593 I am thinking of another directory to put device nodes in, which should be copied over to /dev on system start. Any suggestions? From twaugh at redhat.com Mon Jan 10 10:57:13 2005 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 10 Jan 2005 10:57:13 +0000 Subject: /etc/hotplug/usb/usbcam - console.lock In-Reply-To: <1105276775.18920.20.camel@phantom.kicks-ass.net> References: <41DFD606.6F35FCAA@jwz.org> <20050108233708.GB4388@ip68-4-98-123.oc.oc.cox.net> <41E07442.78C7858F@jwz.org> <20050109094823.GA4467@ip68-4-98-123.oc.oc.cox.net> <1105276775.18920.20.camel@phantom.kicks-ass.net> Message-ID: <20050110105713.GZ5322@redhat.com> On Mon, Jan 10, 2005 at 12:19:35AM +1100, Phantom wrote: > Couldn't find if anyone had posted this in the devel list but thought it > was worth a mention if someone wants to fix it ( if it is indeed an > oversight in the usbcam file ? ) Please report a bug in bugzilla about this. > Turns out a minor change in the usbcam file fixes it. The change you mention doesn't seem to apply to the usbcam file we ship, as far as I can tell. Please report a bug in bugzilla so that this issue can be tracked properly and we can get to the bottom of it. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From christof at damian.net Mon Jan 10 11:06:44 2005 From: christof at damian.net (Christof Damian) Date: Mon, 10 Jan 2005 12:06:44 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <41E25EBD.3040800@redhat.com> References: <41E25EBD.3040800@redhat.com> Message-ID: <20050110110643.GI8912@batman.gotham.krass.com> On Mon, 10 Jan 2005, Harald Hoyer wrote: > Due to > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144593 > I am thinking of another directory to put device nodes in, which should be > copied over to /dev on system start. > > Any suggestions? > Maybe there shouldn't be device files at all, but config files with mknod parameters. christof -- Christof Damian christof at damian.net From felipe_alfaro at linuxmail.org Mon Jan 10 11:10:04 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Mon, 10 Jan 2005 12:10:04 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <41E25EBD.3040800@redhat.com> References: <41E25EBD.3040800@redhat.com> Message-ID: <2DE09267-62F8-11D9-B875-000D9352858E@linuxmail.org> On 10 Jan 2005, at 11:53, Harald Hoyer wrote: > Due to > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144593 > I am thinking of another directory to put device nodes in, which > should be copied over to /dev on system start. > > Any suggestions? "/udev/devices" or "/udev/custom" sounds great. From pp at ee.oulu.fi Mon Jan 10 11:25:34 2005 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Mon, 10 Jan 2005 13:25:34 +0200 Subject: Python vs multilib module packaging question In-Reply-To: <20050110102833.GA3361@redhat.com> References: <20050110102833.GA3361@redhat.com> Message-ID: <20050110112534.GA28575@ee.oulu.fi> On Mon, Jan 10, 2005 at 10:28:33AM +0000, Joe Orton wrote: > In subversion.spec I used: > > %define pydir %(python -c 'from distutils import sysconfig; print > sysconfig.get_python_lib()') > > to find the directory in which to package Python modules, but on x86_64 > this produces /usr/lib/python2.3/site-packages rather than /usr/lib64, > which is presumably wrong. > > Is that a Python bug, or is there some other sysconfig.* thing which > should be used to make this work properly? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143136 is related btw. and has a possible way of fixing the problem in one of the comments. Still no idea whether it's python or the spec files that need to be fixed. -- Pekka Pietikainen From harald at redhat.com Mon Jan 10 11:40:40 2005 From: harald at redhat.com (Harald Hoyer) Date: Mon, 10 Jan 2005 12:40:40 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <20050110110643.GI8912@batman.gotham.krass.com> References: <41E25EBD.3040800@redhat.com> <20050110110643.GI8912@batman.gotham.krass.com> Message-ID: <41E269B8.8000104@redhat.com> Christof Damian wrote: > On Mon, 10 Jan 2005, Harald Hoyer wrote: > >>Due to >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144593 >>I am thinking of another directory to put device nodes in, which should be >>copied over to /dev on system start. >> >>Any suggestions? >> > > > Maybe there shouldn't be device files at all, but config files with > mknod parameters. For that, there is /etc/makedev.d already. :) From jorton at redhat.com Mon Jan 10 11:45:26 2005 From: jorton at redhat.com (Joe Orton) Date: Mon, 10 Jan 2005 11:45:26 +0000 Subject: Python vs multilib module packaging question In-Reply-To: <20050110112534.GA28575@ee.oulu.fi> References: <20050110102833.GA3361@redhat.com> <20050110112534.GA28575@ee.oulu.fi> Message-ID: <20050110114526.GA6182@redhat.com> On Mon, Jan 10, 2005 at 01:25:34PM +0200, Pekka Pietikainen wrote: > On Mon, Jan 10, 2005 at 10:28:33AM +0000, Joe Orton wrote: > > In subversion.spec I used: > > > > %define pydir %(python -c 'from distutils import sysconfig; print > > sysconfig.get_python_lib()') > > > > to find the directory in which to package Python modules, but on x86_64 > > this produces /usr/lib/python2.3/site-packages rather than /usr/lib64, > > which is presumably wrong. > > > > Is that a Python bug, or is there some other sysconfig.* thing which > > should be used to make this work properly? > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143136 > > is related btw. and has a possible way of fixing the problem > in one of the comments. Still no idea whether it's python or the spec files > that need to be fixed. Thanks. Michael's fix there is to use sysconfig.get_python_lib(1) rather than just sysconfig.get_python_lib(). I'll do that for Subversion too unless anyone can tell me that it's a bad idea :) joe From thomasz at hostmaster.org Mon Jan 10 12:13:54 2005 From: thomasz at hostmaster.org (Thomas Zehetbauer) Date: Mon, 10 Jan 2005 13:13:54 +0100 Subject: Python vs multilib module packaging question In-Reply-To: <20050110102833.GA3361@redhat.com> References: <20050110102833.GA3361@redhat.com> Message-ID: <1105359234.4698.7.camel@hostmaster.org> I think most python libs are architecture independent anyway. Tom -- T h o m a s Z e h e t b a u e r ( TZ251 ) PGP encrypted mail preferred - KeyID 96FFCB89 finger thomasz at hostmaster.org for key Growing old is mandatory... growing up is optional. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 481 bytes Desc: This is a digitally signed message part URL: From mike at navi.cx Mon Jan 10 12:52:24 2005 From: mike at navi.cx (Mike Hearn) Date: Mon, 10 Jan 2005 12:52:24 +0000 Subject: HAL policies for port. music players References: <1105279990l.30286l.0l@devel.mpeters.us> <1105311052.5141.149.camel@localhost.localdomain> <1105316099l.4843l.7l@devel.mpeters.us> Message-ID: On Mon, 10 Jan 2005 00:14:59 +0000, Michael A. Peters wrote: > What I'm guessing most users want to do is add and remove files for use > on the device itself later, which needs to be done with a front end > that speaks to the devices library database. Thus I would think most > users want an _application_ to be able to talk to it, which can be > accomplished by mounting the device when the application wants it. That's true for the iPod but some players like the iAudio just use a FAT drive and you can add/remove files from it using raw Nautilus. OK so that doesn't give you the best experience as right now Nautilus insists on putting a trash can on the player, and also Nautilus can't sync two directories together. I started writing an app to do all this but realised it'd be a lot easier to do it manually, I don't load new music *that* often ;) From buildsys at redhat.com Mon Jan 10 13:45:59 2005 From: buildsys at redhat.com (Build System) Date: Mon, 10 Jan 2005 08:45:59 -0500 Subject: rawhide report: 20050110 changes Message-ID: <200501101345.j0ADjxg28930@porkchop.devel.redhat.com> Updated Packages: mozilla-37:1.7.5-3 ------------------ * Sun Jan 09 2005 Christopher Aillon 37:1.7.5-3 - Update pango selection patch to fix cursoring in textareas. psutils-1.17-24 --------------- * Mon Jan 10 2005 Tim Waugh 1.17-24 - Manpage correction for psresize (bug #144582). rpmdb-fedora-1:4-0.20050110 --------------------------- vsftpd-2.0.1-8 -------------- * Mon Jan 10 2005 Radek Vokal 2.0.1-8 - use localtime also in logs (#143687) From n3npq at nc.rr.com Mon Jan 10 15:04:21 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 10 Jan 2005 10:04:21 -0500 Subject: why doesn't yum cache anything? In-Reply-To: <20050110085528.GA6442@dudweiler.stuttgart.redhat.com> References: <41D4F36D.B7DA877@jwz.org> <1104475450.3324.5.camel@stargrazer.home.awesomeplay.com> <41D4F6B2.183B0FA4@jwz.org> <1104477645.3324.7.camel@stargrazer.home.awesomeplay.com> <41D509E5.5576F2E9@jwz.org> <1104482872.3441.2.camel@cutter> <41D5448A.5030602@bppiac.hu> <20050110085528.GA6442@dudweiler.stuttgart.redhat.com> Message-ID: <41E29975.2030304@nc.rr.com> Florian La Roche wrote: >Improving the python awareness within rpmlib would be helpful IMNSHO. > How? The "awareness" of python within rpmlib is already leading to tortured code paths to preserve the pretense that there are no SELinux and multilib and mandatory package signature checking issues that will require changes to python tools. And getting consensus on changes is a matter of months andf years, not otherwise. For starters, the callback, which passes a python object into and out of rpmlib, is not exactly an "aware" implementation. Write rpmlib in python if you *really* want python awareness. 73 de Jeff From ville.skytta at iki.fi Mon Jan 10 15:20:40 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 10 Jan 2005 17:20:40 +0200 Subject: Python vs multilib module packaging question In-Reply-To: <20050110114526.GA6182@redhat.com> References: <20050110102833.GA3361@redhat.com> <20050110112534.GA28575@ee.oulu.fi> <20050110114526.GA6182@redhat.com> Message-ID: <1105370440.5747.5.camel@bobcat.mine.nu> On Mon, 2005-01-10 at 11:45 +0000, Joe Orton wrote: > Thanks. Michael's fix there is to use sysconfig.get_python_lib(1) > rather than just sysconfig.get_python_lib(). I'll do that for > Subversion too unless anyone can tell me that it's a bad idea :) get_python_lib() for noarch Python packages, get_python_lib(1) for arch- dependent ones (as judged by Python) is correct. From rdieter at math.unl.edu Mon Jan 10 15:53:23 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 10 Jan 2005 09:53:23 -0600 Subject: pre-extras: SRPMS? Message-ID: <41E2A4F3.9020803@math.unl.edu> I noticed the pre-extras repo doesn't have SRPMS available. Is this intentional or oversight? Could these be provided? -- Rex From skvidal at phy.duke.edu Mon Jan 10 15:56:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 10 Jan 2005 10:56:41 -0500 Subject: pre-extras: SRPMS? In-Reply-To: <41E2A4F3.9020803@math.unl.edu> References: <41E2A4F3.9020803@math.unl.edu> Message-ID: <1105372601.25990.15.camel@opus.phy.duke.edu> On Mon, 2005-01-10 at 09:53 -0600, Rex Dieter wrote: > I noticed the pre-extras repo doesn't have SRPMS available. Is this > intentional or oversight? Could these be provided? look in the arch dirs and then in the srpms dir. http://fedoraproject.org/pre-extras/3/i386/srpms/ They've been there all along. -sv From rdieter at math.unl.edu Mon Jan 10 16:03:15 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 10 Jan 2005 10:03:15 -0600 Subject: pre-extras: SRPMS? In-Reply-To: <1105372601.25990.15.camel@opus.phy.duke.edu> References: <41E2A4F3.9020803@math.unl.edu> <1105372601.25990.15.camel@opus.phy.duke.edu> Message-ID: <41E2A743.9050802@math.unl.edu> seth vidal wrote: > On Mon, 2005-01-10 at 09:53 -0600, Rex Dieter wrote: > >>I noticed the pre-extras repo doesn't have SRPMS available. Is this >>intentional or oversight? Could these be provided? > > > look in the arch dirs and then in the srpms dir. > > http://fedoraproject.org/pre-extras/3/i386/srpms/ > > They've been there all along. My bad, it's just a different arrangement than what I've seen before. -- Rex From tjb at unh.edu Mon Jan 10 16:09:12 2005 From: tjb at unh.edu (Thomas J. Baker) Date: Mon, 10 Jan 2005 11:09:12 -0500 Subject: lvm on x86_64? Message-ID: <1105373352.30998.5.camel@wintermute.sr.unh.edu> Trying to install something FC3ish on a Dell 670n without much luck. I tried booting the latest devel image and it says "lvm is not supported on this platform". Is this a bug or the truth? Looking through bugzilla, it looks like the devel image may just be broken. tjb --- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From cristiano at keepthinking.it Mon Jan 10 16:13:07 2005 From: cristiano at keepthinking.it (Cristiano Bianchi (keepthinking)) Date: Mon, 10 Jan 2005 16:13:07 +0000 Subject: Multiple MySQL servers In-Reply-To: <41E2A743.9050802@math.unl.edu> References: <41E2A4F3.9020803@math.unl.edu> <1105372601.25990.15.camel@opus.phy.duke.edu> <41E2A743.9050802@math.unl.edu> Message-ID: <838B6189-6322-11D9-804F-000A95CA59FE@keepthinking.it> Hi all, we have a Fedora2 box, with MySQL 4.0.x, which came with the distribution. It seems that Fedora spreads MySQL stuff all over the place (for instance all binaries are in /usr/bin/, instead of /usr/local/mysql...). I cannot find my.cnf and mysql.sock as well. I would like to install MySQL 4.1 alongside the 4.0 and run both. It seems possible, but I cannot (I think) download the RPM as it would replace the 4.0. If I follow the instructions on the MySQL site, I get nowhere. Is there anyone who can point me in some directions? Thanks! Cristiano Bianchi keepthinking ltd From pri.rhl3 at iadonisi.to Mon Jan 10 16:21:26 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Mon, 10 Jan 2005 11:21:26 -0500 Subject: Multiple MySQL servers In-Reply-To: <838B6189-6322-11D9-804F-000A95CA59FE@keepthinking.it> References: <41E2A4F3.9020803@math.unl.edu> <1105372601.25990.15.camel@opus.phy.duke.edu> <41E2A743.9050802@math.unl.edu> <838B6189-6322-11D9-804F-000A95CA59FE@keepthinking.it> Message-ID: <1105374086.26498.10.camel@tuxpaq> 20 lashes for violating netiquette. Please, do NOT *reply* to a message on a mailing list unless you are *actually* replying to a message. From jos at xos.nl Mon Jan 10 16:25:31 2005 From: jos at xos.nl (Jos Vos) Date: Mon, 10 Jan 2005 17:25:31 +0100 Subject: Multiple MySQL servers In-Reply-To: <838B6189-6322-11D9-804F-000A95CA59FE@keepthinking.it>; from cristiano@keepthinking.it on Mon, Jan 10, 2005 at 04:13:07PM +0000 References: <41E2A4F3.9020803@math.unl.edu> <1105372601.25990.15.camel@opus.phy.duke.edu> <41E2A743.9050802@math.unl.edu> <838B6189-6322-11D9-804F-000A95CA59FE@keepthinking.it> Message-ID: <20050110172531.A19004@xos037.xos.nl> On Mon, Jan 10, 2005 at 04:13:07PM +0000, Cristiano Bianchi wrote: > we have a Fedora2 box, with MySQL 4.0.x, which came with the > distribution. It seems that Fedora spreads MySQL stuff all over the > place (for instance all binaries are in /usr/bin/, instead of > /usr/local/mysql...). I cannot find my.cnf and mysql.sock as well. Look in /etc resp. /var/run for these... MySQL is packaged as it should be, according to current filesystem standards. > I would like to install MySQL 4.1 alongside the 4.0 and run both. It > seems possible, but I cannot (I think) download the RPM as it would > replace the 4.0. If I follow the instructions on the MySQL site, I get > nowhere. Is there anyone who can point me in some directions? No, the package does not provide the possibility to install multiple versions in parallel. In that case, you might want to install the second version manually in a separate tree. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From fedora-devel at camperquake.de Mon Jan 10 16:28:19 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Mon, 10 Jan 2005 17:28:19 +0100 Subject: Multiple MySQL servers In-Reply-To: <838B6189-6322-11D9-804F-000A95CA59FE@keepthinking.it> References: <41E2A4F3.9020803@math.unl.edu> <1105372601.25990.15.camel@opus.phy.duke.edu> <41E2A743.9050802@math.unl.edu> <838B6189-6322-11D9-804F-000A95CA59FE@keepthinking.it> Message-ID: <20050110172819.5221df65@nausicaa.camperquake.de> Hi. Cristiano Bianchi (keepthinking) wrote: > we have a Fedora2 box, with MySQL 4.0.x, which came with the > distribution. No Fedora relase has shipped MySQL 4 so far. -- "A million million spermatazoa, ... And among that billion minus one, Might have chanced to be, Shakespeare, another Newton, a new Donne - But the One was Me." -- Aldous Huxley From katzj at redhat.com Mon Jan 10 16:32:33 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 10 Jan 2005 11:32:33 -0500 Subject: lvm on x86_64? In-Reply-To: <1105373352.30998.5.camel@wintermute.sr.unh.edu> References: <1105373352.30998.5.camel@wintermute.sr.unh.edu> Message-ID: <1105374753.4491.10.camel@bree.local.net> On Mon, 2005-01-10 at 11:09 -0500, Thomas J. Baker wrote: > Trying to install something FC3ish on a Dell 670n without much luck. I > tried booting the latest devel image and it says "lvm is not supported > on this platform". Is this a bug or the truth? Looking through bugzilla, > it looks like the devel image may just be broken. It looks like the latest lvm2 package nuked /sbin/lvm which anaconda depended on. *sigh* Jeremy From peter.backlund at home.se Mon Jan 10 16:37:07 2005 From: peter.backlund at home.se (Peter Backlund) Date: Mon, 10 Jan 2005 17:37:07 +0100 Subject: Multiple MySQL servers In-Reply-To: <838B6189-6322-11D9-804F-000A95CA59FE@keepthinking.it> References: <41E2A4F3.9020803@math.unl.edu> <1105372601.25990.15.camel@opus.phy.duke.edu> <41E2A743.9050802@math.unl.edu> <838B6189-6322-11D9-804F-000A95CA59FE@keepthinking.it> Message-ID: <1105375027.4207.2.camel@localhost.localdomain> m?n 2005-01-10 klockan 16:13 +0000 skrev Cristiano Bianchi: > Hi all, > > we have a Fedora2 box, with MySQL 4.0.x, which came with the > distribution. FC2 came with mysql 3.23. > It seems that Fedora spreads MySQL stuff all over the > place (for instance all binaries are in /usr/bin/, instead of > /usr/local/mysql...). I cannot find my.cnf and mysql.sock as well. To list all mysql packages, run rpm -qa \*mysql\*. To list the contents of any package, run rpm -ql . /Peter From cristiano at keepthinking.it Mon Jan 10 16:55:12 2005 From: cristiano at keepthinking.it (Cristiano Bianchi (keepthinking)) Date: Mon, 10 Jan 2005 16:55:12 +0000 Subject: Multiple MySQL servers In-Reply-To: <20050110172531.A19004@xos037.xos.nl> References: <41E2A4F3.9020803@math.unl.edu> <1105372601.25990.15.camel@opus.phy.duke.edu> <41E2A743.9050802@math.unl.edu> <838B6189-6322-11D9-804F-000A95CA59FE@keepthinking.it> <20050110172531.A19004@xos037.xos.nl> Message-ID: <64A65990-6328-11D9-804F-000A95CA59FE@keepthinking.it> Thanks Jon for your quick response. > No, the package does not provide the possibility to install multiple > versions in parallel. In that case, you might want to install the > second version manually in a separate tree. Would you be so kind to tell me/point me in the direction of how to do that, if you have some time? Thanks. Cristiano Bianchi keepthinking ltd From kyrre at solution-forge.net Mon Jan 10 17:10:10 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 10 Jan 2005 18:10:10 +0100 Subject: HAL policies for port. music players In-Reply-To: <41E23583.6070606@insitesinc.com> References: <1105279990l.30286l.0l@devel.mpeters.us> <1105311052.5141.149.camel@localhost.localdomain> <1105316099l.4843l.7l@devel.mpeters.us> <41E23583.6070606@insitesinc.com> Message-ID: <1105377009.2693.3.camel@localhost.localdomain> man, 10.01.2005 kl. 08.57 skrev Michael Favia: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Michael A. Peters wrote: > | On 01/09/2005 02:50:52 PM, Havoc Pennington wrote: > | > |> > |> My prediction is that mounting it by default is what virtually > |> everyone > |> wants. > | What I'm guessing most users want to do is add and remove files for use > | on the device itself later, which needs to be done with a front end > | that speaks to the devices library database. Thus I would think most > | users want an _application_ to be able to talk to it, which can be > | accomplished by mounting the device when the application wants it. > | > This is a lot of guessing. It all seems to be centered around how should > we interact with newly attached [storage] devices. I've seen the > discussion numbers of times on this and the other lists and as many > crazy ideas as how to solve the dilemma. I dont believe the answer is > that simple. > > Advanced users often prefer to work at the file system level and > interact with storage/mp3/digicams with a file manager and normal/basic > users like to be walked through the process of doing whatever it is they > need to do (normally by an application front-end of some sort). > > I dont particularly like the idea of device connection as an > interrupting UI event nor do i like the idea of auto mounting it without > approval or notification (but i dont think asking the user to jump > through hoops to mount/configure the device is an acceptable solution > either). This also seems to be an issue with network interfaces and > virtually any other connected (hot-plug) device. > > My proposed solution is a system tray based utility that discreetly > notifies users when new devices are detected and provides them with an > opportunity to mount/configure the device. This way we dont interrupt > the user interface but instead provide them with information to make the > decision with the added benefit of allowing them to make their selected > action permanent in the future. > I would very much like my usb pen storage to be mounted when inserting it, without having to click a lot of stuff, thank you. > Devices need not be handled immediately upon notification but can be > delayed until the user has finished the task at hand. Devices would > probably remain in the systray utility until they are configured or > detached from the system again. Perhaps we leave them in there the whole > time and have 3 states of device existence (Newly Attached, Configured, > Removed). > > I'd be happy to write up a full mock up of this process if there is any > interest. There are a number of ways i believe we can make the device > initialization and configuration process simpler, unified, elegant and > more powerful at the same time. This is one of the single most important > issues for desktop migration in my opinion. People are ok using whatever > applications as long as they "Just work" the way they want them to but > they are very unwilling to get into the midst of a device configuration > debacle. > > Best wishes, > - -mf > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD8DBQFB4jWCBVsNYjF2rDYRAi+0AJ9VJFYcQ4nswqCBqJxkwBwpZrNZKwCeLARw > RgOxPSllI0G4DAC39Hk479o= > =oYRB > -----END PGP SIGNATURE----- From peter.backlund at home.se Mon Jan 10 17:30:37 2005 From: peter.backlund at home.se (Peter Backlund) Date: Mon, 10 Jan 2005 18:30:37 +0100 Subject: Multiple MySQL servers In-Reply-To: <64A65990-6328-11D9-804F-000A95CA59FE@keepthinking.it> References: <41E2A4F3.9020803@math.unl.edu> <1105372601.25990.15.camel@opus.phy.duke.edu> <41E2A743.9050802@math.unl.edu> <838B6189-6322-11D9-804F-000A95CA59FE@keepthinking.it> <20050110172531.A19004@xos037.xos.nl> <64A65990-6328-11D9-804F-000A95CA59FE@keepthinking.it> Message-ID: <1105378237.4207.5.camel@localhost.localdomain> m?n 2005-01-10 klockan 16:55 +0000 skrev Cristiano Bianchi: > Thanks Jon for your quick response. > > > No, the package does not provide the possibility to install multiple > > versions in parallel. In that case, you might want to install the > > second version manually in a separate tree. > > Would you be so kind to tell me/point me in the direction of how to do > that, if you have some time? Build mysql 4.1 from source, using --prefix=/usr/local/mysql4.1 for example. Run a make DESTDIR=/tmp/mysql install test first, to make sure no files are installed outside the prefix. If there are files that don't obey the prefix, manually put them in place and add a "4.1" suffix to distinguish them from rpm installed files. Examine the output of ./configure --help for any parameters that are useful. /Peter From kyrre at solution-forge.net Mon Jan 10 17:31:25 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 10 Jan 2005 18:31:25 +0100 Subject: ssh X forwarding change in FC3 In-Reply-To: <1105123735.4464.5.camel@localhost.localdomain> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> Message-ID: <1105378285.2693.7.camel@localhost.localdomain> Hmm? i haven't seen any problems with it, and i have used SSH (with X) from anything from a mac to fc3 and fc2 computers, to fc3 and fc2 computers. Never any problem. Only thing worth mention is that the mac and fc2 didn't understand the -Y flag, it just said it wasn't a real flag. So we stuck to X, and everything worked. From fc3 we also needed -Y, and then copy/paste would work. No problem whatsoever. fre, 07.01.2005 kl. 19.48 skrev Havoc Pennington: > Hi, > > The openssh change is totally broken, because none of the clients people > use work with "trusted X" and they could not reasonably be modified to > do so, without an effort on the scale of SELinux or even larger. The > fact that the X server even supports "trusted X" is probably total > nonsense. > > So, anyone who claims that "trusted X" is more secure is basically > making a "concrete blocks not connected to the Internet are secure" > argument. > > Maybe people who only run xterms would find the new ssh default useful, > but even they presumably like to cut and paste... > > I don't know why the default is something that we know is useless and > doesn't work. > > Havoc > From kyrre at solution-forge.net Mon Jan 10 17:33:02 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 10 Jan 2005 18:33:02 +0100 Subject: Multiple MySQL servers In-Reply-To: <64A65990-6328-11D9-804F-000A95CA59FE@keepthinking.it> References: <41E2A4F3.9020803@math.unl.edu> <1105372601.25990.15.camel@opus.phy.duke.edu> <41E2A743.9050802@math.unl.edu> <838B6189-6322-11D9-804F-000A95CA59FE@keepthinking.it> <20050110172531.A19004@xos037.xos.nl> <64A65990-6328-11D9-804F-000A95CA59FE@keepthinking.it> Message-ID: <1105378382.2693.9.camel@localhost.localdomain> Hmm.. drop the RPM and install the source tarball with --prefix=/usr/local/mysql41/ ? man, 10.01.2005 kl. 17.55 skrev Cristiano Bianchi: > Thanks Jon for your quick response. > > > No, the package does not provide the possibility to install multiple > > versions in parallel. In that case, you might want to install the > > second version manually in a separate tree. > > Would you be so kind to tell me/point me in the direction of how to do > that, if you have some time? > > Thanks. > > Cristiano Bianchi > keepthinking ltd From michael.favia at insitesinc.com Mon Jan 10 17:38:53 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Mon, 10 Jan 2005 11:38:53 -0600 Subject: HAL policies for port. music players In-Reply-To: <1105377009.2693.3.camel@localhost.localdomain> References: <1105279990l.30286l.0l@devel.mpeters.us> <1105311052.5141.149.camel@localhost.localdomain> <1105316099l.4843l.7l@devel.mpeters.us> <41E23583.6070606@insitesinc.com> <1105377009.2693.3.camel@localhost.localdomain> Message-ID: <41E2BDAD.2010501@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kyrre Ness Sjobak wrote: | man, 10.01.2005 kl. 08.57 skrev Michael Favia: | | |> I would very much like my usb pen storage to be mounted when inserting |> it, without having to click a lot of stuff, thank you. Which is understandable and possible after the first time you tell it what to do. I think that asking the user the first time which application to use and possibly mounting parameters is an acceptable inconvienence. - -mf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB4r2tBVsNYjF2rDYRAj3rAJ9CUYzqRYaY506RQwXGvJzOfoXkQgCfdngF qXtDN5iUmOw0EN3/lfNzELY= =szSv -----END PGP SIGNATURE----- From P at draigBrady.com Mon Jan 10 17:39:40 2005 From: P at draigBrady.com (P at draigBrady.com) Date: Mon, 10 Jan 2005 17:39:40 +0000 Subject: ssh X forwarding change in FC3 In-Reply-To: <1105378285.2693.7.camel@localhost.localdomain> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> <1105378285.2693.7.camel@localhost.localdomain> Message-ID: <41E2BDDC.4020004@draigBrady.com> Kyrre Ness Sjobak wrote: > Hmm? i haven't seen any problems with it, and i have used SSH (with X) > from anything from a mac to fc3 and fc2 computers, to fc3 and fc2 > computers. Never any problem. Only thing worth mention is that the mac > and fc2 didn't understand the -Y flag, it just said it wasn't a real > flag. So we stuck to X, and everything worked. Yes the problem was only introduced in FC3 > From fc3 we also needed > -Y, and then copy/paste would work. No problem whatsoever. Yes, that what we're saying. -Y is a new option, the long version of which is --dont-fail-in-obscure-ways The default should be to work and we can still have a --fail-in-obscure-ways option. -- P?draig Brady - http://www.pixelbeat.org -- From shiva at sewingwitch.com Mon Jan 10 17:44:39 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 10 Jan 2005 09:44:39 -0800 Subject: Multiple MySQL servers In-Reply-To: <1105375027.4207.2.camel@localhost.localdomain> References: <41E2A4F3.9020803@math.unl.edu> <1105372601.25990.15.camel@opus.phy.duke.edu> <41E2A743.9050802@math.unl.edu> <838B6189-6322-11D9-804F-000A95CA59FE@keepthinking.it> <1105375027.4207.2.camel@localhost.localdomain> Message-ID: --On Monday, January 10, 2005 5:37 PM +0100 Peter Backlund wrote: > To list all mysql packages, run rpm -qa \*mysql\*. Note that the packages from MySQL.com have mixed case names. So try "rpm -qa | grep -i mysql" if they might be installed. From jspaleta at gmail.com Mon Jan 10 18:11:23 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 10 Jan 2005 13:11:23 -0500 Subject: HAL policies for port. music players In-Reply-To: <41E2BDAD.2010501@insitesinc.com> References: <1105279990l.30286l.0l@devel.mpeters.us> <1105311052.5141.149.camel@localhost.localdomain> <1105316099l.4843l.7l@devel.mpeters.us> <41E23583.6070606@insitesinc.com> <1105377009.2693.3.camel@localhost.localdomain> <41E2BDAD.2010501@insitesinc.com> Message-ID: <604aa79105011010117b7f415d@mail.gmail.com> On Mon, 10 Jan 2005 11:38:53 -0600, Michael Favia wrote: > Which is understandable and possible after the first time you tell it > what to do. I think that asking the user the first time which > application to use and possibly mounting parameters is an acceptable > inconvienence. I think you are somewhat on the same page as David Zeuthen with regard to what direction should be taken to make hotpluggable devices more integrated in the desktop. Whether or not the new system prompts for interaction by default or just notifies is a UI detail that could be argued about later... number 4 on David's list. The real trick is bulding up the per-device configuration for each user and teaching the desktop ui how to access those per device properties. I think David did a good job prioritizing the technical issues in his list. -jef From pri.rhl3 at iadonisi.to Mon Jan 10 19:50:03 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Mon, 10 Jan 2005 14:50:03 -0500 Subject: [Possibly OT] Trademarks Message-ID: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> At the risk of stirring up a hornets' nest, I'd like to pose the question to Red Hatters: what approach are you taking to trademarks? Apparently, there is (was?) some discussion going on at debian-legal regarding Mozilla Firefox and Mozilla Thunderbird. At first glance, I see that there are quite a few patches included in the firefox rpm in FC3 and even more in rawhide and I'm wondering if Red Hat has filtered this through its legal eagles, since it is still called Firefox. More generally, what will the Fedora Project's (and possible, by extension, RHEL's) handling of trademark issues be going forward if more allegedly FOSS projects begin to assert trademarks. For the Mozilla case, based on some of the excerpts I've read, they're expectation is unreasonable: they want people to know they are using Firefox and Thunderbird (by name), but they want to control what types of changes are made to the software. To me, that's end-run around the FOSS licenses which they have chosen. Yes, I know some people will point out Red Hat's own trademark policy regarding Fedora Core, but the difference I see is that Red Hat isn't likely to make one whit of noise about derivate works of Fedora Core that have been renamed. IMHO, The Mozilla Foundation seems to want people to use the name, but at the cost of being the gatekeeper where it comes to the types of changes that can be made. Something tells me that FOSS projects that begin to take this path are going to increasing face staunch resistance. They're going to have to take Linus' liberal approach to the Linux trademark, or face there names being scratched out where needed to comply with their own trademark guidelines. Let me close by saying that I do understand the desire (and need) to protect trademarks, but it's inescapable that it conflicts with the spirit of FOSS. Thoughts? -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 10 20:27:02 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 10 Jan 2005 21:27:02 +0100 Subject: [Possibly OT] Trademarks In-Reply-To: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> (Paul Iadonisi's message of "Mon, 10 Jan 2005 14:50:03 -0500") References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> Message-ID: <87is651149.fsf@kosh.ultra.csn.tu-chemnitz.de> pri.rhl3 at iadonisi.to (Paul Iadonisi) writes: > At the risk of stirring up a hornets' nest, I'd like to pose the > question to Red Hatters: what approach are you taking to trademarks? > Apparently, there is (was?) some discussion going on at debian-legal > regarding Mozilla Firefox and Mozilla Thunderbird. At first glance, I > see that there are quite a few patches included in the firefox rpm in > FC3 and even more in rawhide and I'm wondering if Red Hat has filtered > this through its legal eagles, since it is still called Firefox. ACK; I really doubt whether rawhide's firefox can be called 'Firefox'. The applied patches lower quality and reputation of the Mozilla Firefox product significantly (buttugly icons, removed functionality for upgrading extensions with security leaks) so I do not see how the Mozilla Foundation could accept this package as an official build or a "Community Edition"; it is definitively an "Iceweasel". Enrico From tsilims at gmail.com Mon Jan 10 20:44:28 2005 From: tsilims at gmail.com (m g) Date: Mon, 10 Jan 2005 14:44:28 -0600 Subject: [Possibly OT] Trademarks In-Reply-To: <87is651149.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <87is651149.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: An "Iceweasel"? > it is definitively an "Iceweasel". -- MG From caillon at redhat.com Mon Jan 10 20:50:12 2005 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 10 Jan 2005 15:50:12 -0500 Subject: [Possibly OT] Trademarks In-Reply-To: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> Message-ID: <41E2EA84.4000504@redhat.com> Paul Iadonisi wrote: > At the risk of stirring up a hornets' nest, I'd like to pose the > question to Red Hatters: what approach are you taking to trademarks? > Apparently, there is (was?) some discussion going on at debian-legal > regarding Mozilla Firefox and Mozilla Thunderbird.At first glance, I > see that there are quite a few patches included in the firefox rpm in > FC3 and even more in rawhide and I'm wondering if Red Hat has filtered > this through its legal eagles, since it is still called Firefox. I have already replied to this issue (on this list) and noted that we have an agreement with the Mozilla Foundation. Additionally, I have requested permission from the Mozilla Foundation on potential problem areas before patching them into our distribution as of recently. I have not received word of any issue that the Mozilla Foundation has with our officially released packages. > For the Mozilla case, based on some of the excerpts I've read, they're > expectation is unreasonable: they want people to know they are using > Firefox and Thunderbird (by name), but they want to control what types > of changes are made to the software. To me, that's end-run around the > FOSS licenses which they have chosen. Stop misrepresenting it. You are allowed to change whatever you want without recourse. What the Mozilla Foundation is protecting is the name "Firefox" and the respective art. They want to make sure that if you are distributing "Firefox", you aren't selling an IE/NS4 clone. For example, there have been occurences in the past with certain distributors patching gecko which negatively altered the standards compliance of the browser, after their patches had been rejected by upstream. Note that it is completely valid for a distributor to do this per the Mozilla Public License, however, when bug reports and news items come back about certain versions of "Mozilla" being non-conformant to standards it claims to support, that's bad PR and hurts Mozilla and, indirectly open source. Whether or not you agree with that, it does not dillute the fact that the source code is out there and under an open source license (it can be re-distributed as (L)GPL only if you wish) and you can make whatever changes to it that you wish. If you are making substantive changes to it already, what's the big deal about a minor change to its name and artwork? It's obviously not the same software, no need to pretend it is, though it should be attributed. The fact that you are even allowed to see the source and modify and freely distribute such an integral piece of software on the desktop is just awesome, IMO. Also please note that in order to even get the "Firefox" name and artwork built in if you are rolling your own build, you have to knowingly turn it on with a few environment variables and configure flags. From max_list at fedorafaq.org Mon Jan 10 21:07:47 2005 From: max_list at fedorafaq.org (Max Kanat-Alexander) Date: Mon, 10 Jan 2005 13:07:47 -0800 Subject: soundcard access In-Reply-To: <20050105122233.689b4198@nausicaa.camperquake.de> References: <1104863305.2732.8.camel@p.linuxcenter.cl> <1104862898.21468.25.camel@nexus.verbum.private> <20050104210920.11a12753@nausicaa.camperquake.de> <20050104210435.GA6262@devserv.devel.redhat.com> <20050104220922.1b5d25eb@nausicaa.camperquake.de> <1104880012.3866.7.camel@max.localdomain> <20050105122233.689b4198@nausicaa.camperquake.de> Message-ID: <1105391267.4101.4.camel@max.localdomain> On Wed, 2005-01-05 at 12:22 +0100, Ralf Ertzinger wrote: > Hi. > > Max Kanat-Alexander wrote: > > > I think that KT133A is your problem. I have a KT133, and they have > > a famous interrupt problem. That is, at least with my M-Audio Delta 44, > > unless I set the PCI Latency to 0 and turn off PCI Delayed Transaction > > in the BIOS, I get crackle, crackle, crackle. > > Can these parameters be set from a running system in some way, or must this > be done on powerup/reset? You have to do it in the BIOS, usually. > Yes, I had that too, with my SB16 (ISA! Yay!) under Win2k (and Linux), if > the card was using 16bit DMA. 8bit DMA fixed that. > > The current card is an "Ensoniq 5880 AudioPCI" (Soundblaster 128 or > something like that), and it worked just fine with win2k (while I had > that), and with Linux, too, as long as the OSS drivers were used. ALSA > inevitably starts to crackle after a while. Yep, sounds similar to my problem (except that I never could use OSS, because it doesn't support my soundcard). I find that forcing ESD to use 48,000 Hz also helps, sometimes, for some odd reason. -Max From alan at redhat.com Mon Jan 10 21:08:45 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 10 Jan 2005 16:08:45 -0500 Subject: [Possibly OT] Trademarks In-Reply-To: <41E2EA84.4000504@redhat.com> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <41E2EA84.4000504@redhat.com> Message-ID: <20050110210845.GC22602@devserv.devel.redhat.com> Actually on the subject of firefox patches - any idea why the Welsh translation stuff seems to have just gotten stuck and despite being complete and all paperwork done apparently forgotten. From caillon at redhat.com Mon Jan 10 21:14:32 2005 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 10 Jan 2005 16:14:32 -0500 Subject: [Possibly OT] Trademarks In-Reply-To: <20050110210845.GC22602@devserv.devel.redhat.com> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <41E2EA84.4000504@redhat.com> <20050110210845.GC22602@devserv.devel.redhat.com> Message-ID: <41E2F038.5050708@redhat.com> Alan Cox wrote: > Actually on the subject of firefox patches - any idea why the Welsh translation > stuff seems to have just gotten stuck and despite being complete and all > paperwork done apparently forgotten. "stuck"? Feel free to post a bug about it. :) From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 10 21:13:16 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 10 Jan 2005 22:13:16 +0100 Subject: [Possibly OT] Trademarks In-Reply-To: (m. g.'s message of "Mon, 10 Jan 2005 14:44:28 -0600") References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <87is651149.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <87ekgt0yz7.fsf@kosh.ultra.csn.tu-chemnitz.de> tsilims at gmail.com (m g) writes: > An "Iceweasel"? There is a three level naming of the Mozilla Firefox product (see [1] and [2] for more details): 1. The offical 'Firefox' name + the fox-on-earth logo that must be approved by Mozilla Foundation and must contain minor changes only (other bookmarks, other startup-page, official localized builds). 2. The 'Firefox community edition' can contain some more changes (e.g. another default theme, other default settings (e.g. use-system-colors)). 3. "Iceweasel" level Significant functional changes (e.g. removed extension-upgrade capability); binary must not be called 'firefox' and the official artwork must not be used anymore. The naming was created on the Debian legal list. Enrico Footnotes: [1] http://www.mozilla.org/foundation/trademarks/policy.html [2] http://www.mozilla.org/foundation/trademarks/distribution-policy.html From snickell at redhat.com Mon Jan 10 21:17:09 2005 From: snickell at redhat.com (Seth Nickell) Date: Mon, 10 Jan 2005 16:17:09 -0500 Subject: [Possibly OT] Trademarks In-Reply-To: <87is651149.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <87is651149.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1105391830.5541.1.camel@localhost.localdomain> On Mon, 2005-01-10 at 21:27 +0100, Enrico Scholz wrote: > pri.rhl3 at iadonisi.to (Paul Iadonisi) writes: > > > At the risk of stirring up a hornets' nest, I'd like to pose the > > question to Red Hatters: what approach are you taking to trademarks? > > Apparently, there is (was?) some discussion going on at debian-legal > > regarding Mozilla Firefox and Mozilla Thunderbird. At first glance, I > > see that there are quite a few patches included in the firefox rpm in > > FC3 and even more in rawhide and I'm wondering if Red Hat has filtered > > this through its legal eagles, since it is still called Firefox. > > ACK; I really doubt whether rawhide's firefox can be called 'Firefox'. > The applied patches lower quality and reputation of the Mozilla Firefox > product significantly (buttugly icons, removed functionality for upgrading > extensions with security leaks) so I do not see how the Mozilla Foundation > could accept this package as an official build or a "Community Edition"; > it is definitively an "Iceweasel". Chris Aillon is a girl!!! From hp at redhat.com Mon Jan 10 21:19:40 2005 From: hp at redhat.com (Havoc Pennington) Date: Mon, 10 Jan 2005 16:19:40 -0500 Subject: ssh X forwarding change in FC3 In-Reply-To: <1105378285.2693.7.camel@localhost.localdomain> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> <1105378285.2693.7.camel@localhost.localdomain> Message-ID: <1105391980.2195.56.camel@localhost.localdomain> On Mon, 2005-01-10 at 18:31 +0100, Kyrre Ness Sjobak wrote: > Hmm? i haven't seen any problems with it, and i have used SSH (with X) > from anything from a mac to fc3 and fc2 computers, to fc3 and fc2 > computers. Never any problem. Only thing worth mention is that the mac > and fc2 didn't understand the -Y flag, it just said it wasn't a real > flag. So we stuck to X, and everything worked. From fc3 we also needed > -Y, and then copy/paste would work. No problem whatsoever. > -X of course is going to work. If -Y works for you I'm surprised. Are you saying you pass both -X and -Y? Maybe that disables trusted mode. Copy and paste should not work from a trusted app to untrusted because the untrusted app would need to read data from a trusted window. Havoc From hp at redhat.com Mon Jan 10 21:22:04 2005 From: hp at redhat.com (Havoc Pennington) Date: Mon, 10 Jan 2005 16:22:04 -0500 Subject: ssh X forwarding change in FC3 In-Reply-To: <1105391980.2195.56.camel@localhost.localdomain> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> <1105378285.2693.7.camel@localhost.localdomain> <1105391980.2195.56.camel@localhost.localdomain> Message-ID: <1105392124.2195.57.camel@localhost.localdomain> On Mon, 2005-01-10 at 16:19 -0500, Havoc Pennington wrote: > On Mon, 2005-01-10 at 18:31 +0100, Kyrre Ness Sjobak wrote: > > Hmm? i haven't seen any problems with it, and i have used SSH (with X) > > from anything from a mac to fc3 and fc2 computers, to fc3 and fc2 > > computers. Never any problem. Only thing worth mention is that the mac > > and fc2 didn't understand the -Y flag, it just said it wasn't a real > > flag. So we stuck to X, and everything worked. From fc3 we also needed > > -Y, and then copy/paste would work. No problem whatsoever. > > > > -X of course is going to work. If -Y works for you I'm surprised. Are > you saying you pass both -X and -Y? Maybe that disables trusted mode. > Copy and paste should not work from a trusted app to untrusted because > the untrusted app would need to read data from a trusted window. > Doh, -Y enables trusted X so all the windows are trusted. The default (have untrusted windows) is the thing that doesn't work. Havoc From jspaleta at gmail.com Mon Jan 10 21:21:26 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 10 Jan 2005 16:21:26 -0500 Subject: [Possibly OT] Trademarks In-Reply-To: <41E2EA84.4000504@redhat.com> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <41E2EA84.4000504@redhat.com> Message-ID: <604aa79105011013218116e70@mail.gmail.com> On Mon, 10 Jan 2005 15:50:12 -0500, Christopher Aillon wrote: > I have already replied to this issue (on this list) and noted that we > have an agreement with the Mozilla Foundation. Additionally, I have > requested permission from the Mozilla Foundation on potential problem > areas before patching them into our distribution as of recently. I have > not received word of any issue that the Mozilla Foundation has with our > officially released packages. My one question is how is the mozilla situation different from the pine situation in practise. I realize the licensing isn't the same, but my understanding is the pine license allowed for patched versions to be distributed if the name was changed to indicate that the distributed copy was not the same as upstream. What happens if you want to put in a patch into fedora that upstream mozilla does not agree with? If you have to continue to get upstream approval before every patch is applied, don't you run the risk of disagreement which will necesitate renaming and replacing the icons? Isn't this a potential maintence issue for Core? Disagreements do happen. I have no problem with mozilla protecting its marks. But I would prefer fedora to package mozilla using the iceweazel option and not use mozilla's marks at all to forestall any abrupt branding change required over disagreeable patches. > Also please note that in order to even get the "Firefox" name and > artwork built in if you are rolling your own build, you have to > knowingly turn it on with a few environment variables and configure flags. Are you talking about the upstream source or the fedora srpm here? -jef From alan at redhat.com Mon Jan 10 21:35:16 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 10 Jan 2005 16:35:16 -0500 Subject: [Possibly OT] Trademarks In-Reply-To: <604aa79105011013218116e70@mail.gmail.com> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <41E2EA84.4000504@redhat.com> <604aa79105011013218116e70@mail.gmail.com> Message-ID: <20050110213516.GA13822@devserv.devel.redhat.com> On Mon, Jan 10, 2005 at 04:21:26PM -0500, Jeff Spaleta wrote: > pine license allowed for patched versions to be distributed if the > name was changed to indicate that the distributed copy was not the > same as upstream. And various other contortions were followed. > What happens if you want to put in a patch into fedora that upstream > mozilla does not agree with? If you have to continue to get upstream We change the name. We did that with Apache (we ship "httpd"). And I'd note we ask third parties to do the same if they revamp Fedora into something else. From caillon at redhat.com Mon Jan 10 21:41:09 2005 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 10 Jan 2005 16:41:09 -0500 Subject: [Possibly OT] Trademarks In-Reply-To: <604aa79105011013218116e70@mail.gmail.com> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <41E2EA84.4000504@redhat.com> <604aa79105011013218116e70@mail.gmail.com> Message-ID: <41E2F675.6050001@redhat.com> Jeff Spaleta wrote: > What happens if you want to put in a patch into fedora that upstream > mozilla does not agree with? If you have to continue to get upstream > approval before every patch is applied, don't you run the risk of > disagreement which will necesitate renaming and replacing the icons? > Isn't this a potential maintence issue for Core? Disagreements do > happen. I have no problem with mozilla protecting its marks. But I > would prefer fedora to package mozilla using the iceweazel option and > not use mozilla's marks at all to forestall any abrupt branding change > required over disagreeable patches. We want to stay as close to upstream as possible. I have been an upstream developer before joining Red Hat, and continue pushing my changes upstream. The icons patches are preparing to be landed upstream (I've sort of let them languish a little because of holidays and RHEL bugs I've been working on). My thoughts in general on this are basically that one of the reasons we are using "Firefox" is for the brand name recognition. Websites, ISVs, etc. will say they work with Firefox, not Iceweasel, not Epiphany. People complained ON THIS LIST because we were not using "Firefox" at one point. Well, we are now. If we decide to drop "Firefox", it might make more sense to switch back to Epiphany rather than Iceweasel, which fits in stronger with GNOME and the desktop. I'd like however to work together with the Mozilla Foundation rather than against them. Obviously, they want us as a distributor and we want to distribute their software. >>Also please note that in order to even get the "Firefox" name and >>artwork built in if you are rolling your own build, you have to >>knowingly turn it on with a few environment variables and configure flags. > > > Are you talking about the upstream source or the fedora srpm here? Upstream source. From notting at redhat.com Mon Jan 10 21:56:00 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 10 Jan 2005 16:56:00 -0500 Subject: udev: Directory for custom device nodes. In-Reply-To: <41E25EBD.3040800@redhat.com> References: <41E25EBD.3040800@redhat.com> Message-ID: <20050110215600.GC16171@nostromo.devel.redhat.com> Harald Hoyer (harald at redhat.com) said: > Due to > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144593 > I am thinking of another directory to put device nodes in, which should > be copied over to /dev on system start. > > Any suggestions? I'd think that a series of makedev invocations to run would be safer. Bill From jspaleta at gmail.com Mon Jan 10 22:10:03 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 10 Jan 2005 17:10:03 -0500 Subject: [Possibly OT] Trademarks In-Reply-To: <41E2F675.6050001@redhat.com> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <41E2EA84.4000504@redhat.com> <604aa79105011013218116e70@mail.gmail.com> <41E2F675.6050001@redhat.com> Message-ID: <604aa791050110141025f30abb@mail.gmail.com> On Mon, 10 Jan 2005 16:41:09 -0500, Christopher Aillon wrote: > We want to stay as close to upstream as possible Thats great... but you can do that using the iceweasel option. But when there is a disagreement over a patch and there will be at some point.... using the non-ioeweasel options will prevent Fedora Core developers from being able to apply the patch without upstream approval. This a maintence burden... and it will happen at some point. If you have to keep getting approval for each patch you want to apply.... you are bound to run into a situation where upstream disagrees and you sit arguing about it for a month to keep the branding agreement in place. "As close as possible" doesn't mean upstream will approve of all the changes. Instead of burning that disagreement bridge when we get to it... how about we avoid the problem altogether and choose the iceweasel option because its the most flexible. > I'd like however to work together with the Mozilla Foundation rather > than against them. Obviously, they want us as a distributor and we want > to distribute their software. Using the iceweasel option doesn't prevent you or any other fedora developer from working with upstream as much as possible. But disagreements do happen and I'd rather see fedora packaging things free of trademark licensing requirements that impact the developers ability to patch and maintain what is shipping inside Core, as much as possible. How much fun would it be if the linux kernel was packaged in a way that demanded upstream approval of every patch before it was applied to keep a branding agreement in place to prevent having to rename the package and executables? That would be pretty unfun. > > Are you talking about the upstream source or the fedora srpm here? > > Upstream source. Can you find a way to enforce the same sort of rebuilding policy for the fedora srpm so that anyone rebuilding and patching the mozilla srpm has to use 'magic' to get the trademark protected marks? Red Hat has an agreement with mozilla, but downstream community members using fedora's srpms do not. It seems inappropriate to hand fedora community srpms that short-circuit the trademark protections that the upstream source have built in to prevent people from casually rebuilding a package that is infringing on mozilla's marks. -jef"Red Hat shouldn't be relying on special relationship agreements to produce patched versions of anything in fedora"spaleta From pri.rhl3 at iadonisi.to Mon Jan 10 22:17:13 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Mon, 10 Jan 2005 17:17:13 -0500 Subject: [Possibly OT] Trademarks In-Reply-To: <41E2EA84.4000504@redhat.com> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <41E2EA84.4000504@redhat.com> Message-ID: <1105395433.21221.47.camel@va.local.linuxlobbyist.org> On Mon, 2005-01-10 at 15:50 -0500, Christopher Aillon wrote: > Paul Iadonisi wrote: [snip] > > For the Mozilla case, based on some of the excerpts I've read, they're > > expectation is unreasonable: they want people to know they are using > > Firefox and Thunderbird (by name), but they want to control what types > > of changes are made to the software. To me, that's end-run around the > > FOSS licenses which they have chosen. > > > Stop misrepresenting it. You are allowed to change whatever you want > without recourse. What the Mozilla Foundation is protecting is the name > "Firefox" and the respective art. They want to make sure that if you > are distributing "Firefox", you aren't selling an IE/NS4 clone. [snip] > changes to it that you wish. If you are making substantive changes to > it already, what's the big deal about a minor change to its name and > artwork? It's obviously not the same software, no need to pretend it > is, though it should be attributed. The fact that you are even allowed > to see the source and modify and freely distribute such an integral > piece of software on the desktop is just awesome, IMO. And I never implied it *wasn't* awesome. As far as misrepresenting it, I don't believe I was, except for one matter that I wasn't aware of. I wasn't aware that it was a *minor* change to change the name and the artwork. For example, though RHEL has specific trademark guidelines that only require the modification of two rpms, Whitebox Enterprise Linux has gone a lot further to be on the safe side. At one time, before Red Hat became more assertive with its trademark policy (and before I read it), I wondered how hard it would be to track down all the images that are trademarked and replace them. How many packages would need changing? I was relieved when I read the policy and found that only two packages needed modification. If it's simple to change the name of Mozilla products if need be (and it looks like it won't be, for the foreseeable future, if ever), then I'm satisfied. Trademarks can cause a problem and potentially clash with the very licenses that are used to cover software if it is not dead easy to make the change to non-trademarked images and names. It appears that The Mozilla Foundation has done just that. Kudos to them for that. I brought up Mozilla because it's what's being discussed on debian- legal (and subsequently, on lwn.net). My apologies for singling it out. It was but one possible example of what could end up being a bigger problem if every FOSS developer whose software is included in various distributions starts asserting trademark controls. I'm satisfied about the Mozilla (non-)issue, but I don't think I'm alone in my concern about the possibility of many other FOSS developers beginning to assert trademarks. My concern will go away if the trend is for those same developers to make it easy to change (via a simple build option) to a non-trademarked version. Admittedly, it shouldn't be a huge issue for the majority of tools out there because if they've been out there long enough, it's a little late to try to enforce it now. Mozilla's products are relatively new in the grand scheme of things, so that's not a problem they will likely have. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From kyrre at solution-forge.net Mon Jan 10 22:29:37 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 10 Jan 2005 23:29:37 +0100 Subject: HAL policies for port. music players In-Reply-To: <604aa79105011010117b7f415d@mail.gmail.com> References: <1105279990l.30286l.0l@devel.mpeters.us> <1105311052.5141.149.camel@localhost.localdomain> <1105316099l.4843l.7l@devel.mpeters.us> <41E23583.6070606@insitesinc.com> <1105377009.2693.3.camel@localhost.localdomain> <41E2BDAD.2010501@insitesinc.com> <604aa79105011010117b7f415d@mail.gmail.com> Message-ID: <1105396177.30862.11.camel@localhost.localdomain> man, 10.01.2005 kl. 19.11 skrev Jeff Spaleta: > On Mon, 10 Jan 2005 11:38:53 -0600, Michael Favia > wrote: > > Which is understandable and possible after the first time you tell it > > what to do. I think that asking the user the first time which > > application to use and possibly mounting parameters is an acceptable > > inconvienence. > > I think you are somewhat on the same page as David Zeuthen with > regard to what direction should be taken to make hotpluggable devices > more integrated in the desktop. Whether or not the new system prompts > for interaction by default or just notifies is a UI detail that could > be argued about later... number 4 on David's list. The real trick is > bulding up the per-device configuration for each user and teaching the > desktop ui how to access those per device properties. I think David > did a good job prioritizing the technical issues in his list. > > -jef ... And i don't want to be pestered by users demanding me to type the root pasword every time they want to use their usb memory plug. When it comes to those devices, it should be just plug'n'play. No fuss. Like it is now. Of cource, you could create a lot of fuzz, and having some ability to tell the computer "don't allow anyone but user XYZ to mount memory plug named foo". So what? Take the plug and stick it into another box, linux, mac, or windows... If you want such kind of security... encryption. Not that i would oppose some nice GUI where you could log on as root and define some special stuff (as the rest of fstab etc) - but not default? It's a big enough pest to have to configure the DNS and install my install-the-rest-of-the-software-from-server script on every machine... Pluss, it might be a waste of developer time. What about getting a proper gui for the package system? Would'nt that benefit the comunity more? Next question... From hp at redhat.com Mon Jan 10 22:53:41 2005 From: hp at redhat.com (Havoc Pennington) Date: Mon, 10 Jan 2005 17:53:41 -0500 Subject: [Possibly OT] Trademarks In-Reply-To: <604aa791050110141025f30abb@mail.gmail.com> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <41E2EA84.4000504@redhat.com> <604aa79105011013218116e70@mail.gmail.com> <41E2F675.6050001@redhat.com> <604aa791050110141025f30abb@mail.gmail.com> Message-ID: <1105397621.2195.97.camel@localhost.localdomain> On Mon, 2005-01-10 at 17:10 -0500, Jeff Spaleta wrote: > On Mon, 10 Jan 2005 16:41:09 -0500, Christopher Aillon > wrote: > > > We want to stay as close to upstream as possible > > Thats great... but you can do that using the iceweasel option. But > when there is a disagreement over a patch and there will be at some > point.... using the non-ioeweasel options will prevent Fedora Core > developers from being able to apply the patch without upstream > approval. This a maintence burden... and it will happen at some point. It already has happened, essentially. We (well, many of us, not everyone) wanted to contribute a native widgets/HIG version of Firefox; but upstream will not accept that patch under the Firefox name. So this sort of argument has come up. Because they wouldn't take the patch we decided to work on other stuff (including non-browser-related) and right now everything we're doing with Firefox should land upstream. caillon has it under control. Changing the configure arguments in the packages and doing an Obsoletes/Provides firefox wouldn't take very long, if we need to do it someday. So there's no point stressing about hypotheticals. There's value to calling it Firefox for now (if only to avoid user confusion) and if we have to change it someday, it will cause some problems but they'll be the same problems if we change it today. Havoc From mpeters at mac.com Mon Jan 10 23:30:26 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 10 Jan 2005 23:30:26 +0000 Subject: HAL policies for port. music players In-Reply-To: <41E2BDAD.2010501@insitesinc.com> (from michael.favia@insitesinc.com on Mon Jan 10 09:38:53 2005) References: <1105279990l.30286l.0l@devel.mpeters.us> <1105311052.5141.149.camel@localhost.localdomain> <1105316099l.4843l.7l@devel.mpeters.us> <41E23583.6070606@insitesinc.com> <1105377009.2693.3.camel@localhost.localdomain> <41E2BDAD.2010501@insitesinc.com> Message-ID: <1105399826l.5018l.1l@devel.mpeters.us> On 01/10/2005 09:38:53 AM, Michael Favia wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Kyrre Ness Sjobak wrote: > | man, 10.01.2005 kl. 08.57 skrev Michael Favia: > | > | > |> I would very much like my usb pen storage to be mounted when > inserting > |> it, without having to click a lot of stuff, thank you. > > Which is understandable and possible after the first time you tell it > what to do. I think that asking the user the first time which > application to use and possibly mounting parameters is an acceptable > inconvienence. I like that solution as well. From mpeters at mac.com Mon Jan 10 23:37:19 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 10 Jan 2005 23:37:19 +0000 Subject: HAL policies for port. music players In-Reply-To: (from mike@navi.cx on Mon Jan 10 04:52:24 2005) References: <1105279990l.30286l.0l@devel.mpeters.us> <1105311052.5141.149.camel@localhost.localdomain> <1105316099l.4843l.7l@devel.mpeters.us> Message-ID: <1105400239l.5018l.2l@devel.mpeters.us> On 01/10/2005 04:52:24 AM, Mike Hearn wrote: > > OK so that doesn't give you the best experience as right now Nautilus > insists on putting a trash can on the player, and also Nautilus can't > sync > two directories together. I started writing an app to do all this but > realised it'd be a lot easier to do it manually That's a different issue I also think could use help. A standardized (as in freedesktop.org type standard) way of storing multimedia library information - probably in xml - that includes location on filesystem, playcount, rating, other data (that may or may not be in the file metadata) Then common sync tools could be written to the standard for different types of players that would "just work" with whatever app you use to play your music, so long as your jukebox app used the standard. but that's another issue all together, and not a fedora issue. From jspaleta at gmail.com Mon Jan 10 23:45:04 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 10 Jan 2005 18:45:04 -0500 Subject: HAL policies for port. music players In-Reply-To: References: <1105279990l.30286l.0l@devel.mpeters.us> <1105311052.5141.149.camel@localhost.localdomain> <1105316099l.4843l.7l@devel.mpeters.us> Message-ID: <604aa791050110154528132ad2@mail.gmail.com> On Mon, 10 Jan 2005 12:52:24 +0000, Mike Hearn wrote: > > OK so that doesn't give you the best experience as right now Nautilus > insists on putting a trash can on the player The trashcan on removable volume has come up before. But if you look at David's list technical items, maybe there is room in the per-device properties concept to include the ability to disable the trash can for specific devices. So not only can you decide per-device if you want a certain application to launch when you insert it, but you can also set whether or not the device gets a trash can as part of an extended per-device set of properties. -jef From jaboutboul at speakeasy.net Mon Jan 10 23:58:59 2005 From: jaboutboul at speakeasy.net (Jack Aboutboul) Date: Mon, 10 Jan 2005 18:58:59 -0500 Subject: [Possibly OT] Trademarks In-Reply-To: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> Message-ID: <1105401540.20722.108.camel@deepfort> On Mon, 2005-01-10 at 14:50 -0500, Paul Iadonisi wrote: > For the Mozilla case, based on some of the excerpts I've read, they're > expectation is unreasonable: they want people to know they are using > Firefox and Thunderbird (by name), but they want to control what types > of changes are made to the software. To me, that's end-run around the > FOSS licenses which they have chosen. This is almost exactly like the qmail situation. DJB wants you to know and use qmail, but you can't legally distribute any binaries or code thats been modified with his expressed approval. I assume that if these projects keep asserting their trademarks like this, they will face much resistance and backlash from the community and people will just start using some alternative. Jack -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tsilims at gmail.com Tue Jan 11 00:25:25 2005 From: tsilims at gmail.com (m g) Date: Mon, 10 Jan 2005 18:25:25 -0600 Subject: [Possibly OT] Trademarks In-Reply-To: <1105401540.20722.108.camel@deepfort> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <1105401540.20722.108.camel@deepfort> Message-ID: What exactly is modified about the Redhat/FF RPMs? I've been running the standard Moz Foundation FF on Fedora since day 1, and never had any issues. I can see wanting to change the start page, bookmarks, etc., but that (according to a post upthread) is ok for the standard "Official Firefox" level. -- MG From jspaleta at gmail.com Tue Jan 11 00:44:47 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 10 Jan 2005 19:44:47 -0500 Subject: [Possibly OT] Trademarks In-Reply-To: <1105401540.20722.108.camel@deepfort> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <1105401540.20722.108.camel@deepfort> Message-ID: <604aa7910501101644285efc21@mail.gmail.com> On Mon, 10 Jan 2005 18:58:59 -0500, Jack Aboutboul wrote: > This is almost exactly like the qmail situation. No there's a huge difference... you can't even rebrand qmail and distributed modified versions. Mozilla is saying something else, they are saying 'you are free to modify this.. but if you do.. remove the trademark protected material when you modify' Qmail's restrictions prevent you from distributing any modifications. Mozilla's policy forces you to make certain modifications if you modify without approval. Its apples and oranges. Trademarks and copyright are very different things handled in the legal system in very different ways. You have to be much more diligent in proactively protecting a trademark in the US than you do about protecting copyrights. Qmail's restrictions are completely and utterly circumscribed by copyright. Mozilla's restrictions try to limit themselves to aspects of trademark law without unduly burdening the distribution and modification rights to the un-trademarked codebase. I don't think i've seen a reasonably informed legal opinion which says compelling someone to remove trademarked content when modifying any software under an OSI approved copyright license, breaks the copyright license conditions. Whether or not mozilla's approach to protecting trademarks associated with an open source project is the best model remains to be seen. However, I don't think its wise to write-off trademarks and branding completely as something open source projects cannot make use of as a means of legal protection against people who would try to take advantage of the projects efforts. -jef From caillon at redhat.com Tue Jan 11 00:52:40 2005 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 10 Jan 2005 19:52:40 -0500 Subject: [Possibly OT] Trademarks In-Reply-To: <604aa7910501101644285efc21@mail.gmail.com> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <1105401540.20722.108.camel@deepfort> <604aa7910501101644285efc21@mail.gmail.com> Message-ID: <41E32358.2040004@redhat.com> Jeff Spaleta wrote: > On Mon, 10 Jan 2005 18:58:59 -0500, Jack Aboutboul > wrote: > >> This is almost exactly like the qmail situation. > > > Mozilla is saying something else, they > are saying 'you are free to modify this.. but if you do.. remove the > trademark protected material when you modify' Its more like: you are free to modify this. But if you don't, then you are free to add our trademark protected material *which is not added by default.* From jspaleta at gmail.com Tue Jan 11 01:00:08 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 10 Jan 2005 20:00:08 -0500 Subject: [Possibly OT] Trademarks In-Reply-To: <41E32358.2040004@redhat.com> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <1105401540.20722.108.camel@deepfort> <604aa7910501101644285efc21@mail.gmail.com> <41E32358.2040004@redhat.com> Message-ID: <604aa791050110170073ff4cf6@mail.gmail.com> On Mon, 10 Jan 2005 19:52:40 -0500, Christopher Aillon wrote: > Its more like: you are free to modify this. But if you don't, then you > are free to add our trademark protected material *which is not added by > default.* indeed. -jef"so more like apples versus twinkies then"spaleta From jwboyer at jdub.homelinux.org Tue Jan 11 01:05:14 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 10 Jan 2005 19:05:14 -0600 Subject: CVS kernel compiles Message-ID: <1105405514.16242.15.camel@jdub.homelinux.org> OK, I finally got a RedHat developer to step outside the RedHat bubble and try to do a 'make sources' from a fresh CVS checkout. Amazingly enough, he got the exact same error that I did. Will wonders never cease :p. All sarcasm aside, Paul Nasrat said he poked some of the RH developers about the 'download' target in the kernel/devel/ Makefile so hopefully that will be cleared up soon (hint, hint). Thank you, Paul. Also, I manually removed the 'download' target from the TARGETS list in that Makefile and did a 'make i686'. After compiling all day I finally am the proud owner of 4 RPMs. I've yet to install them, but at least the build system seems to work. Even if it needs a little persuasion. Now I understand what DaveJ means whenever he talks about the build system :). josh From michael.favia at insitesinc.com Tue Jan 11 01:08:54 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Mon, 10 Jan 2005 19:08:54 -0600 Subject: HAL policies for port. music players In-Reply-To: <604aa791050110154528132ad2@mail.gmail.com> References: <1105279990l.30286l.0l@devel.mpeters.us> <1105311052.5141.149.camel@localhost.localdomain> <1105316099l.4843l.7l@devel.mpeters.us> <604aa791050110154528132ad2@mail.gmail.com> Message-ID: <41E32726.2030901@insitesinc.com> Jeff Spaleta wrote: >On Mon, 10 Jan 2005 12:52:24 +0000, Mike Hearn wrote: > > >>OK so that doesn't give you the best experience as right now Nautilus >>insists on putting a trash can on the player >> >> > >The trashcan on removable volume has come up before. But if you look >at David's list technical items, maybe there is room in the per-device >properties concept to include the ability to disable the trash can for >specific devices. So not only can you decide per-device if you want a >certain application to launch when you insert it, but you can also set >whether or not the device gets a trash can as part of an extended >per-device set of properties. > >-jef > > > In fact i just brought this up over at nautilus because i had a problem with not being able to "delete" a file in the GUI without configuring the filemanager (it is a file manager after all). I understand and value the concept of a "trash can/recycle bin" and i even think that the default behavior is correct (send to trash on delete key) but i think that you should be able to circumvent the trash (via shift+del or even Edit > Delete) without resorting to configuring the application. I do think that the perdevice configuration is valuable but a good set of default capabilities goes a long way and is much less user work intensive. -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com From michael.favia at insitesinc.com Tue Jan 11 01:19:06 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Mon, 10 Jan 2005 19:19:06 -0600 Subject: HAL policies for port. music players In-Reply-To: <1105396177.30862.11.camel@localhost.localdomain> References: <1105279990l.30286l.0l@devel.mpeters.us> <1105311052.5141.149.camel@localhost.localdomain> <1105316099l.4843l.7l@devel.mpeters.us> <41E23583.6070606@insitesinc.com> <1105377009.2693.3.camel@localhost.localdomain> <41E2BDAD.2010501@insitesinc.com> <604aa79105011010117b7f415d@mail.gmail.com> <1105396177.30862.11.camel@localhost.localdomain> Message-ID: <41E3298A.5010605@insitesinc.com> Kyrre Ness Sjobak wrote: >man, 10.01.2005 kl. 19.11 skrev Jeff Spaleta: > > >>On Mon, 10 Jan 2005 11:38:53 -0600, Michael Favia >> wrote: >> >> >>>Which is understandable and possible after the first time you tell it >>>what to do. I think that asking the user the first time which >>>application to use and possibly mounting parameters is an acceptable >>>inconvienence. >>> >>> >>I think you are somewhat on the same page as David Zeuthen with >>regard to what direction should be taken to make hotpluggable devices >>more integrated in the desktop. Whether or not the new system prompts >>for interaction by default or just notifies is a UI detail that could >>be argued about later... number 4 on David's list. The real trick is >>bulding up the per-device configuration for each user and teaching the >>desktop ui how to access those per device properties. I think David >>did a good job prioritizing the technical issues in his list. >> >>-jef >> >> > >... And i don't want to be pestered by users demanding me to type the >root pasword every time they want to use their usb memory plug. When it >comes to those devices, it should be just plug'n'play. No fuss. Like it >is now. > > Im not suggesting anything like this (unless you configure it that way of course). >Of cource, you could create a lot of fuzz, and having some ability to >tell the computer "don't allow anyone but user XYZ to mount memory plug >named foo". So what? Take the plug and stick it into another box, linux, >mac, or windows... > >If you want such kind of security... encryption. > >Not that i would oppose some nice GUI where you could log on as root and >define some special stuff (as the rest of fstab etc) - but not default? >It's a big enough pest to have to configure the DNS and install my >install-the-rest-of-the-software-from-server script on every machine... > > I am talking about refining the users experience here. Setting system security policies could also be done through such an interface (when accessed by the appropriwate user) and perhaps it belongs there but my focus was on improving the process a user goes through when inserting a new device (cd, mp3 player, usb drive, printer) by unifying the interaction model and presenting them with an opportunity but not forcing them to configure the device (both for this insert and optionally future ones of a particular device or device type). > >Next question... > > grr. -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com From michael.favia at insitesinc.com Tue Jan 11 01:30:03 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Mon, 10 Jan 2005 19:30:03 -0600 Subject: ssh X forwarding change in FC3 In-Reply-To: <1105392124.2195.57.camel@localhost.localdomain> References: <41DD79BB.30304@draigBrady.com> <1105123735.4464.5.camel@localhost.localdomain> <1105378285.2693.7.camel@localhost.localdomain> <1105391980.2195.56.camel@localhost.localdomain> <1105392124.2195.57.camel@localhost.localdomain> Message-ID: <41E32C1B.406@insitesinc.com> Havoc Pennington wrote: >On Mon, 2005-01-10 at 16:19 -0500, Havoc Pennington wrote: > > >>On Mon, 2005-01-10 at 18:31 +0100, Kyrre Ness Sjobak wrote: >> >> >>>Hmm? i haven't seen any problems with it, and i have used SSH (with X) >>>from anything from a mac to fc3 and fc2 computers, to fc3 and fc2 >>>computers. Never any problem. Only thing worth mention is that the mac >>>and fc2 didn't understand the -Y flag, it just said it wasn't a real >>>flag. So we stuck to X, and everything worked. From fc3 we also needed >>>-Y, and then copy/paste would work. No problem whatsoever. >>> >>> >>> >>-X of course is going to work. If -Y works for you I'm surprised. Are >>you saying you pass both -X and -Y? Maybe that disables trusted mode. >>Copy and paste should not work from a trusted app to untrusted because >>the untrusted app would need to read data from a trusted window. >> >> >> > >Doh, -Y enables trusted X so all the windows are trusted. The default >(have untrusted windows) is the thing that doesn't work. > >Havoc > > All these Xs and Ys are confusing me too not to mention giving me nightmarish flashbacks of college genomic study when i sleep. -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com From lists at donut.dk Tue Jan 11 02:29:24 2005 From: lists at donut.dk (Cream[DONut]) Date: Tue, 11 Jan 2005 03:29:24 +0100 Subject: [Possibly OT] Trademarks In-Reply-To: <1105397621.2195.97.camel@localhost.localdomain> References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <41E2EA84.4000504@redhat.com> <604aa79105011013218116e70@mail.gmail.com> <41E2F675.6050001@redhat.com> <604aa791050110141025f30abb@mail.gmail.com> <1105397621.2195.97.camel@localhost.localdomain> Message-ID: <41E33A04.7050703@donut.dk> Havoc Pennington wrote: >Changing the configure arguments in the packages and doing an >Obsoletes/Provides firefox wouldn't take very long, if we need to do it >someday. So there's no point stressing about hypotheticals. There's >value to calling it Firefox for now (if only to avoid user confusion) >and if we have to change it someday, it will cause some problems but >they'll be the same problems if we change it today. > It does indeed have value, for novice novice pc users like my mom, the programs and icons on her desktop are the same at home (on FC3), as the programs and icons at her work (WinXP). The programs are called the same and works the same way (Open Office, Thunderbird & Firefox). Having the same programs with different names & icons would only add confusion. Changing the names & icons at a "later" stage, would ofcouse add confusion, but it might be easier to explain that its "just a namechange" when she have adopted to using it. Kris "wants a cool sig like Mr. Spaleta". From mpeters at mac.com Tue Jan 11 06:09:15 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 11 Jan 2005 06:09:15 +0000 Subject: [Possibly OT] Trademarks In-Reply-To: <604aa791050110141025f30abb@mail.gmail.com> (from jspaleta@gmail.com on Mon Jan 10 14:10:03 2005) References: <1105386603.21221.22.camel@va.local.linuxlobbyist.org> <41E2EA84.4000504@redhat.com> <604aa79105011013218116e70@mail.gmail.com> <41E2F675.6050001@redhat.com> <604aa791050110141025f30abb@mail.gmail.com> Message-ID: <1105423755l.5018l.3l@devel.mpeters.us> On 01/10/2005 02:10:03 PM, Jeff Spaleta wrote: > On Mon, 10 Jan 2005 16:41:09 -0500, Christopher Aillon > wrote: > > > We want to stay as close to upstream as possible > > Thats great... but you can do that using the iceweasel option. But > when there is a disagreement over a patch and there will be at some > point.... using the non-ioeweasel options will prevent Fedora Core > developers from being able to apply the patch without upstream > approval. This a maintence burden... and it will happen at some > point. If it happens and is not resolvable between the two parties, there are ways within rpm to depricate a package and move on. From buildsys at redhat.com Tue Jan 11 13:29:43 2005 From: buildsys at redhat.com (Build System) Date: Tue, 11 Jan 2005 08:29:43 -0500 Subject: rawhide report: 20050111 changes Message-ID: <200501111329.j0BDThH28850@porkchop.devel.redhat.com> New package cpuspeed CPU Frequency adjusting daemon. New package dmidecode Tool to analyse BIOS DMI data. New package enchant An Enchanting Spell Checking Library New package hardlink Create a tree of hardlinks. New package irqbalance IRQ balancing daemon. New package longrun Utility to change processor speed on Transmeta CPUs. New package microcode_ctl Tool to update x86/x86-64 CPU microcode. New package readahead Read a preset list of files into memory. New package rng-utils Random number generator related utilities New package salinfo SAL info tool. New package smartmontools Tools for monitoring SMART capable hard disks. New package x86info x86 processor information tool. Removed package kernel-utils Updated Packages: alsa-lib-1.0.7-3.devel ---------------------- * Mon Jan 10 2005 Martin Stransky 1.0.7-3.devel - fix #144518 - stack protection control dhcpv6-0.10-10 -------------- * Mon Jan 10 2005 Jason Vas Dias - 0.10-10 - Fix bug 144585: dhcp6c wasn't writing radvd.conf in prefix delegation mode * Sun Jan 09 2005 Jason Vas Dias - 0.10-10 - Add Relay Agent support. Thanks to Brian Bluesker - for the patch to add relay support to the server and for submitting the - patch originally contributed by Cristian Cadar of NEC Europe to - DHCPv6-developer mailing list. * Fri Jan 07 2005 Jason Vas Dias - 0.10-9 - fix bug 143728: SEGV core on resolv.conf + radvd.conf update - - yywrap()'s must return 1 glade2-2.6.8-1 -------------- * Mon Jan 10 2005 Matthias Clasen - 2.6.8-1 - Update to 2.6.8 glib2-2.6.1-1 ------------- * Mon Jan 10 2005 Matthias Clasen - 2.6.1-1 - Upgrade to 2.6.1 gpdf-2.8.2-1.3 -------------- * Mon Jan 10 2005 Marco Pesenti Gritti 2.8.2-1.3 - Update to 2.8.2 - Remove patches, they are upstream gphoto2-2.1.5-2 --------------- * Mon Jan 10 2005 Tim Waugh 2.1.5-2 - 2.1.5 (bug #143141). gstreamer-0.8.8-2 ----------------- * Mon Jan 10 2005 Colin Walters 0.8.8-2 - Updated gstreamer-0.8.8-lib64.patch which does not rename tools such as gst-launch to e.g. gst-launch-i686. * Mon Jan 03 2005 Colin Walters 0.8.8-1 - Update to 0.8.8 - Remove upstreamed escape-uris patch - Readd redirection of register output to /dev/null * Tue Nov 09 2004 Colin Walters 0.8.7-6 - Add initial lib64 patch. gtk2-2.6.1-1 ------------ * Mon Jan 10 2005 Matthias Clasen - 2.6.1-1 - Upgrade to 2.6.1 - Drop no longer needed fixes java-1.4.2-gcj-compat-0:1.4.2.0-33jpp ------------------------------------- * Mon Jan 10 2005 Thomas Fitzsimmons - 0:1.4.2.0-33jpp - Bump release number for FC4. * Mon Jan 10 2005 Thomas Fitzsimmons - 0:1.4.2.0-32jpp - Add symbolic JRE Provides. * Fri Jan 07 2005 Thomas Fitzsimmons - 0:1.4.2.0-31jpp - Bump release number. jpilot-0.99.7-4 --------------- * Mon Jan 10 2005 Ivana Varekova - fix part of bug #142520 - problem with Go to Today kernel-2.6.10-1.1076_FC4 ------------------------ * Mon Jan 10 2005 Dave Jones - Update to -bk13, reinstate GFP_ZERO patch which hopefully is now fixed. net-tools-1.60-43 ----------------- * Mon Jan 10 2005 Radek Vokal 1.60-43 - don't report statistics for virtual devices (#143981) - fixing translation headers - content type format - kill bitkeeper warning messages policycoreutils-1.20.1-2 ------------------------ * Mon Jan 10 2005 Dan Walsh 1.20.1-2 - Fix restorecon segfault rpmdb-fedora-1:4-0.20050111 --------------------------- selinux-policy-strict-1.20.1-1 ------------------------------ * Fri Jan 07 2005 Dan Walsh 1.20.1-1 - Start using typeattribute - Implement allow_samba_home_dirs selinux-policy-targeted-1.20.1-1 -------------------------------- * Fri Jan 07 2005 Dan Walsh 1.20.1-1 - Start using typeattribute - Implement allow_samba_home_dirs subversion-1.1.2-3 ------------------ * Mon Jan 10 2005 Joe Orton 1.1.2-3 - update to 1.1.2 - disable swig bindings due to incompatible swig version * Wed Nov 24 2004 Joe Orton 1.1.1-5 - update subversion.conf examples to be SELinux-friendly talk-0.17-27 ------------ * Thu Jul 29 2004 Jindrich Novy 0.17-27 - patch to handle input in UTF-8 from Miloslav Trmac (#143818) xen-2-20050108 -------------- * Sun Jan 09 2005 Rik van Riel - grab newer snapshot, that does start up - add /var/xen/xend-db/{domain,vnet} to %files section xinetd-2:2.3.13-5 ----------------- * Sat Jan 08 2005 Jay Fenlason 2:2.3.13-4 - Added patch committed to upstream CVS to fix bz#140084 (error logging accidentally using one of [012] as the syslog descriptor) * Fri Jun 18 2004 Jay Fenlason 2:2.3.13-3 - Add patch to fix #126242: banner's don't work * Thu Jun 17 2004 Jay Fenlason - Remove the configuration for the no-longer-present "services" service. Closes #126169 From twaugh at redhat.com Tue Jan 11 15:10:23 2005 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 11 Jan 2005 15:10:23 +0000 Subject: Upgrading readline In-Reply-To: <200412090233.19617.symbiont@berlios.de> References: <20041208175651.GL5322@redhat.com> <20041208181407.GA5978@nostromo.devel.redhat.com> <200412090233.19617.symbiont@berlios.de> Message-ID: <20050111151023.GP5322@redhat.com> On Thu, Dec 09, 2004 at 02:33:19AM +0800, Jeff Pitman wrote: > On Thursday 09 December 2004 02:14, Bill Nottingham wrote: > > > For upgrading readline to a new major release (in Fedora > > > development), do I need to provide a readline4 package, or is it > > > sufficient to just rebuild the packages that depend on it? > > > > A compat library may be nice, considering the number of apps that > > link against it. > > Check ABI compat within pkg first. Eg, you can link python 1.5 against > db4 cuz db4 has db1-ish stuff still. Reduction of compat madness is > optimal. No, the soname has definitely changed incompatibly. I'll have a go at making a readline43 package. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From peter.backlund at home.se Tue Jan 11 15:16:51 2005 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 11 Jan 2005 16:16:51 +0100 Subject: Package suggestion: mysql tools Message-ID: <1105456611.4207.15.camel@localhost.localdomain> Hi. Since mysql in rawhide is now 4.1, I'd like to see the inclusion of the mysql administrator (http://www.mysql.com/products/administrator/) and the mysql query browser (http://www.mysql.com/products/query-browser/). They are both written in GTK2 and are available under the same dual- licensing terms as mysql itself, AFAICS. The download page is here: http://dev.mysql.com/downloads/ Regards, Peter Backlund From d.lesca at solinos.it Tue Jan 11 15:20:15 2005 From: d.lesca at solinos.it (Dario Lesca) Date: Tue, 11 Jan 2005 16:20:15 +0100 Subject: libtiff and hylafax fix Message-ID: <1105456814.2630.19.camel@lesca.home.solinos.it> Hi! Little question: Is this fix: - http://bugs.hylafax.org/bugzilla/show_bug.cgi?id=500 contained into libtiff-3.6.1-9.fc3.i386.rpm package? Many thanks -- Dario Lesca From enrico.scholz at informatik.tu-chemnitz.de Tue Jan 11 15:51:27 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 11 Jan 2005 16:51:27 +0100 Subject: rawhide report: 20050111 changes In-Reply-To: <200501111329.j0BDThH28850@porkchop.devel.redhat.com> (Build System's message of "Tue, 11 Jan 2005 08:29:43 -0500") References: <200501111329.j0BDThH28850@porkchop.devel.redhat.com> Message-ID: <8765240xs0.fsf@kosh.ultra.csn.tu-chemnitz.de> buildsys at redhat.com (Build System) writes: > New package enchant > An Enchanting Spell Checking Library apropos spell checker... can we expect an upgrade to aspell 0.60 which is available since August 2004? Enrico From lux at diesel-research.com Tue Jan 11 16:17:06 2005 From: lux at diesel-research.com (Kim Lux) Date: Tue, 11 Jan 2005 09:17:06 -0700 Subject: 2.6.10-1.737 smp kernel crashes. Message-ID: <1105460226.6007.5.camel@localhost.localdomain> I'm not sure if this is the right list, but I'll post here anyway as it is not a user or config issue associated with FC3 operation and 2.6.10 kernels are kind of FC4 stuff ? Anyway... the 2.6.10-1.737 smp kernel is NOT stable on my laptop. It does a hard kernel crash (ie total machine lockup, cannot start a new session). This has happened 3x when websurfing with Konqueror. It seems to occur when performing socket communications ie immediately after double clicking a link, but that is just a quick observation. I've run 2.6.10-1.727 since it became available on the same machine without any issues. I've reverted back to it. Hope this helps. -- Kim Lux, Diesel Research Inc. From shiva at sewingwitch.com Tue Jan 11 16:35:15 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Tue, 11 Jan 2005 08:35:15 -0800 Subject: Package suggestion: mysql tools In-Reply-To: <1105456611.4207.15.camel@localhost.localdomain> References: <1105456611.4207.15.camel@localhost.localdomain> Message-ID: --On Tuesday, January 11, 2005 4:16 PM +0100 Peter Backlund wrote: > Since mysql in rawhide is now 4.1, I'd like to see the inclusion of the > mysql administrator (http://www.mysql.com/products/administrator/) and > the mysql query browser (http://www.mysql.com/products/query-browser/). > > They are both written in GTK2 and are available under the same dual- > licensing terms as mysql itself, AFAICS. The download page is here: > http://dev.mysql.com/downloads/ How do these compare to phpMyAdmin (http://www.phpMyAdmin.net/), which I think most MySQL users are familiar with? (For those who haven't looked recently, phpMyAdmin is now to version 2.6.1-rc2, and works quite nicely with mysql-4.1 from Rawhide. Just unpack the tarball to your web document root and edit config.inc.php.) From P at draigBrady.com Tue Jan 11 17:29:51 2005 From: P at draigBrady.com (P at draigBrady.com) Date: Tue, 11 Jan 2005 17:29:51 +0000 Subject: rawhide report: 20050111 changes In-Reply-To: <200501111329.j0BDThH28850@porkchop.devel.redhat.com> References: <200501111329.j0BDThH28850@porkchop.devel.redhat.com> Message-ID: <41E40D0F.1080901@draigBrady.com> Build System wrote: > New package hardlink > Create a tree of hardlinks. That's a bad description. I was wondering initially, how this was different than `cp -al`. It in fact merges duplicate files in a tree using hardlinks. It's a nice util, but I've a few questions. 1. Does it really need it's own package? Couldn't you try to get it included in util-linux or some place like that? 2. No man page? At least explain what the options do in usage()! 3. version 1.2 is in extras for ages but 1.0 is at following url? http://download.fedora.redhat.com/pub/fedora/linux/core/development/SRPMS/ 4. you assume a block size of 4KiB for calculating saved space? 5. It's significantly slower than the findup component of fslint (which is also in extras). See below: Note, findup has a -m option formerging with hardlinks also. Also note the test data was 2 x 2.4.20 kernel trees [pbrady at pixelbeat fslint]$ time ./findup ~/kernels/ >/dev/null real 0m48.719s user 0m14.070s sys 0m13.990s [pbrady at pixelbeat fslint]$ time ./findup ~/kernels/ >/dev/null real 0m43.601s user 0m13.790s sys 0m14.660s [pbrady at pixelbeat fslint]$ time ./findup ~/kernels/ >/dev/null real 0m52.549s user 0m13.540s sys 0m15.270s ----------------------------------------------- $ time ~/hardlink -cnv ~/kernels/ 2>/dev/null real 1m6.230s user 0m0.270s sys 0m1.910s [pbrady at pixelbeat fslint]$ time ~/hardlink -cnv ~/kernels/ 2>/dev/null real 1m27.496s user 0m0.350s sys 0m2.320s [pbrady at pixelbeat fslint]$ time ~/hardlink -cnv ~/kernels/ 2>/dev/null real 1m5.037s user 0m0.350s sys 0m2.480s -- P?draig Brady - http://www.pixelbeat.org -- From iago.rubio at hispalinux.es Tue Jan 11 17:44:41 2005 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Tue, 11 Jan 2005 18:44:41 +0100 Subject: Package suggestion: mysql tools In-Reply-To: References: <1105456611.4207.15.camel@localhost.localdomain> Message-ID: <1105465480.14091.191.camel@speedy.iagorubio.net> On Tue, 2005-01-11 at 17:35, Kenneth Porter wrote: > --On Tuesday, January 11, 2005 4:16 PM +0100 Peter Backlund > wrote: > > > Since mysql in rawhide is now 4.1, I'd like to see the inclusion of the > > mysql administrator (http://www.mysql.com/products/administrator/) and > > the mysql query browser (http://www.mysql.com/products/query-browser/). > > > > They are both written in GTK2 and are available under the same dual- > > licensing terms as mysql itself, AFAICS. The download page is here: > > http://dev.mysql.com/downloads/ > > How do these compare to phpMyAdmin (http://www.phpMyAdmin.net/), which I > think most MySQL users are familiar with? They do not require a web server installed and running. Regards. -- Iago Rubio From cmadams at hiwaay.net Tue Jan 11 18:25:02 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 11 Jan 2005 12:25:02 -0600 Subject: rawhide report: 20050111 changes In-Reply-To: <41E40D0F.1080901@draigBrady.com> References: <200501111329.j0BDThH28850@porkchop.devel.redhat.com> <41E40D0F.1080901@draigBrady.com> Message-ID: <20050111182502.GE956965@hiwaay.net> Once upon a time, P at draigBrady.com

said: > 1. Does it really need it's own package? > Couldn't you try to get it included in util-linux > or some place like that? It was part of the split of the old kernel-utils. Glomming things together to reduce package count is a bad idea. If it doesn't come with util-linux (and why should hardlink be a part of util-linux; it isn't a Linux specific utility), it shouldn't be in the util-linux RPM. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From notting at redhat.com Tue Jan 11 19:06:00 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 11 Jan 2005 14:06:00 -0500 Subject: rawhide report: 20050111 changes In-Reply-To: <20050111182502.GE956965@hiwaay.net> References: <200501111329.j0BDThH28850@porkchop.devel.redhat.com> <41E40D0F.1080901@draigBrady.com> <20050111182502.GE956965@hiwaay.net> Message-ID: <20050111190600.GB31634@nostromo.devel.redhat.com> Chris Adams (cmadams at hiwaay.net) said: > Once upon a time, P at draigBrady.com

said: > > 1. Does it really need it's own package? > > Couldn't you try to get it included in util-linux > > or some place like that? > > It was part of the split of the old kernel-utils. Glomming things > together to reduce package count is a bad idea. If it doesn't come with > util-linux (and why should hardlink be a part of util-linux; it isn't a > Linux specific utility), it shouldn't be in the util-linux RPM. However, it doesn't mean that trying to get it in upstream util-linux or coreutils isn't a bad idea. Bill From joelonlinux at optonline.net Tue Jan 11 20:33:28 2005 From: joelonlinux at optonline.net (Joel Rittvo) Date: Tue, 11 Jan 2005 15:33:28 -0500 Subject: rawhide report: 20050111 changes In-Reply-To: <200501111329.j0BDThH28850@porkchop.devel.redhat.com> References: <200501111329.j0BDThH28850@porkchop.devel.redhat.com> Message-ID: <41E43818.9090709@optonline.net> Build System wrote: > New package cpuspeed > CPU Frequency adjusting daemon. > > New package dmidecode > Tool to analyse BIOS DMI data. ........ > New package smartmontools > Tools for monitoring SMART capable hard disks. > > New package x86info > x86 processor information tool. > > > Removed package kernel-utils Installing some of these new packages requires removal of kernel-utils. I can't remove kernel-utils because lm_sensors depends on it, and kdebase and net-snmp depend on lm-sensors. [root at LINUX]# rpm -Uvh microcode_ctl-1.11-1.6.i386.rpm error: Failed dependencies: kernel-utils is needed by (installed) lm_sensors-2.8.8-2.i386 [root at LINUX]# rpm -e lm_sensors error: Failed dependencies: libsensors.so.3 is needed by (installed) kdebase-3.3.2-0.2.i386 libsensors.so.3 is needed by (installed) net-snmp-5.2-2.i386 -- Joel Rittvo From davej at redhat.com Tue Jan 11 20:51:08 2005 From: davej at redhat.com (Dave Jones) Date: Tue, 11 Jan 2005 15:51:08 -0500 Subject: rawhide report: 20050111 changes In-Reply-To: <41E43818.9090709@optonline.net> References: <200501111329.j0BDThH28850@porkchop.devel.redhat.com> <41E43818.9090709@optonline.net> Message-ID: <20050111205108.GN29712@redhat.com> On Tue, Jan 11, 2005 at 03:33:28PM -0500, Joel Rittvo wrote: > >Removed package kernel-utils > > Installing some of these new packages requires removal of kernel-utils. > I can't remove kernel-utils because lm_sensors depends on it, and > kdebase and net-snmp depend on lm-sensors. > > [root at LINUX]# rpm -Uvh microcode_ctl-1.11-1.6.i386.rpm > error: Failed dependencies: > kernel-utils is needed by (installed) lm_sensors-2.8.8-2.i386 My guess is it wants it for dmidecode, so its dependancies need updating. Dave From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Jan 11 21:15:58 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 11 Jan 2005 22:15:58 +0100 Subject: 2.6.10-1.737 smp kernel crashes. In-Reply-To: <1105460226.6007.5.camel@localhost.localdomain> References: <1105460226.6007.5.camel@localhost.localdomain> Message-ID: <20050111221558.0ec6d94b@python2> Kim Lux wrote : > Anyway... the 2.6.10-1.737 smp kernel is NOT stable on my laptop. SMP kernel on a laptop? I'm not sure I get the point :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.9-1.724_FC3.radeon Load : 0.01 0.20 0.18 From notting at redhat.com Tue Jan 11 21:21:15 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 11 Jan 2005 16:21:15 -0500 Subject: 2.6.10-1.737 smp kernel crashes. In-Reply-To: <20050111221558.0ec6d94b@python2> References: <1105460226.6007.5.camel@localhost.localdomain> <20050111221558.0ec6d94b@python2> Message-ID: <20050111212115.GB1393@nostromo.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > Anyway... the 2.6.10-1.737 smp kernel is NOT stable on my laptop. > > SMP kernel on a laptop? I'm not sure I get the point :-) Laptop with non-mobile P4 with HT? Bill From cs at zip.com.au Tue Jan 11 22:29:03 2005 From: cs at zip.com.au (cs at zip.com.au) Date: Wed, 12 Jan 2005 09:29:03 +1100 Subject: Reopen a request for gpgme in Core In-Reply-To: <1105185875.6500.33.camel@localhost.localdomain> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106072425.437a2395.fedora@wir-sind-cool.org> <1105053961.5547.83.camel@baythorne.infradead.org> <20050107043149.7fe1feba.fedora@wir-sind-cool.org> <1105095553.5547.105.camel@baythorne.infradead.org> <20050108042746.GC18246@cskk.homeip.net> <1105185875.6500.33.camel@localhost.localdomain> Message-ID: <20050111222903.GB21397@cskk.homeip.net> On 12:04 08 Jan 2005, David Woodhouse wrote: | On Sat, 2005-01-08 at 15:27 +1100, Cameron Simpson wrote: | > in this way _no_ mail reader needs extending because each remote service is | > apparently a local ordinary service. [...] | > I find it extremely convenient. | | It's a cute hack, but it doesn't seem to be as convenient as the way | that Evolution, pine and mutt do it for me transparently. Especially as | the mail servers I use tend not to have an IMAP d??mon listening at all, | and as it still doesn't perform the authentication for you in the way | that using SSH directly does -- your IMAP client would still need to | store a password. Sure, or get me to type it, but on the other hand the place I most do IMAP to doesn't give file-level access to the mail spool files. So I can't "ssh in and run an IMAP _daemon_", so a real IMAP connection is still required, so a password is _still_ required because ssh will only get you as far as the shell server. I don't just do IMAP this way. I do pop this way too, and point fetchmail at "zip.local" for that, too. And IRC. And you can generally get at any service this way. If you're routinely inside a firewall that doesn't allow much out but does allow ssh, you're in business and your tools don't need to know anything special. -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ And besides, we've already discussed the proper way to pick up a bike, at great length. You start by buying it a drink. - Joe McConnell From jwz at jwz.org Tue Jan 11 23:12:34 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Tue, 11 Jan 2005 15:12:34 -0800 Subject: bttv update? Message-ID: <41E45D62.323A974B@jwz.org> Any chance of getting a newer version of the bttv driver into the FC3 kernel updates? I had to patch it to make it stop growing slab-256 without bounds. (It leaks so much that if you grab a single frame every few seconds, slab-256 will be > 800M within three days.) This patch fixes the version of bttv that comes with 2.6.9-1.681_FC3; the latest bttv source is slightly different but has a similar fix. --- ./drivers/media/video/bttv-driver.c.orig 2005-01-11 14:54:15.477911088 -0800 +++ ./drivers/media/video/bttv-driver.c 2005-01-08 13:49:44.000000000 -0800 @@ -2992,6 +2992,9 @@ free_btres(btv,fh,RESOURCE_VBI); } + videobuf_mmap_free(file, &fh->cap); + videobuf_mmap_free(file, &fh->vbi); + #ifdef VIDIOC_G_PRIORITY v4l2_prio_close(&btv->prio,&fh->prio); #endif --- ./drivers/media/video/video-buf.c.orig 2004-10-18 14:54:08.000000000 -0700 +++ ./drivers/media/video/video-buf.c 2005-01-08 13:50:04.000000000 -0800 @@ -889,6 +889,7 @@ int i; videobuf_queue_cancel(file,q); + videobuf_mmap_free(file, q); INIT_LIST_HEAD(&q->stream); for (i = 0; i < VIDEO_MAX_FRAME; i++) { if (NULL == q->bufs[i]) -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From alan at redhat.com Tue Jan 11 23:32:56 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 11 Jan 2005 18:32:56 -0500 Subject: bttv update? In-Reply-To: <41E45D62.323A974B@jwz.org> References: <41E45D62.323A974B@jwz.org> Message-ID: <20050111233256.GG12019@devserv.devel.redhat.com> On Tue, Jan 11, 2005 at 03:12:34PM -0800, Jamie Zawinski wrote: > Any chance of getting a newer version of the bttv driver into the > FC3 kernel updates? I had to patch it to make it stop growing > slab-256 without bounds. (It leaks so much that if you grab a single > frame every few seconds, slab-256 will be > 800M within three days.) Thanks for the diff I'll look into that for -ac merging as well From zaitcev at redhat.com Wed Jan 12 01:29:12 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Tue, 11 Jan 2005 17:29:12 -0800 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: References: <20050108141551.47d3180f@lembas.zaitcev.lan> Message-ID: <20050111172912.2cadb83e@lembas> On Sat, 08 Jan 2005 14:56:22 -0800, Jamie Zawinski wrote: > Pete Zaitcev wrote: > > > > I use SDDR-31 successfuly since 2001, it's a great device with > > [almost] no serious firmware problems which plague this kind of > > peripherals. > > As I can't use the SDDR-31 either, it would be a dramatic improvement if > I could get that working. But I'd most like to find a USB-2 reader that > works, because the files my camera writes are huge... Guess what, I have received a new USB key today, and it shows the problem right off the bat. But what's more, my old and trusty SDDR-31 now misbehaved, too (only one time though)! Here's an unedited dmesg: <----- plugging new 1GB stick usb 1-3: new high speed USB device using ehci_hcd and address 3 usb 3-1: new full speed USB device using uhci_hcd and address 2 usb 3-1: device descriptor read/64, error -71 usb 3-1: device descriptor read/64, error -71 usb 3-1: new full speed USB device using uhci_hcd and address 3 usb 3-1: device descriptor read/64, error -71 usb 3-1: device descriptor read/64, error -71 <----- device not recognized, not drivers are attached <----- plugging SDDR-31 usb 3-1: new full speed USB device using uhci_hcd and address 4 ub: sizeof ub_scsi_cmd 64 ub_dev 2576 uba: device 4 capacity nsec 15681 bsize 512 uba: device 4 capacity nsec 15681 bsize 512 uba: uba1 usbcore: registered new driver ub <---- You'd think you are safe.... ub: cmd #175 cmd status (-71) <---- ... but no. Yay! ub: cmd #176 cmd status (-71) uba: device 4 capacity nsec 0 bsize 512 ub: cmd #177 cmd status (-71) ub: cmd #178 cmd status (-71) uba: device 4 capacity nsec 0 bsize 512 ub: cmd #179 cmd status (-71) uba: device 4 capacity nsec 0 bsize 512 ub: cmd #180 cmd status (-71) uba: device 4 capacity nsec 0 bsize 512 usb 3-1: USB disconnect, address 4 <----- Pulling SDDR-31 and inserting different CF card usb 3-1: new full speed USB device using uhci_hcd and address 5 uba: device 5 capacity nsec 2041201 bsize 512 uba: device 5 capacity nsec 2041201 bsize 512 uba: uba1 usb 3-1: USB disconnect, address 5 <----- From this point on I was unable to make SDDR-31 to throw a -71, but the Imation key does it every time. Insanity! I guess I'm too cheap to buy good stuff which breaks, Jamie :-) The 1GB key was sent to me by Red Hat (the laptop, too). Hurray for corporate support. I'll let you know if I find and fix this, but it's likely the same problem. -- Pete From hhoffman at ip-solutions.net Wed Jan 12 01:35:15 2005 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 11 Jan 2005 20:35:15 -0500 Subject: what USB-2 CF reader is alleged to work? In-Reply-To: <20050111172912.2cadb83e@lembas> References: <20050108141551.47d3180f@lembas.zaitcev.lan> <20050111172912.2cadb83e@lembas> Message-ID: <41E47ED3.5040309@ip-solutions.net> Hurrah! Not that I don't want you to use your device Pete but it's nice on occasion when "taking the car to the mechanic" it actually produces the symptoms. --Harry Pete Zaitcev wrote: > Guess what, I have received a new USB key today, and it shows the problem > right off the bat. But what's more, my old and trusty SDDR-31 now misbehaved, > too (only one time though)! Here's an unedited dmesg: > > <----- plugging new 1GB stick > usb 1-3: new high speed USB device using ehci_hcd and address 3 > usb 3-1: new full speed USB device using uhci_hcd and address 2 > usb 3-1: device descriptor read/64, error -71 > usb 3-1: device descriptor read/64, error -71 > usb 3-1: new full speed USB device using uhci_hcd and address 3 > usb 3-1: device descriptor read/64, error -71 > usb 3-1: device descriptor read/64, error -71 > <----- device not recognized, not drivers are attached > <----- plugging SDDR-31 > usb 3-1: new full speed USB device using uhci_hcd and address 4 > ub: sizeof ub_scsi_cmd 64 ub_dev 2576 > uba: device 4 capacity nsec 15681 bsize 512 > uba: device 4 capacity nsec 15681 bsize 512 > uba: uba1 > usbcore: registered new driver ub <---- You'd think you are safe.... > ub: cmd #175 cmd status (-71) <---- ... but no. Yay! > ub: cmd #176 cmd status (-71) > uba: device 4 capacity nsec 0 bsize 512 > ub: cmd #177 cmd status (-71) > ub: cmd #178 cmd status (-71) > uba: device 4 capacity nsec 0 bsize 512 > ub: cmd #179 cmd status (-71) > uba: device 4 capacity nsec 0 bsize 512 > ub: cmd #180 cmd status (-71) > uba: device 4 capacity nsec 0 bsize 512 > usb 3-1: USB disconnect, address 4 > <----- Pulling SDDR-31 and inserting different CF card > usb 3-1: new full speed USB device using uhci_hcd and address 5 > uba: device 5 capacity nsec 2041201 bsize 512 > uba: device 5 capacity nsec 2041201 bsize 512 > uba: uba1 > usb 3-1: USB disconnect, address 5 > <----- From this point on I was unable to make SDDR-31 to throw a -71, > but the Imation key does it every time. > > Insanity! I guess I'm too cheap to buy good stuff which breaks, Jamie :-) > The 1GB key was sent to me by Red Hat (the laptop, too). Hurray for corporate > support. > > I'll let you know if I find and fix this, but it's likely the same problem. > > -- Pete > From mpeters at mac.com Wed Jan 12 01:38:39 2005 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 12 Jan 2005 01:38:39 +0000 Subject: goals for fc4? In-Reply-To: <1105328387.5866.4.camel@one.myworld> (from feliciano.matias@free.fr on Sun Jan 9 19:39:47 2005) References: <5cf776b8050108150644336d04@mail.gmail.com> <1105328387.5866.4.camel@one.myworld> Message-ID: <1105493919l.5018l.11l@devel.mpeters.us> On 01/09/2005 07:39:47 PM, F?liciano Matias wrote: > Le samedi 08 janvier 2005 ? 19:06 -0400, mbneto a ?crit : > > hi, > > i was wondering where can i find the current goals for fc4 ? > > I want more visibility for the futur "official" Fedora Extra. > Perhaps a /etc/yum.repo.d/extra.repo . I would agree with that. I think installing the extras repo file and putting the key with the other PGP keys would be a good thing. I also think the rawhide and updates-testing repo files should be in a *different* package not installed by a default desktop install, they can cause confusion to new users, who shouldn't be using them unless they specifically know what they are doing. Also - perhaps a jpackage repo and key. That though is a little harder because currently (afaik) jpackage does not provide a repo mirror list. Maybe that should wait until jpackage has their free j2sdk done (I understand they are working on one) Fedora already installs one jpackage package, and jpackage does seem to be the way to go if you want to do java stuff on Fedora, I know of no other alternative that works well through yum. From mpeters at mac.com Wed Jan 12 02:07:19 2005 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 12 Jan 2005 02:07:19 +0000 Subject: udev: Directory for custom device nodes. In-Reply-To: <41E25EBD.3040800@redhat.com> (from harald@redhat.com on Mon Jan 10 02:53:49 2005) References: <41E25EBD.3040800@redhat.com> Message-ID: <1105495639l.5018l.13l@devel.mpeters.us> On 01/10/2005 02:53:49 AM, Harald Hoyer wrote: > Due to > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144593 That bug is very similar to one I filed that was closed because dmesg showed the grep segfault was due to the NVidia drivers. I'm willing to bet that should the reporter disable the nvidia driver, his grep would work perfectly - even with the nvidia modules still in / etc/udev/devices. I'll look for my bug number for you to refer to. From lux at diesel-research.com Wed Jan 12 02:14:29 2005 From: lux at diesel-research.com (Kim Lux) Date: Tue, 11 Jan 2005 19:14:29 -0700 Subject: 2.6.10-1.737 smp kernel crashes. In-Reply-To: <20050111212115.GB1393@nostromo.devel.redhat.com> References: <1105460226.6007.5.camel@localhost.localdomain> <20050111221558.0ec6d94b@python2> <20050111212115.GB1393@nostromo.devel.redhat.com> Message-ID: <1105496070.5833.3.camel@localhost.localdomain> Yep. It is an HP zd7280 which has a 3.2 GHz P4 HT processor. The battery life isn't good, but I don't wait long for compiles. $ cat cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 3.20GHz stepping : 9 cpu MHz : 3192.370 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr bogomips : 6324.22 On Tue, 2005-01-11 at 16:21 -0500, Bill Nottingham wrote: > Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > > Anyway... the 2.6.10-1.737 smp kernel is NOT stable on my laptop. > > > > SMP kernel on a laptop? I'm not sure I get the point :-) > > Laptop with non-mobile P4 with HT? > > Bill > -- Kim Lux, Diesel Research Inc. From mpeters at mac.com Wed Jan 12 02:21:40 2005 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 12 Jan 2005 02:21:40 +0000 Subject: udev: Directory for custom device nodes. In-Reply-To: <1105495639l.5018l.13l@devel.mpeters.us> (from mpeters@mac.com on Tue Jan 11 18:07:19 2005) References: <41E25EBD.3040800@redhat.com> <1105495639l.5018l.13l@devel.mpeters.us> Message-ID: <1105496500l.5018l.14l@devel.mpeters.us> On 01/11/2005 06:07:19 PM, Michael A. Peters wrote: > On 01/10/2005 02:53:49 AM, Harald Hoyer wrote: >> Due to >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144593 > > That bug is very similar to one I filed that was closed because dmesg > showed the grep segfault was due to the NVidia drivers. I can't find the one I reported, I've tried bugzilla parameters that should imho show me closed bugs in grep, but it says zaro bugs found, so I'm not searching bugzilla right apparently - because I _know_ it was there (I filed it), I _know_ it was closed as duplicate of general nvidia bug, I _know_ that the issue was spinlock, and that dmesg showed it was nvidia's driver to blame. But I can't find it in bugzilla. If you know how to search bugzilla better than me, it was reported against grep from my e-mail address < mpeters at mac.com > From mpeters at mac.com Wed Jan 12 02:30:23 2005 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 12 Jan 2005 02:30:23 +0000 Subject: udev: Directory for custom device nodes. In-Reply-To: <1105495639l.5018l.13l@devel.mpeters.us> (from mpeters@mac.com on Tue Jan 11 18:07:19 2005) References: <41E25EBD.3040800@redhat.com> <1105495639l.5018l.13l@devel.mpeters.us> Message-ID: <1105497023l.5018l.15l@devel.mpeters.us> On 01/11/2005 06:07:19 PM, Michael A. Peters wrote: > found it - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141294 From lux at diesel-research.com Wed Jan 12 02:35:43 2005 From: lux at diesel-research.com (Kim Lux) Date: Tue, 11 Jan 2005 19:35:43 -0700 Subject: 2.6.10-1.737 smp kernel crashes. In-Reply-To: <1105496070.5833.3.camel@localhost.localdomain> References: <1105460226.6007.5.camel@localhost.localdomain> <20050111221558.0ec6d94b@python2> <20050111212115.GB1393@nostromo.devel.redhat.com> <1105496070.5833.3.camel@localhost.localdomain> Message-ID: <1105497343.5833.8.camel@localhost.localdomain> cpuinfo was run when running 2.6.9-1.727 NON SMP. If/When I run it with an smp kernel, it shows 2 kernels, kernel 0 and kernel 1. On Tue, 2005-01-11 at 19:14 -0700, Kim Lux wrote: > Yep. It is an HP zd7280 which has a 3.2 GHz P4 HT processor. The > battery life isn't good, but I don't wait long for compiles. > > > $ cat cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 15 > model : 2 > model name : Intel(R) Pentium(R) 4 CPU 3.20GHz > stepping : 9 > cpu MHz : 3192.370 > cache size : 512 KB > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 2 > wp : yes > flags : fpu vme de tsc msr pae mce cx8 apic mtrr pge mca cmov > pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr > bogomips : 6324.22 > > > > On Tue, 2005-01-11 at 16:21 -0500, Bill Nottingham wrote: > > Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > > > Anyway... the 2.6.10-1.737 smp kernel is NOT stable on my laptop. > > > > > > SMP kernel on a laptop? I'm not sure I get the point :-) > > > > Laptop with non-mobile P4 with HT? > > > > Bill > > > -- > Kim Lux, Diesel Research Inc. > > -- Kim Lux, Diesel Research Inc. From dpaun at rogers.com Wed Jan 12 06:15:20 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Wed, 12 Jan 2005 01:15:20 -0500 Subject: Problems with ldap authentication (gdm) Message-ID: <20050112061520.GA30909@rogers.com> It looks like there is (again?) an authentication problem with gdm. Namely, when I'm trying to use LDAP authentication, both local login on a regular console and slogin work like a charm, but gdm fails with the error: "cannot set your user group, you will not be able to log in, please contact your system administrator" Now, this is what I get in /var/log/messages: Jan 12 01:03:16 saturn gdm[2847]: Cannot set user group for bugger Jan 12 01:03:53 saturn gdm[2847]: Cannot set user group for bugger I've done my homework, but I can't seem to find anything useful. Now, I did find a _very_ similar bug reported (strangely enough) exactly one year ago: http://www.redhat.com/archives/fedora-devel-list/2004-January/msg00726.html but that didn't help much either. Any hints would be much appreciated! -- Dimi. From mandreiana at rdslink.ro Wed Jan 12 07:32:31 2005 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Wed, 12 Jan 2005 09:32:31 +0200 Subject: Problems with ldap authentication (gdm) In-Reply-To: <20050112061520.GA30909@rogers.com> References: <20050112061520.GA30909@rogers.com> Message-ID: <1105515152.3584.7.camel@marte.biciclete.ro> On Wed, 2005-01-12 at 01:15 -0500, Dimitrie O. Paun wrote: > Namely, when I'm trying to use LDAP authentication, both > local login on a regular console and slogin work like a charm, > but gdm fails with the error: What files in /etc/pam.d have you changed? system-auth or login? system-auth affects all logins and that should be changed. -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From pknirsch at redhat.com Wed Jan 12 10:02:10 2005 From: pknirsch at redhat.com (Phil Knirsch) Date: Wed, 12 Jan 2005 11:02:10 +0100 Subject: rawhide report: 20050111 changes In-Reply-To: <20050111205108.GN29712@redhat.com> References: <200501111329.j0BDThH28850@porkchop.devel.redhat.com> <41E43818.9090709@optonline.net> <20050111205108.GN29712@redhat.com> Message-ID: <41E4F5A2.6060203@redhat.com> Dave Jones wrote: > On Tue, Jan 11, 2005 at 03:33:28PM -0500, Joel Rittvo wrote: > > > >Removed package kernel-utils > > > > Installing some of these new packages requires removal of kernel-utils. > > I can't remove kernel-utils because lm_sensors depends on it, and > > kdebase and net-snmp depend on lm-sensors. > > > > [root at LINUX]# rpm -Uvh microcode_ctl-1.11-1.6.i386.rpm > > error: Failed dependencies: > > kernel-utils is needed by (installed) lm_sensors-2.8.8-2.i386 > > My guess is it wants it for dmidecode, so its dependancies > need updating. > > Dave > Yep, dmidecode is needed by lm_sensors. Thanks for spotting this, Dave. Next lm_sensors packages will contain the correct deps again. Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From feliciano.matias at free.fr Wed Jan 12 13:09:27 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Wed, 12 Jan 2005 14:09:27 +0100 Subject: mod_dav_svn update Message-ID: <1105535367.28147.14.camel@one.myworld> Update subversion (and mod_dav_svn) to 1.1.2-2.3. But still need to do "services httpd reload". Bugzilla ? RFE ? # rpm -q --scripts mod_dav_svn (empty) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From buildsys at redhat.com Wed Jan 12 13:27:01 2005 From: buildsys at redhat.com (Build System) Date: Wed, 12 Jan 2005 08:27:01 -0500 Subject: rawhide report: 20050112 changes Message-ID: <200501121327.j0CDR1f02226@porkchop.devel.redhat.com> From fedora-devel at camperquake.de Wed Jan 12 14:26:53 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Wed, 12 Jan 2005 15:26:53 +0100 Subject: kernel builds for ppc Message-ID: <20050112152653.3177acc6@nausicaa.camperquake.de> Hi. Before I go off and file a bug about it: is there a reason that no new kernel builds for ppc have shown up for quite a while? -- "Your reality, sir, is lies and balderdash and I am delighted to say that I have no grasp of it whatsoever." -- Baron Munchausen From pbruna at linuxcenterla.com Wed Jan 12 14:41:31 2005 From: pbruna at linuxcenterla.com (Patricio Bruna V) Date: Wed, 12 Jan 2005 11:41:31 -0300 Subject: console caracteres Message-ID: <1105540892.2728.8.camel@p.linuxcenter.cl> im having some troubles with the caracters display in gnome-terminal. for example it can't show the accents and instead shows weird things. PS: i write here because im using fedora devel, and im not sure if its a bug, or a missconfiguration -- Patricio Bruna http://www.linuxcenterla.com Ingeniero de Proyectos Mariano S?nchez Fontecilla 310 Red Hat Certified Engineer Las Condes, Santiago - CHILE Linux Center Latinoamerica Fono: 2745000 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From kyrre at solution-forge.net Wed Jan 12 14:32:25 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 12 Jan 2005 15:32:25 +0100 Subject: Reopen a request for gpgme in Core In-Reply-To: <20050111222903.GB21397@cskk.homeip.net> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106072425.437a2395.fedora@wir-sind-cool.org> <1105053961.5547.83.camel@baythorne.infradead.org> <20050107043149.7fe1feba.fedora@wir-sind-cool.org> <1105095553.5547.105.camel@baythorne.infradead.org> <20050108042746.GC18246@cskk.homeip.net> <1105185875.6500.33.camel@localhost.localdomain> <20050111222903.GB21397@cskk.homeip.net> Message-ID: <1105540345.2654.1.camel@localhost.localdomain> tir, 11.01.2005 kl. 23.29 skrev cs at zip.com.au: > On 12:04 08 Jan 2005, David Woodhouse wrote: > | On Sat, 2005-01-08 at 15:27 +1100, Cameron Simpson wrote: > | > in this way _no_ mail reader needs extending because each remote service is > | > apparently a local ordinary service. [...] > | > I find it extremely convenient. > | > | It's a cute hack, but it doesn't seem to be as convenient as the way > | that Evolution, pine and mutt do it for me transparently. Especially as > | the mail servers I use tend not to have an IMAP d??mon listening at all, > | and as it still doesn't perform the authentication for you in the way > | that using SSH directly does -- your IMAP client would still need to > | store a password. > > Sure, or get me to type it, but on the other hand the place I most do > IMAP to doesn't give file-level access to the mail spool files. So I > can't "ssh in and run an IMAP _daemon_", so a real IMAP connection is > still required, so a password is _still_ required because ssh will only > get you as far as the shell server. > > I don't just do IMAP this way. I do pop this way too, and point fetchmail > at "zip.local" for that, too. And IRC. And you can generally get at any > service this way. If you're routinely inside a firewall that doesn't > allow much out but does allow ssh, you're in business and your tools > don't need to know anything special. So all you need to establish a vpn'ish connection to somewhere is that the site is running an accessable sshd? What about stuffing this into neat etc? It could be super-easy to setup on the server-side, and with a few good point'n'click's you could have it super-easy to setup on the client as well... From kyrre at solution-forge.net Wed Jan 12 14:42:58 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 12 Jan 2005 15:42:58 +0100 Subject: Wanted: A really easy to setup&use small network file server Message-ID: <1105540978.2654.13.camel@localhost.localdomain> After having my strugles with LDAP/NFS/etc, i have seen a need - a need for a really good "set'n'forget" Linux-based directory server, that would allow authentification of users and mounting of homedirs. Something that you could thrust the average person to setup, that would be "insert cd, in anaconda chose LAN file server, install. Add users. Connect clients. Have fun". A really no-fuzz kind of thing. I know this is a short descriptions, i could probably gone to great lengths about this, but i think you get the point. So i just throw out the idea, hoping that somebody caches it... Kyrre Btw. i couldn't not notice that bluecurve window borders around the maps on the control terminal of some new tsunami warning system... I am really relieved they at least did get the OS choice right! Seriously! Now i migth acctually thrust it... (BLUESCREEN: Lost contact with bouy due to earthquake.) From rdieter at math.unl.edu Wed Jan 12 14:45:06 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 12 Jan 2005 08:45:06 -0600 Subject: Pre-Extras apt'able? Message-ID: <41E537F2.4080505@math.unl.edu> Any chance of making Pre-Extras apt'able? -- Rex From jorton at redhat.com Wed Jan 12 15:13:33 2005 From: jorton at redhat.com (Joe Orton) Date: Wed, 12 Jan 2005 15:13:33 +0000 Subject: mod_dav_svn update In-Reply-To: <1105535367.28147.14.camel@one.myworld> References: <1105535367.28147.14.camel@one.myworld> Message-ID: <20050112151332.GA18514@redhat.com> On Wed, Jan 12, 2005 at 02:09:27PM +0100, F?liciano Matias wrote: > Update subversion (and mod_dav_svn) to 1.1.2-2.3. > But still need to do "services httpd reload". As expected, that's entirely the responsibility of root. Doing this from a %post script would be wrong, especially a %post script for anything other than the httpd package itself. joe From dpaun at rogers.com Wed Jan 12 15:31:03 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Wed, 12 Jan 2005 10:31:03 -0500 Subject: Problems with ldap authentication (gdm) In-Reply-To: <1105515152.3584.7.camel@marte.biciclete.ro> References: <20050112061520.GA30909@rogers.com> <1105515152.3584.7.camel@marte.biciclete.ro> Message-ID: <20050112153103.GA469@rogers.com> On Wed, Jan 12, 2005 at 09:32:31AM +0200, Marius Andreiana wrote: > On Wed, 2005-01-12 at 01:15 -0500, Dimitrie O. Paun wrote: > > Namely, when I'm trying to use LDAP authentication, both > > local login on a regular console and slogin work like a charm, > > but gdm fails with the error: > What files in /etc/pam.d have you changed? system-auth or login? Both, and passwd on top of it. -- Dimi. From feliciano.matias at free.fr Wed Jan 12 15:33:13 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Wed, 12 Jan 2005 16:33:13 +0100 Subject: mod_dav_svn update In-Reply-To: <20050112151332.GA18514@redhat.com> References: <1105535367.28147.14.camel@one.myworld> <20050112151332.GA18514@redhat.com> Message-ID: <1105543993.31987.8.camel@one.myworld> Le mercredi 12 janvier 2005 ? 15:13 +0000, Joe Orton a ?crit : > On Wed, Jan 12, 2005 at 02:09:27PM +0100, F?liciano Matias wrote: > > Update subversion (and mod_dav_svn) to 1.1.2-2.3. > > But still need to do "services httpd reload". > > As expected, that's entirely the responsibility of root. "rpm -[iU]" only works with root. But I understand your point. Is this a bug ? $ rpm -q --scripts bind postuninstall scriptlet (using /bin/sh): if [ "$1" -ge 1 ]; then /etc/rc.d/init.d/named condrestart >/dev/null 2>&1 || : fi Seems a common practise : $ rpm -q --scripts --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ -a | grep "condrestart" | wc -l 92 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mbneto at gmail.com Wed Jan 12 16:02:58 2005 From: mbneto at gmail.com (mbneto) Date: Wed, 12 Jan 2005 12:02:58 -0400 Subject: goals for fc4? In-Reply-To: <41E0AC79.90605@insight.rr.com> References: <5cf776b8050108150644336d04@mail.gmail.com> <41E0AC79.90605@insight.rr.com> Message-ID: <5cf776b805011208025d070f81@mail.gmail.com> Hi Jim, I agree with you. I was wondering if there is an "oficial" position regarding this. The website usually has a roadmap or tentative schedule but nothing so far. On Sat, 08 Jan 2005 23:00:57 -0500, Jim Cornette wrote: > mbneto wrote: > > hi, > > i was wondering where can i find the current goals for fc4 ? > > > > I 've checked fedora.redhat.com with no luck. > > > > - mb > > > > There waa some discussion about what to make of FC4. Some of the > discussion centered around making the cycle shorter and FC4 a cleaner > installation. > > The discussion was shortly after the release of FC3. I believe that > nothing ever was really decided as for the makeup of FC4. > > I'd like to see a less buggy release and a release that is as close to > upstream programs as possible. Both goals seem to not fit together, but > are probably alright to consider as. > The lowest bug count with the most stable program versions. > > I cannot recall if the discussion was on the development list or on the > test list. > > Jim > > -- > I sometimes think that God, in creating man, somewhat overestimated his > ability. > -- Oscar Wilde > From dwmw2 at infradead.org Wed Jan 12 16:30:14 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 12 Jan 2005 16:30:14 +0000 Subject: kernel builds for ppc In-Reply-To: <20050112152653.3177acc6@nausicaa.camperquake.de> References: <20050112152653.3177acc6@nausicaa.camperquake.de> Message-ID: <1105547415.26551.115.camel@hades.cambridge.redhat.com> On Wed, 2005-01-12 at 15:26 +0100, Ralf Ertzinger wrote: > > Before I go off and file a bug about it: is there a reason that no new > kernel builds for ppc have shown up for quite a while? It was disabled in 1.1067 with a comment '4-level pagetables broke the world'. If I add ppc64 back to the ExlusiveArch line it does seem to build now, although ppc doesn't build for other reasons (RAID6 Altivec support broken). We really ought to require a bug to be filed before the build system will allow you to exclude architectures. -- dwmw2 From dax at gurulabs.com Wed Jan 12 17:12:19 2005 From: dax at gurulabs.com (Dax Kelson) Date: Wed, 12 Jan 2005 10:12:19 -0700 Subject: 2.6.10-1.737_FC3 kernel panic Message-ID: <1105549939.6089.9.camel@mentorng.gurulabs.com> Note that I've created a bugzilla bug for this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144905 Thought I'd toss it out here to see if anyone else is seeing the same thing. My kernel is not tainted. ------------------------------- (transcribed from a cell phone camera picture) (jpeg here: https://bugzilla.redhat.com/bugzilla/attachment.cgi? id=109677&action=view) ds: 007b es: 007b ss: 0068 Process udevd (pid: 1501, threadinfo=f744e000 task=f7ae0bb0) Stack: f7ffb110 f7fffac0 f77e3000 f7ffb110 f7ffe2c0 c0145b0b 0000000c f7ffb100 f7ffb100 f77e3000 f7ffb110 00000286 c0145d43 f7b78750 f7b78750 00000000 f70ad22c c0118679 f7b78750 c011c696 f7b707fc f7b78750 00000000 0000ea00 Call Trace: [] cache_flusharray+0xc8/0x144 [] kfree+0x3b/0x49 [] free_task+0xb/0x18 [] release_task+0x1b1/0x1c0 [] wait_task_zombie+0x650/0x66b [] do_wait+0x173/0x403 [] default_wake_function+0x0/0xc [] default_wake_function+0x0/0xc [] vfs_read+0xb6/0xe2 [] sys_wait4+0x27/0x2a [] sys_waidpid+0x13/0x17 [] syscalll_call+0x7/0xb Code: 40 24 39 fd 0f 0d 99 00 00 00 0b 04 24 0b 15 10 0e 3f c0 8b 0c a8 8d 81 00 00 00 40 c1 e0 0c c1 e0 05 8b 5c 10 1c 0b 53 04 8b 03 <89> 50 04 89 02 31 d2 2b <0>Kernel panic - not syncing: mm/slab.c:2202: spin_lock(mm/slab.c:f7fffb04) already locked by mm/slab.c/2202 From michael.es.carney at sbcglobal.net Wed Jan 12 18:09:41 2005 From: michael.es.carney at sbcglobal.net (Michael W. Carney) Date: Wed, 12 Jan 2005 10:09:41 -0800 Subject: 2.6.10-1.737_FC3 kernel panic In-Reply-To: <1105549939.6089.9.camel@mentorng.gurulabs.com> References: <1105549939.6089.9.camel@mentorng.gurulabs.com> Message-ID: <41E567E5.3000505@sbcglobal.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dax Kelson wrote: | Note that I've created a bugzilla bug for this: | | https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144905 | | Thought I'd toss it out here to see if anyone else is seeing the same | thing. | | My kernel is not tainted. | | ------------------------------- | (transcribed from a cell phone camera picture) | (jpeg here: https://bugzilla.redhat.com/bugzilla/attachment.cgi? | id=109677&action=view) | | ds: 007b es: 007b ss: 0068 | Process udevd (pid: 1501, threadinfo=f744e000 task=f7ae0bb0) | Stack: f7ffb110 f7fffac0 f77e3000 f7ffb110 f7ffe2c0 c0145b0b 0000000c f7ffb100 | f7ffb100 f77e3000 f7ffb110 00000286 c0145d43 f7b78750 f7b78750 00000000 | f70ad22c c0118679 f7b78750 c011c696 f7b707fc f7b78750 00000000 0000ea00 | Call Trace: | [] cache_flusharray+0xc8/0x144 | [] kfree+0x3b/0x49 | [] free_task+0xb/0x18 | [] release_task+0x1b1/0x1c0 | [] wait_task_zombie+0x650/0x66b | [] do_wait+0x173/0x403 | [] default_wake_function+0x0/0xc | [] default_wake_function+0x0/0xc | [] vfs_read+0xb6/0xe2 | [] sys_wait4+0x27/0x2a | [] sys_waidpid+0x13/0x17 | [] syscalll_call+0x7/0xb | Code: 40 24 39 fd 0f 0d 99 00 00 00 0b 04 24 0b 15 10 0e 3f c0 8b 0c a8 8d 81 00 00 00 40 c1 e0 0c c1 e0 05 8b 5c 10 1c 0b 53 04 8b 03 <89> 50 04 89 02 31 d2 2b <0>Kernel panic - not syncing: mm/slab.c:2202: spin_lock(mm/slab.c:f7fffb04) already locked by mm/slab.c/2202 | | I'm seeing precisely the same panic on my IBM thinkpad R40. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB5Wfl0b4qNouqSt4RAqnxAJ9rssX/CsHIv335V3i0UT+aFbPnWQCdEsBG IfaP9xgM66mxk6KsYdwWwx8= =K2Hz -----END PGP SIGNATURE----- From mpeters at mac.com Thu Jan 13 06:19:18 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 13 Jan 2005 06:19:18 +0000 Subject: LZW and legal stuff Message-ID: <1105597158l.27992l.1l@devel.mpeters.us> LZW patent is no longer valid, according to Unisys themselves. What are the chances (I guess lawyers need to get involved etc.) of using LZW packages with Fedora? For example - giflib, lzw compression kit for libtiff, etc. It does look like the version of gd that ships with Fedora Core has gif functionallity added back into by the upstream developer, and Fedora did not patch it out - is that just an oversight or are you comfortable with lzw compression now that the Unisys patent has expired? If there are no *other* legal issues, I think lzw compression kit for libtiff would definitely be good, the new version of gimp apparently has better support for raw images from various digital cameras, and lzw compressed tiff is a good way to share tiff images between operating systems at a small filesize (IE sending images to stock photo company) From dwmw2 at infradead.org Thu Jan 13 07:55:53 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 13 Jan 2005 07:55:53 +0000 Subject: LZW and legal stuff In-Reply-To: <1105597158l.27992l.1l@devel.mpeters.us> References: <1105597158l.27992l.1l@devel.mpeters.us> Message-ID: <1105602953.30759.34.camel@baythorne.infradead.org> On Thu, 2005-01-13 at 06:19 +0000, Michael A. Peters wrote: > LZW patent is no longer valid, according to Unisys themselves. > What are the chances (I guess lawyers need to get involved etc.) of > using LZW packages with Fedora? > > For example - giflib, lzw compression kit for libtiff, etc. Is this the same patent that covers isdn_lzscomp? -- dwmw2 From mandreiana at rdslink.ro Thu Jan 13 08:33:10 2005 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Thu, 13 Jan 2005 10:33:10 +0200 Subject: enable tcp_syncookies by default? Message-ID: <1105605191.7061.2.camel@marte.biciclete.ro> Hi Based on information below, can /proc/sys/net/ipv4/tcp_syncookies/tcp_syncookies be enabled by default? Are there any drawbacks? A very popular denial of service attack involves a cracker sending many (possibly forged) SYN packets to your server, but never completing the TCP three way handshake. This quickly uses up slots in the kernel's half open queue, preventing legitimate connections from succeeding. Since a connection does not need to be completed, there need be no resources used on the attacking machine, so this is easy to perform and maintain. If the tcp_syncookies variable is set (only available if your kernel was compiled with CONFIG_SYNCOOKIES) then the kernel handles TCP SYN packets normally until the queue is full, at which point the SYN cookie functionality kicks in. SYN cookies work by not using a SYN queue at all. Instead the kernel will reply to any SYN packet with a SYN|ACK as normal, but it will present a specially-crafted TCP sequence number that encodes the source and destination IP address and port number and the time the packet was sent. An attacker performing the SYN flood would never have gotten this packet at all if they're spoofing, so they wouldn't respond. A legitimate connection attempt would send the third packet of the three way handshake which includes this sequence number, and the server can verify that it must be in response to a valid SYN cookie and allows the connection, even though there is no corresponding entry in the SYN queue. Enabling SYN cookies is a very simple way to defeat SYN flood attacks while using only a bit more CPU time for the cookie creation and verification. Since the alternative is to reject all incoming connections, enabling SYN cookies is an obvious choice. Thanks, -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From warren at togami.com Thu Jan 13 09:49:24 2005 From: warren at togami.com (Warren Togami) Date: Wed, 12 Jan 2005 23:49:24 -1000 Subject: 2.6.10-1.737 smp kernel crashes. In-Reply-To: <1105460226.6007.5.camel@localhost.localdomain> References: <1105460226.6007.5.camel@localhost.localdomain> Message-ID: <41E64424.50107@togami.com> Kim Lux wrote: > I'm not sure if this is the right list, but I'll post here anyway as it > is not a user or config issue associated with FC3 operation and 2.6.10 > kernels are kind of FC4 stuff ? > > Anyway... the 2.6.10-1.737 smp kernel is NOT stable on my laptop. It > does a hard kernel crash (ie total machine lockup, cannot start a new > session). This has happened 3x when websurfing with Konqueror. It > seems to occur when performing socket communications ie immediately > after double clicking a link, but that is just a quick observation. > > I've run 2.6.10-1.727 since it became available on the same machine > without any issues. I've reverted back to it. > > Hope this helps. > http://fedoraproject.org/wiki/PostIsOffTopic Your justification is not sufficient, this is a regular user support issue. Posts of these nature are off-topic for this. In any case these issues must be reported to Bugzilla or they will not be acted upon. Warren Togami wtogami at redhat.com From wtogami at redhat.com Thu Jan 13 09:51:53 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 12 Jan 2005 23:51:53 -1000 Subject: Pre-Extras apt'able? In-Reply-To: <41E537F2.4080505@math.unl.edu> References: <41E537F2.4080505@math.unl.edu> Message-ID: <41E644B9.2040303@redhat.com> Rex Dieter wrote: > Any chance of making Pre-Extras apt'able? > > -- Rex > Yes I plan on doing so soon on the download.fedora.us mirrors. Also pre-extras will be relaunched into download.fedora.redhat.com soon. Seth can I rsync the current pre-extras in any way? Warren Togami wtogami at redhat.com From jorton at redhat.com Thu Jan 13 10:05:32 2005 From: jorton at redhat.com (Joe Orton) Date: Thu, 13 Jan 2005 10:05:32 +0000 Subject: mod_dav_svn update In-Reply-To: <1105543993.31987.8.camel@one.myworld> References: <1105535367.28147.14.camel@one.myworld> <20050112151332.GA18514@redhat.com> <1105543993.31987.8.camel@one.myworld> Message-ID: <20050113100532.GA11733@redhat.com> On Wed, Jan 12, 2005 at 04:33:13PM +0100, F?liciano Matias wrote: > Le mercredi 12 janvier 2005 ? 15:13 +0000, Joe Orton a ?crit : > > On Wed, Jan 12, 2005 at 02:09:27PM +0100, F?liciano Matias wrote: > > > Update subversion (and mod_dav_svn) to 1.1.2-2.3. > > > But still need to do "services httpd reload". > > > > As expected, that's entirely the responsibility of root. > > "rpm -[iU]" only works with root. > But I understand your point. > > Is this a bug ? > $ rpm -q --scripts bind > postuninstall scriptlet (using /bin/sh): > if [ "$1" -ge 1 ]; then > /etc/rc.d/init.d/named condrestart >/dev/null 2>&1 || : > fi I'd say it depends on the daemon, for some it could be necessary. But for any network-facing daemon I would say that it's surprising and undesirable behaviour if a package update breaks active client connections etc. Making configuration changes take effect from a %post is unfriendly; especially if the config is not marked noreplace. joe From harald at redhat.com Thu Jan 13 10:55:07 2005 From: harald at redhat.com (Harald Hoyer) Date: Thu, 13 Jan 2005 11:55:07 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <2DE09267-62F8-11D9-B875-000D9352858E@linuxmail.org> References: <41E25EBD.3040800@redhat.com> <2DE09267-62F8-11D9-B875-000D9352858E@linuxmail.org> Message-ID: <41E6538B.9050408@redhat.com> Felipe Alfaro Solana wrote: > On 10 Jan 2005, at 11:53, Harald Hoyer wrote: > >> Due to >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144593 >> I am thinking of another directory to put device nodes in, which >> should be copied over to /dev on system start. >> >> Any suggestions? > > > "/udev/devices" or "/udev/custom" sounds great. > I really don't want to start a new toplevel directory... From harald at redhat.com Thu Jan 13 10:57:38 2005 From: harald at redhat.com (Harald Hoyer) Date: Thu, 13 Jan 2005 11:57:38 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <20050110215600.GC16171@nostromo.devel.redhat.com> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> Message-ID: <41E65422.1070409@redhat.com> Bill Nottingham wrote: > Harald Hoyer (harald at redhat.com) said: > >>Due to >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144593 >>I am thinking of another directory to put device nodes in, which should >>be copied over to /dev on system start. >> >>Any suggestions? > > > I'd think that a series of makedev invocations to run would be > safer. > > Bill > so how can we make this rpm friendly? /etc/sysconfig/makedev.d/ system.nodes custom1.nodes custom2.nodes cat /etc/sysconfig/makedev.d/*.nodes | xargs MAKEDEV -x doh, xargs is in /usr/bin ! :-/ hmm, btw is /etc/makedev.d '.rpmorig' '.rpmsave' save? From feliciano.matias at free.fr Thu Jan 13 10:58:32 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 13 Jan 2005 11:58:32 +0100 Subject: mod_dav_svn update In-Reply-To: <20050113100532.GA11733@redhat.com> References: <1105535367.28147.14.camel@one.myworld> <20050112151332.GA18514@redhat.com> <1105543993.31987.8.camel@one.myworld> <20050113100532.GA11733@redhat.com> Message-ID: <1105613912.8286.20.camel@one.myworld> Le jeudi 13 janvier 2005 ? 10:05 +0000, Joe Orton a ?crit : > On Wed, Jan 12, 2005 at 04:33:13PM +0100, F?liciano Matias wrote: > > Is this a bug ? > > $ rpm -q --scripts bind > > postuninstall scriptlet (using /bin/sh): > > if [ "$1" -ge 1 ]; then > > /etc/rc.d/init.d/named condrestart >/dev/null 2>&1 || : > > fi > > I'd say it depends on the daemon, for some it could be necessary. But > for any network-facing daemon I would say that it's surprising and > undesirable behaviour if a package update breaks active client > connections etc. Making configuration changes take effect from a %post > is unfriendly; especially if the config is not marked noreplace. > When I update my system, the propose is to use the new version (security fix, ...). Perhaps it's better to schedule an update at midnight than when there is a rush of connection. It's up to the administrator to decide when and how to update his system. If daemons are not restarted when I update a system then when this append ? Do you ask me to always reboot my computer after "yum update" ? Too bad. Suppose I update httpd and httpd is not restarted. One week later the server is restarted (power failure), the new httpd does not start and "bad luck" I am in holidays... What do you think about this scenario ? btw, "service httpd reload" (or condreload) is not enough alter an update ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From christof at damian.net Thu Jan 13 10:58:44 2005 From: christof at damian.net (Christof Damian) Date: Thu, 13 Jan 2005 11:58:44 +0100 Subject: Pre-Extras apt'able? In-Reply-To: <41E644B9.2040303@redhat.com> References: <41E537F2.4080505@math.unl.edu> <41E644B9.2040303@redhat.com> Message-ID: <20050113105844.GN24145@batman.gotham.krass.com> On Wed, 12 Jan 2005, Warren Togami wrote: > Rex Dieter wrote: > >Any chance of making Pre-Extras apt'able? > > > > > > Yes I plan on doing so soon on the download.fedora.us mirrors. Also > pre-extras will be relaunched into download.fedora.redhat.com soon. > > Seth can I rsync the current pre-extras in any way? i found one rsync mirror at rsync://ftp.upjs.sk/ftp/pub/mirrors/pre-extras/ christof -- Christof Damian christof at damian.net From feliciano.matias at free.fr Thu Jan 13 11:25:29 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 13 Jan 2005 12:25:29 +0100 Subject: Pre-Extras apt'able? In-Reply-To: <41E644B9.2040303@redhat.com> References: <41E537F2.4080505@math.unl.edu> <41E644B9.2040303@redhat.com> Message-ID: <1105615529.8286.24.camel@one.myworld> About Pre-Extras, is there any know problems or advices to update from fedora.us to Pre-Extra ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nphilipp at redhat.com Thu Jan 13 12:06:36 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Thu, 13 Jan 2005 13:06:36 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <41E65422.1070409@redhat.com> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> Message-ID: <1105617996.5578.5.camel@wombat.tiptoe.de> On Thu, 2005-01-13 at 11:57 +0100, Harald Hoyer wrote: > Bill Nottingham wrote: > > Harald Hoyer (harald at redhat.com) said: > > > >>Due to > >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144593 > >>I am thinking of another directory to put device nodes in, which should > >>be copied over to /dev on system start. > >> > >>Any suggestions? > > > > > > I'd think that a series of makedev invocations to run would be > > safer. > > > > Bill > > > > so how can we make this rpm friendly? > /etc/sysconfig/makedev.d/ > system.nodes > custom1.nodes > custom2.nodes > > cat /etc/sysconfig/makedev.d/*.nodes | xargs MAKEDEV -x > > doh, xargs is in /usr/bin ! :-/ how about this "xargs for the poor" (could be changed a bit and put into /etc/init.d/functions): --- 8< --- FILES=/etc/sysconfig/makedev.d/*.nodes MAXNR=100 COMMAND="MAKEDEV -x" NR=$MAXNR ARGS="" cat $FILES | while read line; do if [ "$NR" -gt 0 ]; then ARGS="$ARGS $line" NR=$[$NR - 1] else $COMMAND $ARGS NR=$MAXNR ARGS="$line" fi done if [ -n "$ARGS" ]; then $COMMAND $ARGS fi --- >8 --- Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From mpeters at mac.com Thu Jan 13 12:15:13 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 13 Jan 2005 12:15:13 +0000 Subject: Pre-Extras apt'able? In-Reply-To: <1105615529.8286.24.camel@one.myworld> (from feliciano.matias@free.fr on Thu Jan 13 03:25:29 2005) References: <41E537F2.4080505@math.unl.edu> <41E644B9.2040303@redhat.com> <1105615529.8286.24.camel@one.myworld> Message-ID: <1105618513l.6511l.0l@devel.mpeters.us> On 01/13/2005 03:25:29 AM, F?liciano Matias wrote: > About Pre-Extras, is there any know problems or advices to update > from > fedora.us to > Pre-Extra ? > My experience is that they are almost the same packages, except pre- extras have (sometimes) some fixes, and a higher release tag - so there should be few (if any) problems. I personally experienced only one, which was a bug in the spec file and very quickly fixed (within a day of pre-extras launch if I recall) From feliciano.matias at free.fr Thu Jan 13 12:25:29 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 13 Jan 2005 13:25:29 +0100 Subject: Pre-Extras apt'able? In-Reply-To: <1105618513l.6511l.0l@devel.mpeters.us> References: <41E537F2.4080505@math.unl.edu> <41E644B9.2040303@redhat.com> <1105615529.8286.24.camel@one.myworld> <1105618513l.6511l.0l@devel.mpeters.us> Message-ID: <1105619129.8920.5.camel@one.myworld> Le jeudi 13 janvier 2005 ? 12:15 +0000, Michael A. Peters a ?crit : > On 01/13/2005 03:25:29 AM, F?liciano Matias wrote: > > About Pre-Extras, is there any know problems or advices to update > > from > > fedora.us to > > Pre-Extra ? > > > > My experience is that they are almost the same packages, except pre- > extras have (sometimes) some fixes, and a higher release tag - so there > should be few (if any) problems. > > I personally experienced only one, which was a bug in the spec file and > very quickly fixed (within a day of pre-extras launch if I recall) > > Thanks for your feedback. I'll try Pre-Extra as soon as I can. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pbruna at linuxcenterla.com Thu Jan 13 12:59:37 2005 From: pbruna at linuxcenterla.com (Patricio Bruna V) Date: Thu, 13 Jan 2005 09:59:37 -0300 Subject: Pre-Extras apt'able? In-Reply-To: <20050113105844.GN24145@batman.gotham.krass.com> References: <41E537F2.4080505@math.unl.edu> <41E644B9.2040303@redhat.com> <20050113105844.GN24145@batman.gotham.krass.com> Message-ID: <1105621177.2709.3.camel@p.linuxcenter.cl> El jue, 13-01-2005 a las 11:58 +0100, Christof Damian escribi?: > On Wed, 12 Jan 2005, Warren Togami wrote: > > Rex Dieter wrote: > > >Any chance of making Pre-Extras apt'able? > > > > > > > > > > Yes I plan on doing so soon on the download.fedora.us mirrors. Also > > pre-extras will be relaunched into download.fedora.redhat.com soon. > > > > Seth can I rsync the current pre-extras in any way? > > i found one rsync mirror at rsync://ftp.upjs.sk/ftp/pub/mirrors/pre-extras/ > > christof > -- > Christof Damian > christof at damian.net > any problems or inconsistency with dag, dries, etc..? -- Patricio Bruna http://www.linuxcenterla.com Ingeniero de Proyectos Mariano S?nchez Fontecilla 310 Red Hat Certified Engineer Las Condes, Santiago - CHILE Linux Center Latinoamerica Fono: 2745000 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje est? firmada digitalmente URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Jan 13 12:57:59 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 13 Jan 2005 13:57:59 +0100 Subject: Pre-Extras apt'able? In-Reply-To: <1105621177.2709.3.camel@p.linuxcenter.cl> References: <41E537F2.4080505@math.unl.edu> <41E644B9.2040303@redhat.com> <20050113105844.GN24145@batman.gotham.krass.com> <1105621177.2709.3.camel@p.linuxcenter.cl> Message-ID: <20050113135759.49a3ef65@python2> Patricio Bruna V wrote : > any problems or inconsistency with dag, dries, etc..? Normally, as little as possible. I'll do my best to have any that people may report fixed on either side , naturally. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.9-1.724_FC3.radeon Load : 1.68 1.73 1.46 From alan at redhat.com Thu Jan 13 13:03:02 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 13 Jan 2005 08:03:02 -0500 Subject: LZW and legal stuff In-Reply-To: <1105602953.30759.34.camel@baythorne.infradead.org> References: <1105597158l.27992l.1l@devel.mpeters.us> <1105602953.30759.34.camel@baythorne.infradead.org> Message-ID: <20050113130302.GC6052@devserv.devel.redhat.com> On Thu, Jan 13, 2005 at 07:55:53AM +0000, David Woodhouse wrote: > On Thu, 2005-01-13 at 06:19 +0000, Michael A. Peters wrote: > > LZW patent is no longer valid, according to Unisys themselves. > > What are the chances (I guess lawyers need to get involved etc.) of > > using LZW packages with Fedora? > > > > For example - giflib, lzw compression kit for libtiff, etc. > > Is this the same patent that covers isdn_lzscomp? No. From buildsys at redhat.com Thu Jan 13 13:38:24 2005 From: buildsys at redhat.com (Build System) Date: Thu, 13 Jan 2005 08:38:24 -0500 Subject: rawhide report: 20050113 changes Message-ID: <200501131338.j0DDcOY23042@porkchop.devel.redhat.com> From rjune at bravegnuworld.com Thu Jan 13 13:50:34 2005 From: rjune at bravegnuworld.com (Richard June) Date: Thu, 13 Jan 2005 08:50:34 -0500 Subject: Reopen a request for gpgme in Core In-Reply-To: <1105540345.2654.1.camel@localhost.localdomain> References: <1104977635.10350.17.camel@Madison.badger.com> <20050111222903.GB21397@cskk.homeip.net> <1105540345.2654.1.camel@localhost.localdomain> Message-ID: <200501130850.38025.rjune@bravegnuworld.com> [snip] > So all you need to establish a vpn'ish connection to somewhere is that > the site is running an accessable sshd? > > What about stuffing this into neat etc? It could be super-easy to setup > on the server-side, and with a few good point'n'click's you could have > it super-easy to setup on the client as well... for a vpn, all you need is accessable ssh and pppd. This is ssh portforwarding which is slightly different, this sets up encryption per port. whereas ppp over ssh is an actual vpn. neat support for ppp over ssh would be nice. I use it a fair bit. -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From iago.rubio at hispalinux.es Thu Jan 13 14:05:06 2005 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Thu, 13 Jan 2005 15:05:06 +0100 Subject: enable tcp_syncookies by default? In-Reply-To: <1105605191.7061.2.camel@marte.biciclete.ro> References: <1105605191.7061.2.camel@marte.biciclete.ro> Message-ID: <1105625105.19764.23.camel@speedy.iagorubio.net> On Thu, 2005-01-13 at 09:33, Marius Andreiana wrote: > Hi > > Based on information below, can > /proc/sys/net/ipv4/tcp_syncookies/tcp_syncookies > be enabled by default? Are there any drawbacks? [snipped explanation on syn flood] Being a CPU consuming process to create and check the cookies, Will not be better to let this setting as is ? People who have to deal with Internet connected machines should know how to enable syn cookies (is not so hard to write down `echo 1 > /proc/sys/net/ipv4/tcp_syncookies` ). Machines not facing Internet have no need to waste resources in creating and checking the cookies. Default settings should be for the most common configuration, and I'm not sure most users should have syn cookies enabled. Regards -- Iago Rubio From harald at redhat.com Thu Jan 13 15:27:59 2005 From: harald at redhat.com (Harald Hoyer) Date: Thu, 13 Jan 2005 16:27:59 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <1105617996.5578.5.camel@wombat.tiptoe.de> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> Message-ID: <41E6937F.2070904@redhat.com> Nils Philippsen wrote: > how about this "xargs for the poor" (could be changed a bit and put > into /etc/init.d/functions): > > --- 8< --- > FILES=/etc/sysconfig/makedev.d/*.nodes > MAXNR=100 > COMMAND="MAKEDEV -x" > > NR=$MAXNR > ARGS="" > cat $FILES | while read line; do > if [ "$NR" -gt 0 ]; then > ARGS="$ARGS $line" > NR=$[$NR - 1] > else > $COMMAND $ARGS > NR=$MAXNR > ARGS="$line" > fi > done > if [ -n "$ARGS" ]; then > $COMMAND $ARGS > fi > --- >8 --- > > Nils what about this one? :) for i in /etc/sysconfig/makedev.d/*.nodes; do MAKEDEV -x $(cat "$i") done From pekkas at netcore.fi Thu Jan 13 15:48:12 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 13 Jan 2005 17:48:12 +0200 (EET) Subject: enable tcp_syncookies by default? In-Reply-To: <1105625105.19764.23.camel@speedy.iagorubio.net> References: <1105605191.7061.2.camel@marte.biciclete.ro> <1105625105.19764.23.camel@speedy.iagorubio.net> Message-ID: On Thu, 13 Jan 2005, Iago Rubio wrote: > Default settings should be for the most common configuration, By that logic, syn cookies should be enabled. It's 2005. Computers are connected to the net, period. It's better to err in the side of caution, you know. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From jspaleta at gmail.com Thu Jan 13 16:09:35 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 13 Jan 2005 11:09:35 -0500 Subject: enable tcp_syncookies by default? In-Reply-To: <1105605191.7061.2.camel@marte.biciclete.ro> References: <1105605191.7061.2.camel@marte.biciclete.ro> Message-ID: <604aa79105011308092dd7cfcd@mail.gmail.com> On Thu, 13 Jan 2005 10:33:10 +0200, Marius Andreiana wrote: > Enabling SYN cookies is a very simple way to defeat SYN flood attacks > while using only a bit more CPU time for the cookie creation and > verification. Since the alternative is to reject all incoming > connections, enabling SYN cookies is an obvious choice. only a bit more CPU time? Are there any hard numbers here to use to evaluate the trade-off more quantiatively? In what sort of load situations would you start to notice the cpu hit? Are we talking about a 400 Mhz pentium running a small public web server? Are we talking about a typical desktop/workstation install on middle of the road current hardware? Does a very active web server on reasonable modern hardware see the cpu hit because of its high network traffic? How does this scale with network activity and hardware resources? Where are the cases where this becomes noticable? -jef From kyrre at solution-forge.net Thu Jan 13 16:12:45 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 13 Jan 2005 17:12:45 +0100 Subject: Pre-Extras apt'able? In-Reply-To: <1105615529.8286.24.camel@one.myworld> References: <41E537F2.4080505@math.unl.edu> <41E644B9.2040303@redhat.com> <1105615529.8286.24.camel@one.myworld> Message-ID: <1105632764.2647.0.camel@localhost.localdomain> tor, 13.01.2005 kl. 12.25 skrev F?liciano Matias: > About Pre-Extras, is there any know problems or advices to update from > fedora.us to > Pre-Extra ? And livna and pre-extras? BTW - why does livna recomend you to put in all of their repos - including "unstable" og "testing"? > > ______________________________________________________________________ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From rdieter at math.unl.edu Thu Jan 13 16:16:33 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 13 Jan 2005 10:16:33 -0600 Subject: Pre-Extras apt'able? In-Reply-To: <1105632764.2647.0.camel@localhost.localdomain> References: <41E537F2.4080505@math.unl.edu> <41E644B9.2040303@redhat.com> <1105615529.8286.24.camel@one.myworld> <1105632764.2647.0.camel@localhost.localdomain> Message-ID: <41E69EE1.5080708@math.unl.edu> Kyrre Ness Sjobak wrote: > BTW - why does livna recomend you to put in all of their repos - > including "unstable" og "testing"? AFAIK, livna does no such thing. ?? -- Rex From rdieter at math.unl.edu Thu Jan 13 16:19:32 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 13 Jan 2005 10:19:32 -0600 Subject: Pre-Extras apt'able? In-Reply-To: <41E69EE1.5080708@math.unl.edu> References: <41E537F2.4080505@math.unl.edu> <41E644B9.2040303@redhat.com> <1105615529.8286.24.camel@one.myworld> <1105632764.2647.0.camel@localhost.localdomain> <41E69EE1.5080708@math.unl.edu> Message-ID: <41E69F94.3010008@math.unl.edu> Rex Dieter wrote: > Kyrre Ness Sjobak wrote: > >> BTW - why does livna recomend you to put in all of their repos - >> including "unstable" og "testing"? > > > AFAIK, livna does no such thing. ?? http://rpm.livna.org/configuration.html Oops, I stand corrected. Their default apt config *does* include testing and unstable. Ack, I hope it's a simple oversight/mistake on their part. -- Rex From os at sumu.org Thu Jan 13 16:36:19 2005 From: os at sumu.org (Oskari Saarenmaa) Date: Thu, 13 Jan 2005 18:36:19 +0200 Subject: enable tcp_syncookies by default? In-Reply-To: <604aa79105011308092dd7cfcd@mail.gmail.com> References: <1105605191.7061.2.camel@marte.biciclete.ro> <604aa79105011308092dd7cfcd@mail.gmail.com> Message-ID: <20050113163619.GA28605@shadow.sumu.org> On Thu, Jan 13, 2005 at 11:09:35AM -0500, Jeff Spaleta wrote: > How does this scale with network activity and hardware resources? > Where are the cases where this becomes noticable? Note that syncookies are not used until the synqueue is full, so unless the server is under attack everything proceeds just as it would with syncookies turned off. They are only enabled when the queue fills up, and in that case spending a bit more (I don't have any numbers on this) CPU time should be favourable to not being able to answer incoming requests. I run a fairly busy database-heavy website on a lowend PC (1.2ghz athlon) that gets around a million hits per day - and also gets SYN flooded every now and then. After I enabled syncookies on the server it has always managed to serve all valid requests. So.. is there a reason why they are not enabled by default? Cheers, Oskari -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From carlos.efr at mail.telepac.pt Thu Jan 13 16:38:25 2005 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Thu, 13 Jan 2005 16:38:25 +0000 Subject: Minimal installation Message-ID: <41E6A401.4020403@mail.telepac.pt> Hi! I've tried to do a minimal installation of FC3, only to find that it really isn't that minimal... So, my suggestion is: would it be possible to have a really minimal installation option? I was thinking something like the base installation of the BSDs. Carlos Rodrigues -- url: http://tudo-sobre-nada.blogspot.com From fedora-devel at camperquake.de Thu Jan 13 16:46:19 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 13 Jan 2005 17:46:19 +0100 Subject: Minimal installation In-Reply-To: <41E6A401.4020403@mail.telepac.pt>; from carlos.efr@mail.telepac.pt on Thu, Jan 13, 2005 at 04:38:25PM +0000 References: <41E6A401.4020403@mail.telepac.pt> Message-ID: <20050113174619.A10689@ryoko.camperquake.de> On Thu, Jan 13, 2005 at 04:38:25PM +0000, Carlos Rodrigues wrote: > to have a really minimal installation option? I was thinking something > like the base installation of the BSDs. I think this depends on what you define as minimal. A kernel and a statically linked shell would suffice :) From jspaleta at gmail.com Thu Jan 13 16:59:27 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 13 Jan 2005 11:59:27 -0500 Subject: enable tcp_syncookies by default? In-Reply-To: <20050113163619.GA28605@shadow.sumu.org> References: <1105605191.7061.2.camel@marte.biciclete.ro> <604aa79105011308092dd7cfcd@mail.gmail.com> <20050113163619.GA28605@shadow.sumu.org> Message-ID: <604aa791050113085970b09216@mail.gmail.com> On Thu, 13 Jan 2005 18:36:19 +0200, Oskari Saarenmaa wrote: > Note that syncookies are not used until the synqueue is full, so unless the > server is under attack everything proceeds just as it would with syncookies > turned off. They are only enabled when the queue fills up, and in that case > spending a bit more (I don't have any numbers on this) CPU time should be > favourable to not being able to answer incoming requests. Seems reasonable to me. I asked just as a clarification. If your explanation as to when in the process the syncookies have to be dealt with is correct... then the performance tradeoff is a non-issue. Other post(s) have implied there is a cpu hit during non-attacked situations, but if thre isn't then there isnt a concern here. -jef From enrico.scholz at informatik.tu-chemnitz.de Thu Jan 13 17:19:12 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 13 Jan 2005 18:19:12 +0100 Subject: Minimal installation In-Reply-To: <20050113174619.A10689@ryoko.camperquake.de> (Ralf Ertzinger's message of "Thu, 13 Jan 2005 17:46:19 +0100") References: <41E6A401.4020403@mail.telepac.pt> <20050113174619.A10689@ryoko.camperquake.de> Message-ID: <87oeftz1pr.fsf@kosh.ultra.csn.tu-chemnitz.de> fedora-devel at camperquake.de (Ralf Ertzinger) writes: >> to have a really minimal installation option? I was thinking something >> like the base installation of the BSDs. > > I think this depends on what you define as minimal. The programs covered by the Posix Shell and Utilities (XCU) specification[1] plus a few base-utilities like rpm. Unfortunately, the related packages have lots of Requires: so that e.g. a minimal system for FC2 consists of 53 packages with <100 MB (afair). I do not know the numbers for FC3 but the situation becomes worse there since the huge kernel package gets added to the minimal system (in FC2, the kernel was not part of the minimal package set). But there are other packaging errors which bloat the system. E.g. when you install 'gnupg' (required by apt or yum), you have to install perl + openldap (around 50 of unneeded and additional MB). A simple solution would be the splitting of the 'gnupg' package into a core- and an extra-subpackage, but nobody cares about it. > A kernel Yes, the kernel is one of the worst packages in fedora; the headers (20-30 MB of wasted place + 6000 inodes) do not belong in a base package. I hope that this disastrous error will be fixed in FC4. Enrico Footnotes: [1] http://www.opengroup.org/onlinepubs/009695399/utilities/contents.html From mattdm at mattdm.org Thu Jan 13 17:24:33 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 13 Jan 2005 12:24:33 -0500 Subject: Minimal installation In-Reply-To: <41E6A401.4020403@mail.telepac.pt> References: <41E6A401.4020403@mail.telepac.pt> Message-ID: <20050113172433.GA16990@jadzia.bu.edu> On Thu, Jan 13, 2005 at 04:38:25PM +0000, Carlos Rodrigues wrote: > I've tried to do a minimal installation of FC3, only to find that it > really isn't that minimal... So, my suggestion is: would it be possible > to have a really minimal installation option? I was thinking something > like the base installation of the BSDs. Yes, it would be possible. However, there's a significant amount of work involved in determining exactly which packages are required for that. Feel free to hack up a comps file that works to your satisfaction and post it here. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mitr at volny.cz Thu Jan 13 17:25:38 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Thu, 13 Jan 2005 18:25:38 +0100 Subject: Minimal installation In-Reply-To: <87oeftz1pr.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <41E6A401.4020403@mail.telepac.pt> <20050113174619.A10689@ryoko.camperquake.de> <87oeftz1pr.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20050113172535.GB4661@chrys.ms.mff.cuni.cz> On Thu, Jan 13, 2005 at 06:19:12PM +0100, Enrico Scholz wrote: > fedora-devel at camperquake.de (Ralf Ertzinger) writes: > > I think this depends on what you define as minimal. > > The programs covered by the Posix Shell and Utilities (XCU) specification[1] > plus a few base-utilities like rpm. This would include c99, ctags, fort77, lex, pax, strings, uucp, yacc. The "small router" folks might disagree. :) Not to mention things not included in Fedora at all, like SCCS or compress. Mirek From jspaleta at gmail.com Thu Jan 13 17:36:31 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 13 Jan 2005 12:36:31 -0500 Subject: Minimal installation In-Reply-To: <41E6A401.4020403@mail.telepac.pt> References: <41E6A401.4020403@mail.telepac.pt> Message-ID: <604aa79105011309364a965e08@mail.gmail.com> On Thu, 13 Jan 2005 16:38:25 +0000, Carlos Rodrigues wrote: > I've tried to do a minimal installation of FC3, only to find that it > really isn't that minimal... So, my suggestion is: would it be possible > to have a really minimal installation option? I was thinking something > like the base installation of the BSDs. This comes up somewhat frequently. My understanding is that some people in the community have been working on making kickstart files and post-installation instructions to produce more minimal installs. Its a completely valid approach that people can use, and kickstart files provide a range of minimal install targets depending on the dedicate purpose once people are aware of kickstart. But if you want to make the anaconda installer's native concept of minimal more minimal then you have to re-work the comps.xml information that defines the groups anaconda uses. This isn't an unaccomplishable task, and my understanding is the red hat developers who oversee anaconda in fedora are willing to accept reasonable changes to the groupings which make the minimal option more minimal but do not affect the desktop or workstation install. But its going to take some concerted effort and concensous from community who want to see this change. Having everyone interested in making this happen individual offer small changes that the developers have to review is going to burn too much developer time that the developers don't have to spare. The real reason the minimal install option isnt better is more a matter of priorities than complete uninterest. If community members who want to see this changed can work together and provide something concrete for a groups.xml file that can be reviewed, things might actually move forward. What i personally would love to see from community members who are interested in enhancing the minimal install option in anaconda is to start publishing alternative comps.xml files that can be used to generate new iso images that other people in the community can test and try out and then give feedback on. The goal being... to craft a new comps.xml file that ONLY changes the minimal install.. but leaves the rest of anaconda functioning exactly the same. The same desktop and workstation install behavior would absolutely be a must. And keeping the visible groups in custom install the same would be desirable as well. There's no reason why interested community members can't learn how to edit the groups defined in comps.xml and try to do some coherent testing of changes before asking for the changes to be included in fedora. -jef From iago.rubio at hispalinux.es Thu Jan 13 18:31:58 2005 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Thu, 13 Jan 2005 19:31:58 +0100 Subject: enable tcp_syncookies by default? In-Reply-To: <20050113163619.GA28605@shadow.sumu.org> References: <1105605191.7061.2.camel@marte.biciclete.ro> <604aa79105011308092dd7cfcd@mail.gmail.com> <20050113163619.GA28605@shadow.sumu.org> Message-ID: <1105641117.24448.77.camel@speedy.iagorubio.net> On Thu, 2005-01-13 at 17:36, Oskari Saarenmaa wrote: > On Thu, Jan 13, 2005 at 11:09:35AM -0500, Jeff Spaleta wrote: > > How does this scale with network activity and hardware resources? > > Where are the cases where this becomes noticable? > > Note that syncookies are not used until the synqueue is full, so unless the > server is under attack everything proceeds just as it would with syncookies > turned off. They are only enabled when the queue fills up, and in that case > spending a bit more (I don't have any numbers on this) CPU time should be > favourable to not being able to answer incoming requests. Hmmm ... so, Why I used to read things like that ? [quote] syncookies seriously violate TCP protocol, do not allow to use TCP extensions, can result in serious degradation of some services (f.e. SMTP relaying), visible not by you, but your clients and relays, contacting you. [/quote] You can read it with this command on your system: vi +159 `locate ip-sysctl.txt` > I run a fairly busy database-heavy website on a lowend > PC (1.2ghz athlon) It seems "lowend" does not have the same meaning here in Spain :) > that gets around a million hits per day - and also gets SYN flooded every > now and then. After I enabled syncookies on the server it has always > managed to serve all valid requests. > > So.. is there a reason why they are not enabled by default? 1.- Violates TCP protocol 2.- You can't use extensions as T/TCP with syncookies. 3.- Can result in serious degradation of some services. Not my words, it's in the kernel documentation. Cheers. -- Iago Rubio From cmadams at hiwaay.net Thu Jan 13 18:33:43 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 13 Jan 2005 12:33:43 -0600 Subject: Minimal installation In-Reply-To: <20050113172535.GB4661@chrys.ms.mff.cuni.cz> References: <41E6A401.4020403@mail.telepac.pt> <20050113174619.A10689@ryoko.camperquake.de> <87oeftz1pr.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050113172535.GB4661@chrys.ms.mff.cuni.cz> Message-ID: <20050113183343.GE631002@hiwaay.net> Once upon a time, Miloslav Trmac said: > On Thu, Jan 13, 2005 at 06:19:12PM +0100, Enrico Scholz wrote: > > The programs covered by the Posix Shell and Utilities (XCU) specification[1] > > plus a few base-utilities like rpm. > This would include c99, ctags, fort77, lex, pax, strings, uucp, yacc. POSIX Conformance includes c99 as a requirement only with the C-Language Development option (same with some of the others you listed). pax is a good requirement (as it may eventually supersede tar and cpio and should be able to handle both formats). UUCP is an XSI extension as well. Some things get pulled in by LSB compliance as well. redhat-lsb is in base and requires X libraries and something providing /usr/sbin/sendmail (which could be a simple send-only MTA; that is probably a sane requirement). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From iago.rubio at hispalinux.es Thu Jan 13 18:35:54 2005 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Thu, 13 Jan 2005 19:35:54 +0100 Subject: enable tcp_syncookies by default? In-Reply-To: <604aa791050113085970b09216@mail.gmail.com> References: <1105605191.7061.2.camel@marte.biciclete.ro> <604aa79105011308092dd7cfcd@mail.gmail.com> <20050113163619.GA28605@shadow.sumu.org> <604aa791050113085970b09216@mail.gmail.com> Message-ID: <1105641353.24448.86.camel@speedy.iagorubio.net> On Thu, 2005-01-13 at 17:59, Jeff Spaleta wrote: [snip] > Other post(s) have implied there is a cpu hit during non-attacked > situations, but if thre isn't then there isnt a concern here. I suposse you speak about my post :) I'm not a kernel hacker, but I suposse there's a cpu hit when I read in the kernel docs: "(tcpsyncookies) can result in serious degradation of some services (f.e. SMTP relaying)". Cheers. -- Iago Rubio From iago.rubio at hispalinux.es Thu Jan 13 19:00:28 2005 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Thu, 13 Jan 2005 20:00:28 +0100 Subject: enable tcp_syncookies by default? In-Reply-To: References: <1105605191.7061.2.camel@marte.biciclete.ro> <1105625105.19764.23.camel@speedy.iagorubio.net> Message-ID: <1105642827.24448.113.camel@speedy.iagorubio.net> On Thu, 2005-01-13 at 16:48, Pekka Savola wrote: > On Thu, 13 Jan 2005, Iago Rubio wrote: > > Default settings should be for the most common configuration, > > By that logic, syn cookies should be enabled. > > It's 2005. Computers are connected to the net, period. Yes, I know. I've got right now 5 computers connected to the net around me, 8 computers in my home LAN. None of them can be target of syn floods from Internet. As I'm sure you now, one computer can access the net without been facing it. A route from your lan to Internet does not make your machine a target of syn flood attacks. >From a desktop user's prespective, with no server running, syncookies have nothing to do enabled, as you need at least one open port to trigger a syn flood. Computers connected to Internet, does not mean computers target of syn floods at all. Only servers connected to Internet have this risk. > It's better to err in the side of caution, you know. I agree with you. But ITOH I'm not sure to ship a broken TCP implementation by default should be a great idea, even while this broken implementation can help during a syn flood attack - but not solve it. It will also break TCP extensions as T/TCP. In fact, against a serious syn flood there's nothing your box can do, even with syncookies enabled. You will end loosing legitimate connections. Regards. -- Iago Rubio From alan at redhat.com Thu Jan 13 19:13:29 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 13 Jan 2005 14:13:29 -0500 Subject: enable tcp_syncookies by default? In-Reply-To: <1105641117.24448.77.camel@speedy.iagorubio.net> References: <1105605191.7061.2.camel@marte.biciclete.ro> <604aa79105011308092dd7cfcd@mail.gmail.com> <20050113163619.GA28605@shadow.sumu.org> <1105641117.24448.77.camel@speedy.iagorubio.net> Message-ID: <20050113191329.GA12343@devserv.devel.redhat.com> On Thu, Jan 13, 2005 at 07:31:58PM +0100, Iago Rubio wrote: > [quote] > syncookies seriously violate TCP protocol, do not allow to use TCP > extensions, can result in serious degradation of some services (f.e. > SMTP relaying), visible not by you, but your clients and relays, > contacting you. > [/quote] The protocol violation claim is IMHO garbage. Most of the reason syn cookies are not used under high load by default is because they were invented by Dan Bernstein. The extensions are problematic but this kicks in mostly at the point where things are not working full stop. There are some things it does confuse a little - programs expecting that the server will intentionally ignore and not make connections when busy for example. > 2.- You can't use extensions as T/TCP with syncookies. T/TCP is an experiment that is dead, it also violates the TCP specification and turned out to have security issues. So T/TCP is dead. OTOH under load you do lose SACK, FACK, PAWS, large windows and some other really useful features. From os at sumu.org Thu Jan 13 19:20:23 2005 From: os at sumu.org (Oskari Saarenmaa) Date: Thu, 13 Jan 2005 21:20:23 +0200 Subject: enable tcp_syncookies by default? In-Reply-To: <1105642827.24448.113.camel@speedy.iagorubio.net> References: <1105605191.7061.2.camel@marte.biciclete.ro> <1105625105.19764.23.camel@speedy.iagorubio.net> <1105642827.24448.113.camel@speedy.iagorubio.net> Message-ID: <20050113192023.GA30046@shadow.sumu.org> On Thu, Jan 13, 2005 at 08:00:28PM +0100, Iago Rubio wrote: > But ITOH I'm not sure to ship a broken TCP implementation by default > should be a great idea, even while this broken implementation can help > during a syn flood attack - but not solve it. > > It will also break TCP extensions as T/TCP. > > In fact, against a serious syn flood there's nothing your box can do, > even with syncookies enabled. > > You will end loosing legitimate connections. SYN cookies will not be used unless the SYN queue is full, if the queue is full the connection would be dropped if SYN cookies are not enabled. Using cookies lets you serve the majority of clients instead of none at all. The document you quoted says that SYN cookies should not be as a fallback facility when legitimate traffic is overwhelming the server. >From linux 2.4.24 net/ipv/tcp_ipv4.c: 1417 if (tcp_synq_is_full(sk) && !isn) { 1418 #ifdef CONFIG_SYN_COOKIES 1419 if (sysctl_tcp_syncookies) { 1420 want_cookie = 1; 1421 } else 1422 #endif 1423 goto drop; 1424 } Cheers, Oskari From carlos.efr at mail.telepac.pt Thu Jan 13 18:20:18 2005 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Thu, 13 Jan 2005 18:20:18 +0000 Subject: Minimal installation In-Reply-To: <20050113174619.A10689@ryoko.camperquake.de> References: <41E6A401.4020403@mail.telepac.pt> <20050113174619.A10689@ryoko.camperquake.de> Message-ID: <41E6BBE2.1040700@mail.telepac.pt> Ralf Ertzinger wrote: > On Thu, Jan 13, 2005 at 04:38:25PM +0000, Carlos Rodrigues wrote: > > >>to have a really minimal installation option? I was thinking something >>like the base installation of the BSDs. > > > I think this depends on what you define as minimal. > A kernel and a statically linked shell would suffice :) > That would be way too minimal :) What I define as minimal is something that only contains the base of a working system not intended for any specific purpose, providing a minimal compile environment (gcc + glibc-devel + g++ maybe) and network connectivity (xinetd, dhcp client), plus a way to pull other packages into the system (rpm + yum). The diskspace necessary shouldn't go too much beyond 300Mb. Right now, a minimal system gives us too much cruft, and forces the "rpm -e" of quite a few packages. I guess a rule of thumb should be "if there is a significant amount of people out there that would remove this package upon installation, then it isn't minimal". Of course there is an amount of common sense here, there are some packages that I could remove from my system, but don't bother me much if I don't. I'm not trying to suggest a "10Mb Fedora install" here. ;) Carlos Rodrigues PS: like I said, this is just like the BSDs base install. PS2: BTW, can someone point me to some of the somewhere else mentioned kickstart files for doing this? (If they aren't easily googlable) -- url: http://tudo-sobre-nada.blogspot.com From daly at rio.sci.ccny.cuny.edu Thu Jan 13 17:43:40 2005 From: daly at rio.sci.ccny.cuny.edu (daly at rio.sci.ccny.cuny.edu) Date: Thu, 13 Jan 2005 12:43:40 -0500 Subject: FC1 vs FC2 vs FC3 Message-ID: <200501131743.MAA31435@springbok.sci.ccny.cuny.edu> Is there a reliable way to know what version of Fedora Core is running? I need to write a shell script to distinguish the cases. uname does not seem to provide this information in a form I can use. Tim From rdieter at math.unl.edu Thu Jan 13 20:13:47 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 13 Jan 2005 14:13:47 -0600 Subject: FC1 vs FC2 vs FC3 In-Reply-To: <200501131743.MAA31435@springbok.sci.ccny.cuny.edu> References: <200501131743.MAA31435@springbok.sci.ccny.cuny.edu> Message-ID: <41E6D67B.9090709@math.unl.edu> daly at rio.sci.ccny.cuny.edu wrote: > Is there a reliable way to know what version of Fedora Core is running? > I need to write a shell script to distinguish the cases. > uname does not seem to provide this information in a form I can use. Parse /etc/redhat-release -- Rex From cpedersen at c-note.dk Thu Jan 13 20:15:23 2005 From: cpedersen at c-note.dk (Casper Pedersen) Date: Thu, 13 Jan 2005 21:15:23 +0100 Subject: FC1 vs FC2 vs FC3 In-Reply-To: <200501131743.MAA31435@springbok.sci.ccny.cuny.edu> References: <200501131743.MAA31435@springbok.sci.ccny.cuny.edu> Message-ID: <41E6D6DB.3060306@c-note.dk> daly at rio.sci.ccny.cuny.edu wrote: >Is there a reliable way to know what version of Fedora Core is running? >I need to write a shell script to distinguish the cases. >uname does not seem to provide this information in a form I can use. > >Tim > > > cat /etc/redhat-release Fedora Core release 3 (Heidelberg) or rpm -qf /etc/redhat-release fedora-release-3-8 Regards/Casper -- GPG Public key is available from: http://www.keyserver.net/ Fingerprint = 56ED 74A4 7B00 20E2 B493 0C1A 6B4E BF8F A086 FE57 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From skvidal at phy.duke.edu Thu Jan 13 20:17:58 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 13 Jan 2005 15:17:58 -0500 Subject: FC1 vs FC2 vs FC3 In-Reply-To: <41E6D67B.9090709@math.unl.edu> References: <200501131743.MAA31435@springbok.sci.ccny.cuny.edu> <41E6D67B.9090709@math.unl.edu> Message-ID: <1105647478.1597.9.camel@opus.phy.duke.edu> On Thu, 2005-01-13 at 14:13 -0600, Rex Dieter wrote: > daly at rio.sci.ccny.cuny.edu wrote: > > Is there a reliable way to know what version of Fedora Core is running? > > I need to write a shell script to distinguish the cases. > > uname does not seem to provide this information in a form I can use. > > Parse /etc/redhat-release > rpm -q fedora-release -sv From fedora-devel at tlarson.com Thu Jan 13 20:20:47 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Thu, 13 Jan 2005 13:20:47 -0700 Subject: FC1 vs FC2 vs FC3 In-Reply-To: <200501131743.MAA31435@springbok.sci.ccny.cuny.edu> References: <200501131743.MAA31435@springbok.sci.ccny.cuny.edu> Message-ID: <41E6D81F.7010809@tlarson.com> daly at rio.sci.ccny.cuny.edu wrote: > Is there a reliable way to know what version of Fedora Core is running? > I need to write a shell script to distinguish the cases. > uname does not seem to provide this information in a form I can use. > > Tim > cat /etc/redhat-release 'course, then you start running into various definitions of "reliable" -- which usually stem from differences in the definition of the word "version." I've run across machines that have most of the software normally found on, for example, redhat 7.3, but claim to be running 7.1. Such boxes are usually installed with one operating system release, but gradually upgraded to keep up with later releases, though never officially installing or upgrading to the newest release. You'll have better luck checking the version of the particular package(s) you're interested in interacting with, in most cases. From nbargnesi at gmail.com Thu Jan 13 20:20:56 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Thu, 13 Jan 2005 15:20:56 -0500 Subject: FC1 vs FC2 vs FC3 In-Reply-To: <1105647478.1597.9.camel@opus.phy.duke.edu> References: <200501131743.MAA31435@springbok.sci.ccny.cuny.edu> <41E6D67B.9090709@math.unl.edu> <1105647478.1597.9.camel@opus.phy.duke.edu> Message-ID: <3077b8a005011312205d544dd0@mail.gmail.com> On Thu, 13 Jan 2005 15:17:58 -0500, seth vidal wrote: > On Thu, 2005-01-13 at 14:13 -0600, Rex Dieter wrote: > > daly at rio.sci.ccny.cuny.edu wrote: > > > Is there a reliable way to know what version of Fedora Core is running? > > > I need to write a shell script to distinguish the cases. > > > uname does not seem to provide this information in a form I can use. > > > > Parse /etc/redhat-release > > > > rpm -q fedora-release > > -sv cat /etc/fedora-release | cut -d ' ' -f4 > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From peter.backlund at home.se Thu Jan 13 20:33:41 2005 From: peter.backlund at home.se (Peter Backlund) Date: Thu, 13 Jan 2005 21:33:41 +0100 Subject: FC1 vs FC2 vs FC3 In-Reply-To: <1105647478.1597.9.camel@opus.phy.duke.edu> References: <200501131743.MAA31435@springbok.sci.ccny.cuny.edu> <41E6D67B.9090709@math.unl.edu> <1105647478.1597.9.camel@opus.phy.duke.edu> Message-ID: <1105648421.6962.4.camel@localhost.localdomain> tor 2005-01-13 klockan 15:17 -0500 skrev seth vidal: > On Thu, 2005-01-13 at 14:13 -0600, Rex Dieter wrote: > > daly at rio.sci.ccny.cuny.edu wrote: > > > Is there a reliable way to know what version of Fedora Core is running? > > > I need to write a shell script to distinguish the cases. > > > uname does not seem to provide this information in a form I can use. > > > > Parse /etc/redhat-release > > > > rpm -q fedora-release rpm -q --qf "%{version}\n" fedora-release should be water-proof :-) /Peter From fs111 at web.de Thu Jan 13 20:55:26 2005 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9?= Kelpe) Date: Thu, 13 Jan 2005 21:55:26 +0100 Subject: FC1 vs FC2 vs FC3 In-Reply-To: <3077b8a005011312205d544dd0@mail.gmail.com> References: <200501131743.MAA31435@springbok.sci.ccny.cuny.edu> <41E6D67B.9090709@math.unl.edu> <1105647478.1597.9.camel@opus.phy.duke.edu> <3077b8a005011312205d544dd0@mail.gmail.com> Message-ID: <1105649725.8667.14.camel@localhost> Am Do, den 13.01.2005 schrieb Nick Bargnesi um 21:20: > cat /etc/fedora-release | cut -d ' ' -f4 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Useless use of cat and pipe :-P cut -d ' ' -f4 /etc/fedora-release Andr? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From i at stingr.net Thu Jan 13 21:09:56 2005 From: i at stingr.net (Paul P Komkoff Jr) Date: Fri, 14 Jan 2005 00:09:56 +0300 Subject: Minimal installation In-Reply-To: <41E6A401.4020403@mail.telepac.pt> References: <41E6A401.4020403@mail.telepac.pt> Message-ID: <20050113210956.GB13996@stingr.sgu.ru> Replying to Carlos Rodrigues: > I've tried to do a minimal installation of FC3, only to find that it > really isn't that minimal... So, my suggestion is: would it be possible What annoys me most - is x11 libraries in minimal install. But they are there by purpose - some another package requires it. But, anyway, this isn't "minimal install - suitable for small routers" anymore. -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From nutello at sweetness.com Thu Jan 13 21:37:09 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Thu, 13 Jan 2005 22:37:09 +0100 Subject: FC1 vs FC2 vs FC3 In-Reply-To: <1105649725.8667.14.camel@localhost> References: <200501131743.MAA31435@springbok.sci.ccny.cuny.edu> <41E6D67B.9090709@math.unl.edu> <1105647478.1597.9.camel@opus.phy.duke.edu> <3077b8a005011312205d544dd0@mail.gmail.com> <1105649725.8667.14.camel@localhost> Message-ID: <20050113213708.GB5200@plain.rackshack.net> On Thu, Jan 13, 2005 at 09:55:26PM +0100, Andr? Kelpe wrote: > cut -d ' ' -f4 /etc/fedora-release Needless use of an external binary! With bash: VER=($(< /etc/fedora-release)) You can now just use array element VER[3]: echo ${VER[3]} or VER=${VER[3]} -- Rudi From feliciano.matias at free.fr Thu Jan 13 21:38:19 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 13 Jan 2005 22:38:19 +0100 Subject: Yum remove openoffice.org-libs ... Problem Message-ID: <1105652299.8920.55.camel@one.myworld> [root at one ~]# rpm -q -a | grep -i openoffice openoffice.org-i18n-1.1.2-11.5.fc3 openoffice.org-1.1.2-11.5.fc3 openoffice.org-libs-1.1.2-11.5.fc3 [root at one ~]# rpm -e --test openoffice.org-libs erreur: D?pendances requises: libcomphelp3gcc3.so est n?cessaire pour (d?j? install?) openoffice.org-1.1.2-11.5.fc3.i386 (...) [root at one ~]# rpm -e --test openoffice.org erreur: D?pendances requises: openoffice.org = 1.1.2-11.5.fc3 est n?cessaire pour (d?j? install?) openoffice.org-i18n-1.1.2-11.5.fc3.i386 openoffice.org = 1.1.2-11.5.fc3 est n?cessaire pour (d?j? install?) openoffice.org-libs-1.1.2-11.5.fc3.i386 So, removing openoffice.org-libs will remove openoffice.org and openoffice.org-i18n . [root at one ~]# yum remove openoffice.org-libs Setting up Remove Process Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package openoffice.org-libs.i386 0:1.1.2-11.5.fc3 set to be erased --> Running transaction check Setting up Repo: updates-testing repomd.xml 100% |=========================| 951 B 00:00 Setting up Repo: Base repomd.xml 100% |=========================| 1.1 kB 00:00 Setting up Repo: updates repomd.xml 100% |=========================| 951 B 00:00 Reading repository metadata in from local files primary.xml.gz 100% |=========================| 6.5 kB 00:00 MD Read : ################################################## 12/12 updates-te: ################################################## 12/12 primary.xml.gz 100% |=========================| 619 kB 00:00 MD Read : ################################################## 1653/1653 Base : ################################################## 1652/1652 primary.xml.gz 100% |=========================| 182 kB 00:00 MD Read : ################################################## 361/361 updates : ################################################## 361/361 --> Processing Dependency: openoffice.org-libs = 1.1.2-11.5.fc3 for package: openoffice.org --> Processing Dependency: libsb645li.so for package: openoffice.org --> Processing Dependency: libsvl645li.so for package: openoffice.org --> Processing Dependency: libucbhelper2gcc3.so for package: openoffice.org --> Processing Dependency: libsal.so.3(UDK_3.1) for package: openoffice.org --> Processing Dependency: libcppuhelpergcc3.so.3 for package: openoffice.org --> Processing Dependency: libtl645li.so for package: openoffice.org --> Processing Dependency: libspa645li.so for package: openoffice.org --> Processing Dependency: libutl645li.so for package: openoffice.org --> Processing Dependency: libcppuhelpergcc3.so.3(UDK_3_0_0) for package: openoffice.org --> Processing Dependency: libpkgchk645li.so for package: openoffice.org --> Processing Dependency: libvcl645li.so for package: openoffice.org --> Processing Dependency: libstlport_gcc.so for package: openoffice.org --> Processing Dependency: libset645li.so for package: openoffice.org --> Processing Dependency: libvos3gcc3.so for package: openoffice.org --> Processing Dependency: libfile645li.so for package: openoffice.org --> Processing Dependency: libdbtools2.so for package: openoffice.org --> Processing Dependency: libsal.so.3 for package: openoffice.org --> Processing Dependency: libcppu.so.3(UDK_3_0_0) for package: openoffice.org --> Processing Dependency: libsvt645li.so for package: openoffice.org --> Processing Dependency: libsal.so.3(UDK_3_0_0) for package: openoffice.org --> Processing Dependency: libtk645li.so for package: openoffice.org --> Processing Dependency: libcppu.so.3 for package: openoffice.org --> Processing Dependency: libsot645li.so for package: openoffice.org --> Processing Dependency: libsalhelpergcc3.so.3 for package: openoffice.org --> Processing Dependency: libcomphelp3gcc3.so for package: openoffice.org --> Processing Dependency: libvclplug_gen645li.so for package: openoffice.org --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package openoffice.org.i386 0:1.1.2-11.5.fc3 set to be erased ---> Package openoffice.org-libs.i386 0:1.1.2-10 set to be updated <============ --> Running transaction check --> Processing Dependency: openoffice.org = 1.1.2-10 for package: openoffice.org-libs <============ --> Processing Dependency: openoffice.org = 1.1.2-11.5.fc3 for package: openoffice.org-i18n --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package openoffice.org.i386 0:1.1.2-10 set to be updated <============ ---> Package openoffice.org-i18n.i386 0:1.1.2-11.5.fc3 set to be erased --> Running transaction check Dependencies Resolved Transaction Listing: Remove: openoffice.org-libs.i386 0:1.1.2-11.5.fc3 Performing the following to resolve dependencies: Remove: openoffice.org.i386 0:1.1.2-11.5.fc3 Remove: openoffice.org-i18n.i386 0:1.1.2-11.5.fc3 Update: openoffice.org.i386 0:1.1.2-10 <============ Update: openoffice.org-libs.i386 0:1.1.2-10 <============ Is this ok [y/N]: y Downloading Packages: Running Transaction Test Finished Transaction Test Transaction Check Error: package openoffice.org-libs-1.1.2-11.5.fc3 (which is newer than openoffice.org-libs-1.1.2-10) is already installed package openoffice.org-1.1.2-11.5.fc3 (which is newer than openoffice.org-1.1.2-10) is already installed Any thought ? yum-2.1.12-0.fc3 Ok, not really relevant to fedora-devel-list but Rawhide use quite the same version. Bugzilla ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Thu Jan 13 21:43:26 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 13 Jan 2005 16:43:26 -0500 Subject: Yum remove openoffice.org-libs ... Problem In-Reply-To: <1105652299.8920.55.camel@one.myworld> References: <1105652299.8920.55.camel@one.myworld> Message-ID: <1105652606.1597.34.camel@opus.phy.duke.edu> > So, removing openoffice.org-libs will remove openoffice.org and openoffice.org-i18n . > > yum-2.1.12-0.fc3 > Ok, not really relevant to fedora-devel-list but Rawhide use quite the same version. > Yah - a few thoughts. What's happening is yum is not following the dep resolution for the erasure out in the right direction for that package. I'll take a look on my own machines b/c I should be able to replicate it. Can you open a bug w/that content? Thanks, -sv From dcbw at redhat.com Thu Jan 13 21:43:49 2005 From: dcbw at redhat.com (Dan Williams) Date: Thu, 13 Jan 2005 16:43:49 -0500 Subject: Yum remove openoffice.org-libs ... Problem In-Reply-To: <1105652299.8920.55.camel@one.myworld> References: <1105652299.8920.55.camel@one.myworld> Message-ID: <1105652629.28097.0.camel@dcbw.boston.redhat.com> On Thu, 2005-01-13 at 22:38 +0100, F?liciano Matias wrote: > Performing the following to resolve dependencies: > Remove: openoffice.org.i386 0:1.1.2-11.5.fc3 > Remove: openoffice.org-i18n.i386 0:1.1.2-11.5.fc3 > Update: openoffice.org.i386 0:1.1.2-10 <============ > Update: openoffice.org-libs.i386 0:1.1.2-10 <============ > Is this ok [y/N]: y > Downloading Packages: > Running Transaction Test > Finished Transaction Test > Transaction Check Error: package openoffice.org-libs-1.1.2-11.5.fc3 (which is newer than openoffice.org-libs-1.1.2-10) is already installed > package openoffice.org-1.1.2-11.5.fc3 (which is newer than openoffice.org-1.1.2-10) is already installed Looks like a yum problem, not an OOo one... Do you really have both versions of OOo installed? rpm -qa |grep openoffice.org will tell you. Dan From feliciano.matias at free.fr Thu Jan 13 21:45:21 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 13 Jan 2005 22:45:21 +0100 Subject: Yum remove openoffice.org-libs ... Problem In-Reply-To: <1105652299.8920.55.camel@one.myworld> References: <1105652299.8920.55.camel@one.myworld> Message-ID: <1105652721.8920.57.camel@one.myworld> Le jeudi 13 janvier 2005 ? 22:38 +0100, F?liciano Matias a ?crit : > Bugzilla ? Perhaps the same bug than this one : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144376 I use a i386 system (not x86_64). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Thu Jan 13 21:47:59 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 13 Jan 2005 16:47:59 -0500 Subject: Yum remove openoffice.org-libs ... Problem In-Reply-To: <1105652721.8920.57.camel@one.myworld> References: <1105652299.8920.55.camel@one.myworld> <1105652721.8920.57.camel@one.myworld> Message-ID: <1105652879.1597.37.camel@opus.phy.duke.edu> On Thu, 2005-01-13 at 22:45 +0100, F?liciano Matias wrote: > Le jeudi 13 janvier 2005 ? 22:38 +0100, F?liciano Matias a ?crit : > > Bugzilla ? > > Perhaps the same bug than this one : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144376 > > I use a i386 system (not x86_64). No - it's not quite the same - but possibly related. It's almost entirely tied up in the depresolution and how it's looking at the transaction info. -sv From feliciano.matias at free.fr Thu Jan 13 21:55:34 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 13 Jan 2005 22:55:34 +0100 Subject: Yum remove openoffice.org-libs ... Problem In-Reply-To: <1105652629.28097.0.camel@dcbw.boston.redhat.com> References: <1105652299.8920.55.camel@one.myworld> <1105652629.28097.0.camel@dcbw.boston.redhat.com> Message-ID: <1105653334.8920.62.camel@one.myworld> Le jeudi 13 janvier 2005 ? 16:43 -0500, Dan Williams a ?crit : > Looks like a yum problem, not an OOo one... Do you really have both > versions of OOo installed? No. > rpm -qa |grep openoffice.org > > will tell you. Check the top of my previous mail : [root at one ~]# rpm -q -a | grep -i openoffice openoffice.org-i18n-1.1.2-11.5.fc3 openoffice.org-1.1.2-11.5.fc3 openoffice.org-libs-1.1.2-11.5.fc3 "rpm -e openoffice.org-i18n openoffice.org openoffice.org-libs" works as expected. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From feliciano.matias at free.fr Thu Jan 13 22:20:09 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 13 Jan 2005 23:20:09 +0100 Subject: Yum remove openoffice.org-libs ... Problem In-Reply-To: <1105652606.1597.34.camel@opus.phy.duke.edu> References: <1105652299.8920.55.camel@one.myworld> <1105652606.1597.34.camel@opus.phy.duke.edu> Message-ID: <1105654809.8920.65.camel@one.myworld> Le jeudi 13 janvier 2005 ? 16:43 -0500, seth vidal a ?crit : > Can you open a bug w/that content? I am not able to create a new bug in bugzilla.redhat.com. When I click on "Open bugzilla entry form" I get an empty page. So, added the bug to linux.duke.edu bugzilla : https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=386 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Thu Jan 13 22:30:59 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 13 Jan 2005 17:30:59 -0500 Subject: Yum remove openoffice.org-libs ... Problem In-Reply-To: <1105654809.8920.65.camel@one.myworld> References: <1105652299.8920.55.camel@one.myworld> <1105652606.1597.34.camel@opus.phy.duke.edu> <1105654809.8920.65.camel@one.myworld> Message-ID: <1105655459.1597.44.camel@opus.phy.duke.edu> On Thu, 2005-01-13 at 23:20 +0100, F?liciano Matias wrote: > Le jeudi 13 janvier 2005 ? 16:43 -0500, seth vidal a ?crit : > > Can you open a bug w/that content? > > I am not able to create a new bug in bugzilla.redhat.com. When I click > on "Open bugzilla entry form" I get an empty page. > So, added the bug to linux.duke.edu bugzilla : > https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=386 Thanks, -sv From michael.favia at insitesinc.com Thu Jan 13 23:59:00 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 13 Jan 2005 17:59:00 -0600 Subject: mod_dav_svn update In-Reply-To: <1105613912.8286.20.camel@one.myworld> References: <1105535367.28147.14.camel@one.myworld> <20050112151332.GA18514@redhat.com> <1105543993.31987.8.camel@one.myworld> <20050113100532.GA11733@redhat.com> <1105613912.8286.20.camel@one.myworld> Message-ID: <41E70B44.8070909@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 F?liciano Matias wrote: | Le jeudi 13 janvier 2005 ? 10:05 +0000, Joe Orton a ?crit : | |>On Wed, Jan 12, 2005 at 04:33:13PM +0100, F?liciano Matias wrote: |> |>>Is this a bug ? |>>$ rpm -q --scripts bind |>>postuninstall scriptlet (using /bin/sh): |>>if [ "$1" -ge 1 ]; then |>> /etc/rc.d/init.d/named condrestart >/dev/null 2>&1 || : |>>fi |> |>I'd say it depends on the daemon, for some it could be necessary. But |>for any network-facing daemon I would say that it's surprising and |>undesirable behaviour if a package update breaks active client |>connections etc. Making configuration changes take effect from a %post |>is unfriendly; especially if the config is not marked noreplace. |> | | | When I update my system, the propose is to use the new version (security | fix, ...). Perhaps it's better to schedule an update at midnight than | when there is a rush of connection. It's up to the administrator to | decide when and how to update his system. | If daemons are not restarted when I update a system then when this | append ? | Do you ask me to always reboot my computer after "yum update" ? Too bad. | Suppose I update httpd and httpd is not restarted. One week later the | server is restarted (power failure), the new httpd does not start and | "bad luck" I am in holidays... | | What do you think about this scenario ? | | btw, "service httpd reload" (or condreload) is not enough alter an | update ? | I was thinking about this the other day in fact and i had a couple of questions. First off i agree that the daemon should be restarted or at least be offered (see discussion below) to be restarted during the installation of an updated package. I was wondering how the rpm process is exposed to agents that use it (e.g. yum, apt). Do yum and apt simply parse standard output from rpm or is there some sort of sane notification method they are using to drive an event (via rpmlibs or somesuch)? Along this same issue packages like mplayer plugin "require" mozilla's rpm to be installed when in fact firefox works just fine as well. Is there any normal way for the packager to specify that either firefox or mozilla should be installed (but not necessarily both). I recognize that this could cause some issues with dep resolution (e.g. prompting on which to include in dep inclusion if neither is installed) which is why i asked the earlier question that refers to how yum and apt communicate with rpm (or possibly rpmlibs?). If these are total non-issues forgive me and ignore the post but i have run into CLI output a number of times while running various GUI's provided with fedora (rhgb, gyum, synaptic). This makes them seem like simple wrappers simple interpreters (that fail on abnormal behavior or output) to the CLI versions instead of integrated alternative views based on event driven architectures. - -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB5wtEBVsNYjF2rDYRAqXVAJ4sH4wdXlzH/gjWK2c91bqhY1BmcQCfX7Pl ekdTd8S7tVb8CEfw9bmNLj8= =e77e -----END PGP SIGNATURE----- From mpeters at mac.com Fri Jan 14 00:03:44 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 14 Jan 2005 00:03:44 +0000 Subject: Pre-Extras apt'able? In-Reply-To: <41E69F94.3010008@math.unl.edu> (from rdieter@math.unl.edu on Thu Jan 13 08:19:32 2005) References: <41E537F2.4080505@math.unl.edu> <41E644B9.2040303@redhat.com> <1105615529.8286.24.camel@one.myworld> <1105632764.2647.0.camel@localhost.localdomain> <41E69EE1.5080708@math.unl.edu> <41E69F94.3010008@math.unl.edu> Message-ID: <1105661024l.6511l.2l@devel.mpeters.us> On 01/13/2005 08:19:32 AM, Rex Dieter wrote: > Rex Dieter wrote: >> Kyrre Ness Sjobak wrote: >> >>> BTW - why does livna recomend you to put in all of their repos - >>> including "unstable" og "testing"? >> >> >> AFAIK, livna does no such thing. ?? > > http://rpm.livna.org/configuration.html > Oops, I stand corrected. Their default apt config *does* include > testing and unstable. > > Ack, I hope it's a simple oversight/mistake on their part. I recommend using testing and unstable from livna. There are some libraries in testing and unstable that are not in stable, that doesn't necessarily mean they don't work well enough - faad2 in my experience does work well, for example. faad2 is a library for aac decoding, needed for the gstreamer plugin for aac playback in totem, or for the xmms plugin for aac playback in xmms. mjpegtools is another library in unstable - works fairly well for me, I have come across mpeg files that will not properly play with software that uses mjpegtools in the past, maybe that's why it is in unstable - but it works for vast majority of the ones I have come across. From ml at elf.no-ip.org Fri Jan 14 01:57:07 2005 From: ml at elf.no-ip.org (Tadashi Jokagi) Date: Fri, 14 Jan 2005 10:57:07 +0900 Subject: Where is the newest rpm? Message-ID: <41e726f3.6942%ml@elf.no-ip.org> Hi, I went into the associate of a translation project. Translation of rpm can be performed in a translation project. http://www.iro.umontreal.ca/translation/registry.cgi?domain=index However, there is a question. I feel that rpm of a translation project is old. RPM of Fedora Project is a version 4.3.3. However, I cannot find formal URL of 4.3.3. Isn't 4.3.3 of rpm formal? I asked a question by rpm-list. However, a reply was not able to be obtained at all. thanks, -- ----.----1----.----2----.----3----.----4----.----5----.----6----.----7 Tadashi Jokagi/Shibuya city mailto:elf at elf.no-ip.org Fedora JP Project http://fedora.jp/ Fedora Project http://fedora.redhat.com/ Fedora and Red Hat are registered trademarks of Red Hat Inc. From mpeters at mac.com Fri Jan 14 02:38:38 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 14 Jan 2005 02:38:38 +0000 Subject: FC1 vs FC2 vs FC3 In-Reply-To: <20050113213708.GB5200@plain.rackshack.net> (from nutello@sweetness.com on Thu Jan 13 13:37:09 2005) References: <200501131743.MAA31435@springbok.sci.ccny.cuny.edu> <41E6D67B.9090709@math.unl.edu> <1105647478.1597.9.camel@opus.phy.duke.edu> <3077b8a005011312205d544dd0@mail.gmail.com> <1105649725.8667.14.camel@localhost> <20050113213708.GB5200@plain.rackshack.net> Message-ID: <1105670318l.6511l.5l@devel.mpeters.us> On 01/13/2005 01:37:09 PM, Rudi Chiarito wrote: > On Thu, Jan 13, 2005 at 09:55:26PM +0100, Andr? Kelpe wrote: > > cut -d ' ' -f4 /etc/fedora-release > > Needless use of an external binary! > With bash: > > VER=($(< /etc/fedora-release)) > > You can now just use array element VER[3]: > > echo ${VER[3]} > > or > > VER=${VER[3]} > > -- > Rudi > That should be ported to c for performance. ;) From daly at rio.sci.ccny.cuny.edu Fri Jan 14 02:16:25 2005 From: daly at rio.sci.ccny.cuny.edu (Tim Daly) Date: Thu, 13 Jan 2005 21:16:25 -0500 Subject: FC1 vs FC2 vs FC3 In-Reply-To: <1105670318l.6511l.5l@devel.mpeters.us> References: <200501131743.MAA31435@springbok.sci.ccny.cuny.edu> <41E6D67B.9090709@math.unl.edu> <1105647478.1597.9.camel@opus.phy.duke.edu> <3077b8a005011312205d544dd0@mail.gmail.com> <1105649725.8667.14.camel@localhost> <20050113213708.GB5200@plain.rackshack.net> <1105670318l.6511l.5l@devel.mpeters.us> Message-ID: <200501140216.VAA32157@springbok.sci.ccny.cuny.edu> can't i just read it out of /proc/kcore? cheese, ask a simple question, get an education.... :-) From ville.skytta at iki.fi Fri Jan 14 07:36:21 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Fri, 14 Jan 2005 09:36:21 +0200 Subject: mod_dav_svn update In-Reply-To: <41E70B44.8070909@insitesinc.com> References: <1105535367.28147.14.camel@one.myworld> <20050112151332.GA18514@redhat.com> <1105543993.31987.8.camel@one.myworld> <20050113100532.GA11733@redhat.com> <1105613912.8286.20.camel@one.myworld> <41E70B44.8070909@insitesinc.com> Message-ID: <1105688181.23430.5.camel@bobcat.mine.nu> On Thu, 2005-01-13 at 17:59 -0600, Michael Favia wrote: > Along this same issue packages like mplayer plugin "require" mozilla's > rpm to be installed when in fact firefox works just fine as well. Is > there any normal way for the packager to specify that either firefox or > mozilla should be installed (but not necessarily both). For plugin packages eg.: Requires: %{_libdir}/mozilla/plugins kdebase (~ Konqueror), firefox and mozilla own that directory and so satisfy the dependency. (HelixPlayer in FC3 owns it too; that has been fixed in Rawhide). From symbiont at berlios.de Fri Jan 14 12:32:40 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Fri, 14 Jan 2005 20:32:40 +0800 Subject: FC1 vs FC2 vs FC3 In-Reply-To: <200501140216.VAA32157@springbok.sci.ccny.cuny.edu> References: <200501131743.MAA31435@springbok.sci.ccny.cuny.edu> <1105670318l.6511l.5l@devel.mpeters.us> <200501140216.VAA32157@springbok.sci.ccny.cuny.edu> Message-ID: <200501142032.40485.symbiont@berlios.de> On Friday 14 January 2005 10:16, Tim Daly wrote: > cheese, ask a simple question, get an education.... :-) Want another fun way? $ lsb_release -rs 3 Of course, this requires the redhat-lsb package. enjoy, -- -jeff From pedro.lamarao at mndfck.org Fri Jan 14 13:04:27 2005 From: pedro.lamarao at mndfck.org (=?ISO-8859-1?Q?Pedro_Lamar=E3o?=) Date: Fri, 14 Jan 2005 11:04:27 -0200 Subject: mod_dav_svn update In-Reply-To: <1105613912.8286.20.camel@one.myworld> References: <1105535367.28147.14.camel@one.myworld> <20050112151332.GA18514@redhat.com> <1105543993.31987.8.camel@one.myworld> <20050113100532.GA11733@redhat.com> <1105613912.8286.20.camel@one.myworld> Message-ID: <41E7C35B.1060007@mndfck.org> F?liciano Matias wrote: >When I update my system, the propose is to use the new version (security >fix, ...). Perhaps it's better to schedule an update at midnight than >when there is a rush of connection. It's up to the administrator to >decide when and how to update his system. >If daemons are not restarted when I update a system then when this >append ? >Do you ask me to always reboot my computer after "yum update" ? Too bad. >Suppose I update httpd and httpd is not restarted. One week later the >server is restarted (power failure), the new httpd does not start and >"bad luck" I am in holidays... > >What do you think about this scenario ? > >btw, "service httpd reload" (or condreload) is not enough alter an >update ? > > "service httpd reload" is enough for reloading the configuration files. httpd can do this while already loaded into memory. Observe we are in a thread about a mod_dav_svn update. That is *not* a configuration file. Reloading a module requires "service httpd restart". Joe, what about a system variable somewhere that would flag if the administrator wants an RPM update to restart the relevant service? Default "false", of course. -- Pedro Lamar?o From pedro.lamarao at mndfck.org Fri Jan 14 13:39:37 2005 From: pedro.lamarao at mndfck.org (=?UTF-8?B?UGVkcm8gTGFtYXLDo28=?=) Date: Fri, 14 Jan 2005 11:39:37 -0200 Subject: Building subversion javahl bindings Message-ID: <41E7CB99.1050804@mndfck.org> I've got this patch to subversion.spec that allows optional building of javahl bindings with a variable-specified JDK path. I've built it as I need Subclipse to work. What do you all think? -- Pedro Lamar?o -------------- next part -------------- A non-text attachment was scrubbed... Name: subversion.spec.diff Type: text/x-patch Size: 1659 bytes Desc: not available URL: From buildsys at redhat.com Fri Jan 14 13:49:10 2005 From: buildsys at redhat.com (Build System) Date: Fri, 14 Jan 2005 08:49:10 -0500 Subject: rawhide report: 20050114 changes Message-ID: <200501141349.j0EDnAY21809@porkchop.devel.redhat.com> From PerSteinar.Iversen at adm.hio.no Fri Jan 14 14:09:44 2005 From: PerSteinar.Iversen at adm.hio.no (Per Steinar Iversen) Date: Fri, 14 Jan 2005 15:09:44 +0100 (CET) Subject: Building rpms on AMD64 Message-ID: I tried this question on fedora-list yesterday, and got a number of messages from other users with the same problem, but no resolution. Perhaps this list is a better place to ask? A silly question: How does one build or rebuild src rpms under x86_64? On a freshly installed FC3 (full install) nearly everything fails to build as configure looks at the wrong X11 libraries. As an example, rebuilding mozilla: $ rpmbuild --rebuild mozilla-1.7.5-3.src.rpm ...lines deleted... checking GLIB_LIBS... -lglib-2.0 configure: error: Could not find the following X libraries: -lX11 -lXext -lXt error: Bad exit status from /var/tmp/rpm-tmp.13288 (%build) Modifying the spec-file to add a line like this cures the problem: --x-libraries=/usr/X11R6/lib64 But this is probably too crude - what is the proper incantation to make rpmbuild understand where the X11 libraries are placed on x86_64? -psi From feliciano.matias at free.fr Fri Jan 14 14:38:54 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Fri, 14 Jan 2005 15:38:54 +0100 Subject: mod_dav_svn update In-Reply-To: <41E7C35B.1060007@mndfck.org> References: <1105535367.28147.14.camel@one.myworld> <20050112151332.GA18514@redhat.com> <1105543993.31987.8.camel@one.myworld> <20050113100532.GA11733@redhat.com> <1105613912.8286.20.camel@one.myworld> <41E7C35B.1060007@mndfck.org> Message-ID: <1105713534.14548.7.camel@one.myworld> Le vendredi 14 janvier 2005 ? 11:04 -0200, Pedro Lamar?o a ?crit : > Observe we are in a thread about a mod_dav_svn update. > That is *not* a configuration file. > Reloading a module requires "service httpd restart". Not here. [root at one i386]# wget --quiet -O - http://localhost/svn/packages/ | grep Subversion (...) Subversion version 1.1.2 (r12471). [root at one i386]# rpm -U --oldpackage mod_dav_svn-1.1.1-1.1.i386.rpm subversion-1.1.1-1.1.i386.rpm [root at one i386]# wget --quiet -O - http://localhost/svn/packages/ | grep Subversion (...) Subversion version 1.1.2 (r12471). [root at one i386]# service httpd reload Rechargement de httpd : [ OK ] [root at one i386]# wget --quiet -O - http://localhost/svn/packages/ | grep Subversion (...) Subversion version 1.1.1 (r11581). [root at one i386]# rpm -U subversion-1.1.2-2.3.i386.rpm mod_dav_svn-1.1.2-2.3.i386.rpm [root at one i386]# wget --quiet -O - http://localhost/svn/packages/ | grep Subversion (...) Subversion version 1.1.1 (r11581). [root at one i386]# service httpd reload Rechargement de httpd : [ OK ] [root at one i386]# wget --quiet -O - http://localhost/svn/packages/ | grep Subversion (...) Subversion version 1.1.2 (r12471). [root at one i386]# -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From linux_4ever at yahoo.com Fri Jan 14 15:11:01 2005 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 14 Jan 2005 07:11:01 -0800 (PST) Subject: rawhide report: 20050114 changes In-Reply-To: <200501141349.j0EDnAY21809@porkchop.devel.redhat.com> Message-ID: <20050114151101.77360.qmail@web50601.mail.yahoo.com> Hi, Since Tuesday I've been getting empty rawhide reports...but yum check-update shows new files like: vim-common.i386 1:6.3.054-2 development vim-enhanced.i386 1:6.3.054-2 development vim-minimal.i386 1:6.3.054-2 New samba, readline, python, too. Did something break the script that does the rawhide report? -Steve Grubb __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From nbargnesi at gmail.com Fri Jan 14 17:00:07 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Fri, 14 Jan 2005 12:00:07 -0500 Subject: Building rpms on AMD64 In-Reply-To: References: Message-ID: <3077b8a0050114090023076a3f@mail.gmail.com> If I were you - I would check to make sure you also do not have 32-bit X libraries installed. Part of the full installation you selected installs compat packages allowing you to build for different platforms. If removing the 32-bit libraries helps, send the solution back to the user list. On Fri, 14 Jan 2005 15:09:44 +0100 (CET), Per Steinar Iversen wrote: > > I tried this question on fedora-list yesterday, and got a number of > messages from other users with the same problem, but no resolution. > Perhaps this list is a better place to ask? > > A silly question: How does one build or rebuild src rpms under x86_64? > > On a freshly installed FC3 (full install) nearly everything fails to build > as configure looks at the wrong X11 libraries. As an example, rebuilding > mozilla: > > $ rpmbuild --rebuild mozilla-1.7.5-3.src.rpm > ...lines deleted... > checking GLIB_LIBS... -lglib-2.0 > configure: error: Could not find the following X libraries: -lX11 -lXext -lXt > error: Bad exit status from /var/tmp/rpm-tmp.13288 (%build) > > Modifying the spec-file to add a line like this cures the problem: > > --x-libraries=/usr/X11R6/lib64 > > But this is probably too crude - what is the proper incantation to make > rpmbuild understand where the X11 libraries are placed on x86_64? > > -psi > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From ellson at research.att.com Fri Jan 14 17:36:37 2005 From: ellson at research.att.com (John Ellson) Date: Fri, 14 Jan 2005 12:36:37 -0500 Subject: Building rpms on AMD64 In-Reply-To: <3077b8a0050114090023076a3f@mail.gmail.com> References: <3077b8a0050114090023076a3f@mail.gmail.com> Message-ID: <41E80325.6070303@research.att.com> Nick Bargnesi wrote: >If I were you - I would check to make sure you also do not have 32-bit >X libraries installed. Part of the full installation you selected >installs compat packages allowing you to build for different >platforms. If removing the 32-bit libraries helps, send the solution >back to the user list. > > Related to this. How does one go about removing 32bit libraries with rpm? How do you selectively remove just i386 rpms? I couldn't find any option in "rpm --help" that selects just the rpms of a given architecture. John Ellson From skvidal at phy.duke.edu Fri Jan 14 17:41:44 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 14 Jan 2005 12:41:44 -0500 Subject: Building rpms on AMD64 In-Reply-To: <41E80325.6070303@research.att.com> References: <3077b8a0050114090023076a3f@mail.gmail.com> <41E80325.6070303@research.att.com> Message-ID: <1105724504.3944.36.camel@cutter> On Fri, 2005-01-14 at 12:36 -0500, John Ellson wrote: > Nick Bargnesi wrote: > > >If I were you - I would check to make sure you also do not have 32-bit > >X libraries installed. Part of the full installation you selected > >installs compat packages allowing you to build for different > >platforms. If removing the 32-bit libraries helps, send the solution > >back to the user list. > > > > > > Related to this. How does one go about removing 32bit libraries with rpm? > > How do you selectively remove just i386 rpms? I couldn't find any > option in "rpm --help" > that selects just the rpms of a given architecture. > with rpm you can do: rpm -e name.arch with yum you can do the same: yum remove name.arch -sv From nbargnesi at gmail.com Fri Jan 14 17:39:35 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Fri, 14 Jan 2005 12:39:35 -0500 Subject: Building rpms on AMD64 In-Reply-To: <41E80325.6070303@research.att.com> References: <3077b8a0050114090023076a3f@mail.gmail.com> <41E80325.6070303@research.att.com> Message-ID: <3077b8a005011409395404aca2@mail.gmail.com> On Fri, 14 Jan 2005 12:36:37 -0500, John Ellson wrote: > Nick Bargnesi wrote: > > >If I were you - I would check to make sure you also do not have 32-bit > >X libraries installed. Part of the full installation you selected > >installs compat packages allowing you to build for different > >platforms. If removing the 32-bit libraries helps, send the solution > >back to the user list. > > > > > > Related to this. How does one go about removing 32bit libraries with rpm? > > How do you selectively remove just i386 rpms? I couldn't find any > option in "rpm --help" > that selects just the rpms of a given architecture. If it was an i386 xorg rpm as an example, rpm -e xorg-x11-devel.i386 i.e., put the arch after the package name with a dot. > > John Ellson > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From notting at redhat.com Fri Jan 14 22:30:20 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 14 Jan 2005 17:30:20 -0500 Subject: Fedora Core 4 Message-ID: <20050114223020.GA7168@nostromo.devel.redhat.com> A Fedora Core 4 proto-schedule is available at: http://fedora.redhat.com/participate/schedule/ Generally, it's 3 4-week test releases, with a release in early/mid May. So, what's planned for Fedora Core 4? Here's what we're looking at from the Red Hat side of things: - GCC 4, if it's ready We're not planning on holding for it, but if it's out in a reasonable time, sure. Failing that, we're looking at making more of the FORTIFY_SOURCE and other gcc & glibc security extensions integrated, if at all possible. - The usual new stuff - GNOME 2.10, KDE 3.4, Xorg 6.8.2, OpenOffice 2.0 (maybe), etc. - Xen and Virtualization This starts by integrating the Xen kernel stuff, and going from there. - SELinux Episode III: Revenge of the AVC Yet more targets in the targeted policy. - Faster boot Eliminating redundancy and old cruft in the bootup process, starting GDM early if possible, using newer and faster udev codebases, and other related tweaks. - Java More native-compiled GCJ stuff. Including Eclipse. - Package management GUI integration of system-config-packages, yum, and friends. - more networking changes Further integration of NetworkManager - PPC support For your brand spanking new MiniMac, or the p655 under your desk. - Extras at launch time. Or else. Hopefully, self explanatory. Could coincide with the move of some bits from Core to Extras. In fact, some of the stuff on this list of features may *be* in Extras. Probably other stuff that I'm forgetting in here. I'm sure more people can remind me. Bill From feliciano.matias at free.fr Fri Jan 14 23:02:10 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sat, 15 Jan 2005 00:02:10 +0100 Subject: Fedora Core 4 In-Reply-To: <20050114223020.GA7168@nostromo.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <1105743730.18319.18.camel@one.myworld> Le vendredi 14 janvier 2005 ? 17:30 -0500, Bill Nottingham a ?crit : > A Fedora Core 4 proto-schedule is available at: > > http://fedora.redhat.com/participate/schedule/ > > Generally, it's 3 4-week test releases, with a release in early/mid May. > > So, what's planned for Fedora Core 4? Here's what we're looking > at from the Red Hat side of things: > GFS ? There are packages in Rawhide. It's just for the record. It's not a request. > - GCC 4, if it's ready > > - Xen and Virtualization > Anaconda support for Xen host ? This should be great for testing propose. > This starts by integrating the Xen kernel stuff, and going > from there. > > - SELinux Episode III: Revenge of the AVC > > Yet more targets in the targeted policy. > > - Faster boot > > Eliminating redundancy and old cruft in the bootup process, > starting GDM early if possible, using newer and faster > udev codebases, and other related tweaks. > > - Java > > More native-compiled GCJ stuff. Including Eclipse. > > - Package management > > GUI integration of system-config-packages, yum, and friends. > > - more networking changes > > Further integration of NetworkManager > > - PPC support > > For your brand spanking new MiniMac, or the p655 under your > desk. > > - Extras at launch time. Or else. > Could you elaborate ? Is Fedora trying to provide this feature : FC4 + Fedora Extra 4 => update with anaconda => FC5 + Fedora Extra 5 Will FC4 provide iso for Fedora Extra ? > Hopefully, self explanatory. Could coincide with the move > of some bits from Core to Extras. In fact, some of the > stuff on this list of features may *be* in Extras. > > Probably other stuff that I'm forgetting in here. I'm sure > more people can remind me. > > Bill > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From adriano.galano at gmail.com Fri Jan 14 23:08:41 2005 From: adriano.galano at gmail.com (Adriano Galano) Date: Sat, 15 Jan 2005 00:08:41 +0100 Subject: Fedora Core 4 In-Reply-To: <20050114223020.GA7168@nostromo.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <754f42e705011415086885274c@mail.gmail.com> Hi Bill: On Fri, 14 Jan 2005 17:30:20 -0500, Bill Nottingham wrote: > A Fedora Core 4 proto-schedule is available at: > > http://fedora.redhat.com/participate/schedule/ > [....] What about Stateless Linux project on FC4? Regards, -- Adriano M. (bryam) Galano D?ez In LiNUX and FLOSS since 1992 (R) http://bryam.blogspot.com From nutello at sweetness.com Fri Jan 14 23:31:18 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Sat, 15 Jan 2005 00:31:18 +0100 Subject: Fedora Core 4 In-Reply-To: <20050114223020.GA7168@nostromo.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <20050114233118.GD5200@plain.rackshack.net> On Fri, Jan 14, 2005 at 05:30:20PM -0500, Bill Nottingham wrote: > - more networking changes > Further integration of NetworkManager How about easier setup of pam_ccreds for cached credentials (disconnected operation)? Mobile users with server-based authentication would love that. Without much fanfare, the package shipped with FC3 and, from my testing, it seems to work, but you need to tweak PAM's configuration manually. The changes are trickier than you need for LDAP or SMB authentication and, to add insult to injury, there's no documentation in the package or anywhere on the web - grab the source tarball and look at the pam.conf if you want to have any hope to get it to work. I already spammed Bugzilla for support in authconfig and anaconda, but I still have no idea if this is a feature that anyone cares about (how did it end up in FC3 in the first place, then?). > - PPC support > For your brand spanking new MiniMac, or the p655 under your > desk. I assume the mention of the p655 means support for ppc AND ppc64? Just asking for a clarification. It's not clear right now which kind of PPC64 hardware can be used for a fresh install. I know because I was checking Raw Hide this very morning. -- Rudi From gemi at bluewin.ch Sat Jan 15 00:30:08 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Sat, 15 Jan 2005 01:30:08 +0100 Subject: Fedora Core 4 In-Reply-To: <20050114223020.GA7168@nostromo.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <1105749008.19635.2.camel@scriabin.tannenrauch.ch> On Fri, 2005-01-14 at 17:30 -0500, Bill Nottingham wrote: > A Fedora Core 4 proto-schedule is available at: > > http://fedora.redhat.com/participate/schedule/ > > Generally, it's 3 4-week test releases, with a release in early/mid May. > > So, what's planned for Fedora Core 4? Here's what we're looking What about the kernel? The only kernel that would work on my computer is 2.6.9 (667), see bugzilla #141141. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From alan at redhat.com Sat Jan 15 00:37:35 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 14 Jan 2005 19:37:35 -0500 Subject: Fedora Core 4 In-Reply-To: <1105749008.19635.2.camel@scriabin.tannenrauch.ch> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105749008.19635.2.camel@scriabin.tannenrauch.ch> Message-ID: <20050115003735.GA3247@devserv.devel.redhat.com> On Sat, Jan 15, 2005 at 01:30:08AM +0100, G?rard Milmeister wrote: > What about the kernel? > > The only kernel that would work on my computer is 2.6.9 (667), > see bugzilla #141141. Probably 2.6.11 by the time FC4 is out From kyrre at solution-forge.net Sat Jan 15 01:20:42 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 15 Jan 2005 02:20:42 +0100 Subject: Fedora Core 4 In-Reply-To: <20050114223020.GA7168@nostromo.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <1105752042.4145.7.camel@localhost.localdomain> fre, 14.01.2005 kl. 23.30 skrev Bill Nottingham: > A Fedora Core 4 proto-schedule is available at: > > http://fedora.redhat.com/participate/schedule/ > > Generally, it's 3 4-week test releases, with a release in early/mid May. > > So, what's planned for Fedora Core 4? Here's what we're looking > at from the Red Hat side of things: > > - GCC 4, if it's ready > > We're not planning on holding for it, but if it's out in a > reasonable time, sure. Failing that, we're looking at making > more of the FORTIFY_SOURCE and other gcc & glibc security extensions > integrated, if at all possible. > How will this affect backwards compat? > - The usual new stuff - GNOME 2.10, KDE 3.4, Xorg 6.8.2, > OpenOffice 2.0 (maybe), etc. > Ooh... OO 2 would be great! :) Any plans for gnome 2.10? Where? > - Xen and Virtualization > > This starts by integrating the Xen kernel stuff, and going > from there. > Hmm.. Xen is quite similar to VMWare, or am i totaly wrong? > - SELinux Episode III: Revenge of the AVC > > Yet more targets in the targeted policy. > > - Faster boot > > Eliminating redundancy and old cruft in the bootup process, > starting GDM early if possible, using newer and faster > udev codebases, and other related tweaks. > Hum-di-dum :) > - Java > > More native-compiled GCJ stuff. Including Eclipse. > Compitability? Effect on OpenOffice? > - Package management > > GUI integration of system-config-packages, yum, and friends. > :D:D:D > - more networking changes > > Further integration of NetworkManager > :) > - PPC support > > For your brand spanking new MiniMac, or the p655 under your > desk. > > - Extras at launch time. Or else. > > Hopefully, self explanatory. Could coincide with the move > of some bits from Core to Extras. In fact, some of the > stuff on this list of features may *be* in Extras. > Great! > Probably other stuff that I'm forgetting in here. I'm sure > more people can remind me. > > Bill What about better lingua support - being able to post-installation install more languages, dont have all of those damn spellcheckers i dont need (but have the ones i need) installed in OO etc.? All in all, this was a lot more than i hoped for. Now i almost have an exuse for updating this thrusty old fc2 box :) Kyrre From alan at redhat.com Sat Jan 15 01:40:13 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 14 Jan 2005 20:40:13 -0500 Subject: Fedora Core 4 In-Reply-To: <1105752042.4145.7.camel@localhost.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> Message-ID: <20050115014013.GA19719@devserv.devel.redhat.com> On Sat, Jan 15, 2005 at 02:20:42AM +0100, Kyrre Ness Sjobak wrote: > > This starts by integrating the Xen kernel stuff, and going > > from there. > > Hmm.. Xen is quite similar to VMWare, or am i totaly wrong? Xen is a high performance paravirtualisating hypervisor. vmware fakes a real PC - which is one hell of a trick to do efficiently and securely. Xen provides a non-PC secure environment to guests which means it runs modified guests not a generic x86 kernel. So it'll run the various BSD's patched with Xen support, Linux and the like - much faster than vmware probably too - but it won't run Windows. There is a Windows port for Xen but Microsoft haven't released it From notting at redhat.com Sat Jan 15 02:35:14 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 14 Jan 2005 21:35:14 -0500 Subject: Fedora Core 4 In-Reply-To: <1105743730.18319.18.camel@one.myworld> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105743730.18319.18.camel@one.myworld> Message-ID: <20050115023514.GA6407@nostromo.devel.redhat.com> F?liciano Matias (feliciano.matias at free.fr) said: > GFS ? > There are packages in Rawhide. > It's just for the record. It's not a request. Told you I was forgetting something. > > - GCC 4, if it's ready > > > > - Xen and Virtualization > > Anaconda support for Xen host ? This should be great for testing > propose. Maybe, maybe not. It's not completely obvious that anaconda is the right way to set up a virtual environment. > > - Extras at launch time. Or else. > > Could you elaborate ? Well, there wa fedora.us for FC1 and FC2, and there are pre-extras at the moment for FC3. With FC4, the plan is to have Extras available for FC4 at release time (Extras for FC3 should be official and public before then.) > Is Fedora trying to provide this feature : > FC4 + Fedora Extra 4 => update with anaconda => FC5 + Fedora Extra 5 That may not be in FC4; that may come later. > Will FC4 provide iso for Fedora Extra ? Unknown. Bill From notting at redhat.com Sat Jan 15 02:36:12 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 14 Jan 2005 21:36:12 -0500 Subject: Fedora Core 4 In-Reply-To: <20050114233118.GD5200@plain.rackshack.net> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <20050114233118.GD5200@plain.rackshack.net> Message-ID: <20050115023612.GB6407@nostromo.devel.redhat.com> Rudi Chiarito (nutello at sweetness.com) said: > > - PPC support > > For your brand spanking new MiniMac, or the p655 under your > > desk. > > I assume the mention of the p655 means support for ppc AND ppc64? Just > asking for a clarification. It's not clear right now which kind of > PPC64 hardware can be used for a fresh install. I know because I was > checking Raw Hide this very morning. I believe that's the plan. Note that not *all* 32 or 64-bit PPCs may be supported; I wouldn't expect 32-bit RS6Ks to work, for example. Bill From symbiont at berlios.de Sat Jan 15 03:30:52 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sat, 15 Jan 2005 11:30:52 +0800 Subject: Vain Imaginations of Fedora Bootup Message-ID: <200501151130.52243.symbiont@berlios.de> As a laptop user and a power user, I have a need that current offerings leave a lot to be desired for. I am pretty certain I am not alone in this need, so I'd like to share what would be the greatest interactive experience with Fedora we've yet to see. Instead of writing a tome about it, I'll lay it out real simple like: 1. Identify bare minimum services for GDM to fully function as soon as possible. (tty, etc.) [Bill mentioned this for FC4 target] 2. Identify bare minimum services for actual login to fully function. (network, postfix/sendmail, etc.) 3. Modify GDM to not display the username/password box until #2 is ready. 4. Integrate RHGB functionality into GDM so that progress can be displayed to the user prior to #2 becoming available. 5. Integrate NetworkManager functionality into GDM so as to facilitate proper start of essential services for #2. 6. NetworkManager integrated into GDM should provide menus to select certain roaming profiles. Most profiles should be auto-detected. (wireless, eth, openvpn tun, vpnc cisco client, openswan vpn, etc., etc. should all be included.) 7. Services that need to identify with a particular network profile should be delayed until network roaming profile is in place. 8. Extra helper services can be delayed until the very end to startup after #3 is displaying on the screen. There could even be an ongoing startup process while the user is logging into the desktop. 9. XDMCP portion of GDM needs to delay binding to sockets until after NetworkManager is done configuring the current roaming profile. 10. Services that are in Error during GDM can use a minimalistic sub-window strategically located so that the user can see problem services. Possibly usage of osd_cat found in xosd would be an excellent candidate. Or, possibly, the mechanism used in amarok and others to display an OSD type sub-window. This would be able to carry through after even GDM is closed and X window is starting up with the user's login. 11. xfs may need to restart to rebind to appropriate interfaces after NetworkManager is done. Other services may need the same. Anyhow, these are just a few of things that came acrossed my head over the last couple of days. Comments? thanks, -- -jeff From feliciano.matias at free.fr Sat Jan 15 03:35:08 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sat, 15 Jan 2005 04:35:08 +0100 Subject: Fedora Core 4 In-Reply-To: <20050115023514.GA6407@nostromo.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105743730.18319.18.camel@one.myworld> <20050115023514.GA6407@nostromo.devel.redhat.com> Message-ID: <1105760108.24193.8.camel@one.myworld> Le vendredi 14 janvier 2005 ? 21:35 -0500, Bill Nottingham a ?crit : > F?liciano Matias (feliciano.matias at free.fr) said: > > GFS ? > > There are packages in Rawhide. > > It's just for the record. It's not a request. > > Told you I was forgetting something. http://www.redhat.com/archives/fedora-devel-list/2004- December/msg00891.html rawhide report: 20041222 changes New package GFS GFS - The Global File System New package GFS-kernel GFS-kernel - The Global File System kernel modules ... > > > > - GCC 4, if it's ready > > > > > > - Xen and Virtualization > > > > Anaconda support for Xen host ? This should be great for testing > > propose. > > Maybe, maybe not. It's not completely obvious that anaconda > is the right way to set up a virtual environment. Not to setup a virtual environment. I want to know if I could install FC4 within a virtual environment provided by Xen. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fedora at wir-sind-cool.org Sat Jan 15 06:27:05 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 15 Jan 2005 07:27:05 +0100 Subject: Fedora Core 4 In-Reply-To: <20050115003735.GA3247@devserv.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105749008.19635.2.camel@scriabin.tannenrauch.ch> <20050115003735.GA3247@devserv.devel.redhat.com> Message-ID: <20050115072705.2544b756.fedora@wir-sind-cool.org> On Fri, 14 Jan 2005 19:37:35 -0500, Alan Cox wrote: > On Sat, Jan 15, 2005 at 01:30:08AM +0100, G?rard Milmeister wrote: > > What about the kernel? > > > > The only kernel that would work on my computer is 2.6.9 (667), > > see bugzilla #141141. > > Probably 2.6.11 by the time FC4 is out Do any theories exist why the FC3 kernel updates since 2.6.9-1.667 stopped working for people like Gerard? He's a fedora.us contributor who could not upgrade to FC4 test releases or FC4 when it comes out, in case future kernels won't work either. From dragoran at feuerpokemon.de Sat Jan 15 06:40:37 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 15 Jan 2005 07:40:37 +0100 Subject: Fedora Core 4 In-Reply-To: <20050114223020.GA7168@nostromo.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <41E8BAE5.2090601@feuerpokemon.de> Bill Nottingham schrieb: >A Fedora Core 4 proto-schedule is available at: > >http://fedora.redhat.com/participate/schedule/ > >Generally, it's 3 4-week test releases, with a release in early/mid May. > >So, what's planned for Fedora Core 4? Here's what we're looking >at from the Red Hat side of things: > >- GCC 4, if it's ready > > We're not planning on holding for it, but if it's out in a > reasonable time, sure. Failing that, we're looking at making > more of the FORTIFY_SOURCE and other gcc & glibc security extensions > integrated, if at all possible. > >- The usual new stuff - GNOME 2.10, KDE 3.4, Xorg 6.8.2, > OpenOffice 2.0 (maybe), etc. > >- Xen and Virtualization > > This starts by integrating the Xen kernel stuff, and going > from there. > >- SELinux Episode III: Revenge of the AVC > > Yet more targets in the targeted policy. > >- Faster boot > > Eliminating redundancy and old cruft in the bootup process, > starting GDM early if possible, using newer and faster > udev codebases, and other related tweaks. > >- Java > > More native-compiled GCJ stuff. Including Eclipse. > >- Package management > > GUI integration of system-config-packages, yum, and friends. > >- more networking changes > > Further integration of NetworkManager > >- PPC support > > For your brand spanking new MiniMac, or the p655 under your > desk. > >- Extras at launch time. Or else. > > Hopefully, self explanatory. Could coincide with the move > of some bits from Core to Extras. In fact, some of the > stuff on this list of features may *be* in Extras. > >Probably other stuff that I'm forgetting in here. I'm sure >more people can remind me. > >Bill > > > what about cdrw/dvd packet writing? the kernel supports it since 2.6.10 only the udftools package is missing to let users use this feature. From skvidal at phy.duke.edu Sat Jan 15 06:45:23 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 15 Jan 2005 01:45:23 -0500 Subject: Fedora Core 4 In-Reply-To: <41E8BAE5.2090601@feuerpokemon.de> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <41E8BAE5.2090601@feuerpokemon.de> Message-ID: <1105771524.3944.109.camel@cutter> > > > > > what about cdrw/dvd packet writing? > the kernel supports it since 2.6.10 only the udftools package is missing > to let users use this feature. I think it is fair to say that if you have a feature you'd like to see in fc4 there are two good routes to getting it included: 1. write the code/package/etc yourself 2. file an RFE about it - RFEs with good non-crackrock patches go further, faster -sv From mandreiana at rdslink.ro Sat Jan 15 07:16:24 2005 From: mandreiana at rdslink.ro (Marius Andreiana) Date: Sat, 15 Jan 2005 09:16:24 +0200 Subject: enable tcp_syncookies by default? In-Reply-To: <20050113191329.GA12343@devserv.devel.redhat.com> References: <1105605191.7061.2.camel@marte.biciclete.ro> <604aa79105011308092dd7cfcd@mail.gmail.com> <20050113163619.GA28605@shadow.sumu.org> <1105641117.24448.77.camel@speedy.iagorubio.net> <20050113191329.GA12343@devserv.devel.redhat.com> Message-ID: <1105773384.3503.4.camel@marte.biciclete.ro> On Thu, 2005-01-13 at 14:13 -0500, Alan Cox wrote: > The protocol violation claim is IMHO garbage. Most of the reason syn cookies > are not used under high load by default is because they were invented by > Dan Bernstein. > > The extensions are problematic but this kicks in mostly at the point where > things are not working full stop. With guru confirmation this is a good thing, I made a request in bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145201 -- Marius Andreiana Galuna - Solutii Linux in Romania http://www.galuna.ro From arjanv at redhat.com Sat Jan 15 07:49:25 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 15 Jan 2005 08:49:25 +0100 Subject: Fedora Core 4 In-Reply-To: <1105752042.4145.7.camel@localhost.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> Message-ID: <1105775365.6300.24.camel@laptopd505.fenrus.org> On Sat, 2005-01-15 at 02:20 +0100, Kyrre Ness Sjobak wrote: > fre, 14.01.2005 kl. 23.30 skrev Bill Nottingham: > > A Fedora Core 4 proto-schedule is available at: > > > > http://fedora.redhat.com/participate/schedule/ > > > > Generally, it's 3 4-week test releases, with a release in early/mid May. > > > > So, what's planned for Fedora Core 4? Here's what we're looking > > at from the Red Hat side of things: > > > > - GCC 4, if it's ready > > > > We're not planning on holding for it, but if it's out in a > > reasonable time, sure. Failing that, we're looking at making > > more of the FORTIFY_SOURCE and other gcc & glibc security extensions > > integrated, if at all possible. > > > > How will this affect backwards compat? FORTIFY_SOURCE is compatible; what it does do is make the binary depend on glibc 2.3.4 or higher, but well you run that risk anyway; apps generally depend on the glibc (or higher) they were compiled against (and for those of you who don't know what FORTIFY_SOURCE is; it is a gcc thing that detects a specific class of buffer overflows at runtime and prevents them) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From zboszor at freemail.hu Sat Jan 15 08:50:38 2005 From: zboszor at freemail.hu (Zoltan Boszormenyi) Date: Sat, 15 Jan 2005 09:50:38 +0100 Subject: Fedora Core 4 In-Reply-To: <20050114223020.GA7168@nostromo.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <41E8D95E.5010809@freemail.hu> Bill Nottingham ?rta: > A Fedora Core 4 proto-schedule is available at: > > http://fedora.redhat.com/participate/schedule/ > > Generally, it's 3 4-week test releases, with a release in early/mid May. > > So, what's planned for Fedora Core 4? Here's what we're looking > at from the Red Hat side of things: > > - GCC 4, if it's ready > > We're not planning on holding for it, but if it's out in a > reasonable time, sure. Failing that, we're looking at making > more of the FORTIFY_SOURCE and other gcc & glibc security extensions > integrated, if at all possible. > > - The usual new stuff - GNOME 2.10, KDE 3.4, Xorg 6.8.2, > OpenOffice 2.0 (maybe), etc. > > - Xen and Virtualization > > This starts by integrating the Xen kernel stuff, and going > from there. > > - SELinux Episode III: Revenge of the AVC > > Yet more targets in the targeted policy. > > - Faster boot > > Eliminating redundancy and old cruft in the bootup process, > starting GDM early if possible, using newer and faster > udev codebases, and other related tweaks. > > - Java > > More native-compiled GCJ stuff. Including Eclipse. > > - Package management > > GUI integration of system-config-packages, yum, and friends. > > - more networking changes > > Further integration of NetworkManager > > - PPC support > > For your brand spanking new MiniMac, or the p655 under your > desk. > > - Extras at launch time. Or else. > > Hopefully, self explanatory. Could coincide with the move > of some bits from Core to Extras. In fact, some of the > stuff on this list of features may *be* in Extras. > > Probably other stuff that I'm forgetting in here. I'm sure > more people can remind me. More complete bi-arch support on 64-bit at least AMD64? On FC3, at least /usr/include/kde/arts/gsl/gslconfig.h in arts-devel (.i386 and .x86_64) conflict, after inspecting both, one of the #defines differs, so it's not only a packaging problem. But I have seen other headers that include arch dependent stuff from /usr/include/asm-i386 or /usr/include/asm-x86_64, respectively. Ultimately, I would like to be able to install both -libs and -devel as the latter may contain static libs in either /usr/lib or /usr/lib64. Maybe there should be a -headers that contains the common stuff between the arch dependent -devel RPM. Hm. Anaconda or firstboot support to install all the .i386 versions of the above on x86-64 would be nice. I don't mind downloading all the 2x N disks for FC4, I installed both versions of FC3 on different machines, too. Best regards, Zolt?n B?sz?rm?nyi From fkooman at tuxed.net Sat Jan 15 10:47:56 2005 From: fkooman at tuxed.net (F. Kooman) Date: Sat, 15 Jan 2005 11:47:56 +0100 Subject: Vain Imaginations of Fedora Bootup In-Reply-To: <200501151130.52243.symbiont@berlios.de> References: <200501151130.52243.symbiont@berlios.de> Message-ID: <1105786076.5937.5.camel@dilithium.bromstraat.net> On Sat, 2005-01-15 at 11:30 +0800, Jeff Pitman wrote: > 10. Services that are in Error during GDM can use a minimalistic > sub-window strategically located so that the user can see problem > services. Possibly usage of osd_cat found in xosd would be an > excellent candidate. Or, possibly, the mechanism used in amarok and > others to display an OSD type sub-window. This would be able to carry > through after even GDM is closed and X window is starting up with the > user's login. Maybe use dbus and the new GNOME 2.10 libnotify stuff (or KDE equivalent) > Comments? 11. Software suspend(2) (is this currently stable?) I don't think ACPI will every work for my (old) laptop. Fran?ois -- Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html From rahulsundaram at gmail.com Sat Jan 15 11:59:16 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sat, 15 Jan 2005 17:29:16 +0530 Subject: Fedora Core 4 In-Reply-To: <20050114223020.GA7168@nostromo.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: Hi > > - SELinux Episode III: Revenge of the AVC how about gui integration with gnome by letting nautllus show security contexts and manipulate them using chcon, fixfiles etc as the backend. Good GUI tools for analysing existing policies or customising/creating policies would be a good step forward in the perceived user friendliness > - Faster boot I would really like a faster productive machine overall. somebody please kill up2date and bring out something better with the ideas discussed before in the list > - Java > > More native-compiled GCJ stuff. Including Eclipse. how about tomcat/ant/ gcjwebplugin? > Hopefully, self explanatory. Could coincide with the move > of some bits from Core to Extras. In fact, some of the > stuff on this list of features may *be* in Extras. Is there any move towards moving "alternatives" like KDE, exim etc into its own alternatives repository as envisioned here http://fedora.redhat.com/participate/terminology.html That would make fedora core truly the core parts of the fedora distribution which should be just one cd and let the other repositories packaged as ISO if possible in parts even in a way that enhances and provides a flexible solution for the fedora core distribution -- Regards, Rahul Sundaram From thomasz at hostmaster.org Sat Jan 15 12:07:03 2005 From: thomasz at hostmaster.org (Thomas Zehetbauer) Date: Sat, 15 Jan 2005 13:07:03 +0100 Subject: Fedora Core 4 In-Reply-To: <20050114223020.GA7168@nostromo.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <1105790823.4698.134.camel@hostmaster.org> On Fri, 2005-01-14 at 17:30 -0500, Bill Nottingham wrote: > - Xen and Virtualization I guess this is only useful for a handful of ISPs who want to sell fully virtual servers, any only if they can get enough IPv4 addresses. > - Java A Mozilla plugin for AMD64 would be really really nice. Tom -- T h o m a s Z e h e t b a u e r ( TZ251 ) PGP encrypted mail preferred - KeyID 96FFCB89 finger thomasz at hostmaster.org for key I hate beeing a DNA molecule - there's so much to remember! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 481 bytes Desc: This is a digitally signed message part URL: From fitzsim at redhat.com Sat Jan 15 12:25:03 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Sat, 15 Jan 2005 07:25:03 -0500 Subject: Fedora Core 4 In-Reply-To: <1105752042.4145.7.camel@localhost.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> Message-ID: <1105791903.17504.11.camel@rh-ibm-t41> Hi, On Sat, 2005-01-15 at 02:20 +0100, Kyrre Ness Sjobak wrote: > > - Java > > > > More native-compiled GCJ stuff. Including Eclipse. > > > > Compitability? Effect on OpenOffice? > All FC4 Java packages, including the SDK wrapper package for GCJ, will be JPackage-compatible. As I understand it, the parts of OpenOffice that can be built with GCJ will be. However there are some parts of OOo's Java code that rely on Sun-private interfaces -- these present a dead end for GCJ, so we'll need to get them reimplemented (using public APIs) upstream. Tom From fitzsim at redhat.com Sat Jan 15 12:27:53 2005 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Sat, 15 Jan 2005 07:27:53 -0500 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <1105792073.17504.14.camel@rh-ibm-t41> Hi, On Sat, 2005-01-15 at 17:29 +0530, Rahul Sundaram wrote: > > - Java > > > > More native-compiled GCJ stuff. Including Eclipse. > > how about tomcat/ant/ gcjwebplugin? > Yes/Yes/No (although a security audit of libgcj, required before a gcjwebplugin release can occur, is on our internal roadmap now). Tom From rahulsundaram at gmail.com Sat Jan 15 12:32:03 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sat, 15 Jan 2005 18:02:03 +0530 Subject: Fedora Core 4 In-Reply-To: <1105791903.17504.11.camel@rh-ibm-t41> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <1105791903.17504.11.camel@rh-ibm-t41> Message-ID: Hi . However there are some parts of > OOo's Java code that rely on Sun-private interfaces -- these present a > dead end for GCJ, so we'll need to get them reimplemented (using public > APIs) upstream. is this going to happen before the final OO.o 2.0 release or are you planning to add patches? -- Regards, Rahul Sundaram From arnaud.abelard at univ-nantes.fr Sat Jan 15 12:55:34 2005 From: arnaud.abelard at univ-nantes.fr (=?ISO-8859-1?Q?Arnaud_Ab=E9lard?=) Date: Sat, 15 Jan 2005 13:55:34 +0100 Subject: NetworkManager update requires bind Message-ID: <41E912C6.8020907@univ-nantes.fr> Hello, I'm wondering why the networkManager package (NetworkManager.i386 0:0.3.3-1.cvs20050112.1.fc3) available in the updates now requires caching-nameserver which requires bind? I'm not saying it's abnormal, but it does look weird to see an update requiring bind... Cheers, Arnaud From rahulsundaram at gmail.com Sat Jan 15 13:01:05 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sat, 15 Jan 2005 18:31:05 +0530 Subject: NetworkManager update requires bind In-Reply-To: <41E912C6.8020907@univ-nantes.fr> References: <41E912C6.8020907@univ-nantes.fr> Message-ID: On Sat, 15 Jan 2005 13:55:34 +0100, Arnaud Ab?lard wrote: > Hello, > > I'm wondering why the networkManager package (NetworkManager.i386 > 0:0.3.3-1.cvs20050112.1.fc3) available in the updates now requires > caching-nameserver which requires bind? not sure if its a bug or something. ask in the devel list or file a bug report at bugzilla.redhat.com -- Regards, Rahul Sundaram From buildsys at redhat.com Sat Jan 15 13:40:44 2005 From: buildsys at redhat.com (Build System) Date: Sat, 15 Jan 2005 08:40:44 -0500 Subject: rawhide report: 20050115 changes Message-ID: <200501151340.j0FDeig00903@porkchop.devel.redhat.com> New package python-twisted Event-driven networking framework written in Python Updated Packages: abiword-1:2.2.2-4 ----------------- * Fri Jan 14 2005 Caolan McNamara - 1:2.2.2-4 - RH#145085# annoying cluepacket message on stdout/stderr autofs-1:4.1.3-76 ----------------- * Tue Jan 11 2005 Jeff Moyer - 1:4.1.3-76 - Fix the large program map patch. * Tue Jan 11 2005 Jeff Moyer - 1:4.1.3-75 - Fix some merging breakages that caused the package not to build. * Thu Jan 06 2005 - 1:4.1.3-74 - Add in the map expiry patch - Bring in other patches that have been committed to other branches. This version should now contain all fixes we have to date - Merge conflicts due to map expiry changes bind-22:9.3.0-2 --------------- * Tue Jan 11 2005 Jason Vas Dias - 22:9.3.0-2 - Fix bug 143438: named.init will now make correct ownership of $ROOTDIR/var/named - based on 'named_write_master_zones' SELinux boolean. - Fix bug 143744: dig & nsupdate IPv6 timeout (dup of 140528) cpio-2.6-2 ---------- * Fri Jan 14 2005 Peter Vrabec - new fixed version of lfs patch (#144688) dhcpv6-0.10-11 -------------- * Thu Jan 13 2005 Jason Vas Dias - 0.10-11 - Fix misc. compiler warnings and ms-dos formatted man-pages * Wed Jan 12 2005 Jason Vas Dias - 0.10-11 - Add 'prefix-delegation-interface' option to allow write - of radvd interface configuration other than that for - the interface the lease was received on. ecj-3.1-0.M4.4 -------------- * Fri Jan 14 2005 Andrew Overholt 3.1.0.M4.4 - build for all but x86 eclipse-3.1-0.M4.18 ------------------- * Sat Jan 15 2005 Andrew Overholt 3.1-0.M4.18 - script path fixes - x86_64 fixes * Fri Jan 14 2005 Andrew Overholt 3.1-0.M4.17 - sed typo * Fri Jan 14 2005 Andrew Overholt 3.1-0.M4.15 - fix /usr/share -> /usr/lib error in launcher script - only add to the db those jar-so combinations that we've compiled gcc-3.4.3-14 ------------ * Fri Jan 14 2005 Jakub Jelinek 3.4.3-14 - update from gcc-3_4-branch - PRs bootstrap/18033, target/18987, target/18720, rtl-optimization/19012, rtl-opt/13299, rtl-opt/10692 - fix PRs c++/19263, rtl-optimization/16104, c/17297, middle-end/19164, rtl-optimization/15139, rtl-optimization/19348, middle-end/19084, java/17255 * Fri Jan 07 2005 Jakub Jelinek 3.4.3-13 - fix memory attribute computation for addqi_1_slp (PR target/19012) - fix TYPE_MODE of enum with __attribute__ ((mode ())) (#144358) * Wed Jan 05 2005 Jakub Jelinek 3.4.3-12 - update from gcc-3_4-branch - PRs c++/14607, middle-end/19175, rtl-optimization/12092, target/17643 - fix ICE in same_translation_unit_p (#144166) gdb-6.3.0.0-0.1 --------------- * Wed Jan 12 2005 Elena Zannoni 6.3.0.0-0.1 Andrew Cagney Jeff Johnston - Various fixes to complete the import and merge. * Wed Dec 01 2004 Andrew Cagney 6.3-0.0 - Import GDB 6.3, get building, add all patches. * Tue Nov 30 2004 Jeff Johnston 1.200400607.63 - When removing breakpoints, continue removing breakpoints even if an error occurs on the list. gimp-2:2.2.2-2 -------------- * Fri Jan 14 2005 Nils Philippsen - avoid writing excessively long EXIF markers (#145100) * Tue Jan 11 2005 Nils Philippsen - version 2.2.2 - autogenerate %microver * Wed Dec 29 2004 Nils Philippsen - version 2.2.1 - pygimp-logo.png included in tarball again kernel-2.6.10-1.1089_FC4 ------------------------ * Fri Jan 14 2005 Dave Jones - Rebase to 2.6.11-bk2 openswan-2.3.0-2 ---------------- * Fri Jan 14 2005 Harald Hoyer - 2.3.0-2 - Do not enable the initscript per default rpmdb-fedora-1:4-0.20050115 --------------------------- sysklogd-1.4.1-26 ----------------- * Fri Jan 14 2005 Jason Vas Dias 1.4.1rh-26 - Final fixup of '@host' name checking code: remove possible - duplicates properly * Tue Jan 04 2005 Jason Vas Dias 1.4.1rh-25 - Fix bug 144084 - bad version of '@host' name checking code - used by mistake + memory corruption caused by free of - addrinfo node returned by getaddrinfo(). syslinux-3.07-1 --------------- * Thu Jan 13 2005 Peter Jones - 3.07-1 - update to 3.07 * Tue Jan 11 2005 Peter Jones - 3.06-1 - update to 3.06 , which should fix the directory parsing bug that wedges it with diskboot.img - change README to README* in doc, to include README.menu and README.usbkey xen-2-20050114 -------------- * Fri Jan 14 2005 Jeremy Katz - 2-20050114 - update to new snap - python-twisted is its own package now - files are in /usr/lib/python now as well, ugh. From Peter.Dedecker at vtk2.UGent.be Sat Jan 15 14:12:04 2005 From: Peter.Dedecker at vtk2.UGent.be (Peter Dedecker - FSU) Date: Sat, 15 Jan 2005 14:12:04 +0000 Subject: Fedora Core 4 In-Reply-To: <754f42e705011415086885274c@mail.gmail.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <754f42e705011415086885274c@mail.gmail.com> Message-ID: <41E924B4.1000506@VTK.UGent.be> Adriano Galano wrote: > What about Stateless Linux project on FC4? Even if the Stateless project isn't continued, I think it would be very usefull to make sure the current state works also on FC4. It would encourage people from outside RedHat to work on it. But I sure hope the project will be continued. It's a very promissing goal that may not get lost and could increase the ease of maintaining a linux installation for a large network of users in a school/company/public place. -- Peter Dedecker The Fedora Stateless @ UGent project http://blog.eikke.com/index.php/fedorastateless From mike at navi.cx Sat Jan 15 14:23:41 2005 From: mike at navi.cx (Mike Hearn) Date: Sat, 15 Jan 2005 14:23:41 +0000 Subject: Fedora Core 4 References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <1105775365.6300.24.camel@laptopd505.fenrus.org> Message-ID: On Sat, 15 Jan 2005 08:49:25 +0100, Arjan van de Ven wrote: > FORTIFY_SOURCE is compatible; what it does do is make the binary depend > on glibc 2.3.4 or higher, but well you run that risk anyway; apps > generally depend on the glibc (or higher) they were compiled against Presumably it's possible to disable the FORTIFY_SOURCE extensions at compile time with a new gcc flag, right? ie, if you don't want a dependency on such a new glibc release you should be able to avoid it. If this isn't currently the case I'm willing to do a patch for this, as being able to build on new, run on old is important to the autopackage project (yes, it is possible ...) From fedora-devel at camperquake.de Sat Jan 15 14:20:56 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Sat, 15 Jan 2005 15:20:56 +0100 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <1105775365.6300.24.camel@laptopd505.fenrus.org> Message-ID: <20050115152056.7e04a061@nausicaa.camperquake.de> Hi. Mike Hearn wrote: > Presumably it's possible to disable the FORTIFY_SOURCE extensions at > compile time with a new gcc flag, right? ie, if you don't want a > dependency on such a new glibc release you should be able to avoid it. Judging from the RPM cflags macro, you have to pass -D_FORTIFY_SOURCE to gcc to get it in the first place. -- A man armed with a whittled cucumber obviously does not have intent to harm. From felipe_alfaro at linuxmail.org Sat Jan 15 14:28:27 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sat, 15 Jan 2005 15:28:27 +0100 Subject: Fedora Core 4 In-Reply-To: <1105790823.4698.134.camel@hostmaster.org> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105790823.4698.134.camel@hostmaster.org> Message-ID: On 15 Jan 2005, at 13:07, Thomas Zehetbauer wrote: > On Fri, 2005-01-14 at 17:30 -0500, Bill Nottingham wrote: >> - Xen and Virtualization > > I guess this is only useful for a handful of ISPs who want to sell > fully > virtual servers, any only if they can get enough IPv4 addresses. Maybe. Currently, I depend heavily on Xen-unstable to run one domain0 and two isolated domainU. This allows me to reduce power consumption and consolidate services. And I'm no ISP: I use Xen at home. From PerSteinar.Iversen at adm.hio.no Sat Jan 15 14:32:00 2005 From: PerSteinar.Iversen at adm.hio.no (Per Steinar Iversen) Date: Sat, 15 Jan 2005 15:32:00 +0100 (CET) Subject: Building rpms on AMD64 In-Reply-To: <1105724504.3944.36.camel@cutter> References: <3077b8a0050114090023076a3f@mail.gmail.com> <41E80325.6070303@research.att.com> <1105724504.3944.36.camel@cutter> Message-ID: On Fri, 14 Jan 2005, seth vidal wrote: > On Fri, 2005-01-14 at 12:36 -0500, John Ellson wrote: >> Nick Bargnesi wrote: >> >>> If I were you - I would check to make sure you also do not have 32-bit >>> X libraries installed. Part of the full installation you selected >>> installs compat packages allowing you to build for different >>> platforms. If removing the 32-bit libraries helps, send the solution >>> back to the user list. >>> >>> >> >> Related to this. How does one go about removing 32bit libraries with rpm? >> >> How do you selectively remove just i386 rpms? I couldn't find any >> option in "rpm --help" >> that selects just the rpms of a given architecture. >> > > with rpm you can do: > > rpm -e name.arch > > with yum you can do the same: > > yum remove name.arch Yet another problem: On a system with dual x86_64 and i386 libraries many rpms are installed by default for both architectures, an example is mozilla, the default install of FC3 contains these: mozilla-1.7.3-17.x86_64.rpm mozilla-chat-1.7.3-17.x86_64.rpm mozilla-devel-1.7.3-17.x86_64.rpm mozilla-dom-inspector-1.7.3-17.x86_64.rpm mozilla-js-debugger-1.7.3-17.x86_64.rpm mozilla-mail-1.7.3-17.x86_64.rpm mozilla-nspr-1.7.3-17.i386.rpm mozilla-nspr-1.7.3-17.x86_64.rpm mozilla-nspr-devel-1.7.3-17.x86_64.rpm mozilla-nss-1.7.3-17.i386.rpm mozilla-nss-1.7.3-17.x86_64.rpm mozilla-nss-devel-1.7.3-17.x86_64.rpm mozplugger-1.6.2-1.x86_64.rpm Here mozilla-nspr and mozilla-nss are for both architectures - the problem is: If one builds updates for x86_64 how does one easily determine what packages that also must be created for i386? I have problems creating the i386 packages anyway, for example: # setarch i386 rpmbuild --target i386 --rebuild mozilla-1.7.5-3.src.rpm Goes like this: Installing mozilla-1.7.5-3.src.rpm Building target platforms: i386 Building for target i386 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.33053 ...lines deleted... Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.60269 + umask 022 + cd /usr/src/redhat/BUILD + cd mozilla + LANG=C + export LANG + unset DISPLAY + /bin/rm -f ./configure + /usr/bin/autoconf-2.13 + '[' -x /usr/bin/getconf ']' ++ getconf _NPROCESSORS_ONLN + CPUS=1 + test x1 = x -o x1 = x0 + OPTFLAGS=-O2 + XCFLAGS=-g + CFLAGS=-g + CXXFLAGS=-g + BUILD_OFFICIAL=1 + MOZILLA_OFFICIAL=1 + ./configure --prefix=/usr --libdir=/usr/lib64 --enable-optimize=-O2 --disable-debug --with-default-mozilla-five-home=/usr/lib64/mozilla-1.7.5 --disable-strip-libs --disable-tests --enable-xinerama --enable-nspr-autoconf --enable-extensions=default,irc --without-mng --enable-crypto --disable-xprint --without-system-nspr --with-system-zlib --with-system-png --with-system-jpeg --enable-default-toolkit=gtk2 --disable-freetype2 --enable-xft --enable-pango --mandir=/usr/share/man ...lines deleted... gmake[6]: Entering directory `/usr/src/redhat/BUILD/mozilla/xpcom/reflect/xptcall/src/md/unix' xptcinvoke_gcc_x86_unix.cpp c++ -o xptcinvoke_gcc_x86_unix.o -c -DOSTYPE=\"Linux2.6.10-1\" -DOSARCH=\"Linux\" -DEXPORT_XPTC_API -I../../../../../../dist/include/xpcom -I../../../../../../dist/include -I/usr/src/redhat/BUILD/mozilla/dist/include/nspr -I./../.. -I/usr/X11R6/include -fPIC -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -g -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O2 -I/usr/X11R6/include -DMOZILLA_CLIENT -include ../../../../../../mozilla-config.h -Wp,-MD,.deps/xptcinvoke_gcc_x86_unix.pp xptcinvoke_gcc_x86_unix.cpp {standard input}: Assembler messages: {standard input}:16: Error: suffix or operands invalid for `push' {standard input}:26: Error: suffix or operands invalid for `push' {standard input}:32: Error: suffix or operands invalid for `pop' gmake[6]: *** [xptcinvoke_gcc_x86_unix.o] Error 1 gmake[6]: Leaving directory `/usr/src/redhat/BUILD/mozilla/xpcom/reflect/xptcall/src/md/unix' Clearly something triggers setup for the wrong platform in this case, at configure looks in the lib64 directories. This "works" though: # rpmbuild --target i386 --rebuild mozilla-1.7.5-3.src.rpm However the resulting rpm is not okay at all: # rpm -qpl mozilla-nspr-1.7.5-3.i386.rpm /usr/lib64/libnspr4.so /usr/lib64/libplc4.so /usr/lib64/libplds4.so Life on the combined x86_64 / i386 architecture seems a bit confusing to me so far :-( -psi From felipe_alfaro at linuxmail.org Sat Jan 15 14:32:58 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sat, 15 Jan 2005 15:32:58 +0100 Subject: Fedora Core 4 In-Reply-To: <1105752042.4145.7.camel@localhost.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> Message-ID: <5A39033C-6702-11D9-A4F6-000D9352858E@linuxmail.org> On 15 Jan 2005, at 02:20, Kyrre Ness Sjobak wrote: >> - Xen and Virtualization >> >> This starts by integrating the Xen kernel stuff, and going >> from there. >> > > Hmm.. Xen is quite similar to VMWare, or am i totaly wrong? Xen is very different from VMware. VMware emulates a fake PC and is able to run nearly any Operating System and suboperating systems (like Windows). However, Xen does perform paravirtualization instead of emulating a whole PC. Paravirtualization requires changes into the guest operating system source code, in order to replace hardware dependent code with calls to Xen itself (the Xen hypervisor). This allows high performance virtualization. VMware-like emulation is a lot trickier. Since Xen requires the guest operating system source code to be modified, Windows is not (and probably will never, in a foreseeable future) supported. Up to date, only Linux and NetBSD are supported, although people are working towards porting FreeBSD to Xen. All in all, Xen is God Blessing. From barryn at pobox.com Sat Jan 15 14:48:37 2005 From: barryn at pobox.com (Barry K. Nathan) Date: Sat, 15 Jan 2005 06:48:37 -0800 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <20050115144837.GA4929@ip68-4-98-123.oc.oc.cox.net> On Sat, Jan 15, 2005 at 05:29:16PM +0530, Rahul Sundaram wrote: > Is there any move towards moving "alternatives" like KDE, exim etc > into its own alternatives repository as envisioned here > > http://fedora.redhat.com/participate/terminology.html I don't think that's what "alternatives" means, in the context of "Fedora Alternatives". The site says: "'Fedora Alternatives' refers to the set of packages which replace packages in the Fedora Core." *Replacing* packages in Fedora Core would be something like having new OpenSSH packages based on CVS snapshots rather than the latest release, or GNOME 2.10 packages backported to FC3, or XFree86 forward-ported to FC3/4, or stuff like that. At least, that's my interpretation. It seems like you're asking for stuff like KDE and exim to be moved out of Core (and that would mean moving them into Extras). Personally, I'd like to see all of the (open-source) RHEL packages stay in Core; splitting them across Core and Extras seems like an effective way of making my life more difficult, unless anaconda gains support for installing just the subset of Extras packages that are also present in RHEL. But, that's just my opinion, and I wouldn't be surprised if this has been previously beaten to death on the list anyway. -Barry K. Nathan From pedro.lamarao at mndfck.org Sat Jan 15 14:22:05 2005 From: pedro.lamarao at mndfck.org (=?ISO-8859-1?Q?Pedro_Lamar=E3o?=) Date: Sat, 15 Jan 2005 12:22:05 -0200 Subject: mod_dav_svn update In-Reply-To: <1105713534.14548.7.camel@one.myworld> References: <1105535367.28147.14.camel@one.myworld> <20050112151332.GA18514@redhat.com> <1105543993.31987.8.camel@one.myworld> <20050113100532.GA11733@redhat.com> <1105613912.8286.20.camel@one.myworld> <41E7C35B.1060007@mndfck.org> <1105713534.14548.7.camel@one.myworld> Message-ID: <41E9270D.70100@mndfck.org> F?liciano Matias wrote: >Not here. > >[root at one i386]# wget --quiet -O - http://localhost/svn/packages/ | grep Subversion > (...) Subversion version 1.1.2 (r12471). >[root at one i386]# rpm -U --oldpackage mod_dav_svn-1.1.1-1.1.i386.rpm subversion-1.1.1-1.1.i386.rpm >[root at one i386]# wget --quiet -O - http://localhost/svn/packages/ | grep Subversion > (...) Subversion version 1.1.2 (r12471). >[root at one i386]# service httpd reload >Rechargement de httpd : [ OK ] >[root at one i386]# wget --quiet -O - http://localhost/svn/packages/ | grep Subversion > (...) Subversion version 1.1.1 (r11581). >[root at one i386]# rpm -U subversion-1.1.2-2.3.i386.rpm mod_dav_svn-1.1.2-2.3.i386.rpm >[root at one i386]# wget --quiet -O - http://localhost/svn/packages/ | grep Subversion > (...) Subversion version 1.1.1 (r11581). >[root at one i386]# service httpd reload >Rechargement de httpd : [ OK ] >[root at one i386]# wget --quiet -O - http://localhost/svn/packages/ | grep Subversion > (...) Subversion version 1.1.2 (r12471). >[root at one i386]# > > Hm... I stand corrected. -- Pedro Lamar?o From arjanv at redhat.com Sat Jan 15 15:10:56 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 15 Jan 2005 16:10:56 +0100 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <1105775365.6300.24.camel@laptopd505.fenrus.org> Message-ID: <1105801856.6300.49.camel@laptopd505.fenrus.org> On Sat, 2005-01-15 at 14:23 +0000, Mike Hearn wrote: > On Sat, 15 Jan 2005 08:49:25 +0100, Arjan van de Ven wrote: > > FORTIFY_SOURCE is compatible; what it does do is make the binary depend > > on glibc 2.3.4 or higher, but well you run that risk anyway; apps > > generally depend on the glibc (or higher) they were compiled against > > Presumably it's possible to disable the FORTIFY_SOURCE extensions at > compile time with a new gcc flag, right? ie, if you don't want a > dependency on such a new glibc release you should be able to avoid it. FORTIFY_SOURCE is by far not the only thing that might make your binaries require a "new" glibc. If you want to run against an old glibc, you should build against such an old glibc. Example: NPTL threads. There are countless other examples of things that make your app require a newer glibc *IF* you build against a new glibc. If you don't want that.. don't do that then. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From elanthis at awesomeplay.com Sat Jan 15 15:32:37 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 15 Jan 2005 10:32:37 -0500 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> On Sat, 2005-01-15 at 17:29 +0530, Rahul Sundaram wrote: > Hi > > > > - SELinux Episode III: Revenge of the AVC > > how about gui integration with gnome by letting nautllus show security > contexts and manipulate them using chcon, fixfiles etc as the backend. That sounds like a pretty bad idea in general, actually - the last thing you need is for the state of your file contexts to ever get out of sync with your configuration files. Besides, you'd need to have some pretty highly elevated privileges to even perform those tasks, and SELinux eventually should probably make sure no GUI tool can ever even have those privileges, except for the ones specifically designed for SELinux administration (like you say below). > Good GUI tools for analysing existing policies or customising/creating > policies would be a good step forward in the perceived user > friendliness -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1809 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Sat Jan 15 16:00:53 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Sat, 15 Jan 2005 17:00:53 +0100 Subject: NetworkManager update requires bind In-Reply-To: References: <41E912C6.8020907@univ-nantes.fr> Message-ID: <20050115170053.5cc26ac0@python2> Rahul Sundaram wrote : > > I'm wondering why the networkManager package (NetworkManager.i386 > > 0:0.3.3-1.cvs20050112.1.fc3) available in the updates now requires > > caching-nameserver which requires bind? > > not sure if its a bug or something. ask in the devel list or file a > bug report at bugzilla.redhat.com It's because it now uses bind on the loopback in caching mode to workaround some glibc resolving limitations. See the last %changelog entry from the package, it explains it. Not sure why _excatly_ that change was made, especially since I had a resolving problem _after_ the update, which I never had before, although I suspend and resume between various different networks... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.737_FC3 Load : 0.92 1.38 1.43 From feliciano.matias at free.fr Sat Jan 15 16:28:00 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sat, 15 Jan 2005 17:28:00 +0100 Subject: Fedora Core 4 In-Reply-To: <20050114223020.GA7168@nostromo.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <1105806480.28025.10.camel@one.myworld> Le vendredi 14 janvier 2005 ? 17:30 -0500, Bill Nottingham a ?crit : > A Fedora Core 4 proto-schedule is available at: > > http://fedora.redhat.com/participate/schedule/ > > Generally, it's 3 4-week test releases, with a release in early/mid May. > > So, what's planned for Fedora Core 4? Here's what we're looking > at from the Red Hat side of things: > > - Package management > > GUI integration of system-config-packages, yum, and friends. > Have you considerer smart : http://www.smartpm.org/ It is Interesting. But sometimes it ignore %{epoch} (for good or bad reason it's not the point), does not support group, the gui interface is a little confusing. Smart is quite fast (python), have gnome, kde, text interface. It's in beta/testing stage. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rahulsundaram at gmail.com Sat Jan 15 16:37:03 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sat, 15 Jan 2005 22:07:03 +0530 Subject: Fedora Core 4 In-Reply-To: <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> Message-ID: Hi > > > > how about gui integration with gnome by letting nautllus show security > > contexts and manipulate them using chcon, fixfiles etc as the backend. > > That sounds like a pretty bad idea in general, actually - the last thing > you need is for the state of your file contexts to ever get out of sync > with your configuration files. Ok. letting random tools manipulate policies does seem to be a bad idea but display security contexts in nautilus seems to be a good thing to me. agreed? -- Regards, Rahul Sundaram From skvidal at phy.duke.edu Sat Jan 15 16:40:13 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 15 Jan 2005 11:40:13 -0500 Subject: Fedora Core 4 In-Reply-To: <1105806480.28025.10.camel@one.myworld> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> Message-ID: <1105807213.13320.1.camel@cutter> > > > > Have you considerer smart : > http://www.smartpm.org/ > > It is Interesting. But sometimes it ignore %{epoch} (for good or bad > reason it's not the point), does not support group, the gui interface is > a little confusing. > Smart is quite fast (python), have gnome, kde, text interface. It's in > beta/testing stage. At this point smart doesn't have multilib support (at least from reading of the code) so I'm not sure how useful that will be for a distro offering (soon, I hope) two multilib archs: x86_64 and ppc64. -sv From rahulsundaram at gmail.com Sat Jan 15 16:37:47 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sat, 15 Jan 2005 22:07:47 +0530 Subject: Fedora Core 4 In-Reply-To: <1105806480.28025.10.camel@one.myworld> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> Message-ID: Hi > It is Interesting. But sometimes it ignore %{epoch} (for good or bad > reason it's not the point), does not support group, the gui interface is > a little confusing. > Smart is quite fast (python), have gnome, kde, text interface. It's in > beta/testing stage. being a beta at this stage, its better off in fedora extras for a while atleast -- Regards, Rahul Sundaram From fedora-devel at camperquake.de Sat Jan 15 17:08:01 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Sat, 15 Jan 2005 18:08:01 +0100 Subject: Current cpio broken, mangled initrd Message-ID: <20050115180801.73b19a14@nausicaa.camperquake.de> Hi. Just a head up warning: the cpio version distributed yesterday or today (2.6-1 or 2.6-2, I am not sure about that) has a bug causing automatic dereferencing of symlinks while packing. This leads to mangled initrd files when new kernels are installed. My system curses a lot, but boots nonetheless, others may not be so lucky :) This does not affect initrd images already created, of course. Filed in bugzilla. -- All that glitters has a high refractive index. From n3npq at nc.rr.com Sat Jan 15 17:08:53 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sat, 15 Jan 2005 12:08:53 -0500 Subject: Fedora Core 4 In-Reply-To: <1105807213.13320.1.camel@cutter> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> Message-ID: <41E94E25.7010005@nc.rr.com> seth vidal wrote: >>Have you considerer smart : >>http://www.smartpm.org/ >> >>It is Interesting. But sometimes it ignore %{epoch} (for good or bad >>reason it's not the point), does not support group, the gui interface is >>a little confusing. >>Smart is quite fast (python), have gnome, kde, text interface. It's in >>beta/testing stage. >> >> > >At this point smart doesn't have multilib support (at least from reading >of the code) so I'm not sure how useful that will be for a distro >offering (soon, I hope) two multilib archs: x86_64 and ppc64. > Multilib pkg choice is a work of hours, not more. Smartpm needs RHN channel too. 73 de Jeff From daryll.strauss at gmail.com Sat Jan 15 17:16:53 2005 From: daryll.strauss at gmail.com (Daryll Strauss) Date: Sat, 15 Jan 2005 09:16:53 -0800 Subject: NetworkManager update requires bind In-Reply-To: <20050115170053.5cc26ac0@python2> References: <41E912C6.8020907@univ-nantes.fr> <20050115170053.5cc26ac0@python2> Message-ID: <55668b8c05011509167b72ef2a@mail.gmail.com> Well installing it did break my running system. By installing caching-nameserver it rewrote my resolv.conf. From mike at flyn.org Sat Jan 15 17:14:15 2005 From: mike at flyn.org (W. Michael Petullo) Date: Sat, 15 Jan 2005 11:14:15 -0600 Subject: Fedora Core 4 In-Reply-To: <1105792073.17504.14.camel@rh-ibm-t41> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105792073.17504.14.camel@rh-ibm-t41> Message-ID: <20050115171415.GA7997@imp.flyn.org> [...] >> how about tomcat/ant/ gcjwebplugin? > > Yes/Yes/No (although a security audit of libgcj, required before a > gcjwebplugin release can occur, is on our internal roadmap now). Bug number 127537 is an RFE for gcjwebplugin. There is a small discussion about what is required for its inclusion attached to bug 127537. -- Mike :wq From skvidal at phy.duke.edu Sat Jan 15 17:54:20 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 15 Jan 2005 12:54:20 -0500 Subject: Fedora Core 4 In-Reply-To: <41E94E25.7010005@nc.rr.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> Message-ID: <1105811660.32328.0.camel@opus.phy.duke.edu> On Sat, 2005-01-15 at 12:08 -0500, Jeff Johnson wrote: > seth vidal wrote: > > >>Have you considerer smart : > >>http://www.smartpm.org/ > >> > >>It is Interesting. But sometimes it ignore %{epoch} (for good or bad > >>reason it's not the point), does not support group, the gui interface is > >>a little confusing. > >>Smart is quite fast (python), have gnome, kde, text interface. It's in > >>beta/testing stage. > >> > >> > > > >At this point smart doesn't have multilib support (at least from reading > >of the code) so I'm not sure how useful that will be for a distro > >offering (soon, I hope) two multilib archs: x86_64 and ppc64. > > > > Multilib pkg choice is a work of hours, not more. Not from what I've seen. Especially when it comes to automatic package selection. But hey, more power to you. -sv From mike at navi.cx Sat Jan 15 18:05:44 2005 From: mike at navi.cx (Mike Hearn) Date: Sat, 15 Jan 2005 18:05:44 +0000 Subject: Fedora Core 4 References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <1105775365.6300.24.camel@laptopd505.fenrus.org> <1105801856.6300.49.camel@laptopd505.fenrus.org> Message-ID: On Sat, 15 Jan 2005 16:10:56 +0100, Arjan van de Ven wrote: > FORTIFY_SOURCE is by far not the only thing that might make your > binaries require a "new" glibc. If you want to run against an old glibc, > you should build against such an old glibc. No, there are plenty of things, it's an annoying policy which we have a lot of code to hack around (see apbuild). > Example: NPTL threads. Code which actually depends on NPTL vs LinuxThreads needs at minimum configure-time checks for that, or more likely just compliance fixes. It's also possible to check for it at runtime like Wine does. > There are countless other examples of things that make your app require > a newer glibc *IF* you build against a new glibc. Thread-local locales are the only one that spring to mind, and that's easily suppressed. And symbol overloading of course. You can work around that too, symbol overloading like glibc does is broken anyway imho (though marking symbols with one version tag isn't) Obviously if you actually require new symbols or features (like ELF TLS) then you'll need a newer glibc, but there's a big difference between consciously depending on a new version and accidentally getting a dependency on it you probably don't need. > If you don't want that.. don't do that then. Building on an old glibc really means "build on an old distro" and that's unacceptable. Fortunately if you have to define _FORTIFY_SOURCE then it's OK, that can be selectively disabled. Or alternatively the symbols that are currently in glibc could be in libgcc or optionally statically linked, which makes checked binaries a lot easier to distribute. thanks -mike From arnaud.abelard at univ-nantes.fr Sat Jan 15 18:00:33 2005 From: arnaud.abelard at univ-nantes.fr (=?ISO-8859-1?Q?Arnaud_Ab=E9lard?=) Date: Sat, 15 Jan 2005 19:00:33 +0100 Subject: NetworkManager update requires bind In-Reply-To: <55668b8c05011509167b72ef2a@mail.gmail.com> References: <41E912C6.8020907@univ-nantes.fr> <20050115170053.5cc26ac0@python2> <55668b8c05011509167b72ef2a@mail.gmail.com> Message-ID: <41E95A41.6060707@univ-nantes.fr> Daryll Strauss wrote: > Well installing it did break my running system. By installing > caching-nameserver it rewrote my resolv.conf. I opened a bug about the require weirdness, maybe you should add your problem as a comment of the bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145212 From stevelist at silverorange.com Sat Jan 15 18:06:46 2005 From: stevelist at silverorange.com (Steven Garrity) Date: Sat, 15 Jan 2005 14:06:46 -0400 Subject: Newer upstream Orinoco drivers Message-ID: <41E95BB6.50407@silverorange.com> Has there been any progress in getting newer upstream Orinoco wireless drivers into Fedora Core? This bug requesting an update for FC2 hasn't been updated since last July: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125282 The newer upstream drivers are required for scanning support with orinoco cards (key for taking advantage of NetworkManager). Thanks, Steven Garrity From arjanv at redhat.com Sat Jan 15 18:47:54 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 15 Jan 2005 19:47:54 +0100 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <1105775365.6300.24.camel@laptopd505.fenrus.org> <1105801856.6300.49.camel@laptopd505.fenrus.org> Message-ID: <1105814874.6300.75.camel@laptopd505.fenrus.org> On Sat, 2005-01-15 at 18:05 +0000, Mike Hearn wrote: > . > > > Example: NPTL threads. > > Code which actually depends on NPTL vs LinuxThreads needs at > minimum configure-time checks for that, or more likely just compliance > fixes. It's also possible to check for it at runtime like Wine does. what I meant was that when you *compile* to a nptl glibc, you actually will not run on and older (linuxthreads) glibc simply because you use symbol versions from the new glibc. > > > There are countless other examples of things that make your app require > > a newer glibc *IF* you build against a new glibc. > > Thread-local locales are the only one that spring to mind, and that's > easily suppressed. And symbol overloading of course. You can work around > that too, symbol overloading like glibc does is broken anyway imho (though > marking symbols with one version tag isn't) it's actually very useful > Building on an old glibc really means "build on an old distro" and that's > unacceptable. Fortunately if you have to define _FORTIFY_SOURCE then it's > OK, that can be selectively disabled. Or alternatively the symbols that > are currently in glibc could be in libgcc or optionally statically > linked, which makes checked binaries a lot easier to distribute. _FORTIFY_SOURCE needs to be specified to be active, so this side of your worries should not be a problem; it's just that your general assumption about compatibility is somewhat problematic. In linux generally there is only unidirectional compatibility; eg old stuff keeps running on newer distributions, but the other way around is mostly if not entirely ignored. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjanv at redhat.com Sat Jan 15 18:48:23 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 15 Jan 2005 19:48:23 +0100 Subject: Newer upstream Orinoco drivers In-Reply-To: <41E95BB6.50407@silverorange.com> References: <41E95BB6.50407@silverorange.com> Message-ID: <1105814903.6300.77.camel@laptopd505.fenrus.org> On Sat, 2005-01-15 at 14:06 -0400, Steven Garrity wrote: > Has there been any progress in getting newer upstream Orinoco wireless > drivers into Fedora Core? has anyone tried to submit them for inclusion in the upstream kernel ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kyrre at solution-forge.net Sat Jan 15 18:49:16 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 15 Jan 2005 19:49:16 +0100 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105790823.4698.134.camel@hostmaster.org> Message-ID: <1105814956.2735.6.camel@localhost.localdomain> l?r, 15.01.2005 kl. 15.28 skrev Felipe Alfaro Solana: > On 15 Jan 2005, at 13:07, Thomas Zehetbauer wrote: > > > On Fri, 2005-01-14 at 17:30 -0500, Bill Nottingham wrote: > >> - Xen and Virtualization > > > > I guess this is only useful for a handful of ISPs who want to sell > > fully > > virtual servers, any only if they can get enough IPv4 addresses. > > Maybe. Currently, I depend heavily on Xen-unstable to run one domain0 > and two isolated domainU. This allows me to reduce power consumption > and consolidate services. And I'm no ISP: I use Xen at home. After reading, i have also got the feeling that it has something to do with CPU partitioning etc. High-performance wmvare :P But yes, it looks great. Finaly i can install a couple of different servers w/o having to have more than one physical box. F.ex. i could want to run two distros at ones - for different purposes. From mike at navi.cx Sat Jan 15 19:43:04 2005 From: mike at navi.cx (Mike Hearn) Date: Sat, 15 Jan 2005 19:43:04 +0000 Subject: Fedora Core 4 References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <1105775365.6300.24.camel@laptopd505.fenrus.org> <1105801856.6300.49.camel@laptopd505.fenrus.org> <1105814874.6300.75.camel@laptopd505.fenrus.org> Message-ID: On Sat, 15 Jan 2005 19:47:54 +0100, Arjan van de Ven wrote: > what I meant was that when you *compile* to a nptl glibc, you actually > will not run on and older (linuxthreads) glibc simply because you use > symbol versions from the new glibc. Right. > it's actually very useful Well, there are two ways to use it. If you use it to tag symbols with a single version specifying when they were introduced, this is useful for lots of reasons. For instance RPM and the linker can figure out minor versions. The problems start when you have one symbol with multiple versions: this is worse than just renaming the symbol because while old *binaries* continue to work, if you then compile the same sources on a newer system they get the new semantics automatically which could break them. Eg take the example of regexec, which has a new overloaded version of GLIBC_2.3.4 - the new version was introduced because now if you specify unknown eflags it returns with error whereas before I guess it didn't. That keeps old binaries working, but what if you then take old code and compile it on a newer system? Well now the code doesn't get the semantics it expects and breaks. The right way to do this IMHO is to just introduce a regexec2 function and then have the headers select the right version at compile time, where the "right" version is based on what version of glibc the program targets as defined by some macro, eg: #define TARGET_GLIBC_MINOR 3 #define TARGET_GLIBC_MICRO 4 // or you could just have an incrementing integer #include now your code is rewritten to use regexec2 and the new behaviour. The changes between each version should be clearly documented so people can read the changes and say "hmm, I seem to remember writing code that did that" and go back and check their source. Meanwhile code is upgraded to the new semantics in a controlled fashion and it's still easy to build against older versions if you don't need or want the new versions. It's also more portable. Likewise it'd be nice if things like thread-local locales were opt-in, really desktop applications don't need this feature at all ... > _FORTIFY_SOURCE needs to be specified to be active, so this side of your > worries should not be a problem; OK, cool. It'd be even better if the __stack_smash symbol[s] (I guess this is what glibc is providing) could be compiled into binaries during the transition period. Of course for distro provided binaries you can have it dynamically linked and one day when most people have upgraded statically linking it wouldn't be needed any more for anybody. > it's just that your general assumption > about compatibility is somewhat problematic. In linux generally there is > only unidirectional compatibility; eg old stuff keeps running on newer > distributions, but the other way around is mostly if not entirely > ignored. Yep I know, been there, done that :) It's a pain. As time goes on I hope to argue that we as a community should do this more how Windows does it, using versioned headers so you can know with confidence exactly what the dependencies of any given build will be. thanks -mike From pedro.lamarao at mndfck.org Sat Jan 15 20:29:08 2005 From: pedro.lamarao at mndfck.org (=?ISO-8859-1?Q?Pedro_Lamar=E3o?=) Date: Sat, 15 Jan 2005 18:29:08 -0200 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <1105775365.6300.24.camel@laptopd505.fenrus.org> <1105801856.6300.49.camel@laptopd505.fenrus.org> <1105814874.6300.75.camel@laptopd505.fenrus.org> Message-ID: <41E97D14.7060007@mndfck.org> Mike Hearn wrote: >The problems start when you have one symbol with multiple versions: this >is worse than just renaming the symbol because while old *binaries* >continue to work, if you then compile the same sources on a newer system >they get the new semantics automatically which could break them. > >Eg take the example of regexec, which has a new overloaded version of >GLIBC_2.3.4 - the new version was introduced because now if you specify >unknown eflags it returns with error whereas before I guess it didn't. > >That keeps old binaries working, but what if you then take old code >and compile it on a newer system? Well now the code doesn't get the >semantics it expects and breaks. > > I believe the point of view of the glibc maintainers is as put by Ulrich Drepper in his paper "Good practices in library design, implementation, and maintenance", chapter three: "One sort of change which should always be made without hesitation is bug fixes. They should be made event if the API is changed. Some people argue that some programs are depending on the old, broken behaviour. But this argumentation is flawed. Equally well there are programs which depend on the correct behaviour, written by people who read the specification. No program which depends on broken behaviour deserves protection. If a programmer has found such a discrepancy and changed the application to use it instead of reporting it to the library maintainer s/he gets what s/he deserves." http://people.redhat.com/drepper/goodpractice.pdf -- Pedro Lamar?o From stevelist at silverorange.com Sat Jan 15 20:33:36 2005 From: stevelist at silverorange.com (Steven Garrity) Date: Sat, 15 Jan 2005 16:33:36 -0400 Subject: Newer upstream Orinoco drivers In-Reply-To: <1105814903.6300.77.camel@laptopd505.fenrus.org> References: <41E95BB6.50407@silverorange.com> <1105814903.6300.77.camel@laptopd505.fenrus.org> Message-ID: <41E97E20.1000308@silverorange.com> Arjan van de Ven wrote: > Steven Garrity wrote: >> Has there been any progress in getting newer upstream Orinoco wireless >> drivers into Fedora Core? > > has anyone tried to submit them for inclusion in the upstream kernel ? A friend answered this for me in IM. Yes, merging into the mainline kernel upstream has begun: http://lkml.org/lkml/2005/1/12/10 Excellent! Thanks, Steven Garrity From alan at redhat.com Sat Jan 15 21:09:45 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 15 Jan 2005 16:09:45 -0500 Subject: Newer upstream Orinoco drivers In-Reply-To: <41E95BB6.50407@silverorange.com> References: <41E95BB6.50407@silverorange.com> Message-ID: <20050115210945.GA3831@devserv.devel.redhat.com> On Sat, Jan 15, 2005 at 02:06:46PM -0400, Steven Garrity wrote: > Has there been any progress in getting newer upstream Orinoco wireless > drivers into Fedora Core? Some stuff has gone into 2.6.11rc1 so hopefully it will get into the base kernel in full soonish. From wtogami at redhat.com Sun Jan 16 03:23:43 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 15 Jan 2005 17:23:43 -1000 Subject: FC3 Pre-Extras for apt Users Message-ID: <41E9DE3F.3070502@redhat.com> /etc/apt/sources.list: rpm http://download.fedora.us/fedora fedora/3/i386 extras Hawaii, USA Mirror rpm http://download.fr.fedora.us/fedora fedora/3/i386 extras France Mirror Pre-Extras currently hosted at http://fedoraproject.org/pre-extras/ is yum metadata only, so I have replicated those packages into the download.fedora.us repository for the convenience of apt users. yum repodata users should continue using http://fedoraproject.org/pre-extras/ instead. http://fedoraproject.org/pre-extras/RPM-GPG-KEY-Fedora-Pre-Extras Import this GPG key for pre-extras packages. download.fedora.us will continue to exist primarily to support apt users of older distributions who depend on the fedora.us Extras. RPMS.updates continues to import updates from download.fedora.redhat.com or the Fedora Legacy project. download.fedora.redhat.com will soon push the official Extras tree. When that happens, RPMS.extras will be populated from that tree instead. Warren Togami wtogami at redhat.com From warren at togami.com Sun Jan 16 03:48:42 2005 From: warren at togami.com (Warren Togami) Date: Sat, 15 Jan 2005 17:48:42 -1000 Subject: Current cpio broken, mangled initrd In-Reply-To: <20050115180801.73b19a14@nausicaa.camperquake.de> References: <20050115180801.73b19a14@nausicaa.camperquake.de> Message-ID: <41E9E41A.2000909@togami.com> Ralf Ertzinger wrote: > Hi. > > Just a head up warning: the cpio version distributed yesterday or today (2.6-1 > or 2.6-2, I am not sure about that) has a bug causing automatic dereferencing > of symlinks while packing. This leads to mangled initrd files when new kernels > are installed. My system curses a lot, but boots nonetheless, others may not > be so lucky :) > > This does not affect initrd images already created, of course. > Filed in bugzilla. > Yikes? Bug #? Always include the bug #. =) Warren From warren at togami.com Sun Jan 16 03:57:01 2005 From: warren at togami.com (Warren Togami) Date: Sat, 15 Jan 2005 17:57:01 -1000 Subject: Fedora Core 4 In-Reply-To: <1105807213.13320.1.camel@cutter> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> Message-ID: <41E9E60D.9080706@togami.com> seth vidal wrote: >>Have you considerer smart : >>http://www.smartpm.org/ >> >>It is Interesting. But sometimes it ignore %{epoch} (for good or bad >>reason it's not the point), does not support group, the gui interface is >>a little confusing. >>Smart is quite fast (python), have gnome, kde, text interface. It's in >>beta/testing stage. > > > At this point smart doesn't have multilib support (at least from reading > of the code) so I'm not sure how useful that will be for a distro > offering (soon, I hope) two multilib archs: x86_64 and ppc64. > It belongs in at least in Extras with ExclusiveArch: i386, ppc. If upstream adds multilib capability later, then the arch support can be expanded. Warren From feliciano.matias at free.fr Sun Jan 16 04:11:06 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sun, 16 Jan 2005 05:11:06 +0100 Subject: Current cpio broken, mangled initrd In-Reply-To: <41E9E41A.2000909@togami.com> References: <20050115180801.73b19a14@nausicaa.camperquake.de> <41E9E41A.2000909@togami.com> Message-ID: <1105848666.1442.5.camel@one.myworld> Le samedi 15 janvier 2005 ? 17:48 -1000, Warren Togami a ?crit : > Ralf Ertzinger wrote: > > Hi. > > > > Just a head up warning: the cpio version distributed yesterday or today (2.6-1 > > or 2.6-2, I am not sure about that) has a bug causing automatic dereferencing > > of symlinks while packing. This leads to mangled initrd files when new kernels > > are installed. My system curses a lot, but boots nonetheless, others may not > > be so lucky :) > > > > This does not affect initrd images already created, of course. > > Filed in bugzilla. > > > > Yikes? Bug #? Always include the bug #. =) > Should be this one : https://bugzilla.redhat.com/beta/show_bug.cgi?id=145225 > Warren > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From wtogami at redhat.com Sun Jan 16 05:16:40 2005 From: wtogami at redhat.com (Warren Togami) Date: Sat, 15 Jan 2005 19:16:40 -1000 Subject: Proposed dovecot update changes Message-ID: <41E9F8B8.4070402@redhat.com> John, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143707 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145214 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145241 Any objections to my proposed changes? I can implement all of this and supply patches for your review, or apply it myself to CVS if you wish. I summarize each problem and my proposed solution below. 1. Unnecessary dependency on mysql/postgresql ============================================= Prereq: postgresql Prereq: mysql These lines are wrong. The package is fine without it, because RPM auto-dep pulls in the client library of mysql and postgresql rather than a larger unnecessary chunk of those databases. These dependencies are resolved properly by yum and handled automatically. Solution: Just remove those lines. 2. dovecot.conf should default to fcntl locking =============================================== https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145214#c7 Our default dovecot.conf changed from fcntl to dotlock sometime after the release of FC2. That is one of the reasons why we see this above bug. This problem must now be attacked on two fronts: 1) Our default dovecot.conf must be changed to use fcntl by default again. If someone uses a broken NFS where fcntl doesn't work, then it is up them to edit their configuration to use dotlocks. If users have not modified dovecot.conf, then upgrading to the new package will set fcntl default. 2) For exisiting users who have modified dovecot.conf, it would be dangerous to force a change to fcntl during %post. Then "mail_extra_groups = mail" is the correct line to add durin 3. FC2 should not link to mysql/postgresql (???) ================================================ https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145241#c1 FC2 dovecot originally did not link to mysql and postgresql, so arguably we should not add those dependencies in an update. Unfortunately our current FC2 update is linked in this way, so we would be breaking existing users if they did begin using this functionality in FC2. I am guessing that the likelihood of this is very low and we should go ahead. (However we could just as easily leave it as is, then it would only be a minor annoyance rather than a real problem.) FC3 dovecot did link to mysql/postgresql libs, so we must not change that or split into sub-packages because then an update would break existing users. FC4 we have the option of splitting mysql/postgresql into sub-packages, which is probably the correct thing to do based on the php precedent. Thoughts? Warren Togami wtogami at redhat.com From pri.rhl3 at iadonisi.to Sun Jan 16 06:13:23 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Sun, 16 Jan 2005 01:13:23 -0500 Subject: Current cpio broken, mangled initrd In-Reply-To: <1105848666.1442.5.camel@one.myworld> References: <20050115180801.73b19a14@nausicaa.camperquake.de> <41E9E41A.2000909@togami.com> <1105848666.1442.5.camel@one.myworld> Message-ID: <1105856003.13008.0.camel@va.local.linuxlobbyist.org> On Sun, 2005-01-16 at 05:11 +0100, F?liciano Matias wrote: > > > > Yikes? Bug #? Always include the bug #. =) > > > > Should be this one : > https://bugzilla.redhat.com/beta/show_bug.cgi?id=145225 Check the latest comment in the bug. I think I tracked the problem down. Frankly, it looks like half finished code. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From lists at arctur.us Sun Jan 16 07:27:47 2005 From: lists at arctur.us (Mitch Skinner) Date: Sat, 15 Jan 2005 23:27:47 -0800 Subject: Fedora Core 4 In-Reply-To: <1105790823.4698.134.camel@hostmaster.org> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105790823.4698.134.camel@hostmaster.org> Message-ID: <1105860468.3978.38.camel@zeitgeist> On Sat, 2005-01-15 at 13:07 +0100, Thomas Zehetbauer wrote: > On Fri, 2005-01-14 at 17:30 -0500, Bill Nottingham wrote: > > - Xen and Virtualization > > I guess this is only useful for a handful of ISPs who want to sell fully > virtual servers, any only if they can get enough IPv4 addresses. I've always wanted to test fedora betas, but I only have one box :) From max_list at fedorafaq.org Sun Jan 16 07:34:50 2005 From: max_list at fedorafaq.org (Max Kanat-Alexander) Date: Sat, 15 Jan 2005 23:34:50 -0800 Subject: Fedora Core 4 In-Reply-To: <20050115014013.GA19719@devserv.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <20050115014013.GA19719@devserv.devel.redhat.com> Message-ID: <1105860890.4098.18.camel@max.localdomain> On Fri, 2005-01-14 at 20:40 -0500, Alan Cox wrote: > There is a Windows port for Xen but Microsoft haven't released it I've seen a Microsoft product called Microsoft Virtual Server. So that would probably explain why they don't have a Xen port released. -Max From mpeters at mac.com Sun Jan 16 09:14:50 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 16 Jan 2005 09:14:50 +0000 Subject: Fedora Core 4 In-Reply-To: <1105814956.2735.6.camel@localhost.localdomain> (from kyrre@solution-forge.net on Sat Jan 15 10:49:16 2005) References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105790823.4698.134.camel@hostmaster.org> <1105814956.2735.6.camel@localhost.localdomain> Message-ID: <1105866890l.6508l.1l@devel.mpeters.us> On 01/15/2005 10:49:16 AM, Kyrre Ness Sjobak wrote: > > But yes, it looks great. Finaly i can install a couple of different > servers w/o having to have more than one physical box. F.ex. i could > want to run two distros at ones - for different purposes. slightly off topic - where I use to work, the policy was we ran RH 7.x One employee wanted slackware, but RH 7.x was the policy (I think because of patch policy). We did have root on our own boxes, though - so he installed slackware and ran it through a chroot in RH7, and even had X working in the chroot. I suppose this could be used for that too ;) From mpeters at mac.com Sun Jan 16 09:16:55 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 16 Jan 2005 09:16:55 +0000 Subject: Fedora Core 4 In-Reply-To: <20050114223020.GA7168@nostromo.devel.redhat.com> (from notting@redhat.com on Fri Jan 14 14:30:20 2005) References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <1105867015l.6508l.2l@devel.mpeters.us> Will there be support for jigdo distribution of iso files? jigdo would make updating test releases and then to final fc4 much easier/less bandwidth. From fedora-devel at camperquake.de Sun Jan 16 12:35:29 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Sun, 16 Jan 2005 13:35:29 +0100 Subject: Fedora Core 4 In-Reply-To: <1105866890l.6508l.1l@devel.mpeters.us> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105790823.4698.134.camel@hostmaster.org> <1105814956.2735.6.camel@localhost.localdomain> <1105866890l.6508l.1l@devel.mpeters.us> Message-ID: <20050116133529.51d9b59e@nausicaa.camperquake.de> Hi. "Michael A. Peters" wrote: > We did have root on our own boxes, though - so he installed slackware > and ran it through a chroot in RH7, and even had X working in the > chroot. This works as long as the kernels are similar enough. I doubt you could make FC2 work in a FC1 chroot, for example. > I suppose this could be used for that too ;) And it gives you your own kernel. -- "I regret to say that we of the FBI are powerless to act in cases of oral-genital intimacy, unless it has in some way obstructed interstate commerce." -- J. Edgar Hoover From mike at navi.cx Sun Jan 16 12:49:32 2005 From: mike at navi.cx (Mike Hearn) Date: Sun, 16 Jan 2005 12:49:32 +0000 Subject: Fedora Core 4 References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <1105775365.6300.24.camel@laptopd505.fenrus.org> <1105801856.6300.49.camel@laptopd505.fenrus.org> <1105814874.6300.75.camel@laptopd505.fenrus.org> <41E97D14.7060007@mndfck.org> Message-ID: On Sat, 15 Jan 2005 18:29:08 -0200, Pedro Lamar?o wrote: > I believe the point of view of the glibc maintainers is as put by Ulrich > Drepper in his paper "Good practices in library design, implementation, > and maintenance", chapter three: I think they are unrelated issues - bugfixes are important, but symbol versioning as implemented in the GNU toolchain is flawed because it ignores the possibility of people compiling old sources on new systems (something that happens all the time ...). So regardless of peoples views on bugfixing, I think overloading symbols with multiple versions is a bad idea (or rather, the linker always selecting the latest version is a bad idea). And actually I'd disagree with Ulrichs view. Bug-free software isn't an end itself, it's a means to an end. Sometimes the cost:benefit analysis of fixing a bug just doesn't add up, and in that case it makes more sense to simply document the buggy behaviour than fix it. This is especially true in 99% of libraries which unlike glibc do not have to match a pre-written specification (effectively, the librariy *is* the specification). thanks -mike From laroche at redhat.com Sun Jan 16 13:19:10 2005 From: laroche at redhat.com (Florian La Roche) Date: Sun, 16 Jan 2005 14:19:10 +0100 Subject: Fedora Core 4 In-Reply-To: <41E8D95E.5010809@freemail.hu> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <41E8D95E.5010809@freemail.hu> Message-ID: <20050116131910.GA1933@dudweiler.stuttgart.redhat.com> > More complete bi-arch support on 64-bit at least AMD64? > On FC3, at least /usr/include/kde/arts/gsl/gslconfig.h in > arts-devel (.i386 and .x86_64) conflict, after inspecting both, > one of the #defines differs, so it's not only a packaging problem. > But I have seen other headers that include arch dependent stuff > from /usr/include/asm-i386 or /usr/include/asm-x86_64, respectively. > > Ultimately, I would like to be able to install both -libs > and -devel as the latter may contain static libs in either > /usr/lib or /usr/lib64. Maybe there should be a -headers > that contains the common stuff between the arch dependent -devel RPM. > > Hm. Anaconda or firstboot support to install all the .i386 versions of > the above on x86-64 would be nice. I don't mind downloading all the > 2x N disks for FC4, I installed both versions of FC3 on different > machines, too. Can you please check out the posting from Miloslav and start filing bugzilla requests and maybe also patches to clean up the important base libraries for this? From: Miloslav Trmac Subject: Differences in headers between i386 and x86_64 To: fedora-devel-list at redhat.com Date: Sat, 7 Aug 2004 05:04:12 +0200 greetings, Florian La Roche From kyrre at solution-forge.net Sun Jan 16 13:08:03 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 16 Jan 2005 14:08:03 +0100 Subject: Fedora Core 4 In-Reply-To: <1105860890.4098.18.camel@max.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <20050115014013.GA19719@devserv.devel.redhat.com> <1105860890.4098.18.camel@max.localdomain> Message-ID: <1105880882.3722.0.camel@localhost.localdomain> s?n, 16.01.2005 kl. 08.34 skrev Max Kanat-Alexander: > On Fri, 2005-01-14 at 20:40 -0500, Alan Cox wrote: > > There is a Windows port for Xen but Microsoft haven't released it > > I've seen a Microsoft product called Microsoft Virtual Server. So that > would probably explain why they don't have a Xen port released. > > -Max > Just wondering: how will you controll different viritual servers? How will the U/I be? From sitsofe at gmail.com Sun Jan 16 13:17:30 2005 From: sitsofe at gmail.com (Sitsofe Wheeler) Date: Sun, 16 Jan 2005 13:17:30 +0000 (UTC) Subject: Dmix (Fedora Core 4) References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: Bill Nottingham redhat.com> writes: > Probably other stuff that I'm forgetting in here. I'm sure > more people can remind me. Any chance that defaulting alsa to use dmix on those cards that don't do hardware mixing was one of the things overlooked? Setting up dmix is moderately painful but hopefully with mass testing most cards can be made to do the right thing... From fedora-devel at camperquake.de Sun Jan 16 13:27:24 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Sun, 16 Jan 2005 14:27:24 +0100 Subject: Dmix (Fedora Core 4) In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <20050116142724.400d54aa@nausicaa.camperquake.de> Hi. Sitsofe Wheeler wrote: > hardware mixing was one of the things overlooked? Setting up dmix is > moderately painful but hopefully with mass testing most cards can be > made to do the right thing... Using the latest alsa packages from rawhide, just put pcm.!default { type plug slave.pcm "asym" } into either ~/.asoundrc or /etc/asoundrc. Previous alsa versions use dmix instead of asym, but do not get recording abilities on the default device. -- Leichen sind Menschen wie Du und ich, nur tot. From buildsys at redhat.com Sun Jan 16 13:34:02 2005 From: buildsys at redhat.com (Build System) Date: Sun, 16 Jan 2005 08:34:02 -0500 Subject: rawhide report: 20050116 changes Message-ID: <200501161334.j0GDY2O20463@porkchop.devel.redhat.com> Updated Packages: exim-4.44-1 ----------- * Sat Jan 15 2005 David Woodhouse 4.44-1 - Update to Exim 4.44 and exiscan-acl-4.44-28 gimp-help-2-0.1.0.6.1 --------------------- * Sat Jan 15 2005 Nils Philippsen - version 2-0.6 mysql-4.1.9-1 ------------- * Sat Jan 15 2005 Tom Lane 4.1.9-1 - Update to MySQL 4.1.9. rpmdb-fedora-1:4-0.20050116 --------------------------- tcsh-6.13-10 ------------ * Sat Jan 15 2005 Miloslav Trmac - 6.13-10 - Avoid reusing iconv_catgets' static buffer (#145177, #145195) From n3npq at nc.rr.com Sun Jan 16 14:13:04 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sun, 16 Jan 2005 09:13:04 -0500 Subject: Current cpio broken, mangled initrd In-Reply-To: <1105856003.13008.0.camel@va.local.linuxlobbyist.org> References: <20050115180801.73b19a14@nausicaa.camperquake.de> <41E9E41A.2000909@togami.com> <1105848666.1442.5.camel@one.myworld> <1105856003.13008.0.camel@va.local.linuxlobbyist.org> Message-ID: <41EA7670.5090001@nc.rr.com> Paul Iadonisi wrote: >On Sun, 2005-01-16 at 05:11 +0100, F?liciano Matias wrote: > > > >>>Yikes? Bug #? Always include the bug #. =) >>> >>> >>> >>Should be this one : >>https://bugzilla.redhat.com/beta/show_bug.cgi?id=145225 >> >> > > Check the latest comment in the bug. I think I tracked the problem >down. Frankly, it looks like half finished code. > > cpio half finished code? hehe, not likely. Looks more like autocrap churn, delete a configure.ac test, lose a #define, and sh*t happens. zlib support into file(1) one of many bugs caused by similar churn. 73 de Jeff From mbneto at gmail.com Sun Jan 16 14:15:05 2005 From: mbneto at gmail.com (mbneto) Date: Sun, 16 Jan 2005 10:15:05 -0400 Subject: Yum/apt sources for rawhide ? Message-ID: <5cf776b80501160615fe5193b@mail.gmail.com> Hi, I was wondering if there is an apt/yum source so I can try rawhide (pre-FC4?) packages... thanks. From ad+lists at uni-x.org Sun Jan 16 14:24:11 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Sun, 16 Jan 2005 15:24:11 +0100 Subject: Yum/apt sources for rawhide ? In-Reply-To: <5cf776b80501160615fe5193b@mail.gmail.com> References: <5cf776b80501160615fe5193b@mail.gmail.com> Message-ID: <1105885451.6970.146.camel@serendipity.dogma.lan> Am So, den 16.01.2005 schrieb mbneto um 15:15: > I was wondering if there is an apt/yum source so I can try rawhide > (pre-FC4?) packages... There is. Running FC3 look into /etc/yum-repos.d/ and you will find a repo file for development/rawhide which is disabled by default. Of course, you should use a nearby mirror server. To prevent headaches: use development only on a test system (at least if development state is not in FC test release period or short in front of a stable FC release). Alexander -- Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.10-1.9_FC2smp Serendipity 15:19:56 up 1 day, 22:42, load average: 0.35, 0.34, 0.28 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From sitsofe at yahoo.com Sun Jan 16 14:51:38 2005 From: sitsofe at yahoo.com (Sitsofe Wheeler) Date: Sun, 16 Jan 2005 14:51:38 +0000 Subject: Dmix (Fedora Core 4) In-Reply-To: <20050116142724.400d54aa@nausicaa.camperquake.de> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <20050116142724.400d54aa@nausicaa.camperquake.de> Message-ID: <1105887099.9959.20.camel@galvatron.localdomain> On Sun, 2005-01-16 at 14:27 +0100, Ralf Ertzinger wrote: > pcm.!default { > type plug > slave.pcm "asym" > } > > into either ~/.asoundrc or /etc/asoundrc. Previous alsa versions use > dmix instead of asym, but do not get recording abilities on the default > device. I believe the above already works with FC3 and allows full duplex (record and playback at the same time) PCM but does not address the need for software mixing of multiple output streams (e.g. the case of playing music while still hearing IM event sounds) which is what I'm thinking of (although please correct me if I am wrong). By enabling dmix on *those cards that need it* (why waste CPU on cards that can already handle this?), existing software mixers like esound can be phased out for local mixing in favour of alsa mixing. I may have bad configuration but dmix produced superior results to esound when playing the SDL game rRootage (which plays music and sound effects at the same time). The quality sounded better and the sound did not lag 2 seconds behind the action. However setting up dmix appropriately seems to vary from card to card and many apps (bzflag, helixplayer) are still stuck with only OSS output. Moving these apps over to alsa (or perhaps esound if they want to support legacy mixing/network sound) would be sensible. From fedora-devel at camperquake.de Sun Jan 16 15:09:05 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Sun, 16 Jan 2005 16:09:05 +0100 Subject: Dmix (Fedora Core 4) In-Reply-To: <1105887099.9959.20.camel@galvatron.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <20050116142724.400d54aa@nausicaa.camperquake.de> <1105887099.9959.20.camel@galvatron.localdomain> Message-ID: <20050116160905.5f7ee091@nausicaa.camperquake.de> Hi. Sitsofe Wheeler wrote: > for software mixing of multiple output streams (e.g. the case of playing > music while still hearing IM event sounds) which is what I'm thinking of > (although please correct me if I am wrong). This works. Just tell the gstreamer system to use alsa as audio sink (Preferences->More Preferences->Multimedia Systems Selector) -- "World domination. Fast." -- Linus Torvalds From lfarkas at bppiac.hu Sun Jan 16 15:36:58 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Sun, 16 Jan 2005 16:36:58 +0100 Subject: Fedora Core 4 In-Reply-To: <20050114223020.GA7168@nostromo.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <41EA8A1A.1030601@bppiac.hu> Bill Nottingham wrote: > A Fedora Core 4 proto-schedule is available at: > > http://fedora.redhat.com/participate/schedule/ > > Generally, it's 3 4-week test releases, with a release in early/mid May. > > So, what's planned for Fedora Core 4? Here's what we're looking > at from the Red Hat side of things: > - PPC support > > For your brand spanking new MiniMac, or the p655 under your > desk. it it possible to merge auroralinux's (which is a fedora fork) changes back to the main fedora release? ie. to be able to use fedora on sparc too? spot working hard on it (and he's also at rh:-) -- Levente "Si vis pacem para bellum!" From fedora at wir-sind-cool.org Sun Jan 16 16:04:48 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 16 Jan 2005 17:04:48 +0100 Subject: Extras package submissions and general thoughts Message-ID: <20050116170448.6f174fa2.fedora@wir-sind-cool.org> Hi everyone, in particular those involved at fedora.us and pre-Extras! While Fedora Extras is still being prepared, here are some thoughts which accumulated over the past few days: PACKAGE SUBMISSIONS The official package submission policies and workflow for Fedora Extras are not known yet. Those who have submitted new packages at bugzilla.redhat.com instead of bugzilla.fedora.us are too early. At fedora.us we've had at least a documented procedure. In bugzilla at redhat.com we don't. But as some form of guidance, please do not ignore existing fedora.us documents completely. There's a good bit of information included with regard to package QA and packaging hints. PACKAGE REQUESTS Every package in Fedora Extras needs at least one maintainer (read: package owner). It is beyond the existing project resources to pick up arbitrary packages found on web sites. If you have a wish list of what ought to be included, discuss this on fedora-extras-list please and maybe somebody steps up as the package maintainer. Naturally, those fine people who support upstream projects with Fedora Core specific packages, are likely the candidates who would also like to maintain a package in Fedora Extras. UNMOTIVATED PACKAGERS It is a pain trying to support new contributors and their package submissions, when someone doesn't reply to feedback or seems to drop off after a first submission. If you decide to stay away or not maintain your included package anymore, please be so fair and inform the project members and the community, so an unmaintained package can be removed or taken over by somebody else. Included packages at some point of time had been reviewed and approved. It would be a pitty to lose them. Whether due to impatience, whether due to disappointment of Fedora Extras progress, whether due to intricate procedures and workflow management, please only join and submit packages or contributions if you are serious about supporting the project, even during somewhat difficult times. It should be clear that with limited infrastructure (such as type of build system and access to it, bugzilla upload procedures instead of direct CVS access), it would be necessary to bridge the period of time till Fedora Extras provides superior infrastructure. EXISTING PACKAGE SUBMISSIONS, http://fedora.us/QA With regard to the many packages in the queue, there has been no slavedriver at fedora.us who forces contributors to review arbitrary packages. At fedora.us we're all volunteers. But the package submission policies recommend that in order to gain experience and trust, packagers should exchange reviews with eachother. Where that doesn't happen and where nobody reviews a package, no progress is made. PACKAGE UPDATES, Fedora pre-Extras Since only a handful of project contributors outside Red Hat have write access to the Fedora Extras CVS till official ways for getting access are announced, it would be necessary that existing package owners approach one of these when they want to commit updates. You should be able to do that via bugzilla Cc or private mail. If I'm informed correctly, the six people (and their bugzilla e-mail addresses) are: Damien Nade Phillip Compton Matthias Saou Michael Schwendt Ville Skytt? Thomas Vander Stichele The list of current package owners can be displayed in bugzilla. PACKAGE UPGRADES, Fedora pre-Extras Where version upgrades are requested or suggested by users, we need to find new ways of doing QA. For instance, library upgrades affect all existing dependencies, and these are not always maintained by the same person. If not in bugzilla, communication channels outside bugzilla (e.g. on fedora-extras-list) need to be established. Michael -- Fedora Core release 2 (Tettnang) - Linux 2.6.10-1.9_FC2 loadavg: 0.38 0.98 0.95 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lfarkas at bppiac.hu Sun Jan 16 16:25:36 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Sun, 16 Jan 2005 17:25:36 +0100 Subject: Proposed dovecot update changes In-Reply-To: <41E9F8B8.4070402@redhat.com> References: <41E9F8B8.4070402@redhat.com> Message-ID: <41EA9580.3010604@bppiac.hu> Warren Togami wrote: > John, > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143707 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145214 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145241 > > Any objections to my proposed changes? I can implement all of this and > supply patches for your review, or apply it myself to CVS if you wish. I > summarize each problem and my proposed solution below. > > 1. Unnecessary dependency on mysql/postgresql > ============================================= > Prereq: postgresql > Prereq: mysql > > These lines are wrong. The package is fine without it, because RPM > auto-dep pulls in the client library of mysql and postgresql rather than > a larger unnecessary chunk of those databases. These dependencies are > resolved properly by yum and handled automatically. > > Solution: Just remove those lines. > > > 2. dovecot.conf should default to fcntl locking > =============================================== > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145214#c7 > Our default dovecot.conf changed from fcntl to dotlock sometime after > the release of FC2. That is one of the reasons why we see this above > bug. This problem must now be attacked on two fronts: > > 1) Our default dovecot.conf must be changed to use fcntl by default > again. If someone uses a broken NFS where fcntl doesn't work, then it > is up them to edit their configuration to use dotlocks. If users have > not modified dovecot.conf, then upgrading to the new package will set > fcntl default. > > 2) For exisiting users who have modified dovecot.conf, it would be > dangerous to force a change to fcntl during %post. Then > "mail_extra_groups = mail" is the correct line to add durin > > > 3. FC2 should not link to mysql/postgresql (???) > ================================================ > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145241#c1 > > FC2 dovecot originally did not link to mysql and postgresql, so arguably > we should not add those dependencies in an update. Unfortunately our > current FC2 update is linked in this way, so we would be breaking > existing users if they did begin using this functionality in FC2. I am > guessing that the likelihood of this is very low and we should go ahead. > (However we could just as easily leave it as is, then it would only be > a minor annoyance rather than a real problem.) > > FC3 dovecot did link to mysql/postgresql libs, so we must not change > that or split into sub-packages because then an update would break > existing users. > > FC4 we have the option of splitting mysql/postgresql into sub-packages, > which is probably the correct thing to do based on the php precedent. > > Thoughts? correct. -- Levente "Si vis pacem para bellum!" From cmadams at hiwaay.net Sun Jan 16 16:33:49 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Sun, 16 Jan 2005 10:33:49 -0600 Subject: Fedora Core 4 In-Reply-To: <20050116133529.51d9b59e@nausicaa.camperquake.de> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105790823.4698.134.camel@hostmaster.org> <1105814956.2735.6.camel@localhost.localdomain> <1105866890l.6508l.1l@devel.mpeters.us> <20050116133529.51d9b59e@nausicaa.camperquake.de> Message-ID: <20050116163349.GA1397307@hiwaay.net> Once upon a time, Ralf Ertzinger said: > "Michael A. Peters" wrote: > > We did have root on our own boxes, though - so he installed slackware > > and ran it through a chroot in RH7, and even had X working in the > > chroot. > > This works as long as the kernels are similar enough. I doubt you could > make FC2 work in a FC1 chroot, for example. It probably does work, more or less. On one system, I ran anaconda from FC2 under FC1 to install to unused partitions. I then mounted the partitions, got everything configured, and rebooted to switch from FC1 to FC2. Anaconda was a little cranky, spit out a few odd errors, and misconfigured a couple of kernel modules (things that had changed), but it worked. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jwboyer at jdub.homelinux.org Sun Jan 16 16:34:18 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 16 Jan 2005 10:34:18 -0600 Subject: Fedora Core 4 In-Reply-To: <20050115023612.GB6407@nostromo.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <20050114233118.GD5200@plain.rackshack.net> <20050115023612.GB6407@nostromo.devel.redhat.com> Message-ID: <1105893258.16242.25.camel@jdub.homelinux.org> On Fri, 2005-01-14 at 21:36 -0500, Bill Nottingham wrote: > Rudi Chiarito (nutello at sweetness.com) said: > > > - PPC support > > > For your brand spanking new MiniMac, or the p655 under your > > > desk. > > > > I assume the mention of the p655 means support for ppc AND ppc64? Just > > asking for a clarification. It's not clear right now which kind of > > PPC64 hardware can be used for a fresh install. I know because I was > > checking Raw Hide this very morning. > > I believe that's the plan. Note that not *all* 32 or 64-bit PPCs > may be supported; I wouldn't expect 32-bit RS6Ks to work, for example. Hmm, that's not because there is lack of interest in those machines. There are at least a couple of us that are 100% willing to be testers. I think all we're really missing is a boot.iso that groks a 32-bit CHRP machine (for the 43p-150 RS6Ks anyway). Paul Nasrat gave me one a while ago that booted the kernel, but didn't understand the initrd for some reason. Others have a kernel, but no knowledge on how to spin a boot.iso. Is there a huge potential user base for these machines? I doubt it. But it would be cool for those of us still running old copies of SuSE or Debian. Can I assume it's mostly just a lack of time that would prevent these machines from being supported, or is there some other technical reason that I'm missing? josh From ghenry at suretecsystems.com Sun Jan 16 16:48:15 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sun, 16 Jan 2005 16:48:15 -0000 (GMT) Subject: Extras package submissions and general thoughts In-Reply-To: <20050116170448.6f174fa2.fedora@wir-sind-cool.org> References: <20050116170448.6f174fa2.fedora@wir-sind-cool.org> Message-ID: <41050.192.168.100.90.1105894095.squirrel@webmail.suretecsystems.com> > PACKAGE REQUESTS > > Every package in Fedora Extras needs at least one maintainer (read: > package owner). It is beyond the existing project resources to pick up > arbitrary packages found on web sites. If you have a wish list of what > ought to be included, discuss this on fedora-extras-list please and > maybe somebody steps up as the package maintainer. I maintain Swatch, and apologise for my slowness in testing for the final Extras release. I do still want to look after it, so please bear with me. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1467 624141 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From sitsofe at yahoo.com Sun Jan 16 16:57:49 2005 From: sitsofe at yahoo.com (Sitsofe Wheeler) Date: Sun, 16 Jan 2005 16:57:49 +0000 Subject: Dmix (Fedora Core 4) In-Reply-To: <20050116160905.5f7ee091@nausicaa.camperquake.de> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <20050116142724.400d54aa@nausicaa.camperquake.de> <1105887099.9959.20.camel@galvatron.localdomain> <20050116160905.5f7ee091@nausicaa.camperquake.de> Message-ID: <1105894669.9959.35.camel@galvatron.localdomain> On Sun, 2005-01-16 at 16:09 +0100, Ralf Ertzinger wrote: > > for software mixing of multiple output streams (e.g. the case of playing > > music while still hearing IM event sounds) which is what I'm thinking of > > (although please correct me if I am wrong). > > This works. Just tell the gstreamer system to use alsa as audio sink > (Preferences->More Preferences->Multimedia Systems Selector) Sounds good! I tried upgrading my alsa libraries on an FC3 box with alsa-lib-1.0.7-3.devel.i386.rpm but it just caused sound to break on the (virtual) console I was using (first it moaned about a missing key and then after I thew away the .asoundrc file alsa support in ogg123 stopped working and started spewing messages). I've downgraded back to the FC3 packages and sound works again. It does appear that DMix software mixing will be on by default in FC4 for everybody (a shame for soundcard owners who have hardware mixing but to be fair they are in the minority). Here's a link to discussion about how some of the difficulties implementing it are being overcome: http://www.redhat.com/archives/fedora-desktop-list/2005-January/msg00011.html From rjune at bravegnuworld.com Sun Jan 16 16:55:50 2005 From: rjune at bravegnuworld.com (Richard June) Date: Sun, 16 Jan 2005 11:55:50 -0500 Subject: Fedora Core 4 In-Reply-To: <20050116133529.51d9b59e@nausicaa.camperquake.de> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105866890l.6508l.1l@devel.mpeters.us> <20050116133529.51d9b59e@nausicaa.camperquake.de> Message-ID: <200501161202.09046.rjune@bravegnuworld.com> On Sunday 16 January 2005 07:35, Ralf Ertzinger wrote: > Hi. > > "Michael A. Peters" wrote: > > We did have root on our own boxes, though - so he installed slackware > > and ran it through a chroot in RH7, and even had X working in the > > chroot. > > This works as long as the kernels are similar enough. I doubt you could > make FC2 work in a FC1 chroot, for example. Well, I ran old Loki games in a rh7.3 chroot on a fc2 box, worked well. updated to fc3 though and it don't work anymore. keeps saying it can't talk to the X server. -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kyrre at solution-forge.net Sun Jan 16 17:21:05 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 16 Jan 2005 18:21:05 +0100 Subject: Fedora Core 4 In-Reply-To: <200501161202.09046.rjune@bravegnuworld.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105866890l.6508l.1l@devel.mpeters.us> <20050116133529.51d9b59e@nausicaa.camperquake.de> <200501161202.09046.rjune@bravegnuworld.com> Message-ID: <1105896064.3722.2.camel@localhost.localdomain> Now or a year from now, a "new loki" could probably shine... Shame they are dead! s?n, 16.01.2005 kl. 17.55 skrev Richard June: > On Sunday 16 January 2005 07:35, Ralf Ertzinger wrote: > > Hi. > > > > "Michael A. Peters" wrote: > > > We did have root on our own boxes, though - so he installed slackware > > > and ran it through a chroot in RH7, and even had X working in the > > > chroot. > > > > This works as long as the kernels are similar enough. I doubt you could > > make FC2 work in a FC1 chroot, for example. > Well, I ran old Loki games in a rh7.3 chroot on a fc2 box, worked well. > updated to fc3 though and it don't work anymore. keeps saying it can't talk to > the X server. From s.mako at gmx.net Sun Jan 16 17:40:25 2005 From: s.mako at gmx.net (Zoltan Kota) Date: Sun, 16 Jan 2005 18:40:25 +0100 (CET) Subject: website update Message-ID: Hi, Could somebody update the list of mailing lists at fedora.redhat.com -> Communicate? Fedora Extras and some of the fedora-trans-xy related lists are missing (at least). A menu for CVS would be also nice. Zoltan From terraformers at gmx.net Sun Jan 16 18:11:28 2005 From: terraformers at gmx.net (Lars) Date: Sun, 16 Jan 2005 19:11:28 +0100 Subject: website update References: Message-ID: Zoltan Kota wrote: > Hi, > > Could somebody update the list of mailing lists at fedora.redhat.com -> > Communicate? Fedora Extras and some of the fedora-trans-xy related lists > are missing (at least). > A menu for CVS would be also nice. > > Zoltan > > ...and registering the missing lists with gmane.org for easy tracking via newsreader would be nice too! best L From pri.rhl3 at iadonisi.to Sun Jan 16 19:23:27 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Sun, 16 Jan 2005 14:23:27 -0500 Subject: Current cpio broken, mangled initrd In-Reply-To: <41EA7670.5090001@nc.rr.com> References: <20050115180801.73b19a14@nausicaa.camperquake.de> <41E9E41A.2000909@togami.com> <1105848666.1442.5.camel@one.myworld> <1105856003.13008.0.camel@va.local.linuxlobbyist.org> <41EA7670.5090001@nc.rr.com> Message-ID: <1105903407.4544.2.camel@va.local.linuxlobbyist.org> On Sun, 2005-01-16 at 09:13 -0500, Jeff Johnson wrote: > Paul Iadonisi wrote: [snip] > > > > Check the latest comment in the bug. I think I tracked the problem > >down. Frankly, it looks like half finished code. > > > > > > cpio half finished code? hehe, not likely. > > Looks more like autocrap churn, delete a configure.ac test, lose a #define, > and sh*t happens. zlib support into file(1) one of many bugs caused by > similar churn. Sorry. Didn't mean to imply that the entirety of cpio was half finished. Just whatever change introduced that '#if !HAVE_LSTAT ...' block was half done. Basically, yeah, what you said. ;-) -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From rjune at bravegnuworld.com Sun Jan 16 21:06:03 2005 From: rjune at bravegnuworld.com (Richard June) Date: Sun, 16 Jan 2005 16:06:03 -0500 Subject: Fedora Core 4 In-Reply-To: <1105896064.3722.2.camel@localhost.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <200501161202.09046.rjune@bravegnuworld.com> <1105896064.3722.2.camel@localhost.localdomain> Message-ID: <200501161606.06649.rjune@bravegnuworld.com> On Sunday 16 January 2005 12:21, Kyrre Ness Sjobak wrote: > Now or a year from now, a "new loki" could probably shine... Shame they > are dead! I agree, altough that sounds suspiciously like you don't know why it don't work anymore. :-) -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora-devel-list at cygnusx-1.org Sun Jan 16 22:20:22 2005 From: fedora-devel-list at cygnusx-1.org (Nathan G. Grennan) Date: Sun, 16 Jan 2005 14:20:22 -0800 Subject: Building rpms on AMD64 In-Reply-To: References: <3077b8a0050114090023076a3f@mail.gmail.com> <41E80325.6070303@research.att.com> <1105724504.3944.36.camel@cutter> Message-ID: <1105914022.5205.26.camel@proton.cygnusx-1.org> > > with rpm you can do: > > > > rpm -e name.arch > > > > with yum you can do the same: > > > > yum remove name.arch > An even better way to remove them all at once. rpm -qa --queryformat="%{name}-%{version}-%{release}.%{arch}\n" | grep devel | grep i386 | xargs rpm -e > Yet another problem: On a system with dual x86_64 and i386 libraries many > rpms are installed by default for both architectures, an example is > mozilla, the default install of FC3 contains these: > > mozilla-1.7.3-17.x86_64.rpm > mozilla-chat-1.7.3-17.x86_64.rpm > mozilla-devel-1.7.3-17.x86_64.rpm > mozilla-dom-inspector-1.7.3-17.x86_64.rpm > mozilla-js-debugger-1.7.3-17.x86_64.rpm > mozilla-mail-1.7.3-17.x86_64.rpm > mozilla-nspr-1.7.3-17.i386.rpm > mozilla-nspr-1.7.3-17.x86_64.rpm > mozilla-nspr-devel-1.7.3-17.x86_64.rpm > mozilla-nss-1.7.3-17.i386.rpm > mozilla-nss-1.7.3-17.x86_64.rpm > mozilla-nss-devel-1.7.3-17.x86_64.rpm > mozplugger-1.6.2-1.x86_64.rpm > > Here mozilla-nspr and mozilla-nss are for both architectures - the problem > is: If one builds updates for x86_64 how does one easily determine what > packages that also must be created for i386? > The building is controlled by what devel package files it finds. So if you only have devel packages for x86_64 installed, then it just works. > > I have problems creating the i386 packages anyway, for example: > > # setarch i386 rpmbuild --target i386 > Clearly something triggers setup for the wrong platform in this case, at > configure looks in the lib64 directories. > > This "works" though: > > # rpmbuild --target i386 --rebuild mozilla-1.7.5-3.src.rpm > > However the resulting rpm is not okay at all: > > # rpm -qpl mozilla-nspr-1.7.5-3.i386.rpm > /usr/lib64/libnspr4.so > /usr/lib64/libplc4.so > /usr/lib64/libplds4.so > > > Life on the combined x86_64 / i386 architecture seems a bit confusing to me so far :-( I fixed this issue by compiling i386 stuff on a i686 box at work. Pretty much the only things I wanted i386 were mozilla and galeon packages. Other things like mplayer I just installed the i386 version with yum from a repository. I have libonobo is installed for both 32bit and 64bit. One of the files in the packages in /usr/libexec/bonobo-activation-server. It is a 64bit executable. It tries to load /usr/lib64/bonobo/servers/GNOME_Galeon_Automation.server for the 32bit galeon which puts it in /usr/lib. So it isn't search both /usr/lib and /usr/lib64 like it should. This also brings up the issue of a lot of bad placement. GNOME_Galeon_Automation.server is a text file, so shouldn't it be in /usr/share or something else anyway. When I asked a galeon developer he said, yes, but that is where bonobo expects it. A galeon developer told me 32bit gtk programs on an FC3 x86_64 system were completely broken. When I asked for detail, he said that 32bit gtk programs trying to use libpixbuf would try to load 64bit themes. From walters at redhat.com Mon Jan 17 00:08:28 2005 From: walters at redhat.com (Colin Walters) Date: Sun, 16 Jan 2005 19:08:28 -0500 Subject: Dmix (Fedora Core 4) In-Reply-To: <1105894669.9959.35.camel@galvatron.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <20050116142724.400d54aa@nausicaa.camperquake.de> <1105887099.9959.20.camel@galvatron.localdomain> <20050116160905.5f7ee091@nausicaa.camperquake.de> <1105894669.9959.35.camel@galvatron.localdomain> Message-ID: <1105920508.4673.3.camel@nexus.verbum.private> On Sun, 2005-01-16 at 16:57 +0000, Sitsofe Wheeler wrote: > On Sun, 2005-01-16 at 16:09 +0100, Ralf Ertzinger wrote: > > > for software mixing of multiple output streams (e.g. the case of playing > > > music while still hearing IM event sounds) which is what I'm thinking of > > > (although please correct me if I am wrong). > > > > This works. Just tell the gstreamer system to use alsa as audio sink > > (Preferences->More Preferences->Multimedia Systems Selector) > > Sounds good! I tried upgrading my alsa libraries on an FC3 box with > alsa-lib-1.0.7-3.devel.i386.rpm but it just caused sound to break on the > (virtual) console I was using (first it moaned about a missing key and > then after I thew away the .asoundrc file alsa support in ogg123 stopped > working and started spewing messages). I've downgraded back to the FC3 > packages and sound works again. > > It does appear that DMix software mixing will be on by default in FC4 > for everybody (a shame for soundcard owners who have hardware mixing but > to be fair they are in the minority). We're trading one very serious, major bug (sound mixing not working for anyone) for a few more minor bugs (sound mixing not efficient as possible, doesn't work for 2nd sound card, etc.). I'm not saying these new bugs are not important - conceptually they are fixable in alsa-lib. From dag at wieers.com Mon Jan 17 04:34:51 2005 From: dag at wieers.com (Dag Wieers) Date: Mon, 17 Jan 2005 05:34:51 +0100 (CET) Subject: Fedora Core 4 In-Reply-To: <41E94E25.7010005@nc.rr.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> Message-ID: On Sat, 15 Jan 2005, Jeff Johnson wrote: > seth vidal wrote: > > > > Have you considerer smart : > > > http://www.smartpm.org/ > > > > > > It is Interesting. But sometimes it ignore %{epoch} (for good or bad > > > reason it's not the point), does not support group, the gui interface is > > > a little confusing. > > > Smart is quite fast (python), have gnome, kde, text interface. It's in > > > beta/testing stage. > > > > > > > At this point smart doesn't have multilib support (at least from reading > > of the code) so I'm not sure how useful that will be for a distro > > offering (soon, I hope) two multilib archs: x86_64 and ppc64. > > Multilib pkg choice is a work of hours, not more. > > Smartpm needs RHN channel too. Yes please :) And a backport to RHEL3's python ! -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From notting at redhat.com Mon Jan 17 05:13:18 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 17 Jan 2005 00:13:18 -0500 Subject: Proposed dovecot update changes In-Reply-To: <41E9F8B8.4070402@redhat.com> References: <41E9F8B8.4070402@redhat.com> Message-ID: <20050117051318.GA17108@nostromo.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > 2. dovecot.conf should default to fcntl locking > =============================================== > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145214#c7 > Our default dovecot.conf changed from fcntl to dotlock sometime after > the release of FC2. That is one of the reasons why we see this above > bug. This problem must now be attacked on two fronts: Argh. *Anything* that touches mail needs to use fcntl and fcntl only; it's stated policy, and not following it is asking for trouble with other mail-handling software. Bill From backes at rhrk.uni-kl.de Mon Jan 17 07:23:29 2005 From: backes at rhrk.uni-kl.de (Joachim Backes) Date: Mon, 17 Jan 2005 08:23:29 +0100 Subject: Recognition of an USB CD-Rom in FC3 Message-ID: <1105946609.5316.6.camel@sunny.rhrk.uni-kl.de> Hi, having the following problem: I have an USB CD ROM, which is attached to my LINUX machine (FC3, Vanilla Kernel 2.6.10) already at boot time. But I can't file the /dev entry, and a mount is impossible. Only if I unplug and plug in the USB device, I can use it. Question: what to do for using the device directly after boot without plugging out/in? Any help appreciated. -- Regards Joachim Backes Joachim Backes University of Kaiserslautern,Computer Center, High Performance Computing, D-67653 Kaiserslautern, PO Box 3049, Germany -------------------------------------------------- Phone: +49-631-205-2438, FAX: +49-631-205-3056 http://hlrwm.rhrk.uni-kl.de/home/staff/backes.html From sitsofe at yahoo.com Mon Jan 17 07:49:34 2005 From: sitsofe at yahoo.com (Sitsofe Wheeler) Date: Mon, 17 Jan 2005 07:49:34 +0000 Subject: Dmix (Fedora Core 4) In-Reply-To: <1105920508.4673.3.camel@nexus.verbum.private> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <20050116142724.400d54aa@nausicaa.camperquake.de> <1105887099.9959.20.camel@galvatron.localdomain> <20050116160905.5f7ee091@nausicaa.camperquake.de> <1105894669.9959.35.camel@galvatron.localdomain> <1105920508.4673.3.camel@nexus.verbum.private> Message-ID: <1105948175.10063.7.camel@galvatron.localdomain> On Sun, 2005-01-16 at 19:08 -0500, Colin Walters wrote: > We're trading one very serious, major bug (sound mixing not working for > anyone) for a few more minor bugs (sound mixing not efficient as Didn't it work for those with hardware mixing? It certainly appeared to work for me (with or without esd)... > possible, doesn't work for 2nd sound card, etc.). I'm not saying these > new bugs are not important - conceptually they are fixable in alsa-lib. I understand and fully agree with the reasoning behind this. There are so few cards with hardware mixing support these days that it doesn't make sense to postpone software mixing any longer (and perhaps dmix will one day smarten up and use hardware mixers when they are available). Non sound daemon mixing is going to be one of those major distro milestones like the WIMPified Anaconda installer, defaulting to antialiased fonts, including yum or EDID support in X. We "just" need ALSA support in those apps not supporting esound or ALSA now (hint hint BZflag :). Oh and for SDL to default to using ALSA rather than OSS... From caolanm at redhat.com Mon Jan 17 09:04:31 2005 From: caolanm at redhat.com (Caolan McNamara) Date: Mon, 17 Jan 2005 09:04:31 +0000 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <1105791903.17504.11.camel@rh-ibm-t41> Message-ID: <1105952671.9354.6.camel@sheol.homelinux.org> On Sat, 2005-01-15 at 18:02 +0530, Rahul Sundaram wrote: > Hi > > . However there are some parts of > > OOo's Java code that rely on Sun-private interfaces -- these present a > > dead end for GCJ, so we'll need to get them reimplemented (using public > > APIs) upstream. > > is this going to happen before the final OO.o 2.0 release or are you > planning to add patches? I've the critical "required" bits of the 2.0 series working with gcj and awaiting OOo qa for integration into the mainline, so the important changes are likely to happen before the final 2.0 release unless there is a QA problem. The bits that don't currently compile with gcj despite those changes are listed at http://tools.openoffice.org/servlets/ReadMsg?list=jdk&msgNo=127 C. From dwmw2 at infradead.org Mon Jan 17 09:33:31 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 17 Jan 2005 09:33:31 +0000 Subject: Proposed dovecot update changes In-Reply-To: <20050117051318.GA17108@nostromo.devel.redhat.com> References: <41E9F8B8.4070402@redhat.com> <20050117051318.GA17108@nostromo.devel.redhat.com> Message-ID: <1105954411.26551.316.camel@hades.cambridge.redhat.com> On Mon, 2005-01-17 at 00:13 -0500, Bill Nottingham wrote: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145214#c7 > > Our default dovecot.conf changed from fcntl to dotlock sometime after > > the release of FC2. That is one of the reasons why we see this above > > bug. This problem must now be attacked on two fronts: > > Argh. *Anything* that touches mail needs to use fcntl and fcntl > only; it's stated policy, and not following it is asking for > trouble with other mail-handling software. We should change the default behaviour of the /usr/libexec/dovecot/imap binary if the MBOX_LOCKS environment variable isn't set, because it doesn't read dovecot.conf for itself. In order to make it work again for people who use it from SSH with Evolution/pine/mutt, I had to make a wrapper script which sets MBOX_LOCKS=fcntl and then runs the real binary. -- dwmw2 From PerSteinar.Iversen at adm.hio.no Mon Jan 17 11:35:02 2005 From: PerSteinar.Iversen at adm.hio.no (Per Steinar Iversen) Date: Mon, 17 Jan 2005 12:35:02 +0100 (CET) Subject: Building rpms on AMD64 In-Reply-To: <3077b8a0050114090023076a3f@mail.gmail.com> References: <3077b8a0050114090023076a3f@mail.gmail.com> Message-ID: The trick for using rpmbuild seems to be that /usr/X11R6/bin must be in the path - otherwise rpmbuild just fails on x86_64. It seems to OK to have this directory last place in the path though. -psi On Fri, 14 Jan 2005, Nick Bargnesi wrote: > If I were you - I would check to make sure you also do not have 32-bit > X libraries installed. Part of the full installation you selected > installs compat packages allowing you to build for different > platforms. If removing the 32-bit libraries helps, send the solution > back to the user list. > > > On Fri, 14 Jan 2005 15:09:44 +0100 (CET), Per Steinar Iversen > wrote: >> >> I tried this question on fedora-list yesterday, and got a number of >> messages from other users with the same problem, but no resolution. >> Perhaps this list is a better place to ask? >> >> A silly question: How does one build or rebuild src rpms under x86_64? >> >> On a freshly installed FC3 (full install) nearly everything fails to build >> as configure looks at the wrong X11 libraries. As an example, rebuilding >> mozilla: >> >> $ rpmbuild --rebuild mozilla-1.7.5-3.src.rpm >> ...lines deleted... >> checking GLIB_LIBS... -lglib-2.0 >> configure: error: Could not find the following X libraries: -lX11 -lXext -lXt >> error: Bad exit status from /var/tmp/rpm-tmp.13288 (%build) >> >> Modifying the spec-file to add a line like this cures the problem: >> >> --x-libraries=/usr/X11R6/lib64 >> >> But this is probably too crude - what is the proper incantation to make >> rpmbuild understand where the X11 libraries are placed on x86_64? >> >> -psi >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > > From dwmw2 at infradead.org Mon Jan 17 11:44:49 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 17 Jan 2005 11:44:49 +0000 Subject: Fedora Core 4 In-Reply-To: <20050114223020.GA7168@nostromo.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <1105962291.26551.335.camel@hades.cambridge.redhat.com> On Fri, 2005-01-14 at 17:30 -0500, Bill Nottingham wrote: > So, what's planned for Fedora Core 4? Here's what we're looking > at from the Red Hat side of things: If you apply the patches I sent you a year or two ago we can have bluetooth networking support working fairly much out of the box too... -- dwmw2 From rahulsundaram at gmail.com Mon Jan 17 11:48:16 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Mon, 17 Jan 2005 17:18:16 +0530 Subject: Fedora Core 4 In-Reply-To: <1105962291.26551.335.camel@hades.cambridge.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105962291.26551.335.camel@hades.cambridge.redhat.com> Message-ID: On Mon, 17 Jan 2005 11:44:49 +0000, David Woodhouse wrote: > On Fri, 2005-01-14 at 17:30 -0500, Bill Nottingham wrote: > > So, what's planned for Fedora Core 4? Here's what we're looking > > at from the Red Hat side of things: > > If you apply the patches I sent you a year or two ago we can have > bluetooth networking support working fairly much out of the box too... > it might be useful to provide links just in case this has been totally forgotten -- Regards, Rahul Sundaram From rahulsundaram at gmail.com Mon Jan 17 11:49:37 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Mon, 17 Jan 2005 17:19:37 +0530 Subject: Fedora Core 4 In-Reply-To: <1105952671.9354.6.camel@sheol.homelinux.org> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <1105791903.17504.11.camel@rh-ibm-t41> <1105952671.9354.6.camel@sheol.homelinux.org> Message-ID: Hi > > I've the critical "required" bits of the 2.0 series working with gcj and > awaiting OOo qa for integration into the mainline, so the important > changes are likely to happen before the final 2.0 release unless there > is a QA problem. The bits that don't currently compile with gcj despite > those changes are listed at > http://tools.openoffice.org/servlets/ReadMsg?list=jdk&msgNo=127 > > C. ok. thanks for taking the time to respond. I was worried that the java database wouldnt work at all in gcj. looks like that isnt in the case for the major parts alteast -- Regards, Rahul Sundaram From rahulsundaram at gmail.com Mon Jan 17 11:53:40 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Mon, 17 Jan 2005 17:23:40 +0530 Subject: Fedora Core 4 In-Reply-To: <1105811660.32328.0.camel@opus.phy.duke.edu> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> Message-ID: Hi Here is a proposal for adding yum repos by default to the fc4 yum rpm or provide it as a seperate add on called say yum-extras fedora - enabled fedora updates - enabled fedora devel - disabled fedora - extras - enabled? dags and other repos in rpmforge - disabled if its still incompatible jpackage - enabled? Seth and others, what do you think of this? -- Regards, Rahul Sundaram From casimiro.barreto at gmail.com Mon Jan 17 11:57:00 2005 From: casimiro.barreto at gmail.com (casimiro barreto) Date: Mon, 17 Jan 2005 09:57:00 -0200 Subject: Recognition of an USB CD-Rom in FC3 In-Reply-To: <1105946609.5316.6.camel@sunny.rhrk.uni-kl.de> References: <1105946609.5316.6.camel@sunny.rhrk.uni-kl.de> Message-ID: <578ed59105011703571aff0104@mail.gmail.com> Yeah, It seems that the SCSI/USB drivers are not working 100% for a long time. I have a similar problem with an old IOMEGA Predator CD-RW driver. The current situation is funny: it won't record anything using cdrecord (crashes after +/- 140MBytes) so it is necessary to use cdrdao and speed 2 (so, if you really want to use it you must be really zen). My solution: migrate to an ATA DVD R/W driver... a kind of dirty Microsoft solution... but I really don't have time to understant and fix the drivers... Regards, Casimiro On Mon, 17 Jan 2005 08:23:29 +0100, Joachim Backes wrote: > Hi, > > having the following problem: I have an USB CD ROM, which is > attached to my LINUX machine (FC3, Vanilla Kernel 2.6.10) > already at boot time. But I can't file the /dev entry, and a > mount is impossible. > > Only if I unplug and plug in the USB device, I can use it. > Question: what to do for using the device directly after > boot without plugging out/in? > > Any help appreciated. > > -- > Regards > > Joachim Backes > > Joachim Backes > University of Kaiserslautern,Computer Center, > High Performance Computing, > D-67653 Kaiserslautern, PO Box 3049, Germany > -------------------------------------------------- > Phone: +49-631-205-2438, FAX: +49-631-205-3056 > http://hlrwm.rhrk.uni-kl.de/home/staff/backes.html > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. From caolanm at redhat.com Mon Jan 17 12:09:46 2005 From: caolanm at redhat.com (Caolan McNamara) Date: Mon, 17 Jan 2005 12:09:46 +0000 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <1105791903.17504.11.camel@rh-ibm-t41> <1105952671.9354.6.camel@sheol.homelinux.org> Message-ID: <1105963786.9356.12.camel@sheol.homelinux.org> On Mon, 2005-01-17 at 17:19 +0530, Rahul Sundaram wrote: > Hi > > > > > I've the critical "required" bits of the 2.0 series working with gcj and > > awaiting OOo qa for integration into the mainline, so the important > > changes are likely to happen before the final 2.0 release unless there > > is a QA problem. The bits that don't currently compile with gcj despite > > those changes are listed at > > http://tools.openoffice.org/servlets/ReadMsg?list=jdk&msgNo=127 > > > > C. > > > ok. thanks for taking the time to respond. I was worried that the java > database wouldnt work at all in gcj. looks like that isnt in the case > for the major parts alteast Not totally up to speed on what the "java database" story is, it *could* be hsqldb. so hsqldb's use of "sun.security.action.GetPropertyAction" is problematic. C. From rahulsundaram at gmail.com Mon Jan 17 12:16:07 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Mon, 17 Jan 2005 17:46:07 +0530 Subject: Fedora Core 4 In-Reply-To: <1105963786.9356.12.camel@sheol.homelinux.org> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <1105791903.17504.11.camel@rh-ibm-t41> <1105952671.9354.6.camel@sheol.homelinux.org> <1105963786.9356.12.camel@sheol.homelinux.org> Message-ID: Hi > Not totally up to speed on what the "java database" story is, it *could* > be hsqldb. so hsqldb's use of "sun.security.action.GetPropertyAction" is > problematic. > err, I meant hsqldb alright. hopefully you and other gcj developers within and outside of redhat could resolve the problem somehow I am not sure adding java dependencies to openoffice is a good idea but gcj is a saving grace (hopefully) -- Regards, Rahul Sundaram From Nicolas.Mailhot at laPoste.net Mon Jan 17 12:18:35 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 17 Jan 2005 13:18:35 +0100 Subject: goals for fc4? In-Reply-To: <1105493919l.5018l.11l@devel.mpeters.us> References: <5cf776b8050108150644336d04@mail.gmail.com> <1105328387.5866.4.camel@one.myworld> <1105493919l.5018l.11l@devel.mpeters.us> Message-ID: <1105964316.5505.13.camel@ulysse.olympe.o2t> Le mercredi 12 janvier 2005 ? 01:38 +0000, Michael A. Peters a ?crit : > Also - perhaps a jpackage repo and key. > That though is a little harder because currently (afaik) jpackage does > not provide a repo mirror list. Maybe that should wait until jpackage > has their free j2sdk done (I understand they are working on one) Well, this is supposed to be secret stuff;) Please don't block on it - there may someday be a redistributable jvm rpm at jpackage, and someday may even be next week, but the $VENDOR we're working with obviously has its own paying products higher on the priority list so it's taking some time... FYI at one point it looked like we could do jpp 1.6 with a jvm in but in the end we had to do the release without it since it was taking too long. > Fedora already installs one jpackage package, and jpackage does seem to > be the way to go if you want to do java stuff on Fedora, I know of no > other alternative that works well through yum. There is more than one jpackage package in Fedora Devel right now;). Stuff is moving both ways pretty smoothly. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fedora at wir-sind-cool.org Mon Jan 17 12:20:21 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 17 Jan 2005 13:20:21 +0100 Subject: Reopen a request for gpgme in Core In-Reply-To: <41DEB7AD.6090000@math.unl.edu> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106110659.17f329f0.toshio@tiki-lounge.com> <20050106183045.1991bdbb.fedora@wir-sind-cool.org> <200501062148.50705.dennis@ausil.us> <41DEB7AD.6090000@math.unl.edu> Message-ID: <20050117132021.36fd2892.fedora@wir-sind-cool.org> On Fri, 07 Jan 2005 10:24:13 -0600, Rex Dieter wrote: > Dennis Gilmore wrote: > > > AFAIK cryptplug is no longer of use in FC3 kmail in kde 3.3 has the > > functionality added > > FYI, not without gpgme/gnupg2... > http://bugzilla.redhat.com/bugzilla/136533 By default, KMail in FC3 only supports OpenPGP through built-in GPGME and external GnuPG. How would we obsolete the cryptplug package? For KMail, which has been our only cryptplug user, it would work to make a gpgme update "Obsoletes: cryptplug". E.g. the gpgme and gnupg packages in the fedora.us queue is built with OpenPGP and S/MIME support. But it would not be entirely correct, since gpgme >= 0.4.5 is not a direct successor of cryptplug. We've discussed opportunity for meta-packages a long time ago, but never implemented them. Where a package is not moved from Extras into Core, we need ways to obsolete "old cruft" ourselves. One way to achieve that in an upgrade would be to create and main a meta package like "fedora-extras-release-3". Thoughts anyone? From nmiell at comcast.net Mon Jan 17 12:22:24 2005 From: nmiell at comcast.net (Nicholas Miell) Date: Mon, 17 Jan 2005 04:22:24 -0800 Subject: Building rpms on AMD64 In-Reply-To: <1105914022.5205.26.camel@proton.cygnusx-1.org> References: <3077b8a0050114090023076a3f@mail.gmail.com> <41E80325.6070303@research.att.com> <1105724504.3944.36.camel@cutter> <1105914022.5205.26.camel@proton.cygnusx-1.org> Message-ID: <1105964544.5470.24.camel@localhost.localdomain> On Sun, 2005-01-16 at 14:20 -0800, Nathan G. Grennan wrote: > I fixed this issue by compiling i386 stuff on a i686 box at work. Pretty > much the only things I wanted i386 were mozilla and galeon packages. > Other things like mplayer I just installed the i386 version with yum > from a repository. AFAIK, there's no way to build i386 software of any complexity on outside of an i386 chroot on an AMD64 system, without completely modifying the package's build system. > I have libonobo is installed for both 32bit and 64bit. One of the files > in the packages in /usr/libexec/bonobo-activation-server. It is a 64bit > executable. It tries to > load /usr/lib64/bonobo/servers/GNOME_Galeon_Automation.server for the > 32bit galeon which puts it in /usr/lib. So it isn't search both /usr/lib > and /usr/lib64 like it should. This also brings up the issue of a lot of > bad placement. GNOME_Galeon_Automation.server is a text file, so > shouldn't it be in /usr/share or something else anyway. When I asked a > galeon developer he said, yes, but that is where bonobo expects it. > Note that while .server files may be text, they describe binary components. Thus, /usr/lib/bonobo lists 32-bit components and /usr/lib64/bonobo lists 64-bit components. Their placement in /usr/lib{,64} instead of /usr/share is correct. Somebody should fix bonobo-activation to do the right thing on 64-bit systems, but I don't think anybody really cares all that much about Bonobo anymore. > A galeon developer told me 32bit gtk programs on an FC3 x86_64 system > were completely broken. When I asked for detail, he said that 32bit gtk > programs trying to use libpixbuf would try to load 64bit themes. Gdk-Pixbuf and GTK immodule problems on biarch systems were fixed for FC3. AFAICT, themes were never broken. Theme engines aren't specified as paths to libraries, just strings which GTK uses to find the libraries. At worst, 32-bit GTK programs will fail to find the requested theme engine and revert to the default. Certainly not "completely broken", especially on FC3 systems. -- Nicholas Miell From kwade at redhat.com Mon Jan 17 13:27:25 2005 From: kwade at redhat.com (Karsten Wade) Date: Mon, 17 Jan 2005 05:27:25 -0800 Subject: Fedora Core 4 In-Reply-To: <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> Message-ID: <1105968445.31480.103.camel@erato.phig.org> On Sat, 2005-01-15 at 10:32 -0500, Sean Middleditch wrote: > On Sat, 2005-01-15 at 17:29 +0530, Rahul Sundaram wrote: > > Hi > > > > > > - SELinux Episode III: Revenge of the AVC > > > > how about gui integration with gnome by letting nautllus show security > > contexts and manipulate them using chcon, fixfiles etc as the backend. > > That sounds like a pretty bad idea in general, actually - the last thing > you need is for the state of your file contexts to ever get out of sync > with your configuration files. Besides, you'd need to have some pretty > highly elevated privileges to even perform those tasks, and SELinux > eventually should probably make sure no GUI tool can ever even have > those privileges, except for the ones specifically designed for SELinux > administration (like you say below). Sword edge balancing time. There are a number of customizable types, that is, ones which an end-user might need to manipulate. These are a small set of the overall types, but they are important for sharing data over SMB, FTP, HTTP, etc. End users need to be able to run chcon. Just as with DAC, they may occasionally mess up the permissions. It would be nice for them if Nautilus supported chcon on the backend, while of course displaying the contexts. For anything that involves relabeling the file system, that sounds like it would be better used in an s-c-selinux that requires root/sysadm_r. - Karsten -- Karsten Wade, RHCE, Sr. Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From buildsys at redhat.com Mon Jan 17 13:28:58 2005 From: buildsys at redhat.com (Build System) Date: Mon, 17 Jan 2005 08:28:58 -0500 Subject: rawhide report: 20050117 changes Message-ID: <200501171328.j0HDSwH17855@porkchop.devel.redhat.com> Updated Packages: gimp-2:2.2.2-3 -------------- * Mon Jan 17 2005 Nils Philippsen - clip thumbnail quality at 75 and don't barf on saving images at quality 0 (fix patch for #145100) * Fri Jan 14 2005 Nils Philippsen - avoid writing excessively long EXIF markers (#145100) * Tue Jan 11 2005 Nils Philippsen - version 2.2.2 - autogenerate %microver libuser-0.53.2-1 ---------------- * Mon Jan 17 2005 Miloslav Trmac - 0.53.2-1 - Important bug fixes in lchage, lgroupmod, lnewusers and lusermod - Minor bug fixes in lpasswd and luseradd - Add man pages for the utilities (#61673) libxml2-2.6.17-1 ---------------- * Sun Jan 16 2005 Daniel Veillard - upstream release 2.6.17 see http://xmlsoft.org/news.html * Thu Jan 02 2003 Daniel Veillard - integrated drv_libxml2 xml.sax driver from St?phane Bidoul - provides the new XmlTextReader interfaces based on C# XML APIs * Wed Oct 23 2002 Daniel Veillard - revamped the spec file, cleaned up some rpm building problems rpmdb-fedora-1:4-0.20050117 --------------------------- zsh-4.2.1-2 ----------- * Sun Jan 16 2005 Colin Walters - 4.2.1-2 - Install config files using install instead of cp, with mode 644 From pri.rhl3 at iadonisi.to Mon Jan 17 13:29:51 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Mon, 17 Jan 2005 08:29:51 -0500 Subject: goals for fc4? In-Reply-To: <1105964316.5505.13.camel@ulysse.olympe.o2t> References: <5cf776b8050108150644336d04@mail.gmail.com> <1105328387.5866.4.camel@one.myworld> <1105493919l.5018l.11l@devel.mpeters.us> <1105964316.5505.13.camel@ulysse.olympe.o2t> Message-ID: <1105968591.933.2.camel@va.local.linuxlobbyist.org> On Mon, 2005-01-17 at 13:18 +0100, Nicolas Mailhot wrote: > Le mercredi 12 janvier 2005 ? 01:38 +0000, Michael A. Peters a ?crit : > > not provide a repo mirror list. Maybe that should wait until jpackage > > has their free j2sdk done (I understand they are working on one) > > Well, this is supposed to be secret stuff;) Please don't block on it - > there may someday be a redistributable jvm rpm at jpackage, and someday > may even be next week, but the $VENDOR we're working with obviously has > its own paying products higher on the priority list so it's taking some > time... Forgive my Java ignorance, but... J2SDK JVM GCJ How do these things intersect/complement each other? And are there any missing pieces from the above to providing a complete Java implementation (possibly without the official, trademarked 'Java' name ;-))? -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From jspaleta at gmail.com Mon Jan 17 14:18:41 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 17 Jan 2005 09:18:41 -0500 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> Message-ID: <604aa7910501170618ab5c65@mail.gmail.com> On Mon, 17 Jan 2005 17:23:40 +0530, Rahul Sundaram wrote: > Here is a proposal for adding yum repos by default to the fc4 yum rpm > or provide it as a seperate add on called say yum-extras I think hoping for red hat to include any repository information for a repository they don't have full content control over is probably ill-advised and not going to happen for reasons outside of the control of any of the developers. There could very well be legal liability issues that you aren't fully aware of that Red Hat as a US company has to be careful of that impacts what outside repositories definitions can be included. -jef From elanthis at awesomeplay.com Mon Jan 17 14:30:54 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 17 Jan 2005 09:30:54 -0500 Subject: Fedora Core 4 In-Reply-To: <1105968445.31480.103.camel@erato.phig.org> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> <1105968445.31480.103.camel@erato.phig.org> Message-ID: <1105972254.19179.4.camel@stargrazer.home.awesomeplay.com> On Mon, 2005-01-17 at 05:27 -0800, Karsten Wade wrote: > On Sat, 2005-01-15 at 10:32 -0500, Sean Middleditch wrote: > > On Sat, 2005-01-15 at 17:29 +0530, Rahul Sundaram wrote: > > > Hi > > > > > > > > - SELinux Episode III: Revenge of the AVC > > > > > > how about gui integration with gnome by letting nautllus show security > > > contexts and manipulate them using chcon, fixfiles etc as the backend. > > > > That sounds like a pretty bad idea in general, actually - the last thing > > you need is for the state of your file contexts to ever get out of sync > > with your configuration files. Besides, you'd need to have some pretty > > highly elevated privileges to even perform those tasks, and SELinux > > eventually should probably make sure no GUI tool can ever even have > > those privileges, except for the ones specifically designed for SELinux > > administration (like you say below). > > Sword edge balancing time. There are a number of customizable types, > that is, ones which an end-user might need to manipulate. These are a > small set of the overall types, but they are important for sharing data > over SMB, FTP, HTTP, etc. That doesn't make much sense - there is no good reason at all for a user to need to muck around with SELinux to perform basic file sharing, and general administration tasks are going to need more than simply setting contexts in Nautilus. Besides, changing them in Nautilus *WILL* break the system, because the second a package upgrade for selinux policies comes in and restorecon is run all of their customized settings will be erased. You have to edit the actual policy control files, and Nautilus is, beyond any doubt, an application that should never, ever be modifying those files. That would be like Apache having rights to edit /etc/passwd and /etc/shadow because the web master might want to change login information for some web users... > > End users need to be able to run chcon. Just as with DAC, they may > occasionally mess up the permissions. It would be nice for them if > Nautilus supported chcon on the backend, while of course displaying the > contexts. The only way they *could* mess them up is if they use root-access in a shell, in which case, they should use the same method to fix it. > > For anything that involves relabeling the file system, that sounds like > it would be better used in an s-c-selinux that requires root/sysadm_r. > > - Karsten > -- > Karsten Wade, RHCE, Sr. Tech Writer > a lemon is just a melon in disguise > http://people.redhat.com/kwade/ > gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 > From Nicolas.Mailhot at laPoste.net Mon Jan 17 14:30:50 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 17 Jan 2005 15:30:50 +0100 Subject: goals for fc4? In-Reply-To: <1105968591.933.2.camel@va.local.linuxlobbyist.org> References: <5cf776b8050108150644336d04@mail.gmail.com> <1105328387.5866.4.camel@one.myworld> <1105493919l.5018l.11l@devel.mpeters.us> <1105964316.5505.13.camel@ulysse.olympe.o2t> <1105968591.933.2.camel@va.local.linuxlobbyist.org> Message-ID: <1105972251.5505.89.camel@ulysse.olympe.o2t> Le lundi 17 janvier 2005 ? 08:29 -0500, Paul Iadonisi a ?crit : > On Mon, 2005-01-17 at 13:18 +0100, Nicolas Mailhot wrote: > > Le mercredi 12 janvier 2005 ? 01:38 +0000, Michael A. Peters a ?crit : > > > > > not provide a repo mirror list. Maybe that should wait until jpackage > > > has their free j2sdk done (I understand they are working on one) > > > > Well, this is supposed to be secret stuff;) Please don't block on it - > > there may someday be a redistributable jvm rpm at jpackage, and someday > > may even be next week, but the $VENDOR we're working with obviously has > > its own paying products higher on the priority list so it's taking some > > time... > > Forgive my Java ignorance, but... > > J2SDK > JVM > GCJ > > How do these things intersect/complement each other? And are there > any missing pieces from the above to providing a complete Java > implementation (possibly without the official, trademarked 'Java' > name ;-))? J2SDK = java 1.2/1.3/1.4 JVM by SUN (seems they switched back to the JVM moniker for 1.5) Can we widened to englobe all the java extentions that end up in J2EE for example. gcj (very general term often used to englobe much more than gcj itself) ~ FOSS reimplementation of a JVM. Not 100% complete. Will probably never be 100 % complete or allowed to use official Sun logos. Strives to implement all the stuff FOSS java software cares about (sometimes doing tricks like asking the aforementioned FOSS software to stop using stuff they don't want to reimplement;) JPP is built using commercial JVMs. A growing number of packages are rebuildable using free implementations and that's what ending up in FC/ FC devel right now (sometimes it still works better with a commercial JVM thought). Someday we might hope there will be a 100% overlap, though I suppose FC will start filtering stuff they don't need (like silly games) way before all JPP is gcj-compatible. One of gcj's peculiarities is that it can generate native code instead of bytecode. So another characteristic of the stuff that ends in FC is that it is dual native/bytecode generated while JPP is pure bytecode at this stage. gcj is supposed to be better at executing native code than bytecode. I don't think there is anyone made the argument than gcj + native is faster than commercial jvm + bytecode. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Mon Jan 17 14:34:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 17 Jan 2005 09:34:33 -0500 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> Message-ID: <1105972473.3725.75.camel@cutter> > fedora - enabled > fedora updates - enabled > fedora devel - disabled > fedora - extras - enabled? > dags and other repos in rpmforge - disabled if its still incompatible > jpackage - enabled? > > Seth and others, what do you think of this? The repositories with legal issues won't be included nor enabled It's just not possible for fairly obvious reasons that have been discussed many times before. I think the best way for other packaging sites to make their stuff available, trivially, for yum would be to make a package that provides their .repo file. then users can: wget url://to/that/rpm yum install /that/rpm -sv From cmadams at hiwaay.net Mon Jan 17 14:44:00 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 17 Jan 2005 08:44:00 -0600 Subject: Fedora Core 4 In-Reply-To: <1105972254.19179.4.camel@stargrazer.home.awesomeplay.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> <1105968445.31480.103.camel@erato.phig.org> <1105972254.19179.4.camel@stargrazer.home.awesomeplay.com> Message-ID: <20050117144400.GA550031@hiwaay.net> Once upon a time, Sean Middleditch said: > That doesn't make much sense - there is no good reason at all for a user > to need to muck around with SELinux to perform basic file sharing, and > general administration tasks are going to need more than simply setting > contexts in Nautilus. Setting up CGI scripts to run under Apache is a fairly common task for webservers and requires setting the file context if scripts are not in cgi-bin (allowing *.cgi and/or *.pl to be CGI scripts is fairly common). > Besides, changing them in Nautilus *WILL* break the system, because the > second a package upgrade for selinux policies comes in and restorecon is > run all of their customized settings will be erased. Does that reset every context on the system, including on non-RPM files? If so, that's going to be highly confusing to both users and system administrators. What is the point of even having the chcon command if everything will be reset to some config file contents at arbitrary times? Just load the config file into the kernel and use it directly. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From elanthis at awesomeplay.com Mon Jan 17 14:56:34 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 17 Jan 2005 09:56:34 -0500 Subject: Fedora Core 4 In-Reply-To: <20050117144400.GA550031@hiwaay.net> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> <1105968445.31480.103.camel@erato.phig.org> <1105972254.19179.4.camel@stargrazer.home.awesomeplay.com> <20050117144400.GA550031@hiwaay.net> Message-ID: <1105973794.19179.9.camel@stargrazer.home.awesomeplay.com> On Mon, 2005-01-17 at 08:44 -0600, Chris Adams wrote: > Once upon a time, Sean Middleditch said: > > That doesn't make much sense - there is no good reason at all for a user > > to need to muck around with SELinux to perform basic file sharing, and > > general administration tasks are going to need more than simply setting > > contexts in Nautilus. > > Setting up CGI scripts to run under Apache is a fairly common task for > webservers and requires setting the file context if scripts are not in > cgi-bin (allowing *.cgi and/or *.pl to be CGI scripts is fairly common). Understood - but there's absolutely no reason for Nautilus to be able to do that. It's an admin task, let admin tools (i.e., the shell) do it. > > > Besides, changing them in Nautilus *WILL* break the system, because the > > second a package upgrade for selinux policies comes in and restorecon is > > run all of their customized settings will be erased. > > Does that reset every context on the system, including on non-RPM files? > If so, that's going to be highly confusing to both users and system > administrators. What is the point of even having the chcon command if > everything will be reset to some config file contents at arbitrary > times? Just load the config file into the kernel and use it directly. I never said SELinux is easy to configure. I just stated how it works. It's actually essential that restorecon resets all files, according to the SELinux experts I last spoke with, since that means that an "SELinux security expert" (i.e. a relatively small handful of SELinux developers) can look in one place to check the available flow of information and privileges in the system; if you could change individual files then you'd really have no way to know what files had what contexts without expensive whole-system searches. (Granted, I think then that the file- systems people use should be "fixed" to make it not-so-expensive and to get rid of duality and complexity in SELinux configuration, but that's of course not technically feasible for Red Hat to pull off in FC4.) From i_p_a_u_l at yahoo.com Mon Jan 17 15:22:35 2005 From: i_p_a_u_l at yahoo.com (Paul Ionescu) Date: Mon, 17 Jan 2005 17:22:35 +0200 Subject: Fedora Core 4 References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: Hi all, Some improvement in suspending to RAM and to DISK would be nice. With a big fat warning for users that it may not work for everybody, but we need this. My colleagues resumed their laptops in 15 secs, and I had to wait some minutes before I could work. Now I am using a custom S3 and swsuspend2 to do suspends to ram and disk. Thanks, On Fri, 14 Jan 2005 17:30:20 -0500, Bill Nottingham wrote: > A Fedora Core 4 proto-schedule is available at: > > http://fedora.redhat.com/participate/schedule/ > > Generally, it's 3 4-week test releases, with a release in early/mid May. > > So, what's planned for Fedora Core 4? Here's what we're looking at from > the Red Hat side of things: > > - GCC 4, if it's ready > > We're not planning on holding for it, but if it's out in a reasonable > time, sure. Failing that, we're looking at making more of the > FORTIFY_SOURCE and other gcc & glibc security extensions integrated, if > at all possible. > > - The usual new stuff - GNOME 2.10, KDE 3.4, Xorg 6.8.2, > OpenOffice 2.0 (maybe), etc. > > - Xen and Virtualization > > This starts by integrating the Xen kernel stuff, and going from there. > > - SELinux Episode III: Revenge of the AVC > > Yet more targets in the targeted policy. > > - Faster boot > > Eliminating redundancy and old cruft in the bootup process, starting GDM > early if possible, using newer and faster udev codebases, and other > related tweaks. > > - Java > > More native-compiled GCJ stuff. Including Eclipse. > > - Package management > > GUI integration of system-config-packages, yum, and friends. > > - more networking changes > > Further integration of NetworkManager > > - PPC support > > For your brand spanking new MiniMac, or the p655 under your desk. > > - Extras at launch time. Or else. > > Hopefully, self explanatory. Could coincide with the move of some bits > from Core to Extras. In fact, some of the stuff on this list of features > may *be* in Extras. > > Probably other stuff that I'm forgetting in here. I'm sure more people can > remind me. > > Bill From walters at redhat.com Mon Jan 17 15:33:34 2005 From: walters at redhat.com (Colin Walters) Date: Mon, 17 Jan 2005 10:33:34 -0500 Subject: Fedora Core 4 In-Reply-To: <1105972254.19179.4.camel@stargrazer.home.awesomeplay.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> <1105968445.31480.103.camel@erato.phig.org> <1105972254.19179.4.camel@stargrazer.home.awesomeplay.com> Message-ID: <1105976014.4673.18.camel@nexus.verbum.private> On Mon, 2005-01-17 at 09:30 -0500, Sean Middleditch wrote: > Besides, changing them in Nautilus *WILL* break the system, because the > second a package upgrade for selinux policies comes in and restorecon is > run all of their customized settings will be erased. The policy package doesn't do any relabeling at the moment. This will likely change though, because it does cause problems. When that occurs, consideration will be given to preserving customized file contexts. From elanthis at awesomeplay.com Mon Jan 17 15:36:43 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 17 Jan 2005 10:36:43 -0500 Subject: Fedora Core 4 In-Reply-To: <1105976014.4673.18.camel@nexus.verbum.private> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> <1105968445.31480.103.camel@erato.phig.org> <1105972254.19179.4.camel@stargrazer.home.awesomeplay.com> <1105976014.4673.18.camel@nexus.verbum.private> Message-ID: <1105976203.19179.11.camel@stargrazer.home.awesomeplay.com> On Mon, 2005-01-17 at 10:33 -0500, Colin Walters wrote: > On Mon, 2005-01-17 at 09:30 -0500, Sean Middleditch wrote: > > > Besides, changing them in Nautilus *WILL* break the system, because the > > second a package upgrade for selinux policies comes in and restorecon is > > run all of their customized settings will be erased. > > The policy package doesn't do any relabeling at the moment. This will > likely change though, because it does cause problems. When that occurs, > consideration will be given to preserving customized file contexts. So a policy update that necessitates a security fix - like changing the context of a file that was mislabeled and is allowing access that should be denied - can't be done? > > From walters at redhat.com Mon Jan 17 15:43:25 2005 From: walters at redhat.com (Colin Walters) Date: Mon, 17 Jan 2005 10:43:25 -0500 Subject: Fedora Core 4 In-Reply-To: <1105976203.19179.11.camel@stargrazer.home.awesomeplay.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> <1105968445.31480.103.camel@erato.phig.org> <1105972254.19179.4.camel@stargrazer.home.awesomeplay.com> <1105976014.4673.18.camel@nexus.verbum.private> <1105976203.19179.11.camel@stargrazer.home.awesomeplay.com> Message-ID: <1105976605.4673.23.camel@nexus.verbum.private> On Mon, 2005-01-17 at 10:36 -0500, Sean Middleditch wrote: > On Mon, 2005-01-17 at 10:33 -0500, Colin Walters wrote: > > On Mon, 2005-01-17 at 09:30 -0500, Sean Middleditch wrote: > > > > > Besides, changing them in Nautilus *WILL* break the system, because the > > > second a package upgrade for selinux policies comes in and restorecon is > > > run all of their customized settings will be erased. > > > > The policy package doesn't do any relabeling at the moment. This will > > likely change though, because it does cause problems. When that occurs, > > consideration will be given to preserving customized file contexts. > > So a policy update that necessitates a security fix - like changing the > context of a file that was mislabeled and is allowing access that should > be denied - can't be done? It could be done, but that solution would have to be weighed against other available solutions. For example, why did this file get mislabeled? Can we fix the root cause? Can we keep the context and adjust policy? Etc. From lists at donut.dk Mon Jan 17 15:44:45 2005 From: lists at donut.dk (lists) Date: Mon, 17 Jan 2005 16:44:45 +0100 Subject: DB_File needs compatible versions of libdb & db.h Message-ID: <20050117154445.5899.qmail@donut.dk> Im trying out rawhide, and have run into a problem can someone please tell me how i can fix this? (or what packages / files to look at) DB_File needs compatible versions of libdb & db.h you have db.h version 4.3.21 and libdb version 4.3.27 Compilation failed in require at /var/qmail/bin/qmail-scanner-queue.pl line 1246. From dpaun at rogers.com Mon Jan 17 15:50:46 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Mon, 17 Jan 2005 10:50:46 -0500 Subject: Fedora Core 4 In-Reply-To: <1105972473.3725.75.camel@cutter> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> <1105972473.3725.75.camel@cutter> Message-ID: <20050117155046.GA19082@rogers.com> On Mon, Jan 17, 2005 at 09:34:33AM -0500, seth vidal wrote: > then users can: > wget url://to/that/rpm > yum install /that/rpm Heh, maybe yum could support (for consistency with rpm): yum install url://to/that/rpm -- Dimi. From n3npq at nc.rr.com Mon Jan 17 16:32:27 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 17 Jan 2005 11:32:27 -0500 Subject: DB_File needs compatible versions of libdb & db.h In-Reply-To: <20050117154445.5899.qmail@donut.dk> References: <20050117154445.5899.qmail@donut.dk> Message-ID: <41EBE89B.1080805@nc.rr.com> lists wrote: > > Im trying out rawhide, and have run into a problem can someone please > tell me how i can fix this? (or what packages / files to look at) > DB_File needs compatible versions of libdb & db.h > you have db.h version 4.3.21 and libdb version 4.3.27 > Compilation failed in require at /var/qmail/bin/qmail-scanner-queue.pl > line 1246. > Upgrade to the db4-devel-4.3.27 package. 73 de Jeff From skvidal at phy.duke.edu Mon Jan 17 16:34:51 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 17 Jan 2005 11:34:51 -0500 Subject: Fedora Core 4 In-Reply-To: <20050117155046.GA19082@rogers.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> <1105972473.3725.75.camel@cutter> <20050117155046.GA19082@rogers.com> Message-ID: <1105979691.3725.92.camel@cutter> On Mon, 2005-01-17 at 10:50 -0500, Dimitrie O. Paun wrote: > On Mon, Jan 17, 2005 at 09:34:33AM -0500, seth vidal wrote: > > then users can: > > wget url://to/that/rpm > > yum install /that/rpm > > Heh, maybe yum could support (for consistency with rpm): > yum install url://to/that/rpm The thing I hate about that syntax is that it lets users do some very- possibly stupid stuff w/o having to think very hard. Making it a two step process at least makes them think a tiny bit more about the very-possibly stupid act their about to undertake. oh and for future reference: consistency with rpm's user interface is not and will not be a design goal of yum development. It may end up that way, occasionally, but it's not going to be something that drives my decisions. -sv From skvidal at phy.duke.edu Mon Jan 17 16:36:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 17 Jan 2005 11:36:06 -0500 Subject: Fedora Core 4 In-Reply-To: <1105979691.3725.92.camel@cutter> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> <1105972473.3725.75.camel@cutter> <20050117155046.GA19082@rogers.com> <1105979691.3725.92.camel@cutter> Message-ID: <1105979766.3725.94.camel@cutter> On Mon, 2005-01-17 at 11:34 -0500, seth vidal wrote: > On Mon, 2005-01-17 at 10:50 -0500, Dimitrie O. Paun wrote: > > On Mon, Jan 17, 2005 at 09:34:33AM -0500, seth vidal wrote: > > > then users can: > > > wget url://to/that/rpm > > > yum install /that/rpm > > > > Heh, maybe yum could support (for consistency with rpm): > > yum install url://to/that/rpm > > The thing I hate about that syntax is that it lets users do some very- > possibly stupid stuff w/o having to think very hard. > > Making it a two step process at least makes them think a tiny bit more > about the very-possibly stupid act their about to undertake. > Wrong 'their'. I meant to use they're. sorry. -sv From skvidal at phy.duke.edu Mon Jan 17 16:49:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 17 Jan 2005 11:49:07 -0500 Subject: Reopen a request for gpgme in Core In-Reply-To: <20050117132021.36fd2892.fedora@wir-sind-cool.org> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106110659.17f329f0.toshio@tiki-lounge.com> <20050106183045.1991bdbb.fedora@wir-sind-cool.org> <200501062148.50705.dennis@ausil.us> <41DEB7AD.6090000@math.unl.edu> <20050117132021.36fd2892.fedora@wir-sind-cool.org> Message-ID: <1105980547.3725.105.camel@cutter> > By default, KMail in FC3 only supports OpenPGP through built-in GPGME > and external GnuPG. > > How would we obsolete the cryptplug package? > > For KMail, which has been our only cryptplug user, it would work to > make a gpgme update "Obsoletes: cryptplug". E.g. the gpgme and gnupg > packages in the fedora.us queue is built with OpenPGP and S/MIME > support. But it would not be entirely correct, since gpgme >= 0.4.5 > is not a direct successor of cryptplug. > > We've discussed opportunity for meta-packages a long time ago, but > never implemented them. Where a package is not moved from Extras into > Core, we need ways to obsolete "old cruft" ourselves. One way to > achieve that in an upgrade would be to create and main a meta package > like "fedora-extras-release-3". > > Thoughts anyone? I think the reason is that metapackages just end up picking up lots of cruft and maintaining that package, going forward, is just a pain in the arse. Why not just have comps.xml-style groups and use the groupinstall/groupupdate options? Counting on obsoletes, I've found, is not always a good idea. Not to mention the very real possibility of something moving out of core to extras and then, for various dependency reasons, having to move back. as much fun as it is to have circular obsoletes, I think I'll pass. -sv From dhollis at davehollis.com Mon Jan 17 16:57:16 2005 From: dhollis at davehollis.com (David Hollis) Date: Mon, 17 Jan 2005 11:57:16 -0500 Subject: Building subversion javahl bindings In-Reply-To: <41E7CB99.1050804@mndfck.org> References: <41E7CB99.1050804@mndfck.org> Message-ID: <1105981036.5081.19.camel@dhollis-lnx.centricconsulting.com> On Fri, 2005-01-14 at 11:39 -0200, Pedro Lamar?o wrote: > I've got this patch to subversion.spec that allows optional building of > javahl bindings with a variable-specified JDK path. > I've built it as I need Subclipse to work. > What do you all think? > You may be able to get buy without having to explicitly set the path to the JDK if you use the jpackage.org JVM setup. It makes use of the alternatives system so my /usr/bin/java winds up pointing to /usr/lib/jvm/jre-1.5.0-sun/bin/java. Since RH is working with the jpackage.org folks, it may be a good way to go. Just a thought. -- David Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Mon Jan 17 17:11:49 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 17 Jan 2005 12:11:49 -0500 Subject: goals for fc4? In-Reply-To: <1105972251.5505.89.camel@ulysse.olympe.o2t> References: <5cf776b8050108150644336d04@mail.gmail.com> <1105328387.5866.4.camel@one.myworld> <1105493919l.5018l.11l@devel.mpeters.us> <1105964316.5505.13.camel@ulysse.olympe.o2t> <1105968591.933.2.camel@va.local.linuxlobbyist.org> <1105972251.5505.89.camel@ulysse.olympe.o2t> Message-ID: <20050117171149.GB11715@devserv.devel.redhat.com> On Mon, Jan 17, 2005 at 03:30:50PM +0100, Nicolas Mailhot wrote: > bytecode. I don't think there is anyone made the argument than gcj + > native is faster than commercial jvm + bytecode. Do the benchmarks on a real world test set or for that matter just compare the start up time of a proprietary commercial jv eclipse and a compiled one. The compiled stuff starts much faster and consumers astronomically less memory and memory bandwidth when running. There are also some nice java bindings for Gnome which are useful when you need to run the same core code with a different UI on your phone and Linux box. I still want an implementation of lcdui for gcj so I can play java phone games on my PC but I digress... Alan From alan at redhat.com Mon Jan 17 17:14:05 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 17 Jan 2005 12:14:05 -0500 Subject: Fedora Core 4 In-Reply-To: <1105972473.3725.75.camel@cutter> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> <1105972473.3725.75.camel@cutter> Message-ID: <20050117171405.GC11715@devserv.devel.redhat.com> On Mon, Jan 17, 2005 at 09:34:33AM -0500, seth vidal wrote: > I think the best way for other packaging sites to make their stuff > available, trivially, for yum would be to make a package that provides > their .repo file. > > then users can: > wget url://to/that/rpm > yum install /that/rpm Time to repeat the six year old proposal originally internally and extenrally since. Define a mime type for a repository description file and its format. Add it with a helper app for mozilla/konqueror/firefox. At that point you can click on a "subscribe to DAG" button on a web page and let the helper do the work (via consolehelper to do the "root password" bit) Alan From mattdm at mattdm.org Mon Jan 17 17:26:12 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 17 Jan 2005 12:26:12 -0500 Subject: Fedora Core 4 In-Reply-To: <20050117171405.GC11715@devserv.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> <1105972473.3725.75.camel@cutter> <20050117171405.GC11715@devserv.devel.redhat.com> Message-ID: <20050117172612.GA833@jadzia.bu.edu> On Mon, Jan 17, 2005 at 12:14:05PM -0500, Alan Cox wrote: > Time to repeat the six year old proposal originally internally and extenrally > since. > Define a mime type for a repository description file and its format. Add it > with a helper app for mozilla/konqueror/firefox. > At that point you can click on a "subscribe to DAG" button on a web page and > let the helper do the work (via consolehelper to do the "root password" bit) This sounds like it'd be reasonable to integrate with pup, since it's doing gui-yum-stuff already. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dpaun at rogers.com Mon Jan 17 17:43:39 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Mon, 17 Jan 2005 12:43:39 -0500 Subject: Fedora Core 4 In-Reply-To: <1105979691.3725.92.camel@cutter> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> <1105972473.3725.75.camel@cutter> <20050117155046.GA19082@rogers.com> <1105979691.3725.92.camel@cutter> Message-ID: <20050117174339.GB19082@rogers.com> > The thing I hate about that syntax is that it lets users do some very- > possibly stupid stuff w/o having to think very hard. What's the big deal? They can do: rpm -i url:/to/the/rpm Which they have to run as root anyway. People would have an option to use either mothod, depending on their confort level. > Making it a two step process at least makes them think a tiny bit more > about the very-possibly stupid act their about to undertake. Heh, they can do so many stupid things as root, this is just an annoyance more then anything. Don't get me wrong, I don't feel that strongly for it, but I'm not sure I buy the argument. > oh and for future reference: consistency with rpm's user interface is > not and will not be a design goal of yum development. It may end up that > way, occasionally, but it's not going to be something that drives my > decisions. I know you don't aim for consistency with rpm, but having it where it doesn't hurt would be nice, no? -- Dimi. From Nicolas.Mailhot at laPoste.net Mon Jan 17 17:45:59 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 17 Jan 2005 18:45:59 +0100 Subject: [JPackage-discuss] Re: goals for fc4? In-Reply-To: <20050117171149.GB11715@devserv.devel.redhat.com> References: <5cf776b8050108150644336d04@mail.gmail.com> <1105328387.5866.4.camel@one.myworld> <1105493919l.5018l.11l@devel.mpeters.us> <1105964316.5505.13.camel@ulysse.olympe.o2t> <1105968591.933.2.camel@va.local.linuxlobbyist.org> <1105972251.5505.89.camel@ulysse.olympe.o2t> <20050117171149.GB11715@devserv.devel.redhat.com> Message-ID: <1105983959.20677.5.camel@rousalka.dyndns.org> Le lundi 17 janvier 2005 ? 12:11 -0500, Alan Cox a ?crit : > On Mon, Jan 17, 2005 at 03:30:50PM +0100, Nicolas Mailhot wrote: > > bytecode. I don't think there is anyone made the argument than gcj + > > native is faster than commercial jvm + bytecode. > > Do the benchmarks on a real world test set or for that matter just compare > the start up time of a proprietary commercial jv eclipse and a compiled one. > > The compiled stuff starts much faster and consumers astronomically less > memory and memory bandwidth when running. There are also some nice java > bindings for Gnome which are useful when you need to run the same core code > with a different UI on your phone and Linux box. > > I still want an implementation of lcdui for gcj so I can play java phone games > on my PC but I digress... I stand corrected;) I hope the gcj packages in FC4 will prove this to all. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Mon Jan 17 18:28:17 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 17 Jan 2005 13:28:17 -0500 Subject: Fedora Core 4 In-Reply-To: <20050117174339.GB19082@rogers.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> <1105972473.3725.75.camel@cutter> <20050117155046.GA19082@rogers.com> <1105979691.3725.92.camel@cutter> <20050117174339.GB19082@rogers.com> Message-ID: <1105986497.3725.126.camel@cutter> On Mon, 2005-01-17 at 12:43 -0500, Dimitrie O. Paun wrote: > > The thing I hate about that syntax is that it lets users do some very- > > possibly stupid stuff w/o having to think very hard. > > What's the big deal? They can do: > rpm -i url:/to/the/rpm they can also do: rpm -e --force glibc but that doesn't mean I'm going to let that happen in yum, either. :) -sv From mike at navi.cx Mon Jan 17 18:53:38 2005 From: mike at navi.cx (Mike Hearn) Date: Mon, 17 Jan 2005 18:53:38 +0000 Subject: Dmix (Fedora Core 4) References: <20050114223020.GA7168@nostromo.devel.redhat.com> <20050116142724.400d54aa@nausicaa.camperquake.de> <1105887099.9959.20.camel@galvatron.localdomain> <20050116160905.5f7ee091@nausicaa.camperquake.de> <1105894669.9959.35.camel@galvatron.localdomain> <1105920508.4673.3.camel@nexus.verbum.private> <1105948175.10063.7.camel@galvatron.localdomain> Message-ID: On Mon, 17 Jan 2005 07:49:34 +0000, Sitsofe Wheeler wrote: > On Sun, 2005-01-16 at 19:08 -0500, Colin Walters wrote: > > We're trading one very serious, major bug (sound mixing not working > > for anyone) for a few more minor bugs (sound mixing not efficient as > > Didn't it work for those with hardware mixing? It certainly appeared to > work for me (with or without esd)... Correct. Really it needs to be slicker: kudzu or HAL needs let the system know if the sound cards support hardware mixing. DMIX can then be selectively enabled or disabled on that basis. Of course, I'm not volunteering to do that ;) From adriano.galano at gmail.com Mon Jan 17 19:01:44 2005 From: adriano.galano at gmail.com (Adriano Galano) Date: Mon, 17 Jan 2005 20:01:44 +0100 Subject: Ummm...SeXen? Message-ID: <754f42e70501171101376d3727@mail.gmail.com> Hi: Interesting reference about Secure Xen: http://sourceforge.net/mailarchive/forum.php?thread_id=6364737&forum_id=35600 Maybe a suggestion to FC4....or maybe FC5 ;-) Regards, -Adriano -- Adriano M. (bryam) Galano D?ez In LiNUX and FLOSS since 1992 (R) http://bryam.blogspot.com From lists at donut.dk Mon Jan 17 19:06:00 2005 From: lists at donut.dk (Cream[DONut]) Date: Mon, 17 Jan 2005 20:06:00 +0100 Subject: DB_File needs compatible versions of libdb & db.h In-Reply-To: <41EBE89B.1080805@nc.rr.com> References: <20050117154445.5899.qmail@donut.dk> <41EBE89B.1080805@nc.rr.com> Message-ID: <41EC0C98.60507@donut.dk> Jeff Johnson wrote: > lists wrote: >> DB_File needs compatible versions of libdb & db.h >> you have db.h version 4.3.21 and libdb version 4.3.27 >> Compilation failed in require at /var/qmail/bin/qmail-scanner-queue.pl >> line 1246. >> > Upgrade to the db4-devel-4.3.27 package. (the original message was from me) I do have dv4-devel-4.3.27 installed # rpm -qf /usr/lib/perl5/5.8.5/i386-linux-thread-multi/DB_File.pm perl-5.8.5-13 It seems DB_File.pm is from the perl package, and thats why im having problems. In lack of other options i have force installed the old db4-*4.2.21 rpms, the only dependency being pam, i hope it will keep working. Thanks for the quick reply Kris From whooperhsd at gmail.com Mon Jan 17 19:17:21 2005 From: whooperhsd at gmail.com (William Hooper) Date: Mon, 17 Jan 2005 14:17:21 -0500 Subject: website update In-Reply-To: References: Message-ID: <6314dfde05011711176096a431@mail.gmail.com> On Sun, 16 Jan 2005 19:11:28 +0100, Lars wrote: > ...and registering the missing lists with gmane.org for easy tracking via > newsreader would be nice too! Check the existing list: http://dir.gmane.org/index.php?prefix=gmane.linux.redhat.fedora Then request any that are missing: http://gmane.org/subscribe.php -- William Hooper From Nicolas.Mailhot at laPoste.net Mon Jan 17 19:20:14 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 17 Jan 2005 20:20:14 +0100 Subject: DB_File needs compatible versions of libdb & db.h In-Reply-To: <41EC0C98.60507@donut.dk> References: <20050117154445.5899.qmail@donut.dk> <41EBE89B.1080805@nc.rr.com> <41EC0C98.60507@donut.dk> Message-ID: <1105989614.20677.8.camel@rousalka.dyndns.org> Le lundi 17 janvier 2005 ? 20:06 +0100, Cream[DONut] a ?crit : > Jeff Johnson wrote: > > lists wrote: > >> DB_File needs compatible versions of libdb & db.h > >> you have db.h version 4.3.21 and libdb version 4.3.27 > >> Compilation failed in require at /var/qmail/bin/qmail-scanner-queue.pl > >> line 1246. > >> > > Upgrade to the db4-devel-4.3.27 package. > > (the original message was from me) > > I do have dv4-devel-4.3.27 installed > > # rpm -qf /usr/lib/perl5/5.8.5/i386-linux-thread-multi/DB_File.pm > perl-5.8.5-13 > > It seems DB_File.pm is from the perl package, and thats why im having > problems. In lack of other options i have force installed the old > db4-*4.2.21 rpms, the only dependency being pam, i hope it will keep > working. If fact there *is* a problem with DB_FILE & ?rl in rawhide, as the fun messages spamassassin sends me show : Use of uninitialized value in numeric gt (>) at /usr/lib/perl5/5.8.5/i386-linux-thread-multi/DB_File.pm line 271. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pri.rhl3 at iadonisi.to Mon Jan 17 19:22:21 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Mon, 17 Jan 2005 14:22:21 -0500 Subject: goals for fc4? In-Reply-To: <20050117171149.GB11715@devserv.devel.redhat.com> References: <5cf776b8050108150644336d04@mail.gmail.com> <1105328387.5866.4.camel@one.myworld> <1105493919l.5018l.11l@devel.mpeters.us> <1105964316.5505.13.camel@ulysse.olympe.o2t> <1105968591.933.2.camel@va.local.linuxlobbyist.org> <1105972251.5505.89.camel@ulysse.olympe.o2t> <20050117171149.GB11715@devserv.devel.redhat.com> Message-ID: <1105989741.3912.4.camel@va.local.linuxlobbyist.org> Thanks for the responses. With all the work going on in this area, with virtualization, with new platforms ... I'm looking forward to the next release cycle (and that one after that!). Happy hacking to all -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From michael.favia at insitesinc.com Mon Jan 17 19:25:32 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Mon, 17 Jan 2005 13:25:32 -0600 Subject: New icon placement on gnome desktop. Message-ID: <41EC112C.8050908@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 New icons that are automatically added to the desktop upon insertion of removable media (e.g. USB mass storage, cd, dvd) often place themselves behind existing icons on my desktop and create a ugly kaleidescope like mash of icon and text. Is this a known issue (e.i. bug report filed and i cant find it) or if not is this a gnome based issue or is HAL/udev at work here (to report it)? BTW it is fixed by simple "Arranging by name" but it seems a silly requirement. Sorry if mildly/not so mildly off topic (but im not looking for someone to fix "my" problem). - -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB7BEsBVsNYjF2rDYRAl5uAJ4pWNq5RLTxPuZGxbUMD5uShSsfiwCfYUOI FWwZNZ3n6Ic7gzuY8yhMueg= =xBMM -----END PGP SIGNATURE----- From kyrre at solution-forge.net Mon Jan 17 19:29:42 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 17 Jan 2005 20:29:42 +0100 Subject: Fedora Core 4 In-Reply-To: <20050117172612.GA833@jadzia.bu.edu> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> <1105972473.3725.75.camel@cutter> <20050117171405.GC11715@devserv.devel.redhat.com> <20050117172612.GA833@jadzia.bu.edu> Message-ID: <1105990182.1536.19.camel@localhost.localdomain> man, 17.01.2005 kl. 18.26 skrev Matthew Miller: > On Mon, Jan 17, 2005 at 12:14:05PM -0500, Alan Cox wrote: > > Time to repeat the six year old proposal originally internally and extenrally > > since. > > Define a mime type for a repository description file and its format. Add it > > with a helper app for mozilla/konqueror/firefox. > > At that point you can click on a "subscribe to DAG" button on a web page and > > let the helper do the work (via consolehelper to do the "root password" bit) > > This sounds like it'd be reasonable to integrate with pup, since it's doing > gui-yum-stuff already. > Sounds nice! How about repo dep. tracking (i.e. extras depending on Core, livna on extras etc? :P Or simply "yum repoinstall http://blah.hah.org/muhaha" ? Whats "pup"? > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> From kyrre at solution-forge.net Mon Jan 17 19:32:39 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 17 Jan 2005 20:32:39 +0100 Subject: Livna down? Message-ID: <1105990359.1536.21.camel@localhost.localdomain> I can't get to rpm.livna.org from this computer - any recent changes (DNS etc)? From skvidal at phy.duke.edu Mon Jan 17 19:39:13 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 17 Jan 2005 14:39:13 -0500 Subject: Fedora Core 4 In-Reply-To: <1105990182.1536.19.camel@localhost.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> <1105972473.3725.75.camel@cutter> <20050117171405.GC11715@devserv.devel.redhat.com> <20050117172612.GA833@jadzia.bu.edu> <1105990182.1536.19.camel@localhost.localdomain> Message-ID: <1105990753.3725.138.camel@cutter> > > > > Sounds nice! How about repo dep. tracking (i.e. extras depending on > Core, livna on extras etc? :P If you feel like writing that, feel free. I think you'll find that matching deps to repos is a fast track to hell. > Whats "pup"? Read fedora-config-list. -sv From dag at wieers.com Mon Jan 17 20:46:56 2005 From: dag at wieers.com (Dag Wieers) Date: Mon, 17 Jan 2005 21:46:56 +0100 (CET) Subject: Fedora Core 4 In-Reply-To: <20050117171405.GC11715@devserv.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> <1105972473.3725.75.camel@cutter> <20050117171405.GC11715@devserv.devel.redhat.com> Message-ID: On Mon, 17 Jan 2005, Alan Cox wrote: > On Mon, Jan 17, 2005 at 09:34:33AM -0500, seth vidal wrote: > > I think the best way for other packaging sites to make their stuff > > available, trivially, for yum would be to make a package that provides > > their .repo file. > > > > then users can: > > wget url://to/that/rpm > > yum install /that/rpm > > Time to repeat the six year old proposal originally internally and extenrally > since. > > Define a mime type for a repository description file and its format. Add it > with a helper app for mozilla/konqueror/firefox. > > At that point you can click on a "subscribe to DAG" button on a web page and > let the helper do the work (via consolehelper to do the "root password" bit) Coincidentally, Gustavo designed smart to allow this: smart channel --add http://some.url/mychannel.txt smart channel --add mychannel.txt It would be nice to have a special content-type/extension for this that is standardized between different package managers. The syntax for such a channel definition is pretty straightforward: ### URL: http://dag.wieers.com/apt/ [dag] name = RPMforge.net: Various packages from Dag RPM Repository for Fedora Core 3 (i386) baseurl = http://apt.sw.be/fedora/3/en/i386/dag type = rpm-md priority = 10 Would be nice if this could be established. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From lists at donut.dk Mon Jan 17 21:25:11 2005 From: lists at donut.dk (Cream[DONut]) Date: Mon, 17 Jan 2005 22:25:11 +0100 Subject: DB_File needs compatible versions of libdb & db.h In-Reply-To: <1105989614.20677.8.camel@rousalka.dyndns.org> References: <20050117154445.5899.qmail@donut.dk> <41EBE89B.1080805@nc.rr.com> <41EC0C98.60507@donut.dk> <1105989614.20677.8.camel@rousalka.dyndns.org> Message-ID: <41EC2D37.4060202@donut.dk> Nicolas Mailhot wrote: >Le lundi 17 janvier 2005 ? 20:06 +0100, Cream[DONut] a ??crit : > >If fact there *is* a problem with DB_FILE & ??rl in rawhide, as the fun >messages spamassassin sends me show : > >Use of uninitialized value in numeric gt (>) >at /usr/lib/perl5/5.8.5/i386-linux-thread-multi/DB_File.pm line 271. > I got that one too with spamassassin, still getting it after my forced downgrade of db4. Cream From mpeters at mac.com Mon Jan 17 21:28:01 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 17 Jan 2005 21:28:01 +0000 Subject: Livna down? In-Reply-To: <1105990359.1536.21.camel@localhost.localdomain> (from kyrre@solution-forge.net on Mon Jan 17 11:32:39 2005) References: <1105990359.1536.21.camel@localhost.localdomain> Message-ID: <1105997281l.6932l.2l@devel.mpeters.us> On 01/17/2005 11:32:39 AM, Kyrre Ness Sjobak wrote: > I can't get to rpm.livna.org from this computer - any recent changes > (DNS etc)? I can get to it - but some other people have had timeout problems and used a mirror with more success, it's posted earlier today on the list. From cturner at redhat.com Mon Jan 17 23:01:03 2005 From: cturner at redhat.com (Chip Turner) Date: Mon, 17 Jan 2005 18:01:03 -0500 Subject: goals for fc4? In-Reply-To: <20050117171149.GB11715@devserv.devel.redhat.com> (Alan Cox's message of "Mon, 17 Jan 2005 12:11:49 -0500") References: <5cf776b8050108150644336d04@mail.gmail.com> <1105328387.5866.4.camel@one.myworld> <1105493919l.5018l.11l@devel.mpeters.us> <1105964316.5505.13.camel@ulysse.olympe.o2t> <1105968591.933.2.camel@va.local.linuxlobbyist.org> <1105972251.5505.89.camel@ulysse.olympe.o2t> <20050117171149.GB11715@devserv.devel.redhat.com> Message-ID: Alan Cox writes: > On Mon, Jan 17, 2005 at 03:30:50PM +0100, Nicolas Mailhot wrote: >> bytecode. I don't think there is anyone made the argument than gcj + >> native is faster than commercial jvm + bytecode. > > Do the benchmarks on a real world test set or for that matter just compare > the start up time of a proprietary commercial jv eclipse and a compiled one. > > The compiled stuff starts much faster and consumers astronomically less > memory and memory bandwidth when running. There are also some nice java > bindings for Gnome which are useful when you need to run the same core code > with a different UI on your phone and Linux box. I don't think it's as clear cut as that. App startup time matters for, say, CLIs (but who would make a java cli app... well, except ant, heh) and for GUI apps (which starts to matter a little more) but not so much about some of the more interesting Java areas -- serverside. I think at best the jury is still out on how fast gcj is vs a hotspot-optimizing jvm for "real world" use. It would be interesting to see some benchmarks comparing real-world workloads and examples. I don't know of any off hand, though, that included gcj. Chip -- Chip Turner cturner at redhat.com Red Hat, Inc. From alan at redhat.com Mon Jan 17 23:12:27 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 17 Jan 2005 18:12:27 -0500 Subject: goals for fc4? In-Reply-To: References: <5cf776b8050108150644336d04@mail.gmail.com> <1105328387.5866.4.camel@one.myworld> <1105493919l.5018l.11l@devel.mpeters.us> <1105964316.5505.13.camel@ulysse.olympe.o2t> <1105968591.933.2.camel@va.local.linuxlobbyist.org> <1105972251.5505.89.camel@ulysse.olympe.o2t> <20050117171149.GB11715@devserv.devel.redhat.com> Message-ID: <20050117231227.GB7452@devserv.devel.redhat.com> On Mon, Jan 17, 2005 at 06:01:03PM -0500, Chip Turner wrote: > not so much about some of the more interesting Java areas -- > serverside. I think at best the jury is still out on how fast gcj is > vs a hotspot-optimizing jvm for "real world" use. I've certainly not done formal benchmarks but playing with it I've found that the good jvm's appear to be a little slower (not a lot) but use astronomically more resources. Which I'd kind of expect intuitively From tromey at redhat.com Mon Jan 17 23:41:39 2005 From: tromey at redhat.com (Tom Tromey) Date: 17 Jan 2005 16:41:39 -0700 Subject: goals for fc4? In-Reply-To: References: <5cf776b8050108150644336d04@mail.gmail.com> <1105328387.5866.4.camel@one.myworld> <1105493919l.5018l.11l@devel.mpeters.us> <1105964316.5505.13.camel@ulysse.olympe.o2t> <1105968591.933.2.camel@va.local.linuxlobbyist.org> <1105972251.5505.89.camel@ulysse.olympe.o2t> <20050117171149.GB11715@devserv.devel.redhat.com> Message-ID: >>>>> "Chip" == Chip Turner writes: Chip> I think at best the jury is still out on how fast gcj is Chip> vs a hotspot-optimizing jvm for "real world" use. Best performance depends on a lot of factors, not just your application but also how you plan to deploy it. For instance, using gcj to build shared libraries may be a winner when you expect to be reusing that library in several running processes, even if the generated code looks marginally slower. gcj and hotspot-like JITs have different optimization opportunities available to them. Another factor is how you compile your code with gcj; the new binary compatibility ABI provides flexibility at the cost of some performance. The usual answer is "try your program and see". On smaller-than-real-applications benchmarks, gcj fares pretty well against the best JITs (especially considering how few gcj-specific optimizations we've added to gcc, e.g. we still haven't implemented array bounds check removal). The 1.5 release from Sun looks like it pulled ahead a little bit, though you can still construct tests where gcj does better. I would expect some bounce from gcc in the 4.1 time frame, though, as more high-level optimizations are written. As a practical matter touching on Fedora, gcj remains the "best" way to deliver java applications on a free system. In my opinion, other free VMs have unacceptable performance, unacceptable platform coverage, or both. Tom From carwyn at carwyn.com Mon Jan 17 23:58:00 2005 From: carwyn at carwyn.com (Carwyn Edwards) Date: Mon, 17 Jan 2005 23:58:00 +0000 Subject: goals for fc4? In-Reply-To: References: <5cf776b8050108150644336d04@mail.gmail.com> <1105328387.5866.4.camel@one.myworld> <1105493919l.5018l.11l@devel.mpeters.us> <1105964316.5505.13.camel@ulysse.olympe.o2t> <1105968591.933.2.camel@va.local.linuxlobbyist.org> <1105972251.5505.89.camel@ulysse.olympe.o2t> <20050117171149.GB11715@devserv.devel.redhat.com> Message-ID: <9DEF1CBE-68E3-11D9-9662-000D9350AFAA@carwyn.com> On 17 Jan 2005, at 23:01, Chip Turner wrote: > > I don't think it's as clear cut as that. I'd agree, many High Performance Computing Research Groups are looking at Java these days. Some recent benchmarks along these lines: http://www.shudo.net/jit/perf/ (Best taken with the usual benchmark pinch of salt.) For desktop applications startup times and memory footprints are still a problem, although recent VMs are getting better. Carwyn From cturner at redhat.com Tue Jan 18 00:06:35 2005 From: cturner at redhat.com (Chip Turner) Date: Mon, 17 Jan 2005 19:06:35 -0500 Subject: perl INSTALLDIRS=vendor In-Reply-To: <1105120812.5058.37.camel@bobcat.mine.nu> (Ville =?utf-8?q?Skytt=C3=A4's?= message of "Fri, 07 Jan 2005 20:00:12 +0200") References: <41D95031.2060903@balclutha.org> <1105120812.5058.37.camel@bobcat.mine.nu> Message-ID: Ville Skytt? writes: > On Tue, 2005-01-04 at 01:01 +1100, Alan Milligan wrote: > >> I'm having a few problems source compiling a number of perl modules. I >> don't really like this vendor concept, whats wrong with site_perl?? > > The modules come from a vendor -> they should go into vendor install > dirs. Site install dirs are for local site installs so that admins can > override system installed stuff a la "perl -MCPAN -e install Foo-Bar" > and traditional tarball install. (Moving site_perl in /usr/local/... > would make this clearer FHS-wise.) I like that idea. A lot. I'd not thought about it til now, but that makes a tremendous amount of sense. It would also address the manpage issue, I think. It would break backwards compatibility, though, with older RPMs (unless we still looked in the /usr/lib/.../site_perl/ dirs, but I'm inclined not to). > In my experience, a lot of bug reports containing the magic string > "perl" in bugzilla.redhat.com or here do not tend to draw much > attention. Hopefully there will be something that the community can do > about it in future FC. That's my fault. I don't get much time to spend on perl as I would like. Now that CVS is exposed, though, I'm hoping I get more help from the community :) There are a TON of perl bugs at this point. Many are no longer valid, but many are. I need to triage them all, but that would likely take more time than fixing most of the ones worth fixing, I suspect. Perhaps it would be better to start a general thread on perl and perl module packaging, and go from there, see what people like/don't like, etc. btw perl 5.8.6 should be in rawhide tonight or tomorrow. Chip -- Chip Turner cturner at redhat.com Red Hat, Inc. From cmadams at hiwaay.net Tue Jan 18 01:52:27 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 17 Jan 2005 19:52:27 -0600 Subject: perl INSTALLDIRS=vendor In-Reply-To: References: <41D95031.2060903@balclutha.org> <1105120812.5058.37.camel@bobcat.mine.nu> Message-ID: <20050118015227.GA1496663@hiwaay.net> Once upon a time, Chip Turner said: > Ville Skytt?? writes: > > The modules come from a vendor -> they should go into vendor install > > dirs. Site install dirs are for local site installs so that admins can > > override system installed stuff a la "perl -MCPAN -e install Foo-Bar" > > and traditional tarball install. (Moving site_perl in /usr/local/... > > would make this clearer FHS-wise.) > > I like that idea. A lot. I'd not thought about it til now, but that > makes a tremendous amount of sense. It would also address the manpage > issue, I think. It would break backwards compatibility, though, with > older RPMs (unless we still looked in the /usr/lib/.../site_perl/ > dirs, but I'm inclined not to). Hmm, you might as well change "vendor_perl" to "rpm_perl" then. I don't want RPM touching /usr/local (that's for the few odds and ends I install manually and local or per-system scripts), but I install perl modules from RPMs all the time. "vendor" to me means Red Hat or Fedora, so I wouldn't make my perl module RPMs install into the "vendor" directory. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From byte at aeon.com.my Tue Jan 18 04:35:29 2005 From: byte at aeon.com.my (Colin Charles) Date: Tue, 18 Jan 2005 12:35:29 +0800 Subject: Proposal: swap epic for irssi Message-ID: <1106022929.6105.106.camel@localhost.localdomain> Hi, For FC-4, what would folk think about removing epic and replacing it with irssi in Core? irssi currently sits in Extras, and we could very likely just move epic to Extras after the swap. Thoughts? -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From rahulsundaram at gmail.com Tue Jan 18 12:25:06 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Tue, 18 Jan 2005 17:55:06 +0530 Subject: Mozilla trademark Message-ID: Hi Since there was a long discussion about the Mozilla trademark policy. This might be of interest to the developers and others concerned. http://lwn.net/Articles/119326/ -- Regards, Rahul Sundaram From sds at epoch.ncsc.mil Tue Jan 18 12:23:45 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 18 Jan 2005 07:23:45 -0500 Subject: Fedora Core 4 In-Reply-To: <20050117144400.GA550031@hiwaay.net> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> <1105968445.31480.103.camel@erato.phig.org> <1105972254.19179.4.camel@stargrazer.home.awesomeplay.com> <20050117144400.GA550031@hiwaay.net> Message-ID: <1106051025.18274.11.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-01-17 at 09:44, Chris Adams wrote: > Once upon a time, Sean Middleditch said: > > Besides, changing them in Nautilus *WILL* break the system, because the > > second a package upgrade for selinux policies comes in and restorecon is > > run all of their customized settings will be erased. > > Does that reset every context on the system, including on non-RPM files? > If so, that's going to be highly confusing to both users and system > administrators. What is the point of even having the chcon command if > everything will be reset to some config file contents at arbitrary > times? Just load the config file into the kernel and use it directly. Policy updates do NOT relabel by default. And if properly handled, only selective relabeling should ever be necessary. Full filesystem relabel should only occur at install time or upon major policy changes (e.g. switching between targeted and strict policies). The on-disk attributes are authoritative; the file_contexts configuration is merely for initialization at install time. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Tue Jan 18 12:24:29 2005 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Tue, 18 Jan 2005 07:24:29 -0500 Subject: Fedora Core 4 In-Reply-To: <1105973794.19179.9.camel@stargrazer.home.awesomeplay.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> <1105968445.31480.103.camel@erato.phig.org> <1105972254.19179.4.camel@stargrazer.home.awesomeplay.com> <20050117144400.GA550031@hiwaay.net> <1105973794.19179.9.camel@stargrazer.home.awesomeplay.com> Message-ID: <1106051069.18274.14.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-01-17 at 09:56, Sean Middleditch wrote: > I never said SELinux is easy to configure. I just stated how it works. > It's actually essential that restorecon resets all files, according to > the SELinux experts I last spoke with, since that means that an "SELinux > security expert" (i.e. a relatively small handful of SELinux developers) > can look in one place to check the available flow of information and > privileges in the system; if you could change individual files then > you'd really have no way to know what files had what contexts without > expensive whole-system searches. (Granted, I think then that the file- > systems people use should be "fixed" to make it not-so-expensive and to > get rid of duality and complexity in SELinux configuration, but that's > of course not technically feasible for Red Hat to pull off in FC4.) Please don't mis-represent what others say. You don't seem to understand SELinux very well at all... -- Stephen Smalley National Security Agency From g.hollestelle at gmail.com Tue Jan 18 13:24:08 2005 From: g.hollestelle at gmail.com (Gijs Hollestelle) Date: Tue, 18 Jan 2005 14:24:08 +0100 Subject: Using custom startup scripts with rhgb Message-ID: <95da2d29050118052452d36455@mail.gmail.com> Hi, At our university we have a script that runs at boot time, which brings the system's packages up to date with a central server and does some other configuration stuff (compare it to running yum update at boot time). This script can take up to 5 minutes to complete but includes progress meters so that the user can see what is happening, this works nicely in the details pane of rhgb and when using text mode. This situation causes two problems under rhgb: 1) There appears to be no way of setting the caption (where it normally says things like Starting Networking) for the text box field, other than adding the string to the main.c file in rhgb. I would like to be able to set a caption like 'Checking for updated packages' or something alike. 2) If there is no rhgb ping command for 35 seconds rhgb swithces back to terminal 1 (which does not show te progress, that is shown correctly in the details pane, but displays only the start of the boot process with two empty lines between every message). Is there a way to disable this time-out (temporarily) other than hacking it away in the main.c file? If there is currently no way of doing these 2 without changing the C code, would it be possible to add commands to rhgb-client to support these? as I could imagine they would be useful to others as well. Kind regards, Gijs Hollestelle From buildsys at redhat.com Tue Jan 18 13:38:22 2005 From: buildsys at redhat.com (Build System) Date: Tue, 18 Jan 2005 08:38:22 -0500 Subject: rawhide report: 20050118 changes Message-ID: <200501181338.j0IDcMX09282@porkchop.devel.redhat.com> Updated Packages: abiword-1:2.2.3-1 ----------------- * Mon Jan 17 2005 Caolan McNamara - 1:2.2.3-1 - bump to new version - drop integrated silenceabidash patch cpio-2.6-3 ---------- * Mon Jan 17 2005 Peter Vrabec - fix symlinks pack (#145225) * Fri Jan 14 2005 Peter Vrabec - new fixed version of lfs patch (#144688) * Thu Jan 13 2005 Peter Vrabec - upgrade to cpio-2.6 device-mapper-1.01.00-1 ----------------------- * Mon Jan 17 2005 Alasdair Kergon - 1.01.00-1 - Update lib interface to make open_count optional. eclipse-3.1-0.M4.19 ------------------- * Mon Jan 17 2005 Andrew Overholt 3.1-0.M4.19 - more 64-bit platform and launching script fixes - add ppc ethereal-0.10.8-3 ----------------- * Tue Jan 18 2005 Radek Vokal 0.10.8-3 - plugins are back - fixed spec file, removed libs renaming glibc-kernheaders-2.4-9.1.88 ---------------------------- * Tue Jan 18 2005 David Woodhouse - Fix and update and include missing ATM headers (#127098) - Update MTD headers. * Fri Dec 10 2004 Roland McGrath - update syscall numbers on x86_64, ia64 - removed many files users should not need - update ia64 ptrace_offsets.h (#117234) - other misc updates from upstream * Tue Aug 31 2004 Arjan van de Ven - update input.h kernel-2.6.10-1.1090_FC4 ------------------------ * Mon Jan 17 2005 Rik van Riel - apply dmi fix, now xenU boots again lvm2-2.01.00-1.0 ---------------- * Mon Jan 17 2005 Alasdair Kergon - 2.01.00-1.0 - Fix metadata auto-correction. Only request open_count when needed. man-pages-ja-20050115-1 ----------------------- * Tue Jan 18 2005 Akira TAGOH - 20050115-1 - updates to 20050115. pcmcia-cs-3.2.7-4.4 ------------------- * Tue Jan 18 2005 Dave Jones - Remove various old compatability cruft from rc.pcmcia - Update Requires: list. * Mon Jan 10 2005 Dave Jones - Fix missing return on new_tuple() (#137857) perl-3:5.8.6-1 -------------- * Mon Jan 17 2005 Chip Turner - 3:5.8.6-1 - update to 5.8.6 * Wed Dec 01 2004 Chip Turner 3:5.8.5-13 - rebuild * Wed Dec 01 2004 Chip Turner 3:5.8.5-11 - bugzilla: 140563, nptl doesn't act like linuxthreads; threads have no PIDs quagga-0:0.98.0-2 ----------------- * Sun Jan 16 2005 Jay Fenlason 0.98.0-2 - New upstream version. This fixes bz#143796 - --with-rtadv needs to be --enable-rtadv according to configure. (but it was enabled by default, so this is a cosmetic change only) Change /etc/logrotate.d/* to /etc/logrotate.d/quagga in this spec file. - Modify this spec file to move the .so files to the base package and close bz#140894 - Modify this spec file to separate out /usr/include/quagga/ospfd from .../*.h and /usr/include/quagga/ospfapi from .../*.h Rpmbuild probably shouldn't allow %dir of a plain file. * Wed Jan 12 2005 Tim Waugh 0.97.3-3 - Rebuilt for new readline. - Don't explicitly require readline. The correct dependency is automatically picked up by linking against it. rpmdb-fedora-1:4-0.20050118 --------------------------- subversion-1.1.3-1 ------------------ * Sun Jan 16 2005 Joe Orton 1.1.3-1 - update to 1.1.3 (#145236) - fix python bindings location on x86_64 (#143522) system-config-printer-0.6.120-1 ------------------------------- * Mon Jan 17 2005 Tim Waugh 0.6.120-1 - 0.6.120: - Disable CUPS import altogether (bug #142898). - Make sure chkconfig output is parseable (bug #142978). - Set LC_ALL=C instead of LANG=C (bug #143035). - Prevent infinite recursion in printconf_conf (bug #145335). * Fri Dec 10 2004 Tim Waugh 0.6.119-1 - Purge magicfilter references (bug #45687). - 0.6.119: - Purge magicfilter references (bug #45687). - Avoid traceback when there is no IEEE 1284 ID (bug #141430). * Tue Nov 30 2004 Tim Waugh 0.6.118-1 - 0.6.118: - Allow queue names to start with digits (bug #121772). wireless-tools-1:28-0.pre4.3 ---------------------------- * Mon Jan 17 2005 Dan Williams 28-0.pre4 - Update to latest wireless-tools From veillard at redhat.com Tue Jan 18 14:18:55 2005 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 18 Jan 2005 09:18:55 -0500 Subject: Using custom startup scripts with rhgb In-Reply-To: <95da2d29050118052452d36455@mail.gmail.com> References: <95da2d29050118052452d36455@mail.gmail.com> Message-ID: <20050118141855.GG8569@redhat.com> On Tue, Jan 18, 2005 at 02:24:08PM +0100, Gijs Hollestelle wrote: > Hi, > > At our university we have a script that runs at boot time, which > brings the system's packages up to date with a central server and does > some other configuration stuff (compare it to running yum update at > boot time). This script can take up to 5 minutes to complete but > includes progress meters so that the user can see what is happening, > this works nicely in the details pane of rhgb and when using text > mode. > > This situation causes two problems under rhgb: > > 1) There appears to be no way of setting the caption (where it > normally says things like Starting Networking) for the text box field, > other than adding the string to the main.c file in rhgb. I would like > to be able to set a caption like 'Checking for updated packages' or > something alike. > > 2) If there is no rhgb ping command for 35 seconds rhgb swithces back > to terminal 1 (which does not show te progress, that is shown > correctly in the details pane, but displays only the start of the boot > process with two empty lines between every message). Is there a way to > disable this time-out (temporarily) other than hacking it away in the > main.c file? > > If there is currently no way of doing these 2 without changing the C > code, This requires changes to the C code > would it be possible to add commands to rhgb-client to support > these? as I could imagine they would be useful to others as well. This opens a big can of worm. You add strings but they won't be translated, and rhgb code isn't really trivial. Playing with the timeouts is also very error prone. I'm concerned by the maintainance troubles this may turn into. Daniel -- Daniel Veillard | Red Hat Desktop team http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From ssahni at gmail.com Tue Jan 18 14:38:16 2005 From: ssahni at gmail.com (Simarjeet Sahni) Date: Tue, 18 Jan 2005 09:38:16 -0500 Subject: Proposal: swap epic for irssi In-Reply-To: <1106022929.6105.106.camel@localhost.localdomain> References: <1106022929.6105.106.camel@localhost.localdomain> Message-ID: <45b47df3050118063868a9946@mail.gmail.com> I would prefer irssi over epic, having made the switch a while ago, its been stable and very intuitive. On Tue, 18 Jan 2005 12:35:29 +0800, Colin Charles wrote: > Hi, > > For FC-4, what would folk think about removing epic and replacing it > with irssi in Core? > > irssi currently sits in Extras, and we could very likely just move epic > to Extras after the swap. > > Thoughts? > -- > Colin Charles, byte at aeon.com.my > http://www.bytebot.net/ > "First they ignore you, then they laugh at you, then they fight you, > then you win." -- Mohandas Gandhi > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Regards, Simarjeet Sahni From mattdm at mattdm.org Tue Jan 18 15:10:19 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 18 Jan 2005 10:10:19 -0500 Subject: Using custom startup scripts with rhgb In-Reply-To: <20050118141855.GG8569@redhat.com> References: <95da2d29050118052452d36455@mail.gmail.com> <20050118141855.GG8569@redhat.com> Message-ID: <20050118151019.GA8219@jadzia.bu.edu> On Tue, Jan 18, 2005 at 09:18:55AM -0500, Daniel Veillard wrote: > This opens a big can of worm. You add strings but they won't be translated, > and rhgb code isn't really trivial. > Playing with the timeouts is also very error prone. > I'm concerned by the maintainance troubles this may turn into. In other words, the best solution for Gijs is probably: disable rhgb for your systems. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From buildsys at redhat.com Tue Jan 18 15:15:21 2005 From: buildsys at redhat.com (Build System) Date: Tue, 18 Jan 2005 10:15:21 -0500 Subject: rawhide report: 20041225 changes Message-ID: <200501181515.j0IFFLw27956@porkchop.devel.redhat.com> From ich at Frank-Schmitt.net Tue Jan 18 15:31:42 2005 From: ich at Frank-Schmitt.net (Frank Schmitt) Date: Tue, 18 Jan 2005 16:31:42 +0100 Subject: Proposal: swap epic for irssi References: <1106022929.6105.106.camel@localhost.localdomain> <45b47df3050118063868a9946@mail.gmail.com> Message-ID: Simarjeet Sahni writes: > I would prefer irssi over epic, having made the switch a while ago, > its been stable and very intuitive. Yes, I don't think there's an other console IRC client which beats irssi. -- Did you ever realize how much text fits in eighty columns? If you now consider that a signature usually consists of up to four lines, this gives you enough space to spread a tremendous amount of information with your messages. So seize this opportunity and don't waste your signature with bullshit nobody will read. From nbargnesi at gmail.com Tue Jan 18 15:42:25 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Tue, 18 Jan 2005 10:42:25 -0500 Subject: Using custom startup scripts with rhgb In-Reply-To: <20050118151019.GA8219@jadzia.bu.edu> References: <95da2d29050118052452d36455@mail.gmail.com> <20050118141855.GG8569@redhat.com> <20050118151019.GA8219@jadzia.bu.edu> Message-ID: <3077b8a005011807423d8b442e@mail.gmail.com> On Tue, 18 Jan 2005 10:10:19 -0500, Matthew Miller wrote: > On Tue, Jan 18, 2005 at 09:18:55AM -0500, Daniel Veillard wrote: > > This opens a big can of worm. You add strings but they won't be translated, > > and rhgb code isn't really trivial. > > Playing with the timeouts is also very error prone. > > I'm concerned by the maintainance troubles this may turn into. > > In other words, the best solution for Gijs is probably: disable rhgb for > your systems. I would suggest disabling it too. A better idea would be to have that stuff executing in a cron job during down time. Remembering my University years, I would not have wanted to wait for my workstation to retrieve updates. > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From gauret at free.fr Tue Jan 18 15:47:48 2005 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 18 Jan 2005 16:47:48 +0100 Subject: Using custom startup scripts with rhgb References: <95da2d29050118052452d36455@mail.gmail.com> <20050118141855.GG8569@redhat.com> <20050118151019.GA8219@jadzia.bu.edu> <3077b8a005011807423d8b442e@mail.gmail.com> Message-ID: > I would suggest disabling it too. A better idea would be to have that > stuff executing in a cron job during down time. Remembering my > University years, I would not have wanted to wait for my workstation > to retrieve updates. Maybe something like anacron would be a good candidate... Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Make everything as simple as possible, but not simpler." -- Albert Einstein From mattdm at mattdm.org Tue Jan 18 16:04:04 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 18 Jan 2005 11:04:04 -0500 Subject: Using custom startup scripts with rhgb In-Reply-To: <3077b8a005011807423d8b442e@mail.gmail.com> References: <95da2d29050118052452d36455@mail.gmail.com> <20050118141855.GG8569@redhat.com> <20050118151019.GA8219@jadzia.bu.edu> <3077b8a005011807423d8b442e@mail.gmail.com> Message-ID: <20050118160404.GA10644@jadzia.bu.edu> On Tue, Jan 18, 2005 at 10:42:25AM -0500, Nick Bargnesi wrote: > I would suggest disabling it too. A better idea would be to have that > stuff executing in a cron job during down time. Remembering my > University years, I would not have wanted to wait for my workstation > to retrieve updates. Yeah, but you want the system to come up "clean" at first boot.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From g.hollestelle at gmail.com Tue Jan 18 16:07:45 2005 From: g.hollestelle at gmail.com (Gijs Hollestelle) Date: Tue, 18 Jan 2005 17:07:45 +0100 Subject: Using custom startup scripts with rhgb In-Reply-To: <3077b8a005011807423d8b442e@mail.gmail.com> References: <95da2d29050118052452d36455@mail.gmail.com> <20050118141855.GG8569@redhat.com> <20050118151019.GA8219@jadzia.bu.edu> <3077b8a005011807423d8b442e@mail.gmail.com> Message-ID: <95da2d290501180807298324de@mail.gmail.com> On Tue, 18 Jan 2005 10:42:25 -0500, Nick Bargnesi wrote: > I would suggest disabling it too. A better idea would be to have that > stuff executing in a cron job during down time. Remembering my > University years, I would not have wanted to wait for my workstation > to retrieve updates. Thanks for the tips, but this is unfortunatly not possible to do from cron because some of the updates require a reboot to become active (but all of this is beyond the scope of this list). The underlying problem I am trying to address here is the fact that rhgb has a lot of settings hardcoded into the main.c file, I think it would be a good idea if the string descriptions of services and various time-out settings could for example be set using configuration files instead of requiring a recompile. Kind regards, Gijs PS I'm using a modified rhgb rpm now, that I have patched to include the description of my service and that does not switch back to vt 1 after 35 seconds of no pinging. From dwmw2 at infradead.org Tue Jan 18 16:08:40 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 18 Jan 2005 16:08:40 +0000 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105962291.26551.335.camel@hades.cambridge.redhat.com> Message-ID: <1106064520.26551.432.camel@hades.cambridge.redhat.com> On Mon, 2005-01-17 at 17:18 +0530, Rahul Sundaram wrote: > > If you apply the patches I sent you a year or two ago we can have > > bluetooth networking support working fairly much out of the box > too... > > > > it might be useful to provide links just in case this has been totally > forgotten Two patches -- first we split the end of ifup/ifdown into separate ifup- eth/ifup-eth scripts, then we add the if{down,up}-bnep scripts which use that for Bluetooth networking support. We can move some other stuff out of the generic scripts now too -- like the bridge support. That's left as an exercise for the reader. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: initscripts-bnep.patch Type: text/x-patch Size: 1882 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: initscripts-separate-ifupdown-eth.patch Type: text/x-patch Size: 31898 bytes Desc: not available URL: From mattdm at mattdm.org Tue Jan 18 16:12:30 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 18 Jan 2005 11:12:30 -0500 Subject: Using custom startup scripts with rhgb In-Reply-To: <3077b8a0050118080775806626@mail.gmail.com> References: <95da2d29050118052452d36455@mail.gmail.com> <20050118141855.GG8569@redhat.com> <20050118151019.GA8219@jadzia.bu.edu> <3077b8a005011807423d8b442e@mail.gmail.com> <20050118160404.GA10644@jadzia.bu.edu> <3077b8a0050118080775806626@mail.gmail.com> Message-ID: <20050118161230.GA11107@jadzia.bu.edu> On Tue, Jan 18, 2005 at 11:07:29AM -0500, Nick Bargnesi wrote: > > > I would suggest disabling it too. A better idea would be to have that > > > stuff executing in a cron job during down time. Remembering my > > > University years, I would not have wanted to wait for my workstation > > > to retrieve updates. > > Yeah, but you want the system to come up "clean" at first boot.... > How do you mean clean? I've never needed to reboot after package > updates. He could always run the job at a particular time with cron, > or with anacron, or atd, or whatever; and force a reboot afterwards. Not that. I mean that if a system has been down for a while, you don't want to wait N hours for security updates to be applied. You want them before system services even start, so there's no window of vulnerability. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nbargnesi at gmail.com Tue Jan 18 16:19:20 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Tue, 18 Jan 2005 11:19:20 -0500 Subject: Using custom startup scripts with rhgb In-Reply-To: <20050118161230.GA11107@jadzia.bu.edu> References: <95da2d29050118052452d36455@mail.gmail.com> <20050118141855.GG8569@redhat.com> <20050118151019.GA8219@jadzia.bu.edu> <3077b8a005011807423d8b442e@mail.gmail.com> <20050118160404.GA10644@jadzia.bu.edu> <3077b8a0050118080775806626@mail.gmail.com> <20050118161230.GA11107@jadzia.bu.edu> Message-ID: <3077b8a00501180819743846fe@mail.gmail.com> On Tue, 18 Jan 2005 11:12:30 -0500, Matthew Miller wrote: > On Tue, Jan 18, 2005 at 11:07:29AM -0500, Nick Bargnesi wrote: > > > > I would suggest disabling it too. A better idea would be to have that > > > > stuff executing in a cron job during down time. Remembering my > > > > University years, I would not have wanted to wait for my workstation > > > > to retrieve updates. > > > Yeah, but you want the system to come up "clean" at first boot.... > > How do you mean clean? I've never needed to reboot after package > > updates. He could always run the job at a particular time with cron, > > or with anacron, or atd, or whatever; and force a reboot afterwards. > > Not that. I mean that if a system has been down for a while, you don't want > to wait N hours for security updates to be applied. You want them before > system services even start, so there's no window of vulnerability. No decent sysadmin should have workstations that need to be secure and up to date powered off or down. This is getting to off topic though. > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From mattdm at mattdm.org Tue Jan 18 16:29:20 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 18 Jan 2005 11:29:20 -0500 Subject: Using custom startup scripts with rhgb In-Reply-To: <3077b8a00501180819743846fe@mail.gmail.com> References: <95da2d29050118052452d36455@mail.gmail.com> <20050118141855.GG8569@redhat.com> <20050118151019.GA8219@jadzia.bu.edu> <3077b8a005011807423d8b442e@mail.gmail.com> <20050118160404.GA10644@jadzia.bu.edu> <3077b8a0050118080775806626@mail.gmail.com> <20050118161230.GA11107@jadzia.bu.edu> <3077b8a00501180819743846fe@mail.gmail.com> Message-ID: <20050118162920.GA11938@jadzia.bu.edu> On Tue, Jan 18, 2005 at 11:19:20AM -0500, Nick Bargnesi wrote: > No decent sysadmin should have workstations that need to be secure and > up to date powered off or down. This is getting to off topic though. It is typical to power off lab and desktop systems over breaks in universities. Decent sysadmin or no, it's nice for those systems to be secure when they come back up. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From kyrre at solution-forge.net Tue Jan 18 18:16:17 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 18 Jan 2005 19:16:17 +0100 Subject: Using custom startup scripts with rhgb In-Reply-To: <3077b8a005011807423d8b442e@mail.gmail.com> References: <95da2d29050118052452d36455@mail.gmail.com> <20050118141855.GG8569@redhat.com> <20050118151019.GA8219@jadzia.bu.edu> <3077b8a005011807423d8b442e@mail.gmail.com> Message-ID: <1106072177.2784.2.camel@localhost.localdomain> tir, 18.01.2005 kl. 16.42 skrev Nick Bargnesi: > On Tue, 18 Jan 2005 10:10:19 -0500, Matthew Miller wrote: > > On Tue, Jan 18, 2005 at 09:18:55AM -0500, Daniel Veillard wrote: > > > This opens a big can of worm. You add strings but they won't be translated, > > > and rhgb code isn't really trivial. > > > Playing with the timeouts is also very error prone. > > > I'm concerned by the maintainance troubles this may turn into. > > > > In other words, the best solution for Gijs is probably: disable rhgb for > > your systems. > > I would suggest disabling it too. A better idea would be to have that > stuff executing in a cron job during down time. Remembering my > University years, I would not have wanted to wait for my workstation > to retrieve updates. > Or you could use something as this: http://solution-forge.net/source/unprotected/admin-script/admin-script-final.tar.gz From mbneto at gmail.com Tue Jan 18 21:41:45 2005 From: mbneto at gmail.com (mbneto) Date: Tue, 18 Jan 2005 17:41:45 -0400 Subject: Problem with mirrors (rawhide) ? Message-ID: <5cf776b80501181341449ad034@mail.gmail.com> Hi, I am trying to update my machine but keep geting http://ftp.dulug.duke.edu/pub/fedora/linux/core/development/i386/repodata/primary.xml.gz: [Errno -1] Metadatafile does not match checksum Trying other mirror. primary.xml.gz 100% |=========================| 1.0 MB 00:01 http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. primary.xml.gz 100% |=========================| 1.0 MB 00:00 http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/development/i386/repodata/primary.xml.gz:[Errno -1] Metadata file does not match checksum Trying other mirror. primary.xml.gz 100% |=========================| 1.0 MB 00:00 http://sunsite.mff.cuni.cz/pub/fedora/development/i386/repodata/primary.xml.gz: [Errno -1] Metadata file doesnot match checksum Trying other mirror. primary.xml.gz 100% |=========================| 1.0 MB 00:00 http://mirrors.kernel.org/fedora/core/development/i386/repodata/primary.xml.gz: [Errno -1] Metadata file doesnot match checksum Trying other mirror. primary.xml.gz 100% |=========================| 1.0 MB 00:00 http://mirror.hiwaay.net/redhat/fedora/linux/core/development/i386/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. Error: failure: repodata/primary.xml.gz from development: [Errno 256] No more mirrors to try. Any ideas ? From fedora-devel-list at cygnusx-1.org Wed Jan 19 04:22:47 2005 From: fedora-devel-list at cygnusx-1.org (Nathan G. Grennan) Date: Tue, 18 Jan 2005 20:22:47 -0800 Subject: Building rpms on AMD64 In-Reply-To: <1105964544.5470.24.camel@localhost.localdomain> References: <3077b8a0050114090023076a3f@mail.gmail.com> <41E80325.6070303@research.att.com> <1105724504.3944.36.camel@cutter> <1105914022.5205.26.camel@proton.cygnusx-1.org> <1105964544.5470.24.camel@localhost.localdomain> Message-ID: <1106108567.8201.5.camel@proton.cygnusx-1.org> > AFAIK, there's no way to build i386 software of any complexity on > outside of an i386 chroot on an AMD64 system, without completely > modifying the package's build system. This is bad, but not surprising. > Note that while .server files may be text, they describe binary > components. Thus, /usr/lib/bonobo lists 32-bit components > and /usr/lib64/bonobo lists 64-bit components. Their placement > in /usr/lib{,64} instead of /usr/share is correct. > This doesn't seem to be true in the case of Galeon. I see nothing in the .server files that is 32bit or 64bit explicit. > Somebody should fix bonobo-activation to do the right thing on 64-bit > systems, but I don't think anybody really cares all that much about > Bonobo anymore. Not care about bonobo anymore, don't plenty of common applications still use it. > Gdk-Pixbuf and GTK immodule problems on biarch systems were fixed for > FC3. > This is a good to hear. From niemeyer at conectiva.com Wed Jan 19 13:34:26 2005 From: niemeyer at conectiva.com (Gustavo Niemeyer) Date: Wed, 19 Jan 2005 11:34:26 -0200 Subject: Fedora Core 4 In-Reply-To: <1105806480.28025.10.camel@one.myworld> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> Message-ID: <20050119133426.GA8334@burma.localdomain> > Have you considerer smart : > http://www.smartpm.org/ Good choice! ;-) > It is Interesting. But sometimes it ignore %{epoch} (for good or bad I'm unaware about such problems. Please, let me know if you find any cases I might study. > reason it's not the point), does not support group, the gui interface is > a little confusing. It supports group in several places. If you have suggestions about how you'd like to see them handled, or GUI improvements, contact me please. > Smart is quite fast (python), have gnome, kde, text interface. It's in > beta/testing stage. No kde interfaces yet.. but it's already being thought about by me and others. It has also a shell interface, btw (which might certainly fall under your "text" category). Thanks for suggesting it, -- Gustavo Niemeyer http://niemeyer.net From buildsys at redhat.com Wed Jan 19 13:42:53 2005 From: buildsys at redhat.com (Build System) Date: Wed, 19 Jan 2005 08:42:53 -0500 Subject: rawhide report: 20050119 changes Message-ID: <200501191342.j0JDgri30951@porkchop.devel.redhat.com> New package linux-atm Tools to support ATM networking under Linux. Updated Packages: createrepo-0.4.2-2 ------------------ * Tue Jan 18 2005 Jeremy Katz - 0.4.2-2 - add the manpage * Tue Jan 18 2005 Jeremy Katz - 0.4.2-1 - 0.4.2 foomatic-3.0.2-13 ----------------- * Tue Jan 18 2005 Tim Waugh 3.0.2-13 - Updated db to 20050118. * Mon Jan 10 2005 Tim Waugh - Added IEEE 1284 information for Epson Stylus Photo R200 (bug #144631). * Tue Jan 04 2005 Tim Waugh - Added IEEE 1284 information for Okidata Okipage 6ex (bug #143964). - Added IEEE 1284 information for Epson Stylus Photo R300 (bug #143939). gaim-1:1.1.1-3 -------------- * Tue Jan 18 2005 Chip Turner 1:1.1.1-3 - rebuild for new perl gcc-3.4.3-15 ------------ * Tue Jan 18 2005 Jakub Jelinek 3.4.3-15 - add gcc-gnat and libgnat on ppc, x86_64 and ia64 again - fix Ada bootstrap problems on 64-bit architectures (PR ada/13470) - run ACATS tests under expect, so that if they hang, they'll be timed out gcc4-4.0.0-0.20 --------------- * Tue Jan 18 2005 Jakub Jelinek 4.0.0-0.20 - update from trunk - fix PR c++/19406 jpackage-utils-0:1.6.2-1jpp_2rh ------------------------------- * Tue Jan 18 2005 Thomas Fitzsimmons - 0:1.6.2-1jpp_2rh - Import jpackage-utils 0:1.6.0-2jpp from jpackage.org. mkinitrd-4.2.0.1-1 ------------------ * Tue Jan 18 2005 Jeremy Katz - 4.2.0.1-1 - fix grubby tests to run on systems with /boot = / * Tue Jan 18 2005 Jeremy Katz - 4.2.0-1 - grubby: add multiboot support for xen0 - new-kernel-pkg: likewise mod_perl-1.99_17-2 ------------------ * Tue Jan 18 2005 Chip Turner 1.99_17-2 - rebuild for new perl postgresql-8.0.0-1 ------------------ * Wed Jan 19 2005 Tom Lane 8.0.0-1 - Update to PostgreSQL 8.0.0, PyGreSQL 3.6.1, pgtcl 1.5.2, and jdbc driver build 309. - Extensive cleanout of obsolete cruft in patch set. - Regression tests are run during RPM build (NOTE: cannot build as root when this is enabled). - Postmaster stderr goes someplace useful, not /dev/null (bz#76503, #103767) - Make init script return a useful exit status (bz#80782) - Move docs' tutorial directory to %{_libdir}/pgsql/tutorial, since it includes .so files that surely do not belong under /usr/share. - Remove useless .sgml files from docs RPM (bz#134450) - Put regression tests under /usr/lib64 on 64-bit archs, since .so files are not architecture-independent. readline-5.0-2 -------------- * Tue Jan 18 2005 Tim Waugh 5.0-2 - Fix line-wrapping (bug #145329). - Apply "read -e" patch from bash package. rp-pppoe-3.5-25 --------------- * Wed Jan 19 2005 David Woodhouse 3.5-25 - Kill br2684ctl after ifdown if we started it * Wed Jan 19 2005 David Woodhouse 3.5-24 - Add support for RFC2684 Ethernet-over-ATM (for PPPoE-over-ATM) rpmdb-fedora-1:4-0.20050119 --------------------------- vim-1:6.3.058-2 --------------- * Tue Jan 18 2005 Chip Turner 1:058-2 - rebuild for new perl * Tue Jan 18 2005 Karsten Hopp 6.3.058-1 - Patchlevel 58 - rebuild with new perl - remove all rpm backup files xchat-1:2.4.1-3 --------------- * Tue Jan 18 2005 Chip Turner 1:2.4.1-3 - rebuild for new perl From niemeyer at conectiva.com Wed Jan 19 13:43:05 2005 From: niemeyer at conectiva.com (Gustavo Niemeyer) Date: Wed, 19 Jan 2005 11:43:05 -0200 Subject: Fedora Core 4 In-Reply-To: <1105807213.13320.1.camel@cutter> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> Message-ID: <20050119134305.GB8334@burma.localdomain> > At this point smart doesn't have multilib support Yes, it does. Anything not working is a bug which I'll fix, once reported and consensus on correct behavior is obtained. > (at least from reading of the code) You've read the code, so you know it's easy to implement almost anything, and that there are many other interesting aspects on the software. > so I'm not sure how useful that will be for a distro > offering (soon, I hope) two multilib archs: x86_64 and ppc64. Tell me what kind of support you consider necessary for a "distro offering" and I'll implement it. You know I've been working hard to make everything work perfectly, and that even though it's not yet completely polished due to its incipient life, the project is in a quite advanced state, and have many advantages over APT-RPM and others. -- Gustavo Niemeyer http://niemeyer.net From niemeyer at conectiva.com Wed Jan 19 13:45:59 2005 From: niemeyer at conectiva.com (Gustavo Niemeyer) Date: Wed, 19 Jan 2005 11:45:59 -0200 Subject: Fedora Core 4 In-Reply-To: <1105811660.32328.0.camel@opus.phy.duke.edu> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> Message-ID: <20050119134559.GC8334@burma.localdomain> > > Multilib pkg choice is a work of hours, not more. > > Not from what I've seen. Especially when it comes to automatic package > selection. Can you please tell me what you've seen? I'm really curious. > But hey, more power to you. Give me the expected behavior (consensus, please) and I'll implement. -- Gustavo Niemeyer http://niemeyer.net From skvidal at phy.duke.edu Wed Jan 19 13:57:18 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 19 Jan 2005 08:57:18 -0500 Subject: Fedora Core 4 In-Reply-To: <20050119134559.GC8334@burma.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> <20050119134559.GC8334@burma.localdomain> Message-ID: <1106143038.13831.23.camel@cutter> On Wed, 2005-01-19 at 11:45 -0200, Gustavo Niemeyer wrote: > > > Multilib pkg choice is a work of hours, not more. > > > > Not from what I've seen. Especially when it comes to automatic package > > selection. > > Can you please tell me what you've seen? I'm really curious. I was referring to jeff's claim that it only takes a couple of hours to get multilib right. > > But hey, more power to you. > > Give me the expected behavior (consensus, please) and I'll implement. consensus. haha. that's funny. -sv From niemeyer at conectiva.com Wed Jan 19 14:00:35 2005 From: niemeyer at conectiva.com (Gustavo Niemeyer) Date: Wed, 19 Jan 2005 12:00:35 -0200 Subject: Fedora Core 4 In-Reply-To: <41E9E60D.9080706@togami.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E9E60D.9080706@togami.com> Message-ID: <20050119140035.GD8334@burma.localdomain> > It belongs in at least in Extras with ExclusiveArch: i386, ppc. If > upstream adds multilib capability later, then the arch support can be > expanded. Mutlilib is already supported *right now* on Smart. What is missing is testing and fixing bug. There's also another major issue, which is implementing the expected behavior. Personally, I have no contact with multilib systems, and so I'm unable to tell what's the expected behavior on such systems. I've asked many different people what they expect to happen on their multilib system, but got no reasonable answer so far. Anyway, will be glad to implement ASAP whatever is decided to be the correct way to handle multilib/coloring/biarch/however it's named. -- Gustavo Niemeyer http://niemeyer.net From rahulsundaram at gmail.com Wed Jan 19 14:01:02 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Wed, 19 Jan 2005 19:31:02 +0530 Subject: Fedora Core 4 In-Reply-To: <1106143038.13831.23.camel@cutter> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> <20050119134559.GC8334@burma.localdomain> <1106143038.13831.23.camel@cutter> Message-ID: Hi > > > > Give me the expected behavior (consensus, please) and I'll implement. > > consensus. haha. that's funny. It might not be what you intended but it looks like you are making fun of someone who is eager to fix and improve his software. if there are problems in having consensus ,explaining that or directing him to discussions taken place already might be a better thing to do -- Regards, Rahul Sundaram From niemeyer at conectiva.com Wed Jan 19 14:02:01 2005 From: niemeyer at conectiva.com (Gustavo Niemeyer) Date: Wed, 19 Jan 2005 12:02:01 -0200 Subject: Fedora Core 4 In-Reply-To: <1106143038.13831.23.camel@cutter> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> <20050119134559.GC8334@burma.localdomain> <1106143038.13831.23.camel@cutter> Message-ID: <20050119140201.GE8334@burma.localdomain> > > > > Multilib pkg choice is a work of hours, not more. > > > > > > Not from what I've seen. Especially when it comes to automatic package > > > selection. > > > > Can you please tell me what you've seen? I'm really curious. > > I was referring to jeff's claim that it only takes a couple of hours to > get multilib right. If he was talking about Smart, it's really a matter of hours. > > > But hey, more power to you. > > > > Give me the expected behavior (consensus, please) and I'll implement. > > consensus. haha. that's funny. Really? -- Gustavo Niemeyer http://niemeyer.net From skvidal at phy.duke.edu Wed Jan 19 14:05:07 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 19 Jan 2005 09:05:07 -0500 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <41E94E25.7010005@nc.rr.com> <1105811660.32328.0.camel@opus.phy.duke.edu> <20050119134559.GC8334@burma.localdomain> <1106143038.13831.23.camel@cutter> Message-ID: <1106143507.13831.25.camel@cutter> On Wed, 2005-01-19 at 19:31 +0530, Rahul Sundaram wrote: > Hi > > > > > > Give me the expected behavior (consensus, please) and I'll implement. > > > > consensus. haha. that's funny. > > It might not be what you intended but it looks like you are making fun > of someone who is eager to fix and improve his software. if there are > problems in having consensus ,explaining that or directing him to > discussions taken place already might be a better thing to do > No, i'm not making fun of him - but I am finding it funny the suggestion that you can come to consensus of behavior of pkg managers. -sv From cturner at redhat.com Wed Jan 19 14:16:46 2005 From: cturner at redhat.com (Chip Turner) Date: Wed, 19 Jan 2005 09:16:46 -0500 Subject: perl INSTALLDIRS=vendor In-Reply-To: <20050118015227.GA1496663@hiwaay.net> (Chris Adams's message of "Mon, 17 Jan 2005 19:52:27 -0600") References: <41D95031.2060903@balclutha.org> <1105120812.5058.37.camel@bobcat.mine.nu> <20050118015227.GA1496663@hiwaay.net> Message-ID: Chris Adams writes: > Once upon a time, Chip Turner said: >> Ville Skytt?? writes: >> > The modules come from a vendor -> they should go into vendor install >> > dirs. Site install dirs are for local site installs so that admins can >> > override system installed stuff a la "perl -MCPAN -e install Foo-Bar" >> > and traditional tarball install. (Moving site_perl in /usr/local/... >> > would make this clearer FHS-wise.) >> >> I like that idea. A lot. I'd not thought about it til now, but that >> makes a tremendous amount of sense. It would also address the manpage >> issue, I think. It would break backwards compatibility, though, with >> older RPMs (unless we still looked in the /usr/lib/.../site_perl/ >> dirs, but I'm inclined not to). > > Hmm, you might as well change "vendor_perl" to "rpm_perl" then. I don't > want RPM touching /usr/local (that's for the few odds and ends I install > manually and local or per-system scripts), but I install perl modules > from RPMs all the time. "vendor" to me means Red Hat or Fedora, so I > wouldn't make my perl module RPMs install into the "vendor" directory. Well, perl itself calls it vendor_perl. Various things like 'perl -V:vendorlib' etc make me hesitant to diverge from upstream naming. vendor_perl is where Fedora's perl modules end up landing; site_perl is where your site's perl modules. RPM doesn't really have anything to do with it. There's no law against rpm managing files living in /usr/local, but that's one of the few places that is even viable for things like man pages from third party apps that might conflict with the ones living in /usr. Chip -- Chip Turner cturner at redhat.com Red Hat, Inc. From feliciano.matias at free.fr Wed Jan 19 14:19:00 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Wed, 19 Jan 2005 15:19:00 +0100 Subject: Fedora Core 4 In-Reply-To: <20050119133426.GA8334@burma.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> Message-ID: <1106144340.15549.10.camel@one.myworld> Le mercredi 19 janvier 2005 ? 11:34 -0200, Gustavo Niemeyer a ?crit : > > Have you considerer smart : > > http://www.smartpm.org/ > > Good choice! ;-) > > > It is Interesting. But sometimes it ignore %{epoch} (for good or bad > > I'm unaware about such problems. Please, let me know if you find any > cases I might study. README : http://linux-br.conectiva.com.br/~niemeyer/smart/doc/README.html#case-1- apt > > > reason it's not the point), does not support group, the gui interface is > > a little confusing. > > It supports group in several places. If you have suggestions about how > you'd like to see them handled, or GUI improvements, contact me please. Rpm group : # rpm -q --queryformat "%{GROUP}\n" -a | sort | uniq Applications/Archivage Applications/Archiving Applications/Bases de donn?es Applications/Communications ... Group (/usr/share/comps/i386/comps.xml) : # yum grouplist Installed Groups: Administration Tools Compatibility Arch Support DNS Name Server Editors GNOME Desktop Environment Graphical Internet ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fedora-devel at camperquake.de Wed Jan 19 14:24:25 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Wed, 19 Jan 2005 15:24:25 +0100 Subject: Fedora Core 4 In-Reply-To: <1106144340.15549.10.camel@one.myworld> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> Message-ID: <20050119152425.34e064f1@nausicaa.camperquake.de> Hi. F?liciano Matias wrote: > README : > http://linux-br.conectiva.com.br/~niemeyer/smart/doc/README.html#case-1- > apt This is entirely intentional, and I for one consider this a feature. -- "Wozu Mails loeschen wenn man Platten nachschieben kann ?" David Sternheimer, AnimeGer From jspaleta at gmail.com Wed Jan 19 15:06:34 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 19 Jan 2005 10:06:34 -0500 Subject: Fedora Core 4 In-Reply-To: <20050119152425.34e064f1@nausicaa.camperquake.de> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119152425.34e064f1@nausicaa.camperquake.de> Message-ID: <604aa791050119070644bbb0b7@mail.gmail.com> On Wed, 19 Jan 2005 15:24:25 +0100, Ralf Ertzinger wrote: > This is entirely intentional, and I for one consider this a feature. Package downgrades and removals are a very difficult thing to do correctly and are dangerous as an automated concept. With downgrades or removals active, small packaging problems in the packages themselves can lead to very strange behavior and unexpected behavior. So as an advanced user you might find the automated decision making as to what to remove or to downgrade useful a novice user will be confused because they might assume the downgrading is a perfectly natural thing. Lets take the latest wireless-tools updates-released package that showed up as a fc3 updates-release: wireless-tools-28-0.pre4.1.fc3.i386.rpm wireless-tools-28-0.pre4.1 libiw.so.28 wireless-tools-27-0.pre25.3 libiw.so.27 Now... the lastest core NetworkManager and latest core kdenetwork packages both require libiw.so.27 Using smart to update wireless-tools from Core updates-released smart tells me it needs to remove kdenetwork and NetworkManager. This sort of thing is VERY dangerous to expose to a novice user. A novice user can not be trusted to review the 'downgrade' and 'remove' sections of the smart transaction and understand WHY certain packages are in the list. How does a novice user make an informed opinion about whether or not to let smart downgrade or remove packages? This is a stop and think situation... not a point and click okay situation. Building tools accessible to novice users that encourage them to hit a big OK button regardless of the problem is bad. The auto downgrading and auto removing to meet a transaction should absolutely NOT be turned on by default in ANY packaging tool. Sure its a very powerful and very flexible tool for advanced users who have experience working with packages, but for a novice user its going to be a nightmare. This approach is not robust to packaging errors. As a result small packaging errors that make it into the release tree or updates tree are going to have a HUGE detrimental effect of novice users who start trusting smart to make decisions about what should and should not be downgraded or removed. The whole approach to tools contructed downgrades/removals pretty much assumes that packaging errors will not happen. They happen and the tools need to constructed in a way that encourages reporting of packaging problems back to the package maintainers instead of allowing novice users to click their way into a situation where packaging errors result in the removal of packages from a user's system. I'm much more confident in up2date's and yum's approach to a situation like this that a novice user might face. They keel over and die, leaving the user's system as it was. If there were a packaging error in a glibc update or something more critical than wireless-tools... i would imagine that the damage smart could do to a system by allowing users to remove a large set of packages to make the requested transaction work would be spectacular. -jef"is anyone running smart against rawhide... im sure there are more than enough pathelogical packaging error cases in rawhide to chew on"spaleta From jspaleta at gmail.com Wed Jan 19 15:51:23 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 19 Jan 2005 10:51:23 -0500 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <20050119134305.GB8334@burma.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> Message-ID: <604aa79105011907515a656615@mail.gmail.com> Good Morning! I hope you read my contribution to the thread on -devel-list. But if you don't i'd like to point out the specific example of where i think smart's behavior is wrong and to it to frame an argument as to what i think smart could be doing instead of using per-package and per-repo priorities. The example i want to show you is the newest wireless-tools in updates-released: wireless-tools-28-0.pre4.1.fc3.i386.rpm which provides libiw.so.28 the latest NetworkManager and kdenetwork in Core require libiw.so.27 as a result if i try to use smart to update to the latest wireless-tools package in updates-released, smart wants to remove NetworkManager and kdenetwork from my fc3 system. I feel this is incorrect behavior, smart should understand this situation as a reportable packaging error instead of offering to remove those 2 packages to make the transaction work. This is clearly a case of a package bug leading to unrequired package removals.. and I am concerned that a novice user with little experience with rpms won't have enough information to cancel the operation and similar operations if there is a packaging error. My solution to this sort of problem in smart is to move a way from fully exposing per-package and per-repository priorities and to move toward codifying the relationship between channels in a way that codefies how channel interaction policy is being handled by the channel maintainers themselves. The key idea is for channel maintainers to define for themselves how they fit into a multiple channel frame work, and smart can use that information to flag error situations that should not be happening according to channel policy. Let me construct for you a simple hypothetical setup of channels based on Core 3 and show how it could help prevent the wireless-tools packaging problem. Lets start with just the Core channels: Core3os: The channel for fc3 os, this channel explicit states as a matter of policy that it is self-consistent and that it requires no dependances from anwhere else. And conflicts between packages in Core should be considered a reportable bug Core3updates: The channel for core 3 updates-released This channel states as a matter of policy that it is self-consistent and that it updates Core3os, any conflict when packages in Core3os and Core3updates are used together should be considered a reportable bug. Core3testing: The channel for core 3 updates-testing Core3os: From fedora-devel at camperquake.de Wed Jan 19 15:54:49 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Wed, 19 Jan 2005 16:54:49 +0100 Subject: Fedora Core 4 In-Reply-To: <604aa791050119070644bbb0b7@mail.gmail.com>; from jspaleta@gmail.com on Wed, Jan 19, 2005 at 10:06:34AM -0500 References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119152425.34e064f1@nausicaa.camperquake.de> <604aa791050119070644bbb0b7@mail.gmail.com> Message-ID: <20050119165449.A15870@ryoko.camperquake.de> On Wed, Jan 19, 2005 at 10:06:34AM -0500, Jeff Spaleta wrote: > Package downgrades and removals are a very difficult thing to do > correctly and are dangerous as an automated concept.o Please note that the example I commented on was an explicit request to install a specific package, not a general update. smart just told the user that it needed to downgrade to fulfil the request, which is true. What the other tools do in the same situation is listed on the same page. > So as an advanced user you might find the automated decision making as > to what to remove or to downgrade useful a novice user will be > confused because they might assume the downgrading is a perfectly > natural thing. Make downgrades an option, defaulting to no? But I think the first thing on a repositories FAQ will be: "In order to avoid problems, set AllowDowngrade to yes in smart". > Using smart to update wireless-tools from Core updates-released > smart tells me it needs to remove kdenetwork and NetworkManager. This Was this during a general 'upgrade' command, or did you tell smart to explicitly upgrade wireless-tools? > -jef"is anyone running smart against rawhide... im sure there are more > than enough pathelogical packaging error cases in rawhide to chew > on"spaleta I am running rawhide with smart. Enabled repos are fc-devel at 0, freshrpms at 0, dag at -5 newrpms at -5, atrpms-stable at -10, atrpms-good at -10, atrpms-bleeding at -20. It's heaven. From jpo at di.uminho.pt Wed Jan 19 15:56:06 2005 From: jpo at di.uminho.pt (=?UTF-8?B?Sm9zw6kgUGVkcm8gT2xpdmVpcmE=?=) Date: Wed, 19 Jan 2005 15:56:06 +0000 Subject: perl INSTALLDIRS=vendor (help and outdated perl modules) In-Reply-To: References: <41D95031.2060903@balclutha.org> <1105120812.5058.37.camel@bobcat.mine.nu> Message-ID: <41EE8316.2010007@di.uminho.pt> Chip, > Ville Skytt? writes: ... >>On Tue, 2005-01-04 at 01:01 +1100, Alan Milligan wrote: ... >>In my experience, a lot of bug reports containing the magic string >>"perl" in bugzilla.redhat.com or here do not tend to draw much >>attention. Hopefully there will be something that the community can do >>about it in future FC. > > That's my fault. I don't get much time to spend on perl as I would > like. Now that CVS is exposed, though, I'm hoping I get more help > from the community :) Count me in! > There are a TON of perl bugs at this point. Many are no longer valid, > but many are. I need to triage them all, but that would likely take > more time than fixing most of the ones worth fixing, I suspect. Here goes a list of outdated perl modules in Rawhide. A good place to start is the perl Time::HiRes core module and the standalone one (more information below). I can also help reviewing some of the bugzilla perl entries, in particular the ones I created. Outdated perl modules Rawhide CPAN ---------------------------------------------------------------------- mod_perl-1.99_17-2.src.rpm mod_perl-2.0.0-RC3.tar.gz (version 1.999020) perl-Archive-Tar-1.08-3.src.rpm Archive-Tar-1.23.tar.gz perl-Bit-Vector-6.3-3.src.rpm Bit-Vector-6.4.tar.gz perl-BSD-Resource-1.23-6.src.rpm BSD-Resource-1.24.tar.gz perl-Date-Calc-5.3-10.src.rpm Date-Calc-5.4.tar.gz perl-DBD-Pg-1.31-6.src.rpm DBD-Pg-1.32.tar.gz perl-DBI-1.40-5.src.rpm DBI-1.46.tar.gz perl-Digest-SHA1-2.07-5.src.rpm Digest-SHA1-2.10.tar.gz perl-File-MMagic-1.21-2.src.rpm File-MMagic-1.22.tar.gz perl-Frontier-RPC-0.06-38.src.rpm Frontier-RPC-0.07b4.tar.gz perl-HTML-Parser-3.35-7.src.rpm HTML-Parser-3.45.tar.gz perl-HTML-Tagset-3.03-30.src.rpm HTML-Tagset-3.04.tar.gz perl-LDAP-0.31-5.src.rpm perl-ldap-0.3202.tar.gz perl-libwww-perl-5.79-6.src.rpm libwww-perl-5.803.tar.gz perl-libxml-perl-0.07-30.src.rpm libxml-perl-0.08.tar.gz perl-TermReadKey-2.20-17.src.rpm TermReadKey-2.21.tar.gz perl-Text-Kakasi-1.05-12.src.rpm Text-Kakasi-2.04.tar.gz perl-Time-HiRes-1.55-3.src.rpm Time-HiRes-1.66.tar.gz perl-URI-1.30-4.src.rpm URI-1.35.tar.gz perl-XML-Twig-3.13-6.src.rpm XML-Twig-3.15.tar.gz Note: The core module Time::HiRes in perl 5.8.[456] is more recent than the one packaged as a standalone module (perl-Time-HiRes 1.55). perl Time::HiRes ----------------------- 5.008003 1.52 5.008004 1.59 5.008005 1.59 5.008006 1.65 Bugzilla (perl component) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136496 Bugzilla (perl-Time-HiRes) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136494 Note2: Archive::Tar now requires IO::Zlib which is already available in Fedora.us/extras repositories Bugzilla (perl-Archive-Tar component) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136498 Perl SRPMS that include .tar.bz2 files ---------------------------------------------------------------------- QA packagers can't validate these tarballs (CPAN only has .tar.gz files and some .zip files): WARN: perl-libxml-perl-0.07-30.src.rpm has a BZ2 source file! WARN: perl-XML-Encoding-1.01-26.src.rpm has a BZ2 source file! WARN: perl-XML-Grove-0.46alpha-27.src.rpm has a BZ2 source file! Best regards, jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Wed Jan 19 15:58:12 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 19 Jan 2005 10:58:12 -0500 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <604aa79105011907515a656615@mail.gmail.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> Message-ID: <604aa791050119075863b7c9da@mail.gmail.com> On Wed, 19 Jan 2005 10:51:23 -0500, Jeff Spaleta wrote: Crap... i hate it when i accidently hit send instead of save. Sorry... consider the last message an unfinished draft... I'd be amazed if its even interpretable as english. -jef"i swear there's a good idea buried in that scribble somewhere"spaleta From jspaleta at gmail.com Wed Jan 19 16:00:36 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 19 Jan 2005 11:00:36 -0500 Subject: Fedora Core 4 In-Reply-To: <20050119165449.A15870@ryoko.camperquake.de> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119152425.34e064f1@nausicaa.camperquake.de> <604aa791050119070644bbb0b7@mail.gmail.com> <20050119165449.A15870@ryoko.camperquake.de> Message-ID: <604aa791050119080054ff3ca4@mail.gmail.com> On Wed, 19 Jan 2005 16:54:49 +0100, Ralf Ertzinger wrote: > I am running rawhide with smart. Enabled repos are fc-devel at 0, freshrpms at 0, > dag at -5 newrpms at -5, atrpms-stable at -10, atrpms-good at -10, atrpms-bleeding at -20. > > It's heaven. Maybe to you... but i have sincere doubts that using smart is helping to identify real packaging problems that exist. Has smart helped you identify and report any rawhide packaging bugs? -jef From technojoecoolusa at charter.net Wed Jan 19 16:08:22 2005 From: technojoecoolusa at charter.net (Joseph D. Wagner) Date: Wed, 19 Jan 2005 10:08:22 -0600 Subject: RFC: Optimizing for 386 Message-ID: <3khdfd$heo20h@mxip04a.cluster1.charter.net> I can count the total number of people in the world who still use a 386 on the fingers of both of my hands. Why are we still catering to this small group of people? With the exception of the kernel and glibc, all RPM's are optimized for 386 architecture. This is a waste of system resources. Study after study shows that you can achieve a 10% - 40% performance improvement my optimizing code for a specific architecture. Windows XP may only be optimized for a Pentium, but by golly, at least the whole thing is optimized, not just the kernel and the C library. Just look at X. Is anyone seriously trying to get X to run on a 386? I can understand compiling the text-based programs, like bash, for 386. You can run a text-only box on a 386 just fine. Why do that for X? Why do that for GNOME, KDE, or any graphical program for that matter? I know that I can recompile of these program from the source code to achieve those optimizations. However, why should everyone who wants to optimize their systems have to go through that, just so a handful of people with 386 machines can run X out-of-the-box? Then, we have recompile all over again with the next RPM release. Why can't the few people who have a 386 be made to recompile X from sources to get it to run on there machines, so the rest of us can enjoy the performance boost from running optimized binaries? I think we seriously need to rethink the distribution strategy. At the very least, all graphical programs should be optimized for i686. Joseph D. Wagner From fedora-devel at camperquake.de Wed Jan 19 16:09:11 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Wed, 19 Jan 2005 17:09:11 +0100 Subject: Fedora Core 4 In-Reply-To: <604aa791050119080054ff3ca4@mail.gmail.com>; from jspaleta@gmail.com on Wed, Jan 19, 2005 at 11:00:36AM -0500 References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119152425.34e064f1@nausicaa.camperquake.de> <604aa791050119070644bbb0b7@mail.gmail.com> <20050119165449.A15870@ryoko.camperquake.de> <604aa791050119080054ff3ca4@mail.gmail.com> Message-ID: <20050119170911.B15870@ryoko.camperquake.de> On Wed, Jan 19, 2005 at 11:00:36AM -0500, Jeff Spaleta wrote: > Has smart helped you identify and report any rawhide packaging bugs? It has helped me to use packages from a variety of repositories while keeping said repositories from stepping on each others feet or overwriting packages provided by FC. This is what I consider to be it's job, and it is doing great at it. No other package manager has come close to that. And just for the record: I read what it is trying to do before committing, and I know that downgrading or suspicious removal usually means that there is a bug somewhere. From mattdm at mattdm.org Wed Jan 19 16:09:44 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 19 Jan 2005 11:09:44 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <3khdfd$heo20h@mxip04a.cluster1.charter.net> References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> Message-ID: <20050119160944.GA25782@jadzia.bu.edu> On Wed, Jan 19, 2005 at 10:08:22AM -0600, Joseph D. Wagner wrote: > With the exception of the kernel and glibc, all RPM's are optimized for > 386 architecture. This is a waste of system resources. Study after study Read the archives -- this comes up a lot. They're optimized for pentium4, but use the i386 instruction set. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora-devel at camperquake.de Wed Jan 19 16:10:47 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Wed, 19 Jan 2005 17:10:47 +0100 Subject: RFC: Optimizing for 386 In-Reply-To: <3khdfd$heo20h@mxip04a.cluster1.charter.net>; from technojoecoolusa@charter.net on Wed, Jan 19, 2005 at 10:08:22AM -0600 References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> Message-ID: <20050119171047.C15870@ryoko.camperquake.de> On Wed, Jan 19, 2005 at 10:08:22AM -0600, Joseph D. Wagner wrote: > With the exception of the kernel and glibc, all RPM's are optimized > for 386 architecture. This is not true. The default optimization is for Pentium 4 class processors. From rahulsundaram at gmail.com Wed Jan 19 16:17:43 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Wed, 19 Jan 2005 21:47:43 +0530 Subject: RFC: Optimizing for 386 In-Reply-To: <3khdfd$heo20h@mxip04a.cluster1.charter.net> References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> Message-ID: On Wed, 19 Jan 2005 10:08:22 -0600, Joseph D. Wagner wrote: > I can count the total number of people in the world who still use a 386 on the fingers of both of my hands. Why are we still catering to this small group of people? You could have spend some time searching through the archives -- Regards, Rahul Sundaram From niemeyer at conectiva.com Wed Jan 19 16:19:39 2005 From: niemeyer at conectiva.com (Gustavo Niemeyer) Date: Wed, 19 Jan 2005 14:19:39 -0200 Subject: Fedora Core 4 In-Reply-To: <1106144340.15549.10.camel@one.myworld> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> Message-ID: <20050119161939.GA11983@burma.localdomain> > > > It is Interesting. But sometimes it ignore %{epoch} (for good or bad > > > > I'm unaware about such problems. Please, let me know if you find any > > cases I might study. > > README : > http://linux-br.conectiva.com.br/~niemeyer/smart/doc/README.html#case-1- > apt Can you please be a little bit more verbose? Smart is not ignoring the epoch anywhere there. > > It supports group in several places. If you have suggestions about how > > you'd like to see them handled, or GUI improvements, contact me please. > > Rpm group : > # rpm -q --queryformat "%{GROUP}\n" -a | sort | uniq > Applications/Archivage > Applications/Archiving > Applications/Bases de donn?es > Applications/Communications > ... > > Group (/usr/share/comps/i386/comps.xml) : > # yum grouplist > Installed Groups: > Administration Tools > Compatibility Arch Support > DNS Name Server > Editors > GNOME Desktop Environment > Graphical Internet > ... So you're not talking about rpm groups. Interesting concept. -- Gustavo Niemeyer http://niemeyer.net From technojoecoolusa at charter.net Wed Jan 19 16:26:51 2005 From: technojoecoolusa at charter.net (Joseph D. Wagner) Date: Wed, 19 Jan 2005 10:26:51 -0600 Subject: RFC: Optimizing for 386 In-Reply-To: <20050119160944.GA25782@jadzia.bu.edu> Message-ID: <3khdg6$gpoloe@mxip03a.cluster1.charter.net> > They're optimized for pentium4, but use the i386 instruction set. There are instructions which have come out since the 386, like MMX, that could improve the performance of programs. In this case, graphics programs. Why should my graphics programs suffer because some fool is running a 20 year old computer? > this comes up a lot. If that many people are crying for it, maybe it should be done. Joseph D. Wagner From technojoecoolusa at charter.net Wed Jan 19 16:27:23 2005 From: technojoecoolusa at charter.net (Joseph D. Wagner) Date: Wed, 19 Jan 2005 10:27:23 -0600 Subject: RFC: Optimizing for 386 In-Reply-To: Message-ID: <3k70kp$m0vvfm@mxip16a.cluster1.charter.net> > You could have spend some time searching through the archives You could have spent some time counting the huge numbers of people who are asking for the same thing I am asking for, and perhaps a little time working towards those ends. Joseph D. Wagner From nbargnesi at gmail.com Wed Jan 19 16:27:12 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Wed, 19 Jan 2005 11:27:12 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <3khdfd$heo20h@mxip04a.cluster1.charter.net> References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> Message-ID: <3077b8a0050119082743fff58a@mail.gmail.com> On Wed, 19 Jan 2005 10:08:22 -0600, Joseph D. Wagner wrote: > I can count the total number of people in the world who still use a 386 on the fingers of both of my hands. Why are we still catering to this small group of people? > > With the exception of the kernel and glibc, all RPM's are optimized for 386 architecture. Acckk! All RPM's are optimized for i386? But I'm running x86_64! Who let 3 out of the cage with this showstopper? Where's the errata? :) This is a waste of system resources. Study after study shows that you can achieve a 10% - 40% performance improvement my optimizing code for a specific architecture. Windows XP may only be optimized for a Pentium, but by golly, at least the whole thing is optimized, not just the kernel and the C library. > > Just look at X. Is anyone seriously trying to get X to run on a 386? I can understand compiling the text-based programs, like bash, for 386. You can run a text-only box on a 386 just fine. Why do that for X? Why do that for GNOME, KDE, or any graphical program for that matter? > > I know that I can recompile of these program from the source code to achieve those optimizations. However, why should everyone who wants to optimize their systems have to go through that, just so a handful of people with 386 machines can run X out-of-the-box? Then, we have recompile all over again with the next RPM release. > > Why can't the few people who have a 386 be made to recompile X from sources to get it to run on there machines, so the rest of us can enjoy the performance boost from running optimized binaries? > > I think we seriously need to rethink the distribution strategy. At the very least, all graphical programs should be optimized for i686. > > Joseph D. Wagner > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From jspaleta at gmail.com Wed Jan 19 16:30:42 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 19 Jan 2005 11:30:42 -0500 Subject: Fedora Core 4 In-Reply-To: <20050119170911.B15870@ryoko.camperquake.de> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119152425.34e064f1@nausicaa.camperquake.de> <604aa791050119070644bbb0b7@mail.gmail.com> <20050119165449.A15870@ryoko.camperquake.de> <604aa791050119080054ff3ca4@mail.gmail.com> <20050119170911.B15870@ryoko.camperquake.de> Message-ID: <604aa791050119083055fb42bc@mail.gmail.com> On Wed, 19 Jan 2005 17:09:11 +0100, Ralf Ertzinger wrote: > And just for the record: I read what it is trying to do before committing, > and I know that downgrading or suspicious removal usually means that there > is a bug somewhere. I'm not concerned about people like you or I... people who could be considered technically proficient and who have experience troubleshooting problems that are the result of packaging errors. I am very concerned about what happens if/when novice users begin to use smart as their primary tool. I admit that for advanced users who understand when something is 'suspicious' this approach can be very powerful... but for the 90% of the userbase who don't have a good grasp as to when something is suspicious and when it is not.. this can lead to problems. Especially if the advanced users using the same tool.. aren't being encourage to file bugs. The best way to encourage the filing of bugs is to stop execution and throw an error message. There is a better way in my head, involving keeping up with 'channel policies' instead of 'priorities'.. i just have to find the words and the time to articulate it. A way that allows smart to do exactly what it does now when it needs to deal with overlapping addon repos when you want to install something new... but flags reportable problems when a channel or group of channels aren't self-consistent when they should be. -jef From technojoecoolusa at charter.net Wed Jan 19 16:35:43 2005 From: technojoecoolusa at charter.net (Joseph D. Wagner) Date: Wed, 19 Jan 2005 10:35:43 -0600 Subject: RFC: Optimizing for 386 In-Reply-To: <20050119171047.C15870@ryoko.camperquake.de> Message-ID: <3k77vd$gbck0f@mxip10a.cluster1.charter.net> > This is not true. The default optimization is for Pentium 4 class > processors. This is not accurate. gcc has two separate sets of optimizations. The first (mtune) tunes everything except the ABI. This is the part that is optimized for the Pentium 4. The second (march) actually tunes the ABI. The second is optimized for 386. In other words, it won't take advantage of any instruction that didn't exist on the original 386. I would like my ABI, especially for the graphics programs, to be optimized for more modern architecture, like i686. Joseph D. Wagner From feliciano.matias at free.fr Wed Jan 19 16:36:14 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Wed, 19 Jan 2005 17:36:14 +0100 Subject: Fedora Core 4 In-Reply-To: <20050119161939.GA11983@burma.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119161939.GA11983@burma.localdomain> Message-ID: <1106152574.15549.19.camel@one.myworld> Le mercredi 19 janvier 2005 ? 14:19 -0200, Gustavo Niemeyer a ?crit : > > > > It is Interesting. But sometimes it ignore %{epoch} (for good or bad > > > > > > I'm unaware about such problems. Please, let me know if you find any > > > cases I might study. > > > > README : > > http://linux-br.conectiva.com.br/~niemeyer/smart/doc/README.html#case-1- > > apt > > Can you please be a little bit more verbose? Smart is not ignoring > the epoch anywhere there. http://linux-br.conectiva.com.br/~niemeyer/smart/doc/README.html#case-1-apt Version 2.3.3 is needed, but *1*:2.3.2-586_1cl is to be installed. This message is mostly correct. The only problem is, "*1*:2.3.2-586_1cl" is already installed: Version 2.3.3 means *0*:2.3.3. [root at damien:/root] smart install xscreensaver Updating cache... ######################################## [100%] Computing transaction... Downgrading packages (1): <== glibc-gconvdata-0:2.3.3-69473cl.i386 <== replace *1*:2.3.2 I don't know (or care) if this is good or bad. But %{epoch} (as I understand it) is not a version. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From niemeyer at conectiva.com Wed Jan 19 16:38:22 2005 From: niemeyer at conectiva.com (Gustavo Niemeyer) Date: Wed, 19 Jan 2005 14:38:22 -0200 Subject: Fedora Core 4 In-Reply-To: <20050119165449.A15870@ryoko.camperquake.de> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119152425.34e064f1@nausicaa.camperquake.de> <604aa791050119070644bbb0b7@mail.gmail.com> <20050119165449.A15870@ryoko.camperquake.de> Message-ID: <20050119163822.GB11983@burma.localdomain> > Please note that the example I commented on was an explicit > request to install a specific package, not a general update. > > smart just told the user that it needed to downgrade to > fulfil the request, which is true. What the other tools do in > the same situation is listed on the same page. That's exactly the idea. We're all in the same boat, looking at the same issues from different angles. Smart has algorithms to choose a better possibility given the available options. Jeff seems to be looking for a debug tool to detect broken distributions. > > So as an advanced user you might find the automated decision making > > as to what to remove or to downgrade useful a novice user will be > > confused because they might assume the downgrading is a perfectly > > natural thing. Why was the dependency broken? Why was the downgrade needed? Why the old package was still available if downgrading to it was a bad option? Smart currently is not a debugging tool (it might easily become one though, and I've used portions of it to do so). It's a tool to help users achieve a given goal they're looking for. Any distribution wanting to prevent Smart from doing downgrades may very easily do so, but IMO, the correct way to handle it is not to prevent Smart from doing downgrades, but preventing downgrades to be actually needed as a distribution supporter. If things are broken, then let Smart do its job trying to find a feasible solution. [...] > I am running rawhide with smart. Enabled repos are fc-devel at 0, freshrpms at 0, > dag at -5 newrpms at -5, atrpms-stable at -10, atrpms-good at -10, atrpms-bleeding at -20. > > It's heaven. I'm glad to hear that. Let me know if you find problems. -- Gustavo Niemeyer http://niemeyer.net From elanthis at awesomeplay.com Wed Jan 19 16:38:30 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Wed, 19 Jan 2005 11:38:30 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <3khdg6$gpoloe@mxip03a.cluster1.charter.net> References: <3khdg6$gpoloe@mxip03a.cluster1.charter.net> Message-ID: <1106152710.27237.22.camel@support02.civic.twp.ypsilanti.mi.us> On Wed, 2005-01-19 at 10:26 -0600, Joseph D. Wagner wrote: > > They're optimized for pentium4, but use the i386 instruction set. > > There are instructions which have come out since the 386, like MMX, > that could improve the performance of programs. In this case, > graphics programs. Why should my graphics programs suffer because > some fool is running a 20 year old computer? File bugs for the apps that you *know* could use the optimization. Make sure the code actually can use those newer instructions and that the compiler actually does any auto-vectorization for the code in question. Provide benchmarks proving that performance increases instead of simply blind and likely incorrect assumptions. > > > this comes up a lot. > > If that many people are crying for it, maybe it should be done. Or maybe that many people are clueless. Thankfully most of them are as rude and obnoxious as certain others. > > Joseph D. Wagner > > From technojoecoolusa at charter.net Wed Jan 19 16:40:39 2005 From: technojoecoolusa at charter.net (Joseph D. Wagner) Date: Wed, 19 Jan 2005 10:40:39 -0600 Subject: RFC: Optimizing for 386 In-Reply-To: <3077b8a0050119082743fff58a@mail.gmail.com> Message-ID: <3khj1h$ghul9b@mxip07a.cluster1.charter.net> > Acckk! All RPM's are optimized for i386? But I'm running x86_64! OK, let me make clarify what I said. AMENDED: All IA32 RPM's are optimized for 386 architecture. x86_64 uses a completely separate set of RPM's. Joseph D. Wagner From sopwith at redhat.com Wed Jan 19 16:40:32 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 19 Jan 2005 11:40:32 -0500 (EST) Subject: RFC: Optimizing for 386 In-Reply-To: <3k77vd$gbck0f@mxip10a.cluster1.charter.net> References: <3k77vd$gbck0f@mxip10a.cluster1.charter.net> Message-ID: On Wed, 19 Jan 2005, Joseph D. Wagner wrote: > This is not accurate. gcc has two separate sets of optimizations. The > first (mtune) tunes everything except the ABI. This is the part that is > optimized for the Pentium 4. The second (march) actually tunes the ABI. > The second is optimized for 386. In other words, it won't take > advantage of any instruction that didn't exist on the original 386. We know this, but the present compile settings still are just fine. Please go read the archives! :) Best, -- Elliot From davej at redhat.com Wed Jan 19 16:42:19 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 19 Jan 2005 11:42:19 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <3khdg6$gpoloe@mxip03a.cluster1.charter.net> References: <20050119160944.GA25782@jadzia.bu.edu> <3khdg6$gpoloe@mxip03a.cluster1.charter.net> Message-ID: <20050119164219.GX29712@redhat.com> On Wed, Jan 19, 2005 at 10:26:51AM -0600, Joseph D. Wagner wrote: > > They're optimized for pentium4, but use the i386 instruction set. > There are instructions which have come out since the 386, like MMX, that > could improve the performance of programs. In this case, graphics programs. Many graphics programs test for features such as mmx/3dnow/sse at runtime and run alternative hand-written assembly routines when present. This way the program runs on any x86 platform regardless of featureset without needing to be compiled for a specific variant. > Why should my graphics programs suffer because some fool is running a 20 > year old computer? You forgot to attach the benchmarks showing the improvements. For a large percentage of the packages shipped in Fedora, RPMs 'optimised' for >386 just won't be noticable. Dave From niemeyer at conectiva.com Wed Jan 19 16:46:09 2005 From: niemeyer at conectiva.com (Gustavo Niemeyer) Date: Wed, 19 Jan 2005 14:46:09 -0200 Subject: Fedora Core 4 In-Reply-To: <1106152574.15549.19.camel@one.myworld> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119161939.GA11983@burma.localdomain> <1106152574.15549.19.camel@one.myworld> Message-ID: <20050119164609.GC11983@burma.localdomain> > http://linux-br.conectiva.com.br/~niemeyer/smart/doc/README.html#case-1-apt > Version 2.3.3 is needed, but *1*:2.3.2-586_1cl is to be > installed. This message is mostly correct. The only problem is, > "*1*:2.3.2-586_1cl" is already installed: > > Version 2.3.3 means *0*:2.3.3. Exactly. > > [root at damien:/root] smart install xscreensaver > Updating cache... ######################################## [100%] > > Computing transaction... > > Downgrading packages (1): <== > glibc-gconvdata-0:2.3.3-69473cl.i386 <== replace *1*:2.3.2 Version *0*:2.3.3 is needed, and version *0*:2.3.3 is being installed, replacing *1*:2.3.2, to satisfy dependencies in the other packages being installed, which require *0*:2.3.3. Where's the ignored epoch? > I don't know (or care) if this is good or bad. But %{epoch} (as I > understand it) is not a version. What are you talking about? -- Gustavo Niemeyer http://niemeyer.net From fedora-devel at camperquake.de Wed Jan 19 16:47:41 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Wed, 19 Jan 2005 17:47:41 +0100 Subject: Fedora Core 4 In-Reply-To: <20050119163822.GB11983@burma.localdomain>; from niemeyer@conectiva.com on Wed, Jan 19, 2005 at 02:38:22PM -0200 References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119152425.34e064f1@nausicaa.camperquake.de> <604aa791050119070644bbb0b7@mail.gmail.com> <20050119165449.A15870@ryoko.camperquake.de> <20050119163822.GB11983@burma.localdomain> Message-ID: <20050119174741.D15870@ryoko.camperquake.de> On Wed, Jan 19, 2005 at 02:38:22PM -0200, Gustavo Niemeyer wrote: > > I am running rawhide with smart. Enabled repos are fc-devel at 0, freshrpms at 0, > > dag at -5 newrpms at -5, atrpms-stable at -10, atrpms-good at -10, atrpms-bleeding at -20. > > > > It's heaven. > > I'm glad to hear that. Let me know if you find problems. For one, I'd like smart (I am using the shell mode for the most part) to tell me the repo the package it is trying to update/install is coming from (maybe optional). There are some other things, but nothing major. I'll PM that to you. From michael.favia at insitesinc.com Wed Jan 19 16:51:19 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Wed, 19 Jan 2005 10:51:19 -0600 Subject: RFC: Optimizing for 386 In-Reply-To: <3k70kp$m0vvfm@mxip16a.cluster1.charter.net> References: <3k70kp$m0vvfm@mxip16a.cluster1.charter.net> Message-ID: <41EE9007.3050906@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joseph D. Wagner wrote: |>You could have spend some time searching through the archives | | | You could have spent some time counting the huge numbers of people who are asking for the same thing I am asking for, and perhaps a little time working towards those ends. I think we could all spend a little more time being a little more tolerant of each other. Everyone has the same goals here. Let's be civil towards one another. - -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB7pAHBVsNYjF2rDYRAu9+AJ0Z8MlKEgCEX67oYIQ5wNQNbTN8LwCgjZr8 TRXKbSrYrd3/vjHwwQJOS+A= =W6br -----END PGP SIGNATURE----- From Axel.Thimm at ATrpms.net Wed Jan 19 16:51:53 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 19 Jan 2005 17:51:53 +0100 Subject: Fedora Core 4 In-Reply-To: <20050119134305.GB8334@burma.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> Message-ID: <20050119165153.GG6804@neu.physik.fu-berlin.de> On Wed, Jan 19, 2005 at 11:43:05AM -0200, Gustavo Niemeyer wrote: > > At this point smart doesn't have multilib support > > Yes, it does. Anything not working is a bug which I'll fix, once > reported and consensus on correct behavior is obtained. There are different schools on multilib behaviour. One is to have minimal installs, e.g. do not install all arch versions just because they exits, the other is to do so, as asking a package manager for package foo is ambiguous (all of them or just the native package?). Sometimes I'm setting up multilib-free systems (e.g. no overlapping packages at all), and a yum install foo (w/o adding an arch) will pull in both x86_64 and i386 packages. So it is basically more a matter of personal taste than consensus. I would suggest the following: o make an explicit removal w/o any arch mean "remove for all archs". I think that is unambigous. o make the explicit install of a package w/o mentioning any arch be dependent on configuration, so some users can have "all archs" and some "only the best arch" o make the updating/fixing algorithm be generally minimal in package installations, or perhaps depend on the above configuration setting. In general I think less is better ;) Thanks! > > (at least from reading of the code) > > You've read the code, so you know it's easy to implement almost > anything, and that there are many other interesting aspects on > the software. > > > so I'm not sure how useful that will be for a distro > > offering (soon, I hope) two multilib archs: x86_64 and ppc64. > > Tell me what kind of support you consider necessary for a > "distro offering" and I'll implement it. > > You know I've been working hard to make everything work perfectly, and > that even though it's not yet completely polished due to its incipient > life, the project is in a quite advanced state, and have many > advantages over APT-RPM and others. > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jon at jonshouse.co.uk Wed Jan 19 16:52:15 2005 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 19 Jan 2005 16:52:15 +0000 Subject: RFC: Optimizing for 386 In-Reply-To: <3k77vd$gbck0f@mxip10a.cluster1.charter.net> References: <3k77vd$gbck0f@mxip10a.cluster1.charter.net> Message-ID: <1106153534.5881.2391.camel@jonspc> On Wed, 2005-01-19 at 16:35, Joseph D. Wagner wrote: > > This is not true. The default optimization is for Pentium 4 class > > processors. > > This is not accurate. gcc has two separate sets of optimizations. The first (mtune) tunes everything except the ABI. This is the part that is optimized for the Pentium 4. The second (march) actually tunes the ABI. The second is optimized for 386. In other words, it won't take advantage of any instruction that didn't exist on the original 386. > > I would like my ABI, especially for the graphics programs, to be optimized for more modern architecture, like i686. > > Joseph D. Wagner Pointing out the obvious why doesn't somebody test core 3 against a fully source built distro like Gentoo and see if the performance gains are real - thats not just benchmark, but perceived responsiveness. If the gains are that huge then users will cry ever louder and it will happen.... thats the open source way. Or alternately some people can "fork off" and build their own Fedora based distro - Redhat lawyers permitting....... Jon From niemeyer at conectiva.com Wed Jan 19 16:53:56 2005 From: niemeyer at conectiva.com (Gustavo Niemeyer) Date: Wed, 19 Jan 2005 14:53:56 -0200 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <604aa79105011907515a656615@mail.gmail.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> Message-ID: <20050119165356.GD11983@burma.localdomain> Greetings Jeff, > I hope you read my contribution to the thread on -devel-list. But if > you don't i'd like to point out I think so, but I'm back from vacation this week, and trying to work out the backlog, so I'm sorry for any delays. [...] > concerned that a novice user with little experience with rpms won't > have enough information to cancel the operation and similar operations > if there is a packaging error. As I mentioned in the other message, you're looking for a debug tool and not for a dependency solver. I'll be glad to exchange ideas with you and create a special "debugging mode" for Smart for distribution maintainers to use during development period, if that's considered an important feature. > Let me construct for you a simple hypothetical setup of channels based > on Core 3 and show how it could help prevent the wireless-tools > packaging problem. > > Lets start with just the Core channels: > > Core3os: The channel for fc3 os, > this channel explicit states as a matter of policy that it is > self-consistent and that it > requires no dependances from anwhere else. And conflicts between [...] That kind of "policy tool" is an excelent idea, and very easily done with what Smart currently offers. Contact me if you need help in building something like this. PS. You mentioned your message was unfinished, so I hope I was able to follow your intentions correctly. -- Gustavo Niemeyer http://niemeyer.net From davej at redhat.com Wed Jan 19 17:00:08 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 19 Jan 2005 12:00:08 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <1106153534.5881.2391.camel@jonspc> References: <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <1106153534.5881.2391.camel@jonspc> Message-ID: <20050119170008.GY29712@redhat.com> On Wed, Jan 19, 2005 at 04:52:15PM +0000, Jonathan Andrews wrote: > Pointing out the obvious why doesn't somebody test core 3 against a > fully source built distro like Gentoo and see if the performance gains > are real - thats not just benchmark, but perceived responsiveness. If > the gains are that huge then users will cry ever louder and it will > happen.... thats the open source way. Because its an apples/oranges comparison. Unless you have the exact same versions of software, with exactly the same patches, with exactly the same configuration options, on exactly the same kernel/glibc, and only different compiler flags for the application, you're comparing N different things at the same time, resulting in a cumulative effect rather than a direct 1:1 comparison. > Or alternately some people can "fork off" and build their own Fedora > based distro - Redhat lawyers permitting....... We didn't send lawyers after the folks rebuilding RHEL packages into binary distros, so I can't see why we'd do so for Fedora, as long as any trademark's were respected etc. Dave From seyman at wanadoo.fr Wed Jan 19 17:00:01 2005 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Wed, 19 Jan 2005 18:00:01 +0100 Subject: RFC: Optimizing for 386 In-Reply-To: <1106153534.5881.2391.camel@jonspc> References: <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <1106153534.5881.2391.camel@jonspc> Message-ID: <20050119170001.GA8330@orient.maison.moi> On Wed, Jan 19, 2005 at 04:52:15PM +0000, Jonathan Andrews wrote: > > Pointing out the obvious why doesn't somebody test core 3 against a > fully source built distro like Gentoo and see if the performance gains > are real - thats not just benchmark, but perceived responsiveness. If Even better, test un unoptimized Gentoo against an optimized one. That way, you'll have identical versions of tested software. Emmanuel From jakub at redhat.com Wed Jan 19 17:02:36 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 19 Jan 2005 12:02:36 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <3k77vd$gbck0f@mxip10a.cluster1.charter.net> References: <20050119171047.C15870@ryoko.camperquake.de> <3k77vd$gbck0f@mxip10a.cluster1.charter.net> Message-ID: <20050119170235.GV10340@devserv.devel.redhat.com> On Wed, Jan 19, 2005 at 10:35:43AM -0600, Joseph D. Wagner wrote: > > This is not true. The default optimization is for Pentium 4 class > > processors. > > This is not accurate. gcc has two separate sets of optimizations. The > first (mtune) tunes everything except the ABI. This is the part that is > optimized for the Pentium 4. The second (march) actually tunes the ABI. > The second is optimized for 386. In other words, it won't take advantage > of any instruction that didn't exist on the original 386. > > I would like my ABI, especially for the graphics programs, to be optimized > for more modern architecture, like i686. Please read the archives, all this has been answered several times already. Yes, we know very well about -march and -mtune difference. The current CFLAGS (for *.i386.rpm -march=i386 -mtune=pentium4) are just fine for the whole distro. But please tell us what instructions could be useful and would overweight the negatives (making FC impossible to run on certain hardware). The ISA changes between i386 and i586 are uninteresting for the vast majority of programs (the main differences are atomic and specialized instructions, atomic instructions are used mostly by the kernel, C library and thread library, all of them come in i686 variants). The i686 ISA adds conditional moves (some argue that this is optional i686 feature, but GCC's definition of i686 is i686 with cmov). Now, cmov* speeds things up on certain architectures, but: 1) using it everywhere would mean that FC doesn't support various not so old VIA CPUs, etc. 2) on P4, cmov* instructions aren't any win over using branches Later CPUs add MMX, 3dNOW!, SSE, SSE2, SSE3 instructions. But 1) only GCC 4.0+ supports autovectorization, and only for SSE/SSE2 2) programs/libraries that have MMX/3dNOW!/SSE/SSE2/SSE3 assembly or use {,p,e,x}mmintrin.h usually choose between several implementations at runtime depending on what the CPU supports (e.g. various graphics/multimedia programs do this), or like e.g. gmp are packaged, so that the dynamic linker uses optimized libraries on SSE2+ capable CPUs 3) with SSE2+, -mfpmath=sse can speed up FPU intensive programs or libraries quite a bit. But SSE2+ is very high bar for the lowest supported CPU by FCx/ix86 ATM, that would mean not supporting even 2 years old CPUs. So, if a particular library is seen that has measurable improvements with -mfpmath=sse, it is far better to ship it as /usr/lib/sse2/ library instead of shipping everything in .pentium4.rpm's. Note that the vast majority of packages in the distro aren't CPU bound, so it is just about selecting those where there are measurable improvements that justify alternate rpms resp. second set of libraries in .i386.rpm packages etc. Jakub From abo at kth.se Wed Jan 19 17:02:53 2005 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Wed, 19 Jan 2005 18:02:53 +0100 Subject: RFC: Optimizing for 386 In-Reply-To: <3khdfd$heo20h@mxip04a.cluster1.charter.net> References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> Message-ID: <1106154173.25705.30.camel@tudor.e.kth.se> ons 2005-01-19 klockan 10:08 -0600 skrev Joseph D. Wagner: > I can count the total number of people in the world who still use a > 386 on the fingers of both of my hands. Why are we still catering to > this small group of people? I'm not going to read the archives for you, but I think it has been pointed out that there are relevant CPU:s that only implement the i386 instructions. For example the VIA CPU:s. /abo From jon at jonshouse.co.uk Wed Jan 19 17:04:43 2005 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 19 Jan 2005 17:04:43 +0000 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <20050119165356.GD11983@burma.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> <20050119165356.GD11983@burma.localdomain> Message-ID: <1106154283.5881.2396.camel@jonspc> Im no novice user - nor an expert, but somebody please tell me what yum/up2date has that apt/synaptic doesn't ? I've been using apt/synaptic against core 3 and im beginning to think that yum is a political move not a technical one ? Sorry if this annoys - im not trying to troll Jon From nbargnesi at gmail.com Wed Jan 19 17:05:17 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Wed, 19 Jan 2005 12:05:17 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <20050119170001.GA8330@orient.maison.moi> References: <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <1106153534.5881.2391.camel@jonspc> <20050119170001.GA8330@orient.maison.moi> Message-ID: <3077b8a00501190905a1f9c2d@mail.gmail.com> On Wed, 19 Jan 2005 18:00:01 +0100, Emmanuel Seyman wrote: > On Wed, Jan 19, 2005 at 04:52:15PM +0000, Jonathan Andrews wrote: > > > > Pointing out the obvious why doesn't somebody test core 3 against a > > fully source built distro like Gentoo and see if the performance gains > > are real - thats not just benchmark, but perceived responsiveness. If > > Even better, test un unoptimized Gentoo against an optimized one. > That way, you'll have identical versions of tested software. That's the best suggestion. In theory, I think optimized/unoptimized builds of gentoo leading to a comparison would support the main argument here. I for one have built KDE from qt on up optimized versus unoptimized with no noticeable gain in anything. > > Emmanuel > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From niemeyer at conectiva.com Wed Jan 19 17:09:58 2005 From: niemeyer at conectiva.com (Gustavo Niemeyer) Date: Wed, 19 Jan 2005 15:09:58 -0200 Subject: Fedora Core 4 In-Reply-To: <20050119165153.GG6804@neu.physik.fu-berlin.de> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <20050119165153.GG6804@neu.physik.fu-berlin.de> Message-ID: <20050119170958.GE11983@burma.localdomain> > There are different schools on multilib behaviour. One is to have > minimal installs, e.g. do not install all arch versions just because > they exits, the other is to do so, as asking a package manager for > package foo is ambiguous (all of them or just the native package?). FWIW, the currently adopted approach in Smart is to have disjoint graphs on multilib packages. In other words, if there are 64bit and 32bit versions of a package, they'll be upgraded by newer versions of their counterparts. > Sometimes I'm setting up multilib-free systems (e.g. no overlapping > packages at all), and a yum install foo (w/o adding an arch) will pull > in both x86_64 and i386 packages. > > So it is basically more a matter of personal taste than consensus. I That's what I see as well. > would suggest the following: > > o make an explicit removal w/o any arch mean "remove for all archs". I > think that is unambigous. What if the user wanted to remove just the 32bit version? > o make the explicit install of a package w/o mentioning any arch be > dependent on configuration, so some users can have "all archs" and > some "only the best arch" > o make the updating/fixing algorithm be generally minimal in package > installations, or perhaps depend on the above configuration > setting. Thanks a lot for these suggestions. I'll write them down and study if what Smart currently implements could be enhanced by implementing something around your ideas. > In general I think less is better ;) I agree. The real issue about this is creating some scheme that users actually expect, making usual things simple, and unusual things possible. I hope to put my hands on a multilib system ASAP, to be able to also develop my own feeling about these cases. Thank you very much! -- Gustavo Niemeyer http://niemeyer.net From jon at jonshouse.co.uk Wed Jan 19 17:12:04 2005 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 19 Jan 2005 17:12:04 +0000 Subject: RFC: Optimizing for 386 In-Reply-To: <3077b8a00501190905a1f9c2d@mail.gmail.com> References: <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <1106153534.5881.2391.camel@jonspc> <20050119170001.GA8330@orient.maison.moi> <3077b8a00501190905a1f9c2d@mail.gmail.com> Message-ID: <1106154723.5881.2402.camel@jonspc> On Wed, 2005-01-19 at 17:05, Nick Bargnesi wrote: > On Wed, 19 Jan 2005 18:00:01 +0100, Emmanuel Seyman wrote: > > On Wed, Jan 19, 2005 at 04:52:15PM +0000, Jonathan Andrews wrote: > > > > > > Pointing out the obvious why doesn't somebody test core 3 against a > > > fully source built distro like Gentoo and see if the performance gains > > > are real - thats not just benchmark, but perceived responsiveness. If > > > > Even better, test un unoptimized Gentoo against an optimized one. > > That way, you'll have identical versions of tested software. > > That's the best suggestion. In theory, I think optimized/unoptimized > builds of gentoo leading to a comparison would support the main > argument here. I for one have built KDE from qt on up optimized > versus unoptimized with no noticeable gain in anything. True, my 1.3Ghz athlon doesnt even break a sweat in the CPU stakes doing most jobs. A request for core 4 If more people has the fantastic 'kcpuload' tool available it would give them a better idea whats going on. Its in the kde archive, can it go back into core 4 as a default applet. Gnome has a good cpu monitor, but the best one kde has is missing from core ? Jon From walters at redhat.com Wed Jan 19 17:14:19 2005 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Jan 2005 12:14:19 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <3k70kp$m0vvfm@mxip16a.cluster1.charter.net> References: <3k70kp$m0vvfm@mxip16a.cluster1.charter.net> Message-ID: <1106154860.8243.9.camel@nexus.verbum.private> On Wed, 2005-01-19 at 10:27 -0600, Joseph D. Wagner wrote: > > You could have spend some time searching through the archives > > You could have spent some time counting the huge numbers of people who are asking for the same thing I am asking for, and perhaps a little time working towards those ends. I think the reason many people are asking about it is many people do not understand performance tuning. I'm one of them; several times I've guessed at what is making my program slow, and have been completely wrong. The right approach is to use tools to identify specific bottlenecks in specific programs or libraries. As for the specific case of extended CPU instructions, many packages do already use them at runtime. For example, GStreamer does that. From peter.backlund at home.se Wed Jan 19 17:24:16 2005 From: peter.backlund at home.se (Peter Backlund) Date: Wed, 19 Jan 2005 18:24:16 +0100 Subject: RFC: Optimizing for 386 In-Reply-To: <20050119170235.GV10340@devserv.devel.redhat.com> References: <20050119171047.C15870@ryoko.camperquake.de> <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <20050119170235.GV10340@devserv.devel.redhat.com> Message-ID: <1106155456.1952.45.camel@localhost.localdomain> Has anyone been testing -Os (optimize for size) instead of -O2 on any greater scale? Fitting as much as possible in L1-cache is a great way to obtain high performance. /Peter Backlund From pri.rhl3 at iadonisi.to Wed Jan 19 17:18:06 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Wed, 19 Jan 2005 12:18:06 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <41EE9007.3050906@insitesinc.com> References: <3k70kp$m0vvfm@mxip16a.cluster1.charter.net> <41EE9007.3050906@insitesinc.com> Message-ID: <1106155086.13408.5.camel@tuxpaq> On Wed, 2005-01-19 at 10:51 -0600, Michael Favia wrote: > I think we could all spend a little more time being a little more > tolerant of each other. Everyone has the same goals here. Let's be civil > towards one another. Okay, but could Joseph Wagner answer this question: Have you gone and read the archives regarding your 10%-40% claim? This has been discussed ad-nauseum on this list at a level of detail that I can only hope to ever understand, but I will defer to the glibc/gcc/kernel experts. For Mr. Wagner, I would also point out that to change compile options, change directory names, change the architecture portion of the rpm names (not all of which are required, but most certainly desirable to lessen confusion) is a HUGE undertaking. Not to mention the additional testing. To expect Fedora Core developers to embark on this journey without hard facts (i.e.: benchmarks) is dreaming. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From wcohen at redhat.com Wed Jan 19 17:28:33 2005 From: wcohen at redhat.com (William Cohen) Date: Wed, 19 Jan 2005 12:28:33 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <1106152710.27237.22.camel@support02.civic.twp.ypsilanti.mi.us> References: <3khdg6$gpoloe@mxip03a.cluster1.charter.net> <1106152710.27237.22.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <41EE98C1.6060707@redhat.com> Sean Middleditch wrote: > On Wed, 2005-01-19 at 10:26 -0600, Joseph D. Wagner wrote: > >>>They're optimized for pentium4, but use the i386 instruction set. >> >>There are instructions which have come out since the 386, like MMX, >>that could improve the performance of programs. In this case, >>graphics programs. Why should my graphics programs suffer because >>some fool is running a 20 year old computer? > > > File bugs for the apps that you *know* could use the optimization. Make > sure the code actually can use those newer instructions and that the > compiler actually does any auto-vectorization for the code in question. > Provide benchmarks proving that performance increases instead of simply > blind and likely incorrect assumptions. Benchmarking is important in this case. Use of the new instructions is only going to help in very specific cases where the code is CPU bound and the operations fit the style of parallel processing supported by the new instructions. In some cases the performance could be hurt due to the overheads of packing and unpacking the data for the MMX/SSE/3DNOW! register, besides on P4 processors the SSE hardware works at only half the speed as the integer units, so the gains are not going to be as big on P4. OProfile could be used to identify areas of code that are cpu bound. Some analsysis could be done to determine whether those sections of code could benefit from using the the special operations. However, these types of improvements by changing instructions are not going to give the order of magnitude improvements due to algorithm changes/improvements in code. These instruction changes are also very processor specific, while improvements in the algorithms will work on virtually everything. Blindly compiling all the rpms to use the latest instruction set isn't going to magically improve the performance of the code. There are other lots of other things besides processor instructions affecting performance like the memory hierarchy, interprocessor communciation, and algorithms. -Will From dcbw at redhat.com Wed Jan 19 17:32:27 2005 From: dcbw at redhat.com (Dan Williams) Date: Wed, 19 Jan 2005 12:32:27 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <1106155456.1952.45.camel@localhost.localdomain> References: <20050119171047.C15870@ryoko.camperquake.de> <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <20050119170235.GV10340@devserv.devel.redhat.com> <1106155456.1952.45.camel@localhost.localdomain> Message-ID: <1106155947.16525.14.camel@dcbw.boston.redhat.com> On Wed, 2005-01-19 at 18:24 +0100, Peter Backlund wrote: > Has anyone been testing -Os (optimize for size) instead of -O2 on any > greater scale? Fitting as much as possible in L1-cache is a great way to > obtain high performance. -Os versus -O2 for OpenOffice.org (on RHEL3, with gcc 3.3.2) produced no real benefit, besides a small reduction in library size (7-8 MB total through the whole set of libraries). It also made OOo hit optimization bugs (either gcc bugs or OOo code bugs) that had stuff as simple as file opening crashing. Most likely, its OOo's aggressive use of inline functions and complex templates that causes there to be only a minor benefit. For other programs though, -Os may well produce better-running, small- therefore-better-for-cache binaries. Dan From wcohen at redhat.com Wed Jan 19 17:37:56 2005 From: wcohen at redhat.com (William Cohen) Date: Wed, 19 Jan 2005 12:37:56 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <1106155456.1952.45.camel@localhost.localdomain> References: <20050119171047.C15870@ryoko.camperquake.de> <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <20050119170235.GV10340@devserv.devel.redhat.com> <1106155456.1952.45.camel@localhost.localdomain> Message-ID: <41EE9AF4.3060406@redhat.com> Peter Backlund wrote: > Has anyone been testing -Os (optimize for size) instead of -O2 on any > greater scale? Fitting as much as possible in L1-cache is a great way to > obtain high performance. > > /Peter Backlund > > The kernels in FC are currently compiled with -Os. I worked with some North Carolina State University studenst testing something like this out this fall on Mozilla. They found some improvement in performance (reduction in L1 cache and instruction TLB misses). I have put the pdf report at: http://people.redhat.com/wcohen/ncsu2004/Space%20Optimizations.pdf -Will From michael.favia at insitesinc.com Wed Jan 19 17:40:21 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Wed, 19 Jan 2005 11:40:21 -0600 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <1106154283.5881.2396.camel@jonspc> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> <20050119165356.GD11983@burma.localdomain> <1106154283.5881.2396.camel@jonspc> Message-ID: <41EE9B85.4030206@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan Andrews wrote: | Im no novice user - nor an expert, but somebody please tell me what | yum/up2date has that apt/synaptic doesn't ? | | I've been using apt/synaptic against core 3 and im beginning to think | that yum is a political move not a technical one ? | | Sorry if this annoys - im not trying to troll I am definitely not the most qualified one to answer this question but i dont mind telling you what i know or have heard. Yum/gyum/up2date were all written for fedora and for rpm package management. Apt/synaptic have been ported from debian and have a couple of layers of messiness to make things work just right (hearsay). Apt downloads (or did) semi-large digests that contain information about the packages currently available on the repo (which is updated every time the repo is updated) this digest is used to determine what is new and what dependencies exist between packages. Yum (recent versions at least) on the other hand downloads a brief (read: smaller) listing of the packages (with some meta data i think but not sure what) and then fetches the headers of the rpms independently to do dep resolution. I too was an apt user during fc1 and 2 but in the middle of fc2 i switched to yum because it is native, well supported and pretty well feature laden. I have issues with it like i do with most packages (and package managers) but all in all i consider it a strong utility. My chief complaint is the absence of a robust GUI interface (GYUM has way too many caveats for my tastes) that i can give to my novice users so they can explore the realms of OSS without having to use the CLI (i want to draw them in to Linux not scare them off with complexities). As a result i normally install new users with apt/synaptic and use yum myself because i like to think i know what im doing (if for no other reason than to track its development). Please dont take anything i said in this email as fact i didnt do any research because im lazy and just wanted to share with you the things that i had been told/found out through other means to provide you with a starting point for your own research. In short yum seems (to me) to be the package manager supported by FC and consequently more reliably depended on for future development and system compliance (at least internally). If you think that the selection of Yum is unwarranted i ask you to remember Beta and VHS tapes. Beta was better but VHS won because of market acceptance. At a certain point the benefits provided by one format are outweighed by their scarcity in the marketplace. - -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB7puEBVsNYjF2rDYRAvgVAJ9GZf4f/P5Ns1TzTUx8ICjbPZ7SlACghfDd AbCnt/1E5SuxB0aOsj0jElI= =H+RT -----END PGP SIGNATURE----- From jspaleta at gmail.com Wed Jan 19 17:52:05 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 19 Jan 2005 12:52:05 -0500 Subject: Fedora Core 4 In-Reply-To: <20050119163822.GB11983@burma.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119152425.34e064f1@nausicaa.camperquake.de> <604aa791050119070644bbb0b7@mail.gmail.com> <20050119165449.A15870@ryoko.camperquake.de> <20050119163822.GB11983@burma.localdomain> Message-ID: <604aa791050119095253da328f@mail.gmail.com> On Wed, 19 Jan 2005 14:38:22 -0200, Gustavo Niemeyer wrote: > That's exactly the idea. We're all in the same boat, looking at > the same issues from different angles. Smart has algorithms to > choose a better possibility given the available options. Jeff > seems to be looking for a debug tool to detect broken > distributions. Actually... im not looking for a debugging tool. I'm looking to find a balance between ultimate flexibility and robustness in the face of packaging errors in a way that protects novice users from errors in situations where errors are obvious based on our human understanding of how a channel is suppose to operate. I think we can all pretty much agree that if a Core updates-released package requires the removal of a Core package without an explicit obsolete tag being set, there is a problem there and it should be identified as an error. Novice users will click their way through pretty much any set of dialogs you give them, without blinking. If you present this case to a novice user they will simply do what smart suggests. And in the wireless-tools case smart's suggestion is sub-optimal to doing nothing. There is absolutely no good reason to provide a simple UI that encourages average users to commit package update transactions that are trying to work around internal package conflicts inside Core + Updates. These situations should NEVER happen, and we all know that. If the end-user tools lets them happen with a simple click of the mouse, thats a huge usability problem and its going to lead directly to broken systems. Flexibility needs to be tempered with robustness to errors. Point and click tools aimed at the average user, absolutely need to be designed to prevent novice users from taking action based on erronous packaging information as much as possible. A lot of what smart does when trying to be 'smart' breaks rpm mechanisms for constraining the dependancy space inside a self-consistent channel. smart's logic tries very hard to find a 'best fit' solution to a large multi-repo space but at the cost of removing consistency checks meant to be used when a channel or a group of channels is designed to be self-consistent. Its one thing to be clever and know that when you want to install a package from atrpms you should remove a conflicting core package because atrpms and core are not designed to be self-consistent as a pair. Its quite another to be so clever that you forget that Core itself is self-consistent and that Core+Updates-released is suppose to be self-consistent. What i want is to give smart's flexibility scope based on the understanding of how a channel is suppose to work and how a channel is suppose to work with other channels. installing something from livna, as a matter of channel policy, shouldn't require the removal of a core package.. we all know this.. its a stated policy for the livna channel. The update of a updates-released package shouldn't require the removal of a core package without an explicit obsolete being set... we know this.. this is a stated policy of how updates are suppose to work. These 'policy' definitions for the livna and the updates-released channel should be respected by packaging tools and should be used in the calculation of 'best' transaction to avoid offering any transaction that we know should never be presented to a user because it HAS to be the result of a packaging error according to established channel policy for the channels invovled in the transaction. We must build tools that protect users from errenous packaging. Epochs exist for a reasons... smart breaks the epoch functionality on purpose to perform superflexible dowgrades... regardless of which channels are being used in the transaction. This superflexible epoch ignore shouldn't be used in transactions in a self-consistent set of channels. There is no good reason to engage in this level of flexibility if you only have Core and Core Updates as active channels in the transaction set... this will lead to unexpected breakage for novice users when package errors are introduced. Obsolete tags exist for a reason... smart breaks the obsolete functionality to perform superflexible package removals across overlapping channels. There is no good reason to remove Core packages when updating a Core Update if there isn't an explicit obsolete being set. This will lead to unexpected breakage for novice users when package errors are introduced. Its a matter of finding a way to encode each channel's understood policy so that smart only offers transactions we are sure are not the result of packaging errors. The wireless-tools example is a concrete example of an offered transaction that should be prevented based on the expectation of how the updates channel is suppose to work. The only reason smart offers the transaction it does... is because there is a packaging error. Garbage in- garbage out. This situation can be refined if understood channel policy constraints are used in smart's transaction calculation. Since we know Core updates should never need to remove a Core package without an obsoletes tag, smart should avoid offering any transaction that would require that. -jef From Axel.Thimm at ATrpms.net Wed Jan 19 17:55:10 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 19 Jan 2005 18:55:10 +0100 Subject: Fedora Core 4 In-Reply-To: <20050119170958.GE11983@burma.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <20050119165153.GG6804@neu.physik.fu-berlin.de> <20050119170958.GE11983@burma.localdomain> Message-ID: <20050119175510.GI6804@neu.physik.fu-berlin.de> On Wed, Jan 19, 2005 at 03:09:58PM -0200, Gustavo Niemeyer wrote: > > o make an explicit removal w/o any arch mean "remove for all archs". I > > think that is unambigous. > > What if the user wanted to remove just the 32bit version? Perhaps have smart use yum's syntax here like in `smart remove foo.i386'? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From feliciano.matias at free.fr Wed Jan 19 17:27:24 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Wed, 19 Jan 2005 18:27:24 +0100 Subject: Fedora Core 4 In-Reply-To: <20050119164609.GC11983@burma.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119161939.GA11983@burma.localdomain> <1106152574.15549.19.camel@one.myworld> <20050119164609.GC11983@burma.localdomain> Message-ID: <1106155644.15549.27.camel@one.myworld> Le mercredi 19 janvier 2005 ? 14:46 -0200, Gustavo Niemeyer a ?crit : > Where's the ignored epoch? > The user use (want/need) glibc-gconvdata-1: > > I don't know (or care) if this is good or bad. But %{epoch} (as I > > understand it) is not a version. > > What are you talking about? "glibc-gconvdata-1: > glibc-gconvdata-0:" is false. glibc-gconvdata-1: != glibc-gconvdata-0: is true. They are two different packages. Smart replace an apple by an orange. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ad+lists at uni-x.org Wed Jan 19 18:02:23 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Wed, 19 Jan 2005 19:02:23 +0100 Subject: Proposal: swap epic for irssi In-Reply-To: <1106022929.6105.106.camel@localhost.localdomain> References: <1106022929.6105.106.camel@localhost.localdomain> Message-ID: <1106157742.6970.439.camel@serendipity.dogma.lan> Am Di, den 18.01.2005 schrieb Colin Charles um 5:35: > For FC-4, what would folk think about removing epic and replacing it > with irssi in Core? > > irssi currently sits in Extras, and we could very likely just move epic > to Extras after the swap. > > Thoughts? > Colin Charles, byte at aeon.com.my Hi Colin, I think this is a good idea as there are certainly much more irssi users than epic fans. irssi is actively developed and has powerful features like the proxy ability. Alexander -- Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.10-1.9_FC2smp Serendipity 18:58:27 up 5 days, 2:20, load average: 0.26, 0.21, 0.27 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From cmadams at hiwaay.net Wed Jan 19 19:49:28 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 19 Jan 2005 13:49:28 -0600 Subject: RFC: Optimizing for 386 In-Reply-To: <3khj1h$ghul9b@mxip07a.cluster1.charter.net> References: <3077b8a0050119082743fff58a@mail.gmail.com> <3khj1h$ghul9b@mxip07a.cluster1.charter.net> Message-ID: <20050119194928.GD1219319@hiwaay.net> Once upon a time, Joseph D. Wagner said: > OK, let me make clarify what I said. > > AMENDED: All IA32 RPM's are optimized for 386 architecture. And that is still wrong. All FC i386 arch RPMs are optimized for either i686 (up through FC2) or P4 (starting with FC3). Some important RPMs (kernel, glibc, openssl) where the difference has been proven come with i686 arch RPMs as well as i386 arch RPMs. Some other RPMs have code that detects i386 vs. i686 vs. Athlon (really "regular" vs. MMX/SSE/etc.) at runtime and uses the best available. Whenever this comes up, people make some claims of improvement if the instruction set used is i686 instead of i386, but the challenge is to prove it. The only valid way to prove it is to do some type of repeatable benchmark of real applications with Fedora Core installed as distributed. Then rebuild the packages from the same source with the only change being i686 arch instead of i386 arch and retest. Anything else is not a valid test of the gain Fedora could see in switching from i386 arch to i686 arch. If someone takes the time to prove the point (and it is proven that the pain is worth the gain), you will get results; people will listen. Until it is proven, you'll just get told to RTFA. The burden of proof is on those asking for the change. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From nigelenki at comcast.net Wed Jan 19 19:45:44 2005 From: nigelenki at comcast.net (John Richard Moser) Date: Wed, 19 Jan 2005 19:45:44 +0000 (UTC) Subject: Improving security References: <416E5A76.4050906@hhs.nl> Message-ID: Hans de Goede hhs.nl> writes: > > Hi, > > I just read this interesting article on lwn: > http://lwn.net/Articles/106214/ > (lwn subscriber only) > Yay :) > This talks about things like: > 1 Stack Smash Protection > 2 PAX (alternative Exec Shield) > 3 Position Independent Executables. > > Stack Smash Protection sounds like a cool feature to me. I don't know > what the performance impact is, but as a developer even if it is to slow > to use by default I would love to have it intergrated into the gcc > shipped by Fedora to make debugging easier. > I use it. The performance impact isn't noticable, but it's highly variable. It's theoretical maximum is something like 8%; and it drops when a function gets bigger, or when functions aren't protected. You can use heuristics (-fstack-protector) to protect only functions with a local character array; or just protect all (-fstack-protector-all). With the heuristics, it's likely you don't much encounter protected functions. My best guess looking at the design (not the code) is that it takes about 4 instructions to protect a function on the base, plus one more per passed argument, based on the below. SSP rearranges variables at compile time. This produces no runtime overhead. SSP protects a function with a local char[] using a __guard value. This would require expanding the stack frame. The best way is to allocate the entire stack frame at once, so I assume the GCC devs are smart and that this produces 0 extra instructions. Next, you need to check the GOT for __guard (I'm assuming O(1), so one instruction), and use MOV to copy __guard to local_guard (1 insn). At return in a protected function, __guard must be checked with CMP. If it's fine, then JE past the code that calls __stack_smash_handler(). Two more instructions. This totals 4 for a __guard protection on a function. To protect passed arguments, the stack frame has to be made bigger (no overhead?). A MOV based on an offset from an address in some register has to be made for each argument (1 insn for each argument). I'm guessing at internals, but I think most of this is possible. I'm not sure about the O(1) GOT lookup. I'm probably wrong there. > PAX uses tricks to get a non executable stack, and assignes random > addresses to PIE executables, which Fedora already has in the form of > Exec Shield, good! But if I undertand it correctly PAX does more for > example also make data pages non executable, this might be something > worth looking into. PaX makes a strict separation between Writable and Executable memory. It also has more accurate NX emulation on x86. Ingo has admitted that PaX is competetive with Exec Shield in recent LKML posts: (but no doubt PaX is fine and protects against exploits at least as effectively as (and in some cases more effectively than) exec-shield, so you've definitely not made a bad choice.) It's also older and still actively developed (older and inactive is bad, older and active is good, younger and active is not quite as good unless your developer is quite a lot more competant on the subject). SEGMEXEC on x86 splits the address space in half to emulate an NX bit; I've never seen this cause a problem in anything. PAGEEXEC used to use kernel-assisted MMU walking, which can be very high overhead depending on memory access patterns; now it uses the same method Exec Shield uses, but falls back to kernel-assisted MMU walking if that fails (due to mprotect()ing a higher address with PROT_EXEC). > > PIE we already have, good! > Feh, your PIE is a joke. My ENTIRE SYSTEM is PIE, save for what won't compile PIE. I don't use Fedora, but last I heard, only a few programs were PIE. The overhead of PIC (based on nbyte-bench) is something like 0.99002% on x86, and 0.02% on amd64. There's another caveat: -fomit-frame-pointer usually gives a -5% overhead (i.e. it removes overhead and thus programs use less CPU). This is lost on x86; no effect (ok, 0.01%) on amd64. That being said, you have to understand that libraries are ALL PIC. You lose NOTHING in libraries by going to PIE. All plug-ins to anything (except gimp?), all encoder and decoder libraries, libtheora, libogg, libvorbis, libvorbisenc, liblame, libmad, libzlib and libbzip2, ALL YOUR HEAVY LIFTING is done in libraries. I haven't profiled it but I'm fairly sure that any large amounts of CPU are typically spent in PIC code anyway. I'm pretty certain that the real-world system-wide impact of PIE is dismally low due to the low amount of time the actual executable load module spends on the CPU versus the libraries it uses. > Regards, > > Hans > From ad+lists at uni-x.org Wed Jan 19 19:59:30 2005 From: ad+lists at uni-x.org (Alexander Dalloz) Date: Wed, 19 Jan 2005 20:59:30 +0100 Subject: RFE: php-mcrypt + libmcrypt Message-ID: <1106164770.6970.514.camel@serendipity.dogma.lan> Hi! Before writing a bugzilla RFE ticket I like to ask whether there are good reasons to not ship PHP with mcrypt support, means a php-mcrypt module and the required libmcrypt package. Are there such specific reasons? I know there is http://phprpms.sourceforge.net/mcrypt but think it would be worth to have it in the Core packages. Alexander -- Alexander Dalloz | Enger, Germany | new address - new key: 0xB366A773 legal statement: http://www.uni-x.org/legal.html Fedora GNU/Linux Core 2 (Tettnang) on Athlon kernel 2.6.10-1.9_FC2smp Serendipity 20:57:46 up 5 days, 4:19, load average: 0.74, 0.81, 0.66 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From mike at navi.cx Wed Jan 19 20:14:11 2005 From: mike at navi.cx (Mike Hearn) Date: Wed, 19 Jan 2005 20:14:11 +0000 Subject: Fedora Core 4 References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> <1105968445.31480.103.camel@erato.phig.org> <1105972254.19179.4.camel@stargrazer.home.awesomeplay.com> <1105976014.4673.18.camel@nexus.verbum.private> Message-ID: On Mon, 17 Jan 2005 10:33:34 -0500, Colin Walters wrote: > The policy package doesn't do any relabeling at the moment. This will > likely change though, because it does cause problems. When that occurs, > consideration will be given to preserving customized file contexts. At some point (after we release 1.0) I'd like to add some basic SELinux support to autopackage so as files are installed they are given some better context than whatever the default is (bearing in mind autopackage lets you install to any prefix so we can't rely on parent directory propagation). If we install some shared libs to say /opt/foobar/lib (or into $HOME) and then label the lib directory as system_u:object_r:lib_t and the DSOs inside as system_u:object_r:shlib_t is there some risk that the contexts would be deleted? Is there anything I can do to work with you guys on this? thanks -mike From walters at redhat.com Wed Jan 19 20:26:01 2005 From: walters at redhat.com (Colin Walters) Date: Wed, 19 Jan 2005 15:26:01 -0500 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> <1105968445.31480.103.camel@erato.phig.org> <1105972254.19179.4.camel@stargrazer.home.awesomeplay.com> <1105976014.4673.18.camel@nexus.verbum.private> Message-ID: <1106166361.8243.22.camel@nexus.verbum.private> On Wed, 2005-01-19 at 20:14 +0000, Mike Hearn wrote: > If we install some shared libs to say /opt/foobar/lib (or into $HOME) > and > then label the lib directory as system_u:object_r:lib_t and the DSOs > inside as system_u:object_r:shlib_t is there some risk that the > contexts > would be deleted? If a user runs 'fixfiles relabel' or does the "touch /.autorelabel;reboot", this will reset all unknown contexts to default_t. Right now it is not uncommon to tell users to do this on labeling problems. We've been talking about some solutions to this, essentially performing a more targeted relabeling automatically. But it needs careful thought, and the available RPM mechanisms don't make it easy. > Is there anything I can do to work with you guys on this? I'd suggest redirecting this discussion to fedora-selinux-list. From jwz at jwz.org Wed Jan 19 21:42:13 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Wed, 19 Jan 2005 13:42:13 -0800 Subject: RFC: Optimizing for 386 References: <3077b8a0050119082743fff58a@mail.gmail.com> <3khj1h$ghul9b@mxip07a.cluster1.charter.net> <20050119194928.GD1219319@hiwaay.net> Message-ID: <41EED435.3B0D8EF0@jwz.org> Chris Adams wrote: > > Some other RPMs have code that detects i386 vs. i686 vs. Athlon > (really "regular" vs. MMX/SSE/etc.) at runtime and uses the best > available. Just curious -- which packages are those? (Besides X and kernel.) -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From arjanv at redhat.com Wed Jan 19 21:49:43 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 19 Jan 2005 22:49:43 +0100 Subject: Improving security In-Reply-To: <416E5A76.4050906@hhs.nl> References: <416E5A76.4050906@hhs.nl> Message-ID: <1106171383.6310.210.camel@laptopd505.fenrus.org> > Stack Smash Protection sounds like a cool feature to me. I don't know > what the performance impact is, but as a developer even if it is to slow > to use by default I would love to have it intergrated into the gcc > shipped by Fedora to make debugging easier. well.. gcc in fc4 (well rawhide right now) has something that has a quite similar effect, with basically zero performance impact. Try it ;) > > PAX uses tricks to get a non executable stack, and assignes random > addresses to PIE executables, which Fedora already has in the form of > Exec Shield, good! But if I undertand it correctly PAX does more for > example also make data pages non executable, this might be something > worth looking into. Exec-Shield makes datapages also non-executable. There is very little practical difference between PAX and Exec-Shield protection wise. There are theoretical differences, mostly comming from a different viewpoint (Exec-Shield is about being as secure as possible without breaking things, while PaX does make the deliberate choice to break things. The difference is small, the things that "break" are rare. very rare.) The reason Exec-Shield does this is because the worst thing that can happen is to be too secure, so secure that all sysadmins just turn it off entirely. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjanv at redhat.com Wed Jan 19 21:51:27 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 19 Jan 2005 22:51:27 +0100 Subject: Improving security In-Reply-To: References: <416E5A76.4050906@hhs.nl> Message-ID: <1106171487.6310.212.camel@laptopd505.fenrus.org> > That being said, you have to understand that libraries are ALL PIC. > You lose NOTHING in libraries by going to PIE. All plug-ins to it also is utter pointless; PIE for a library means NOTHING. In fact it's IDENTICAL to PIC, which it already is -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seyman at wanadoo.fr Wed Jan 19 22:05:06 2005 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Wed, 19 Jan 2005 23:05:06 +0100 Subject: RFC: Optimizing for 386 In-Reply-To: <41EED435.3B0D8EF0@jwz.org> References: <3077b8a0050119082743fff58a@mail.gmail.com> <3khj1h$ghul9b@mxip07a.cluster1.charter.net> <20050119194928.GD1219319@hiwaay.net> <41EED435.3B0D8EF0@jwz.org> Message-ID: <20050119220506.GA9424@orient.maison.moi> On Wed, Jan 19, 2005 at 01:42:13PM -0800, Jamie Zawinski wrote: > > Just curious -- which packages are those? (Besides X and kernel.) IIRC, mplayer. Emmanuel From cmadams at hiwaay.net Wed Jan 19 22:11:02 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 19 Jan 2005 16:11:02 -0600 Subject: RFC: Optimizing for 386 In-Reply-To: <41EED435.3B0D8EF0@jwz.org> References: <3077b8a0050119082743fff58a@mail.gmail.com> <3khj1h$ghul9b@mxip07a.cluster1.charter.net> <20050119194928.GD1219319@hiwaay.net> <41EED435.3B0D8EF0@jwz.org> Message-ID: <20050119221102.GE1219319@hiwaay.net> Once upon a time, Jamie Zawinski said: > Chris Adams wrote: > > Some other RPMs have code that detects i386 vs. i686 vs. Athlon > > (really "regular" vs. MMX/SSE/etc.) at runtime and uses the best > > available. > > Just curious -- which packages are those? (Besides X and kernel.) I think some of the video related libraries do, but I don't know which right off. A quick check on my system (FC2 still) looks like: /usr/X11R6/lib/libOSMesa.so.4 checks for MMX, 3DNow!, SSE /usr/bin/gimp checks for MMX, 3DNow!, SSE /usr/bin/xmms may use MMX, 3DNow! /usr/lib/libFLAC.so.4 may use cmov, MMX, SSE, SSE2, 3DNow! /usr/lib/libSDL-1.2.so.0 may use MMX, SSE /usr/lib/libgstreamer-0.8.so may use MMX, 3DNow!, SSE /usr/lib/libasound.so.2 may use MMX Looking at libraries on my system, I also see special versions of some libraries: /lib/tls/libdb-4.2.so /usr/lib/tls/libdb_cxx-4.2.so /usr/lib/sse2/libgmp.so.3 /usr/lib/sse2/libgmpxx.so.3 /usr/lib/sse2/libmp.so.3 The tls libraries are different because of threading, but that is i686 related. I also see other things (from freshrpms and such) that are i386 arch but the library/binary has MMX/SSE/etc. detection code. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From kyrre at solution-forge.net Wed Jan 19 22:16:06 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 19 Jan 2005 23:16:06 +0100 Subject: RFC: Optimizing for 386 In-Reply-To: <3khdfd$heo20h@mxip04a.cluster1.charter.net> References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> Message-ID: <1106172965.2663.16.camel@localhost.localdomain> ons, 19.01.2005 kl. 17.08 skrev Joseph D. Wagner: > I can count the total number of people in the world who still use a 386 on the fingers of both of my hands. Why are we still catering to this small group of people? > > With the exception of the kernel and glibc, all RPM's are optimized for 386 architecture. This is a waste of system resources. Study after study shows that you can achieve a 10% - 40% performance improvement my optimizing code for a specific architecture. Windows XP may only be optimized for a Pentium, but by golly, at least the whole thing is optimized, not just the kernel and the C library. > > Just look at X. Is anyone seriously trying to get X to run on a 386? I can understand compiling the text-based programs, like bash, for 386. You can run a text-only box on a 386 just fine. Why do that for X? Why do that for GNOME, KDE, or any graphical program for that matter? > > I know that I can recompile of these program from the source code to achieve those optimizations. However, why should everyone who wants to optimize their systems have to go through that, just so a handful of people with 386 machines can run X out-of-the-box? Then, we have recompile all over again with the next RPM release. > > Why can't the few people who have a 386 be made to recompile X from sources to get it to run on there machines, so the rest of us can enjoy the performance boost from running optimized binaries? > > I think we seriously need to rethink the distribution strategy. At the very least, all graphical programs should be optimized for i686. > > Joseph D. Wagner > Actually, i don't think the CPU is the biggest slowdown for fedora. From my personal experience - memory (RAM) is a bigger issue. I have a 200 mhz pentium 2 running fedora 3, full GUI and everything, and while i ain't claiming that it is hyperfast, its certainly usable. It has 384 MB of RAM. OTOH, i have seen much "stronger" pc's (counting on CPU - from 600 mhz to a bit over 1 GHz) with less memory (256 MB or 180 MB) be slow/barely usable. Especially when starting up the big memory-eater - OpenOffice. Which sometimes takes as long as 1-2 minutes to load. BAD. So maybe this is more of a problem - RAM usage and *startup times of apps*? When it comes to startup times - how difficult would it be to (given enough RAM - autodetection+manual config) preload OpenOffice and Firefox on OS start, so it would just "be there" (like both of them are when first started) when the user clicks the nice, little icon? Something that could be done to ease up OO memory usage, is make it stop loading a ton of dictionaryes. Well, it has certain upsides. Now i know that many mispelled norwegian words are correct in Hungarian... I have heard this is a goal for FC4 (splitting up OOi18n) - am i correct? Kyrre From nutello at sweetness.com Wed Jan 19 22:25:07 2005 From: nutello at sweetness.com (Rudi Chiarito) Date: Wed, 19 Jan 2005 23:25:07 +0100 Subject: Fedora Core 4 In-Reply-To: <20050119165153.GG6804@neu.physik.fu-berlin.de> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <20050119165153.GG6804@neu.physik.fu-berlin.de> Message-ID: <20050119222507.GB5234@plain.rackshack.net> On Wed, Jan 19, 2005 at 05:51:53PM +0100, Axel Thimm wrote: > Sometimes I'm setting up multilib-free systems (e.g. no overlapping > packages at all), and a yum install foo (w/o adding an arch) will pull > in both x86_64 and i386 packages. I think that was a problem with yum 2.1.11 and it has been fixed in the latest 2.1.12 errata. I remember seeing two FC3 machines behaving differently in this regard, even if they had a mostly identical setup. The only difference was that one of them had a more recent yum from Raw Hide. -- Rudi From seyman at wanadoo.fr Wed Jan 19 22:40:36 2005 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Wed, 19 Jan 2005 23:40:36 +0100 Subject: RFC: Optimizing for 386 In-Reply-To: <1106172965.2663.16.camel@localhost.localdomain> References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> <1106172965.2663.16.camel@localhost.localdomain> Message-ID: <20050119224036.GA9537@orient.maison.moi> On Wed, Jan 19, 2005 at 11:16:06PM +0100, Kyrre Ness Sjobak wrote: > > Actually, i don't think the CPU is the biggest slowdown for fedora. From > my personal experience - memory (RAM) is a bigger issue. I have a 200 Same here, really. > I have heard this is a goal for FC4 (splitting up OOi18n) - am i > correct? Yes, it's bugzilla-ed but I can't remember the bug_id off the top of my head. Emmanuel From jon at jonshouse.co.uk Wed Jan 19 22:43:33 2005 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Wed, 19 Jan 2005 22:43:33 +0000 Subject: XDMCP Core 3 Message-ID: <1106174613.5881.2524.camel@jonspc> Is XDMCP, remote X bust in core 3 ? I've tried the gui configuration for tool gdm. The machine has no firewall enabled - all I get the "gdm_child_action: Aborting display jonspc:1" in the log ? I've googled for this message and I get the same useless file over and over again with no comments that help me. Before somebody cries this is the wrong list, I disagree - if the GUI tool in core3 (and soon core 4) pretends you can enabled XDMCP and remote greeter then it should work, its getting a bit rarer - but it ain't dead yet ! Thanks, Jon From elanthis at awesomeplay.com Thu Jan 20 00:07:20 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Wed, 19 Jan 2005 19:07:20 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <1106172965.2663.16.camel@localhost.localdomain> References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> <1106172965.2663.16.camel@localhost.localdomain> Message-ID: <1106179640.5599.6.camel@stargrazer.home.awesomeplay.com> On Wed, 2005-01-19 at 23:16 +0100, Kyrre Ness Sjobak wrote: > ons, 19.01.2005 kl. 17.08 skrev Joseph D. Wagner: > > I can count the total number of people in the world who still use a 386 on the fingers of both of my hands. Why are we still catering to this small group of people? > > > > With the exception of the kernel and glibc, all RPM's are optimized for 386 architecture. This is a waste of system resources. Study after study shows that you can achieve a 10% - 40% performance improvement my optimizing code for a specific architecture. Windows XP may only be optimized for a Pentium, but by golly, at least the whole thing is optimized, not just the kernel and the C library. > > > > Just look at X. Is anyone seriously trying to get X to run on a 386? I can understand compiling the text-based programs, like bash, for 386. You can run a text-only box on a 386 just fine. Why do that for X? Why do that for GNOME, KDE, or any graphical program for that matter? > > > > I know that I can recompile of these program from the source code to achieve those optimizations. However, why should everyone who wants to optimize their systems have to go through that, just so a handful of people with 386 machines can run X out-of-the-box? Then, we have recompile all over again with the next RPM release. > > > > Why can't the few people who have a 386 be made to recompile X from sources to get it to run on there machines, so the rest of us can enjoy the performance boost from running optimized binaries? > > > > I think we seriously need to rethink the distribution strategy. At the very least, all graphical programs should be optimized for i686. > > > > Joseph D. Wagner > > > > Actually, i don't think the CPU is the biggest slowdown for fedora. From > my personal experience - memory (RAM) is a bigger issue. I have a 200 > mhz pentium 2 running fedora 3, full GUI and everything, and while i > ain't claiming that it is hyperfast, its certainly usable. It has 384 MB > of RAM. Disk access is also pretty important. I've started some "simple" apps using strace and watched as screen after screen after screen after screen of open/stat/etc calls were made. GUI apps with all their icons and external resource files and image plugins and so on are the worst. The GTK+ folks are working on solutions in some cases (like icon loading), but there's a lot that could be done by just slimming down what apps need and how they go about getting those needs. (Take a JAR file - load the whole thing in RAM and get your code and data with only loading one file off the disk. I wonder how well that could work for normal executables?) > When it comes to startup times - how difficult would it be to (given > enough RAM - autodetection+manual config) preload OpenOffice and Firefox > on OS start, so it would just "be there" (like both of them are when > first started) when the user clicks the nice, little icon? I don't really believe much in preloading. If you're a company CEO that doesn't do anything other than make presentations and fire off a memo here and there, maybe preloading works. In general, though, spending startup time preloading OOo just to have Mozilla kick it back out again if you start Mozilla first, just isn't going to help - the preloading only helps once and only if its the first large app you run. Better to just slim down memory usage. Or go buy more RAM, it's cheap. Seriously, I've got a 512MB chip as a keychain ornament. ~_^ > > Something that could be done to ease up OO memory usage, is make it stop > loading a ton of dictionaryes. Well, it has certain upsides. Now i know > that many mispelled norwegian words are correct in Hungarian... > I have heard this is a goal for FC4 (splitting up OOi18n) - am i > correct? > > Kyrre > From alan at redhat.com Thu Jan 20 00:10:39 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Jan 2005 19:10:39 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <3khdfd$heo20h@mxip04a.cluster1.charter.net> References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> Message-ID: <20050120001039.GB18174@devserv.devel.redhat.com> On Wed, Jan 19, 2005 at 10:08:22AM -0600, Joseph D. Wagner wrote: > With the exception of the kernel and glibc, all RPM's are optimized for 386 architecture. This is a waste of system resources. Study after study shows that you can achieve a 10% - 40% performance improvement my optimizing code for a specific architecture. Windows XP may only be optimized for a Pentium, but by golly, at least the whole thing is optimized, not just the kernel and the C library. > The number of people who don't check the archives first is regrettably not a handful ;) The files are currently mostly PIV optimised From alan at redhat.com Thu Jan 20 00:12:28 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Jan 2005 19:12:28 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <3khdg6$gpoloe@mxip03a.cluster1.charter.net> References: <20050119160944.GA25782@jadzia.bu.edu> <3khdg6$gpoloe@mxip03a.cluster1.charter.net> Message-ID: <20050120001228.GC18174@devserv.devel.redhat.com> On Wed, Jan 19, 2005 at 10:26:51AM -0600, Joseph D. Wagner wrote: > > They're optimized for pentium4, but use the i386 instruction set. > > There are instructions which have come out since the 386, like MMX, that could improve the performance of programs. In this case, graphics programs. Why should my graphics programs suffer because some fool is running a 20 year old computer? MMX using apps all check for MMX v 3Dnow v SSE already and have too. The instructions in question are not compiler generated as they are specialist > If that many people are crying for it, maybe it should be done. Lots of people thought the earth was flat and cried for the death of those who disagred too From alan at redhat.com Thu Jan 20 00:16:39 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Jan 2005 19:16:39 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <1106155456.1952.45.camel@localhost.localdomain> References: <20050119171047.C15870@ryoko.camperquake.de> <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <20050119170235.GV10340@devserv.devel.redhat.com> <1106155456.1952.45.camel@localhost.localdomain> Message-ID: <20050120001639.GD18174@devserv.devel.redhat.com> On Wed, Jan 19, 2005 at 06:24:16PM +0100, Peter Backlund wrote: > Has anyone been testing -Os (optimize for size) instead of -O2 on any > greater scale? Fitting as much as possible in L1-cache is a great way to > obtain high performance. I run with almost all of gnome -Os and its faster where I can do tests - but its hard to be scientific From alan at redhat.com Thu Jan 20 00:26:09 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Jan 2005 19:26:09 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <41EED435.3B0D8EF0@jwz.org> References: <3077b8a0050119082743fff58a@mail.gmail.com> <3khj1h$ghul9b@mxip07a.cluster1.charter.net> <20050119194928.GD1219319@hiwaay.net> <41EED435.3B0D8EF0@jwz.org> Message-ID: <20050120002609.GF18174@devserv.devel.redhat.com> On Wed, Jan 19, 2005 at 01:42:13PM -0800, Jamie Zawinski wrote: > Chris Adams wrote: > > > > Some other RPMs have code that detects i386 vs. i686 vs. Athlon > > (really "regular" vs. MMX/SSE/etc.) at runtime and uses the best > > available. > > Just curious -- which packages are those? (Besides X and kernel.) Most of the video and audio apps do this, Mesa does this for 3D and can make good use of 3DNow! From alan at redhat.com Thu Jan 20 00:28:05 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 19 Jan 2005 19:28:05 -0500 Subject: XDMCP Core 3 In-Reply-To: <1106174613.5881.2524.camel@jonspc> References: <1106174613.5881.2524.camel@jonspc> Message-ID: <20050120002805.GG18174@devserv.devel.redhat.com> On Wed, Jan 19, 2005 at 10:43:33PM +0000, Jonathan Andrews wrote: > Is XDMCP, remote X bust in core 3 ? > > I've tried the gui configuration for tool gdm. The machine has no > firewall enabled - all I get the "gdm_child_action: Aborting display > jonspc:1" in the log ? Turn on gdm debug. Get traces. > remote greeter then it should work, its getting a bit rarer - but it > ain't dead yet ! Works for me with FC *but* I've had horrible problems if you get any forward/reverse DNS mismatchs From jon at jonshouse.co.uk Thu Jan 20 00:54:40 2005 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Thu, 20 Jan 2005 00:54:40 +0000 Subject: XDMCP Core 3 In-Reply-To: <20050120002805.GG18174@devserv.devel.redhat.com> References: <1106174613.5881.2524.camel@jonspc> <20050120002805.GG18174@devserv.devel.redhat.com> Message-ID: <1106182480.5881.2538.camel@jonspc> On Thu, 2005-01-20 at 00:28, Alan Cox wrote: > On Wed, Jan 19, 2005 at 10:43:33PM +0000, Jonathan Andrews wrote: > > Is XDMCP, remote X bust in core 3 ? > > > > I've tried the gui configuration for tool gdm. The machine has no > > firewall enabled - all I get the "gdm_child_action: Aborting display > > jonspc:1" in the log ? > > Turn on gdm debug. Get traces. > > > remote greeter then it should work, its getting a bit rarer - but it > > ain't dead yet ! > > Works for me with FC *but* I've had horrible problems if you get any > forward/reverse DNS mismatchs That was it ! Many thanks :-) The name resolver behaviour must have changed between core 2 and core 3? Im using dnsmasq for the LAN, the server configuration is unchanged - it was working against RH9,core1 and core 2 ! http://thekelleys.org.uk/dnsmasq/doc.html I don't understand this nameresolver problem. Dig and nslookup say all is fine, but ping says no - unless the name has an extra "." I don't expect a tutorial, but which end is wrong, the name resolver client in core 3 or the masqurading dns server ? Cheers, Jon [root at localhost ~]# dig jonspc ; <<>> DiG 9.2.4 <<>> jonspc ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62171 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;jonspc. IN A ;; ANSWER SECTION: jonspc. 0 IN A 10.10.10.5 ;; Query time: 1 msec ;; SERVER: 10.10.10.80#53(10.10.10.80) ;; WHEN: Thu Jan 20 00:46:41 2005 ;; MSG SIZE rcvd: 40 [root at localhost ~]# ping jonspc ping: unknown host jonspc [root at localhost ~]# ping jonspc. PING jonspc (10.10.10.5) 56(84) bytes of data. 64 bytes from jonspc (10.10.10.5): icmp_seq=0 ttl=64 time=0.126 ms 64 bytes from jonspc (10.10.10.5): icmp_seq=1 ttl=64 time=0.176 ms --- jonspc ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 0.126/0.151/0.176/0.025 ms, pipe 2 [root at localhost ~]# nslookup jonspc Server: 10.10.10.80 Address: 10.10.10.80#53 Name: jonspc Address: 10.10.10.5 [root at localhost ~]# From dag at wieers.com Thu Jan 20 02:48:26 2005 From: dag at wieers.com (Dag Wieers) Date: Thu, 20 Jan 2005 03:48:26 +0100 (CET) Subject: Fedora Core 4 In-Reply-To: <604aa791050119080054ff3ca4@mail.gmail.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119152425.34e064f1@nausicaa.camperquake.de> <604aa791050119070644bbb0b7@mail.gmail.com> <20050119165449.A15870@ryoko.camperquake.de> <604aa791050119080054ff3ca4@mail.gmail.com> Message-ID: On Wed, 19 Jan 2005, Jeff Spaleta wrote: > On Wed, 19 Jan 2005 16:54:49 +0100, Ralf Ertzinger > wrote: > > I am running rawhide with smart. Enabled repos are fc-devel at 0, freshrpms at 0, > > dag at -5 newrpms at -5, atrpms-stable at -10, atrpms-good at -10, atrpms-bleeding at -20. > > > > It's heaven. > > Maybe to you... but i have sincere doubts that using smart is helping > to identify real packaging problems that exist. Has smart helped you > identify and report any rawhide packaging bugs? I don't think smart is intended to be a tool to identify real packaging problems. But there's a nice option that prints all unsatisfied dependencies. And I hope we can extend that dialog with more details of problems. In fact this dialog has helped Dries and me to improve our repository and fix a number of issues 3 days after Smart was released. Smart was also able to tell what old packages were still available that had issues we already fixed. Apart from that, I don't think it's good behaviour to bail out if there is a packaging problem. People may miss important updates just because somewhere, someone made a mistake. It could even be due to a mirror inconsistency, not something that can be fixed by a packager anyway. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From skvidal at phy.duke.edu Thu Jan 20 03:05:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 19 Jan 2005 22:05:34 -0500 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119152425.34e064f1@nausicaa.camperquake.de> <604aa791050119070644bbb0b7@mail.gmail.com> <20050119165449.A15870@ryoko.camperquake.de> <604aa791050119080054ff3ca4@mail.gmail.com> Message-ID: <1106190334.21334.4.camel@cutter> On Thu, 2005-01-20 at 03:48 +0100, Dag Wieers wrote: > On Wed, 19 Jan 2005, Jeff Spaleta wrote: > > > On Wed, 19 Jan 2005 16:54:49 +0100, Ralf Ertzinger > > wrote: > > > I am running rawhide with smart. Enabled repos are fc-devel at 0, freshrpms at 0, > > > dag at -5 newrpms at -5, atrpms-stable at -10, atrpms-good at -10, atrpms-bleeding at -20. > > > > > > It's heaven. > > > > Maybe to you... but i have sincere doubts that using smart is helping > > to identify real packaging problems that exist. Has smart helped you > > identify and report any rawhide packaging bugs? > > I don't think smart is intended to be a tool to identify real packaging > problems. But there's a nice option that prints all unsatisfied > dependencies. And I hope we can extend that dialog with more details of > problems. > > In fact this dialog has helped Dries and me to improve our repository and > fix a number of issues 3 days after Smart was released. Smart was also > able to tell what old packages were still available that had issues we > already fixed. > > Apart from that, I don't think it's good behaviour to bail out if there is > a packaging problem. People may miss important updates just because > somewhere, someone made a mistake. It could even be due to a mirror > inconsistency, not something that can be fixed by a packager anyway. > I think the situation where it exits with all the problems listed is better than cheerily moving along and seemingly finishing completely even though not all updates have been applied. -sv From dag at wieers.com Thu Jan 20 03:12:16 2005 From: dag at wieers.com (Dag Wieers) Date: Thu, 20 Jan 2005 04:12:16 +0100 (CET) Subject: Fedora Core 4 In-Reply-To: <604aa791050119083055fb42bc@mail.gmail.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119152425.34e064f1@nausicaa.camperquake.de> <604aa791050119070644bbb0b7@mail.gmail.com> <20050119165449.A15870@ryoko.camperquake.de> <604aa791050119080054ff3ca4@mail.gmail.com> <20050119170911.B15870@ryoko.camperquake.de> <604aa791050119083055fb42bc@mail.gmail.com> Message-ID: On Wed, 19 Jan 2005, Jeff Spaleta wrote: > On Wed, 19 Jan 2005 17:09:11 +0100, Ralf Ertzinger > wrote: > > And just for the record: I read what it is trying to do before committing, > > and I know that downgrading or suspicious removal usually means that there > > is a bug somewhere. > > I'm not concerned about people like you or I... people who could be > considered technically proficient and who have experience > troubleshooting problems that are the result of packaging errors. I am > very concerned about what happens if/when novice users begin to use > smart as their primary tool. I admit that for advanced users who > understand when something is 'suspicious' this approach can be very > powerful... but for the 90% of the userbase who don't have a good > grasp as to when something is suspicious and when it is not.. this can > lead to problems. Especially if the advanced users using the same > tool.. aren't being encourage to file bugs. The best way to encourage > the filing of bugs is to stop execution and throw an error message. I bet you will get more rants than bug reports. Especially if important security fixes are in the pipeline and they are not installed because of a single unrelated problem. I wouldn't want to expose my family to packaging problems. > There is a better way in my head, involving keeping up with 'channel > policies' instead of 'priorities'.. i just have to find the words and > the time to articulate it. A way that allows smart to do exactly what > it does now when it needs to deal with overlapping addon repos when > you want to install something new... but flags reportable problems > when a channel or group of channels aren't self-consistent when they > should be. Smart has this, look in smart-gui at: Edit > Check All Packages -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From dag at wieers.com Thu Jan 20 03:21:30 2005 From: dag at wieers.com (Dag Wieers) Date: Thu, 20 Jan 2005 04:21:30 +0100 (CET) Subject: Fedora Core 4 In-Reply-To: <1106190334.21334.4.camel@cutter> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119152425.34e064f1@nausicaa.camperquake.de> <604aa791050119070644bbb0b7@mail.gmail.com> <20050119165449.A15870@ryoko.camperquake.de> <604aa791050119080054ff3ca4@mail.gmail.com> <1106190334.21334.4.camel@cutter> Message-ID: On Wed, 19 Jan 2005, seth vidal wrote: > On Thu, 2005-01-20 at 03:48 +0100, Dag Wieers wrote: > > On Wed, 19 Jan 2005, Jeff Spaleta wrote: > > > > > On Wed, 19 Jan 2005 16:54:49 +0100, Ralf Ertzinger > > > wrote: > > > > I am running rawhide with smart. Enabled repos are fc-devel at 0, freshrpms at 0, > > > > dag at -5 newrpms at -5, atrpms-stable at -10, atrpms-good at -10, atrpms-bleeding at -20. > > > > > > > > It's heaven. > > > > > > Maybe to you... but i have sincere doubts that using smart is helping > > > to identify real packaging problems that exist. Has smart helped you > > > identify and report any rawhide packaging bugs? > > > > I don't think smart is intended to be a tool to identify real packaging > > problems. But there's a nice option that prints all unsatisfied > > dependencies. And I hope we can extend that dialog with more details of > > problems. > > > > In fact this dialog has helped Dries and me to improve our repository and > > fix a number of issues 3 days after Smart was released. Smart was also > > able to tell what old packages were still available that had issues we > > already fixed. > > > > Apart from that, I don't think it's good behaviour to bail out if there is > > a packaging problem. People may miss important updates just because > > somewhere, someone made a mistake. It could even be due to a mirror > > inconsistency, not something that can be fixed by a packager anyway. > > I think the situation where it exits with all the problems listed is > better than cheerily moving along and seemingly finishing completely > even though not all updates have been applied. I beg to differ. Security updates may not get installed from the Core updates because Extras has a problem that could be mirror-related. I did not say that keeping things silent is the way to go, but bailing out because of a single problem is imo not a good idea. By default I would not want to confront my family with issues like that, things they wouldn't know how to handle anyway. Also people that don't know what it means often get a wrong perception. But we do not have to agree on this, there's room for different package managers. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From dag at wieers.com Thu Jan 20 05:36:00 2005 From: dag at wieers.com (Dag Wieers) Date: Thu, 20 Jan 2005 06:36:00 +0100 (CET) Subject: Fedora Core 4 In-Reply-To: <604aa7910501191939a550a31@mail.gmail.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119152425.34e064f1@nausicaa.camperquake.de> <604aa791050119070644bbb0b7@mail.gmail.com> <20050119165449.A15870@ryoko.camperquake.de> <604aa791050119080054ff3ca4@mail.gmail.com> <20050119170911.B15870@ryoko.camperquake.de> <604aa791050119083055fb42bc@mail.gmail.com> <604aa7910501191939a550a31@mail.gmail.com> Message-ID: On Wed, 19 Jan 2005, Jeff Spaleta wrote: > On Thu, 20 Jan 2005 04:12:16 +0100 (CET), Dag Wieers wrote: > > I bet you will get more rants than bug reports. Especially if important > > security fixes are in the pipeline and they are not installed because of a > > single unrelated problem. > > I'm not talking about unrelated problems... or stopping the full set > of unrelated transactions cold because of one package problem. I'm > trying to confine my arguments to the scope of how the broken dep > wireless-tools update should be working... without the extra > complication of additional unrelated transactions. Yes, and you fail to indicate where Smart does it wrong :) Smart actually does what you said it should be doing. > What I am arguing is that there needs to be an ecoding of an > understanding of inherent channel policy and inherent inter-channel > policy to avoid presenting transactions that are clearly only going to > be presented to the user if there has been a packaging error. This is > orthogonal to channel priorities or per-package priorties. We know.. > as competent users.. that updates-releases should never implicitly > require a removal of a Core package. We know this because this is a > policy of how updates-released is defined. The tools like smart > should be able to codify that knowledge so that clearly contrary > transactions will not be presented to the user. In the case of wireless-tools, there would not be any removals if you just do an upgrade. The smart-gui would not upgrade to a newer wireless-tools because it considers the cost of the removals more important for not upgrading, than the gain of a newer wireless-tools. Unless, of course, you specify that you want to upgrade wireless-tools _specifically_. In that case smart-gui will show you exactly _what_ it will do and _why_ it will do that. (The removals) > I as a user should not be shown a transaction that includes the removal > of a NetworkManager and kdenetwork from Core because of the busted > wireless-tools update from updates-released. Exactly, smart-gui would not show that transaction if you update. It would only show you when you select the newer wireless-tools despite what it suggests. Did you try this or is this based on how you think Smart works ? > > Smart has this, look in smart-gui at: > > > > Edit > Check All Packages > > This does not appear to be what I am trying to describe at all. > Perhaps if you give me a a few sentences as to what I'm actually > seeing in this dialog this might clear up my confusion. Jeff, you removed what you said. Actually what you said did not describe what you wanted, it just gave a general disagreement. Here is what you said and what I commented on: > > > There is a better way in my head, involving keeping up with 'channel > > > policies' instead of 'priorities'.. i just have to find the words > > > and the time to articulate it. A way that allows smart to do exactly what > > > it does now when it needs to deal with overlapping addon repos when > > > you want to install something new... but flags reportable problems > > > when a channel or group of channels aren't self-consistent when they > > > should be. I commented on the self-consistency. The dialog I talked about does exactly that. It shows what packages have unresolved dependencies. Sure it can be improved, send your suggestions to Gustavo when you succeed in formulating them. > The dialog certaintly didn't notice the wireless-tools update > deficiency afaict. I certaintly can't use that dialog to ask > questions like 'Are there any packages in updates-released that > require the removal of Core packages to be installed?' Any older package could be causing the removal of a package that requires the newer packager. So that definition would not be good. What would be useful though, and I'm certainly going to ask Gustavo this, is that this dialog should show which newer versions would cause other newer versions to be uninstalled. (Maybe a special debug-menu is in order) (In the pretense that a newer package is introduced with the sole aim to become updated, because with Smart you could be introducing an older package, to fix a situation that RPM fails to detect, and keep the new one in the repo :)) That's where Smart differs, it does not only take the E-V-R into account. It does not try to force a new version on to you because it happens to be available, it looks at what cost. And I understand the uncomfortable feeling of this seemingly undeterministic behaviour, but it works. And you can make use of this cleverness if you want to mix repositories. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From byte at aeon.com.my Thu Jan 20 06:08:40 2005 From: byte at aeon.com.my (Colin Charles) Date: Thu, 20 Jan 2005 14:08:40 +0800 Subject: Fedora Core 4 In-Reply-To: References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105752042.4145.7.camel@localhost.localdomain> <1105791903.17504.11.camel@rh-ibm-t41> <1105952671.9354.6.camel@sheol.homelinux.org> <1105963786.9356.12.camel@sheol.homelinux.org> Message-ID: <1106201320.4092.110.camel@localhost.localdomain> On Mon, 2005-01-17 at 17:46 +0530, Rahul Sundaram wrote: > > I am not sure adding java dependencies to openoffice is a good idea > but gcj is a saving grace (hopefully) OpenOffice.org always has had dependencies on Java; now its just Base that might depend on hsqldb. Its an almost certainty, as the other useful option is libmysqld (with a license change) http://www.bytebot.net/blog/archives/2004/12/21/ooo-is-still-free-it- just-has-a-lot-of-java-depends (thats got a mostly-complete-list of the java depends) -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From dag at wieers.com Thu Jan 20 07:36:14 2005 From: dag at wieers.com (Dag Wieers) Date: Thu, 20 Jan 2005 08:36:14 +0100 (CET) Subject: RFC: Optimizing for 386 In-Reply-To: <20050119221102.GE1219319@hiwaay.net> References: <3077b8a0050119082743fff58a@mail.gmail.com> <3khj1h$ghul9b@mxip07a.cluster1.charter.net> <20050119194928.GD1219319@hiwaay.net> <41EED435.3B0D8EF0@jwz.org> <20050119221102.GE1219319@hiwaay.net> Message-ID: On Wed, 19 Jan 2005, Chris Adams wrote: > Once upon a time, Jamie Zawinski said: > > Chris Adams wrote: > > > Some other RPMs have code that detects i386 vs. i686 vs. Athlon > > > (really "regular" vs. MMX/SSE/etc.) at runtime and uses the best > > > available. > > > > Just curious -- which packages are those? (Besides X and kernel.) > > I think some of the video related libraries do, but I don't know which > right off. A quick check on my system (FC2 still) looks like: > > /usr/X11R6/lib/libOSMesa.so.4 checks for MMX, 3DNow!, SSE > /usr/bin/gimp checks for MMX, 3DNow!, SSE > /usr/bin/xmms may use MMX, 3DNow! > /usr/lib/libFLAC.so.4 may use cmov, MMX, SSE, SSE2, 3DNow! > /usr/lib/libSDL-1.2.so.0 may use MMX, SSE > /usr/lib/libgstreamer-0.8.so may use MMX, 3DNow!, SSE > /usr/lib/libasound.so.2 may use MMX I'm wondering, did you run a command to get such a list ? -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From markmc at redhat.com Thu Jan 20 08:14:21 2005 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 20 Jan 2005 08:14:21 +0000 Subject: XDMCP Core 3 In-Reply-To: <1106174613.5881.2524.camel@jonspc> References: <1106174613.5881.2524.camel@jonspc> Message-ID: <1106208861.32395.4.camel@blaa> Hi, On Wed, 2005-01-19 at 22:43 +0000, Jonathan Andrews wrote: > Is XDMCP, remote X bust in core 3 ? I was using it not so long ago and it was working fine. > I've tried the gui configuration for tool gdm. The machine has no > firewall enabled - all I get the "gdm_child_action: Aborting display > jonspc:1" in the log ? I'm suprised that's the only message you get - a glance at the code suggests if you're getting this error message (which is from the master) you should be getting another message from the slave. Anyway, as Alan says - switch on gdm_debug and it'll help diagnose the problem. Cheers, Mark. From caolanm at redhat.com Thu Jan 20 08:51:50 2005 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 20 Jan 2005 08:51:50 +0000 Subject: RFC: Optimizing for 386 In-Reply-To: <20050120001639.GD18174@devserv.devel.redhat.com> References: <20050119171047.C15870@ryoko.camperquake.de> <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <20050119170235.GV10340@devserv.devel.redhat.com> <1106155456.1952.45.camel@localhost.localdomain> <20050120001639.GD18174@devserv.devel.redhat.com> Message-ID: <1106211110.9780.6.camel@sheol.homelinux.org> On Wed, 2005-01-19 at 19:16 -0500, Alan Cox wrote: > On Wed, Jan 19, 2005 at 06:24:16PM +0100, Peter Backlund wrote: > > Has anyone been testing -Os (optimize for size) instead of -O2 on any > > greater scale? Fitting as much as possible in L1-cache is a great way to > > obtain high performance. > > I run with almost all of gnome -Os and its faster where I can do tests - but > its hard to be scientific On the OOo front, the compile flags for 2.0 will be/should be "-Os -fno-strict-aliasing" the strict aliasing is apparently why 1.1.X becomes unstable when compiled just with -Os. C. From caolanm at redhat.com Thu Jan 20 08:55:48 2005 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 20 Jan 2005 08:55:48 +0000 Subject: RFC: Optimizing for 386 In-Reply-To: <1106172965.2663.16.camel@localhost.localdomain> References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> <1106172965.2663.16.camel@localhost.localdomain> Message-ID: <1106211348.9780.11.camel@sheol.homelinux.org> On Wed, 2005-01-19 at 23:16 +0100, Kyrre Ness Sjobak wrote: > When it comes to startup times - how difficult would it be to (given > enough RAM - autodetection+manual config) preload OpenOffice and Firefox > on OS start, so it would just "be there" (like both of them are when > first started) when the user clicks the nice, little icon? Actually take a look at /usr/lib/ooo-1.1/soffice and its use of its own "pagein" program to prime the diskcache with the OOo libs. You could play around with calling pagein from your desktop login or other places. C. From iago.rubio at hispalinux.es Thu Jan 20 09:38:53 2005 From: iago.rubio at hispalinux.es (Iago Rubio) Date: Thu, 20 Jan 2005 10:38:53 +0100 Subject: RFC: Optimizing for 386 In-Reply-To: <1106172965.2663.16.camel@localhost.localdomain> References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> <1106172965.2663.16.camel@localhost.localdomain> Message-ID: <1106213932.29800.29.camel@speedy.iagorubio.net> On Wed, 2005-01-19 at 23:16, Kyrre Ness Sjobak wrote: > Actually, i don't think the CPU is the biggest slowdown for fedora. From > my personal experience - memory (RAM) is a bigger issue. I have a 200 > mhz pentium 2 running fedora 3, full GUI and everything, and while i > ain't claiming that it is hyperfast, its certainly usable. It has 384 MB > of RAM. > > OTOH, i have seen much "stronger" pc's (counting on CPU - from 600 mhz > to a bit over 1 GHz) with less memory (256 MB or 180 MB) be slow/barely > usable. Especially when starting up the big memory-eater - OpenOffice. I've had FC3 running on a p233 with 64 Mb and Gnome, and it was usable if you avoided to open a huge bunch of X apps at the same time. Of course I didn't used OO in this box - abiword eats less resources - and no daemon was runing in the background. The system was capable of normal desktop use: surfing the net, using mail apps, writing docs and such. I Also tried xfce in this box and it's a bit faster, seems less memory hungry that Gnome, and better suited for low end machines. Right now this machine is running RHEL4 beta and Gnome with success. May be the stop point is not FC3 resources consuming but OO's :) Best regards. -- Iago Rubio From d.lesca at solinos.it Thu Jan 20 09:42:51 2005 From: d.lesca at solinos.it (Dario Lesca) Date: Thu, 20 Jan 2005 10:42:51 +0100 Subject: HowTo read/write /dev/port from a user not root Message-ID: <1106214171.2820.115.camel@lesca.home.solinos.it> Hi, is possible read and write on /dev/port via a normal user (not root)? > sh-3.00$ ls -l /dev/port > crw-rw-rw- 1 root kmem 1, 4 29 dic 10:38 /dev/port > sh-3.00$ cat -v /dev/port > cat: /dev/port: Operation not permitted > sh-3.00$ Many thanks -- Dario Lesca From arjanv at redhat.com Thu Jan 20 09:44:34 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 20 Jan 2005 10:44:34 +0100 Subject: HowTo read/write /dev/port from a user not root In-Reply-To: <1106214171.2820.115.camel@lesca.home.solinos.it> References: <1106214171.2820.115.camel@lesca.home.solinos.it> Message-ID: <1106214274.6742.11.camel@laptopd505.fenrus.org> On Thu, 2005-01-20 at 10:42 +0100, Dario Lesca wrote: > Hi, is possible read and write on /dev/port via a normal user (not > root)? it should not be possible; since when I have access to /dev/port as normal user I can easily get root rights ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From harald at redhat.com Thu Jan 20 10:12:55 2005 From: harald at redhat.com (Harald Hoyer) Date: Thu, 20 Jan 2005 11:12:55 +0100 Subject: Fedora Core 4 In-Reply-To: <1106155644.15549.27.camel@one.myworld> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119161939.GA11983@burma.localdomain> <1106152574.15549.19.camel@one.myworld> <20050119164609.GC11983@burma.localdomain> <1106155644.15549.27.camel@one.myworld> Message-ID: <41EF8427.6000908@redhat.com> F?liciano Matias wrote: > "glibc-gconvdata-1: > glibc-gconvdata-0:" is false. false... this is true Epoch was introduced to let rpm cope with "downgrades". So doing a general "update" and introducing a higher epoch makes a "downgrade" possible. EVR - epoch:version-release is compared and a higher epoch for package A means its EVR is higher. From rahulsundaram at gmail.com Thu Jan 20 10:23:18 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Thu, 20 Jan 2005 15:53:18 +0530 Subject: RFC: Optimizing for 386 In-Reply-To: <3k70kp$m0vvfm@mxip16a.cluster1.charter.net> References: <3k70kp$m0vvfm@mxip16a.cluster1.charter.net> Message-ID: Hi > > You could have spent some time counting the huge numbers of people who are asking for the same thing I am asking for, and perhaps a little time working towards those ends. unfortunately a large number of ignorant people exist. we already know that. Fedora is slow for a good number of people. they are looking for ways to improve that but compiler optimisations arent one of them according to knowledgable developers -- Regards, Rahul Sundaram From feliciano.matias at free.fr Thu Jan 20 10:42:35 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Thu, 20 Jan 2005 11:42:35 +0100 Subject: Fedora Core 4 In-Reply-To: <41EF8427.6000908@redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119161939.GA11983@burma.localdomain> <1106152574.15549.19.camel@one.myworld> <20050119164609.GC11983@burma.localdomain> <1106155644.15549.27.camel@one.myworld> <41EF8427.6000908@redhat.com> Message-ID: <1106217755.20938.3.camel@one.myworld> Le jeudi 20 janvier 2005 ? 11:12 +0100, Harald Hoyer a ?crit : > F?liciano Matias wrote: > > "glibc-gconvdata-1: > glibc-gconvdata-0:" is false. > > false... this is true Sorry ... [] <= -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jon at jonshouse.co.uk Thu Jan 20 11:20:07 2005 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Thu, 20 Jan 2005 11:20:07 +0000 Subject: XDMCP Core 3 In-Reply-To: <1106208861.32395.4.camel@blaa> References: <1106174613.5881.2524.camel@jonspc> <1106208861.32395.4.camel@blaa> Message-ID: <1106220007.31944.3.camel@jonspc> On Thu, 2005-01-20 at 08:14, Mark McLoughlin wrote: > Hi, > > On Wed, 2005-01-19 at 22:43 +0000, Jonathan Andrews wrote: > > Is XDMCP, remote X bust in core 3 ? > > I was using it not so long ago and it was working fine. > > > I've tried the gui configuration for tool gdm. The machine has no > > firewall enabled - all I get the "gdm_child_action: Aborting display > > jonspc:1" in the log ? > > I'm suprised that's the only message you get - a glance at the code > suggests if you're getting this error message (which is from the master) > you should be getting another message from the slave. If found my problem, its a name resolver issue (thank you Mr Cox :-D ) I think email is on a go-slow, please look back if you have time. Some comments on this and a few other things 1) gdm doesn't have a process itself, it runs from init - but when gdm is started it seems to undergo a name change to "gdm-binary" without being owned by gdm or anything called gdm. As a result its not possible to cleanly restart gdm ? ie no "/etc/init.d/gdm restart". Am I missing something here or this a bit naff ? 2) If the reverse name doesn't resolve the only entry in the log with debugging off is : Jan 20 10:57:19 localhost gdm[7118]: gdm_child_action: Aborting display jonspc:1 3) Speaking of logs, this is only a machine for "play" - so if its not been owned, and the following is normal, then the log should have something less pant wetting than this - something above or below explaining what process is doing this and/or why would be nice. Jan 20 07:01:01 localhost crond(pam_unix)[6836]: session opened for user root by (uid=0)Jan 20 07:01:01 localhost crond(pam_unix)[6836]: session closed for user root Jan 20 07:01:01 localhost crond(pam_unix)[6836]: session closed for user root Cheers, Jon From rms at 1407.org Thu Jan 20 12:02:55 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 20 Jan 2005 12:02:55 +0000 Subject: Fedora Core 4 In-Reply-To: <604aa791050119070644bbb0b7@mail.gmail.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119152425.34e064f1@nausicaa.camperquake.de> <604aa791050119070644bbb0b7@mail.gmail.com> Message-ID: <1106222575.4082.7.camel@roque> On Wed, 2005-01-19 at 10:06 -0500, Jeff Spaleta wrote: > Using smart to update wireless-tools from Core updates-released > smart tells me it needs to remove kdenetwork and NetworkManager. This > sort of thing is VERY dangerous to expose to a novice user. Of course that the current behaviour has to be corrected, because such an ugly barf out and it's solution (--exclude=wireless-tools) is really so much better for the novice user. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From niemeyer at conectiva.com Thu Jan 20 12:50:54 2005 From: niemeyer at conectiva.com (Gustavo Niemeyer) Date: Thu, 20 Jan 2005 10:50:54 -0200 Subject: Fedora Core 4 In-Reply-To: <1106155644.15549.27.camel@one.myworld> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <20050119133426.GA8334@burma.localdomain> <1106144340.15549.10.camel@one.myworld> <20050119161939.GA11983@burma.localdomain> <1106152574.15549.19.camel@one.myworld> <20050119164609.GC11983@burma.localdomain> <1106155644.15549.27.camel@one.myworld> Message-ID: <20050120125054.GA5922@burma.localdomain> > > Where's the ignored epoch? > > The user use (want/need) glibc-gconvdata-1: No, he doesn't. I was at his side when the problem happened. > > > I don't know (or care) if this is good or bad. But %{epoch} (as I > > > understand it) is not a version. > > > > What are you talking about? > > "glibc-gconvdata-1: > glibc-gconvdata-0:" is false. No, it isn't. > glibc-gconvdata-1: != glibc-gconvdata-0: is true. They are two different > packages. Smart replace an apple by an orange. That's excelent, since the user asked for the orange. -- Gustavo Niemeyer http://niemeyer.net From buildsys at redhat.com Thu Jan 20 13:36:23 2005 From: buildsys at redhat.com (Build System) Date: Thu, 20 Jan 2005 08:36:23 -0500 Subject: rawhide report: 20050120 changes Message-ID: <200501201336.j0KDaN700648@porkchop.devel.redhat.com> Updated Packages: GConf2-2.8.1-2 -------------- * Wed Jan 19 2005 Mark McLoughlin 2.8.1-2 - Backport some fixes from upstream CVS Maelstrom-3.0.6-7 ----------------- * Wed Jan 19 2005 Karsten Hopp 3.0.6-7 - add patch from Andrew Church anaconda-10.2.0.12-1 -------------------- * Wed Jan 19 2005 Chris Lumens 10.2.0.12-1 - Fix partitioning bugs (#101432, #137119) - Support --bytes-per-inode on a per-partition basis (#57550) apr-util-0.9.5-3 ---------------- * Wed Jan 19 2005 Joe Orton 0.9.5-3 - restore db-4.3 detection lost in 0.9.5 upgrade * Wed Jan 19 2005 Joe Orton 0.9.5-2 - rebuild cups-1:1.1.23-3 --------------- * Wed Jan 19 2005 Tim Waugh 1.1.23-3 - Applied patch to fix CAN-2005-0064. doxygen-1:1.4.1-1 ----------------- * Wed Jan 19 2005 Than Ngo 1:1.4.1-1 - update to 1.4.1 glibc-kernheaders-2.4-9.1.87 ---------------------------- * Tue Aug 31 2004 Ajran van de Ven - update input.h * Thu Jul 29 2004 Arjan van de Ven - update limits.h to reflect NR_GROUPS change * Thu Jul 22 2004 Jakub Jelinek - update syscall numbers from latest kernel on alpha/ia64 gnome-python2-2.6.0-5 --------------------- * Wed Jan 19 2005 Mark McLoughlin - 2.6.0-5 - Backport wrapping for GConfEngine from upstream CVS initscripts-8.04-1 ------------------ * Wed Jan 19 2005 Bill Nottingham 8.04-1 - split out ifup/ifdown general case to ifup/ifdown-eth; add ifup/ifdown-bnep () - ifup-ipsec: add fwd policies (#145507) - fix multiple scsi_hostadapter loads (#145432) - enable syncookies in sysctl.conf (#145201) kernel-2.6.10-1.1103_FC4 ------------------------ * Wed Jan 19 2005 Dave Jones - Re-add diskdump/netdump based on Jeff Moyers patches. - Rebase to -bk7 * Tue Jan 18 2005 Jeremy Katz - fixup xen0 %post to use new grubby features for multiboot kernels - conflict with older mkinitrd for kernel-xen0 * Tue Jan 18 2005 Dave Jones - -bk6 lvm2-2.01.01-1.0 ---------------- * Mon Jan 17 2005 Alasdair Kergon - 2.01.01-1.0 - Update vgcreate man page. Preparation for snapshot origin extension fix. nvi-m17n-1.79-20040401.21 ------------------------- * Thu Jan 20 2005 Akira TAGOH - 1.79-20040401.21 - updates m17n patch to 20040401. - added iso8859-15 support. octave-6:2.1.57-9 ----------------- * Wed Jan 19 2005 Ivana Varekova 2.1.57-9 - Fix bug #142440 - change octave.spec: autoconf is BuildPrereq - Fix bug #142631 - change octave.spec: mkoctfile.1.gz is part of octave-devel not octave perl-3:5.8.6-2 -------------- * Tue Jan 18 2005 Chip Turner - 3:5.8.6-2 - bugzilla: 145448, fix invalid utf8 in changelog * Tue Jan 18 2005 Chip Turner - 3:5.8.6-1 - bugzilla: 145447, add 5.8.5 to perlmodcompat list rhpl-0.152-1 ------------ * Wed Jan 19 2005 Jeremy Katz - 0.152-1 - fix build with new glibc-kernheaders (#145442) rpmdb-fedora-1:4-0.20050120 --------------------------- selinux-policy-strict-1.21.2-2 ------------------------------ * Wed Jan 19 2005 Dan Walsh 1.21.2-2 - Fixed policy for telnet and rlogin * Tue Jan 18 2005 Dan Walsh 1.21.2-1 - Update with latest from NSA - Add Policy man pages selinux-policy-targeted-1.21.2-4 -------------------------------- * Wed Jan 19 2005 Nalin Dahyabhai 1.21.2-4 - Add a default_context entry for the remote_login_t domain, for telnet * Wed Jan 19 2005 Dan Walsh 1.21.2-2 - Fixed policy for telnet and rlogin * Tue Jan 18 2005 Dan Walsh 1.21.2-1 - Update with latest from NSA - Add Policy man pages squid-7:2.5.STABLE7-2 --------------------- * Tue Jan 18 2005 Jay Fenlason 7:2.5.STABLE7-2 - Add a triggerin on samba-common to make /var/cache/samba/winbindd_privileged accessable so that ntlm_auth will work. It needs to be in this rpm, because the Samba RPM can't assume the squid user exists. Note that this will only work if the Samba RPM is recent enough to create that directory at install time instead of at winbindd startup time. That should be samba-common-3.0.0-15 or later. This fixes bugzilla #103726 - Clean up extra whitespace in this spec file. - Add additional upstream patches. (Now 18 upstream patches). - patch #112 closes CAN-2005-0096 and CAN-2005-0097, remote DOS security holes. - patch #113 closes CAN-2005-0094, a remote buffer-overflow DOS security hole. - patch #114 closes CAN-2005-0095, a remote DOS security hole. - Remove the -nonbl (replaced by #104) and -close (replaced by #111) patches, since they're now fixed by upstream patches. tetex-2.0.2-30 -------------- * Wed Jan 19 2005 Jindrich Novy 2.0.2-30 - Fix CAN-2005-0064 xpdf buffer overflow x3270-3.3.2.p1-10 ----------------- * Wed Jan 12 2005 Tim Waugh 3.3.2.p1-10 - Rebuilt for new readline. * Wed Dec 08 2004 Karsten Hopp 3.3.2.p1-9 - add icon (#141599, #125577) - fix variable usage (local variable overwrite) (#116660) * Wed Dec 08 2004 Karsten Hopp 3.3.2.p1-8 - rebuild From fedora at wir-sind-cool.org Thu Jan 20 14:00:21 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Thu, 20 Jan 2005 15:00:21 +0100 Subject: Reopen a request for gpgme in Core In-Reply-To: <20050107084810.09c3aa38.fedora@wir-sind-cool.org> References: <1104977635.10350.17.camel@Madison.badger.com> <20050106110659.17f329f0.toshio@tiki-lounge.com> <20050106183045.1991bdbb.fedora@wir-sind-cool.org> <200501062148.50705.dennis@ausil.us> <20050107084810.09c3aa38.fedora@wir-sind-cool.org> Message-ID: <20050120150021.01dbf2d2.fedora@wir-sind-cool.org> On Fri, 7 Jan 2005 08:48:10 +0100, Michael Schwendt wrote: > On Thu, 6 Jan 2005 21:48:44 -0600, Dennis Gilmore wrote: > > > > Among the things to examine are: > > > > > > * Dependencies on GPGME 0.4.x: gpa, elmo > > > * Dependencies on GPGME 0.3.x: cryptplug, seahorse, sylpheed-claws > > > (seahorse is very old, but pcomptom said maybe he will continue it) > > > * In which way or whether cryptplug uses gpgsm? > > > * Is cryptplug of any use in FC3? > > > > AFAIK cryptplug is no longer of use in FC3 kmail in kde 3.3 has the > > functionality added i think mutt may have used it to sign mails also but i > > dont think there was ever a client patch to take advantage it. > > Good. Then the only dependency on gpgme 0.3.x is Sylpheed-claws (well, > and Sylpheed in Fedora Core for people like me who rebuild it with > GPGME privately). > > Has anyone any objections against rebuilding GPGME 0.3.x without > support for GPGSM? That would enable us to get rid of the dependency > on newpg (via /usr/bin/gpgsm). It would also make libksba 0.4.x > obsolete, and upgradable to libksba 0.9.x as needed by GNUPG 2. The > build dependency on gpgsm could be dropped anyway, and the > install-time dependency would no longer be needed. Does any package > exist which would use GPGME 0.3.x + GPGSM and is not included in > Extras? > > Left would be GPGME 0.4.x as used by elmo and gpa. Neither one uses > GPGSM either, so GPGME 0.4.x could also be rebuilt without gpgsm > dependency. Then, both gpa and elmo build against GPGME 1.0.x, so no > urgent need to keep GPGME 0.4.x, not even as gpgme04 package. > > Still to check: gpa and elmo build with GPGME 1.0.x, but do they work > correctly? As a status update here: elmo : "project was closed" 2005-01-06 according to the web site gpgme03 : can stay until Sylpheed-claws/Sylpheed are ported to GPGME 1.0 API gpgme : as mentioned above, the 0.4.x version is only used by "elmo" and "gpa", and both build with GPGME 1.0 API - we could upgrade it and need not keep a gpgme04 package cryptplug : not used anymore (it depends on gpgme03) newpg : temporary project, obsolete with GnuPG 2, none of our packages _really_ requires its functionality through GPGME libksba : 0.4.x version only used by newpg - we could upgrade to the 0.9.x version used by GnuPG 2 Conclusively: If we continued with trying to add a GnuPG 2 pre-release into Extras, we would upgrade libassuan libksba gpgme (0.4.x to 1.0.x) and add gnupg2 (which would be parallel-installable with gnupg) dirmngr and we would need to decide on which features to include, since the current candidates in fedora.us QA queue also include smartcard functionality. GnuPG 2, however, is something which will likely be included in Fedora Core some day. Hence I feel we should avoid that future core packages of GnuPG 2 contain less features. What's current procedure with regard to such coordination between Core and Extras? From arjanv at redhat.com Thu Jan 20 14:01:37 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 20 Jan 2005 15:01:37 +0100 Subject: rawhide report: 20050120 changes In-Reply-To: <200501201336.j0KDaN700648@porkchop.devel.redhat.com> References: <200501201336.j0KDaN700648@porkchop.devel.redhat.com> Message-ID: <1106229698.6742.36.camel@laptopd505.fenrus.org> > kernel-2.6.10-1.1103_FC4 > ------------------------ > * Wed Jan 19 2005 Dave Jones > - Re-add diskdump/netdump based on Jeff Moyers patches. > - Rebase to -bk7 why is this gunk added back to the fedora kernel? I can see trying to get kexec-dump working instead as useful, but diskdump/netdump? God no. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora_devel_list at poczta.fm Thu Jan 20 13:36:24 2005 From: fedora_devel_list at poczta.fm (Dawid Gajownik) Date: Thu, 20 Jan 2005 14:36:24 +0100 Subject: RFC: Optimizing for 386 In-Reply-To: <20050119170235.GV10340@devserv.devel.redhat.com> References: <20050119171047.C15870@ryoko.camperquake.de> <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <20050119170235.GV10340@devserv.devel.redhat.com> Message-ID: <41EFB3D8.6000800@poczta.fm> Dnia 01/19/2005 06:02 PM, U?ytkownik Jakub Jelinek napisa?: > Yes, we know very well about -march and -mtune difference. > The current CFLAGS (for *.i386.rpm -march=i386 -mtune=pentium4) are just fine > for the whole distro. And what about LDFLAGS? Has anyone been experimenting with this variable? I've read those two pages: http://forums.gentoo.org/viewtopic.php?t=226909 http://bugs.gentoo.org/show_bug.cgi?id=65002 and it sounds promising - some optimizations for free :D Does it have any drawbacks? -- ^_* ---------------------------------------------------------------------- Najlepsze auto, najlepsze moto... >>> http://link.interia.pl/f1841 From caolanm at redhat.com Thu Jan 20 14:21:24 2005 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 20 Jan 2005 14:21:24 +0000 Subject: RFC: Optimizing for 386 In-Reply-To: <41EFB3D8.6000800@poczta.fm> References: <20050119171047.C15870@ryoko.camperquake.de> <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <20050119170235.GV10340@devserv.devel.redhat.com> <41EFB3D8.6000800@poczta.fm> Message-ID: <1106230884.9780.101.camel@sheol.homelinux.org> On Thu, 2005-01-20 at 14:36 +0100, Dawid Gajownik wrote: > And what about LDFLAGS? Has anyone been experimenting with this > variable? I've read those two pages: FWIW OOo (2 at least) links with -Wl,-01 C. From n3npq at nc.rr.com Thu Jan 20 14:25:19 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 20 Jan 2005 09:25:19 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <1106230884.9780.101.camel@sheol.homelinux.org> References: <20050119171047.C15870@ryoko.camperquake.de> <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <20050119170235.GV10340@devserv.devel.redhat.com> <41EFB3D8.6000800@poczta.fm> <1106230884.9780.101.camel@sheol.homelinux.org> Message-ID: <41EFBF4F.2000700@nc.rr.com> Caolan McNamara wrote: >On Thu, 2005-01-20 at 14:36 +0100, Dawid Gajownik wrote: > > >>And what about LDFLAGS? Has anyone been experimenting with this >>variable? I've read those two pages: >> >> > >FWIW OOo (2 at least) links with -Wl,-01 > > With no objective measurement of any performance win through optimizing LDFLAGS, as always. And with hints of build breakage and incompatibilities. 73 de Jeff From cmadams at hiwaay.net Thu Jan 20 14:32:27 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 20 Jan 2005 08:32:27 -0600 Subject: RFC: Optimizing for 386 In-Reply-To: References: <3077b8a0050119082743fff58a@mail.gmail.com> <3khj1h$ghul9b@mxip07a.cluster1.charter.net> <20050119194928.GD1219319@hiwaay.net> <41EED435.3B0D8EF0@jwz.org> <20050119221102.GE1219319@hiwaay.net> Message-ID: <20050120143227.GA1031661@hiwaay.net> Once upon a time, Dag Wieers said: > On Wed, 19 Jan 2005, Chris Adams wrote: > > /usr/X11R6/lib/libOSMesa.so.4 checks for MMX, 3DNow!, SSE > > /usr/bin/gimp checks for MMX, 3DNow!, SSE > > /usr/bin/xmms may use MMX, 3DNow! > > /usr/lib/libFLAC.so.4 may use cmov, MMX, SSE, SSE2, 3DNow! > > /usr/lib/libSDL-1.2.so.0 may use MMX, SSE > > /usr/lib/libgstreamer-0.8.so may use MMX, 3DNow!, SSE > > /usr/lib/libasound.so.2 may use MMX > > I'm wondering, did you run a command to get such a list ? find, grep, and strings -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jakub at redhat.com Thu Jan 20 14:45:35 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 20 Jan 2005 09:45:35 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <41EFB3D8.6000800@poczta.fm> References: <20050119171047.C15870@ryoko.camperquake.de> <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <20050119170235.GV10340@devserv.devel.redhat.com> <41EFB3D8.6000800@poczta.fm> Message-ID: <20050120144535.GB10340@devserv.devel.redhat.com> On Thu, Jan 20, 2005 at 02:36:24PM +0100, Dawid Gajownik wrote: > Dnia 01/19/2005 06:02 PM, U??ytkownik Jakub Jelinek napisa??: > > >Yes, we know very well about -march and -mtune difference. > >The current CFLAGS (for *.i386.rpm -march=i386 -mtune=pentium4) are just > >fine > >for the whole distro. > > And what about LDFLAGS? Has anyone been experimenting with this > variable? I've read those two pages: > http://forums.gentoo.org/viewtopic.php?t=226909 > http://bugs.gentoo.org/show_bug.cgi?id=65002 > and it sounds promising - some optimizations for free :D Does it have > any drawbacks? First of all, I guess for many packages it isn't trivial to propagate LDFLAGS down. -Wl,-O1 does only one thing in all binutils I know, particularly use an O(nsyms^2) algorithm to optimize .hash section for minimal chain lengths. It is very expensive for really large shared libraries, for the largest ones I've seen it takes an hour or more to link with this option. Plus when the library is prelinked and used (at least mostly) as direct dependency of prelinked programs, then -Wl,-O1 actually hurts (as it means .hash section is bigger than necessary) instead of helping. Jakub From rdieter at math.unl.edu Thu Jan 20 15:05:13 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 20 Jan 2005 09:05:13 -0600 (CST) Subject: XDMCP Core 3 In-Reply-To: <1106220007.31944.3.camel@jonspc> References: <1106174613.5881.2524.camel@jonspc> <1106208861.32395.4.camel@blaa> <1106220007.31944.3.camel@jonspc> Message-ID: On Thu, 20 Jan 2005, Jonathan Andrews wrote: > 1) gdm doesn't have a process itself, it runs from init - but when gdm > is started it seems to undergo a name change to "gdm-binary" without > being owned by gdm or anything called gdm. As a result its not possible > to cleanly restart gdm ? ie no "/etc/init.d/gdm restart". Am I missing > something here or this a bit naff ? /sbin/telinit 3 /sbin/telinit 5 effectively restarts it. (-: -- Rex From fedora_devel_list at poczta.fm Thu Jan 20 15:05:44 2005 From: fedora_devel_list at poczta.fm (Dawid Gajownik) Date: Thu, 20 Jan 2005 16:05:44 +0100 Subject: RFC: Optimizing for 386 In-Reply-To: <20050120144535.GB10340@devserv.devel.redhat.com> References: <20050119171047.C15870@ryoko.camperquake.de> <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <20050119170235.GV10340@devserv.devel.redhat.com> <41EFB3D8.6000800@poczta.fm> <20050120144535.GB10340@devserv.devel.redhat.com> Message-ID: <41EFC8C8.1040806@poczta.fm> Dnia 01/20/2005 03:45 PM, U?ytkownik Jakub Jelinek napisa?: > Plus when the library is prelinked and used (at least mostly) as direct > dependency of prelinked programs, then -Wl,-O1 actually hurts (as it means > .hash section is bigger than necessary) instead of helping. Really helpful answer - thanks for claryfing it :) -- ^_* ---------------------------------------------------------------------- Najlepsze auto, najlepsze moto... >>> http://link.interia.pl/f1841 From dcbw at redhat.com Thu Jan 20 15:08:56 2005 From: dcbw at redhat.com (Dan Williams) Date: Thu, 20 Jan 2005 10:08:56 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <1106211110.9780.6.camel@sheol.homelinux.org> References: <20050119171047.C15870@ryoko.camperquake.de> <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <20050119170235.GV10340@devserv.devel.redhat.com> <1106155456.1952.45.camel@localhost.localdomain> <20050120001639.GD18174@devserv.devel.redhat.com> <1106211110.9780.6.camel@sheol.homelinux.org> Message-ID: <1106233736.29604.35.camel@dcbw.boston.redhat.com> On Thu, 2005-01-20 at 08:51 +0000, Caolan McNamara wrote: > On Wed, 2005-01-19 at 19:16 -0500, Alan Cox wrote: > > On Wed, Jan 19, 2005 at 06:24:16PM +0100, Peter Backlund wrote: > > > Has anyone been testing -Os (optimize for size) instead of -O2 on any > > > greater scale? Fitting as much as possible in L1-cache is a great way to > > > obtain high performance. > > > > I run with almost all of gnome -Os and its faster where I can do tests - but > > its hard to be scientific > > On the OOo front, the compile flags for 2.0 will be/should be > "-Os -fno-strict-aliasing" the strict aliasing is apparently why 1.1.X > becomes unstable when compiled just with -Os. Good to know, maybe we should do some tests on that again with 1.1.x and see what we get... Dan From peter.backlund at home.se Thu Jan 20 15:26:05 2005 From: peter.backlund at home.se (Peter Backlund) Date: Thu, 20 Jan 2005 16:26:05 +0100 Subject: XDMCP Core 3 In-Reply-To: <1106220007.31944.3.camel@jonspc> References: <1106174613.5881.2524.camel@jonspc> <1106208861.32395.4.camel@blaa> <1106220007.31944.3.camel@jonspc> Message-ID: <1106234765.16789.19.camel@localhost.localdomain> tor 2005-01-20 klockan 11:20 +0000 skrev Jonathan Andrews: > On Thu, 2005-01-20 at 08:14, Mark McLoughlin wrote: > > Hi, > > > > On Wed, 2005-01-19 at 22:43 +0000, Jonathan Andrews wrote: > > > Is XDMCP, remote X bust in core 3 ? > > > > I was using it not so long ago and it was working fine. > > > > > I've tried the gui configuration for tool gdm. The machine has no > > > firewall enabled - all I get the "gdm_child_action: Aborting display > > > jonspc:1" in the log ? > > > > I'm suprised that's the only message you get - a glance at the code > > suggests if you're getting this error message (which is from the master) > > you should be getting another message from the slave. > If found my problem, its a name resolver issue (thank you Mr Cox :-D ) > I think email is on a go-slow, please look back if you have time. > > Some comments on this and a few other things > > 1) gdm doesn't have a process itself, it runs from init - but when gdm > is started it seems to undergo a name change to "gdm-binary" without > being owned by gdm or anything called gdm. As a result its not possible > to cleanly restart gdm ? ie no "/etc/init.d/gdm restart". Am I missing > something here or this a bit naff ? You can simply kill gdm by pkill gdm-binary (or your preferred method of killing processes). init should respawn gdm automatically. /Peter From jon at jonshouse.co.uk Thu Jan 20 16:05:09 2005 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Thu, 20 Jan 2005 16:05:09 +0000 Subject: XDMCP Core 3 In-Reply-To: <1106234765.16789.19.camel@localhost.localdomain> References: <1106174613.5881.2524.camel@jonspc> <1106208861.32395.4.camel@blaa> <1106220007.31944.3.camel@jonspc> <1106234765.16789.19.camel@localhost.localdomain> Message-ID: <1106237109.32325.46.camel@jonspc> On Thu, 2005-01-20 at 15:26, Peter Backlund wrote: > tor 2005-01-20 klockan 11:20 +0000 skrev Jonathan Andrews: > > On Thu, 2005-01-20 at 08:14, Mark McLoughlin wrote: > > > Hi, > > > > > > On Wed, 2005-01-19 at 22:43 +0000, Jonathan Andrews wrote: > > > > Is XDMCP, remote X bust in core 3 ? > > > > > > I was using it not so long ago and it was working fine. > > > > > > > I've tried the gui configuration for tool gdm. The machine has no > > > > firewall enabled - all I get the "gdm_child_action: Aborting display > > > > jonspc:1" in the log ? > > > > > > I'm suprised that's the only message you get - a glance at the code > > > suggests if you're getting this error message (which is from the master) > > > you should be getting another message from the slave. > > If found my problem, its a name resolver issue (thank you Mr Cox :-D ) > > I think email is on a go-slow, please look back if you have time. > > > > Some comments on this and a few other things > > > > 1) gdm doesn't have a process itself, it runs from init - but when gdm > > is started it seems to undergo a name change to "gdm-binary" without > > being owned by gdm or anything called gdm. As a result its not possible > > to cleanly restart gdm ? ie no "/etc/init.d/gdm restart". Am I missing > > something here or this a bit naff ? > > > You can simply kill gdm by > > pkill gdm-binary > > (or your preferred method of killing processes). init should respawn gdm > automatically. > > /Peter Yes, i'm well aware of how to do this - I was really just trying to point out that its a bit crappy ! With xdm you edit the xdm support files and re-start xdm, this is not possible with gdm. You have to find the *specific* "gdm-binary that relates to the display and kill it, if you killall gdm-binary then then you lose all sessions. This is doubly crappy as prefdm started "gdm" - this vanished without trace leaving an unknown number of gdm-binary behind. If I run A - I expect to see "A" not lots of little "B", I know its legal and possible - its just not friendly. Jon From jspaleta at gmail.com Thu Jan 20 16:27:58 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 20 Jan 2005 11:27:58 -0500 Subject: XDMCP Core 3 In-Reply-To: <1106220007.31944.3.camel@jonspc> References: <1106174613.5881.2524.camel@jonspc> <1106208861.32395.4.camel@blaa> <1106220007.31944.3.camel@jonspc> Message-ID: <604aa791050120082759b532db@mail.gmail.com> On Thu, 20 Jan 2005 11:20:07 +0000, Jonathan Andrews wrote: > 1) gdm doesn't have a process itself, it runs from init - but when gdm > is started it seems to undergo a name change to "gdm-binary" without > being owned by gdm or anything called gdm. As a result its not possible > to cleanly restart gdm ? ie no "/etc/init.d/gdm restart". Am I missing > something here or this a bit naff ? > /etc/X11/prefdm is a script set to respawn and has logic to use selectable dm's using /etc/sysconfig/desktop (which could easily be configured to use kdm or xdm). Here's a question for you... how does init know when its appropriate to respawn prefdm? /usr/bin/gdm is just a shell script that calls gdm-binary. The shell script here is very simple and seems to only be checking to make sure that /etc/profile is run if available. Is this script wrapper necessarily for correct gdm operation? -jef From kyrre at solution-forge.net Thu Jan 20 17:27:34 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 20 Jan 2005 18:27:34 +0100 Subject: XDMCP Core 3 In-Reply-To: <1106220007.31944.3.camel@jonspc> References: <1106174613.5881.2524.camel@jonspc> <1106208861.32395.4.camel@blaa> <1106220007.31944.3.camel@jonspc> Message-ID: <1106242053.5344.0.camel@localhost.localdomain> tor, 20.01.2005 kl. 12.20 skrev Jonathan Andrews: > On Thu, 2005-01-20 at 08:14, Mark McLoughlin wrote: > > Hi, > > > > On Wed, 2005-01-19 at 22:43 +0000, Jonathan Andrews wrote: > > > Is XDMCP, remote X bust in core 3 ? > > > > I was using it not so long ago and it was working fine. > > > > > I've tried the gui configuration for tool gdm. The machine has no > > > firewall enabled - all I get the "gdm_child_action: Aborting display > > > jonspc:1" in the log ? > > > > I'm suprised that's the only message you get - a glance at the code > > suggests if you're getting this error message (which is from the master) > > you should be getting another message from the slave. > If found my problem, its a name resolver issue (thank you Mr Cox :-D ) > I think email is on a go-slow, please look back if you have time. > > Some comments on this and a few other things > > 1) gdm doesn't have a process itself, it runs from init - but when gdm > is started it seems to undergo a name change to "gdm-binary" without > being owned by gdm or anything called gdm. As a result its not possible > to cleanly restart gdm ? ie no "/etc/init.d/gdm restart". Am I missing > something here or this a bit naff ? > it is. But you have the tools gdm-restart etc. (just type gdm*tabtab* and you'l find 'em > 2) If the reverse name doesn't resolve the only entry in the log with > debugging off is : > Jan 20 10:57:19 localhost gdm[7118]: gdm_child_action: Aborting display > jonspc:1 > > > 3) Speaking of logs, this is only a machine for "play" - so if its not > been owned, and the following is normal, then the log should have > something less pant wetting than this - something above or below > explaining what process is doing this and/or why would be nice. > > Jan 20 07:01:01 localhost crond(pam_unix)[6836]: session opened for > user root by (uid=0)Jan 20 07:01:01 localhost crond(pam_unix)[6836]: > session closed for user root > Jan 20 07:01:01 localhost crond(pam_unix)[6836]: session closed for user > root > > Cheers, > Jon > > From 1 at 234.cx Thu Jan 20 17:45:36 2005 From: 1 at 234.cx (Pete Chown) Date: Thu, 20 Jan 2005 17:45:36 +0000 Subject: goals for fc4? References: <5cf776b8050108150644336d04@mail.gmail.com> <1105328387.5866.4.camel@one.myworld> <1105493919l.5018l.11l@devel.mpeters.us> <1105964316.5505.13.camel@ulysse.olympe.o2t> <1105968591.933.2.camel@va.local.linuxlobbyist.org> <1105972251.5505.89.camel@ulysse.olympe.o2t> <20050117171149.GB11715@devserv.devel.redhat.com> Message-ID: Tom Tromey wrote: > As a practical matter touching on Fedora, gcj remains the "best" way > to deliver java applications on a free system. In my opinion, other > free VMs have unacceptable performance, unacceptable platform > coverage, or both. Have you tried ikvm? Rhino runs with it successfully, so it must be fairly complete. I haven't tried anything more demanding, though. One nice thing about ikvm is that it's a JIT (or rather, uses a JIT, either Mono or .NET). This means that in use, it is much more similar to other Java implementations. Pete From kyrre at solution-forge.net Thu Jan 20 18:05:51 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 20 Jan 2005 19:05:51 +0100 Subject: RFC: Optimizing for 386 In-Reply-To: <1106179640.5599.6.camel@stargrazer.home.awesomeplay.com> References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> <1106172965.2663.16.camel@localhost.localdomain> <1106179640.5599.6.camel@stargrazer.home.awesomeplay.com> Message-ID: <1106244351.5344.36.camel@localhost.localdomain> tor, 20.01.2005 kl. 01.07 skrev Sean Middleditch: > On Wed, 2005-01-19 at 23:16 +0100, Kyrre Ness Sjobak wrote: > > ons, 19.01.2005 kl. 17.08 skrev Joseph D. Wagner: > > > I can count the total number of people in the world who still use a 386 on the fingers of both of my hands. Why are we still catering to this small group of people? > > > > > > With the exception of the kernel and glibc, all RPM's are optimized for 386 architecture. This is a waste of system resources. Study after study shows that you can achieve a 10% - 40% performance improvement my optimizing code for a specific architecture. Windows XP may only be optimized for a Pentium, but by golly, at least the whole thing is optimized, not just the kernel and the C library. > > > > > > Just look at X. Is anyone seriously trying to get X to run on a 386? I can understand compiling the text-based programs, like bash, for 386. You can run a text-only box on a 386 just fine. Why do that for X? Why do that for GNOME, KDE, or any graphical program for that matter? > > > > > > I know that I can recompile of these program from the source code to achieve those optimizations. However, why should everyone who wants to optimize their systems have to go through that, just so a handful of people with 386 machines can run X out-of-the-box? Then, we have recompile all over again with the next RPM release. > > > > > > Why can't the few people who have a 386 be made to recompile X from sources to get it to run on there machines, so the rest of us can enjoy the performance boost from running optimized binaries? > > > > > > I think we seriously need to rethink the distribution strategy. At the very least, all graphical programs should be optimized for i686. > > > > > > Joseph D. Wagner > > > > > > > Actually, i don't think the CPU is the biggest slowdown for fedora. From > > my personal experience - memory (RAM) is a bigger issue. I have a 200 > > mhz pentium 2 running fedora 3, full GUI and everything, and while i > > ain't claiming that it is hyperfast, its certainly usable. It has 384 MB > > of RAM. > > Disk access is also pretty important. I've started some "simple" apps > using strace and watched as screen after screen after screen after > screen of open/stat/etc calls were made. GUI apps with all their icons > and external resource files and image plugins and so on are the worst. > The GTK+ folks are working on solutions in some cases (like icon > loading), but there's a lot that could be done by just slimming down > what apps need and how they go about getting those needs. (Take a JAR > file - load the whole thing in RAM and get your code and data with only > loading one file off the disk. I wonder how well that could work for > normal executables?) > > > When it comes to startup times - how difficult would it be to (given > > enough RAM - autodetection+manual config) preload OpenOffice and Firefox > > on OS start, so it would just "be there" (like both of them are when > > first started) when the user clicks the nice, little icon? > > I don't really believe much in preloading. If you're a company CEO that > doesn't do anything other than make presentations and fire off a memo > here and there, maybe preloading works. In general, though, spending > startup time preloading OOo just to have Mozilla kick it back out again > if you start Mozilla first, just isn't going to help - the preloading > only helps once and only if its the first large app you run. > At least most of the (non-technical) users i know use typically just a few apps. And thats a web browser (usually the one that goes with the OS), and an Office suite. Often they use the two in paralell - i.e. clicking on a link to a .doc just to read it. (i know .doc's are a damn stupid format for document exange etc. but... its used. Can't change the whole world at once!) They expect the office program to be there in the matter of secounds. Then they log on to/borrow mine/ask me nicely to check something. Just some plan, standard form ETC. I open the page in the webbrowser (no problem, quick. The firefox start-up delay is at least tolerable, if not optimal), and click the link. Do i want to open it in /home/kyrre/.redhat-openoffice(etc)? Yes. *wait* *wait* *spash screen* *wait* *wait* *gray document area, main window visible* *wait* and there the document is. Now, print it. (this is from my laptop. its a 850 mhz with about (:P)300 MB of RAM (the number is odd, nonstandard, strange, so i cant remember it). Overall, an OK laptop. As i am lucky there actually is a shared cups printer on the net. BUT the damn stupid windows DNS which i get from DHCP isn't configured to allow me to lookup the printer server, so i can't print without changing my DNS. (even if cups has the IP adress. Why not let cups use this as a fallback when DNS fails?) *control-alt-f1* *black, scary looking terminal* *type root and password hellishly fast* *vim /etc/resolv.conf* *whacka-whack!* And the person looking over my shoulder finds out that this is an OS only for ?ber-geeks which do little other than "hack" the computer (and ofcource he believes a hacker is someone who breaks into governement computers, and generally use the term "1337" about them). He ain't far off asking me to change the saldo of his bank account now, as this looks about as cryptic (especially done in fast-foreward... It isn't like this is the first time i am doing this). *logout* *print* He happily wanders off to collect the papers, only a little confused. While i am sitting pussled about why the little printer icon doesn't dissapear. Did i do anything wrong? Will he come back again, telling "there was no print!". He didn't. But he didn't complain about the print using 1 page and 2 lines instead of exactly one page (due to font diffs). All of this should be a simple fast forward as "click "web", open page, hit "open", wait one-five secounds, hit print, select printer. Here, get you paper. > Better to just slim down memory usage. Or go buy more RAM, it's cheap. > Seriously, I've got a 512MB chip as a keychain ornament. ~_^ *rant* You tell that to a public shool which IT budget is to bogged down by mandantory Windows/office licenses, while the governement demands more licenses and less money to schools (while they claim they are pro-education. Oh, you mean all those new private schools popping up like mushrooms? I guess they meant that, especially their shareholders.). Luckily, it looks that not i am not the only one tired of having the coutry being ran of a coalition of right-wing party's, who get little rigth exept figthing between each other and internally, never listening to the public (such as when 90% of the people was opposed to the war on Iraq and had declared hate on Bush, they managed to send them a bunch of weapons (they shure need it!), strongly supporting Bushis'm (and being the honor guest of some republican meeting). Then they declared tax cutbacks their most important thing - while most of the people rather wanted the public sector to be rescued. And that was when they did not privatize everything they could as fast as possible, claiming that theocraties are evil (their prime minister is a priest. But you know, he's christian, so its okay) And noooobody eeever mentioned doublespeak? Well, you know - we are extremely good at sending people to get people to make peace to eachother - just look at Israel/Palestina and Sri Lanka! */rant* From kyrre at solution-forge.net Thu Jan 20 18:24:39 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 20 Jan 2005 19:24:39 +0100 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <1106154283.5881.2396.camel@jonspc> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> <20050119165356.GD11983@burma.localdomain> <1106154283.5881.2396.camel@jonspc> Message-ID: <1106245478.5344.45.camel@localhost.localdomain> ons, 19.01.2005 kl. 18.04 skrev Jonathan Andrews: > Im no novice user - nor an expert, but somebody please tell me what > yum/up2date has that apt/synaptic doesn't ? > > I've been using apt/synaptic against core 3 and im beginning to think > that yum is a political move not a technical one ? > > Sorry if this annoys - im not trying to troll > > Jon > > apt doesn't have multilib support. From jon at jonshouse.co.uk Thu Jan 20 18:32:23 2005 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Thu, 20 Jan 2005 18:32:23 +0000 Subject: XDMCP Core 3 In-Reply-To: <1106242053.5344.0.camel@localhost.localdomain> References: <1106174613.5881.2524.camel@jonspc> <1106208861.32395.4.camel@blaa> <1106220007.31944.3.camel@jonspc> <1106242053.5344.0.camel@localhost.localdomain> Message-ID: <1106245942.32325.67.camel@jonspc> On Thu, 2005-01-20 at 17:27, Kyrre Ness Sjobak wrote: > tor, 20.01.2005 kl. 12.20 skrev Jonathan Andrews: > > On Thu, 2005-01-20 at 08:14, Mark McLoughlin wrote: > > > Hi, > > > > > > On Wed, 2005-01-19 at 22:43 +0000, Jonathan Andrews wrote: > > > > Is XDMCP, remote X bust in core 3 ? > > > > > > I was using it not so long ago and it was working fine. > > > > > > > I've tried the gui configuration for tool gdm. The machine has no > > > > firewall enabled - all I get the "gdm_child_action: Aborting display > > > > jonspc:1" in the log ? > > > > > > I'm suprised that's the only message you get - a glance at the code > > > suggests if you're getting this error message (which is from the master) > > > you should be getting another message from the slave. > > If found my problem, its a name resolver issue (thank you Mr Cox :-D ) > > I think email is on a go-slow, please look back if you have time. > > > > Some comments on this and a few other things > > > > 1) gdm doesn't have a process itself, it runs from init - but when gdm > > is started it seems to undergo a name change to "gdm-binary" without > > being owned by gdm or anything called gdm. As a result its not possible > > to cleanly restart gdm ? ie no "/etc/init.d/gdm restart". Am I missing > > something here or this a bit naff ? > > > > it is. But you have the tools gdm-restart etc. (just type gdm*tabtab* > and you'l find 'em Thanks, i've found it - yet another small shell script. In a way you are making my point nicely. Gnome broke the way xdm works when they ported it into gnome, then they keep bodging on another shell script for the functionality thats missing. I know in the global scheme of things its a minor point, but breaking the sensible way process control works just to add a few lines of logic before and after the process seems to be a bit ... well ... you get the idea ! I have to admit gdm is pretty though (after xdm anything looks better) :-) - but to many bodges ... *** warning - nasty idea for Unix purists *** Linux is general seems a bit confused about process control, init, xinetd and rc all overlap slightly in functionality. Couldn't the entire machine come up with just a slightly better xinetd and config files ? xinetd treats socket connects as an event - but isn't starting, stopping or changing runlevel just another event ? Jon From pri.rhl3 at iadonisi.to Thu Jan 20 18:37:57 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Thu, 20 Jan 2005 13:37:57 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <1106244351.5344.36.camel@localhost.localdomain> References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> <1106172965.2663.16.camel@localhost.localdomain> <1106179640.5599.6.camel@stargrazer.home.awesomeplay.com> <1106244351.5344.36.camel@localhost.localdomain> Message-ID: <1106246277.19994.6.camel@tuxpaq> On Thu, 2005-01-20 at 19:05 +0100, Kyrre Ness Sjobak wrote: [snip] > *rant* [bunch of political crap snipped] > */rant* Please realize that fedora-devel list members are likely of wide and varied political opinion (as well as wide and varied country of residence and/or citizenship) and keep this kind of crap off this list. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From jon at jonshouse.co.uk Thu Jan 20 18:45:00 2005 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Thu, 20 Jan 2005 18:45:00 +0000 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <1106245478.5344.45.camel@localhost.localdomain> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> <20050119165356.GD11983@burma.localdomain> <1106154283.5881.2396.camel@jonspc> <1106245478.5344.45.camel@localhost.localdomain> Message-ID: <1106246699.32325.77.camel@jonspc> On Thu, 2005-01-20 at 18:24, Kyrre Ness Sjobak wrote: > ons, 19.01.2005 kl. 18.04 skrev Jonathan Andrews: > > Im no novice user - nor an expert, but somebody please tell me what > > yum/up2date has that apt/synaptic doesn't ? > > > > I've been using apt/synaptic against core 3 and im beginning to think > > that yum is a political move not a technical one ? > > > > Sorry if this annoys - im not trying to troll > > > > Jon > > > > > > apt doesn't have multilib support. Yum doesn't have a good front end ? What would be quicker - add a quality front end to yum or add multilib to apt/synaptic ... I bet I know ;-) Isn't this just a packaging niceness, divide packages into arch and noarch halves and the problem goes away - or am I being naive ? Jon From n3npq at nc.rr.com Thu Jan 20 19:00:53 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 20 Jan 2005 14:00:53 -0500 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <1106246699.32325.77.camel@jonspc> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> <20050119165356.GD11983@burma.localdomain> <1106154283.5881.2396.camel@jonspc> <1106245478.5344.45.camel@localhost.localdomain> <1106246699.32325.77.camel@jonspc> Message-ID: <41EFFFE5.1070808@nc.rr.com> Jonathan Andrews wrote: > >Isn't this just a packaging niceness, divide packages into arch and >noarch halves and the problem goes away - or am I being naive ? > > Well, naive. Packages are marked 0 uncolored 1 elf32 2 elf64 dep0ending on what is contained within (i.e. a pkg that contains an elf32 binary will have color == 1. No package has both elf32 and elf64 yet, but the mechanism can/will support when someone is daft enough to try.) and one has to choose, say, the elf64 package to upgrade an elf64 package. Then the usual mechanism, choose closest matching arch, say, preferring i586 over i386 on i686 (except for kernel which is a whole differerent selection mechanism). But mutilib (or biarch if you prefer) has nothing whatsoever to do with arch or "noarch" tags in packages. 73 de Jeff From kyrre at solution-forge.net Thu Jan 20 19:02:34 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 20 Jan 2005 20:02:34 +0100 Subject: XDMCP Core 3 In-Reply-To: <1106245942.32325.67.camel@jonspc> References: <1106174613.5881.2524.camel@jonspc> <1106208861.32395.4.camel@blaa> <1106220007.31944.3.camel@jonspc> <1106242053.5344.0.camel@localhost.localdomain> <1106245942.32325.67.camel@jonspc> Message-ID: <1106247753.5344.54.camel@localhost.localdomain> tor, 20.01.2005 kl. 19.32 skrev Jonathan Andrews: > On Thu, 2005-01-20 at 17:27, Kyrre Ness Sjobak wrote: > > tor, 20.01.2005 kl. 12.20 skrev Jonathan Andrews: > > > On Thu, 2005-01-20 at 08:14, Mark McLoughlin wrote: > > > > Hi, > > > > > > > > On Wed, 2005-01-19 at 22:43 +0000, Jonathan Andrews wrote: > > > > > Is XDMCP, remote X bust in core 3 ? > > > > > > > > I was using it not so long ago and it was working fine. > > > > > > > > > I've tried the gui configuration for tool gdm. The machine has no > > > > > firewall enabled - all I get the "gdm_child_action: Aborting display > > > > > jonspc:1" in the log ? > > > > > > > > I'm suprised that's the only message you get - a glance at the code > > > > suggests if you're getting this error message (which is from the master) > > > > you should be getting another message from the slave. > > > If found my problem, its a name resolver issue (thank you Mr Cox :-D ) > > > I think email is on a go-slow, please look back if you have time. > > > > > > Some comments on this and a few other things > > > > > > 1) gdm doesn't have a process itself, it runs from init - but when gdm > > > is started it seems to undergo a name change to "gdm-binary" without > > > being owned by gdm or anything called gdm. As a result its not possible > > > to cleanly restart gdm ? ie no "/etc/init.d/gdm restart". Am I missing > > > something here or this a bit naff ? > > > > > > > it is. But you have the tools gdm-restart etc. (just type gdm*tabtab* > > and you'l find 'em > > Thanks, i've found it - yet another small shell script. In a way you > are making my point nicely. Gnome broke the way xdm works when they > ported it into gnome, then they keep bodging on another shell script for > the functionality thats missing. I know in the global scheme of things > its a minor point, but breaking the sensible way process control works > just to add a few lines of logic before and after the process seems to > be a bit ... well ... you get the idea ! > > I have to admit gdm is pretty though (after xdm anything looks better) > :-) - but to many bodges ... > Agreed. Which rc.d(or is it init.d? what is the difference? and what is the diff between "tellinit 3" and "init 3" as i like to do it?) script starts GDM, anyway? why not have a separate script in there, controlling gdm? The /etc/init.d/servicename {start|stop|restart|status} is pretty standard. Standards means consistency, consistency means user-friendlyness (no matter how andvanced an user you are). > *** warning - nasty idea for Unix purists *** > Linux is general seems a bit confused about process control, init, > xinetd and rc all overlap slightly in functionality. Couldn't the entire > machine come up with just a slightly better xinetd and config files ? > xinetd treats socket connects as an event - but isn't starting, stopping > or changing runlevel just another event ? > > Jon > > From andreas at conectiva.com.br Thu Jan 20 19:06:52 2005 From: andreas at conectiva.com.br (Andreas Hasenack) Date: Thu, 20 Jan 2005 17:06:52 -0200 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <41EE9B85.4030206@insitesinc.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> <20050119165356.GD11983@burma.localdomain> <1106154283.5881.2396.camel@jonspc> <41EE9B85.4030206@insitesinc.com> Message-ID: <20050120190651.GF22321@conectiva.com.br> On Wed, Jan 19, 2005 at 11:40:21AM -0600, Michael Favia wrote: > Apt downloads (or did) semi-large digests that contain information about > the packages currently available on the repo (which is updated every They are less in size than what yum downloads, because the pkglist file used by apt doesn't have to list all files inside packages. yum downloads rpm headers which can be as big as 600kb for a single package (read: tetex). At least in my upgrade it showed me it was downloading 600kb of headers for tetex. And afterwards it would download tetex itself, headers again of course. > time the repo is updated) this digest is used to determine what is new > and what dependencies exist between packages. Yum (recent versions at > least) on the other hand downloads a brief (read: smaller) listing of > the packages (with some meta data i think but not sure what) and then > fetches the headers of the rpms independently to do dep resolution. I just today tried yum from FC3 and here are my complaints (bear in mind that these may have been addressed in a newer version: what I tested was from a fresh FC3 install): - yum update gives you absolutely no idea how long the download will take - yum update is *really* verbose. You get pages and pages of data even before getting a list of packages which will be upgraded - yum update can't be aborted: ctrl-c just aborts the current download and then yum proceeds to the next one where you have to press ctrl-c again and so on. - after downloading lots of headers and after lots of screens filled with information yum finally showed me what packages would be upgraded/obsoleted/removed. Then the packages would be downloaded and, again, there was no indication of how long that would take. The ETA displayed was for each package, and not the whole download. - yum update also doesn't tell you how big the download is in terms of size (how many megabytes?) > I too was an apt user during fc1 and 2 but in the middle of fc2 i > switched to yum because it is native, well supported and pretty well > feature laden. I have issues with it like i do with most packages (and I think that (being native which means it's the official update method for a distro) is a very important reason. After all, the distro maintainers wouldn't care if you had a problem with something outside their distro. From jspaleta at gmail.com Thu Jan 20 19:46:36 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 20 Jan 2005 14:46:36 -0500 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <20050120190651.GF22321@conectiva.com.br> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> <20050119165356.GD11983@burma.localdomain> <1106154283.5881.2396.camel@jonspc> <41EE9B85.4030206@insitesinc.com> <20050120190651.GF22321@conectiva.com.br> Message-ID: <604aa791050120114670f9a1fb@mail.gmail.com> On Thu, 20 Jan 2005 17:06:52 -0200, Andreas Hasenack > They are less in size than what yum downloads, because the pkglist file > used by apt doesn't have to list all files inside packages. You are talking about apt for rpm here or are you basing this on experience of using apt with debian packages? My understanding is .deb packages don't have a native understanding of 'file dependancies' where as .rpm packages do. My understanding is dated to mid 2003 which was the last time i read up on the differences between the .deb and .rpm packaging formats... so I might have an out of date understanding, Once you have explicit file dependancies like "Requires /sbin/ldconfig" in packages you have to make some effort to grab the file lists to be able to resolve that sort of requirement. How else do you resolve file dependancies, if you don't have the per-package file lists? And I'm pretty sure the metadata structures yum is using now 2.1.x don't download all the filelists unless an exotic file dependancy has to be met. I'm pretty sure that commonly used filelist information (things like (/usr)/(s)bin/* , /etc/* and /var/lib/*) is stored in the primary.xml metadata file.. while the full file lists (things like /usr/share/docs/*) are kept in filelists.xml. -jef From andreas at conectiva.com.br Thu Jan 20 19:52:24 2005 From: andreas at conectiva.com.br (Andreas Hasenack) Date: Thu, 20 Jan 2005 17:52:24 -0200 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <604aa791050120114670f9a1fb@mail.gmail.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> <20050119165356.GD11983@burma.localdomain> <1106154283.5881.2396.camel@jonspc> <41EE9B85.4030206@insitesinc.com> <20050120190651.GF22321@conectiva.com.br> <604aa791050120114670f9a1fb@mail.gmail.com> Message-ID: <20050120195224.GL22321@conectiva.com.br> On Thu, Jan 20, 2005 at 02:46:36PM -0500, Jeff Spaleta wrote: > On Thu, 20 Jan 2005 17:06:52 -0200, Andreas Hasenack > > They are less in size than what yum downloads, because the pkglist file > > used by apt doesn't have to list all files inside packages. > > You are talking about apt for rpm here or are you basing this on > experience of using apt with debian packages? My understanding is apt-rpm, I don't know about apt for debian. > .deb packages don't have a native understanding of 'file dependancies' > where as .rpm packages do. My understanding is dated to mid 2003 Correct, rpm has file dependencies and many of them are automatic ones (library sonames, for example) > which was the last time i read up on the differences between the .deb > and .rpm packaging formats... so I might have an out of date > understanding, > > Once you have explicit file dependancies like "Requires > /sbin/ldconfig" in packages you have to make some effort to grab the > file lists to be able to resolve that sort of requirement. How else > do you resolve file dependancies, if you don't have the per-package > file lists? apt-rpm has a smaller file list. It doesn't include all package files, just some like those in *bin* directories and libraries and some others which I don't recall now. > And I'm pretty sure the metadata structures yum is using now 2.1.x > don't download all the filelists unless an exotic file dependancy has > to be met. I'm pretty sure that commonly used filelist information > (things like (/usr)/(s)bin/* , /etc/* and /var/lib/*) is stored in the > primary.xml metadata file.. while the full file lists (things like > /usr/share/docs/*) are kept in filelists.xml. I was under the impression that the *rpm headers* yum downloaded would contain all files inside the package. This is a somewhat two step update, right? First it downloads this xml file and then the rpm headers. At least seemed that way when I fired it up here with FC3. If not, then I don't know what that 600kb "header" download from tetex contained. From michael.favia at insitesinc.com Thu Jan 20 19:54:48 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 20 Jan 2005 13:54:48 -0600 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <20050120190651.GF22321@conectiva.com.br> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> <20050119165356.GD11983@burma.localdomain> <1106154283.5881.2396.camel@jonspc> <41EE9B85.4030206@insitesinc.com> <20050120190651.GF22321@conectiva.com.br> Message-ID: <41F00C88.1010504@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Hasenack wrote: | On Wed, Jan 19, 2005 at 11:40:21AM -0600, Michael Favia wrote: | |>Apt downloads (or did) semi-large digests that contain information about |>the packages currently available on the repo (which is updated every | | | They are less in size than what yum downloads, because the pkglist file | used by apt doesn't have to list all files inside packages. yum downloads | rpm headers which can be as big as 600kb for a single package (read: tetex). | At least in my upgrade it showed me it was downloading 600kb of headers for | tetex. And afterwards it would download tetex itself, headers again of course. Good point. Which means that using headers for dep resolution only makes bandwidth sense if: p = size of pkglist file in apt repo y = size of yum md file n = average number of packages to install or upgrade h = average size of a header file p < y + n * h Make sure you include the times when no update is required in your n average. Discount that against the number of times you try to do that while the repomd/pkglist file is unchanged (which is not downloaded at that time unde reither method). The header files are downloaded by both methods the second time so they are really a sunk cost in comparative terms. But because yum has them already perhaps it could be avoided under that mechanism. But i a=nd most people would argue that it doesnt make sense because then you lose the wholeness of the rpm for other fetching purposes unless you have 3 sections: "rpms", "headers", "headless rpms". Which drastically iincreases storage requirements and bandwidth in case of error. | I just today tried yum from FC3 and here are my complaints (bear in mind that | these may have been addressed in a newer version: what I tested was from a | fresh FC3 install): There is a newer version that is cleaned up quite a bit. | - yum update gives you absolutely no idea how long the download will take Does now have file ETA | - yum update is *really* verbose. You get pages and pages of data even before | getting a list of packages which will be upgraded I agree here but it is cleaning up a bit each time and eventually there will be detractors saying "what is going on? give us more output" too. :). But generally yes i think a simplification of the pout put would be appreciated. | - yum update can't be aborted: ctrl-c just aborts the current download and | then yum proceeds to the next one where you have to press ctrl-c again and | so on. I've noticed this as well. But actually Yum does bail out eventually normally (but does go to next mirror). Havent tested when or why. | - after downloading lots of headers and after lots of screens filled with | information yum finally showed me what packages would be upgraded/obsoleted/removed. | Then the packages would be downloaded and, again, there was no indication of | how long that would take. The ETA displayed was for each package, and not the | whole download. Dont know this status but i think it still remains in my version. | - yum update also doesn't tell you how big the download is in terms of size | (how many megabytes?) Real issue too. Ill check up on the yum lists to see if i can make some usefull suggestions for output reduction/clarification and the like. Ill see what info is available and try to help bring the good info to light (Total Eta, Total Size, etc). - -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB8AyIBVsNYjF2rDYRAkzbAJ9WOIE+KO/oY01xeszrThHQb/j0+wCeKyTN 9m7nxlnQ7tExtE1nb8cgWh8= =p9Nu -----END PGP SIGNATURE----- From strange at nsk.no-ip.org Thu Jan 20 19:59:08 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Thu, 20 Jan 2005 19:59:08 +0000 Subject: XDMCP Core 3 In-Reply-To: <1106247753.5344.54.camel@localhost.localdomain> References: <1106174613.5881.2524.camel@jonspc> <1106208861.32395.4.camel@blaa> <1106220007.31944.3.camel@jonspc> <1106242053.5344.0.camel@localhost.localdomain> <1106245942.32325.67.camel@jonspc> <1106247753.5344.54.camel@localhost.localdomain> Message-ID: <20050120195908.GA7276@nsk.no-ip.org> On Thu, Jan 20, 2005 at 08:02:34PM +0100, Kyrre Ness Sjobak wrote: > Agreed. Which rc.d(or is it init.d? init.d contains scripts for services; rc?.d contains symbolic links for services to be started or stoped in that runlevel; rc.d contains those directories (on fedora). > and what is the diff between "tellinit 3" and "init 3" None. The binary is the same. It just chooses to behave as telinit instead of init by checking that its PID != 1. > starts GDM, anyway? why not have a separate script in there, controlling > gdm? If gdm is to be started earlier in the boot process, isn't that the only way? Regards, Luciano Rocha -- 1/16 From michael.favia at insitesinc.com Thu Jan 20 20:15:31 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 20 Jan 2005 14:15:31 -0600 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <41F00C88.1010504@insitesinc.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> <20050119165356.GD11983@burma.localdomain> <1106154283.5881.2396.camel@jonspc> <41EE9B85.4030206@insitesinc.com> <20050120190651.GF22321@conectiva.com.br> <41F00C88.1010504@insitesinc.com> Message-ID: <41F01163.7030204@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | Ill check up on the yum lists to see if i can make some usefull | suggestions for output reduction/clarification and the like. Ill see | what info is available and try to help bring the good info to light | (Total Eta, Total Size, etc). Beat to the punch. The newest (cvs) version of Yum is looking even nicer from the endusers perspective (cleaned up all that repomd.xml and other extra lines of repeating strings) . And the speeds that they are gettng by experiementing with sqlite patchs are very impressive. I think i might be in for the long haul and i suggest that you read through their recent devel archives for some useful information on the current situation and nearterm plans. - -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB8BFjBVsNYjF2rDYRAkI1AJ46AsN4bP5pYpM0v3SkjfaXERdD3gCfUFqF m1+U/m3IKwZF7O6efOu1RrQ= =zn9j -----END PGP SIGNATURE----- From stephen_pollei at comcast.net Thu Jan 20 20:47:06 2005 From: stephen_pollei at comcast.net (Stephen Pollei) Date: 20 Jan 2005 12:47:06 -0800 Subject: gcc optimation flags -- was Re: RFC: Optimizing for 386 In-Reply-To: <41EFBF4F.2000700@nc.rr.com> References: <20050119171047.C15870@ryoko.camperquake.de> <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <20050119170235.GV10340@devserv.devel.redhat.com> <41EFB3D8.6000800@poczta.fm> <1106230884.9780.101.camel@sheol.homelinux.org> <41EFBF4F.2000700@nc.rr.com> Message-ID: <1106254028.984.18.camel@fury> On Thu, 2005-01-20 at 06:25, Jeff Johnson wrote: > >>And what about LDFLAGS? Has anyone been experimenting with this > >>variable? I've read those two pages: > >FWIW OOo (2 at least) links with -Wl,-01 > With no objective measurement of any performance win through optimizing > LDFLAGS, as always. http://www.coyotegulch.com/reviews/intel_comp/intel_gcc_bench2.html I remember that coyote gulch did some benchmarks of gcc compilers with different flags. His site seems to be down though. The url I gave is not the study I'm really thinking of. I think that he tried a genetic algorithm type approach to try and find the "perfect" set of optimization flags to use. I'm sure of someone wants to use up a lot of cycles then someone could use a lot of benchmarks with different combinations of flags to find the perfect match for some programs. You could use simulated annealing or genetic algorithms if you didn't want to exercise each and every combination. -- http://dmoz.org/profiles/pollei.html http://sourceforge.net/users/stephen_pollei/ http://www.orkut.com/Profile.aspx?uid=2455954990164098214 http://stephen_pollei.home.comcast.net/ GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1 3C01 910F 6BB5 4A7D 9677 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mnemo at minimum.se Fri Jan 21 05:43:15 2005 From: mnemo at minimum.se (Martin Olsson) Date: Thu, 20 Jan 2005 21:43:15 -0800 Subject: Parallel preloading when viewing from browser (was: Optimizing for 386) In-Reply-To: <1106244351.5344.36.camel@localhost.localdomain> References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> <1106172965.2663.16.camel@localhost.localdomain> <1106179640.5599.6.camel@stargrazer.home.awesomeplay.com> <1106244351.5344.36.camel@localhost.localdomain> Message-ID: <41F09673.1050700@minimum.se> > > Then they log on to/borrow mine/ask me nicely to check something. Just > some plan, standard form ETC. I open the page in the webbrowser (no > problem, quick. The firefox start-up delay is at least tolerable, if not > optimal), and click the link. Do i want to open it in > /home/kyrre/.redhat-openoffice(etc)? Yes. > > One thing I always wished for x-mas but never got it this: First the bad case (how it today afaik): 1. I click the .doc and select "open with BLAH_PROG" 2. There is some waiting while it's downloaded into doh.tmp 3. The browser executes "BLAH_PROG doh.tmp" 4. There is some waiting for the app. 5. My doc is done. Here is how I always wanted it to be instead: 1. I click the .doc and select "open with BLAH_PROG" 2. The browser tells program BLAH_PROG to launch and wait for a doc 3. I want for the .doc to download and parallely BLAH_PROG launches 5. My doc is done. See how this would save a lof of time, especially when viewing docs from servers with highload (low bandwidth) and on a client with little RAM (long launch time)? This is something not even Windows has yet. PS. This is of course very similar to the idea of parallelizing the boot process (such a discussion for seen on this list not too long ago) and I'm sure there are TONS if other places where such parallellization would speed up things conderiably! DS. regards, martin From ssaccone at link.wustl.edu Thu Jan 20 21:42:48 2005 From: ssaccone at link.wustl.edu (Scott Saccone) Date: Thu, 20 Jan 2005 15:42:48 -0600 Subject: gcc -m32 failure on FC2 x86_64 Message-ID: <1106257368.2726.28.camel@localhost.localdomain> I'm using the x86_64 of FC2 and FC3 and I cannot use gcc with the -m32 option. Compiling helloworld using gcc -m32 yields "/usr/bin/ld: crt1.o: No such file: No such file or directory collect2: ld returned 1 exit status". Is this because the glibc package has not installed the files needed for the -m32 option? The file /usr/lib64/crt1.o exists, but not /usr/lib/crt1.o. I've installed the latest versions of this package with up2date. Others have reported this, and have flirted with the idea of installing files from the i386 version of glibc, but I would prefer to find a "real" solution. This is pretty serious problem for me as there are some apps that don't seem to run with plain gcc - seg faults perhaps due to the assumption of 4 byte pointers. Also in the lastest version GRUB the configure program fails when it attempts to compile something using -m32. SPECS: CPU: 2 x 3.2GHz Xeon Nocona Linux: 2.6.5-1.358smp Distro: FC2 x86_64 gcc: 3.3.3 20040412 (Red Hat Linux 3.3.3-7) and CPU: AMD64 3400+ Linux: not sure (no access at the moment) Distro: FC3 x86_64 gcc: not sure From sopwith at redhat.com Thu Jan 20 21:34:41 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 20 Jan 2005 16:34:41 -0500 (EST) Subject: gcc -m32 failure on FC2 x86_64 In-Reply-To: <1106257368.2726.28.camel@localhost.localdomain> References: <1106257368.2726.28.camel@localhost.localdomain> Message-ID: On Thu, 20 Jan 2005, Scott Saccone wrote: > > I'm using the x86_64 of FC2 and FC3 and I cannot use gcc with the -m32 > option. Compiling helloworld using gcc -m32 yields "/usr/bin/ld: crt1.o: > No such file: No such file or directory collect2: ld returned 1 exit > status". You need the i386 glibc-devel package installed (and dependencies) in order to compile & link most programs. -- Elliot From n3npq at nc.rr.com Thu Jan 20 22:03:49 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 20 Jan 2005 17:03:49 -0500 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <20050120190651.GF22321@conectiva.com.br> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> <20050119165356.GD11983@burma.localdomain> <1106154283.5881.2396.camel@jonspc> <41EE9B85.4030206@insitesinc.com> <20050120190651.GF22321@conectiva.com.br> Message-ID: <41F02AC5.3060705@nc.rr.com> Andreas Hasenack wrote: >I just today tried yum from FC3 and here are my complaints (bear in mind that >these may have been addressed in a newer version: what I tested was from a >fresh FC3 install): >- yum update gives you absolutely no idea how long the download will take > Knowing your bw, and estimating network traffic, a priorii is no easy, nor yum, problem. >- yum update is *really* verbose. You get pages and pages of data even before > getting a list of packages which will be upgraded > Verbosity increases the likelihood os diagnosing a problem. Wrapper to redirect spewage to a log file, and invoke with -y, ain't *THAT* hard if the verbosity annoys. >- yum update can't be aborted: ctrl-c just aborts the current download and > then yum proceeds to the next one where you have to press ctrl-c again and > so on. > Blame not yum for this, rpmlib runs with signals masked. If you want/need more responsiveness, then there is a single call to check-and-exit that may need to be added to rpmlib within some loops. >- after downloading lots of headers and after lots of screens filled with > information yum finally showed me what packages would be upgraded/obsoleted/removed. > Then the packages would be downloaded and, again, there was no indication of > how long that would take. The ETA displayed was for each package, and not the > whole download. > See answer to 1). >- yum update also doesn't tell you how big the download is in terms of size > (how many megabytes?) > > This could be computed/displayed, but only in units of bytes. I suspect that knowing the size is not so useful, judging from 2 complaints regarding "how long ...", but only 1 complaint "how large ...". YMMV. > > >>I too was an apt user during fc1 and 2 but in the middle of fc2 i >>switched to yum because it is native, well supported and pretty well >>feature laden. I have issues with it like i do with most packages (and >> >> > >I think that (being native which means it's the official update method for a >distro) is a very important reason. After all, the distro maintainers wouldn't >care if you had a problem with something outside their distro. > > If you like apt, then please, by all means, *Use apt!* No one is stopping you ... 73 de Jeff From ssaccone at link.wustl.edu Thu Jan 20 23:01:56 2005 From: ssaccone at link.wustl.edu (Scott Saccone) Date: Thu, 20 Jan 2005 17:01:56 -0600 Subject: gcc -m32 failure on FC2 x86_64 In-Reply-To: References: <1106257368.2726.28.camel@localhost.localdomain> Message-ID: <1106262116.2726.36.camel@localhost.localdomain> In the past I problems getting the i386 version to install, but I finally did it with glibc-devel-2.3.3-27.1.i386.rpm from rpmfind.net. Thanks! -Scott On Thu, 2005-01-20 at 15:34, Elliot Lee wrote: > On Thu, 20 Jan 2005, Scott Saccone wrote: > > > > > I'm using the x86_64 of FC2 and FC3 and I cannot use gcc with the -m32 > > option. Compiling helloworld using gcc -m32 yields "/usr/bin/ld: crt1.o: > > No such file: No such file or directory collect2: ld returned 1 exit > > status". > > You need the i386 glibc-devel package installed (and dependencies) in > order to compile & link most programs. > > -- Elliot -- >>>NOTE NEW EMAIL: ssaccone at link.wustl.edu<<< Scott F. Saccone, Ph.D. Department of Psychiatry, Box 8134 Washington University School of Medicine 660 South Euclid Avenue Saint Louis, Missouri 63110-1093 Voice: (314) 286-2581 FAX: (314) 286-2577 Email: ssaccone at link.wustl.edu From stephen_pollei at comcast.net Thu Jan 20 23:25:14 2005 From: stephen_pollei at comcast.net (Stephen Pollei) Date: 20 Jan 2005 15:25:14 -0800 Subject: gcc optimation flags -- was Re: RFC: Optimizing for 386 In-Reply-To: <1106254028.984.18.camel@fury> References: <20050119171047.C15870@ryoko.camperquake.de> <3k77vd$gbck0f@mxip10a.cluster1.charter.net> <20050119170235.GV10340@devserv.devel.redhat.com> <41EFB3D8.6000800@poczta.fm> <1106230884.9780.101.camel@sheol.homelinux.org> <41EFBF4F.2000700@nc.rr.com> <1106254028.984.18.camel@fury> Message-ID: <1106263515.984.27.camel@fury> > I remember that coyote gulch did some benchmarks of gcc compilers with > different flags. > He tried a genetic algorithm type approach to try and find > the "perfect" set of optimization flags to use. His site is probably permanently down. I found some people had it cached and mirrored. http://geckies.user.cis.ksu.edu/tiki-view_cache.php?url=http://www.coyotegulch.com%2Facovea%2Facoveaga.html Acovea: Analysis of Compiler Options via Evolutionary Algorithm by Scott Robert Ladd . -- http://dmoz.org/profiles/pollei.html http://sourceforge.net/users/stephen_pollei/ http://www.orkut.com/Profile.aspx?uid=2455954990164098214 http://stephen_pollei.home.comcast.net/ GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1 3C01 910F 6BB5 4A7D 9677 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Jason.Haar at trimble.co.nz Thu Jan 20 23:48:39 2005 From: Jason.Haar at trimble.co.nz (Jason Haar) Date: Fri, 21 Jan 2005 12:48:39 +1300 Subject: Is there a working swsusp for FC3 2.6.10? Message-ID: <41F04357.4020108@trimble.co.nz> Hi there I've just dropped-kicked SuSE-9.1 off my new HP NX5000 (I've been using Redhat too long to change, and can't live without yum :-) and put FC3 on it. I've got WiFi working (madwifi), but one thing SuSe 9.1 had that I can't live without was the swsusp support. It was great! Hit the power button, and 10-15 sec later the laptop had written RAM to disk and turned itself off. Hit the power button again, and 15-20 sec later you were back where you started. Cool :-) Anyway, I tried installing vanilla 2.6.10 patched with the current swsusp, but it fell all over itself while booting. Laptops are so fickle! However, it likes FC3 well enough (i.e. one of the 1,000 kernel patches in it must have fixed something to do with my laptop hardware), so has anyone got a src.rpm or a patch-for-the-swsusp-patch that'll get the current FC3 kernel playing nicely with swsusp? Thanks! -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 From rodd at clarkson.id.au Thu Jan 20 23:48:07 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 21 Jan 2005 10:48:07 +1100 Subject: Fedora Core 4 In-Reply-To: <20050114223020.GA7168@nostromo.devel.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> Message-ID: <1106264887.5246.4.camel@trevally.redfishdemo.com> On Fri, 2005-01-14 at 17:30 -0500, Bill Nottingham wrote: > So, what's planned for Fedora Core 4? Here's what we're looking > at from the Red Hat side of things: > - more networking changes > > Further integration of NetworkManager Does this include getting hal to correctly recognize the capabilities of PCMCIA based wireless network cards so that Network Manager properly detects these devices. If someone would like me to file a bug report on this, then tell me where and I'll get right to it. Rodd -- >From the pain come the dream >From the dream come the vision >From the vision come the people >From the people come the power >From this power come the change - Peter Gabriel From bclark at redhat.com Fri Jan 21 00:35:15 2005 From: bclark at redhat.com (Bryan Clark) Date: Thu, 20 Jan 2005 19:35:15 -0500 Subject: Fedora Core 4 In-Reply-To: <1106264887.5246.4.camel@trevally.redfishdemo.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1106264887.5246.4.camel@trevally.redfishdemo.com> Message-ID: <1106267715.12773.23.camel@rhbw.boston.redhat.com> On Fri, 2005-01-21 at 10:48 +1100, Rodd Clarkson wrote: > On Fri, 2005-01-14 at 17:30 -0500, Bill Nottingham wrote: > > > So, what's planned for Fedora Core 4? Here's what we're looking > > at from the Red Hat side of things: > > > - more networking changes > > > > Further integration of NetworkManager > > Does this include getting hal to correctly recognize the capabilities of > PCMCIA based wireless network cards so that Network Manager properly > detects these devices. This is actually about making applications aware of network changes and properties. For instance Dan Reed is working on making the DHCP options available through NetworkManager. This means that the web browser will be able to query NetworkManager for proxy settings to use for accessing the internet. Also the web browser would be aware of the network going up or down so you wouldn't get error dialogs when the network is down. Instead we can show you the state of your network and give you the choice to connect to a different wireless network (for instance). PCMCIA cards should be detected properly in NetworkManager as long as HAL detects them properly. You can search [0] the NetworkManager list for previous discussion on this [1]. Otherwise if you know it's a problem with HAL you could try the HAL Bugzilla [2]. Cheers, ~ Bryan [0] http://www.google.com/search?q=networkmanager%20PCMCIA%20HAL%20site:mail.gnome.org [1] http://mail.gnome.org/archives/networkmanager-list/2005-January/msg00022.html [2] https://bugs.freedesktop.org/enter_bug.cgi?product=hal From david at fubar.dk Fri Jan 21 00:45:12 2005 From: david at fubar.dk (David Zeuthen) Date: Thu, 20 Jan 2005 19:45:12 -0500 Subject: Fedora Core 4 In-Reply-To: <1106267715.12773.23.camel@rhbw.boston.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1106264887.5246.4.camel@trevally.redfishdemo.com> <1106267715.12773.23.camel@rhbw.boston.redhat.com> Message-ID: <1106268312.4240.2.camel@daxter.boston.redhat.com> On Thu, 2005-01-20 at 19:35 -0500, Bryan Clark wrote: > [2] https://bugs.freedesktop.org/enter_bug.cgi?product=hal > Actually, rather use the Red Hat Bugzilla for hal bugs https://bugzilla.redhat.com Thanks, David From michael.favia at insitesinc.com Fri Jan 21 00:54:47 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 20 Jan 2005 18:54:47 -0600 Subject: Parallel preloading when viewing from browser In-Reply-To: <41F09673.1050700@minimum.se> References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> <1106172965.2663.16.camel@localhost.localdomain> <1106179640.5599.6.camel@stargrazer.home.awesomeplay.com> <1106244351.5344.36.camel@localhost.localdomain> <41F09673.1050700@minimum.se> Message-ID: <41F052D7.5090602@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Olsson wrote: > Here is how I always wanted it to be instead: > 1. I click the .doc and select "open with BLAH_PROG" > 2. The browser tells program BLAH_PROG to launch and wait for a doc > 3. I want for the .doc to download and parallely BLAH_PROG launches > 5. My doc is done. Simple but very good idea i think. It requires a little more "situational awareness" i think. The filemanager will need to have someway to evoke a load document event of some type right? Unless you can count on launching the app (empty) and then launching the app again (with document title appended and some unique switch) Which would revert to the current running instance. But you can't depend on that type of behavior for most apps for some time. Or is there an easier implementation? - -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB8FLXBVsNYjF2rDYRAuEvAJoDryozbLg1gTH7z10b4euwWRxSfQCfazSN 77+Cfbb7P/bFfTAorNyxFrs= =BAkZ -----END PGP SIGNATURE----- From rodd at clarkson.id.au Fri Jan 21 02:16:05 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 21 Jan 2005 13:16:05 +1100 Subject: Fedora Core 4 In-Reply-To: <1106267715.12773.23.camel@rhbw.boston.redhat.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1106264887.5246.4.camel@trevally.redfishdemo.com> <1106267715.12773.23.camel@rhbw.boston.redhat.com> Message-ID: <1106273766.5246.12.camel@trevally.redfishdemo.com> On Thu, 2005-01-20 at 19:35 -0500, Bryan Clark wrote: > On Fri, 2005-01-21 at 10:48 +1100, Rodd Clarkson wrote: > > On Fri, 2005-01-14 at 17:30 -0500, Bill Nottingham wrote: > > > > > So, what's planned for Fedora Core 4? Here's what we're looking > > > at from the Red Hat side of things: > > > > > - more networking changes > > > > > > Further integration of NetworkManager > > > > Does this include getting hal to correctly recognize the capabilities of > > PCMCIA based wireless network cards so that Network Manager properly > > detects these devices. > > PCMCIA cards should be detected properly in NetworkManager as long as > HAL detects them properly. You can search [0] the NetworkManager list > for previous discussion on this [1]. Otherwise if you know it's a > problem with HAL you could try the HAL Bugzilla [2]. The NM list doesn't have much on this (and mostly from me - I'm on the list). As far as I'm aware, the problem is that hal doesn't recognise the capabilites of the PCMCIA card. It should have an entry something like: info.cababilities string net.80211 net but it doesn't list any info.capabilities. I'm going to file this against HAL and see what happens. see: BUG #145750 ( https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145750 ) Rodd -- >From the pain come the dream >From the dream come the vision >From the vision come the people >From the people come the power >From this power come the change - Peter Gabriel From gemi at bluewin.ch Fri Jan 21 02:30:41 2005 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 21 Jan 2005 03:30:41 +0100 Subject: Fedora updates CD-ROM? Message-ID: <1106274641.6091.2.camel@scriabin.tannenrauch.ch> I recently installed FC3 and had to go through the update procedure and download several hundreds of megabytes. I could imagine that once or twice an Updates CD-ROM would be released. The Fedora installer might ask after an installation for the user to insert an Updates CD-ROM if available, and perform the required updates. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From davej at redhat.com Fri Jan 21 02:41:51 2005 From: davej at redhat.com (Dave Jones) Date: Thu, 20 Jan 2005 21:41:51 -0500 Subject: rawhide report: 20050120 changes In-Reply-To: <1106229698.6742.36.camel@laptopd505.fenrus.org> References: <200501201336.j0KDaN700648@porkchop.devel.redhat.com> <1106229698.6742.36.camel@laptopd505.fenrus.org> Message-ID: <20050121024151.GD32430@redhat.com> On Thu, Jan 20, 2005 at 03:01:37PM +0100, Arjan van de Ven wrote: > > kernel-2.6.10-1.1103_FC4 > > ------------------------ > > * Wed Jan 19 2005 Dave Jones > > - Re-add diskdump/netdump based on Jeff Moyers patches. > > - Rebase to -bk7 > > why is this gunk added back to the fedora kernel? > I can see trying to get kexec-dump working instead as useful, but > diskdump/netdump? God no. It's a transitional thing until upstream has something that's usable. The kernel-side is still seeing quite a lot of churn judging by the amount of change seen in yesterdays -mm update, and userspace is clearly lacking. Until we have all the pieces, this is what we have as a stopgap. Dave From mpeters at mac.com Fri Jan 21 02:54:20 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 21 Jan 2005 02:54:20 +0000 Subject: Fedora updates CD-ROM? In-Reply-To: <1106274641.6091.2.camel@scriabin.tannenrauch.ch> (from gemi@bluewin.ch on Thu Jan 20 18:30:41 2005) References: <1106274641.6091.2.camel@scriabin.tannenrauch.ch> Message-ID: <1106276060l.6979l.0l@devel.mpeters.us> On 01/20/2005 06:30:41 PM, G?rard Milmeister wrote: > I recently installed FC3 and had to go through the update procedure > and > download several hundreds of megabytes. > > I could imagine that once or twice an Updates CD-ROM would be > released. > The Fedora installer might ask after an installation for the user to > insert an Updates CD-ROM if available, and perform the required > updates. http://mpeters.us/linux/fedora_c3_updates.php It's not from RH/Fedora, it's my own creation (created nightly from cron - lftp mirror - so it is always fresh) but all the updates are from Fedora - and signed by the Fedora GPG key. I use it when setting up someone on Fedora who can't bring their PC to my house, it brings there boxes right up to patch level easily and painlessly. Put DVD in, run autorun, and it updates the system through yum from the CD (w/o altering your system yum configuration, and respecting any excludes in main yum.conf or /etc/yum.repos.d/fedora-updates.repo) There's also another company that for $99.00 a year (I think - I might have that wrong) sends you new install CD's every month that have all the updates integrated right into Anaconda - which is the better solution probably for the IT department that does a lot of Fedora installs. I don't remember the companies name, but I suspect someone here will. From barryn at pobox.com Fri Jan 21 03:09:30 2005 From: barryn at pobox.com (Barry K. Nathan) Date: Thu, 20 Jan 2005 19:09:30 -0800 Subject: Is there a working swsusp for FC3 2.6.10? In-Reply-To: <41F04357.4020108@trimble.co.nz> References: <41F04357.4020108@trimble.co.nz> Message-ID: <20050121030930.GA6292@ip68-4-98-123.oc.oc.cox.net> On Fri, Jan 21, 2005 at 12:48:39PM +1300, Jason Haar wrote: > Anyway, I tried installing vanilla 2.6.10 patched with the current > swsusp, but it fell all over itself while booting. Laptops are so fickle! If you don't mind, please be more specific than "patch with the current swsusp". There are at least two different swsusp forks that could both be considered "current"... -Barry K. Nathan From Jason.Haar at trimble.co.nz Fri Jan 21 06:01:31 2005 From: Jason.Haar at trimble.co.nz (Jason Haar) Date: Fri, 21 Jan 2005 19:01:31 +1300 Subject: Is there a working swsusp for FC3 2.6.10? In-Reply-To: <20050121030930.GA6292@ip68-4-98-123.oc.oc.cox.net> References: <41F04357.4020108@trimble.co.nz> <20050121030930.GA6292@ip68-4-98-123.oc.oc.cox.net> Message-ID: <41F09ABB.1060503@trimble.co.nz> Barry K. Nathan wrote: >On Fri, Jan 21, 2005 at 12:48:39PM +1300, Jason Haar wrote: > > >>Anyway, I tried installing vanilla 2.6.10 patched with the current >>swsusp, but it fell all over itself while booting. Laptops are so fickle! >> >> > >If you don't mind, please be more specific than "patch with the current >swsusp". There are at least two different swsusp forks that could both >be considered "current"... > > > Oh - that's news to me. I only know of swsusp.sf.net. ...I guess that'd be why I wasn't any more specific ;-) Care to point me at the forks? -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 From technojoecoolusa at charter.net Fri Jan 21 06:14:38 2005 From: technojoecoolusa at charter.net (Joseph D. Wagner) Date: Fri, 21 Jan 2005 00:14:38 -0600 Subject: RFC: Optimizing for 386 In-Reply-To: <200501192242.56462.moe@blagblagblag.org> Message-ID: <3k70mg$l3n28t@mxip15a.cluster1.charter.net> > If you think there will be a performance gain, then rebuild /one/ > RPM with the optimizations you want and show how much faster it is. I actually did that once. I recompiled KDE from scratch. 36 hours. No noticeable difference. Then I recompiled the underlying Qt libraries from scratch. 5 hours. A few seconds here, a few seconds there. Then I recompiled XFree86 from scratch. 4 hours. Now we're starting to talk increased responsiveness. Then XFree86 became Xorg, and both Qt and KDE came out with a new version of there programs, and everything had to be recompiled from scratch all over again. The problem is EVERYTHING from the ground up has to be optimized to feel the cumulative effect. There is no way you are going to convince me that being optimized for a 386 is OK when I felt the effectiveness of optimizing the graphics programs. However, because I didn't do my tests in a "scientific" manor with precise measurements, the developers won't even consider my results. > the developers explain over & over that there won't be > these performance gains people think there will be These same people say that theoretically EXT3 with Data Ordered mode should be faster that EXT3 with Data Journaled mode, but reality has proven that this isn't the case. I'd like just one of these developers to take the hours of compiling time necessary to produce an optimized version and test the results. I think the results would be equally surprising. > In sum, "the huge numbers of people" are asking for something > that... will hurt others Who? Who is still using a 386? A 486? Do anyone on this list have anything less than a 586? Who are these victims of my push for better optimizations? Joseph D. Wagner From mattdm at mattdm.org Fri Jan 21 06:15:38 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 21 Jan 2005 01:15:38 -0500 Subject: Is there a working swsusp for FC3 2.6.10? In-Reply-To: <41F09ABB.1060503@trimble.co.nz> References: <41F04357.4020108@trimble.co.nz> <20050121030930.GA6292@ip68-4-98-123.oc.oc.cox.net> <41F09ABB.1060503@trimble.co.nz> Message-ID: <20050121061538.GA12868@jadzia.bu.edu> On Fri, Jan 21, 2005 at 07:01:31PM +1300, Jason Haar wrote: > Oh - that's news to me. I only know of swsusp.sf.net. > ...I guess that'd be why I wasn't any more specific ;-) > Care to point me at the forks? It was my understanding that they've actually been merged back together at this point. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Fri Jan 21 06:17:19 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 21 Jan 2005 01:17:19 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <3k70mg$l3n28t@mxip15a.cluster1.charter.net> References: <200501192242.56462.moe@blagblagblag.org> <3k70mg$l3n28t@mxip15a.cluster1.charter.net> Message-ID: <20050121061719.GB12868@jadzia.bu.edu> On Fri, Jan 21, 2005 at 12:14:38AM -0600, Joseph D. Wagner wrote: > However, because I didn't do my tests in a "scientific" manor with precise > measurements, the developers won't even consider my results. Well, do you blame them? Effectively, you _have no results_. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From perbj at stanford.edu Fri Jan 21 06:28:41 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Thu, 20 Jan 2005 22:28:41 -0800 Subject: Is there a working swsusp for FC3 2.6.10? In-Reply-To: <20050121061538.GA12868@jadzia.bu.edu> References: <41F04357.4020108@trimble.co.nz> <20050121030930.GA6292@ip68-4-98-123.oc.oc.cox.net> <41F09ABB.1060503@trimble.co.nz> <20050121061538.GA12868@jadzia.bu.edu> Message-ID: <1106288921.5199.6.camel@localhost.localdomain> On Fri, 2005-01-21 at 01:15 -0500, Matthew Miller wrote: > On Fri, Jan 21, 2005 at 07:01:31PM +1300, Jason Haar wrote: > > Oh - that's news to me. I only know of swsusp.sf.net. > > ...I guess that'd be why I wasn't any more specific ;-) > > Care to point me at the forks? > > It was my understanding that they've actually been merged back together at > this point. Well, the in-tree implementations (swsusp and pmdisk) have been merged as far as I have understood but I don't think that swsusp2 (which is what can be found at swsusp.sf.net) is merged. In any case, software suspend is not enabled in the Fedora kernels as the Fedora kernel developers find it ugly and dangerous - at least that was the last that was the understanding I got last time this was discussed on this list. /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From Jason.Haar at trimble.co.nz Fri Jan 21 06:36:18 2005 From: Jason.Haar at trimble.co.nz (Jason Haar) Date: Fri, 21 Jan 2005 19:36:18 +1300 Subject: Is there a working swsusp for FC3 2.6.10? In-Reply-To: <1106288921.5199.6.camel@localhost.localdomain> References: <41F04357.4020108@trimble.co.nz> <20050121030930.GA6292@ip68-4-98-123.oc.oc.cox.net> <41F09ABB.1060503@trimble.co.nz> <20050121061538.GA12868@jadzia.bu.edu> <1106288921.5199.6.camel@localhost.localdomain> Message-ID: <41F0A2E2.7060600@trimble.co.nz> Per Bjornsson wrote: >In any case, software suspend is not enabled in the Fedora kernels as >the Fedora kernel developers find it ugly and dangerous - at least that >was the last that was the understanding I got last time this was >discussed on this list. > > > Yes - and hence my explanation that I am running a HP NX5000 which comes with SuSE 9.1 - where swsusp is implemented and works splendidly. It appears SuSE and Redhat differ on this account. That's why I'm trying to find out if anyone has got it working -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 From arjanv at redhat.com Fri Jan 21 07:19:07 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Fri, 21 Jan 2005 08:19:07 +0100 Subject: rawhide report: 20050120 changes In-Reply-To: <20050121024151.GD32430@redhat.com> References: <200501201336.j0KDaN700648@porkchop.devel.redhat.com> <1106229698.6742.36.camel@laptopd505.fenrus.org> <20050121024151.GD32430@redhat.com> Message-ID: <20050121071907.GA22443@devserv.devel.redhat.com> On Thu, Jan 20, 2005 at 09:41:51PM -0500, Dave Jones wrote: > On Thu, Jan 20, 2005 at 03:01:37PM +0100, Arjan van de Ven wrote: > > > > kernel-2.6.10-1.1103_FC4 > > > ------------------------ > > > * Wed Jan 19 2005 Dave Jones > > > - Re-add diskdump/netdump based on Jeff Moyers patches. > > > - Rebase to -bk7 > > > > why is this gunk added back to the fedora kernel? > > I can see trying to get kexec-dump working instead as useful, but > > diskdump/netdump? God no. > > It's a transitional thing until upstream has something that's usable. ok that makes me wonder if diskdump offers value to fedora users at all; it doesn't work with lvm (which is the default installation) for example. > > The kernel-side is still seeing quite a lot of churn judging by > the amount of change seen in yesterdays -mm update, and userspace > is clearly lacking. I thought this was rawhide. Also it's a chicken and egg situation; userspace is somewhat there (at least in prototype form) but it will never get there unless some kernels ship/enable the kernel side From pri.rhl3 at iadonisi.to Fri Jan 21 07:54:07 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Fri, 21 Jan 2005 02:54:07 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <3k70mg$l3n28t@mxip15a.cluster1.charter.net> References: <3k70mg$l3n28t@mxip15a.cluster1.charter.net> Message-ID: <1106294047.6476.33.camel@md.local.linuxlobbyist.org> On Fri, 2005-01-21 at 00:14 -0600, Joseph D. Wagner wrote: > > If you think there will be a performance gain, then rebuild /one/ > > RPM with the optimizations you want and show how much faster it is. > > I actually did that once. I recompiled KDE from scratch. 36 hours. > No noticeable difference. Then I recompiled the underlying Qt > libraries from scratch. 5 hours. A few seconds here, a few seconds > there. Then I recompiled XFree86 from scratch. 4 hours. Now we're > starting to talk increased responsiveness. > > Then XFree86 became Xorg, and both Qt and KDE came out with a new > version of there programs, and everything had to be recompiled from > scratch all over again. > > The problem is EVERYTHING from the ground up has to be optimized to > feel the cumulative effect. There is no way you are going to convince > me that being optimized for a 386 is OK when I felt the effectiveness > of optimizing the graphics programs. > > However, because I didn't do my tests in a "scientific" manor with > precise measurements, the developers won't even consider my results. I'd like to suggest for you to rally support from a few people to go through the recompilations necessary for the entire distribution (suggest using FC3 as the base) to prove the points you've been making. There are a few things I think you will need to consider if you want to be convincing. First, provide the entire resulting RPMS for download (bittorrent to share bandwidth) for others to help out with benchmarking. For the truly paranoid (and to comply with most FOSS licenses), provide the SRPMS as well. Next, be sure that anyone who does the 'subjective' part of the test has two *identical* machines side by side to test simultaneously. If anyone's going to trust someone saying "It's faster" without hard numbers, it'll be a hard sell unless there are no time and space separators involved in the test. I'd also suggest making *both* machines dual boot with both the original distro and the recompiled distro. Boot one machine to the original and one to the recompiled distro. Time the boots. Login and time the login times. Launch OpenOffice.org. Launch Mozilla. Launch evolution. Maybe do an 'rpmbuild --rebuild --target=i686 ' on both at the same time and check out responsiveness during the build. But do the same things at roughly the same time on each machine. Time how long it takes to launch each app under various conditions. Now repeat all testing, switching which version (original vs. recompiled) is used on each machine. This will help confirm that there are no unknown difference that have any significant impact on performance. (It happens, even with supposedly identical hardware ... anybody remember Gateway's graphics card of the month? Even identical model number cards can have different chipsets.) You may want to try the same tests with KDE as your default desktop or XFCE as well. Be aware that even sometimes small variations in what you do between the two boxes can (potentially) have significant impact later in testing, so keep what you do as identical as humanly possible. You don't need a lot of people for this, but you do need some dedication to coming up with some numbers. If the above steps are taken and you can come back with some rough numbers with a *real* recompiled *full* distribution (or at least as full as you'd like to advocate ... don't bother with bash if you think it won't matter). Or maybe consider just picking some of the key ones you've mentioned to start with like xorg-x11, qt, gtk2, kde, and gnome. This whole exercise can serve a dual purpose. If you end up having trouble garnering the support you need to do this kind of testing, then just maybe there aren't as many people clamoring for this kind thing as you claim. Or at least not as many people who want it who are willing to prove their point. Consider that if anyone wants to make a claim that retargeting the distro for i586 or i686 or i686 with cmov or whatever will improve performance, and if he wants anyone to believe that he has the expertise to make that claim, then he should have the expertise (and the willingness!) to prove it by take the steps I've outlined above, or something vaguely similar. If you *do* get lots of people to participate, then the task will be completed much more quickly and you will have some hard evidence to report to those putting the distribution together for them to consider. Note what I'm suggesting here is not full-on scientific benchmarking. But some initial hard numbers are necessary to convince the people who will have to expend the most effort to implement what you are suggesting. More thorough testing can be done by more people if your results show promise. One other thing you need to keep in mind as well: a modest improvement may not be considered reason enough to make the change. Particularly if it leaves certain hardware in the dust. And I'm not talking about 386s, but some 686s (VIA?) that won't run the resulting binaries. At least that's what I'm hearing from people who know, like Alan Cox, if I've understood correctly. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From seyman at wanadoo.fr Fri Jan 21 10:12:41 2005 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Fri, 21 Jan 2005 11:12:41 +0100 Subject: Fedora updates CD-ROM? In-Reply-To: <1106276060l.6979l.0l@devel.mpeters.us> References: <1106274641.6091.2.camel@scriabin.tannenrauch.ch> <1106276060l.6979l.0l@devel.mpeters.us> Message-ID: <20050121101241.GA7347@orient.maison.moi> On Fri, Jan 21, 2005 at 02:54:20AM +0000, Michael A. Peters wrote: > > I don't remember the companies name, but I suspect someone here will. KRUD : http://www.tummy.com/krud/ Emmanuel From rms at 1407.org Fri Jan 21 10:18:41 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 21 Jan 2005 10:18:41 +0000 Subject: Is there a working swsusp for FC3 2.6.10? In-Reply-To: <1106288921.5199.6.camel@localhost.localdomain> References: <41F04357.4020108@trimble.co.nz> <20050121030930.GA6292@ip68-4-98-123.oc.oc.cox.net> <41F09ABB.1060503@trimble.co.nz> <20050121061538.GA12868@jadzia.bu.edu> <1106288921.5199.6.camel@localhost.localdomain> Message-ID: <1106302722.3495.15.camel@roque> On Thu, 2005-01-20 at 22:28 -0800, Per Bjornsson wrote: > In any case, software suspend is not enabled in the Fedora kernels as > the Fedora kernel developers find it ugly and dangerous - at least that > was the last that was the understanding I got last time this was > discussed on this list. I want to run that risk. Exactly what flags do I need to make =y in the i686 kernel config of FC's Linux src.rpm ? I've tried the obvious one, but the kernel _never_ compiles :| Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora-devel at camperquake.de Fri Jan 21 12:18:53 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Fri, 21 Jan 2005 13:18:53 +0100 Subject: Fedora updates CD-ROM? In-Reply-To: <1106276060l.6979l.0l@devel.mpeters.us> References: <1106274641.6091.2.camel@scriabin.tannenrauch.ch> <1106276060l.6979l.0l@devel.mpeters.us> Message-ID: <20050121131853.70426f59@nausicaa.camperquake.de> Hi. "Michael A. Peters" wrote: > http://mpeters.us/linux/fedora_c3_updates.php Hey, neat. -- "Self-Destruct sequence initiated. Your mission, should you choose to accept it, is to get out of here alive. Good luck." -- Lemon Sherbet, Ch. 4 From andreas at conectiva.com.br Fri Jan 21 12:40:49 2005 From: andreas at conectiva.com.br (Andreas Hasenack) Date: Fri, 21 Jan 2005 10:40:49 -0200 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <41F02AC5.3060705@nc.rr.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> <20050119165356.GD11983@burma.localdomain> <1106154283.5881.2396.camel@jonspc> <41EE9B85.4030206@insitesinc.com> <20050120190651.GF22321@conectiva.com.br> <41F02AC5.3060705@nc.rr.com> Message-ID: <20050121124049.GD3435@conectiva.com.br> On Thu, Jan 20, 2005 at 05:03:49PM -0500, Jeff Johnson wrote: > >- yum update gives you absolutely no idea how long the download will take > > Knowing your bw, and estimating network traffic, a priorii is no easy, > nor yum, problem. Come one, even wget shows this :) > >- yum update is *really* verbose. You get pages and pages of data even > >before > > getting a list of packages which will be upgraded > > > > Verbosity increases the likelihood os diagnosing a problem. Wrapper to > redirect > spewage to a log file, and invoke with -y, ain't *THAT* hard if the > verbosity annoys. Why make the verbosity default? Or do you run X in verbose mode? Mozilla? Do you upgrade local rpm packages with rpm -Uvvh all the time? Why are people so worried about diagnosing packaging problems? Does this happen that often in fedora? > >- yum update can't be aborted: ctrl-c just aborts the current download and > > then yum proceeds to the next one where you have to press ctrl-c again and > > so on. > > > > Blame not yum for this, rpmlib runs with signals masked. If you > want/need more responsiveness, > then there is a single call to check-and-exit that may need to be added > to rpmlib within > some loops. I disagree. One thing is to cancel an rpm transaction, another is to abort a simple download. Unless the transaction includes the download, hmm. Anyway, yum aborts the download in progress (so it is indeed catching the ctrl-c signal), but it then proceeds to the next download in the list and I have to press ctrl-c again and so on. Do that with a +100Mb upgrade and you will be annoyed really quick and wanting to kill -9 the thing. Now, why did I even start the download then you may ask? It's because I had no idea how large it would be (yum didn't tell me). > >- after downloading lots of headers and after lots of screens filled with > > information yum finally showed me what packages would be > > upgraded/obsoleted/removed. > > Then the packages would be downloaded and, again, there was no indication > > of > > how long that would take. The ETA displayed was for each package, and not > > the > > whole download. > > > > See answer to 1). I hate to have to tell this, but other package managers show the ETA for the whole thing just fine. They know how much they have do download, and they also know how fast it is comming, and they know how to divide one by the other. > >- yum update also doesn't tell you how big the download is in terms of size > > (how many megabytes?) > > > > > > This could be computed/displayed, but only in units of bytes. I suspect > that knowing the > size is not so useful, judging from 2 complaints regarding "how long > ...", but only 1 complaint > "how large ...". YMMV. Oh, it is useful. If I come home and yum tells me that the daily upgrade would be 100Mb I might want to leave it running during the night instead of waiting in front of my desktop seeing it consume my bandwidth which I could be using for something else at that time. After all, doesn't yum have to know what it is going to download? I'm not talking about used space after installation (would be nice, but I wouldn't miss it that much): it's the download size. > If you like apt, then please, by all means, *Use apt!* No one is > stopping you ... I was afraid it would piss people off. That's not what I meant. If you think the above suggestions are crap, too bad. I was trying to help. In fact, why don't you alias yum="strace yum" if it's that buggy that you need to debug it all the time. > 73 de Jeff From buildsys at redhat.com Fri Jan 21 13:28:52 2005 From: buildsys at redhat.com (Build System) Date: Fri, 21 Jan 2005 08:28:52 -0500 Subject: rawhide report: 20050121 changes Message-ID: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> Removed package gnuchess Removed package freeciv Removed package ytalk Removed package sylpheed Removed package aumix Removed package xboard Removed package balsa Removed package grip Removed package libesmtp Removed package gv Removed package diskcheck Removed package xosview Removed package pdksh Removed package comsat Removed package xsnow Updated Packages: Xaw3d-1.5E-3 ------------ * Thu Jan 20 2005 Than Ngo 1.5E-3 - bump release * Thu Jan 20 2005 Than Ngo 1.5E-2 - enable ARROW_SCROLLBARS, MULTIPLANE_PIXMAPS ant-0:1.6.2-3jpp_2fc -------------------- * Thu Jan 20 2005 Gary Benson 0:1.6.2-3jpp_2fc - Use jdtcore.jar instead of ecj.jar when running under libgcj. bluez-libs-2.14-2 ----------------- * Thu Jan 20 2005 David Woodhouse 2.14-2 - Update to bluez-libs 2.14 - Restore hci_remote_name() and hci_local_name() functions bluez-utils-2.14-1 ------------------ * Thu Jan 20 2005 David Woodhouse 2.14-1 - Update to bluez-utils 2.14 cups-1:1.1.23-4 --------------- * Thu Jan 20 2005 Tim Waugh 1.1.23-4 - Mark the initscript noreplace (bug #145629). emacs-21.3-20 ------------- * Fri Jan 14 2005 Jens Petersen - 21.3-20 - workaround xorg-x11 modifier key problem with emacs-21.3-xterm-modifiers-137868.patch (Thomas Woerner, 137868) * Mon Nov 29 2004 Jens Petersen - 21.3-19 - prefer XIM status under-the-window for now to stop xft httx from dying (125413): add emacs-xim-status-under-window-125413.patch - default diff to unified format in .emacs * Thu Nov 04 2004 Jens Petersen - 21.3-18 - show emacs again in the desktop menu (132567) - require fonts-xorg-75dpi to prevent empty boxes at startup due to missing fonts (Johannes Kaiser, 137060) gaim-1:1.1.2-1 -------------- * Thu Jan 20 2005 Warren Togami 6.3.0.0-0.7 - Fix to allow breaking by line in both the in-charge and not-in-charge ctor/dtor. - Bugzilla 117826 * Thu Jan 20 2005 Andrew Cagney 6.3.0.0-0.6 - Rebuild. * Thu Jan 20 2005 Andrew Cagney 6.3.0.0-0.5 - Use bfd_get_synthetic_symtab to read in any synthetic symbols such as 64-bit PPC's ".symbol"s. glibc-kernheaders-2.4-9.1.89 ---------------------------- * Thu Jan 20 2005 David Woodhouse 2.4-9.1.89 - Revert the tarball update of December 10th; too much was pruned. * Tue Jan 18 2005 David Woodhouse 2.4-9.1.88 - Fix and update and include missing ATM headers (#127098) - Update MTD headers. * Fri Dec 10 2004 Roland McGrath - update syscall numbers on x86_64, ia64 - removed many files users should not need - update ia64 ptrace_offsets.h (#117234) - other misc updates from upstream gpdf-2.8.2-2.3 -------------- * Wed Jan 19 2005 Marco Pesenti Gritti 2.8.2-2.3 - Add patch for CAN-2005-0064 hal-0.4.6-2 ----------- * Thu Jan 20 2005 David Zeuthen 0.4.6-2 - Fix parameters to configure * Thu Jan 20 2005 David Zeuthen 0.4.6-1 - New upstream release - Should close #145099, #144600, #140150, #145223, #137672 * Wed Jan 12 2005 David Zeuthen 0.4.5-1 - New upstream release. - Should close #142834, #141771, #142183 kernel-2.6.10-1.1105_FC4 ------------------------ * Thu Jan 20 2005 Dave Jones - Rebase to -bk8 libieee1284-0.2.9-1 ------------------- * Thu Jan 20 2005 Tim Waugh 0.2.9-1 - 0.2.9. - Build requires python-devel. - Ship Python extension module. libselinux-1.21.1-1 ------------------- * Thu Jan 20 2005 Dan Walsh 1.21.1-1 - Update from NSA * Wed Jan 12 2005 Dan Walsh 1.20.1-3 - Modify matchpathcon to also process file_contexts.local if it exists libsepol-1.2.1.1-1 ------------------ * Thu Jan 20 2005 Dan Walsh 1.2.1.1-1 - Update to latest from NSA * Merged build fix patch from Manoj Srivastava. mozplugger-1.7.1-1 ------------------ * Thu Jan 20 2005 Than Ngo 1.7.1-1 - update to 1.7.1 - remove mozplugger-1.6-2-ia64.patch, it's included in new upstream policycoreutils-1.21.1-1 ------------------------ * Thu Jan 20 2005 Dan Walsh 1.21.1-1 - Update to latest from NSA pygtk2-2.5.2-1 -------------- * Thu Jan 20 2005 - 2.5.1-1 - New version rpmdb-fedora-1:4-0.20050121 --------------------------- selinux-policy-strict-1.21.2-5 ------------------------------ * Thu Jan 20 2005 Dan Walsh 1.21.2-5 - More Fixes for rlogind * Wed Jan 19 2005 Nalin Dahyabhai 1.21.2-4 - Add a default_context entry for the remote_login_t domain, for telnet selinux-policy-targeted-1.21.2-5 -------------------------------- * Thu Jan 20 2005 Dan Walsh 1.21.2-5 - More Fixes for rlogind usermode-1.77-1 --------------- * Thu Jan 20 2005 Jindrich Novy 1.77-1 - preserve LANGUAGE environment variable in userhelper (#82300) - use badge instead of keyring icon for pam-panel-icon (#122487) - icon is not showed in the panel when logged as root (#75234) - use new environment variable USERHELPER_UID to identify an user who executed an application via userhelper (#116186) wget-1.9.1-18 ------------- * Thu Jan 20 2005 Karsten Hopp 1.9.1-18 - add support for --protocol-directories option as documented in the man page (Ville Skytt?, #145571) xemacs-sumo-20050118-1 ---------------------- * Wed Jan 19 2005 Jens Petersen 20050118-1 - update to new sumos - update auctex-texjp-platex.patch - auctex-texsite-lisp-dir.patch no longer needed - auc-tex.info is now correctly auctex.info - physically remove .el.orig patch backup files * Tue Dec 14 2004 Jens Petersen - add auctex-texsite-lisp-dir.patch to initialise auctex TeX-lisp-directory - exclude .orig backup files xpdf-1:3.00-15 -------------- * Thu Jan 20 2005 Than Ngo 1:3.00-15 - Applied patch to fix CAN-2005-0064 (bug #145050) From peter.backlund at home.se Fri Jan 21 13:37:17 2005 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 21 Jan 2005 14:37:17 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> Message-ID: <1106314637.16789.24.camel@localhost.localdomain> > emacs-21.3-20 > ------------- > * Fri Jan 14 2005 Jens Petersen - 21.3-20 > - workaround xorg-x11 modifier key problem with > emacs-21.3-xterm-modifiers-137868.patch (Thomas Woerner, 137868) > > * Mon Nov 29 2004 Jens Petersen - 21.3-19 > - prefer XIM status under-the-window for now to stop xft httx from dying > (125413): add emacs-xim-status-under-window-125413.patch > - default diff to unified format in .emacs > > * Thu Nov 04 2004 Jens Petersen - 21.3-18 > - show emacs again in the desktop menu (132567) > - require fonts-xorg-75dpi to prevent empty boxes at startup due to missing > fonts (Johannes Kaiser, 137060) Any news on the Gtk Emacs front? /Peter From j.underwood at open.ac.uk Fri Jan 21 13:50:16 2005 From: j.underwood at open.ac.uk (Jonathan Underwood) Date: Fri, 21 Jan 2005 13:50:16 +0000 Subject: environment (/etc/profile) and X Message-ID: Dear All, Firstly apologies if there is already perceived wisdom on this matter, and I've missed it despite googling fairly extensively. I recently noticed that in FC3 in a gnome-terminal or xterm that the delete key didn't work and just produced a tilde. Having checked that the correct escape string was being returned, I realised that it was because /etc/inputrc was not being read and so readline wasn't set up correctly in bash, and that the reason for this is because INPUTRC is set in /etc/profile which is never read one one launches a terminal from within X as these start a non login shell ... it's really a manifestation of the fact that logging in via xdm/gdm/kdm starts a session which never invokes a login shell, and so /etc/profile is never read - opening a terminal in Gnome etc starts an interactive non-login shell and so /etc/bashrc and $HOME/.bashrc are read but not /etc/profile or $HOME/.bash_profile. At least that's my understanding. Googling around a bit, this situation has quite a history, and there was even a time when /etc/profile was even sourced twice at login. This has been discussed at length lately by debian people here: http://tinyurl.com/6mlw8 http://groups.google.co.uk/groups?hl=en&lr=&client=firefox-a&threadm=27SaO-2Hu-43%40gated-at.bofh.it&rnum=7&prev=/groups%3Fq%3Dshell%2Binitialization%2BX%2B/etc/profile%26hl%3Den%26lr%3D%26client%3Dfirefox-a%26selm%3D27SaO-2Hu-43%2540gated-at.bofh.it%26rnum%3D7 I myself am unsure about what the right way to deal with this is, but my feeling is that at somepoint during login, the appropriate shell login file should be read i.e. /etc/profile for bash. Thoughts? Jonathan. From felipe_alfaro at linuxmail.org Fri Jan 21 14:12:03 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Fri, 21 Jan 2005 15:12:03 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> Message-ID: <6CAAA96A-6BB6-11D9-86B4-000D9352858E@linuxmail.org> On 21 Jan 2005, at 14:28, Build System wrote: > Removed package aumix Why? From enrico.scholz at informatik.tu-chemnitz.de Fri Jan 21 14:30:17 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 21 Jan 2005 15:30:17 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> (Build System's message of "Fri, 21 Jan 2005 08:28:52 -0500") References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> Message-ID: <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> buildsys at redhat.com (Build System) writes: > Removed package gnuchess > > Removed package freeciv > > Removed package ytalk > > Removed package sylpheed > > Removed package aumix > > Removed package xboard > > Removed package balsa > > Removed package grip > > Removed package libesmtp > > Removed package gv ??? I hope that some of these removals happened just because of temporary issues. I understand that things like sylpheed or balsa can disappear as there are enough alternatives. But e.g. viewing postscript files is a common task and I do not know a program which can replace 'gv'. And games like 'gnuchess' or 'freeciv' are classics which should not be missed on any system. Enrico From feliciano.matias at free.fr Fri Jan 21 14:34:05 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Fri, 21 Jan 2005 15:34:05 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <6CAAA96A-6BB6-11D9-86B4-000D9352858E@linuxmail.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <6CAAA96A-6BB6-11D9-86B4-000D9352858E@linuxmail.org> Message-ID: <1106318045.32306.5.camel@one.myworld> Le vendredi 21 janvier 2005 ? 15:12 +0100, Felipe Alfaro Solana a ?crit : > On 21 Jan 2005, at 14:28, Build System wrote: > > > Removed package aumix > > Why? > Perhaps because OSS is not supported. Use alsamixer. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From feliciano.matias at free.fr Fri Jan 21 14:37:28 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Fri, 21 Jan 2005 15:37:28 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106318248.32306.8.camel@one.myworld> Le vendredi 21 janvier 2005 ? 15:30 +0100, Enrico Scholz a ?crit : > buildsys at redhat.com (Build System) writes: > > > Removed package gnuchess > > > > Removed package freeciv > > > > Removed package ytalk > > > > Removed package sylpheed > > > > Removed package aumix > > > > Removed package xboard > > > > Removed package balsa > > > > Removed package grip > > > > Removed package libesmtp > > > > Removed package gv > > ??? I hope that some of these removals happened just because of temporary > issues. I understand that things like sylpheed or balsa can disappear as > there are enough alternatives. But e.g. viewing postscript files is a > common task and I do not know a program which can replace 'gv'. And games > like 'gnuchess' or 'freeciv' are classics which should not be missed on > any system. > > Perhaps they will be in Fedora Extra (official). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From enrico.scholz at informatik.tu-chemnitz.de Fri Jan 21 14:40:58 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 21 Jan 2005 15:40:58 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106314637.16789.24.camel@localhost.localdomain> (Peter Backlund's message of "Fri, 21 Jan 2005 14:37:17 +0100") References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> Message-ID: <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> peter.backlund at home.se (Peter Backlund) writes: >> emacs-21.3-20 >> ------------- > ... > Any news on the Gtk Emacs front? I would not spend much energy on such a port. A Gtk port means AA fonts which are really a bad choice for text based applications. Current (X)Emacs have a startup-time <1 second so that it can be used as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10 seconds. Enrico From dcbw at redhat.com Fri Jan 21 14:41:19 2005 From: dcbw at redhat.com (Dan Williams) Date: Fri, 21 Jan 2005 09:41:19 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106318479.9659.5.camel@dcbw.boston.redhat.com> On Fri, 2005-01-21 at 15:30 +0100, Enrico Scholz wrote: > > Removed package gv > there are enough alternatives. But e.g. viewing postscript files is a > common task and I do not know a program which can replace 'gv'. And games Um, ggv or gpdf? or kpd? or xpdf? I'd personally use ggv, and if that doesn't work, use xpdf for PDFs. Furthermore, these are really just leaving Fedora Core, but should still be in Fedora Extras AFAIK. Dan From dcbw at redhat.com Fri Jan 21 14:44:17 2005 From: dcbw at redhat.com (Dan Williams) Date: Fri, 21 Jan 2005 09:44:17 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106318657.9659.7.camel@dcbw.boston.redhat.com> On Fri, 2005-01-21 at 15:40 +0100, Enrico Scholz wrote: > I would not spend much energy on such a port. A Gtk port means AA > fonts which are really a bad choice for text based applications. > Current (X)Emacs have a startup-time <1 second so that it can be used > as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10 > seconds. Many GTK apps have startup times around 1s. gedit, for example, on a relatively fast box, and that's pulling some GNOME libs with it... What about emacs would make it so slow? Dan From fedora at wir-sind-cool.org Fri Jan 21 14:47:00 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 21 Jan 2005 15:47:00 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20050121154700.71d13183.fedora@wir-sind-cool.org> On Fri, 21 Jan 2005 15:30:17 +0100, Enrico Scholz wrote: > buildsys at redhat.com (Build System) writes: > > > Removed package gnuchess > > > > Removed package freeciv > > > > Removed package ytalk > > > > Removed package sylpheed > > > > Removed package aumix > > > > Removed package xboard > > > > Removed package balsa > > > > Removed package grip > > > > Removed package libesmtp > > > > Removed package gv > > ??? I hope that some of these removals happened just because of temporary > issues. I understand that things like sylpheed or balsa can disappear as > there are enough alternatives. And Fedora Extras. Sylpheed in Extras could be built with GPGME support finally as long as GPGME is not part of Core. I'd love to see that. My old sylpheed-gpg package in fedora.us didn't make it because it would conflict with Core's sylpheed. > But e.g. viewing postscript files is a > common task and I do not know a program which can replace 'gv'. And games > like 'gnuchess' or 'freeciv' are classics which should not be missed on > any system. Bigger games should all be moved into Extras. A game like Freeciv should not be included with a core operating system, IMHO. From rahulsundaram at gmail.com Fri Jan 21 14:46:29 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Fri, 21 Jan 2005 20:16:29 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <1106318657.9659.7.camel@dcbw.boston.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> Message-ID: Hi > > Many GTK apps have startup times around 1s. gedit, for example, on a > relatively fast box, and that's pulling some GNOME libs with it... What > about emacs would make it so slow? gedit is pretty slow compared to leafpad on my box. it would nice to have that one as an alternative. the gtk file dialog boxes takes around 5 seconds the first time -- Regards, Rahul Sundaram From j.underwood at open.ac.uk Fri Jan 21 14:44:56 2005 From: j.underwood at open.ac.uk (Jonathan Underwood) Date: Fri, 21 Jan 2005 14:44:56 +0000 Subject: rawhide report: 20050121 changes In-Reply-To: <1106318479.9659.5.camel@dcbw.boston.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> Message-ID: Dan Williams wrote: > On Fri, 2005-01-21 at 15:30 +0100, Enrico Scholz wrote: > >>>Removed package gv >> >>there are enough alternatives. But e.g. viewing postscript files is a >>common task and I do not know a program which can replace 'gv'. And games > > > Um, ggv or gpdf? or kpd? or xpdf? I'd personally use ggv, and if that > doesn't work, use xpdf for PDFs. > > Furthermore, these are really just leaving Fedora Core, but should still > be in Fedora Extras AFAIK. > > Dan > IMO it is a shame to lose gv - gv works much faster with xforwarding over ssh than the "ponderous" ggv. From rahulsundaram at gmail.com Fri Jan 21 14:47:59 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Fri, 21 Jan 2005 20:17:59 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <1106318479.9659.5.camel@dcbw.boston.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> Message-ID: Hi > > Furthermore, these are really just leaving Fedora Core, but should still > be in Fedora Extras AFAIK. it would nice to receive a email notice from someone involved in this to the discussion list before the rawhide changes -- Regards, Rahul Sundaram From jamatos at fc.up.pt Fri Jan 21 14:52:16 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Fri, 21 Jan 2005 14:52:16 +0000 Subject: rawhide report: 20050121 changes In-Reply-To: <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <200501211452.16431.jamatos@fc.up.pt> On Friday 21 January 2005 14:40, Enrico Scholz wrote: > peter.backlund at home.se (Peter Backlund) writes: > >> emacs-21.3-20 > > ... > > Any news on the Gtk Emacs front? > > I would not spend much energy on such a port. A Gtk port means AA > fonts which are really a bad choice for text based applications. > Current (X)Emacs have a startup-time <1 second so that it can be used > as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10 > seconds. I am using the packages from http://people.redhat.com/petersen/emacs without any problems. Actually it has been a pleasant surprise as it works, it looks nice, etc... I don't notice any difference in the startup time from the previous frontend. I also feel a little bit guilty since I should have reported this directly to the packager but since it works there isn't nothing to complain... ;-) > Enrico -- Jos? Ab?lio From rahulsundaram at gmail.com Fri Jan 21 14:57:17 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Fri, 21 Jan 2005 20:27:17 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> Message-ID: Hi > > IMO it is a shame to lose gv - gv works much faster with xforwarding > over ssh than the "ponderous" ggv. evince which is available is available as a test yum repo is fast for pdf and is supposed to be capable for viewing postscript files too. http://www.gnome.org/projects/evince/ any chance this will be part of fc4? -- Regards, Rahul Sundaram From skvidal at phy.duke.edu Fri Jan 21 15:00:56 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 21 Jan 2005 10:00:56 -0500 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <20050121124049.GD3435@conectiva.com.br> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105806480.28025.10.camel@one.myworld> <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> <20050119165356.GD11983@burma.localdomain> <1106154283.5881.2396.camel@jonspc> <41EE9B85.4030206@insitesinc.com> <20050120190651.GF22321@conectiva.com.br> <41F02AC5.3060705@nc.rr.com> <20050121124049.GD3435@conectiva.com.br> Message-ID: <1106319656.28666.18.camel@cutter> > Come one, even wget shows this :) Then file an rfe. It might get done. Ranting about what you don't like just on this list means it probably won't. why? B/c I'm busy and I don't always have time to read all the messages on every list. So I try to follow out the bugs that get filed. Bugzilla filing is also the best way to let others track progress (or lack thereof) on items filed against a program. > Why make the verbosity default? Or do you run X in verbose mode? Mozilla? Do > you upgrade local rpm packages with rpm -Uvvh all the time? Why are people so > worried about diagnosing packaging problems? Does this happen that often in > fedora? Packaging problems happen often when you mix a lot of repositories, yes. Also there are a number of occasions where fedora updates-released cause packaging problems. I've found if you don't output anything while things are going on people infer that to be slow. If you do output something people think things are fast. Of course you try to make it take as little time as possible but sometimes it doesn't and rather than sit there silently I'd love for people to know what's going on. > Now, why did I even start the download then you may ask? It's because I had no > idea how large it would be (yum didn't tell me). Please, file an rfe, then. > I hate to have to tell this, but other package managers show the ETA for the > whole thing just fine. They know how much they have do download, and they also > know how fast it is comming, and they know how to divide one by the other. How do you know how fast it will come before downloading anything? > I was afraid it would piss people off. That's not what I meant. If you think > the above suggestions are crap, too bad. I was trying to help. So help, then, open rfes. > In fact, why don't > you alias yum="strace yum" if it's that buggy that you need to debug it all the > time. You don't think that sort of comment is unnecessary and inflammatory? -sv From enrico.scholz at informatik.tu-chemnitz.de Fri Jan 21 15:01:16 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 21 Jan 2005 16:01:16 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106318657.9659.7.camel@dcbw.boston.redhat.com> (Dan Williams's message of "Fri, 21 Jan 2005 09:44:17 -0500") References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> Message-ID: <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> dcbw at redhat.com (Dan Williams) writes: >> I would not spend much energy on such a port. A Gtk port means AA >> fonts which are really a bad choice for text based applications. >> Current (X)Emacs have a startup-time <1 second so that it can be used >> as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10 >> seconds. > > Many GTK apps have startup times around 1s. gedit, for example, not here (P4 2.6 GHz)... gedit needs 5-6 seconds to come up. On first startup it needs yet more as it has to start lots of Gnome programs. Enrico From katzj at redhat.com Fri Jan 21 15:07:09 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 21 Jan 2005 10:07:09 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> Message-ID: <1106320029.4002.10.camel@bree.local.net> On Fri, 2005-01-21 at 20:27 +0530, Rahul Sundaram wrote: > > IMO it is a shame to lose gv - gv works much faster with xforwarding > > over ssh than the "ponderous" ggv. > > evince which is available is available as a test yum repo is fast for > pdf and is supposed to be capable for viewing postscript files too. > > http://www.gnome.org/projects/evince/ > > any chance this will be part of fc4? Magic 8 ball says "Highly likely" :) For now, packages for the devel tree at http://people.redhat.com/~katzj/evince/ (cvs snap updated last night) Jeremy From enrico.scholz at informatik.tu-chemnitz.de Fri Jan 21 15:08:01 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 21 Jan 2005 16:08:01 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106318479.9659.5.camel@dcbw.boston.redhat.com> (Dan Williams's message of "Fri, 21 Jan 2005 09:41:19 -0500") References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> Message-ID: <87mzv23jn2.fsf@kosh.ultra.csn.tu-chemnitz.de> dcbw at redhat.com (Dan Williams) writes: >> > Removed package gv >> there are enough alternatives. But e.g. viewing postscript files is a >> common task and I do not know a program which can replace 'gv'. And games > > Um, ggv or gpdf? or kpd? or xpdf? *pdf does not display PS files. > I'd personally use ggv, This has huge startup times (5 seconds) where gv appears in <1 second, is dog slow accross ssh tunnels and has unergonomic keyboard bindings (every viewer can be terminated with pressing 'Q' -- but not ggv which follows probably a stupid Gnome guide and requires ^W). Enrico From hp at redhat.com Fri Jan 21 15:10:23 2005 From: hp at redhat.com (Havoc Pennington) Date: Fri, 21 Jan 2005 10:10:23 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106320223.7601.87.camel@localhost.localdomain> On Fri, 2005-01-21 at 15:40 +0100, Enrico Scholz wrote: > peter.backlund at home.se (Peter Backlund) writes: > > >> emacs-21.3-20 > >> ------------- > > ... > > Any news on the Gtk Emacs front? > > I would not spend much energy on such a port. A Gtk port means AA > fonts which are really a bad choice for text based applications. > Current (X)Emacs have a startup-time <1 second so that it can be used > as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10 > seconds. > GTK port does *not* mean AA fonts. It means using the standard font system fontconfig, which *can be configured* to have AA fonts (and we do that by default). But if you open Preferences->Font or edit fonts.conf you can get whatever aliasing (or font) you like. Havoc From hp at redhat.com Fri Jan 21 15:12:15 2005 From: hp at redhat.com (Havoc Pennington) Date: Fri, 21 Jan 2005 10:12:15 -0500 Subject: environment (/etc/profile) and X In-Reply-To: References: Message-ID: <1106320335.7601.89.camel@localhost.localdomain> On Fri, 2005-01-21 at 13:50 +0000, Jonathan Underwood wrote: > read - opening a terminal in Gnome etc starts an interactive non-login > shell and so /etc/bashrc and $HOME/.bashrc are read but not /etc/profile > or $HOME/.bash_profile. At least that's my understanding. > > Googling around a bit, this situation has quite a history, and there was > even a time when /etc/profile was even sourced twice at login. You're absolutely right, gdm/xdm/kdm should be running the login files 1 time. We spent a lot of time fixing this several years ago, must have gotten busted somehow. Be sure there's a bugzilla... Havoc From katzj at redhat.com Fri Jan 21 15:16:55 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 21 Jan 2005 10:16:55 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106320615.4002.14.camel@bree.local.net> On Fri, 2005-01-21 at 15:40 +0100, Enrico Scholz wrote: > peter.backlund at home.se (Peter Backlund) writes: > >> emacs-21.3-20 > >> ------------- > > ... > > Any news on the Gtk Emacs front? > > I would not spend much energy on such a port. A Gtk port means AA > fonts which are really a bad choice for text based applications. > Current (X)Emacs have a startup-time <1 second so that it can be used > as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10 > seconds. The last time I tried (and checking again with the current packages Jens has, it's still true), they're just using gtk for all of the windowing code. The text widget is still the same old emacs text widget. Jeremy From elanthis at awesomeplay.com Fri Jan 21 15:18:53 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 21 Jan 2005 10:18:53 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <87mzv23jn2.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <87mzv23jn2.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106320733.31381.29.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2005-01-21 at 16:08 +0100, Enrico Scholz wrote: > dcbw at redhat.com (Dan Williams) writes: > > >> > Removed package gv > >> there are enough alternatives. But e.g. viewing postscript files is a > >> common task and I do not know a program which can replace 'gv'. And games > > > > Um, ggv or gpdf? or kpd? or xpdf? > > *pdf does not display PS files. > > > > I'd personally use ggv, > > This has huge startup times (5 seconds) where gv appears in <1 second, > is dog slow accross ssh tunnels and has unergonomic keyboard bindings > (every viewer can be terminated with pressing 'Q' -- but not ggv which > follows probably a stupid Gnome guide and requires ^W). If you don't like the software in Core, you are fully allowed and encouraged to install add-ons from Extras or other places. Core cannot and should not try to meet everyone's personal preferences, and should not carry six apps that do the same thing. There's a reason it's called "Core" and not "Everything". ;-) Between gv and ggv, ggv is entirely the correct app to choose for Core. While 'q' may be common among certain viewing apps, it is *not* common among GUI apps in general, and the key bindings should be consistent across the *entire* desktop. Startup time, while _very_ unfortunate if slow, takes second seat to user interface concerns. Again, if you dislike ggv, don't use it, and install something you do like. In any event, Evince is likely to replace both ggv and gpdf (hopefully even by Fedora Core 4's release, if we're lucky) so check that out and see if it's speedy enough for you. (It seems snappy as can possibly be on my machine.) http://www.gnome.org/projects/evince/ (FC RPMs available at that site) From rahulsundaram at gmail.com Fri Jan 21 15:19:50 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Fri, 21 Jan 2005 20:49:50 +0530 Subject: environment (/etc/profile) and X In-Reply-To: <1106320335.7601.89.camel@localhost.localdomain> References: <1106320335.7601.89.camel@localhost.localdomain> Message-ID: Hi > > We spent a lot of time fixing this several years ago, must have gotten > busted somehow. > Be sure there's a bugzilla... exactly what I suggested when the question came up on the users list :-) -- Regards, Rahul Sundaram From otaylor at redhat.com Fri Jan 21 15:29:19 2005 From: otaylor at redhat.com (Owen Taylor) Date: Fri, 21 Jan 2005 10:29:19 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106321359.30800.7.camel@localhost.localdomain> On Fri, 2005-01-21 at 16:01 +0100, Enrico Scholz wrote: > dcbw at redhat.com (Dan Williams) writes: > > >> I would not spend much energy on such a port. A Gtk port means AA > >> fonts which are really a bad choice for text based applications. > >> Current (X)Emacs have a startup-time <1 second so that it can be used > >> as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10 > >> seconds. > > > > Many GTK apps have startup times around 1s. gedit, for example, > > not here (P4 2.6 GHz)... gedit needs 5-6 seconds to come up. On first > startup it needs yet more as it has to start lots of Gnome programs. I'd like to say that was far too slow, and it sounds a little slow, but gedit does take 5 seconds or so to start on my laptop. (P3 1Ghz) Some things you can try: - Make sure that your font caches is up to date (run fc-cache -f as root). I've seen people have this screwed up somehow before, though it theoretically should fall back to a homedir cache if the global caches aren't up-to-date. - Try using gtk-update-icon-cache - There's a patch in GTK+ CVS (will be in 2.6.2) that eliminates some excessive font lookup and loading action: 2005-01-09 Anders Carlsson * gtk/gtkcellrenderertext.c: (get_size): * gtk/gtklabel.c: (gtk_label_size_request): * gtk/gtkprogressbar.c: (gtk_progress_bar_size_request): Don't pass NULL to pango_context_get_metrics. Use pango_context_get_language instead, which is way faster. That may make a substantial difference in startup times. Regards, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter.backlund at home.se Fri Jan 21 15:40:42 2005 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 21 Jan 2005 16:40:42 +0100 Subject: DM Session cleanup Message-ID: <1106322042.16789.27.camel@localhost.localdomain> Hello. Could /usr/share/xsessions/gnome.desktop be moved to gnome-session, and /etc/X11/dm/Sessions/gnome.desktop and /etc/X11/gdm/Sessions/GNOME be removed completely, for consistency? /Peter From j.underwood at open.ac.uk Fri Jan 21 15:32:59 2005 From: j.underwood at open.ac.uk (Jonathan Underwood) Date: Fri, 21 Jan 2005 15:32:59 +0000 Subject: environment (/etc/profile) and X In-Reply-To: <1106320335.7601.89.camel@localhost.localdomain> References: <1106320335.7601.89.camel@localhost.localdomain> Message-ID: > > You're absolutely right, gdm/xdm/kdm should be running the login files 1 > time. > > We spent a lot of time fixing this several years ago, must have gotten > busted somehow. > Be sure there's a bugzilla... I would've filed one earlier, but I honestly thought I must be missing something obvious :) Is my thinking correct that this should be taken care of in the script /etc/xdm/Xsession (which is sourced by gdm and kdm as well as xdm) by having #!/bin/bash -l as the first line to invoke bash as a login shell? But then again, this would be the wrong behaviour for someone whose default shell was tcsh? Anyway, shall I file a bug report against xorg-X11, or against a different component? Cheers, J. From michael.favia at insitesinc.com Fri Jan 21 15:37:34 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Fri, 21 Jan 2005 09:37:34 -0600 Subject: RFC: Optimizing for 386 In-Reply-To: <1106294047.6476.33.camel@md.local.linuxlobbyist.org> References: <3k70mg$l3n28t@mxip15a.cluster1.charter.net> <1106294047.6476.33.camel@md.local.linuxlobbyist.org> Message-ID: <41F121BE.5030109@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Iadonisi wrote: > I'd like to suggest for you to rally support from a few people to go > through the recompilations necessary for the entire distribution > (suggest using FC3 as the base) to prove the points you've been making. > There are a few things I think you will need to consider if you want to > be convincing. > First, provide the entire resulting RPMS for download (bittorrent to > share bandwidth) for others to help out with benchmarking. For the > truly paranoid (and to comply with most FOSS licenses), provide the > SRPMS as well. > Next, be sure that anyone who does the 'subjective' part of the test > has two *identical* machines side by side to test simultaneously. If > anyone's going to trust someone saying "It's faster" without hard > numbers, it'll be a hard sell unless there are no time and space > separators involved in the test. Why do you need 2 machines and not just 1 dual booted machine? You can rule out chipset and harware diaparity that way? Maybe i am missing something. - -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB8SG9BVsNYjF2rDYRAqr9AJ9mT2PcV3BRVbP5DIhpp28r4a5o9ACghxXw aeo+E8MYzwZo+8W3jSwUub4= =4WmU -----END PGP SIGNATURE----- From jspaleta at gmail.com Fri Jan 21 15:39:19 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Jan 2005 10:39:19 -0500 Subject: environment (/etc/profile) and X In-Reply-To: <1106320335.7601.89.camel@localhost.localdomain> References: <1106320335.7601.89.camel@localhost.localdomain> Message-ID: <604aa79105012107394832d2f8@mail.gmail.com> On Fri, 21 Jan 2005 10:12:15 -0500, Havoc Pennington wrote: > We spent a lot of time fixing this several years ago, must have gotten > busted somehow. > Be sure there's a bugzilla... I'm not that sure its busted out-of-the-box ... my delete key works just fine in gnome-term and xterm running in a gnome-desktop started from gdm out of runlevel 5 using the prefdm mechanism. INPUTRC is set and as far as I can tell reading through the prefdm logic... /etc/profile gets called exactly once inside the /usr/bin/gdm script, assuming the test -f /etc/profile succeeds. Sounds to me like someone has made a local change to the script logic either in prefdm or in /usr/bin/gdm -jef"this explains why /usr/bin/gdm is a script just to setup /etc/profile before starting gdm-binary"spaleta From j.underwood at open.ac.uk Fri Jan 21 15:36:46 2005 From: j.underwood at open.ac.uk (Jonathan Underwood) Date: Fri, 21 Jan 2005 15:36:46 +0000 Subject: environment (/etc/profile) and X In-Reply-To: References: <1106320335.7601.89.camel@localhost.localdomain> Message-ID: Rahul Sundaram wrote: > Hi > >>We spent a lot of time fixing this several years ago, must have gotten >>busted somehow. >>Be sure there's a bugzilla... > > > exactly what I suggested when the question came up on the users list :-) Well, actually you suggested I raise it on fedora-devel, which I'm doing. Plus I wanted to be sure it was a bug and not my lack of understanding. Plus I wasn't entirely sure which component to file a bug against - you suggested bash, but it seemed to me to be an X bug. Anyway, apologies if I'm making noise on too many lists. J. From elanthis at awesomeplay.com Fri Jan 21 15:41:48 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 21 Jan 2005 10:41:48 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <1106321359.30800.7.camel@localhost.localdomain> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> Message-ID: <1106322108.31381.35.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2005-01-21 at 10:29 -0500, Owen Taylor wrote: > I'd like to say that was far too slow, and it sounds a little slow, > but gedit does take 5 seconds or so to start on my laptop. (P3 1Ghz) It also seems like he's not running GNOME at all, so gedit would pull in a lot of GNOME stuff that isn't already loaded. gedit should really only be used by GNOME users. gedit's speed in this case would not affect GTK emacs, since emacs would be _just_ a GTK program, and not depend on all the GNOME stuff (like gnome-vfs) that gedit does. From ssaccone at link.wustl.edu Fri Jan 21 15:54:45 2005 From: ssaccone at link.wustl.edu (Scott Saccone) Date: Fri, 21 Jan 2005 09:54:45 -0600 Subject: RAM detection error: 32-bit int issue? Message-ID: <1106322885.2726.67.camel@localhost.localdomain> FC2/x86_64 (2.6.5-1.358smp) ran fine with 2GB RAM, but after installing another 2GB it only detects 3GB. GRUB 0.94 also only detects 3GB. I noticed in the source code that GRUB is using int to store certain quantities related to RAM. There is also a bug report at http://savannah.gnu.org/bugs/?func=detailitem&item_id=9954 related to this. Could this my problem? If GRUB has a bug, would this affect linux? Can I fix this by simply updating GRUB? >From /var/log/dmesg: BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009b800 (usable) BIOS-e820: 000000000009b800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 00000000bff60000 (usable) BIOS-e820: 00000000bff60000 - 00000000bff6f000 (ACPI data) BIOS-e820: 00000000bff6f000 - 00000000bff80000 (ACPI NVS) BIOS-e820: 00000000bff80000 - 00000000c0000000 (reserved) BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved) BIOS-e820: 00000000fffffc00 - 0000000100000000 (reserved) BIOS-e820: 0000000100000000 - 0000000140000000 (usable) ... Memory: 3096192k/3145088k available (1879k kernel code, 0k reserved, 1326k data, 176k init) I processed the above: start finish start-dec finish-dec dec-width MB 0 9b800 0 636928 636928 0.607 u 9b800 a0000 636928 655360 18432 0.018 r e0000 100000 917504 1048576 131072 0.125 r 100000 bff60000 1048576 3220570112 3219521536 3070.375 u bff60000 bff6f000 3220570112 3220631552 61440 0.059 r bff6f000 bff80000 3220631552 3220701184 69632 0.066 r bff80000 c0000000 3220701184 3221225472 524288 0.500 r e0000000 f0000000 3758096384 4026531840 268435456 256.000 r fec00000 fec10000 4273995776 4274061312 65536 0.062 r fee00000 fee01000 4276092928 4276097024 4096 0.004 r ff800000 ffc00000 4286578688 4290772992 4194304 4.000 r fffffc00 100000000 4294966272 4294967296 1024 0.001 r 100000000 140000000 4294967296 5368709120 1073741824 1024.000 u Usable=4293900288 (4094.982421875 MB) Not usable=273505280 (260.8349609375 MB) Total=4567405568 (4355.8173828125 MB) The addresses in the last line exceed 2^32. Why is that? Do some of these addresses refer to something besides my RAM? SPECS: CPU: 2 x 3.2GHz Xeon Nocona MOBO: Tyan Thunder i7525 (S2676) RAM: 4GB 2 x 1GB Corsair Reg DDR2 4 x 512MB Corsair Reg DDR2 BIOS: S2676 Rev 2.00 (9/28/04) Linux: 2.6.5-1.358smp Distro: FC2 x86_64 GRUB: GNU GRUB 0.94 gcc: 3.3.3 20040412 (Red Hat Linux 3.3.3-7) From andreas at conectiva.com.br Fri Jan 21 15:44:32 2005 From: andreas at conectiva.com.br (Andreas Hasenack) Date: Fri, 21 Jan 2005 13:44:32 -0200 Subject: Smartrpm was (Re: Fedora Core 4) In-Reply-To: <1106319656.28666.18.camel@cutter> References: <1105807213.13320.1.camel@cutter> <20050119134305.GB8334@burma.localdomain> <604aa79105011907515a656615@mail.gmail.com> <20050119165356.GD11983@burma.localdomain> <1106154283.5881.2396.camel@jonspc> <41EE9B85.4030206@insitesinc.com> <20050120190651.GF22321@conectiva.com.br> <41F02AC5.3060705@nc.rr.com> <20050121124049.GD3435@conectiva.com.br> <1106319656.28666.18.camel@cutter> Message-ID: <20050121154432.GA1335@conectiva.com.br> On Fri, Jan 21, 2005 at 10:00:56AM -0500, seth vidal wrote: > Packaging problems happen often when you mix a lot of repositories, yes. > Also there are a number of occasions where fedora updates-released cause > packaging problems. I've found if you don't output anything while things > are going on people infer that to be slow. If you do output something So show an ETA :) > > I hate to have to tell this, but other package managers show the ETA for the > > whole thing just fine. They know how much they have do download, and they also > > know how fast it is comming, and they know how to divide one by the other. > > How do you know how fast it will come before downloading anything? You are joking, right? :) Do you need to download everything to give an estimate? I wonder how all those progress bars in mozilla, thunderbird, wget, lftp, ncftp, zmodem, xmodem, etc. work then. > > I was afraid it would piss people off. That's not what I meant. If you think > > the above suggestions are crap, too bad. I was trying to help. > > So help, then, open rfes. I'm sure these things will be implemented some time. > > In fact, why don't > > you alias yum="strace yum" if it's that buggy that you need to debug it all the > > time. > > You don't think that sort of comment is unnecessary and inflammatory? Of course. I was agitated by Jeff's typical reaction, apologies. From rms at 1407.org Fri Jan 21 15:51:32 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 21 Jan 2005 15:51:32 +0000 Subject: rawhide report: 20050121 changes In-Reply-To: <1106322108.31381.35.camel@support02.civic.twp.ypsilanti.mi.us> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> <1106322108.31381.35.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1106322692.3495.67.camel@roque> On Fri, 2005-01-21 at 10:41 -0500, Sean Middleditch wrote: > On Fri, 2005-01-21 at 10:29 -0500, Owen Taylor wrote: > > > I'd like to say that was far too slow, and it sounds a little slow, > > but gedit does take 5 seconds or so to start on my laptop. (P3 1Ghz) > > It also seems like he's not running GNOME at all, I use GNOME all the time, and gedit just took 6s to be usable (counting from click on 'Text Editor' in the Accessories menu). This is a Pentium 4 Mobile at 2.8 MHz and 512 MB of RAM (filled at approximately 75%). > so gedit would pull in a lot of GNOME stuff that isn't already loaded. I don't know if that solves all problems (like disk speed, etc)... Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From elanthis at awesomeplay.com Fri Jan 21 15:52:46 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 21 Jan 2005 10:52:46 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <1106322692.3495.67.camel@roque> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> <1106322108.31381.35.camel@support02.civic.twp.ypsilanti.mi.us> <1106322692.3495.67.camel@roque> Message-ID: <1106322766.31381.38.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2005-01-21 at 15:51 +0000, Rui Miguel Seabra wrote: > I use GNOME all the time, and gedit just took 6s to be usable (counting > from click on 'Text Editor' in the Accessories menu). > > This is a Pentium 4 Mobile at 2.8 MHz and 512 MB of RAM (filled at > approximately 75%). Aside from the stuff Owen suggested, are you perhaps loading certain plugins that cause the slow down, or loading a very large file? You might try experimenting with the plugins especially to see if one of them is causing it. I only have the spell checker enabled and gedit loaded within 1s cold. From enrico.scholz at informatik.tu-chemnitz.de Fri Jan 21 15:56:52 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 21 Jan 2005 16:56:52 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106321359.30800.7.camel@localhost.localdomain> (Owen Taylor's message of "Fri, 21 Jan 2005 10:29:19 -0500") References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> Message-ID: <87is5q3hdn.fsf@kosh.ultra.csn.tu-chemnitz.de> otaylor at redhat.com (Owen Taylor) writes: >> not here (P4 2.6 GHz)... gedit needs 5-6 seconds to come up. On first >> startup it needs yet more as it has to start lots of Gnome programs. > > I'd like to say that was far too slow, and it sounds a little slow, > but gedit does take 5 seconds or so to start on my laptop. (P3 1Ghz) > > Some things you can try: > > - Make sure that your font caches is up to date (run fc-cache -f > as root). I've seen people have this screwed up somehow before, > though it theoretically should fall back to a homedir cache > if the global caches aren't up-to-date. > > - Try using gtk-update-icon-cache Thanks, but this does not help. I have two theories: * Gnome2 application are only in Gnome2 environments fast, and I do not run Gnome2... KDE has similar effects but after starting one KDE application, the other ones have reasonable startup-times (e.g. kghostview needs 10-15s on first start and then around 2s). * 'strace -eopen ggv' shows that it opens all and every icon which it can find on the system. As these icons are on /usr/share which are on an NFS share, this can cause slowdowns. Nevertheless, this is a broken behavior as only a small subset of the icons will be used by gedit finally. > - There's a patch in GTK+ CVS (will be in 2.6.2) that eliminates some > excessive font lookup and loading action: I will follow rawhide development but do not have time to try this now. Enrico From rahulsundaram at gmail.com Fri Jan 21 15:59:18 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Fri, 21 Jan 2005 21:29:18 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <1106321359.30800.7.camel@localhost.localdomain> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> Message-ID: Hi > > - Make sure that your font caches is up to date (run fc-cache -f > as root). I've seen people have this screwed up somehow before, > though it theoretically should fall back to a homedir cache > if the global caches aren't up-to-date. I did this > > - Try using gtk-update-icon-cache You mean run it as root or user?. did both anyway take about 6 seonds on cold and 3 secs on rerun. PIII with 128 MB ram. even the file dialog boxes take about 3-4 secs to show up -- Regards, Rahul Sundaram From elanthis at awesomeplay.com Fri Jan 21 16:02:32 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 21 Jan 2005 11:02:32 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <87is5q3hdn.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> <87is5q3hdn.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106323352.31381.41.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2005-01-21 at 16:56 +0100, Enrico Scholz wrote: > * 'strace -eopen ggv' shows that it opens all and every icon which it > can find on the system. As these icons are on /usr/share which are on > an NFS share, this can cause slowdowns. Nevertheless, this is a broken > behavior as only a small subset of the icons will be used by gedit > finally. That's why Owen asked you to run gtk-update-icon-cache. It's a new feature of GTK 2.6 that attempts to solve the icon loading performance problems. From felipe_alfaro at linuxmail.org Fri Jan 21 16:11:00 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Fri, 21 Jan 2005 17:11:00 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106322692.3495.67.camel@roque> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> <1106322108.31381.35.camel@support02.civic.twp.ypsilanti.mi.us> <1106322692.3495.67.camel@roque> Message-ID: <0AE52E56-6BC7-11D9-86B4-000D9352858E@linuxmail.org> On 21 Jan 2005, at 16:51, Rui Miguel Seabra wrote: > On Fri, 2005-01-21 at 10:41 -0500, Sean Middleditch wrote: >> On Fri, 2005-01-21 at 10:29 -0500, Owen Taylor wrote: >> >>> I'd like to say that was far too slow, and it sounds a little slow, >>> but gedit does take 5 seconds or so to start on my laptop. (P3 1Ghz) >> >> It also seems like he's not running GNOME at all, > > I use GNOME all the time, and gedit just took 6s to be usable (counting > from click on 'Text Editor' in the Accessories menu). > > This is a Pentium 4 Mobile at 2.8 MHz and 512 MB of RAM (filled at > approximately 75%). Ah! That explains the slowness... 2.8Mhz is even slower than my old XT :-) Now seriously: something is going on wrong, since gedit tooks 2 seconds to open on my Northwood P4 2Ghz with 512MB running Xen with concurrent 2 domains running. From rms at 1407.org Fri Jan 21 16:16:29 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 21 Jan 2005 16:16:29 +0000 Subject: rawhide report: 20050121 changes In-Reply-To: <0AE52E56-6BC7-11D9-86B4-000D9352858E@linuxmail.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> <1106322108.31381.35.camel@support02.civic.twp.ypsilanti.mi.us> <1106322692.3495.67.camel@roque> <0AE52E56-6BC7-11D9-86B4-000D9352858E@linuxmail.org> Message-ID: <1106324189.3495.75.camel@roque> On Fri, 2005-01-21 at 17:11 +0100, Felipe Alfaro Solana wrote: > Ah! That explains the slowness... 2.8Mhz is even slower than my old XT > :-) > Now seriously: something is going on wrong, since gedit tooks 2 seconds > to open on my Northwood P4 2Ghz with 512MB running Xen with concurrent > 2 domains running. LOL yes. G, not M :) my gosh, this would be almost 8 times slower than my first computer :))) Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From enrico.scholz at informatik.tu-chemnitz.de Fri Jan 21 16:15:50 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 21 Jan 2005 17:15:50 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106323352.31381.41.camel@support02.civic.twp.ypsilanti.mi.us> (Sean Middleditch's message of "Fri, 21 Jan 2005 11:02:32 -0500") References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> <87is5q3hdn.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106323352.31381.41.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <87ekge3gi1.fsf@kosh.ultra.csn.tu-chemnitz.de> elanthis at awesomeplay.com (Sean Middleditch) writes: >> * 'strace -eopen ggv' shows that it opens all and every icon which it >> can find on the system. As these icons are on /usr/share which are on >> an NFS share, this can cause slowdowns. Nevertheless, this is a broken >> behavior as only a small subset of the icons will be used by gedit >> finally. > > That's why Owen asked you to run gtk-update-icon-cache. I executed this command but it did not help. 'strace' showed that it is nearly a noop: it loads some dynamic libraries and exits then with code 0... Enrico From rms at 1407.org Fri Jan 21 16:18:17 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 21 Jan 2005 16:18:17 +0000 Subject: rawhide report: 20050121 changes In-Reply-To: <1106322766.31381.38.camel@support02.civic.twp.ypsilanti.mi.us> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> <1106322108.31381.35.camel@support02.civic.twp.ypsilanti.mi.us> <1106322692.3495.67.camel@roque> <1106322766.31381.38.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1106324297.3495.78.camel@roque> On Fri, 2005-01-21 at 10:52 -0500, Sean Middleditch wrote: > On Fri, 2005-01-21 at 15:51 +0000, Rui Miguel Seabra wrote: > > I use GNOME all the time, and gedit just took 6s to be usable (counting > > from click on 'Text Editor' in the Accessories menu). > > > > This is a Pentium 4 Mobile at 2.8 MHz and 512 MB of RAM (filled at ^ should be a G <:) > > approximately 75%). > > Aside from the stuff Owen suggested, are you perhaps loading certain > plugins that cause the slow down, or loading a very large file? You > might try experimenting with the plugins especially to see if one of > them is causing it. I only have the spell checker enabled and gedit > loaded within 1s cold. Well, since gedit is too braindead for my uses I never use it, so it comes as default on Fedora. Also, notice that I simply clicked on the menu item, so I didn't even load any file at all! Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rahulsundaram at gmail.com Fri Jan 21 16:17:30 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Fri, 21 Jan 2005 21:47:30 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <87is5q3hdn.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> <87is5q3hdn.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: Hi ... KDE has similar effects but after starting one > KDE application, the other ones have reasonable startup-times > (e.g. kghostview needs 10-15s on first start and then around 2s). kde apps seem to use a hack called kdeinit to share common base. it does cause problems with selinux From elanthis at awesomeplay.com Fri Jan 21 16:21:04 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 21 Jan 2005 11:21:04 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <87ekge3gi1.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> <87is5q3hdn.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106323352.31381.41.camel@support02.civic.twp.ypsilanti.mi.us> <87ekge3gi1.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106324464.31381.45.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2005-01-21 at 17:15 +0100, Enrico Scholz wrote: > elanthis at awesomeplay.com (Sean Middleditch) writes: > > That's why Owen asked you to run gtk-update-icon-cache. > > I executed this command but it did not help. 'strace' showed that it is > nearly a noop: it loads some dynamic libraries and exits then with code > 0... --help is your friend. ;-) Try gtk-update-icon-cache ~/.icons as your user, or gtk-update-icon- cache /usr/share/icons as root. > > > Enrico > From rahulsundaram at gmail.com Fri Jan 21 16:21:27 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Fri, 21 Jan 2005 21:51:27 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <1106320733.31381.29.camel@support02.civic.twp.ypsilanti.mi.us> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <87mzv23jn2.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106320733.31381.29.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: Hi There's a reason it's called > "Core" and not "Everything". ;-) This is why I wanted non default stuff like KDE etc moved to fedora extras. it can be handed over to the kde-redhat.sf.net guys since they are redoing upstream KDE anyway -- Regards, Rahul Sundaram From pri.rhl3 at iadonisi.to Fri Jan 21 16:28:01 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Fri, 21 Jan 2005 11:28:01 -0500 Subject: RFC: Optimizing for 386 In-Reply-To: <41F121BE.5030109@insitesinc.com> References: <3k70mg$l3n28t@mxip15a.cluster1.charter.net> <1106294047.6476.33.camel@md.local.linuxlobbyist.org> <41F121BE.5030109@insitesinc.com> Message-ID: <1106324881.30064.14.camel@tuxpaq> On Fri, 2005-01-21 at 09:37 -0600, Michael Favia wrote: [snip] > Why do you need 2 machines and not just 1 dual booted machine? You can > rule out chipset and harware diaparity that way? Maybe i am missing > something. Yeah, I guess it's a tradeoff. Launching a copy of Mozilla or OpenOffice on both boxes at the same instant in time would make it easy to see which one launches first. It's also a lot easier to ensure you are doing the same things on each box if you have them side by side. But, yes, you risk some unknown hardware differences doing it this way. The alternative is to be sure you document every click and keystroke and resulting response times as well as things like disk activity. Either way can work. Consider my rough test plan modifiable to your heart's content, provided you explain what method(s) you've used for testing for peer review. ;-) -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From j.underwood at open.ac.uk Fri Jan 21 16:27:27 2005 From: j.underwood at open.ac.uk (Jonathan Underwood) Date: Fri, 21 Jan 2005 16:27:27 +0000 Subject: environment (/etc/profile) and X In-Reply-To: <604aa79105012107394832d2f8@mail.gmail.com> References: <1106320335.7601.89.camel@localhost.localdomain> <604aa79105012107394832d2f8@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On Fri, 21 Jan 2005 10:12:15 -0500, Havoc Pennington wrote: > >>We spent a lot of time fixing this several years ago, must have gotten >>busted somehow. >>Be sure there's a bugzilla... > > > > I'm not that sure its busted out-of-the-box ... my delete key works > just fine in gnome-term and xterm running in a gnome-desktop started > from gdm out of runlevel 5 using the prefdm mechanism. INPUTRC is set > and as far as I can tell reading through the prefdm logic... > /etc/profile gets called exactly once inside the /usr/bin/gdm > script, assuming the test -f /etc/profile succeeds. Sounds to me > like someone has made a local change to the script logic either in > prefdm or in /usr/bin/gdm > > Nope, I've made no change to either, and see the same issue on two different FC3 boxes. To be clear, I'm talking about delete and not backspace. INPUTRC is definately not set on either box inside of a gnome-session. J. > -jef"this explains why /usr/bin/gdm is a script just to setup > /etc/profile before starting gdm-binary"spaleta > From rstrode at redhat.com Fri Jan 21 16:43:43 2005 From: rstrode at redhat.com (Ray Strode) Date: Fri, 21 Jan 2005 11:43:43 -0500 Subject: DM Session cleanup In-Reply-To: <1106322042.16789.27.camel@localhost.localdomain> References: <1106322042.16789.27.camel@localhost.localdomain> Message-ID: <1106325823.5060.0.camel@localhost.localdomain> Hi, > Could /usr/share/xsessions/gnome.desktop be moved to gnome-session, > and /etc/X11/dm/Sessions/gnome.desktop and /etc/X11/gdm/Sessions/GNOME > be removed completely, for consistency? Could you file a bug, so I don't forget? Thanks, Ray Strode From aoliva at redhat.com Fri Jan 21 16:51:37 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 21 Jan 2005 14:51:37 -0200 Subject: RFC: Optimizing for 386 In-Reply-To: <41F121BE.5030109@insitesinc.com> References: <3k70mg$l3n28t@mxip15a.cluster1.charter.net> <1106294047.6476.33.camel@md.local.linuxlobbyist.org> <41F121BE.5030109@insitesinc.com> Message-ID: On Jan 21, 2005, Michael Favia wrote: > Why do you need 2 machines and not just 1 dual booted machine? To run the apps side by side? To install the optimized distro in the faster portion of the disk and in the slower portion of the disk on the other? To introduce a little bit of randomness in the layout of files on disk such that results you get are not biased by some lucky layout for one way or the other. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From peter.backlund at home.se Fri Jan 21 17:04:32 2005 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 21 Jan 2005 18:04:32 +0100 Subject: DM Session cleanup In-Reply-To: <1106325823.5060.0.camel@localhost.localdomain> References: <1106322042.16789.27.camel@localhost.localdomain> <1106325823.5060.0.camel@localhost.localdomain> Message-ID: <1106327073.16789.30.camel@localhost.localdomain> fre 2005-01-21 klockan 11:43 -0500 skrev Ray Strode: > Hi, > > Could /usr/share/xsessions/gnome.desktop be moved to gnome-session, > > and /etc/X11/dm/Sessions/gnome.desktop and /etc/X11/gdm/Sessions/GNOME > > be removed completely, for consistency? > Could you file a bug, so I don't forget? https://bugzilla.redhat.com/beta/show_bug.cgi?id=145791 /Peter From P at draigBrady.com Fri Jan 21 17:01:40 2005 From: P at draigBrady.com (P at draigBrady.com) Date: Fri, 21 Jan 2005 17:01:40 +0000 Subject: rawhide report: 20050121 changes In-Reply-To: <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <41F13574.2040106@draigBrady.com> Enrico Scholz wrote: > peter.backlund at home.se (Peter Backlund) writes: > > >>>emacs-21.3-20 >>>------------- >> >>... >>Any news on the Gtk Emacs front? > > > I would not spend much energy on such a port. A Gtk port means AA > fonts which are really a bad choice for text based applications. > Current (X)Emacs have a startup-time <1 second so that it can be used > as $EDITOR. With Gtk I fear, that this will be somewhere around 5-10 > seconds. I agree with you, but you can easily turn off antialiasing: http://www.pixelbeat.org/docs/fc_fixed.html -- P?draig Brady - http://www.pixelbeat.org -- From enrico.scholz at informatik.tu-chemnitz.de Fri Jan 21 17:05:59 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 21 Jan 2005 18:05:59 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: (Rahul Sundaram's message of "Fri, 21 Jan 2005 21:51:27 +0530") References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <87mzv23jn2.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106320733.31381.29.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> rahulsundaram at gmail.com (Rahul Sundaram) writes: > There's a reason it's called >> "Core" and not "Everything". ;-) > > This is why I wanted non default stuff like KDE etc moved to fedora > extras. ACK. Same should happen with Gnome. Enrico From enrico.scholz at informatik.tu-chemnitz.de Fri Jan 21 17:05:04 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 21 Jan 2005 18:05:04 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106324464.31381.45.camel@support02.civic.twp.ypsilanti.mi.us> (Sean Middleditch's message of "Fri, 21 Jan 2005 11:21:04 -0500") References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> <87is5q3hdn.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106323352.31381.41.camel@support02.civic.twp.ypsilanti.mi.us> <87ekge3gi1.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106324464.31381.45.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <87acr23e7z.fsf@kosh.ultra.csn.tu-chemnitz.de> elanthis at awesomeplay.com (Sean Middleditch) writes: >> > That's why Owen asked you to run gtk-update-icon-cache. >> >> I executed this command but it did not help. 'strace' showed that it is >> nearly a noop: it loads some dynamic libraries and exits then with code >> 0... > > --help is your friend. ;-) > > Try gtk-update-icon-cache ~/.icons as your user, or gtk-update-icon- > cache /usr/share/icons as root. Ah... running on /usr/share/icons alone will not help. But after figuring out the expected 'icon-theme.cache' files, I executed the command for the 5 requested directories. Then gedit starts significantly faster. Unfortunately, the cache must be renewed manually when things change there and I have ugly 'icon-theme.cache' files which are not covered by the package-management. Enrico From rstrode at redhat.com Fri Jan 21 17:05:58 2005 From: rstrode at redhat.com (Ray Strode) Date: Fri, 21 Jan 2005 12:05:58 -0500 Subject: environment (/etc/profile) and X In-Reply-To: References: Message-ID: <1106327158.5060.6.camel@localhost.localdomain> Hi, > it's really a > manifestation of the fact that logging in via xdm/gdm/kdm starts a > session which never invokes a login shell, and so /etc/profile is never > read - That doesn't sound right. When GDM starts a user, /etc/X11/xdm/Xsession should get run which does start a login shell. Could you file a bug about this please? --Ray Strode From tibbs at math.uh.edu Fri Jan 21 17:09:29 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 21 Jan 2005 11:09:29 -0600 Subject: RAM detection error: 32-bit int issue? In-Reply-To: <1106322885.2726.67.camel@localhost.localdomain> (Scott Saccone's message of "Fri, 21 Jan 2005 09:54:45 -0600") References: <1106322885.2726.67.camel@localhost.localdomain> Message-ID: >>>>> "SS" == Scott Saccone writes: SS> FC2/x86_64 (2.6.5-1.358smp) ran fine with 2GB RAM, but after SS> installing another 2GB it only detects 3GB. GRUB 0.94 also only SS> detects 3GB. No problems with 8GB on x86_64 here (using two 2 Opterons 250s on a Tyan S2882). Grub can certainly handle that much memory. (It even handles 6GB on 32-bit Xeon system.) I'd guess there's an issue with your BIOS, or the Kernel's interaction with it. - J< From elanthis at awesomeplay.com Fri Jan 21 17:43:03 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 21 Jan 2005 12:43:03 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <87mzv23jn2.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106320733.31381.29.camel@support02.civic.twp.ypsilanti.mi.us> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2005-01-21 at 18:05 +0100, Enrico Scholz wrote: > rahulsundaram at gmail.com (Rahul Sundaram) writes: > > > There's a reason it's called > >> "Core" and not "Everything". ;-) > > > > This is why I wanted non default stuff like KDE etc moved to fedora > > extras. > > ACK. Same should happen with Gnome. GNOME is the default desktop, so of course it shouldn't be removed. I'm wary of moving KDE due to the political issues, but I wouldn't mind seeing all the other WMs and DEs moved (XFCE, for one). > > > > Enrico > From davej at redhat.com Fri Jan 21 17:45:35 2005 From: davej at redhat.com (Dave Jones) Date: Fri, 21 Jan 2005 12:45:35 -0500 Subject: rawhide report: 20050120 changes In-Reply-To: <20050121071907.GA22443@devserv.devel.redhat.com> References: <200501201336.j0KDaN700648@porkchop.devel.redhat.com> <1106229698.6742.36.camel@laptopd505.fenrus.org> <20050121024151.GD32430@redhat.com> <20050121071907.GA22443@devserv.devel.redhat.com> Message-ID: <20050121174535.GA18607@redhat.com> On Fri, Jan 21, 2005 at 08:19:07AM +0100, Arjan van de Ven wrote: > > > why is this gunk added back to the fedora kernel? > > > I can see trying to get kexec-dump working instead as useful, but > > > diskdump/netdump? God no. > > > > It's a transitional thing until upstream has something that's usable. > > ok that makes me wonder if diskdump offers value to fedora users at all; it > doesn't work with lvm (which is the default installation) for example. The two are somewhat intertwined. Ie, 'crashdump-common' contains quite a bit of diskdump goo. Merging it all was just a shortest path thing.. > > The kernel-side is still seeing quite a lot of churn judging by > > the amount of change seen in yesterdays -mm update, and userspace > > is clearly lacking. > I thought this was rawhide. Also it's a chicken and egg situation; userspace > is somewhat there (at least in prototype form) but it will never get there > unless some kernels ship/enable the kernel side When it settles down a bit in -mm I'll pull it back in, and we'll see what happens. Dave From dax at gurulabs.com Fri Jan 21 17:50:57 2005 From: dax at gurulabs.com (Dax Kelson) Date: Fri, 21 Jan 2005 10:50:57 -0700 Subject: Alien Night vs ksh (was: rawhide report: 20050121 changes) Message-ID: <1106329858.12994.25.camel@mentorng.gurulabs.com> > Removed package ytalk This is a shame. On a multi-user boxes communicating at the command line via ytalk is the way to go. Much much better than regular "talk". > Removed package pdksh We have a large tutorial that introduces and explorers the features of various shells that includes coverage of pdksh. I also know of quite a few gray beards that swear by ksh. Having ksh or a ksh clone has pretty much been a given on any Unix or Linux box for a couple decades now. Breaking this expected behavior now would be extremely unfortunate. Doesn't seem worth it save ~350kb. If you want to save 350kb, then pick one of the following and ditch it instead: /usr/share/wallpapers/alien-night.jpg /usr/share/wallpapers/kiagara.jpg /usr/share/wallpapers/Island-of-Elba.jpg 20 years of tradition or alien night? When brining it back, please consider replacing pdksh with the official ksh? http://www.kornshell.com/ It is licensed under the CPL 1.0 which is an OSI approved license. Dax Kelson Guru Labs From elanthis at awesomeplay.com Fri Jan 21 17:51:47 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 21 Jan 2005 12:51:47 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <87acr23e7z.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> <87is5q3hdn.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106323352.31381.41.camel@support02.civic.twp.ypsilanti.mi.us> <87ekge3gi1.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106324464.31381.45.camel@support02.civic.twp.ypsilanti.mi.us> <87acr23e7z.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106329907.31381.54.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2005-01-21 at 18:05 +0100, Enrico Scholz wrote: > Ah... running on /usr/share/icons alone will not help. But after figuring > out the expected 'icon-theme.cache' files, I executed the command for the > 5 requested directories. Then gedit starts significantly faster. Whoops, right. Sorry. > > Unfortunately, the cache must be renewed manually when things change > there and I have ugly 'icon-theme.cache' files which are not covered by > the package-management. An "ugly" filename buried in /usr or ~/.icons is absolutely nothing bad. All those weird linux-* files in /boot are pretty ugly, too... The cache files should be part of any packaged themes. Probably should be a bug report requesting this if they are not already. The user theme installer needs to be running this on install as well if it doesn't already. (Would be more likely to happen if GNOME had a real theme format so installing icon themes using the theme installer was actually easier than just unpacking from file-roller... or should all icon themes come with the icon-theme.cache file pre-generated from now on?) From ssaccone at link.wustl.edu Fri Jan 21 18:03:25 2005 From: ssaccone at link.wustl.edu (Scott Saccone) Date: Fri, 21 Jan 2005 12:03:25 -0600 Subject: RAM detection error: 32-bit int issue? In-Reply-To: References: <1106322885.2726.67.camel@localhost.localdomain> Message-ID: <1106330605.15199.17.camel@localhost.localdomain> Thanks very much, could you tell me what versions of GRUB and linux you're using? BTW, the BIOS reports 4GB of memory, and Memtest86+ shows 4GB working fine, so it must have something to do with the interaction between the kernel and BIOS. Doesn't everything depend on the BIOS-provided physical RAM map that's in the dmesg file, or is it more than that? This is quote from a GRUB bug report that was posted after v.95 came out (I'm using v.94, the only version after .95 is GRUB2 which is in development) http://savannah.gnu.org/bugs/?func=detailitem&item_id=9954 'In char_io.c the memcheck function uses "int addr" to store addresses and does bounds checking on it. On systems with over 2G of ram the "int addr" will be negative and the bounds checking will fail producing an "ERR_WONT_FIT".' On Fri, 2005-01-21 at 11:09, Jason L Tibbitts III wrote: > >>>>> "SS" == Scott Saccone writes: > > SS> FC2/x86_64 (2.6.5-1.358smp) ran fine with 2GB RAM, but after > SS> installing another 2GB it only detects 3GB. GRUB 0.94 also only > SS> detects 3GB. > > No problems with 8GB on x86_64 here (using two 2 Opterons 250s on a > Tyan S2882). Grub can certainly handle that much memory. (It even > handles 6GB on 32-bit Xeon system.) > > I'd guess there's an issue with your BIOS, or the Kernel's interaction > with it. > > - J< From sopwith at redhat.com Fri Jan 21 18:01:29 2005 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 21 Jan 2005 13:01:29 -0500 (EST) Subject: Alien Night vs ksh (was: rawhide report: 20050121 changes) In-Reply-To: <1106329858.12994.25.camel@mentorng.gurulabs.com> References: <1106329858.12994.25.camel@mentorng.gurulabs.com> Message-ID: On Fri, 21 Jan 2005, Dax Kelson wrote: > > Removed package pdksh This will be replaced by the Real ksh sometime soon. -- Elliot From rjune at bravegnuworld.com Fri Jan 21 18:08:38 2005 From: rjune at bravegnuworld.com (Richard June) Date: Fri, 21 Jan 2005 13:08:38 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <200501211308.40737.rjune@bravegnuworld.com> > GNOME is the default desktop, so of course it shouldn't be removed. I'm > wary of moving KDE due to the political issues, but I wouldn't mind > seeing all the other WMs and DEs moved (XFCE, for one). I'm with you, keep GNOME and KDE in core. everything else can go in extras *especially* after there's a graphical yum client/software manager that's included in core. -- Public Key available Here: http://www.bravegnuworld.com/~rjune/pubkey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From linville at redhat.com Fri Jan 21 18:11:38 2005 From: linville at redhat.com (John W. Linville) Date: Fri, 21 Jan 2005 13:11:38 -0500 Subject: Alien Night vs ksh (was: rawhide report: 20050121 changes) In-Reply-To: <1106329858.12994.25.camel@mentorng.gurulabs.com> References: <1106329858.12994.25.camel@mentorng.gurulabs.com> Message-ID: <20050121181138.GD9611@redhat.com> On Fri, Jan 21, 2005 at 10:50:57AM -0700, Dax Kelson wrote: > 20 years of tradition or alien night? > > When brining it back, please consider replacing pdksh with the official > ksh? I'd have to second this -- fortunately, it looks like it is already "in the works"... > http://www.kornshell.com/ Thanks for the link...I didn't realize this had been opened-up! John -- John W. Linville linville at redhat.com From tadams-lists at myrealbox.com Fri Jan 21 18:49:22 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Fri, 21 Jan 2005 11:49:22 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] Message-ID: <1106333362.3427.19.camel@localhost.localdomain> So, why is grip being removed? Sound Juicer does not yet allow quality selection. Trever -- "Women reason with the heart and are much less often wrong than men who reason with the head." -- DeLescure From ellson at research.att.com Fri Jan 21 18:52:58 2005 From: ellson at research.att.com (John Ellson) Date: Fri, 21 Jan 2005 13:52:58 -0500 Subject: Alien Night vs ksh (was: rawhide report: 20050121 changes) In-Reply-To: <20050121181138.GD9611@redhat.com> References: <1106329858.12994.25.camel@mentorng.gurulabs.com> <20050121181138.GD9611@redhat.com> Message-ID: <41F14F8A.5040104@research.att.com> John W. Linville wrote: >On Fri, Jan 21, 2005 at 10:50:57AM -0700, Dax Kelson wrote: > > > >>20 years of tradition or alien night? >> >>When brining it back, please consider replacing pdksh with the official >>ksh? >> >> > >I'd have to second this -- fortunately, it looks like it is already >"in the works"... > > > >>http://www.kornshell.com/ >> >> > >Thanks for the link...I didn't realize this had been opened-up! > >John > > Just FYI: Graphviz, also from AT&T Research, is also now released under the CPL. http://www.graphviz.org/ There is a pre-CPL version in extras, but I don't know who is looking after it and they don't respond to bugzilla. If someone-in-charge of Fedora would like me (a graphviz author) to maintain it, please let me know how... John Ellson From tadams-lists at myrealbox.com Fri Jan 21 19:00:41 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Fri, 21 Jan 2005 12:00:41 -0700 Subject: Evolution 2.2, OpenOffice 2.0, Gnome 2.10 Message-ID: <1106334041.6561.3.camel@localhost.localdomain> I believe I saw these on a list for inclusion in FC4. However, there have been no signs of it yet. OO 2 was delayed a bit, so I can see if this was dropped, though I hope it wasn't. Evolution 2.1.x should go beta for 2.2 very shortly (may have happened, but release not done yet). Gnome 2.10 is on more or less the same schedule as 2.1.x. When, if, are we going to see these in rawhide? Is there anything I can do? Trever -- "He that demands mercy, and shows none, ruins the bridge over which he himself is to pass." -- Thomas Adams, 1612-1653 From mclasen at redhat.com Fri Jan 21 19:16:48 2005 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 21 Jan 2005 14:16:48 -0500 Subject: Evolution 2.2, OpenOffice 2.0, Gnome 2.10 In-Reply-To: <1106334041.6561.3.camel@localhost.localdomain> References: <1106334041.6561.3.camel@localhost.localdomain> Message-ID: <1106335008.356.31.camel@golem.boston.redhat.com> On Fri, 2005-01-21 at 12:00 -0700, Trever L. Adams wrote: > I believe I saw these on a list for inclusion in FC4. However, there > have been no signs of it yet. > > OO 2 was delayed a bit, so I can see if this was dropped, though I hope > it wasn't. > > Evolution 2.1.x should go beta for 2.2 very shortly (may have happened, > but release not done yet). > > Gnome 2.10 is on more or less the same schedule as 2.1.x. > > When, if, are we going to see these in rawhide? We're planning to push Gnome 2.10 into rawhide between Gnome 2.10 beta1 and FC4 test1. Matthias From walters at redhat.com Fri Jan 21 19:14:31 2005 From: walters at redhat.com (Colin Walters) Date: Fri, 21 Jan 2005 14:14:31 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106333362.3427.19.camel@localhost.localdomain> References: <1106333362.3427.19.camel@localhost.localdomain> Message-ID: <1106334872.3809.3.camel@nexus.verbum.private> On Fri, 2005-01-21 at 11:49 -0700, Trever L. Adams wrote: > So, why is grip being removed? > > Sound Juicer does not yet allow quality selection. It will; grip is a good candidate for extras. From barryn at pobox.com Fri Jan 21 19:15:50 2005 From: barryn at pobox.com (Barry K. Nathan) Date: Fri, 21 Jan 2005 11:15:50 -0800 Subject: Is there a working swsusp for FC3 2.6.10? In-Reply-To: <41F09ABB.1060503@trimble.co.nz> References: <41F04357.4020108@trimble.co.nz> <20050121030930.GA6292@ip68-4-98-123.oc.oc.cox.net> <41F09ABB.1060503@trimble.co.nz> Message-ID: <20050121191550.GB6292@ip68-4-98-123.oc.oc.cox.net> On Fri, Jan 21, 2005 at 07:01:31PM +1300, Jason Haar wrote: > Oh - that's news to me. I only know of swsusp.sf.net. > > ...I guess that'd be why I wasn't any more specific ;-) > > Care to point me at the forks? swsusp.sf.net (swsusp2) is one of the forks. The other fork is the swsusp that comes in the mainline kernel. (The most up-to-date version of this fork, in recent times anyway, tends to be the one that ships in the -mm patches; this version tends to go into mainline several days afterward.) (There used to be a third fork, pmdisk, but it was merged into mainline swsusp a few kernel versions ago.) Personally, I haven't used swsusp2, because mainline swsusp has been working reasonably well for me. I intend to try swsusp2 eventually, but I'm not sure when that will be... -Barry K. Nathan From barryn at pobox.com Fri Jan 21 19:23:11 2005 From: barryn at pobox.com (Barry K. Nathan) Date: Fri, 21 Jan 2005 11:23:11 -0800 Subject: Is there a working swsusp for FC3 2.6.10? In-Reply-To: <1106302722.3495.15.camel@roque> References: <41F04357.4020108@trimble.co.nz> <20050121030930.GA6292@ip68-4-98-123.oc.oc.cox.net> <41F09ABB.1060503@trimble.co.nz> <20050121061538.GA12868@jadzia.bu.edu> <1106288921.5199.6.camel@localhost.localdomain> <1106302722.3495.15.camel@roque> Message-ID: <20050121192311.GC6292@ip68-4-98-123.oc.oc.cox.net> On Fri, Jan 21, 2005 at 10:18:41AM +0000, Rui Miguel Seabra wrote: > I want to run that risk. Exactly what flags do I need to make =y in the > i686 kernel config of FC's Linux src.rpm ? > > I've tried the obvious one, but the kernel _never_ compiles :| I think that compile failure was being caused by the 4g4g patch (at least, that used to be the case). 2.6.9/10's swsusp is slow and fragile compared to current mainline swsusp, so things might work out better if you try with FC4 kernels. I need to get swsusp working on FC3 on my own laptop, so I'll have to tackle this problem soon. However, I might not get to it for another week or two. -Barry K. Nathan From jspaleta at gmail.com Fri Jan 21 19:49:05 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Jan 2005 14:49:05 -0500 Subject: Alien Night vs ksh (was: rawhide report: 20050121 changes) In-Reply-To: <1106329858.12994.25.camel@mentorng.gurulabs.com> References: <1106329858.12994.25.camel@mentorng.gurulabs.com> Message-ID: <604aa7910501211149342a9fc8@mail.gmail.com> On Fri, 21 Jan 2005 10:50:57 -0700, Dax Kelson wrote: > If you want to save 350kb, then pick one of the following and ditch it > instead: > > /usr/share/wallpapers/alien-night.jpg > /usr/share/wallpapers/kiagara.jpg > /usr/share/wallpapers/Island-of-Elba.jpg You could save a lot more space by just removing the whole package that owns these files. -jef"why does kde come with so many wallpapers anyways?"spaleta From malists at epon.ro Fri Jan 21 20:06:58 2005 From: malists at epon.ro (Marius Andreiana) Date: Fri, 21 Jan 2005 22:06:58 +0200 Subject: removing packages in fedora; nedit Message-ID: <1106338018.4351.17.camel@marte.biciclete.ro> It was good to see some packages removed from fedora to make room for new ones. I guess all had alternatives (except gnuchess/xboard, I thought about maintaining it in Extras but then remembered how it always beats me and grinned :-D ) Still, would be nice to have a proposal for removal on devel list first. Feels more like community. How about removing nedit too? I find out about it by typing "nc" instead of mc (nc is also netcat) Waiting for FC Extras submitting policy to be done and commit Hylafax, -- Marius Andreiana Epon Business Applications http://www.epon.ro From toshio at tiki-lounge.com Fri Jan 21 20:22:00 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Fri, 21 Jan 2005 12:22:00 -0800 Subject: rawhide report: 20050121 changes In-Reply-To: <200501211308.40737.rjune@bravegnuworld.com>; from rjune@bravegnuworld.com on Fri, Jan 21, 2005 at 01:08:38PM -0500 References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> Message-ID: <20050121122200.A24036@tiki-lounge.com> On Fri, Jan 21, 2005 at 01:08:38PM -0500, Richard June wrote: > > GNOME is the default desktop, so of course it shouldn't be removed. I'm > > wary of moving KDE due to the political issues, but I wouldn't mind > > seeing all the other WMs and DEs moved (XFCE, for one). > I'm with you, keep GNOME and KDE in core. everything else can go in extras > *especially* after there's a graphical yum client/software manager that's > included in core. > Although KDE and GNOME fill pretty much the same niche while XFCE aims for a slightly different goal.... Having things in Core means you don't have to download if you can buy the CDs. XFCE is targetted at people with older hardware. Are they more likely to be highly technical people rescuing older hardware and therefore going to have high speed access or poor and therefore more likely to be on dialup? -Toshio From rms at 1407.org Fri Jan 21 19:39:50 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Fri, 21 Jan 2005 19:39:50 +0000 Subject: Is there a working swsusp for FC3 2.6.10? In-Reply-To: <20050121192311.GC6292@ip68-4-98-123.oc.oc.cox.net> References: <41F04357.4020108@trimble.co.nz> <20050121030930.GA6292@ip68-4-98-123.oc.oc.cox.net> <41F09ABB.1060503@trimble.co.nz> <20050121061538.GA12868@jadzia.bu.edu> <1106288921.5199.6.camel@localhost.localdomain> <1106302722.3495.15.camel@roque> <20050121192311.GC6292@ip68-4-98-123.oc.oc.cox.net> Message-ID: <1106336391.3495.1.camel@roque> On Fri, 2005-01-21 at 11:23 -0800, Barry K. Nathan wrote: > On Fri, Jan 21, 2005 at 10:18:41AM +0000, Rui Miguel Seabra wrote: > > I want to run that risk. Exactly what flags do I need to make =y in the > > i686 kernel config of FC's Linux src.rpm ? > > > > I've tried the obvious one, but the kernel _never_ compiles :| > > I think that compile failure was being caused by the 4g4g patch (at > least, that used to be the case). > > 2.6.9/10's swsusp is slow and fragile compared to current mainline > swsusp, so things might work out better if you try with FC4 kernels. I'm using rawhide. > I need to get swsusp working on FC3 on my own laptop, so I'll have to > tackle this problem soon. However, I might not get to it for another > week or two. Unless you get the patch and proper Linux versions, it's a hell to try. Specially with FC's Linux :| Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From elanthis at awesomeplay.com Fri Jan 21 20:41:50 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 21 Jan 2005 15:41:50 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <20050121122200.A24036@tiki-lounge.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <20050121122200.A24036@tiki-lounge.com> Message-ID: <1106340110.31381.65.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2005-01-21 at 12:22 -0800, Toshio Kuratomi wrote: > Having things in Core means you don't have to download if you can buy the > CDs. XFCE is targetted at people with older hardware. Are they more likely > to be highly technical people rescuing older hardware and therefore going to > have high speed access or poor and therefore more likely to be on dialup? Personally, I think Extras should be included in most CD sets, and that it should be supported in the installer. (Obviously not in FC4, maybe in FC5.) Especially when DVD distributions are a little more common, it's entirely realistic to expect a user to have both Core and Extras on disk. > > -Toshio > From fedora at wir-sind-cool.org Fri Jan 21 21:09:27 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 21 Jan 2005 22:09:27 +0100 Subject: graphviz (was: Alien Night vs ksh (was: rawhide report: 20050121 changes)) In-Reply-To: <41F14F8A.5040104@research.att.com> References: <1106329858.12994.25.camel@mentorng.gurulabs.com> <20050121181138.GD9611@redhat.com> <41F14F8A.5040104@research.att.com> Message-ID: <20050121220927.5cd86cfa.fedora@wir-sind-cool.org> On Fri, 21 Jan 2005 13:52:58 -0500, John Ellson wrote: > Just FYI: Graphviz, also from AT&T Research, is also now released > under the CPL. > http://www.graphviz.org/ > > There is a pre-CPL version in extras, but I don't know who is looking > after it and > they don't respond to bugzilla. If someone-in-charge of Fedora would > like me (a graphviz author) to maintain it, > please let me know how... A few comments here. Your bug report didn't go unnoticed. But we're still dealing with "pre-Extras" which was chosen to be another step on the road of migration from unofficial Fedora Linux (fedora.us) to fully official Fedora Extras. There are no means yet for outside contributors to get CVS access. And hence the only way you could maintain the package currently is by supplying patches and/or fully prepared source rpms and getting the current package owner to apply them. Your bug report requests that "an update of graphviz is needed". But it lacks any information whether all of current extra packages, which use graphviz as a build requirement, do rebuild fine with the new major version. As one of the authors I bet you either know that. Or else it would need to be tested by somebody. From jwboyer at jdub.homelinux.org Fri Jan 21 22:04:21 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 21 Jan 2005 16:04:21 -0600 Subject: rawhide report: 20050121 changes In-Reply-To: <200501211308.40737.rjune@bravegnuworld.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> Message-ID: <1106345061.8056.12.camel@jdub.homelinux.org> On Fri, 2005-01-21 at 13:08 -0500, Richard June wrote: > > GNOME is the default desktop, so of course it shouldn't be removed. I'm > > wary of moving KDE due to the political issues, but I wouldn't mind > > seeing all the other WMs and DEs moved (XFCE, for one). > I'm with you, keep GNOME and KDE in core. everything else can go in extras > *especially* after there's a graphical yum client/software manager that's > included in core. One could argue that Xorg and fvmw2 are all that's needed for Core. Minimalistic to the bone. If KDE goes to Extras, then GNOME needs to as well. But like most others said, I'd rather see both GNOME and KDE available in Core. That allows people that are new to Fedora, and Linux in general, the ability to play around and choose which they like better without downloading MiB worth of RPMs. josh From elanthis at awesomeplay.com Fri Jan 21 22:17:00 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 21 Jan 2005 17:17:00 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <1106345061.8056.12.camel@jdub.homelinux.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> Message-ID: <1106345821.31381.77.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2005-01-21 at 16:04 -0600, Josh Boyer wrote: > On Fri, 2005-01-21 at 13:08 -0500, Richard June wrote: > > > GNOME is the default desktop, so of course it shouldn't be removed. I'm > > > wary of moving KDE due to the political issues, but I wouldn't mind > > > seeing all the other WMs and DEs moved (XFCE, for one). > > I'm with you, keep GNOME and KDE in core. everything else can go in extras > > *especially* after there's a graphical yum client/software manager that's > > included in core. > > One could argue that Xorg and fvmw2 are all that's needed for Core. > Minimalistic to the bone. If KDE goes to Extras, then GNOME needs to as > well. It's not "strip down," it's, "only provide one option." GNOME, KDE, and XFCE are the only actual desktop environments in the system. (Yes, there is a very big difference between a desktop environment and a window manager.) Three desktops environments aren't needed. Of the three, two are very popular and very politically charged, the third is in fact an extra provided mostly for low-resource folks. *If* KDE is removed (and I don't think it will be, or should be at this time) then that doesn't mean GNOME should be removed. GNOME is the default, KDE is by definition (by not being the default) provided as an extra desktop in addition to GNOME. I certainly wouldn't mind seeing Core become the bare minimum, and then split Extras into sets like Network Server, GNOME Desktop, KDE Desktop, Desktop Applications, and so on. That's a fundamentally different distribution model than the Fedora Core/Extras split, though. From jwboyer at jdub.homelinux.org Fri Jan 21 22:29:35 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 21 Jan 2005 16:29:35 -0600 Subject: rawhide report: 20050121 changes In-Reply-To: <1106345821.31381.77.camel@support02.civic.twp.ypsilanti.mi.us> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106345821.31381.77.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1106346575.8056.24.camel@jdub.homelinux.org> On Fri, 2005-01-21 at 17:17 -0500, Sean Middleditch wrote: > On Fri, 2005-01-21 at 16:04 -0600, Josh Boyer wrote: > > > > One could argue that Xorg and fvmw2 are all that's needed for Core. > > Minimalistic to the bone. If KDE goes to Extras, then GNOME needs to as > > well. > > It's not "strip down," it's, "only provide one option." GNOME, KDE, and > XFCE are the only actual desktop environments in the system. (Yes, > there is a very big difference between a desktop environment and a > window manager.) Yeah, I know. That's why I don't want either GNOME or KDE to go. > > Three desktops environments aren't needed. Of the three, two are very > popular and very politically charged, the third is in fact an extra > provided mostly for low-resource folks. > > *If* KDE is removed (and I don't think it will be, or should be at this > time) then that doesn't mean GNOME should be removed. GNOME is the > default, KDE is by definition (by not being the default) provided as an > extra desktop in addition to GNOME. I'll agree with you there, but with one twist. *If* a desktop environment is to be moved to Extras, why would it have to be KDE? Or in other words, why is GNOME the default? Because of historical reasons? Like you said, GNOME vs. KDE is hugely political or as others like to call it, religion. In a community driven distribution, which Fedora is supposed to be, you'll never get everyone to agree which environment should be the default. So instead of having an endless debate over which should be the default and which should go, I'd just rather see both stay. josh From lux at diesel-research.com Fri Jan 21 22:41:14 2005 From: lux at diesel-research.com (Kim Lux) Date: Fri, 21 Jan 2005 15:41:14 -0700 Subject: Any known bugs in gcc wrt symbols in gdb and/or var allocation ? Message-ID: <1106347274.9288.28.camel@localhost.localdomain> I think I've found 2 issues with gcc-3.4.2-6.fc3. Consider the following code: void dbug12_stop_reason (enum dbug12_stop *reason, int *sigrc) { int replyEnd; unsigned char reply[254]; replyEnd = 0; // get the reply replyEnd = dbug12_get_reply(reply); printf("Reply is %s\n",reply); // handle the error condition // can't pass here with a zero length if (replyEnd == 0) ... Problem #1: gdb cannot find replyEnd: (gdb) whatis replyEnd No symbol "replyEnd" in current context. Problem #2: The code doesn't execute properly if I delete the "replyEnd = 0;" line. Without "replyEnd = 0;" in the code, it gets an unalterable junk value. With "replyEnd = 0;" in the code, replyEnd gets set to the return value of dbug12_get_reply, which it should. BTW: the definition of dbug12_get_reply is: static int dbug12_get_reply (unsigned char *packet) I was also playing around with changing the size of the reply buffer, ie "reply[255]", reply[253], etc. It didn't look like gcc was changing the size of the buffer on a clean build. It looks like gcc isn't allocating something properly. Has anyone seen anything like this before ? rpm -q gdb gdb-6.1post-1.20040607.43 Thanks -- Kim Lux, Diesel Research Inc. From jspaleta at gmail.com Fri Jan 21 23:16:21 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Jan 2005 18:16:21 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <1106318479.9659.5.camel@dcbw.boston.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> Message-ID: <604aa79105012115166926aec5@mail.gmail.com> On Fri, 21 Jan 2005 09:41:19 -0500, Dan Williams wrote: > Furthermore, these are really just leaving Fedora Core, but should still > be in Fedora Extras AFAIK. This is entirely unclear to anyone sitting outside the Red Hat fenceline. I have no idea if the people who maintain something inside Core will continue to be required to maintain or volunteer to maintain the package as part of Extras. I fully expect some packages will have to change maintainers as part of moving to Extras. If i had the luxury to demand one thing from Red Hat package maintainers I would demand to know if for each dropped package out of Core if the Red Hat maintainer who was maintaining it inside Core is going to continue maintain it as part of Extras of if a community member needs to be found to maintain the dropped packages. It is totally unclear from my perspective whether or not dropped from Core means the original Core maintainer is no longer going to be the person maintaining it in Extras. For every package dropped from Core from now on... i want to know if its being orphaned by the maintainer and if a new maintainer needs to be found. And i want to know it ASAP. I want the list of orphaned packages consolidated into a webpage so that its easily cross-referenced when questions about why it was totally dropped come up. As soon as Red Hat makes the decision to drop a package from Core and its decided if the original Core maintainer is not going to maintain it as part of Extras.. the community needs to be told.. so the community can determine a new maintainer and start the indoctrination of a new maintainer if the person who steps up is a packaging novice. For orphaned packages that the original Core maintainer is no longer going to maintain as part of Extras.. The ealier the community knows its orphaned... the less time it will be unavailable if a new packager is the one who steps up out of the community and volunteers to maintain it. I'm not asking for a garuntee that the package will always be available. But I am asking that the community be given as much lead time as possible to start the process of selecting a new maintainer. If ANY of these packages are not going to be maintained by the original Core maintainers as part of Extras... tell the community NOW so that someone can step up and offer to maintain it. -jef"Don't make me read your minds... my brain wave laser tends to cause dandruff"spaleta From notting at redhat.com Fri Jan 21 23:49:43 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 21 Jan 2005 18:49:43 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <604aa79105012115166926aec5@mail.gmail.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> Message-ID: <20050121234943.GA6392@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > If ANY of these packages are not going to be maintained by the > original Core maintainers as part of Extras... tell the community NOW > so that someone can step up and offer to maintain it. You're absolutely correct. This is how it stands, AFAIK: Orphaned: - aumix - balsa/libesmtp (really, they go together) - cdp - comsat - grip - gv - pdksh (then again, it's getting replaced by ksh) - sylpheed - xosview - xsnow - ytalk Not sure: - diskcheck - freeciv - gnuchess - pan - xboard Bill From jspaleta at gmail.com Fri Jan 21 23:58:24 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Jan 2005 18:58:24 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <20050121234943.GA6392@nostromo.devel.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> Message-ID: <604aa7910501211558581fb9d2@mail.gmail.com> On Fri, 21 Jan 2005 18:49:43 -0500, Bill Nottingham wrote: > You're absolutely correct. This is how it stands, AFAIK: you have fedoraproject.org wiki write access right? right? hint hint -jef"sharpens his eye-poking stick because its become blunt with over use"spaleta From notting at redhat.com Fri Jan 21 23:58:49 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 21 Jan 2005 18:58:49 -0500 Subject: further package removals/potential package removals Message-ID: <20050121235849.GA6469@nostromo.devel.redhat.com> Removed and orphaned: asp2php - does not show any history of usage, not really a core package Suggested for removal: xloadimage - there are better apps for displaying images (ImageMagick, eog, gthumb, kview, etc) - there are better apps for setting the root window (xsri) - it's *ancient* code that doesn't even support PNG nedit - legacy interface (motif) - doesn't support Unicode jed - doesn't support Unicode Opinions? Bill From pri.rhl3 at iadonisi.to Sat Jan 22 00:01:01 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Fri, 21 Jan 2005 19:01:01 -0500 Subject: further package removals/potential package removals In-Reply-To: <20050121235849.GA6469@nostromo.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> Message-ID: <1106352061.11656.1.camel@md.local.linuxlobbyist.org> On Fri, 2005-01-21 at 18:58 -0500, Bill Nottingham wrote: > Removed and orphaned: > asp2php - does not show any history of usage, not really a core package > > Suggested for removal: > > xloadimage > - there are better apps for displaying images (ImageMagick, > eog, gthumb, kview, etc) > - there are better apps for setting the root window (xsri) > - it's *ancient* code that doesn't even support PNG > nedit > - legacy interface (motif) > - doesn't support Unicode > jed > - doesn't support Unicode > > Opinions? Blast 'em all. But please keep joe. It helped tremendously when vim was broken a few days ago. :-) -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From kyrre at solution-forge.net Sat Jan 22 00:07:30 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 22 Jan 2005 01:07:30 +0100 Subject: RFC: Optimizing for 386 In-Reply-To: <1106246277.19994.6.camel@tuxpaq> References: <3khdfd$heo20h@mxip04a.cluster1.charter.net> <1106172965.2663.16.camel@localhost.localdomain> <1106179640.5599.6.camel@stargrazer.home.awesomeplay.com> <1106244351.5344.36.camel@localhost.localdomain> <1106246277.19994.6.camel@tuxpaq> Message-ID: <1106352450.6775.3.camel@localhost.localdomain> tor, 20.01.2005 kl. 19.37 skrev Paul Iadonisi: > On Thu, 2005-01-20 at 19:05 +0100, Kyrre Ness Sjobak wrote: > > [snip] > > > *rant* > > [bunch of political crap snipped] > > > */rant* > > Please realize that fedora-devel list members are likely of wide and > varied political opinion (as well as wide and varied country of > residence and/or citizenship) and keep this kind of crap off this list. Just got a bit provoked. I had a long argument about if we could afford upgrading one computer from 128 to 256 MB of RAM. Turned out we could only afford a 64 MB chip scavenged from a defunct older box (which was also scavenged for PSU, CPU-fan, HDD, floppy, cdrom etc. pretty enviromentaly friendly, tough. From kyrre at solution-forge.net Sat Jan 22 00:41:28 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 22 Jan 2005 01:41:28 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106320733.31381.29.camel@support02.civic.twp.ypsilanti.mi.us> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <87mzv23jn2.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106320733.31381.29.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1106354487.6775.6.camel@localhost.localdomain> > http://www.gnome.org/projects/evince/ > > (FC RPMs available at that site) Ugh.. but they doesn't work - at least not on my computers. fc2 and fc3. Do those require rawhide? On the fc3 sys it sais it needs gtk2 >= 2.6, but fc3 only has 2.4 ... From jspaleta at gmail.com Sat Jan 22 00:49:21 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Jan 2005 19:49:21 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <1106354487.6775.6.camel@localhost.localdomain> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <87mzv23jn2.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106320733.31381.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106354487.6775.6.camel@localhost.localdomain> Message-ID: <604aa79105012116494482f060@mail.gmail.com> On Sat, 22 Jan 2005 01:41:28 +0100, Kyrre Ness Sjobak wrote: > > http://www.gnome.org/projects/evince/ > > > > (FC RPMs available at that site) > > Ugh.. but they doesn't work - at least not on my computers. fc2 and fc3. > Do those require rawhide? On the fc3 sys it sais it needs gtk2 >= 2.6, > but fc3 only has 2.4 ... it works once you get the rawhide gtk2 installed on your system.... and since this is a discussion about the development tree.... that requirement seems appropriate to me. -jef From riel at redhat.com Sat Jan 22 00:58:36 2005 From: riel at redhat.com (Rik van Riel) Date: Fri, 21 Jan 2005 19:58:36 -0500 (EST) Subject: RFC: Optimizing for 386 In-Reply-To: <3k77vd$gbck0f@mxip10a.cluster1.charter.net> References: <3k77vd$gbck0f@mxip10a.cluster1.charter.net> Message-ID: On Wed, 19 Jan 2005, Joseph D. Wagner wrote: > I would like my ABI, especially for the graphics programs, to be > optimized for more modern architecture, like i686. Why ? How much benefit does this provide in your tests ? -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From pbrobinson at gmail.com Sat Jan 22 01:05:19 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Sat, 22 Jan 2005 09:05:19 +0800 Subject: further package removals/potential package removals In-Reply-To: <20050121235849.GA6469@nostromo.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> Message-ID: <5256d0b050121170521aa145b@mail.gmail.com> > Opinions? Yep, get rid of them. Can we also get rid / move to extras all the non GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK 1 cruft as well? pete From fedora-devel at tlarson.com Sat Jan 22 02:41:48 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Fri, 21 Jan 2005 19:41:48 -0700 Subject: Power off Message-ID: <41F1BD6C.3000801@tlarson.com> I ran into a problem (bug?) that I would like to help solve, but I'm at a loss as to where to go next. My laptop (Dell C400) used to run Linux just fine, dual boot with Windows. In the past few months, I've installed XP SP2 on the Windows side, reinstalled Windows a few times (it happens), and updated by BIOS image. I somehow managed to trash my partition table attempting to put GRUB back as my bootloader, then had to reinstall everything all over again (windows and Linux). I've since downgraded the BIOS to the previous known-good version to try and fix the thing. Windows works fine, but on the Linux side.... The computer powers itself off without warning--no matter what is, or isn't, running. Certain things seem to trigger it, and it may be tied to high CPU load. I can trigger the shutdown fairly reliably by running aircrack on a packet capture file. To rule out any background services as being the culprit, I booted with init=/bin/bash, ran aircrack, and sure enough, it powered off after about 90 seconds. This behavior has continued no matter what kernel I use--I'ved tried with both the original FC3 kernel and the most recent one. In fact, the machine powered itself down a number of times while I was running off the install CD. It took 10 tries before I got it to complete the install process. So, my question to you all is--how can I possibly get some useful information to start diagnosing this problem? There's nothing in the logs on disk, of course. There's no warning, no panic, no nothing. Just a quick *plink* and it's gone. From dmalcolm at redhat.com Sat Jan 22 03:04:35 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 21 Jan 2005 22:04:35 -0500 Subject: Evolution 2.2, OpenOffice 2.0, Gnome 2.10 In-Reply-To: <1106334041.6561.3.camel@localhost.localdomain> References: <1106334041.6561.3.camel@localhost.localdomain> Message-ID: <1106363075.28097.3.camel@cassandra.boston.redhat.com> On Fri, 2005-01-21 at 12:00 -0700, Trever L. Adams wrote: > I believe I saw these on a list for inclusion in FC4. However, there > have been no signs of it yet. > > OO 2 was delayed a bit, so I can see if this was dropped, though I hope > it wasn't. > > Evolution 2.1.x should go beta for 2.2 very shortly (may have happened, > but release not done yet). I plan to push this into Rawhide next week - and there are quite a few packages depending on evolution-data-server these days (gaim, gnome-panel and OO, IIRC) so I'll need to fixup these when I do. > > Gnome 2.10 is on more or less the same schedule as 2.1.x. > > When, if, are we going to see these in rawhide? > > Is there anything I can do? > > Trever > -- > "He that demands mercy, and shows none, ruins the bridge over which he > himself is to pass." -- Thomas Adams, 1612-1653 > From dcbw at redhat.com Sat Jan 22 03:11:23 2005 From: dcbw at redhat.com (Dan Williams) Date: Fri, 21 Jan 2005 22:11:23 -0500 (EST) Subject: rawhide report: 20050121 changes In-Reply-To: <604aa79105012115166926aec5@mail.gmail.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> Message-ID: On Fri, 21 Jan 2005, Jeff Spaleta wrote: > On Fri, 21 Jan 2005 09:41:19 -0500, Dan Williams wrote: > > Furthermore, these are really just leaving Fedora Core, but should still > > be in Fedora Extras AFAIK. > > This is entirely unclear to anyone sitting outside the Red Hat > fenceline. I have no idea if the people who maintain something inside > Core will continue to be required to maintain or volunteer to maintain > the package as part of Extras. I fully expect some packages will have > to change maintainers as part of moving to Extras. I currently own 'gv', and I don't particularly want to maintain it outside of Fedora Core. Somebody who knows, likes, and uses gv would be a much better person for the job, since I also own a bunch of other packages, some quite large (openoffice.org). If some other person was able to focus their time on gv, I think that would be a win for users of the package. This however is my opinion, and isn't necessarily indicative of how changes to the gv package will play out. Dan From hp at redhat.com Sat Jan 22 03:36:20 2005 From: hp at redhat.com (Havoc Pennington) Date: Fri, 21 Jan 2005 22:36:20 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <604aa79105012115166926aec5@mail.gmail.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> Message-ID: <1106364980.29183.109.camel@localhost.localdomain> Doesn't debian have some type of "orphaned package" process? We should have a look at that. Havoc From mattdm at mattdm.org Sat Jan 22 03:48:49 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 21 Jan 2005 22:48:49 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106352061.11656.1.camel@md.local.linuxlobbyist.org> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106352061.11656.1.camel@md.local.linuxlobbyist.org> Message-ID: <20050122034849.GA26087@jadzia.bu.edu> On Fri, Jan 21, 2005 at 07:01:01PM -0500, Paul Iadonisi wrote: > Blast 'em all. But please keep joe. It helped tremendously when vim > was broken a few days ago. :-) It now passes the "supports unicode" litmus test, at least. :) -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From jspaleta at gmail.com Sat Jan 22 03:51:18 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 21 Jan 2005 22:51:18 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <1106364980.29183.109.camel@localhost.localdomain> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <1106364980.29183.109.camel@localhost.localdomain> Message-ID: <604aa791050121195170c659bd@mail.gmail.com> On Fri, 21 Jan 2005 22:36:20 -0500, Havoc Pennington wrote: > Doesn't debian have some type of "orphaned package" process? We should > have a look at that. debian also has longer timescales between releases.... I'm somewhat concerned about when in the development process Red Hat makes decisions as to what gets orphaned and whether or not there is going to be enough time for new community members step up, jump through whatever legal hoops are in place around Extras, earn access to the build system and produce an Extras package before the next Core release. I'd personal rather not have any packages orphaned by Red Hat maintainers until Extras policy is flushed out. I have a twisted dark malevolent desire to force Red Hat developers to maintain the the packages dropped from Core this time around in Extras, as an experimental group for the Extras process. I'd really like to have a process with enough lead time so that when the community learns a package is to be orphaned there is a reasonable chance that a community member can get a package into Extras before the next Core is released. While we surely can not gartunee that an orphaned package will be available in time as an Extras for the next Core.. i'd hate to see a process where the timescales were such that we could garunteed that an orphaned package would never be ready in time. I'd like to make sure that a good-faith effort by a proactive community member will be rewarded with a package in Extras by the next Core release. -jef From feliciano.matias at free.fr Sat Jan 22 04:16:30 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sat, 22 Jan 2005 05:16:30 +0100 Subject: further package removals/potential package removals In-Reply-To: <20050121235849.GA6469@nostromo.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> Message-ID: <1106367390.5183.14.camel@one.myworld> Le vendredi 21 janvier 2005 ? 18:58 -0500, Bill Nottingham a ?crit : > Removed and orphaned: > asp2php - does not show any history of usage, not really a core package > > Suggested for removal: > > (...) > nedit > - legacy interface (motif) ddd use motif :-) > - doesn't support Unicode > jed > - doesn't support Unicode > > Opinions? Move to Fedora Extra : dosfstools Lynx (or elinks) lesstif and/or openmotif21 > > Bill > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dcbw at redhat.com Sat Jan 22 04:31:08 2005 From: dcbw at redhat.com (Dan Williams) Date: Fri, 21 Jan 2005 23:31:08 -0500 (EST) Subject: further package removals/potential package removals In-Reply-To: <1106367390.5183.14.camel@one.myworld> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> Message-ID: On Sat, 22 Jan 2005, [ISO-8859-1] F?liciano Matias wrote: > ddd use motif :-) We don't really have any other standalone graphical debuggers AFAIK, but we do have quite a few text editors... Dan From cmadams at hiwaay.net Sat Jan 22 04:33:10 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 21 Jan 2005 22:33:10 -0600 Subject: rawhide report: 20050121 changes In-Reply-To: <20050121234943.GA6392@nostromo.devel.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> Message-ID: <20050122043310.GA1067121@hiwaay.net> Once upon a time, Bill Nottingham said: > Not sure: > - pan Pan is still in rawhide; I take it it won't be for long? What are we supposed to use instead of pan? Last time I tried to load a large binaries group (alt.binaries.emulators.mame) in Thunderbird it locked up solid. Also, does Thunderbird handle yEnc (Mozilla didn't last time I tried)? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From katzj at redhat.com Sat Jan 22 04:48:08 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 21 Jan 2005 23:48:08 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <1106354487.6775.6.camel@localhost.localdomain> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <87mzv23jn2.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106320733.31381.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106354487.6775.6.camel@localhost.localdomain> Message-ID: <1106369288.4002.31.camel@bree.local.net> On Sat, 2005-01-22 at 01:41 +0100, Kyrre Ness Sjobak wrote: > > http://www.gnome.org/projects/evince/ > > > > (FC RPMs available at that site) > > Ugh.. but they doesn't work - at least not on my computers. fc2 and fc3. > Do those require rawhide? On the fc3 sys it sais it needs gtk2 >= 2.6, > but fc3 only has 2.4 ... They require gtk+ 2.6. evince is taking advantage of some of the new functionality provided. And as Jef says, this _is_ the development list. :-) Jeremy From feliciano.matias at free.fr Sat Jan 22 04:51:03 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sat, 22 Jan 2005 05:51:03 +0100 Subject: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> Message-ID: <1106369463.5183.24.camel@one.myworld> Le vendredi 21 janvier 2005 ? 23:31 -0500, Dan Williams a ?crit : > On Sat, 22 Jan 2005, [ISO-8859-1] Fliciano Matias wrote: > > ddd use motif :-) > > We don't really have any other standalone graphical debuggers AFAIK, but > we do have quite a few text editors... > I love ddd :-) I request to move lesstif and openmotif21 to Fedora Extra. But keep openmotif (use by ddd). Why do we keep xpdf in Fedora Core ? gpdf works fine. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From katzj at redhat.com Sat Jan 22 04:52:20 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 21 Jan 2005 23:52:20 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106367390.5183.14.camel@one.myworld> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> Message-ID: <1106369540.4002.34.camel@bree.local.net> On Sat, 2005-01-22 at 05:16 +0100, F?liciano Matias wrote: > dosfstools dosfstools is needed for anaconda. Certain architectures (*cough*ia64*cough*) require a vfat partition for booting. Also, it's helpful in a lot of cases where you have things like USB keys. Jeremy From notting at redhat.com Sat Jan 22 04:53:11 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 21 Jan 2005 23:53:11 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <20050122043310.GA1067121@hiwaay.net> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> <20050122043310.GA1067121@hiwaay.net> Message-ID: <20050122045311.GA14114@nostromo.devel.redhat.com> Chris Adams (cmadams at hiwaay.net) said: > Once upon a time, Bill Nottingham said: > > Not sure: > > - pan > > Pan is still in rawhide; I take it it won't be for long? What are we > supposed to use instead of pan? Last time I tried to load a large > binaries group (alt.binaries.emulators.mame) in Thunderbird it locked up > solid. Also, does Thunderbird handle yEnc (Mozilla didn't last time I > tried)? It's entirely possible I mistyped. But I believe Thunderbird and Evolution both read news. Bill From katzj at redhat.com Sat Jan 22 04:58:03 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 21 Jan 2005 23:58:03 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106369463.5183.24.camel@one.myworld> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <1106369463.5183.24.camel@one.myworld> Message-ID: <1106369883.4002.40.camel@bree.local.net> On Sat, 2005-01-22 at 05:51 +0100, F?liciano Matias wrote: > Why do we keep xpdf in Fedora Core ? > gpdf works fine. gpdf works with a much smaller subset of pdfs than gpdf. There's hope, though. evince[1] will save us all from our crappy widget PDF viewing experience. Jeremy [1] http://www.gnome.org/projects/evince/ From davej at redhat.com Sat Jan 22 05:09:53 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 22 Jan 2005 00:09:53 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <20050122045311.GA14114@nostromo.devel.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> <20050122043310.GA1067121@hiwaay.net> <20050122045311.GA14114@nostromo.devel.redhat.com> Message-ID: <20050122050953.GB28219@redhat.com> On Fri, Jan 21, 2005 at 11:53:11PM -0500, Bill Nottingham wrote: > > Pan is still in rawhide; I take it it won't be for long? What are we > > supposed to use instead of pan? Last time I tried to load a large > > binaries group (alt.binaries.emulators.mame) in Thunderbird it locked up > > solid. Also, does Thunderbird handle yEnc (Mozilla didn't last time I > > tried)? > It's entirely possible I mistyped. But I believe Thunderbird and > Evolution both read news. Evolution and Thunderbird are also utterly unusable on a machine with < 256MB, and a slow CPU in my experience, whereas pan seemed very capable of running comfortably in 128MB. Dave From rahulsundaram at gmail.com Sat Jan 22 08:49:20 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sat, 22 Jan 2005 14:19:20 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <87mzv23jn2.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106320733.31381.29.camel@support02.civic.twp.ypsilanti.mi.us> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: Hi > GNOME is the default desktop, so of course it shouldn't be removed. I'm > wary of moving KDE due to the political issues, but I wouldn't mind > seeing all the other WMs and DEs moved (XFCE, for one). > political reasons are there for xfce and even for the argument of including something like fluxbox in core. you need clear technical arguments to retain packages in core. there are some hard decisions to be made fedora core has a defined goal of including only defaults and moving the rest of the stuff to extras and alternatives. -- Regards, Rahul Sundaram From rahulsundaram at gmail.com Sat Jan 22 08:51:34 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sat, 22 Jan 2005 14:21:34 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <1106346575.8056.24.camel@jdub.homelinux.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106345821.31381.77.camel@support02.civic.twp.ypsilanti.mi.us> <1106346575.8056.24.camel@jdub.homelinux.org> Message-ID: Hi > I'll agree with you there, but with one twist. *If* a desktop > environment is to be moved to Extras, why would it have to be KDE? Or > in other words, why is GNOME the default? Because of historical > reasons? No. because redhat has more gnome developers and does all its integration bits for gnome. its the default desktop environment. > > Like you said, GNOME vs. KDE is hugely political or as others like to > call it, religion. In a community driven distribution, which Fedora is > supposed to be, you'll never get everyone to agree which environment > should be the default. so, lets have xfce, fluxbox and the rest of the gang inside core?. why call it fedora core anymore then. thats going the way of debian -- Regards, Rahul Sundaram From lfarkas at bppiac.hu Sat Jan 22 08:54:25 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Sat, 22 Jan 2005 09:54:25 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <20050121234943.GA6392@nostromo.devel.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> Message-ID: <41F214C1.8090006@bppiac.hu> Bill Nottingham wrote: > Jeff Spaleta (jspaleta at gmail.com) said: > >>If ANY of these packages are not going to be maintained by the >>original Core maintainers as part of Extras... tell the community NOW >>so that someone can step up and offer to maintain it. > > > You're absolutely correct. This is how it stands, AFAIK: > Not sure: > - diskcheck is there anything which can be used in stead of diskcheck? -- Levente "Si vis pacem para bellum!" From rahulsundaram at gmail.com Sat Jan 22 08:54:59 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sat, 22 Jan 2005 14:24:59 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <1106345061.8056.12.camel@jdub.homelinux.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> Message-ID: Hi > One could argue that Xorg and fvmw2 are all that's needed for Core. > Minimalistic to the bone. no. fvwm2 is not a typical DE. . That allows people that are new to Fedora, and Linux in > general, the ability to play around and choose which they like better > without downloading MiB worth of RPMs. extras can be packaged as a ISO image. you need to download the whole of fedora or buy it from a third party vendor. if fedora extras or a subset of it is an ISO image, then moving KDE into extras is just better reorganisation. the advantage is that fedora core would be limited to the default stuff in one or two cds -- Regards, Rahul Sundaram From i_p_a_u_l at yahoo.com Sat Jan 22 08:55:52 2005 From: i_p_a_u_l at yahoo.com (Paul Ionescu) Date: Sat, 22 Jan 2005 10:55:52 +0200 Subject: Evolution 2.2, OpenOffice 2.0, Gnome 2.10 References: <1106334041.6561.3.camel@localhost.localdomain> <1106363075.28097.3.camel@cassandra.boston.redhat.com> Message-ID: Hi, On Fri, 21 Jan 2005 22:04:35 -0500, David Malcolm wrote: > On Fri, 2005-01-21 at 12:00 -0700, Trever L. Adams wrote: >> I believe I saw these on a list for inclusion in FC4. However, there >> have been no signs of it yet. >> >> OO 2 was delayed a bit, so I can see if this was dropped, though I hope >> it wasn't. >> >> Evolution 2.1.x should go beta for 2.2 very shortly (may have happened, >> but release not done yet). > I plan to push this into Rawhide next week - and there are quite a few > packages depending on evolution-data-server these days (gaim, gnome-panel > and OO, IIRC) so I'll need to fixup these when I do. Don't forget gnomemeeting which also depends on evolution-data-server. From i_p_a_u_l at yahoo.com Sat Jan 22 09:06:55 2005 From: i_p_a_u_l at yahoo.com (Paul Ionescu) Date: Sat, 22 Jan 2005 11:06:55 +0200 Subject: Is there a working swsusp for FC3 2.6.10? References: <41F04357.4020108@trimble.co.nz> <20050121030930.GA6292@ip68-4-98-123.oc.oc.cox.net> <41F09ABB.1060503@trimble.co.nz> <20050121061538.GA12868@jadzia.bu.edu> <1106288921.5199.6.camel@localhost.localdomain> <1106302722.3495.15.camel@roque> Message-ID: Hi, On Fri, 21 Jan 2005 10:18:41 +0000, Rui Miguel Seabra wrote: > On Thu, 2005-01-20 at 22:28 -0800, Per Bjornsson wrote: >> In any case, software suspend is not enabled in the Fedora kernels as >> the Fedora kernel developers find it ugly and dangerous - at least that >> was the last that was the understanding I got last time this was >> discussed on this list. > > I want to run that risk. Exactly what flags do I need to make =y in the > i686 kernel config of FC's Linux src.rpm ? > > I've tried the obvious one, but the kernel _never_ compiles :| I am in the same situation here. But for me software suspend is a stringent requirement, so I had to gave up official FC kernel and build my own. Now I have kernel-2.6.11rc1 with swsusp2 v2.1.5.14 running just fine on my IBM Thinkpad T41 and also is working fine on my colleague's R50p. Of course I would like to have it in FC kernels, but till then, I don't have other option. For a laptop, the ability to suspend is essential. At least it could be enabled in FC kernels but not used by any programs, and let the willing users to try to use it at their own risk. Thx, Paul From i_p_a_u_l at yahoo.com Sat Jan 22 09:12:07 2005 From: i_p_a_u_l at yahoo.com (Paul Ionescu) Date: Sat, 22 Jan 2005 11:12:07 +0200 Subject: rawhide report: 20050121 changes References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> Message-ID: Hi, On Fri, 21 Jan 2005 18:49:43 -0500, Bill Nottingham wrote: > Jeff Spaleta (jspaleta at gmail.com) said: >> If ANY of these packages are not going to be maintained by the original >> Core maintainers as part of Extras... tell the community NOW so that >> someone can step up and offer to maintain it. > Not sure: > - diskcheck > - freeciv > - gnuchess > - pan > - xboard I am using right now PAN to send this message. Not because I don't want to use something else, but because other news programs don't have the functionality of pan yet. And is fast too, compared with other options. Thx, Paul From giallu at gmail.com Sat Jan 22 09:55:04 2005 From: giallu at gmail.com (Gianluca Sforna) Date: Sat, 22 Jan 2005 10:55:04 +0100 Subject: removing packages in fedora; nedit In-Reply-To: <1106338018.4351.17.camel@marte.biciclete.ro> References: <1106338018.4351.17.camel@marte.biciclete.ro> Message-ID: Well, I have quite a few users that WANT nedit for coding, so I am not against this move provided you assure me I can still install it easily (read extras...) and timely update it. While I am at this, is there any easy postinstall method for installing stuff from extras using a kickstart installation?? Cheers Gianluca From caolanm at redhat.com Sat Jan 22 10:27:41 2005 From: caolanm at redhat.com (Caolan McNamara) Date: Sat, 22 Jan 2005 10:27:41 +0000 Subject: Evolution 2.2, OpenOffice 2.0, Gnome 2.10 In-Reply-To: <1106334041.6561.3.camel@localhost.localdomain> References: <1106334041.6561.3.camel@localhost.localdomain> Message-ID: <1106389661.7995.9.camel@sheol.homelinux.org> On Fri, 2005-01-21 at 12:00 -0700, Trever L. Adams wrote: > I believe I saw these on a list for inclusion in FC4. However, there > have been no signs of it yet. > > OO 2 was delayed a bit, so I can see if this was dropped, though I hope > it wasn't. To build the help documentation of OOo2 you require a working java, so I've been working on making OOo and gcj play together well enough to do that, and support a handful of the optional java components. The gcj patches for OOo were approved up-stream on friday. There was a little problem in libgcj which should be resolved soon enough https://bugzilla.redhat.com/beta/show_bug.cgi?id=142366 and then we should be able to push a OOo2 alpha/beta in parallel with the OOo1.1 similiar to gcc4/gcc reasonably soon. A sort of relevent pretty picture progress dashboard http://people.redhat.com/caolanm/progress/progress.png C. From j.w.r.degoede at hhs.nl Sat Jan 22 10:26:59 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 22 Jan 2005 11:26:59 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> Message-ID: <41F22A73.6080402@hhs.nl> Paul Ionescu wrote: > Hi, > > I am using right now PAN to send this message. > Not because I don't want to use something else, but because other news > programs don't have the functionality of pan yet. > And is fast too, compared with other options. > > Thx, > Paul > I would like to give a vote for keeping pan in core too, and while we're at it make it the default news program. pan is the best gui newsreader for unix, so it deserves to be the default and its gnome, so it fits well with Fedora's default desktop. Regards, Hans From rc040203 at freenet.de Sat Jan 22 10:34:52 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 22 Jan 2005 11:34:52 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> Message-ID: <1106390092.7211.440.camel@mccallum.corsepiu.local> On Sat, 2005-01-22 at 14:24 +0530, Rahul Sundaram wrote: > Hi > > > > One could argue that Xorg and fvmw2 are all that's needed for Core. > > Minimalistic to the bone. > > no. fvwm2 is not a typical DE. X+fvwm2 had been the Linux standard desktop environment for many, many years and is still being used by more folks that you might assume. Some *nix-purists won't use want any other environment. > extras can be packaged as a ISO image. you need to download the whole > of fedora or buy it from a third party vendor. if fedora extras or a > subset of it is an ISO image, then moving KDE into extras is just > better reorganisation. Despite some folke here don't seem to get tired to reiterate this idea, I have to object: That won't be better, It's naive to move KDE out of Core. Ralf From rahulsundaram at gmail.com Sat Jan 22 10:39:24 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sat, 22 Jan 2005 16:09:24 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <1106390092.7211.440.camel@mccallum.corsepiu.local> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> Message-ID: Hi > > > > no. fvwm2 is not a typical DE. > X+fvwm2 had been the Linux standard desktop environment for many, many > years and is still being used by more folks that you might assume. its not the default DE nor part of fedora at all now. > Despite some folke here don't seem to get tired to reiterate this idea, > I have to object: That won't be better, It's naive to move KDE out of > Core. I dont see any technical objections here -- Regards, Rahul Sundaram From teg at pvv.org Sat Jan 22 11:14:24 2005 From: teg at pvv.org (=?UTF-8?B?VHJvbmQgRWl2aW5kIEdsb21zcsO4ZA==?=) Date: Sat, 22 Jan 2005 12:14:24 +0100 Subject: RFC: Optimizing for 386 In-Reply-To: <3k70mg$l3n28t@mxip15a.cluster1.charter.net> References: <3k70mg$l3n28t@mxip15a.cluster1.charter.net> Message-ID: <41F23590.5010901@pvv.org> Joseph D. Wagner wrote: >>If you think there will be a performance gain, then rebuild /one/ >>RPM with the optimizations you want and show how much faster it is. >> >> > >I actually did that once. I recompiled KDE from scratch. 36 hours. No noticeable difference. Then I recompiled the underlying Qt libraries from scratch. 5 hours. A few seconds here, a few seconds there. Then I recompiled XFree86 from scratch. 4 hours. Now we're starting to talk increased responsiveness. > > What aboyt trying just XFree (x.org), then? >The problem is EVERYTHING from the ground up has to be optimized to feel the cumulative effect. There is no way you are going to convince me that being optimized for a 386 is OK when I felt the effectiveness of optimizing the graphics programs. > > Optimization isn't being done for i386 now... it's being done for P4. Yes, you can do that and still have the binaries run on i386... the only issue then is missing instructions, most of which aren't automatically used anyway (MMX, SSE). CMOV could be useful, but I'm not sure of more... SSE/MMX are used already in X. >However, because I didn't do my tests in a "scientific" manor with precise measurements, the developers won't even consider my results. > > "Feeling" faster just doesn't work, especially when one has just done something one believes should have done a lot of difference. That said, there are graphic benchmarks available. > Who? Who is still using a 386? A 486? Do anyone on this list have > anything less than a 586? Who are these victims of my push for better > optimizations? I doubt anyone has less than a 586 (and some 686 chips are still considered 586 in some ways, as they lack the useful, but optional to the 686 instruction set, CMOV), but tuning for pentium is, AFAIR, harmful to code running on i686, compared to just optimizing for i386. From rms at 1407.org Sat Jan 22 12:26:04 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Sat, 22 Jan 2005 12:26:04 +0000 Subject: further package removals/potential package removals In-Reply-To: <1106369883.4002.40.camel@bree.local.net> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <1106369463.5183.24.camel@one.myworld> <1106369883.4002.40.camel@bree.local.net> Message-ID: <1106396764.3568.16.camel@roque> On Fri, 2005-01-21 at 23:58 -0500, Jeremy Katz wrote: > On Sat, 2005-01-22 at 05:51 +0100, F?liciano Matias wrote: > > Why do we keep xpdf in Fedora Core ? > > gpdf works fine. > > gpdf works with a much smaller subset of pdfs than gpdf. > > There's hope, though. evince[1] will save us all from our crappy widget > PDF viewing experience. I've been bought by evince. The speed of it displaying PDFs is astonishing all by it self. Also, it hasn't had any problem with none of the PDFs I've got here, and some I had to open with xpdf, other with gpdf (and a few with ggv). Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Sat Jan 22 13:34:02 2005 From: buildsys at redhat.com (Build System) Date: Sat, 22 Jan 2005 08:34:02 -0500 Subject: rawhide report: 20050122 changes Message-ID: <200501221334.j0MDY2m17384@porkchop.devel.redhat.com> New package ksh The Original ATT Korn Shell Removed package asp2php Updated Packages: Guppi-0.40.3-22 --------------- * Fri Jan 21 2005 Bill Nottingham 0.40.3-22 - fix some random oddness (#114374) PyQt-3.13-3 ----------- * Fri Jan 21 2005 Than Ngo 3.13-3 - Add missing sip dependency cups-1:1.1.23-5 --------------- * Fri Jan 21 2005 Tim Waugh 1.1.23-5 - Use tmpwatch to remove unused files in the spool temporary directory (bug #110026). * Thu Jan 20 2005 Tim Waugh - Use gzip's -n flag for the PPDs. gdb-6.3.0.0-0.10 ---------------- * Fri Jan 21 2005 Jeff Johnston 6.3.0.0-0.10 - Fix to prevent resetting unwind kernel table size to invalid value when debugging a core file - Bugzilla 145309 * Fri Jan 21 2005 Andrew Cagney 6.3.0.0-0.9 - When single stepping handle both back-to-back and nested signals. - Disable .symbol patch, results in BFD errors. * Fri Jan 21 2005 Jeff Johnston 6.3.0.0-0.8 - Support listing both in-charge and not-in-charge dtors when just the dtor name is given. - Add new test case for newly added ctor/dtor functionality. jpilot-0.99.7-5 --------------- * Fri Jan 21 2005 Ivana Varekova 0.99.7-5 - fix problem with previous patch (problem with cb_cal_changed connection) - fix problem with add_new_record (problem with cb_cal_changed connection) * Mon Jan 10 2005 Ivana Varekova 0.99.7-4 - fix part of bug #142520 - problem with Go to Today * Mon Nov 22 2004 Ivana Varekova 0.99.7-3 - fix bug #139377 - problem with x86_64 kernel-2.6.10-1.1107_FC4 ------------------------ * Fri Jan 21 2005 Dave Jones - Rebase to 2.6.11-rc2 * Fri Jan 21 2005 Rik van Riel - make exec-shield segment limits work inside the xen kernels lftp-3.0.13-1 ------------- * Fri Jan 21 2005 Jason Vas Dias 3.0.13-1 - Upgrade to upstream version 3.0.13 . lvm2-2.01.02-1.0 ---------------- * Fri Jan 21 2005 Alasdair Kergon - 2.01.02-1.0 - Minor fixes. mailcap-2.1.18-1 ---------------- * Fri Jan 21 2005 Bill Nottingham 2.1.18-1 - add iso, img to octet-stream (#142459 ) memtest86+-1.50-1 ----------------- * Fri Jan 21 2005 Warren Togami - 1.50-1 - 1.50 microcode_ctl-1:1.11-1.18 ------------------------- * Fri Jan 21 2005 Dave Jones - Create/remove the /dev/cpu/microcode dev node as needed. - Use correct path again for the microcode.dat. - Remove some no longer needed tests in the init script. mkinitrd-4.2.0.3-1 ------------------ * Fri Jan 21 2005 Peter Jones - 4.2.0.3-1 - Make nash expand environment variables on command lines (#144474) - Make nash check pids returned from wait*() (#145660) * Fri Jan 21 2005 Peter Jones - 4.2.0.2-1 - Make getArg return NULL on cmd=NULL, fixing #144472 . Based on a patch from Kasper Dupont. openoffice.org-1.1.3-2.7 ------------------------ * Fri Jan 21 2005 Dan Williams - 1.1.3-2 - Update to latest ooo-build. - NOTE: there may still be some i18n text-entry bugs when using IIIMF input modules. * Thu Jan 06 2005 Dan Williams - 1.1.3-1 - Update to OpenOffice.org 1.1.3, latest ooo-build * Sun Dec 12 2004 Dan Williams - 1.1.2-18 - #rh137854# Japanese document from Windows is heavily broken (Pass #2, much better fix this time around) - #rh129719# Upstream indic translations need to be incorporated into OOo packages (Work around translation bugs, most Gujarati UI strings should be native now) parted-1.6.21-1 --------------- * Fri Jan 21 2005 Chris Lumens 1.6.21-1 - Updated to 1.6.21 pciutils-2.1.99.test8-5 ----------------------- * Fri Jan 21 2005 Bill Nottingham - 2.1.99.test8-5 - fix domain bug (#138722, #144383) rp-pppoe-3.5-26 --------------- * Sat Jan 22 2005 Than Ngo 3.5-26 - rename config files #145255 rpmdb-fedora-1:4-0.20050122 --------------------------- selinux-policy-strict-1.21.2-7 ------------------------------ * Thu Jan 20 2005 Dan Walsh 1.21.2-7 - Allow restorecon and setfiles to read default_context_t * Thu Jan 20 2005 Dan Walsh 1.21.2-6 - Remove crond alias to unconfined_t in targeted selinux-policy-targeted-1.21.2-6 -------------------------------- * Thu Jan 20 2005 Dan Walsh 1.21.2-6 - Remove crond alias to unconfined_t in targeted telnet-1:0.17-33 ---------------- * Fri Jan 21 2005 Harald Hoyer - 1:0.17-33 - added patch telnetd-0.17-pty_read.patch, which fixes 145636 usbutils-0.11-6.2 ----------------- * Thu Jan 20 2005 David Woodhouse 0.11-6.2 - Don't byteswap parts of device descriptor which kernel already swapped xloadimage-4.1-33 ----------------- * Fri Jan 21 2005 Bill Nottingham 4.1-33 - fix bad use of format strings (#70867, #78481 ) xorg-x11-6.8.1.902-4 -------------------- * Fri Jan 21 2005 Mike A. Harris 6.8.1.902-4 - Renamed the xorg-x11-6.8.0-AMD64-enable-i810-driver.patch patch to xorg-x11-6.8.0-AMD64-override-default-driverlist.patch and added the "vmware" driver to the default list of drivers to be build on AMD64. (#145588) * Thu Jan 20 2005 Mike A. Harris 6.8.1.902-3 - Added xorg-x11-6.8.1.902-xf86pcibus-PCIX-bar-64bit-fix.patch to attempt to fix bugs (#140601, 143910) * Mon Jan 17 2005 Mike A. Harris 6.8.1.902-2 - Added xorg-x11-6.8.1.902-ia64-hp-zx2-support-bug-119364.patch to add support for new Hewlett Packard IA64 ZX2 chipset. (#119364) From toshio at tiki-lounge.com Sat Jan 22 15:05:20 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Sat, 22 Jan 2005 07:05:20 -0800 Subject: further package removals/potential package removals In-Reply-To: <5256d0b050121170521aa145b@mail.gmail.com>; from pbrobinson@gmail.com on Sat, Jan 22, 2005 at 09:05:19AM +0800 References: <20050121235849.GA6469@nostromo.devel.redhat.com> <5256d0b050121170521aa145b@mail.gmail.com> Message-ID: <20050122070520.A14172@tiki-lounge.com> On Sat, Jan 22, 2005 at 09:05:19AM +0800, Peter Robinson wrote: > > Opinions? > > Yep, get rid of them. Can we also get rid / move to extras all the non > GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK > 1 cruft as well? > This would be wonderful but... someone has to throw some manpower at porting gnucash from Gnome1 in order for this to happen. (This is being worked on upstream but there is still much to be done.) Links for porting status are here: http://gnomesupport.org/wiki/index.php/GnuCashPortingStatus There are other financial applications out there but I haven't looked into whether any of these might be a suitable replacement or what the migration cost might be. -Toshio From pri.rhl3 at iadonisi.to Sat Jan 22 15:13:49 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Sat, 22 Jan 2005 10:13:49 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106367390.5183.14.camel@one.myworld> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> Message-ID: <1106406829.11656.7.camel@md.local.linuxlobbyist.org> On Sat, 2005-01-22 at 05:16 +0100, F?liciano Matias wrote: [snip] > Move to Fedora Extra : > dosfstools Er...why? Given the number of consumer devices these days that use VFAT, I can't think of a reason why this would belong in Core. Yes, I know they usually come pre-formatted, but I still think it's ill advised to move out of Core a set of tools for recovering or reformatting these media. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From pri.rhl3 at iadonisi.to Sat Jan 22 15:16:04 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Sat, 22 Jan 2005 10:16:04 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106369540.4002.34.camel@bree.local.net> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <1106369540.4002.34.camel@bree.local.net> Message-ID: <1106406964.11656.9.camel@md.local.linuxlobbyist.org> On Fri, 2005-01-21 at 23:52 -0500, Jeremy Katz wrote: > On Sat, 2005-01-22 at 05:16 +0100, F?liciano Matias wrote: > > dosfstools > > Certain architectures > (*cough*ia64*cough*) require a vfat partition for booting. Ugh! How pathetic. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From jwboyer at jdub.homelinux.org Sat Jan 22 15:37:57 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 22 Jan 2005 09:37:57 -0600 Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> Message-ID: <1106408277.15391.17.camel@jdub.homelinux.org> On Sat, 2005-01-22 at 16:09 +0530, Rahul Sundaram wrote: > Hi > > > > > > > no. fvwm2 is not a typical DE. > > X+fvwm2 had been the Linux standard desktop environment for many, many > > years and is still being used by more folks that you might assume. > > its not the default DE nor part of fedora at all now. No, it's not and I'm not advocating that it should be. It was just a "devils advocate" type of statement. > > Despite some folke here don't seem to get tired to reiterate this idea, > > I have to object: That won't be better, It's naive to move KDE out of > > Core. > > I dont see any technical objections here That's because it's not always a technical issue. It's about choice. Default does not mean "this has to be installed". It's just a default. If I don't like the default, I should be given the option of installing an alternative. And that is without needing to download another large ISO after the fact because one didn't realize that KDE wasn't included in Core anymore. I say KDE is that alternate because it has a very large user base, and has been included in the "core" ISOs of every Red Hat/Fedora product since at least RH 7.3. Now that's not to say that all the non-base KDE packages have to be included with Core. I could see having kdegames, kdepim, kdemultimedia, etc all in Extras. Same goes for the non-base GNOME packages as well. If there isn't a desktop environment choice in the Core ISOs, then people will either deal with it, or switch to a different distro. Personally, I'd rather see more people come to Fedora. On a positive note, I'm glad this discussion is taking place. Even if it's being completely ignored by the Red Hat folks, at least members of the Fedora community are speaking up. :) josh From troels at arvin.dk Sat Jan 22 15:39:46 2005 From: troels at arvin.dk (Troels Arvin) Date: Sat, 22 Jan 2005 16:39:46 +0100 Subject: further package removals/potential package removals References: <20050121235849.GA6469@nostromo.devel.redhat.com> Message-ID: On Fri, 21 Jan 2005 18:58:49 -0500, Bill Nottingham wrote: > Removed and orphaned: [...] > Suggested for removal: [...] Yes, I believe they can be removed. -- Greetings from Troels Arvin, Copenhagen, Denmark From nbargnesi at gmail.com Sat Jan 22 15:53:24 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Sat, 22 Jan 2005 10:53:24 -0500 Subject: Power off In-Reply-To: <41F1BD6C.3000801@tlarson.com> References: <41F1BD6C.3000801@tlarson.com> Message-ID: <3077b8a0050122075312f907a0@mail.gmail.com> On Fri, 21 Jan 2005 19:41:48 -0700, Tyler Larson wrote: > I ran into a problem (bug?) that I would like to help solve, but I'm at > a loss as to where to go next. My laptop (Dell C400) used to run Linux > just fine, dual boot with Windows. In the past few months, I've > installed XP SP2 on the Windows side, reinstalled Windows a few times > (it happens), and updated by BIOS image. I somehow managed to trash my > partition table attempting to put GRUB back as my bootloader, then had > to reinstall everything all over again (windows and Linux). I've since > downgraded the BIOS to the previous known-good version to try and fix > the thing. Windows works fine, but on the Linux side.... > > The computer powers itself off without warning--no matter what is, or > isn't, running. Certain things seem to trigger it, and it may be tied to > high CPU load. I can trigger the shutdown fairly reliably by running > aircrack on a packet capture file. To rule out any background services > as being the culprit, I booted with init=/bin/bash, ran aircrack, and > sure enough, it powered off after about 90 seconds. This behavior has > continued no matter what kernel I use--I'ved tried with both the > original FC3 kernel and the most recent one. In fact, the machine > powered itself down a number of times while I was running off the > install CD. It took 10 tries before I got it to complete the install > process. > > So, my question to you all is--how can I possibly get some useful > information to start diagnosing this problem? There's nothing in the > logs on disk, of course. There's no warning, no panic, no nothing. Just > a quick *plink* and it's gone. > If I were you I'd send this to the users list - it seems better served there. I would try booting without acpi or apm, try to make things as stripped-down as possible (noacpi noapm). And you might want to check your BIOS settings to make sure the flashing didn't change settings, maybe some power-related stuff. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From mlauterbach at mail.wtamu.edu Sat Jan 22 16:04:53 2005 From: mlauterbach at mail.wtamu.edu (Matthew Lauterbach) Date: Sat, 22 Jan 2005 10:04:53 -0600 Subject: RAM detection error: 32-bit int issue? In-Reply-To: <1106330605.15199.17.camel@localhost.localdomain> References: <1106322885.2726.67.camel@localhost.localdomain> <1106330605.15199.17.camel@localhost.localdomain> Message-ID: <5A05DCE4-6C8F-11D9-8156-000A95DD2484@mail.wtamu.edu> On Jan 21, 2005, at 12:03, Scott Saccone wrote: > > Thanks very much, could you tell me what versions of GRUB and linux > you're using? BTW, the BIOS reports 4GB of memory, and Memtest86+ shows > 4GB working fine, so it must have something to do with the interaction > between the kernel and BIOS. Doesn't everything depend on the > BIOS-provided physical RAM map that's in the dmesg file, or is it more > than that? > > This is quote from a GRUB bug report that was posted after v.95 > came out (I'm using v.94, the only version after .95 is GRUB2 which is > in development) > http://savannah.gnu.org/bugs/?func=detailitem&item_id=9954 > > 'In char_io.c the memcheck function uses "int addr" to store addresses > and does bounds checking on it. On systems with over 2G of ram the "int > addr" will be negative and the bounds checking will fail producing an > "ERR_WONT_FIT".' > > On Fri, 2005-01-21 at 11:09, Jason L Tibbitts III wrote: >>>>>>> "SS" == Scott Saccone writes: >> >> SS> FC2/x86_64 (2.6.5-1.358smp) ran fine with 2GB RAM, but after >> SS> installing another 2GB it only detects 3GB. GRUB 0.94 also only >> SS> detects 3GB. >> >> No problems with 8GB on x86_64 here (using two 2 Opterons 250s on a >> Tyan S2882). Grub can certainly handle that much memory. (It even >> handles 6GB on 32-bit Xeon system.) >> >> I'd guess there's an issue with your BIOS, or the Kernel's interaction >> with it. >> >> - J< >> Upgrade you kernel. Updates has 2.6.10 From arjanv at redhat.com Sat Jan 22 16:08:25 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sat, 22 Jan 2005 17:08:25 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106408277.15391.17.camel@jdub.homelinux.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> Message-ID: <1106410105.4153.117.camel@laptopd505.fenrus.org> On Sat, 2005-01-22 at 09:37 -0600, Josh Boyer wrote: > That's because it's not always a technical issue. It's about choice. > Default does not mean "this has to be installed". It's just a default. > If I don't like the default, I should be given the option of installing > an alternative. And that is without needing to download another large > ISO after the fact because one didn't realize that KDE wasn't included > in Core anymore. ok just to be devils advocate again; how is having an iso labeled "Extras-KDE" different from having one additional iso in core that has the kde packages (I'm not sure if kde fills an entire CD but it'll go quite some way towards that anyway). In the first case you offer the user the choice to download it or *not* download it if the user isn't going to use KDE, in the case of KDE-in-core you force downloading that same ISO on all users, regardless of whether they will install KDE or not. Your argument seems to be "but then I have to download an extra iso".... well you download that iso anyway, and not just you but everyone else too. (Note: I guess OpenOffice might deserve the own-iso treatment as well :) Note to conspiracy theorists: this is NOT a RH official opinion. It's not even MY opinion per se; it's just food for thought on the "but then we make people download one more iso" argument which I considered flawed. There may or may not be other arguments, the discussion is interesting, but this one I consider mostly a bad argument. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thuforuk at yahoo.co.uk Sat Jan 22 16:16:16 2005 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Sat, 22 Jan 2005 16:16:16 +0000 Subject: rawhide report: 20050121 changes In-Reply-To: <1106410105.4153.117.camel@laptopd505.fenrus.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410105.4153.117.camel@laptopd505.fenrus.org> Message-ID: <41F27C50.10401@yahoo.co.uk> On 01/22/2005 04:08 PM, Arjan van de Ven wrote: > On Sat, 2005-01-22 at 09:37 -0600, Josh Boyer wrote: > > Your argument seems to be "but then I have to download an extra iso".... > well you download that iso anyway, and not just you but everyone else > too. > > > > (Note: I guess OpenOffice might deserve the own-iso treatment as well :) And so might Gnome :-) Note: I'm Gnome user but I like to have KDE installed on my boxes as well... Regards, Dariusz From jwboyer at jdub.homelinux.org Sat Jan 22 16:23:12 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 22 Jan 2005 10:23:12 -0600 Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> Message-ID: <1106410993.15391.42.camel@jdub.homelinux.org> On Sat, 2005-01-22 at 21:28 +0530, Rahul Sundaram wrote: > Hi > Putting this back on the list because you make some good points and this is a good discussion. > > > > That's because it's not always a technical issue. It's about choice. > > Default does not mean "this has to be installed". It's just a default. > > If I don't like the default, I should be given the option of installing > > an alternative. And that is without needing to download another large > > ISO after the fact because one didn't realize that KDE wasn't included > > in Core anymore. > > > > I dont think you read my previous mails completely. Let me explain > this once more > > today fedora core is 4+1 cds. if you limit fedora core to the > defaults and have it in 1 or 2 cds, you can have fedora extras or a > subset of it on the rest of the cds. so the totally number of CD's you > have to download as a KDE user still remains the same. Morever by With you so far, but I have an issue I'll discuss below. > limiting fedora core to the default others who are satisfied with the > defaults and dont want to make choice initially either due to > ignorance or due to lack of knowledge would be happy to stick with > what they get. the rest download what they want and install what they > want from fedora extras and elsewhere > > You still have the choice. the choices only increase with the > formation of fedora extras. If the Core install CDs give you an option to install from the Extras CDs at _install_ time, and you have the choice to not accept the default, then I could be OK with that. However, my main concern with moving KDE to Extras is not ISO organization. It's more of a maintainership issue. This whole thread started because some packages were removed from Core, and then the community found out that quite a few of those packages were orphaned. KDE is a large package to maintain both because of it's code size and it's large user base. Someone from the community maybe well be able to do the job, but right now KDE is released and maintained as a part of Core. It has a maintainer, it's part of the daily, weekly, whatever builds and it probably gets at least some QA testing. I realize that Fedora is officially an unsupported distribution, but the fact remains that the kind folks at Red Hat still work on this quite a bit. If it's moved to Extras and needs a new maintainer (which may not be the case), how quickly will it be picked up? Who knows? > > fedora core however has a defined goal. its called "core" for a reason > and all I am asking for is for the fedora project to implement that > goal for FC4. Fedora installer should make it easy for anyone to > install updates or add repositories and manage to have atleast the > same software before the formation of fedora extras > Could you kindly point me to where the "defined goal of including only defaults" is stated? I can't seem to find it anywhere. In fact, I find statements all over the Fedora webpage that are contrary to that: From: http://fedora.redhat.com/about/ "The goal of The Fedora Project is to work with the Linux community to build a complete, general purpose operating system exclusively from open source software." and "Fedora Core is intended to be a logical upgrade path for previous users of Red Hat Linux whose needs are consistent with the objectives of the Fedora Project." From: http://fedora.redhat.com/about/objectives.html "Include a range of popular packages, beyond those included in Red Hat's commercially supported products. (Limited, of course, to packages that Red Hat can legally provide; also limited to quality packages as defined by our standards.)" I see nothing about Core only containing defaults. Maybe I'm missing it somewhere. Do you have a link to it? I'm not saying it's not a decent goal to have, but that I just can't find it anywhere. If all you want is to reorganize the ISOs so that all the default options can be on 1 or 2 CDs, that's fine with me. As long as the installer has the option of installing from the "non-default" CDs as well. josh From feliciano.matias at free.fr Sat Jan 22 16:30:08 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sat, 22 Jan 2005 17:30:08 +0100 Subject: further package removals/potential package removals In-Reply-To: <20050121235849.GA6469@nostromo.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> Message-ID: <1106411409.8091.5.camel@one.myworld> Le vendredi 21 janvier 2005 ? 18:58 -0500, Bill Nottingham a ?crit : > Removed and orphaned: > asp2php - does not show any history of usage, not really a core package > > Suggested for removal: > (...) > Opinions? Remove rpmdb. move experimental gcc (gcc4 in FC3 for example) to Fedora Extra. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From katzj at redhat.com Sat Jan 22 16:30:58 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 22 Jan 2005 11:30:58 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <1106408277.15391.17.camel@jdub.homelinux.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> Message-ID: <1106411458.4002.49.camel@bree.local.net> On Sat, 2005-01-22 at 09:37 -0600, Josh Boyer wrote: > On a positive note, I'm glad this discussion is taking place. Even if > it's being completely ignored by the Red Hat folks, at least members > of > the Fedora community are speaking up. :) I can pretty safely say it's not being ignored. I'm just trying to avoid stifling the discussion. Others are probably in a similar boat. Jeremy From jwboyer at jdub.homelinux.org Sat Jan 22 16:34:28 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 22 Jan 2005 10:34:28 -0600 Subject: rawhide report: 20050121 changes In-Reply-To: <1106410105.4153.117.camel@laptopd505.fenrus.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410105.4153.117.camel@laptopd505.fenrus.org> Message-ID: <1106411668.15391.52.camel@jdub.homelinux.org> On Sat, 2005-01-22 at 17:08 +0100, Arjan van de Ven wrote: > > ok just to be devils advocate again; how is having an iso labeled > "Extras-KDE" different from having one additional iso in core that has > the kde packages (I'm not sure if kde fills an entire CD but it'll go > quite some way towards that anyway). In the first case you offer the > user the choice to download it or *not* download it if the user isn't > going to use KDE, in the case of KDE-in-core you force downloading that > same ISO on all users, regardless of whether they will install KDE or > not. > Your argument seems to be "but then I have to download an extra iso".... > well you download that iso anyway, and not just you but everyone else > too. > You're right, the ISO argument is flawed and Rahul pointed this out too. And that's not really the argument I was trying to make, but I can see how it comes across like that. For the record, I have no problem with KDE being on a separate ISO, as long as the installer gives one the choice of installing from said ISO at install time. In fact, I think a reorg of the ISOs could be a great thing. As I said in the email I just posted, my concern is more of a maintainership issue of actually officially declaring it an Extras package. Maybe it's a non-issue, but I still have that concern. josh From jwboyer at jdub.homelinux.org Sat Jan 22 16:35:01 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 22 Jan 2005 10:35:01 -0600 Subject: rawhide report: 20050121 changes In-Reply-To: <1106411458.4002.49.camel@bree.local.net> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106411458.4002.49.camel@bree.local.net> Message-ID: <1106411702.15391.54.camel@jdub.homelinux.org> On Sat, 2005-01-22 at 11:30 -0500, Jeremy Katz wrote: > On Sat, 2005-01-22 at 09:37 -0600, Josh Boyer wrote: > > On a positive note, I'm glad this discussion is taking place. Even if > > it's being completely ignored by the Red Hat folks, at least members > > of > > the Fedora community are speaking up. :) > > I can pretty safely say it's not being ignored. I'm just trying to > avoid stifling the discussion. Others are probably in a similar boat. Good to know. Thanks :) josh From jon at jonshouse.co.uk Sat Jan 22 16:35:28 2005 From: jon at jonshouse.co.uk (Jonathan Andrews) Date: Sat, 22 Jan 2005 16:35:28 +0000 Subject: further package removals/potential package removals In-Reply-To: <1106406829.11656.7.camel@md.local.linuxlobbyist.org> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <1106406829.11656.7.camel@md.local.linuxlobbyist.org> Message-ID: <1106411727.8428.2.camel@jonspc> On Sat, 2005-01-22 at 15:13, Paul Iadonisi wrote: > On Sat, 2005-01-22 at 05:16 +0100, F?liciano Matias wrote: > > [snip] > > > Move to Fedora Extra : > > dosfstools > > Er...why? Given the number of consumer devices these days that use > VFAT, I can't think of a reason why this would belong in Core. I second that why ? Every USB stick, camera or floppy disk owner will be cursing you. Jon From ellson at research.att.com Sat Jan 22 16:45:36 2005 From: ellson at research.att.com (John Ellson) Date: Sat, 22 Jan 2005 11:45:36 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106411409.8091.5.camel@one.myworld> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106411409.8091.5.camel@one.myworld> Message-ID: <41F28330.7000809@research.att.com> F?liciano Matias wrote: > > >Remove rpmdb. >move experimental gcc (gcc4 in FC3 for example) to Fedora Extra. > > You're kidding, right? Where is your smiley? I haven't used anything but gcc4 for the last six months. It catches more bugs that gcc3. It would make more sense, IMO, to make gcc4 the primary compiler and to deprecate gcc3. Or just leave both around. Its not a disk hog like some other packages. John From rahulsundaram at gmail.com Sat Jan 22 16:47:24 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sat, 22 Jan 2005 22:17:24 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <1106410993.15391.42.camel@jdub.homelinux.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410993.15391.42.camel@jdub.homelinux.org> Message-ID: On Sat, 22 Jan 2005 10:23:12 -0600, Josh Boyer wrote: > On Sat, 2005-01-22 at 21:28 +0530, Rahul Sundaram wrote: > > Hi > > > > Putting this back on the list because you make some good points and this > is a good discussion. Ok thanks > If the Core install CDs give you an option to install from the Extras > CDs at _install_ time, and you have the choice to not accept the > default, then I could be OK with that. I would very much want this to be supported in the installer. adding repositories and selecting packages from the extras and alternatives repo including the ability to install them from kickstart would satisfy everyone I believe. If anyone still has any other problems with fedora core only /only/ the defaults I would like to hear about it > > However, my main concern with moving KDE to Extras is not ISO > organization. It's more of a maintainership issue. valid concern. I already answered this one too to a limited extend . here is a more detailed answer. You might be well aware that kde-redhat.sf.net project has existed for quite sometime and is maintained in a active manner. when fedora extras policy for including packages, redhat or the other members in the community can ask these people and other upstream KDE developers to engage themselves with Redhat. one of the previous concerns with them was that Redhat was making modifications to KDE that was crippling the user experience for KDE ( I am not making that accusation. it just already exists). By moving these into extras and actively inviting the community, it is likely that upstream KDE developers and others would see this as an oppurtunity to build packages and provide a better experience for KDE users on fedora. one of the other benefits of having KDE and other such non default packages outside fedora core is that the amount of software a typical end users installs on his/her system is reduced. ideally someone would step up to make anaconda installer have a minimal setup too. in essence this improves security and increases maintainability. Fedora has a stated policy of staying close with upstream. so package updates dont just include security and bug fixes but also introduces new features. a typical fedora user usually gigabytes of updates because there is no easy way to stay conservative and ignore packages containing new features. I also suggest this capability be introduced in pup and its command line variants too in FC4. > Could you kindly point me to where the "defined goal of including only > defaults" is stated? I can't seem to find it anywhere. To be honest I did look for this in the website too but couldnt find it. It seems to be more of a implicit policy from reading through the previous discussions in this list. feel free to correct me otherwise -- Regards, Rahul Sundaram From rahulsundaram at gmail.com Sat Jan 22 16:48:32 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sat, 22 Jan 2005 22:18:32 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <1106411458.4002.49.camel@bree.local.net> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106411458.4002.49.camel@bree.local.net> Message-ID: Hi > I can pretty safely say it's not being ignored. I'm just trying to > avoid stifling the discussion. Others are probably in a similar boat. Even if you cannot speak on the behalf of Redhat, I would like to hear the opinions of the developers working on the fedora project. -- Regards, Rahul Sundaram From alan at redhat.com Sat Jan 22 16:50:44 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 22 Jan 2005 11:50:44 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106411727.8428.2.camel@jonspc> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <1106406829.11656.7.camel@md.local.linuxlobbyist.org> <1106411727.8428.2.camel@jonspc> Message-ID: <20050122165044.GE2898@devserv.devel.redhat.com> On Sat, Jan 22, 2005 at 04:35:28PM +0000, Jonathan Andrews wrote: > > Er...why? Given the number of consumer devices these days that use > > VFAT, I can't think of a reason why this would belong in Core. > > I second that why ? Every USB stick, camera or floppy disk owner will > be cursing you. I'd second that. Its needed for so many things. From rahulsundaram at gmail.com Sat Jan 22 16:50:49 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sat, 22 Jan 2005 22:20:49 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <1106410105.4153.117.camel@laptopd505.fenrus.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410105.4153.117.camel@laptopd505.fenrus.org> Message-ID: Hi > Your argument seems to be "but then I have to download an extra iso".... > well you download that iso anyway, and not just you but everyone else > too. exactly. > > Note to conspiracy theorists: this is NOT a RH official opinion. It's > not even MY opinion per se; it's just food for thought on the "but then > we make people download one more iso" argument which I considered > flawed. There may or may not be other arguments, the discussion is > interesting, but this one I consider mostly a bad argument. > its just sad that developers have to include disclaimers just to add some random thoughts to this discussion but its good that you clarify things I guess -- Regards, Rahul Sundaram From katzj at redhat.com Sat Jan 22 16:53:06 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 22 Jan 2005 11:53:06 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106411409.8091.5.camel@one.myworld> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106411409.8091.5.camel@one.myworld> Message-ID: <1106412786.4002.58.camel@bree.local.net> On Sat, 2005-01-22 at 17:30 +0100, F?liciano Matias wrote: > Remove rpmdb. One of the gating factors on this is writing something to use the rpm metadata to provide the same information. It shouldn't be hard, just will take some time. > move experimental gcc (gcc4 in FC3 for example) to Fedora Extra. Unfortunately, a lot of the java stuff right now is depending on gcc4 just because that's where the work is happening. Thus, tough call. On the note of the free java stuff... gcj is really coming along impressively in the things it can run now. Jeremy From alan at redhat.com Sat Jan 22 16:56:25 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 22 Jan 2005 11:56:25 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106345821.31381.77.camel@support02.civic.twp.ypsilanti.mi.us> <1106346575.8056.24.camel@jdub.homelinux.org> Message-ID: <20050122165625.GF2898@devserv.devel.redhat.com> On Sat, Jan 22, 2005 at 02:21:34PM +0530, Rahul Sundaram wrote: > so, lets have xfce, fluxbox and the rest of the gang inside core?. why > call it fedora core anymore then. thats going the way of debian I'm nowdays using XFCE a lot but I do believe its a logical candidate for extras. I'm not so sure personally about KDE being an extras item. If someone said "you have two CD-ROM images no more" then I'd consider KDE for extras but not with four. The politics is unfortunate because its not neccessarily about which is best (current hypothesis: they serve different user needs so there is no more a 'best' than arguing about two very different cars - it depends what you use it for and how you use it). Its about building an integrated consistent environment. Alan From rahulsundaram at gmail.com Sat Jan 22 16:56:46 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sat, 22 Jan 2005 22:26:46 +0530 Subject: further package removals/potential package removals In-Reply-To: <1106412786.4002.58.camel@bree.local.net> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106411409.8091.5.camel@one.myworld> <1106412786.4002.58.camel@bree.local.net> Message-ID: Hi . gcj is really coming along > impressively in the things it can run now. yes. I am impressed on the recent developments on gcj,. that reminds me is jonas going to be included in fc4? -- Regards, Rahul Sundaram From alan at redhat.com Sat Jan 22 16:58:10 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 22 Jan 2005 11:58:10 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <20050122045311.GA14114@nostromo.devel.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> <20050122043310.GA1067121@hiwaay.net> <20050122045311.GA14114@nostromo.devel.redhat.com> Message-ID: <20050122165810.GG2898@devserv.devel.redhat.com> On Fri, Jan 21, 2005 at 11:53:11PM -0500, Bill Nottingham wrote: > > supposed to use instead of pan? Last time I tried to load a large > > binaries group (alt.binaries.emulators.mame) in Thunderbird it locked up > > solid. Also, does Thunderbird handle yEnc (Mozilla didn't last time I > > tried)? > > It's entirely possible I mistyped. But I believe Thunderbird and > Evolution both read news. In the same was as "ed" means we don't need to ship an editor IMHO. Alan From alan at redhat.com Sat Jan 22 16:59:16 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 22 Jan 2005 11:59:16 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106369463.5183.24.camel@one.myworld> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <1106369463.5183.24.camel@one.myworld> Message-ID: <20050122165916.GH2898@devserv.devel.redhat.com> On Sat, Jan 22, 2005 at 05:51:03AM +0100, F?liciano Matias wrote: > I love ddd :-) > I request to move lesstif and openmotif21 to Fedora Extra. But keep > openmotif (use by ddd). You love ddd but is it a critical base package ? The idea that "extras" == "inferior" has to go away to make it work well. From elanthis at awesomeplay.com Sat Jan 22 16:59:27 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 22 Jan 2005 11:59:27 -0500 Subject: further package removals/potential package removals In-Reply-To: <41F28330.7000809@research.att.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106411409.8091.5.camel@one.myworld> <41F28330.7000809@research.att.com> Message-ID: <1106413167.31857.14.camel@stargrazer.home.awesomeplay.com> On Sat, 2005-01-22 at 11:45 -0500, John Ellson wrote: > F?liciano Matias wrote: > > > > > > >Remove rpmdb. > >move experimental gcc (gcc4 in FC3 for example) to Fedora Extra. > > > > > > You're kidding, right? Where is your smiley? > > I haven't used anything but gcc4 for the last six months. It catches > more bugs that gcc3. So? That has nothing to do with whether a package is applicable to being in Core or not. You *can* use gcc4 if it's in Extras, you know. ;-) > > It would make more sense, IMO, to make gcc4 the primary compiler and to > deprecate gcc3. Right... except that gcc 4.0 is not yet released and is a beta/experimental compiler. The last time Red Hat made an experimental compiler the default they caused a metric ton of hell for everyone... > Or just leave both around. Its not a disk hog like some other packages. I don't think being a "disk hog" is the criteria here, either. It's simple - either it's a core package required for the basic functionality Fedora intends to deliver (i.e., basic server, basic development box, usable desktop, whatever) or it's something that is an _extra_. gcc4 is by its definition an extra, since its not the default and not even _installed_ by default, and it is in no way required for any use case that Fedora has that isn't solved by another package already in Core (gcc3), so it should thus be in Extras. That's what Extras is for - extras. Even if cutting out gcc4 only saves a few megabytes, cutting out all the packages in the same boat as gcc4 might just cut Fedora Core down to two CDs, and maybe someday down to one. And it's not like you can't just get some Extras ISOs. Fedora really does need the ability to install off Extras CDs during install time, though. It should be seemless - other than telling the installer which CDs you have, the package selection process should completely hide which ISO which package is on. > > John > From alan at redhat.com Sat Jan 22 17:01:30 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 22 Jan 2005 12:01:30 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106367390.5183.14.camel@one.myworld> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> Message-ID: <20050122170130.GI2898@devserv.devel.redhat.com> On Sat, Jan 22, 2005 at 05:16:30AM +0100, F?liciano Matias wrote: > Move to Fedora Extra : > dosfstools > Lynx (or elinks) lynx is needed for mutt to do html reading on text logins. Its also fairly important for accessibility for some users. Elinks I wouldn't worry about > lesstif and/or openmotif21 If nothing essential still uses them definitely. Possibly joe also ought to go to extras nowdays. It used to make sense to ship it in base because although it had a low userbase it was the best editor on the planet and also easy for new users. We have nano ans we have new users in X with gedit nowdays. Alan From rahulsundaram at gmail.com Sat Jan 22 17:04:07 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sat, 22 Jan 2005 22:34:07 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <20050122165625.GF2898@devserv.devel.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106345821.31381.77.camel@support02.civic.twp.ypsilanti.mi.us> <1106346575.8056.24.camel@jdub.homelinux.org> <20050122165625.GF2898@devserv.devel.redhat.com> Message-ID: Hi > I'm nowdays using XFCE a lot but I do believe its a logical candidate for > extras. to clarify my stand on this I use KDE and even fluxbox on occasions depending on my requirements. so I am not asking for KDE to moved to fedora extras just because I happen to use Gnome or something else I'm not so sure personally about KDE being an extras item. If someone > said "you have two CD-ROM images no more" then I'd consider KDE for extras > but not with four. I was actually hoping that Fedora core 4 would limit itself to just one CD or at the maximum two. If Fedora project on the whole can manage to produce more ISO images, having a subset of fedora extras which includes the more popular packages especially those being moved into fedora extras ( Making a case for KDE , xfce etc) would be very useful -- Regards, Rahul Sundaram From cra at WPI.EDU Sat Jan 22 17:04:34 2005 From: cra at WPI.EDU (Charles R. Anderson) Date: Sat, 22 Jan 2005 12:04:34 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <20050122165625.GF2898@devserv.devel.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106345821.31381.77.camel@support02.civic.twp.ypsilanti.mi.us> <1106346575.8056.24.camel@jdub.homelinux.org> <20050122165625.GF2898@devserv.devel.redhat.com> Message-ID: <20050122170434.GU28566@angus.ind.WPI.EDU> On Sat, Jan 22, 2005 at 11:56:25AM -0500, Alan Cox wrote: > I'm nowdays using XFCE a lot but I do believe its a logical candidate for > extras. I'm not so sure personally about KDE being an extras item. If someone > said "you have two CD-ROM images no more" then I'd consider KDE for extras > but not with four. > > The politics is unfortunate because its not neccessarily about which is best > (current hypothesis: they serve different user needs so there is no more a > 'best' than arguing about two very different cars - it depends what you use > it for and how you use it). Its about building an integrated consistent > environment. When people speak of moving KDE to extras, which parts of it do they mean? The whole DE, applets, applications, libraries? QT? There are many KDE/QT applications which serve a particular function better than any GNOME/GTK counterpart, such as k3b. It would be a shame to lose some of the better applications simply because they are bundled with KDE or use KDE infrastructure... From alan at redhat.com Sat Jan 22 17:08:03 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 22 Jan 2005 12:08:03 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <20050121234943.GA6392@nostromo.devel.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> Message-ID: <20050122170803.GK2898@devserv.devel.redhat.com> On Fri, Jan 21, 2005 at 06:49:43PM -0500, Bill Nottingham wrote: > - balsa/libesmtp (really, they go together) > - sylpheed One of these - IMHO sylpheed or slypheed+claws should stay IFF we keep XFCE in the base distro. The other gui mailers are unusable on low end machines. If XFCE also goes to extras (sensible perhaps) then fine. > - freeciv > - gnuchess > - xboard I'd like to see some newer / better games picked up. Another question for FC4 maybe "bzflag or bzflag2" Alan From feliciano.matias at free.fr Sat Jan 22 17:09:00 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sat, 22 Jan 2005 18:09:00 +0100 Subject: further package removals/potential package removals In-Reply-To: <41F28330.7000809@research.att.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106411409.8091.5.camel@one.myworld> <41F28330.7000809@research.att.com> Message-ID: <1106413740.8091.17.camel@one.myworld> Le samedi 22 janvier 2005 ? 11:45 -0500, John Ellson a ?crit : > F?liciano Matias wrote: > > > > > > >Remove rpmdb. > >move experimental gcc (gcc4 in FC3 for example) to Fedora Extra. > > > > > > You're kidding, right? Where is your smiley? > > I haven't used anything but gcc4 for the last six months. It catches > more bugs that gcc3. I don't say gcc4 is a bad compiler. I said that experimental stuff dedicated to developer should be in Fedora Extra. There are more users than developers. Jeremy Katz pointed out that gcc4 is already needed by some java stuff in FC3. So gcc4 is not only an experimental compiler (a "toy" for for some developers ; thanks for improving GNU/Linux) and its right place is Fedora Core (for FC3). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From feliciano.matias at free.fr Sat Jan 22 17:21:00 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sat, 22 Jan 2005 18:21:00 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106412786.4002.58.camel@bree.local.net> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106411409.8091.5.camel@one.myworld> <1106412786.4002.58.camel@bree.local.net> Message-ID: <1106414460.8091.28.camel@one.myworld> Le samedi 22 janvier 2005 ? 11:53 -0500, Jeremy Katz a ?crit : > On Sat, 2005-01-22 at 17:30 +0100, F?liciano Matias wrote: > > Remove rpmdb. > > One of the gating factors on this is writing something to use the rpm > metadata to provide the same information. It shouldn't be hard, just > will take some time. rpmdb only store Fedora Core packages. rpmdb is huge : 37 Mo. rpmdb help to provide a "poor resolver" to rpm. yum/apt/up2date do a better job. Since rpmdb is huge, perhaps rpmdb should not provide /usr/lib/rpmdb/i386-redhat-linux/redhat/ (97 Mo) but a tool to generate the rpmdb base (like rpmdb-fedora.spec does). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mike at navi.cx Sat Jan 22 17:25:49 2005 From: mike at navi.cx (Mike Hearn) Date: Sat, 22 Jan 2005 17:25:49 +0000 Subject: Any known bugs in gcc wrt symbols in gdb and/or var allocation ? References: <1106347274.9288.28.camel@localhost.localdomain> Message-ID: On Fri, 21 Jan 2005 15:41:14 -0700, Kim Lux wrote: > Problem #1: gdb cannot find replyEnd: > > (gdb) whatis replyEnd > No symbol "replyEnd" in current context. It might have been optimized out (might seem crazy but that code does look like replyEnd could be completely optimized away). Try rebuilding it with -O0 thanks -mike From jwboyer at jdub.homelinux.org Sat Jan 22 17:24:20 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 22 Jan 2005 11:24:20 -0600 Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410993.15391.42.camel@jdub.homelinux.org> Message-ID: <1106414660.15391.72.camel@jdub.homelinux.org> On Sat, 2005-01-22 at 22:17 +0530, Rahul Sundaram wrote: > On Sat, 22 Jan 2005 10:23:12 -0600, Josh Boyer > > If the Core install CDs give you an option to install from the Extras > > CDs at _install_ time, and you have the choice to not accept the > > default, then I could be OK with that. > > I would very much want this to be supported in the installer. adding > repositories and selecting packages from the extras and alternatives > repo including the ability to install them from kickstart would > satisfy everyone I believe. Agreed. Fedora Core and Fedora Extras (maybe even alternatives) could still be packaged together in a DVD ISO for those that want "one ISO to rule them all". So maybe given that, we could look at reorganizing the CD ISOs as you suggested. > > > > > However, my main concern with moving KDE to Extras is not ISO > > organization. It's more of a maintainership issue. > > valid concern. I already answered this one too to a limited extend . > here is a more detailed answer. > > You might be well aware that kde-redhat.sf.net project has existed for > quite sometime and is maintained in a active manner. when fedora > extras policy for including packages, redhat or the other members in > the community can ask these people and other upstream KDE developers > to engage themselves with Redhat. one of the previous concerns with > them was that Redhat was making modifications to KDE that was > crippling the user experience for KDE ( I am not making that > accusation. it just already exists). By moving these into extras and > actively inviting the community, it is likely that upstream KDE > developers and others would see this as an oppurtunity to build > packages and provide a better experience for KDE users on fedora. Hm.. I seemed to have missed where you mentioned the kde-redhat.sf.net project earlier. That does make me a bit less apprehensive. I'd still be concerned if KDE was declared as an Extras package, but I can see some reasoning behind it. Who knows, maybe KDE could be the "ultimate test" of whether Extras will really work. > > one of the other benefits of having KDE and other such non default > packages outside fedora core is that the amount of software a typical > end users installs on his/her system is reduced. ideally someone would > step up to make anaconda installer have a minimal setup too. in > essence this improves security and increases maintainability. Agreed. > > Fedora has a stated policy of staying close with upstream. so package > updates dont just include security and bug fixes but also introduces > new features. a typical fedora user usually gigabytes of updates > because there is no easy way to stay conservative and ignore packages > containing new features. I also suggest this capability be introduced > in pup and its command line variants too in FC4. I personally like the fact that Fedora stays close to upstream. It's almost necessary given the release cycle that it has. But maybe a community driven bug-fixes project could fill the gap. Or maybe that's not realistic. Just theorizing here. > > > > Could you kindly point me to where the "defined goal of including only > > defaults" is stated? I can't seem to find it anywhere. > > To be honest I did look for this in the website too but couldnt find > it. It seems to be more of a implicit policy from reading through the > previous discussions in this list. feel free to correct me otherwise No need to correct anyone. It's potentially a good goal. I just couldn't find it stated anywhere. Apologies if it came off a bit harsh. josh From fedora at wir-sind-cool.org Sat Jan 22 17:27:08 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 22 Jan 2005 18:27:08 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <20050122170803.GK2898@devserv.devel.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> <20050122170803.GK2898@devserv.devel.redhat.com> Message-ID: <20050122182708.10075a83.fedora@wir-sind-cool.org> On Sat, 22 Jan 2005 12:08:03 -0500, Alan Cox wrote: > On Fri, Jan 21, 2005 at 06:49:43PM -0500, Bill Nottingham wrote: > > - balsa/libesmtp (really, they go together) > > - sylpheed > > One of these - IMHO sylpheed or slypheed+claws should stay IFF we keep XFCE > in the base distro. The other gui mailers are unusable on low end machines. > If XFCE also goes to extras (sensible perhaps) then fine. Both Sylpheed and Sylpheed-claws are crippled if built without GPGME support. From jwboyer at jdub.homelinux.org Sat Jan 22 17:27:45 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 22 Jan 2005 11:27:45 -0600 Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106411458.4002.49.camel@bree.local.net> Message-ID: <1106414865.15391.76.camel@jdub.homelinux.org> On Sat, 2005-01-22 at 22:18 +0530, Rahul Sundaram wrote: > Hi > > > I can pretty safely say it's not being ignored. I'm just trying to > > avoid stifling the discussion. Others are probably in a similar boat. > > > Even if you cannot speak on the behalf of Redhat, I would like to hear > the opinions of the developers working on the fedora project. I agree. A community driven distro should include the ones that spend the most time on it for sure. :) josh From feliciano.matias at free.fr Sat Jan 22 17:31:34 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sat, 22 Jan 2005 18:31:34 +0100 Subject: further package removals/potential package removals In-Reply-To: <20050122165916.GH2898@devserv.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <1106369463.5183.24.camel@one.myworld> <20050122165916.GH2898@devserv.devel.redhat.com> Message-ID: <1106415094.8091.34.camel@one.myworld> Le samedi 22 janvier 2005 ? 11:59 -0500, Alan Cox a ?crit : > On Sat, Jan 22, 2005 at 05:51:03AM +0100, F?liciano Matias wrote: > > I love ddd :-) > > I request to move lesstif and openmotif21 to Fedora Extra. But keep > > openmotif (use by ddd). > > You love ddd but is it a critical base package ? No. > The idea that "extras" == > "inferior" has to go away to make it work well. > You are right. ddd in Fedora Extra is fine to me. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From feliciano.matias at free.fr Sat Jan 22 17:38:12 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sat, 22 Jan 2005 18:38:12 +0100 Subject: further package removals/potential package removals In-Reply-To: <20050122170130.GI2898@devserv.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> Message-ID: <1106415492.8091.41.camel@one.myworld> Le samedi 22 janvier 2005 ? 12:01 -0500, Alan Cox a ?crit : > On Sat, Jan 22, 2005 at 05:16:30AM +0100, F?liciano Matias wrote: > > lesstif and/or openmotif21 > > If nothing essential still uses them definitely. > With FC3 : [fmatias at one i386]$ rpm -e --test --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ lesstif erreur: D?pendances requises: libMrm.so.1 est n?cessaire pour (d?j? install?) lesstif-devel-0.93.36-6.i386 libXm.so.1 est n?cessaire pour (d?j? install?) lesstif-devel-0.93.36-6.i386 lesstif = 0.93.36 est n?cessaire pour (d?j? install?) lesstif-devel-0.93.36-6.i386 => lesstif is not used. [fmatias at one i386]$ rpm -e --test --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ openmotif21 (empty) => openmotif21 is not used. [fmatias at one i386]$ rpm -e --test --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/ openmotif erreur: D?pendances requises: libMrm.so.3 est n?cessaire pour (d?j? install?) openmotif-devel-2.2.3-6.i386 libUil.so.3 est n?cessaire pour (d?j? install?) openmotif-devel-2.2.3-6.i386 libXm.so.3 est n?cessaire pour (d?j? install?) ddd-3.3.9-1.i386 libXm.so.3 est n?cessaire pour (d?j? install?) iiimf-le-chinput-0.3-11.i386 libXm.so.3 est n?cessaire pour (d?j? install?) nedit-5.4-3.i386 libXm.so.3 est n?cessaire pour (d?j? install?) openmotif-devel-2.2.3-6.i386 libXm.so.3 est n?cessaire pour (d?j? install?) stardict-1.31-21.i386 libXm.so.3 est n?cessaire pour (d?j? install?) xpdf-3.00-10.i386 openmotif est n?cessaire pour (d?j? install?) ddd-3.3.9-1.i386 openmotif = 2.2.3-6 est n?cessaire pour (d?j? install?) openmotif-devel-2.2.3-6.i386 openmotif est n?cessaire pour (d?j? install?) stardict-1.31-21.i386 => openmotif is used by stardict, ddd, xpdf, nedit, iiimf-le-chinput -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tsilims at gmail.com Sat Jan 22 18:30:39 2005 From: tsilims at gmail.com (m g) Date: Sat, 22 Jan 2005 12:30:39 -0600 Subject: further package removals/potential package removals In-Reply-To: <20050122170130.GI2898@devserv.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> Message-ID: > lynx is needed for mutt to do html reading on text logins. Its also fairly > important for accessibility for some users. Elinks I wouldn't worry about > Also, both are key parts of my "ssh in and fix an HTML-interface-only router" toolbox. Depending on the HTML/authentication/router, one will work and one will not. In my experience in Freenode's #fedora, I'm not alone in this use. -- MG From selinux at gmail.com Sat Jan 22 19:03:39 2005 From: selinux at gmail.com (Tom London) Date: Sat, 22 Jan 2005 11:03:39 -0800 Subject: kernel-devel: should yum install, not update? Message-ID: <4c4ba15305012211032bde7867@mail.gmail.com> Running latest rawhide. Yum seems to update the kernel-devel package. Should it be added to the default 'installonly' packages? tom -- Tom London From jspaleta at gmail.com Sat Jan 22 19:22:32 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 22 Jan 2005 14:22:32 -0500 Subject: kernel-devel: should yum install, not update? In-Reply-To: <4c4ba15305012211032bde7867@mail.gmail.com> References: <4c4ba15305012211032bde7867@mail.gmail.com> Message-ID: <604aa7910501221122724f734c@mail.gmail.com> On Sat, 22 Jan 2005 11:03:39 -0800, Tom London wrote: > Running latest rawhide. > > Yum seems to update the kernel-devel package. > > Should it be added to the default 'installonly' packages? probably... looking at the kernel-devel file payload it seems to be parallel installable by design. I think its perfectly reasonable to set this to parallel install by default instead of upgrade. I would imagine for most people who need the kernel-devel package installed and have multiple kernels on their system they will want to be able to compile modules for each kernel they have on the system and not just the latest. Whatever is decided you probably want to have up2date default to the same behavior for consistency. -jef From seyman at wanadoo.fr Sat Jan 22 19:27:00 2005 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Sat, 22 Jan 2005 20:27:00 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <20050122170434.GU28566@angus.ind.WPI.EDU> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106345821.31381.77.camel@support02.civic.twp.ypsilanti.mi.us> <1106346575.8056.24.camel@jdub.homelinux.org> <20050122165625.GF2898@devserv.devel.redhat.com> <20050122170434.GU28566@angus.ind.WPI.EDU> Message-ID: <20050122192659.GB8274@orient.maison.moi> On Sat, Jan 22, 2005 at 12:04:34PM -0500, Charles R. Anderson wrote: > > any GNOME/GTK counterpart, such as k3b. It would be a shame to lose > some of the better applications simply because they are bundled with > KDE or use KDE infrastructure... I'ld hardly consider apps being moved to Extras as being lost. Emmanuel From peter.backlund at home.se Sat Jan 22 19:39:26 2005 From: peter.backlund at home.se (Peter Backlund) Date: Sat, 22 Jan 2005 20:39:26 +0100 Subject: further package removals/potential package removals In-Reply-To: <20050121235849.GA6469@nostromo.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> Message-ID: <1106422766.16789.55.camel@localhost.localdomain> This discussion is turning a bit absurd, imo. Just because a package is lifted out of Core doesn't mean it will vanish from the face of the earth. You can still install it from Extras if you need it. More productive would be to reach a clear definition of the scope and purpose of Core and Extras, respectively. Then the question of whether a package belongs in Core or Extras or neither should be fairly trivial. There seems to be a general consensus that Core should have no more than one or two pieces of software for any given task. The Desktop sub- project (Bluecurve) has a clear definition of how these applications are selected: http://fedora.redhat.com/projects/desktop/defaults.html. This checklist can quite easily be adopted for the entire Core. Other applications/toolkits/etc that are more of niche players, or less used, can and should live in Extras. Question that are currently unanswered about Extras include: - Who will maintain the Extras packages? RH, the community or both? - Will Extras be distributed in ISO form, and will it be possible to use the Extras CD during installation? - Will the packages in Extras be continually updated, like they were in fedora.us, or will they move more slowly, like the RH maintained packages in Core? And finally, the issue of ISO content distribution: can the ISOs be split up more intelligently, according to type of installation? For example: for a default headless server or minimal installation, use CD 1. For a default desktop or workstation installation, use CD 1 and 2. For a non-default graphical installations with no non-English localization, use CD 1, 2 and 3. For localized/internationalized installations, use all four CDs. /Peter Backlund From pri.rhl3 at iadonisi.to Sat Jan 22 19:35:50 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Sat, 22 Jan 2005 14:35:50 -0500 Subject: further package removals/potential package removals In-Reply-To: <20050122170130.GI2898@devserv.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> Message-ID: <1106422550.6599.3.camel@md.local.linuxlobbyist.org> On Sat, 2005-01-22 at 12:01 -0500, Alan Cox wrote: [snip] > Possibly joe also ought to go to extras nowdays. It used to make sense to ship > it in base because although it had a low userbase it was the best editor on > the planet and also easy for new users. We have nano ans we have new users > in X with gedit nowdays. I can deal with that. I forgot about nano. As long as there is one alternative (and *small*) text editor besides vi (vim). I like vim, but was astonished by how utterly dependent I am on it when it was broken a few days ago. Then I remembered joe ... saved the day for me. Nano can serve that role, too. -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From skvidal at phy.duke.edu Sat Jan 22 19:39:50 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 22 Jan 2005 14:39:50 -0500 Subject: kernel-devel: should yum install, not update? In-Reply-To: <604aa7910501221122724f734c@mail.gmail.com> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> Message-ID: <1106422790.3511.2.camel@cutter> On Sat, 2005-01-22 at 14:22 -0500, Jeff Spaleta wrote: > On Sat, 22 Jan 2005 11:03:39 -0800, Tom London wrote: > > Running latest rawhide. > > > > Yum seems to update the kernel-devel package. > > > > Should it be added to the default 'installonly' packages? > > probably... looking at the kernel-devel file payload it seems to be > parallel installable by design. I think its perfectly reasonable to > set this to parallel install by default instead of upgrade. I would > imagine for most people who need the kernel-devel package installed > and have multiple kernels on their system they will want to be able to > compile modules for each kernel they have on the system and not just > the latest. > > Whatever is decided you probably want to have up2date default to the > same behavior for consistency. > make kernel-devel provide 'kernel' or 'kernel-modules' and it will happen automatically. -sv From pri.rhl3 at iadonisi.to Sat Jan 22 19:46:26 2005 From: pri.rhl3 at iadonisi.to (Paul Iadonisi) Date: Sat, 22 Jan 2005 14:46:26 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106413167.31857.14.camel@stargrazer.home.awesomeplay.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106411409.8091.5.camel@one.myworld> <41F28330.7000809@research.att.com> <1106413167.31857.14.camel@stargrazer.home.awesomeplay.com> Message-ID: <1106423186.6599.12.camel@md.local.linuxlobbyist.org> On Sat, 2005-01-22 at 11:59 -0500, Sean Middleditch wrote: [snip] > Right... except that gcc 4.0 is not yet released and is a > beta/experimental compiler. The last time Red Hat made an experimental > compiler the default they caused a metric ton of hell for everyone... No doubt the result of the metric two tons of FUD that was circulating about that specific decision. The whole controversy (particularly the statement from the gcc team) was kind of ironic given that a good number of gcc developers were Red Hat employees due to their acquisition of Cygnus. > Even if cutting out gcc4 only saves a few megabytes, cutting out all the > packages in the same boat as gcc4 might just cut Fedora Core down to two > CDs, and maybe someday down to one. Awe, but I *like* doing a full install from DVD and seeing 7GB used when I'm done. ;-) > Fedora really does need the ability to install off Extras CDs during > install time, though. It should be seemless - other than telling the > installer which CDs you have, the package selection process should > completely hide which ISO which package is on. I second that. If that happens, I don't care what's in Core and what's in Extras, personally. Actually, I'll bet a good part of what's needed is already in firstboot. How about just moving it to anaconda? -- -Paul Iadonisi Senior System Administrator Red Hat Certified Engineer / Local Linux Lobbyist Ever see a penguin fly? -- Try Linux. GPL all the way: Sell services, don't lease secrets From jspaleta at gmail.com Sat Jan 22 20:11:32 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 22 Jan 2005 15:11:32 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106422766.16789.55.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> Message-ID: <604aa79105012212112b0b3bee@mail.gmail.com> On Sat, 22 Jan 2005 20:39:26 +0100, Peter Backlund wrote: > There seems to be a general consensus that Core should have no more than > one or two pieces of software for any given task. I'm not so sure there is a general concensous about that.... I see people lobbying for several different usage cases but I don't see a clear defined set of usage cases that Core is suppose to fulfill by itself. 'General Purpose' is too vague. I think Core needs to back up and define one or two specific usage cases and target those.. and move out applications and technologies that do not fit into the primary usage situations. Core right now is a compromise that suits pretty much everyone equally badly. And while thats an admirable feat, its doesn't give a clear guiding perspective for the future . If there is serious interest in slimming Core down.. then a decision has to be made to define a reference usage case or two so we can get past personal preference and make decisions based on the design needs of the usage case goal. If a reference usage case for Core is suppose to be a developer oriented workspace thats going to impact the decisions as to what is important to include. If a reference usage case for Core is suppose to be a desktop for the average human, that's going to impact the decisions in very different ways. If Core is suppose to provide both.. well guess what.. Core will continue to be 4+ CD images. You can't have a small footprint and have ultimate flexibility. Frankly I think the community has a whole is better served if Core defines its primary usage case to be average human being's desktop and push as much of the developer and highly technically oriented tools to Extras. I personally use emacs and tetex more than openoffice.org... but i would much rather have Emacs and tetex maintained in extras than move openoffice.org out. I think a primary usage case that places a premium on out-of-the-box ease for a developer or 'power user' is somewhat backwards. I certaintly don't NEED emacs and tetex to be installed by default. I simply NEED a way to get those tools installed from media. And the same goes with most of the non modern desktop tools i need to write code or technical documentation. And I would say 'most' of the fedora developers know enough to get by just fine if they had to use Extras to get developer oriented tools installed. But even 'average human being' isn't specific enough.. i think there needs to be some very clearly defined usage cases or personas that Core needs to target, personas or characters that can be used as a reference for decissions as to what applications to include paying very close attention. Not just typical day-to-day tasks as the persona.. I know some people inside Red Hat think in these terms and i think it needs to be applied to Core's definition as a stand-alone OS. -jef"My general rule of thumb is... if I use it on a daily basis.. its clearly not something an average person will want and therefore it should not be in Core"spaleta From elanthis at awesomeplay.com Sat Jan 22 20:12:53 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 22 Jan 2005 15:12:53 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106422550.6599.3.camel@md.local.linuxlobbyist.org> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106422550.6599.3.camel@md.local.linuxlobbyist.org> Message-ID: <1106424774.31857.17.camel@stargrazer.home.awesomeplay.com> On Sat, 2005-01-22 at 14:35 -0500, Paul Iadonisi wrote: > I can deal with that. I forgot about nano. As long as there is one > alternative (and *small*) text editor besides vi (vim). I like vim, but > was astonished by how utterly dependent I am on it when it was broken a > few days ago. Then I remembered joe ... saved the day for me. Nano can > serve that role, too. The proper fix for that break (libperl) to make sure that such an essential utility stays working in the future would be to check for libperl at runtime and dlopen() it. The Vim folks might take a patch (or bug report) for that. Then if libperl breaks (it can happen even outside of Rawhide when you make certain kinds of mistakes) the standard UNIX text editor will still work. From elanthis at awesomeplay.com Sat Jan 22 20:14:51 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 22 Jan 2005 15:14:51 -0500 Subject: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> Message-ID: <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> On Sat, 2005-01-22 at 12:30 -0600, m g wrote: > > lynx is needed for mutt to do html reading on text logins. Its also fairly > > important for accessibility for some users. Elinks I wouldn't worry about > > > > Also, both are key parts of my "ssh in and fix an HTML-interface-only > router" toolbox. Depending on the HTML/authentication/router, one > will work and one will not. In my experience in Freenode's #fedora, > I'm not alone in this use. These kinds of comments really need to stop - it doesn't matter how useful a utility is on your site, or even a number of users sites, because *you can still install it from Extras*! Removing a utility from Core is not going to in any way stop you from doing what you need. It'll just help make sure other users don't pay the price (bloated "core" distro) for you doing what you need. > -- > MG > From mitr at volny.cz Sat Jan 22 20:17:09 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Sat, 22 Jan 2005 21:17:09 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> Message-ID: <20050122201706.GA3494@chrys.ms.mff.cuni.cz> On Sat, Jan 22, 2005 at 03:14:51PM -0500, Sean Middleditch wrote: > On Sat, 2005-01-22 at 12:30 -0600, m g wrote: > > > lynx is needed for mutt to do html reading on text logins. Its also fairly > > > important for accessibility for some users. Elinks I wouldn't worry about > > Also, both are key parts of my "ssh in and fix an HTML-interface-only > > router" toolbox. Depending on the HTML/authentication/router, one > > will work and one will not. In my experience in Freenode's #fedora, > > I'm not alone in this use. > These kinds of comments really need to stop - it doesn't matter how > useful a utility is on your site, or even a number of users sites, > because *you can still install it from Extras*! That's not the case if we are talking about the rescue mode available on the first installation CD of Core. Mirek From elanthis at awesomeplay.com Sat Jan 22 20:17:12 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 22 Jan 2005 15:17:12 -0500 Subject: kernel-devel: should yum install, not update? In-Reply-To: <1106422790.3511.2.camel@cutter> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> Message-ID: <1106425033.31857.23.camel@stargrazer.home.awesomeplay.com> On Sat, 2005-01-22 at 14:39 -0500, seth vidal wrote: > On Sat, 2005-01-22 at 14:22 -0500, Jeff Spaleta wrote: > > Whatever is decided you probably want to have up2date default to the > > same behavior for consistency. > > > > make kernel-devel provide 'kernel' or 'kernel-modules' and it will > happen automatically. Out of curiosity, isn't having to have each package manager front-end special case the kernel kinda grotesque? Should maybe packages that can be and prefer to be parallel installed over updated have an RPM header that states this, so that any package renames or new packages that need this behavior will just work? One place it would be useful, for example, would be driver package for out-of-tree drivers (yes, GPL ones, too). From elanthis at awesomeplay.com Sat Jan 22 20:21:28 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 22 Jan 2005 15:21:28 -0500 Subject: further package removals/potential package removals In-Reply-To: <20050122201706.GA3494@chrys.ms.mff.cuni.cz> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <20050122201706.GA3494@chrys.ms.mff.cuni.cz> Message-ID: <1106425288.31857.26.camel@stargrazer.home.awesomeplay.com> On Sat, 2005-01-22 at 21:17 +0100, Miloslav Trmac wrote: > On Sat, Jan 22, 2005 at 03:14:51PM -0500, Sean Middleditch wrote: > > These kinds of comments really need to stop - it doesn't matter how > > useful a utility is on your site, or even a number of users sites, > > because *you can still install it from Extras*! > That's not the case if we are talking about the rescue mode available > on the first installation CD of Core. And the package set included in Core has roughly nothing to do with the pre-built OS image used by the rescue system. For a rescue CD the preferred browser would definitely be a text-based one and not Firefox. ;-) From jspaleta at gmail.com Sat Jan 22 20:22:53 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 22 Jan 2005 15:22:53 -0500 Subject: kernel-devel: should yum install, not update? In-Reply-To: <1106422790.3511.2.camel@cutter> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> Message-ID: <604aa79105012212225b58487b@mail.gmail.com> On Sat, 22 Jan 2005 14:39:50 -0500, seth vidal wrote: > make kernel-devel provide 'kernel' or 'kernel-modules' and it will > happen automatically. Well i certaintly can't comment on whether its appropriate for kernel-devel to provide either of those. This seems kernel-devel package is the new and better solution to try to provide the headers. So it doesnt actually provide a kernel.. and it doesnt actually provide kernel-modules. It does provide kernel-devel, which is consistent with every other *-devel package in the distro :-> Providing 'kernel' would definitely be inappropriate and misleading.. packages actually require 'kernel' so it means something significant to provide 'kernel' Providing 'kernel-modules' on the other hand... i don't think anything requires 'kernel-modules' so it might be okay to make kernel-devel provide that but i still seems to me like potential double-meaning to what 'kernel-modules' means since kernel-devel doesnt actually include a single kernel-module. Maybe Dave Jones can be poked into making a comment about this. -jef"snow"spaleta From fedora-devel-list at cygnusx-1.org Sat Jan 22 21:30:43 2005 From: fedora-devel-list at cygnusx-1.org (Nathan G. Grennan) Date: Sat, 22 Jan 2005 13:30:43 -0800 Subject: further package removals/potential package removals In-Reply-To: <1106369463.5183.24.camel@one.myworld> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <1106369463.5183.24.camel@one.myworld> Message-ID: <1106429443.13437.2.camel@proton.cygnusx-1.org> On Sat, 2005-01-22 at 05:51 +0100, F?liciano Matias wrote: > Why do we keep xpdf in Fedora Core ? > gpdf works fine. gpdf still lacks a search feature, but xpdf has one. From casimiro.barreto at gmail.com Sat Jan 22 20:30:33 2005 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Sat, 22 Jan 2005 18:30:33 -0200 Subject: further package removals/potential package removals In-Reply-To: <604aa79105012212112b0b3bee@mail.gmail.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> Message-ID: <41F2B7E9.9060305@gmail.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From jcornett at insight.rr.com Sat Jan 22 22:14:03 2005 From: jcornett at insight.rr.com (Jim Cornette) Date: Sat, 22 Jan 2005 17:14:03 -0500 Subject: further package removals/potential package removals In-Reply-To: <20050122170130.GI2898@devserv.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> Message-ID: <41F2D02B.30300@insight.rr.com> Alan Cox wrote: > On Sat, Jan 22, 2005 at 05:16:30AM +0100, F?liciano Matias wrote: > >>Move to Fedora Extra : >>dosfstools >>Lynx (or elinks) > > > lynx is needed for mutt to do html reading on text logins. Its also fairly > important for accessibility for some users. Elinks I wouldn't worry about Lynx is also an important application for when one is not capable of using a GUI to browse html sites. I find the program valuble and not "cruft". Mc is a very handy cli application also and should be included in the core installation. Is the concept of Fedora Extras to push programs off to the side or to find a better location for programs that are close to the upstream developers model in containment? Is there work in making compatible iso files for Fedora Extras to enable installing them during an initial fresh installation? programs for inclusion from my point are xorg-x11, gedit, mc, mozilla (full suite), lynx, various server applications, up2date (or a better, configurable, GUI capable updating tool.) Jim > > Alan > From ville.skytta at iki.fi Sat Jan 22 22:40:11 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 23 Jan 2005 00:40:11 +0200 Subject: kernel-devel: should yum install, not update? In-Reply-To: <1106425033.31857.23.camel@stargrazer.home.awesomeplay.com> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <1106425033.31857.23.camel@stargrazer.home.awesomeplay.com> Message-ID: <1106433611.18887.48.camel@bobcat.mine.nu> On Sat, 2005-01-22 at 15:17 -0500, Sean Middleditch wrote: > On Sat, 2005-01-22 at 14:39 -0500, seth vidal wrote: > > On Sat, 2005-01-22 at 14:22 -0500, Jeff Spaleta wrote: > > > Whatever is decided you probably want to have up2date default to the > > > same behavior for consistency. > > > > make kernel-devel provide 'kernel' or 'kernel-modules' and it will > > happen automatically. > > Out of curiosity, isn't having to have each package manager front-end > special case the kernel kinda grotesque? Should maybe packages that can > be and prefer to be parallel installed over updated have an RPM header > that states this, so that any package renames or new packages that need > this behavior will just work? > > One place it would be useful, for example, would be driver package for > out-of-tree drivers (yes, GPL ones, too). There is a simple way to make this work, already applied by lots of 3rd party kernel stuff (modules, devel etc) package(r)s: put the uname of the kernel in question to the package's Name: field. This would also work with the kernel-devel packages. No special cases needed in any tools. The uname-in-name scheme is not too pretty looking, and it's (very) mildly annoying whenever one has to type it manually (eg. to rpm -e one), but other than that, it Just Works(tm). From jspaleta at gmail.com Sat Jan 22 23:08:03 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 22 Jan 2005 18:08:03 -0500 Subject: further package removals/potential package removals In-Reply-To: <41F2B7E9.9060305@gmail.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> Message-ID: <604aa7910501221508580ce874@mail.gmail.com> On Sat, 22 Jan 2005 18:30:33 -0200, Casimiro de Almeida Barreto > The best thing to do about that is to make a pol: send periodic reports to > be filled by members of Fedora comunities and trying to measure what is > being used, by who and under what circunstancies. Bah... i dont care about popularity.... I dont care one little bit about it. Relying on a measure of current popularity is going to entrench the status quo in terms of user demographics and technologies.. not a particularly good idea for a distro that is suppose to be pushing new promising technology in quickly. And polls of this nature are subject to extreme 'sweaky wheel' bias. -jef From elanthis at awesomeplay.com Sat Jan 22 23:21:18 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 22 Jan 2005 18:21:18 -0500 Subject: kernel-devel: should yum install, not update? In-Reply-To: <1106433611.18887.48.camel@bobcat.mine.nu> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <1106425033.31857.23.camel@stargrazer.home.awesomeplay.com> <1106433611.18887.48.camel@bobcat.mine.nu> Message-ID: <1106436078.4591.3.camel@stargrazer.home.awesomeplay.com> On Sun, 2005-01-23 at 00:40 +0200, Ville Skytt? wrote: > On Sat, 2005-01-22 at 15:17 -0500, Sean Middleditch wrote: > > On Sat, 2005-01-22 at 14:39 -0500, seth vidal wrote: > > > On Sat, 2005-01-22 at 14:22 -0500, Jeff Spaleta wrote: > > > > Whatever is decided you probably want to have up2date default to the > > > > same behavior for consistency. > > > > > > make kernel-devel provide 'kernel' or 'kernel-modules' and it will > > > happen automatically. > > > > Out of curiosity, isn't having to have each package manager front-end > > special case the kernel kinda grotesque? Should maybe packages that can > > be and prefer to be parallel installed over updated have an RPM header > > that states this, so that any package renames or new packages that need > > this behavior will just work? > > > > One place it would be useful, for example, would be driver package for > > out-of-tree drivers (yes, GPL ones, too). > > There is a simple way to make this work, already applied by lots of 3rd > party kernel stuff (modules, devel etc) package(r)s: put the uname of > the kernel in question to the package's Name: field. That doesn't work for the same reason Fedora doesn't do that with the kernel packages themselves - upgrades. Let's say Fedora pushes a new kernel 2.6.12-0.1000. Presumably around the same time whatever third- party repository I'm grabbing my drivers from will push a new version of the driver. If the package had the kernel version in its package name, it would not get automatically updated, and I'd have to manually install the new drivers. Laaaame... ;-) If the drivers come the same way as the kernel this problem doesn't exist. There's also the point that it's still just silly to special case every variation of the kernel packages that needs the install behavior. It's poor abstraction and poor design. From ville.skytta at iki.fi Sat Jan 22 23:22:19 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 23 Jan 2005 01:22:19 +0200 Subject: kernel-devel: should yum install, not update? In-Reply-To: <1106433611.18887.48.camel@bobcat.mine.nu> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <1106425033.31857.23.camel@stargrazer.home.awesomeplay.com> <1106433611.18887.48.camel@bobcat.mine.nu> Message-ID: <1106436139.18887.64.camel@bobcat.mine.nu> On Sun, 2005-01-23 at 00:40 +0200, Ville Skytt? wrote: > There is a simple way to make this work, already applied by lots of 3rd > party kernel stuff (modules, devel etc) package(r)s: put the uname of > the kernel in question to the package's Name: field. > > This would also work with the kernel-devel packages. No special cases > needed in any tools. The uname-in-name scheme is not too pretty > looking, and it's (very) mildly annoying whenever one has to type it > manually (eg. to rpm -e one), but other than that, it Just Works(tm). Actually, there's one more thing: with this scheme, depsolvers should be taught to pull in updated modules along with the kernel when it's updated. So that scheme alone doesn't solve the problem entirely, it kind of just moves it elsewhere. apt from fedora.us/pre-extras has done that module pull-in for ages now, which is probably why I forgot to mention this earlier. This stuff is more a critical problem with external module packages than kernel-devel ones though. Whichever way is chosen, depsolvers need to be updated one way or the another. Maybe it's closest to the POLA to continue on the same path as with the kernel packages, ie. add to installonlypkgs and similar for all of them. Adding a new field for this to the actual rpm packages sounds like "not going to happen" to me, and would probably be essentially the same as what the uname-in-name scheme does. From jspaleta at gmail.com Sat Jan 22 23:23:45 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 22 Jan 2005 18:23:45 -0500 Subject: further package removals/potential package removals In-Reply-To: <41F2B7E9.9060305@gmail.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> Message-ID: <604aa79105012215234bf32d3f@mail.gmail.com> On Sat, 22 Jan 2005 18:30:33 -0200, Casimiro de Almeida Barreto > The best thing to do about that is to make a pol: send periodic reports to > be filled by members of Fedora comunities and trying to measure what is > being used, by who and under what circunstancies. Relying on a measure of current popularity run the risk of entrenching the status quo in terms of user demographics and technologies.. not a particularly good idea for a distro that is suppose to be pushing new promising technology in quickly. And polls of this nature are subject to extreme 'sweaky wheel' bias where a small minority who care deeply about keeping their applications in could very well respond in a disproportionate manner compared to people who just use default apps and don't care enough to respond. Not sure if its worth the effort to mount a poll that can't be used in a quantitative way. -jef From alan at redhat.com Sat Jan 22 23:38:56 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 22 Jan 2005 18:38:56 -0500 Subject: further package removals/potential package removals In-Reply-To: <604aa79105012215234bf32d3f@mail.gmail.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> Message-ID: <20050122233856.GA16555@devserv.devel.redhat.com> On Sat, Jan 22, 2005 at 06:23:45PM -0500, Jeff Spaleta wrote: > Relying on a measure of current popularity run the risk of entrenching > the status quo in terms of user demographics and technologies.. not a > particularly good idea for a distro that is suppose to be pushing new It also may not be productive if you don't stat the usage of the programs. Debian data for example does this and it tells you that people install KDE then don't use it (but don't delete it). No suprise there but its important to know. From ville.skytta at iki.fi Sat Jan 22 23:38:56 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 23 Jan 2005 01:38:56 +0200 Subject: kernel-devel: should yum install, not update? In-Reply-To: <1106436078.4591.3.camel@stargrazer.home.awesomeplay.com> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <1106425033.31857.23.camel@stargrazer.home.awesomeplay.com> <1106433611.18887.48.camel@bobcat.mine.nu> <1106436078.4591.3.camel@stargrazer.home.awesomeplay.com> Message-ID: <1106437136.18887.73.camel@bobcat.mine.nu> On Sat, 2005-01-22 at 18:21 -0500, Sean Middleditch wrote: > That doesn't work for the same reason Fedora doesn't do that with the > kernel packages themselves - upgrades. Yeah, I realized that after posting, see my reply-to-self message in this thread. > Let's say Fedora pushes a new > kernel 2.6.12-0.1000. Presumably around the same time whatever third- > party repository I'm grabbing my drivers from will push a new version of > the driver. If the package had the kernel version in its package name, > it would not get automatically updated, and I'd have to manually install > the new drivers. Laaaame... ;-) ...unless you're using apt from fedora.us/pre-extras :) Probably it's that way also in apt packages from other repositories. Yeah, apt doesn't really count that much any more and will do so even less in the future. Nevertheless, this is good food for thought. From czar at czarc.net Sat Jan 22 23:39:16 2005 From: czar at czarc.net (Gene C.) Date: Sat, 22 Jan 2005 18:39:16 -0500 Subject: removing packages in fedora; nedit In-Reply-To: <1106338018.4351.17.camel@marte.biciclete.ro> References: <1106338018.4351.17.camel@marte.biciclete.ro> Message-ID: <200501221839.16172.czar@czarc.net> On Friday 21 January 2005 15:06, Marius Andreiana wrote: > It was good to see some packages removed from fedora to make room for > new ones. I guess all had alternatives (except gnuchess/xboard, I > thought about maintaining it in Extras but then remembered how it always > beats me and grinned :-D ) > > Still, would be nice to have a proposal for removal on devel list first. > Feels more like community. > > How about removing nedit too? I find out about it by typing "nc" instead > of mc (nc is also netcat) > > Waiting for FC Extras submitting policy to be done and commit Hylafax, Some of us like nedit and would be very disappointed to see it removed. I can certainly see that nc could be removed/renamed since it conflicts with netcat's nc but nedit itself ... no, that would be undesirable. -- Gene From kyrre at solution-forge.net Sat Jan 22 23:40:35 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 23 Jan 2005 00:40:35 +0100 Subject: further package removals/potential package removals In-Reply-To: <20050122165044.GE2898@devserv.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <1106406829.11656.7.camel@md.local.linuxlobbyist.org> <1106411727.8428.2.camel@jonspc> <20050122165044.GE2898@devserv.devel.redhat.com> Message-ID: <1106437234.4047.1.camel@localhost.localdomain> l?r, 22.01.2005 kl. 17.50 skrev Alan Cox: > On Sat, Jan 22, 2005 at 04:35:28PM +0000, Jonathan Andrews wrote: > > > Er...why? Given the number of consumer devices these days that use > > > VFAT, I can't think of a reason why this would belong in Core. > > > > I second that why ? Every USB stick, camera or floppy disk owner will > > be cursing you. > > I'd second that. Its needed for so many things. agreed. killing vfat support would be bad. It's the reason i keep cursing Debian whenever i need to read such a disk. Besides, vfat is imensely usefull on removable storage - you don't need a permissions system on that stuff. But what about mtools? Isn't that "dos-style handling of floppyes"? From kyrre at solution-forge.net Sat Jan 22 23:41:56 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 23 Jan 2005 00:41:56 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106429443.13437.2.camel@proton.cygnusx-1.org> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <1106369463.5183.24.camel@one.myworld> <1106429443.13437.2.camel@proton.cygnusx-1.org> Message-ID: <1106437316.4047.3.camel@localhost.localdomain> l?r, 22.01.2005 kl. 22.30 skrev Nathan G. Grennan: > On Sat, 2005-01-22 at 05:51 +0100, F?liciano Matias wrote: > > Why do we keep xpdf in Fedora Core ? > > gpdf works fine. > > gpdf still lacks a search feature, but xpdf has one. and evince. *great* app! From czar at czarc.net Sat Jan 22 23:44:53 2005 From: czar at czarc.net (Gene C.) Date: Sat, 22 Jan 2005 18:44:53 -0500 Subject: further package removals/potential package removals In-Reply-To: <20050121235849.GA6469@nostromo.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> Message-ID: <200501221844.53199.czar@czarc.net> On Friday 21 January 2005 18:58, Bill Nottingham wrote: > ?nedit > ? ?- legacy interface (motif) > ? ?- doesn't support Unicode I would be disappointed to see nedit removed. If, and only if, Fedora Extras is real (a lot more real than it has been so far), then moving it to Extras I can understand. Will I do my own thing and build my own nedit if it is removed: yes. Will be be a bit pissed: yes. When the latest version is not built for the current release but is available in rawhide/development, do I rebuild it for the current release: yes. Editors are very personal. Once you get use to one, that is your editor and it is difficult to change no matter if there are better one available. I have been at this computer stuff for more years than I care to think about ... nedit is my editor of choice. -- Gene From jspaleta at gmail.com Sat Jan 22 23:54:38 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 22 Jan 2005 18:54:38 -0500 Subject: further package removals/potential package removals In-Reply-To: <20050122233856.GA16555@devserv.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> Message-ID: <604aa79105012215547cd6144a@mail.gmail.com> On Sat, 22 Jan 2005 18:38:56 -0500, Alan Cox wrote: > It also may not be productive if you don't stat the usage of the programs. > Debian data for example does this and it tells you that people install > KDE then don't use it (but don't delete it). No suprise there but its > important to know. On a tangent to this... whats the easiest way to get a feel of which packages I'm not using on my fedora install? Is there anytihng more clever than doing an exhaustive check of atimes on all the files owned by rpm packages and comparing that to the package install time? -jef From jspaleta at gmail.com Sat Jan 22 23:54:38 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 22 Jan 2005 18:54:38 -0500 Subject: further package removals/potential package removals In-Reply-To: <20050122233856.GA16555@devserv.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> Message-ID: <604aa79105012215547cd6144a@mail.gmail.com> On Sat, 22 Jan 2005 18:38:56 -0500, Alan Cox wrote: > It also may not be productive if you don't stat the usage of the programs. > Debian data for example does this and it tells you that people install > KDE then don't use it (but don't delete it). No suprise there but its > important to know. On a tangent to this... whats the easiest way to get a feel of which packages I'm not using on my fedora install? Is there anytihng more clever than doing an exhaustive check of atimes on all the files owned by rpm packages and comparing that to the package install time? -jef From feliciano.matias at free.fr Sun Jan 23 00:23:44 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sun, 23 Jan 2005 01:23:44 +0100 Subject: kernel-devel: should yum install, not update? In-Reply-To: <1106422790.3511.2.camel@cutter> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> Message-ID: <1106439825.3845.4.camel@one.myworld> Le samedi 22 janvier 2005 ? 14:39 -0500, seth vidal a ?crit : > make kernel-devel provide 'kernel' or 'kernel-modules' and it will > happen automatically. I do not like this. I prefer (/etc/yum.conf) : installonlypkgs=kernel-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jwz at jwz.org Sun Jan 23 00:25:54 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Sat, 22 Jan 2005 16:25:54 -0800 Subject: further package removals/potential package removals References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> Message-ID: <41F2EF12.E8EF945@jwz.org> Jeff Spaleta wrote: > > On a tangent to this... whats the easiest way to get a feel of which > packages I'm not using on my fedora install? Is there anytihng more > clever than doing an exhaustive check of atimes on all the files owned > by rpm packages and comparing that to the package install time? After I do a fresh install, I usually just go through the "rpm -qa" list and start trying "rpm -e" on stuff that I believe I don't use, and see when I get a dependency on something that I know I *do* use. Which is distressingly often. There is just an amazing amount of dependency clutter in there. For example: I don't use Windows, ever. This means I don't use Samba. But I can't uninstall it, because Nautilus depends on it. Now, I don't use Nautilus either, but I can't just uninstall *that*, because control-center depends on it, which I *do* use. Likewise, I don't own a printer and haven't in years, but I often find myself unable to delete the zillions of printer drivers without also deleting Ghostscript and half of Gnome or something. If space is tight, the first thing I do is nuke everything except en_US under /usr/share/locale/ and /usr/lib/locale/ -- since I don't happen to speak 113 different languages, that's more than 320MB of pure waste. Blowing away /usr/share/doc/ is also helpful; it's huge, and every file in there is Googlable. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From Nicolas.Mailhot at laPoste.net Sat Jan 22 12:56:55 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 22 Jan 2005 13:56:55 +0100 Subject: further package removals/potential package removals In-Reply-To: <5256d0b050121170521aa145b@mail.gmail.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <5256d0b050121170521aa145b@mail.gmail.com> Message-ID: <1106398615.28457.2.camel@rousalka.dyndns.org> Le samedi 22 janvier 2005 ? 09:05 +0800, Peter Robinson a ?crit : > > Opinions? > > Yep, get rid of them. Can we also get rid / move to extras all the non > GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK > 1 cruft as well? Even better : get rid of all the stuff that doesn't use fontconfig yet -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From davej at redhat.com Sun Jan 23 00:36:39 2005 From: davej at redhat.com (Dave Jones) Date: Sat, 22 Jan 2005 19:36:39 -0500 Subject: kernel-devel: should yum install, not update? In-Reply-To: <604aa79105012212225b58487b@mail.gmail.com> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> Message-ID: <20050123003639.GA28104@redhat.com> On Sat, Jan 22, 2005 at 03:22:53PM -0500, Jeff Spaleta wrote: > Providing 'kernel-modules' on the other hand... i don't think anything > requires 'kernel-modules' so it might be okay to make kernel-devel > provide that but i still seems to me like potential double-meaning to > what 'kernel-modules' means since kernel-devel doesnt actually include > a single kernel-module. > > Maybe Dave Jones can be poked into making a comment about this. Adding either of the provides seems like a rather ugly hack. up2date already has the smarts to installonly the -devel package, so I'm of the opinion yum should be fixed to do the right thing too. Jeremy is rebuilding yum as I type for tomorrows rawhide to take care of this issue. Dave From feliciano.matias at free.fr Sun Jan 23 00:46:25 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Sun, 23 Jan 2005 01:46:25 +0100 Subject: kernel-devel: should yum install, not update? In-Reply-To: <604aa79105012212225b58487b@mail.gmail.com> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> Message-ID: <1106441185.3845.20.camel@one.myworld> Le samedi 22 janvier 2005 ? 15:22 -0500, Jeff Spaleta a ?crit : > Maybe Dave Jones can be poked into making a comment about this. > Maybe he will want to change "Provides: kernel = %{version}" to "Provides: kernel = %{version}-%{release}". Example : [admin at one i386]$ rpm -q --provides -p kernel-2.6.10-1.741_FC3.i686.rpm kernel = 2.6.10 kernel-drm = 4.3.0 kernel = 2.6.10-1.741_FC3 If a package provide "kernel = 2.6.10-1.741_FC3" it already provides "kernel = 2.6.10". [admin at one i386]$ rpm -q --requires -p kernel-module-unicorn-atm-0.8.7-mat.3_2.6.10_1.741_FC3.mat.1.i686.rpm /bin/sh /sbin/depmod kernel = 2.6.10-1.741_FC3.mat.1 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 This package requires "kernel = 2.6.10-1.741_FC3.mat.1" but all kernel-2.6.10* from Fedora provide "kernel = 2.6.10" (that is "kernel = 2.6.10-*"). So any kernel-* from Fedora provide the requirement for "kernel = 2.6.10-1.741_FC3.mat.1". Every time a new kernel is released, I apply this little patch : --- old/kernel-2.6.spec 2005-01-23 01:43:02.909909259 +0100 +++ new/kernel-2.6.spec 2005-01-23 01:43:33.604401005 +0100 @@ -161,7 +161,6 @@ #ExclusiveArch: noarch %{all_x86} x86_64 ppc64 ppc ExclusiveArch: noarch %{all_x86} x86_64 ExclusiveOS: Linux -Provides: kernel = %{version} Provides: kernel-drm = 4.3.0 Prereq: %{kernel_prereq} Conflicts: %{kernel_dot_org_conflicts} @@ -381,7 +380,7 @@ Summary: The Linux kernel compiled for SMP machines. Group: System Environment/Kernel -Provides: kernel = %{version} +Provides: kernel = %{version}-%{release} Provides: kernel-drm = 4.3.0 Prereq: %{kernel_prereq} Conflicts: %{kernel_dot_org_conflicts} -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From felipe_alfaro at linuxmail.org Sun Jan 23 01:53:04 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sun, 23 Jan 2005 02:53:04 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106422766.16789.55.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> Message-ID: <855C1D68-6CE1-11D9-86B4-000D9352858E@linuxmail.org> On 22 Jan 2005, at 20:39, Peter Backlund wrote: > This discussion is turning a bit absurd, imo. Just because a package is > lifted out of Core doesn't mean it will vanish from the face of the > earth. You can still install it from Extras if you need it. I think what some people is discussing here is not the fact that some packages will end up in Core or Extras repository: it's the fact that Anaconda installer should allow to install packages from the Extras repository easily and automatically, if told so, as it is able to install packages from the Core repository. Particularly, I don't mind if KDE, XFCE or whatever ends up in the Extras repository, but I want to be able to install Fedora Core 4 and install packages from both Core and Extras in a single pass, during the installation process. Also, I do want packages in the Extras repository to be maintained and be bound to the same QA process as Core packages. From mpeters at mac.com Sun Jan 23 02:12:12 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 23 Jan 2005 02:12:12 +0000 Subject: further package removals/potential package removals In-Reply-To: <604aa79105012212112b0b3bee@mail.gmail.com> (from jspaleta@gmail.com on Sat Jan 22 12:11:32 2005) References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> Message-ID: <1106446332l.21465l.0l@devel.mpeters.us> On 01/22/2005 12:11:32 PM, Jeff Spaleta wrote: > > If there is serious interest in slimming Core down.. then a decision > has to be made to define a reference usage case or two so we can get > past personal preference and make decisions based on the design needs > of the usage case goal. If a reference usage case for Core is > suppose > to be a developer oriented workspace thats going to impact the > decisions as to what is important to include. If a reference usage > case for Core is suppose to be a desktop for the average human, > that's > going to impact the decisions in very different ways. If Core is > suppose to provide both.. well guess what.. Core will continue to be > 4+ CD images. I definitely want to see Fedora Core shrink. I want to see Linux on the Desktop really take off - as in someday see 20% or more marketshare. That only is going to happen with OEM's. Other than Apple users, most people I know use the version of the OS that their PC ships with - they don't bother to buy updates let alone other operating systems. Corporate desktop is different, there they run whatever IT trusts - which also often is not latest. Anyway - to get Fedora on OEM's it has to be smaller because up the cost of support - it's cheaper to train support staff for a smaller base of software. IMHO it should be easy for an OEM to start with a smaller base, rip either KDE or GNOME out (depending upon what their staff is trained in), rip the dev tools out, add some patented stuff (like GStreamer plugins from fluendo or whoever) and have well under a gig of packages. They can do that now, but it is harder because there is a lot more to sift through. From n3npq at nc.rr.com Sun Jan 23 02:39:28 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sat, 22 Jan 2005 21:39:28 -0500 Subject: further package removals/potential package removals In-Reply-To: <41F2EF12.E8EF945@jwz.org> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> Message-ID: <41F30E60.5050605@nc.rr.com> Jamie Zawinski wrote: >Jeff Spaleta wrote: > > >>On a tangent to this... whats the easiest way to get a feel of which >>packages I'm not using on my fedora install? Is there anytihng more >>clever than doing an exhaustive check of atimes on all the files owned >>by rpm packages and comparing that to the package install time? >> >> > >After I do a fresh install, I usually just go through the "rpm -qa" >list and start trying "rpm -e" on stuff that I believe I don't use, >and see when I get a dependency on something that I know I *do* use. > > Try "rpm -qa --last", the older packages are often unused. >Which is distressingly often. There is just an amazing amount of >dependency clutter in there. > > "dependency clutter" presumes that dependencies are arbitrarily designed to decrease the quality of your life. That is not the case. Instead ... >For example: I don't use Windows, ever. This means I don't use Samba. >But I can't uninstall it, because Nautilus depends on it. Now, I don't >use Nautilus either, but I can't just uninstall *that*, because >control-center depends on it, which I *do* use. > > ... nautilus "needs" samba much likes it needs just about every other bleeping library in FC4. Why? Because users want "features", and features requires implementations, usually in libraries, which use sonames, which are copied into package dependencies. This situation is unlikely to change as long as users want "features", duh. However, dependencies are the least of your problems. As long as nautilus links libraries that link libraries that link libraraies that need samba, then one will not be able to achieve joy of a full "featured" nautilus that executes unless the necessary libraries are, indeed, present and installed. Blaming dependencies form libraries is like blaming Kerry for Iraq. >Likewise, I don't own a printer and haven't in years, but I often find >myself unable to delete the zillions of printer drivers without also >deleting Ghostscript and half of Gnome or something. > > So change how ghostscript is packaged, splitting out each individual printer driver into a separate package, leaving a pristine ghostscript that floats your boat. >If space is tight, the first thing I do is nuke everything except en_US >under /usr/share/locale/ and /usr/lib/locale/ -- since I don't happen to >speak 113 different languages, that's more than 320MB of pure waste. > > If space is tight, then you're cheap ;-) Seriously, diska *are* cheap. And there is already a mechanism to install only requested locales, feel free to configure to limit locales to *only* en_US if your boat is sinking because of locale baggage. >Blowing away /usr/share/doc/ is also helpful; it's huge, and every file >in there is Googlable. > > > Try --excludedocs, been in rpm for years. Seriously, /usr/share/doc ain't the problem, look around a bit on your file system with "du -s". 73 de Jeff From jwz at jwz.org Sun Jan 23 03:03:19 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Sat, 22 Jan 2005 19:03:19 -0800 Subject: further package removals/potential package removals References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> Message-ID: <41F313F7.7679D847@jwz.org> Jeff Johnson wrote: > > ... nautilus "needs" samba much likes it needs just about every other > bleeping library in FC4. Why? Because users want "features", and > features requires implementations, usually in libraries, which use > sonames, which are copied into package dependencies. If you think that the fact that Nautilus has a lot of "features" means that it's necessary for it to cause the entire desktop as a single unsplittable ball of mud, well, you have been misinformed. > So change how ghostscript is packaged, splitting out each individual > printer driver into a separate package, leaving a pristine ghostscript > that floats your boat. Hey, guess what! I don't maintain Ghostscript or work for Red Hat! Other people on this list have the ability to fix this crap, not me. > If space is tight, then you're cheap ;-) Ok smartass, now why don't you explain to me how I'm "cheap" because I don't have the time or inclination to back up, repartition, and restore my machines' drives every time I upgrade the OSes because someone with your "disk space doesn't matter" attitude decided that it was ok for a default install to go from a /usr that takes ~400MB to >2GB in just two years. > Seriously, diska *are* cheap. Seriously, you *are* missing the point. > And there is already a mechanism to install only requested locales, > feel free to configure to limit locales to *only* en_US if your boat > is sinking because of locale baggage. What binary rpm installation does that? Oh, I'm sorry, you must have been under the impression that I was compiling all my packages from source, since everyone does that. > Try --excludedocs, been in rpm for years. I must have overlooked the Anaconda checkbox that turns that on. And the "yum update" option, too. > look around a bit on your file system with "du -s". GOLLY I NEVER THOUGHT OF THAT. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From n3npq at nc.rr.com Sun Jan 23 03:28:18 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sat, 22 Jan 2005 22:28:18 -0500 Subject: further package removals/potential package removals In-Reply-To: <41F313F7.7679D847@jwz.org> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <41F313F7.7679D847@jwz.org> Message-ID: <41F319D2.6080303@nc.rr.com> Jamie Zawinski wrote: >Jeff Johnson wrote: > > >>... nautilus "needs" samba much likes it needs just about every other >>bleeping library in FC4. Why? Because users want "features", and >>features requires implementations, usually in libraries, which use >>sonames, which are copied into package dependencies. >> >> > >If you think that the fact that Nautilus has a lot of "features" means >that it's necessary for it to cause the entire desktop as a single >unsplittable ball of mud, well, you have been misinformed. > > By George, I think he's got it! The point is that dependencies are not the problem, bloat is. > > >>So change how ghostscript is packaged, splitting out each individual >>printer driver into a separate package, leaving a pristine ghostscript >>that floats your boat. >> >> > >Hey, guess what! I don't maintain Ghostscript or work for Red Hat! >Other people on this list have the ability to fix this crap, not me. > > Well I have maintained ghostscript for Red Hat, and splitting up the drivers into single packages so that users who wish to use ghostscript without printer drivers just ain't worth the trouble. How much space is saved? And how many additional packages need to be added, one per driver, to support the illusion of choice? Do the math, it's not worth the trouble. There are far bigger problems that need solving than ghostscript drivers. > > >>If space is tight, then you're cheap ;-) >> >> > >Ok smartass, now why don't you explain to me how I'm "cheap" because I >don't have the time or inclination to back up, repartition, and restore >my machines' drives every time I upgrade the OSes because someone with >your "disk space doesn't matter" attitude decided that it was ok for a >default install to go from a /usr that takes ~400MB to >2GB in just two >years. > I, too was astonished at the amount of bloat. And the actual sum is closer to 4 GB, then 2 Gb for an "everything" install. And the bloat happened longer than 2 years ago. Again because users wish "features", like 4 or 5 copies of automake (I've lost count), and 6+ copies of Berkely DB. And 6+ shells, and as many text editors as exist, and ... > > >>Seriously, diska *are* cheap. >> >> > >Seriously, you *are* missing the point. > > What was the point I'm missing again? > > >>And there is already a mechanism to install only requested locales, >>feel free to configure to limit locales to *only* en_US if your boat >>is sinking because of locale baggage. >> >> > >What binary rpm installation does that? Oh, I'm sorry, you must have >been under the impression that I was compiling all my packages from >source, since everyone does that. > > No, choosing locales is an install option that applies to binary options that is anaconda selectable, and globally configurable. And all rpm installations since like RHL 7.2 have had that functionality. > > >>Try --excludedocs, been in rpm for years. >> >> > >I must have overlooked the Anaconda checkbox that turns that on. >And the "yum update" option, too. > > So make an RFE. The mechanism exists even if anaconda and yum choose not to use --excludedocs. The mechanism is also globally configurable, put %_netsharedpath /usr/share/doc in /etc/rpm/macros. Or keeep bitching about the energy and effort that *YOU* need to go through to tune *YOUR* system to *YOUR* custom tatstes, perhaps *YOU* will be heard, and yum and anaconda will provide *YOU* a special radio button that customizes exactly to *YOUR* taste. > > >>look around a bit on your file system with "du -s". >> >> > >GOLLY I NEVER THOUGHT OF THAT. > > Well keep practicing, perhaps you'll figger it out some day. 73 de Jeff From symbiont at berlios.de Sun Jan 23 03:36:22 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sun, 23 Jan 2005 11:36:22 +0800 Subject: rawhide report: 20050121 changes In-Reply-To: <1106410993.15391.42.camel@jdub.homelinux.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106410993.15391.42.camel@jdub.homelinux.org> Message-ID: <200501231136.22648.symbiont@berlios.de> On Sunday 23 January 2005 00:23, Josh Boyer wrote: > KDE is a large package to maintain both because of it's code size and > it's large user base. ?Someone from the community maybe well be able > to do the job, but right now KDE is released and maintained as a part > of Core. ?It has a maintainer, it's part of the daily, weekly, > whatever builds and it probably gets at least some QA testing. For what it's worth, I always nuke the KDE packages sent from Core with the kde-redhat.sf.net packages. I've been an avid KDE user from the beginning, but still, on occasion use GNOME apps (xchat being the most used). I'm not opposed to moving KDE onto another ISO. As a more advanced user of KDE, I wouldn't be that opposed to just throwing it all out because I'm just gonna hookup with Rex's packages anyway. That said, if this is seriously being considered, then I would recommend that GNOME get fair treatment: put onto its own ISO. Maybe the base GNOME/Gtk libs to get up2date, anaconda, system-config-*, blah blah working should be on the first CD. The rest of it (gnobots2, etc.) can be piled onto another ISO, which one can elect not to install. Another thing to consider: users with bandwidth. One CD bootstrap, mainlibs in place, then yum, apt, or smart the rest of it. have fun, -- -jeff From rc040203 at freenet.de Sun Jan 23 03:59:56 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 23 Jan 2005 04:59:56 +0100 Subject: further package removals/potential package removals In-Reply-To: <20050122170130.GI2898@devserv.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> Message-ID: <1106452796.7211.491.camel@mccallum.corsepiu.local> On Sat, 2005-01-22 at 12:01 -0500, Alan Cox wrote: > Possibly joe also ought to go to extras nowdays. Is there any wordstar compatible editor in Core? To me, seeing joe removed would be a severe regression. >15 years of using wordstar compatible editors can't simply be ignored. Ralf From jspaleta at gmail.com Sun Jan 23 04:02:56 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 22 Jan 2005 23:02:56 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <200501231136.22648.symbiont@berlios.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106410993.15391.42.camel@jdub.homelinux.org> <200501231136.22648.symbiont@berlios.de> Message-ID: <604aa79105012220026740af36@mail.gmail.com> On Sun, 23 Jan 2005 11:36:22 +0800, Jeff Pitman wrote: > Another thing to consider: users with bandwidth. One CD bootstrap, > mainlibs in place, then yum, apt, or smart the rest of it. I think the network install mode of anaconda that is already there serves a similar enough purpose for anyone who wants to use a network as part of the install process. And don't forget about the much maligned mininal install option. A more advanced one CD bootstrap that gives you a usable desktop is a tough target to meet. I don't want to see the rescue environment being ditched to make room for a 1 CD desktop install. I think its vitally important to keep a usable rescue mode available as part of every self-contained piece of install media that's going to be offered. -jef"the damn weatherman promised me a lull in the snow...wheres my damn lull..."spaleta From elanthis at awesomeplay.com Sun Jan 23 04:08:29 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 22 Jan 2005 23:08:29 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <604aa79105012220026740af36@mail.gmail.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106410993.15391.42.camel@jdub.homelinux.org> <200501231136.22648.symbiont@berlios.de> <604aa79105012220026740af36@mail.gmail.com> Message-ID: <1106453309.4591.20.camel@stargrazer.home.awesomeplay.com> On Sat, 2005-01-22 at 23:02 -0500, Jeff Spaleta wrote: > A more advanced one CD bootstrap that gives you a usable desktop is a > tough target to meet. I don't want to see the rescue environment > being ditched to make room for a 1 CD desktop install. I think its > vitally important to keep a usable rescue mode available as part of > every self-contained piece of install media that's going to be > offered. Not to start a completely different flame war, but... Ubuntu seems to manage both a single CD install and a usable rescue mode. I have not actually used Ubuntu, so I don't know exactly *how* usable the rescue mode is, but the docs indicate it's there and can do a thing or two. ;-) From elanthis at awesomeplay.com Sun Jan 23 04:11:26 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sat, 22 Jan 2005 23:11:26 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106452796.7211.491.camel@mccallum.corsepiu.local> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> Message-ID: <1106453486.4591.24.camel@stargrazer.home.awesomeplay.com> On Sun, 2005-01-23 at 04:59 +0100, Ralf Corsepius wrote: > On Sat, 2005-01-22 at 12:01 -0500, Alan Cox wrote: > > > Possibly joe also ought to go to extras nowdays. > Is there any wordstar compatible editor in Core? > > To me, seeing joe removed would be a severe regression. >15 years of > using wordstar compatible editors can't simply be ignored. So install it from Extras. It's preclusion from Core will not cause a retroactive obliteration of every copy of joe in the known world, nor hinder you in the least from installing it whenever you want from Extras. Why is this not getting through to people? Is "extras" a synonym for "/dev/null" in half the world or something? ;-) From cmadams at hiwaay.net Sun Jan 23 04:16:00 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 22 Jan 2005 22:16:00 -0600 Subject: further package removals/potential package removals In-Reply-To: <41F30E60.5050605@nc.rr.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> Message-ID: <20050123041600.GB1420188@hiwaay.net> Once upon a time, Jeff Johnson said: > ... nautilus "needs" samba much likes it needs just about every other > bleeping library > in FC4. Why? Because users want "features", and features requires > implementations, > usually in libraries, which use sonames, which are copied into package > dependencies. nautilus has an explicit dependency in the spec file on gnome-vfs2-smb. It does not have any apparent dependency on libsmb.so that is provided by gnome-vfs2-smb (nothing seems to have such a dependency). If I don't have any need to browse Windows networks, why do I need the software installed? Features are great; _required_ features are not. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From michael.favia at insitesinc.com Sun Jan 23 04:33:05 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Sat, 22 Jan 2005 22:33:05 -0600 Subject: kernel-devel: should yum install, not update? In-Reply-To: <20050123003639.GA28104@redhat.com> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> <20050123003639.GA28104@redhat.com> Message-ID: <41F32901.7080003@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Jones wrote: > On Sat, Jan 22, 2005 at 03:22:53PM -0500, Jeff Spaleta wrote: > > > Providing 'kernel-modules' on the other hand... i don't think anything > > requires 'kernel-modules' so it might be okay to make kernel-devel > > provide that but i still seems to me like potential double-meaning to > > what 'kernel-modules' means since kernel-devel doesnt actually include > > a single kernel-module. > > > > Maybe Dave Jones can be poked into making a comment about this. > > Adding either of the provides seems like a rather ugly hack. > up2date already has the smarts to installonly the -devel package, > so I'm of the opinion yum should be fixed to do the right thing too. > Jeremy is rebuilding yum as I type for tomorrows rawhide to > take care of this issue. Yes but the real question is "Where does this information belong?" I dont think that these things should be managed ad-hoc by each competing package manager but instead internalized into the packages themselves somehow for scalabiltiy and adaptability purposes. - -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB8ykBBVsNYjF2rDYRAvApAJ0aoYeqEuIFDovCsZgxdoZS7093qgCgjCi0 M/g76/4+8nV+BWkkpdgrqz4= =3K86 -----END PGP SIGNATURE----- From n3npq at nc.rr.com Sun Jan 23 04:32:59 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sat, 22 Jan 2005 23:32:59 -0500 Subject: further package removals/potential package removals In-Reply-To: <20050123041600.GB1420188@hiwaay.net> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <20050123041600.GB1420188@hiwaay.net> Message-ID: <41F328FB.2040105@nc.rr.com> Chris Adams wrote: >Once upon a time, Jeff Johnson said: > > >>... nautilus "needs" samba much likes it needs just about every other >>bleeping library >>in FC4. Why? Because users want "features", and features requires >>implementations, >>usually in libraries, which use sonames, which are copied into package >>dependencies. >> >> > >nautilus has an explicit dependency in the spec file on gnome-vfs2-smb. >It does not have any apparent dependency on libsmb.so that is provided >by gnome-vfs2-smb (nothing seems to have such a dependency). If I don't >have any need to browse Windows networks, why do I need the software >installed? > >Features are great; _required_ features are not. > > rpm -q --changelog nautilus ... * Thu Aug 26 2004 Alexander Larsson - 2.7.4-3 - Added requires eject - Depend on gnome-vfs2-smb instead of -extras RFE in bugzilla is far more effective mechanism for change than fedora-devel. 73 de Jeff From enrico.scholz at informatik.tu-chemnitz.de Sun Jan 23 04:31:37 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 23 Jan 2005 05:31:37 +0100 Subject: further package removals/potential package removals In-Reply-To: <41F319D2.6080303@nc.rr.com> (Jeff Johnson's message of "Sat, 22 Jan 2005 22:28:18 -0500") References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <41F313F7.7679D847@jwz.org> <41F319D2.6080303@nc.rr.com> Message-ID: <87651odavq.fsf@londo.ultra.csn.tu-chemnitz.de> Jeff Johnson writes: >>If you think that the fact that Nautilus has a lot of "features" means >>that it's necessary for it to cause the entire desktop as a single >>unsplittable ball of mud, well, you have been misinformed. > > By George, I think he's got it! The point is that dependencies are not > the problem, The gnupg -> (perl,openldap) deps *are* a problem, because they are not needed for the gnupg core functionality but only for two extra programs, which are unused on most systems. > bloat is. Yes, the stupid kernel packaging which brings 30 MB of bloat into / is a problem also. But nevertheless, the deps should be cut. A candidate would be 'pam' which brings 'glib2' in, or all the packages with 'Requires: kernel>=2.6' which should be either removed or rewritten to 'Conflicts: kernel<2.6'. > No, choosing locales is an install option that applies to binary > options that is anaconda selectable, I might be wrong (I do not have time to verify it now) but afair, on my last FC3 installation, the language selection in anaconda had no influence on %_install_langs but sets some value in /etc/sysconfig/i18n only. >>>Try --excludedocs, been in rpm for years. >> >>I must have overlooked the Anaconda checkbox that turns that on. And >>the "yum update" option, too. > > So make an RFE. Has probably only a small chance of success. 'anaconda' will follow more and more the Gnome UI guidelines so that there is no room for useful features. Existing ones like package selection or detailed progress reports were removed already. > The mechanism exists even if anaconda and yum choose not to use > --excludedocs. The mechanism is also globally configurable, put > %_netsharedpath /usr/share/doc mmmh... %_netsharedpath... we had a lot of fruitless discussions about this so I wonder that you mention it here ;) It has serious implementation flaws (infection of parent paths; bug #52725 lasts for >3 years in bugzilla) and there does not exist a mechanisms to test it in %scriptlets (which causes problems e.g. in all the java packages). Using %_netsharedpath to disable installation of certain files is not a good idea. E.g. files in /usr/share/doc are required by cups for its web-frontend. %_netsharedpath is for situations where the files exist but are managed externally. > in /etc/rpm/macros. anaconda does not honor any previous rpm setting. Partially, this is caused by rpm which makes it really difficultly to override paths of its configuration. Enrico From cmadams at hiwaay.net Sun Jan 23 04:36:09 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 22 Jan 2005 22:36:09 -0600 Subject: further package removals/potential package removals In-Reply-To: <1106453486.4591.24.camel@stargrazer.home.awesomeplay.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106453486.4591.24.camel@stargrazer.home.awesomeplay.com> Message-ID: <20050123043609.GC1420188@hiwaay.net> Once upon a time, Sean Middleditch said: > So install it from Extras. It's preclusion from Core will not cause a > retroactive obliteration of every copy of joe in the known world, nor > hinder you in the least from installing it whenever you want from > Extras. > > Why is this not getting through to people? Is "extras" a synonym for > "/dev/null" in half the world or something? ;-) Just because _you_ don't think it should be in Core doesn't mean that it in fact should be removed. Why do you think you get to dictate what gets moved to Extras and anyone that disagrees with you is wrong? To quote from the Fedora website: Objectives of Fedora Core: 1. Create a complete general-purpose operating system with capabilities equivalent to competing operating systems, built for and by a community -- those who not only consume, but also produce for the good of other community members. ... 8. Include a range of popular packages, beyond those included in Red Hat's commercially supported products. (Limited, of course, to packages that Red Hat can legally provide; also limited to quality packages as defined by our standards.) These are objectives of Fedora _Core_, not Fedora Extras. Do "competing operating systems" include joe? I would say yes; joe has been included in most Linux distributions for years. If you install the Solaris 9 "Sun Freeware" collection, you get joe. Is it a popular package? It sounds like it. Is it already included in Red Hat's commecially support products? It is in RHEL 3. In any case, until Fedora Extras fully materializes, I think it is a moot point. I would like to see a release with FC and FE released at the same time (with FE being based on the current "pre-Extras") and FE fully operational _before_ packages start migrating from Core to Extras. We need to see how well FE really works before pushing a bunch of packages out of FC. I think we also need anaconda to handle installing from FE ISOs during install to make things as seamless as possible. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From enrico.scholz at informatik.tu-chemnitz.de Sun Jan 23 03:48:39 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 23 Jan 2005 04:48:39 +0100 Subject: further package removals/potential package removals In-Reply-To: <41F2EF12.E8EF945@jwz.org> (Jamie Zawinski's message of "Sat, 22 Jan 2005 16:25:54 -0800") References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> Message-ID: <87acr0dcvc.fsf@londo.ultra.csn.tu-chemnitz.de> Jamie Zawinski writes: > For example: I don't use Windows, ever. This means I don't use Samba. > But I can't uninstall it, because Nautilus depends on it. Now, I don't > use Nautilus either, but I can't just uninstall *that*, because > control-center depends on it, which I *do* use. ACK; some packages should be split to avoid such dependencies. 'gnupg' (which brings 'perl' and 'openldap' into the game (additional 50MB)) and 'kernel' (which wastes 30MB and 6000 inodes of my /) are packages coming at first into my mind... > If space is tight, the first thing I do is nuke everything except en_US > under /usr/share/locale/ and /usr/lib/locale/ Just do 'echo "%_install_langs C:en" >>/etc/rpm/macros' and reinstall everything (as anaconda neither sets it on fresh installs nor honors it on upgrades). Enrico From jspaleta at gmail.com Sun Jan 23 04:42:02 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 22 Jan 2005 23:42:02 -0500 Subject: further package removals/potential package removals In-Reply-To: <41F30E60.5050605@nc.rr.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> Message-ID: <604aa79105012220422a3f4b48@mail.gmail.com> On Sat, 22 Jan 2005 21:39:28 -0500, Jeff Johnson wrote: > "dependency clutter" presumes that dependencies are arbitrarily designed to > decrease the quality of your life. > > That is not the case. > > Instead ... > ... nautilus "needs" samba much likes it needs just about every other > bleeping library > in FC4. Why? Because users want "features", and features requires > implementations, > usually in libraries, which use sonames, which are copied into package > dependencies. Taking a quick peek at the specific nautilus issue raised. The nautilus's rpms dependancy on the package samba-common is actually the result of an explicit requires for 'gnome-vfs2-smb.' and not a hard library dependancy. gnome-vfs2-smb package requires samba-common through a library dep libsmbclient.so.0 However, nautilus requires gnome-vfs2-smb though an explicit requires on gnome-vfs2-smb, a decision made by the packager to ensure that the runtime detectable smb support is always available when nautilus is installed to provide a perfectly reasonable and recommended default behavior for the average gnome desktop user. Some would argue doing this is bending the purpose of 'requires' field out of necessity to be used as a 'suggests' or 'recommends' field which rpm doesn't yet have support for. I was able to rebuild nautilus with the explicit requires on gnome-vfs2-smb turned off, which allowed me to remove samba-common without removing a cascade of gnome components. I did this just as a double-check to make sure my reading of the deptree was correct. samba-common now requires the removal of: authconfig-gtk, firstboot, gnome-vfs2-smb and samba-client. Clearly this is an example of the tension between providing reasonable default/recommended featureset and providing a measure of flexibility for more advanced users and system admins to control which run-time detectable features are available on their systems. If rpm had a 'suggests' or 'recommends' tag which could be used for such recommended but runtime detectable options, that would change the dynamic of this tension greatly. But I am unqualified to comment on whether or not the flexibility gain worth the effort to implement this in rpm. I will say that I can imagine situations where corporate network admins might not want to have the smb support in their linux desktop installs, so maybe there is a compelling business interest for red hat to make it easier for those network admins to decide whether they need that gnome-vfs2-smb feature on the system without recompiling nautilus for themselves. -jef From n3npq at nc.rr.com Sun Jan 23 04:53:12 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sat, 22 Jan 2005 23:53:12 -0500 Subject: further package removals/potential package removals In-Reply-To: <87acr0dcvc.fsf@londo.ultra.csn.tu-chemnitz.de> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <87acr0dcvc.fsf@londo.ultra.csn.tu-chemnitz.de> Message-ID: <41F32DB8.20409@nc.rr.com> Enrico Scholz wrote: >Jamie Zawinski writes: > > > >>For example: I don't use Windows, ever. This means I don't use Samba. >>But I can't uninstall it, because Nautilus depends on it. Now, I don't >>use Nautilus either, but I can't just uninstall *that*, because >>control-center depends on it, which I *do* use. >> >> > >ACK; some packages should be split to avoid such dependencies. 'gnupg' >(which brings 'perl' and 'openldap' into the game (additional 50MB)) and >'kernel' (which wastes 30MB and 6000 inodes of my /) are packages coming >at first into my mind... > > > ACK ACK: packages should be split, dependencies (at least those that are automagically generated, the majority these days) are not the problem. > > >>If space is tight, the first thing I do is nuke everything except en_US >>under /usr/share/locale/ and /usr/lib/locale/ >> >> > >Just do 'echo "%_install_langs C:en" >>/etc/rpm/macros' and reinstall >everything (as anaconda neither sets it on fresh installs nor honors it >on upgrades). > > Yep. And no matter what (fairly arcane and obscure) flaws there are %_netsharedpath /usr/share/doc is at least as good a solution as cd /usr/share/doc rm -rf * for preventing files from being installed in /usr/share/doc. Assuming that is what you want to do. 73 de Jeff > > >Enrico > > > From rc040203 at freenet.de Sun Jan 23 05:04:26 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 23 Jan 2005 06:04:26 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106453486.4591.24.camel@stargrazer.home.awesomeplay.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106453486.4591.24.camel@stargrazer.home.awesomeplay.com> Message-ID: <1106456666.7211.532.camel@mccallum.corsepiu.local> On Sat, 2005-01-22 at 23:11 -0500, Sean Middleditch wrote: > On Sun, 2005-01-23 at 04:59 +0100, Ralf Corsepius wrote: > > On Sat, 2005-01-22 at 12:01 -0500, Alan Cox wrote: > > > > > Possibly joe also ought to go to extras nowdays. > > Is there any wordstar compatible editor in Core? > > > > To me, seeing joe removed would be a severe regression. >15 years of > > using wordstar compatible editors can't simply be ignored. > > So install it from Extras. It's preclusion from Core will not cause a > retroactive obliteration of every copy of joe in the known world, nor > hinder you in the least from installing it whenever you want from > Extras. You are missing my point: Which packages to go into Core is subject of personal perspective/perception. FC contains a lot of packages I don't have much use for or care much about, unless they conflict or cause damage. For those, I don't really care much about whether they are part of Core or Extras. However, one minimal requirement I impose on a distribution is having a wordstar compatible editor. Therefore to me, removing "joe" from Core without substitute, is more than "substituting on package by another", it is crippling the distribution. To put the other way round: How you would feel if somebody proposes to remove vi or emacs without substitute? That's the situation I am facing. > Why is this not getting through to people? Is "extras" a synonym for > "/dev/null" in half the world or something? ;-) Before it is implemented, to some extend yes ;-) Of cause extras is not a synonym of /dev/null! It's just that removing joe from Core to me means FC is going to deviate from my demands and therefore means a step towards becoming less attractive. Ralf From felipe_alfaro at linuxmail.org Sun Jan 23 05:05:02 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sun, 23 Jan 2005 06:05:02 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106453309.4591.20.camel@stargrazer.home.awesomeplay.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106410993.15391.42.camel@jdub.homelinux.org> <200501231136.22648.symbiont@berlios.de> <604aa79105012220026740af36@mail.gmail.com> <1106453309.4591.20.camel@stargrazer.home.awesomeplay.com> Message-ID: <56A1B454-6CFC-11D9-86B4-000D9352858E@linuxmail.org> On 23 Jan 2005, at 05:08, Sean Middleditch wrote: > On Sat, 2005-01-22 at 23:02 -0500, Jeff Spaleta wrote: >> A more advanced one CD bootstrap that gives you a usable desktop is a >> tough target to meet. I don't want to see the rescue environment >> being ditched to make room for a 1 CD desktop install. I think its >> vitally important to keep a usable rescue mode available as part of >> every self-contained piece of install media that's going to be >> offered. > > Not to start a completely different flame war, but... Ubuntu seems to > manage both a single CD install and a usable rescue mode. I have not > actually used Ubuntu, so I don't know exactly *how* usable the rescue > mode is, but the docs indicate it's there and can do a thing or two. > ;-) Ubuntu for x86 is two CD's: one is x86 install and the other one is x86 Live CD. I'm not 100% sure, but I think only x86 Live CD can be used as a rescue CD but x86 install not. From n3npq at nc.rr.com Sun Jan 23 05:07:01 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sun, 23 Jan 2005 00:07:01 -0500 Subject: further package removals/potential package removals In-Reply-To: <87651odavq.fsf@londo.ultra.csn.tu-chemnitz.de> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <41F313F7.7679D847@jwz.org> <41F319D2.6080303@nc.rr.com> <87651odavq.fsf@londo.ultra.csn.tu-chemnitz.de> Message-ID: <41F330F5.2020001@nc.rr.com> Enrico Scholz wrote: >Jeff Johnson writes: > > > >>>If you think that the fact that Nautilus has a lot of "features" means >>>that it's necessary for it to cause the entire desktop as a single >>>unsplittable ball of mud, well, you have been misinformed. >>> >>> >>By George, I think he's got it! The point is that dependencies are not >>the problem, >> >> > >The gnupg -> (perl,openldap) deps *are* a problem, because they are not >needed for the gnupg core functionality but only for two extra programs, >which are unused on most systems. > > > > >>bloat is. >> >> > >Yes, the stupid kernel packaging which brings 30 MB of bloat into / is a >problem also. But nevertheless, the deps should be cut. A candidate would >be 'pam' which brings 'glib2' in, or all the packages with 'Requires: >kernel>=2.6' which should be either removed or rewritten to 'Conflicts: >kernel<2.6'. > > Perhaps. The rationale for preferring Requires: rather than Conflicts: is that depsolvers have a Will an upgrade "fix" a dependency problem? but do not have a similar, widely deployed, policy for Conflicts: afaik. Well, apt does, and perhaps smartpm, but let's not go there ... > > > >>No, choosing locales is an install option that applies to binary >>options that is anaconda selectable, >> >> > >I might be wrong (I do not have time to verify it now) but afair, on my >last FC3 installation, the language selection in anaconda had no influence >on %_install_langs but sets some value in /etc/sysconfig/i18n only. > > If true, then it's a bug in anaconda, which does permit selection of desired locales, and has attempted to limit the number of installed locales in the past. > > > >>>>Try --excludedocs, been in rpm for years. >>>> >>>> >>>I must have overlooked the Anaconda checkbox that turns that on. And >>>the "yum update" option, too. >>> >>> >>So make an RFE. >> >> > >Has probably only a small chance of success. 'anaconda' will follow more >and more the Gnome UI guidelines so that there is no room for useful >features. Existing ones like package selection or detailed progress >reports were removed already. > > > Predciting the future without attempting an RFE is pointless blather. Not that you haven't made many reasonable RFE's over the years ... > > >>The mechanism exists even if anaconda and yum choose not to use >>--excludedocs. The mechanism is also globally configurable, put >> %_netsharedpath /usr/share/doc >> >> > >mmmh... %_netsharedpath... we had a lot of fruitless discussions about >this so I wonder that you mention it here ;) > >It has serious implementation flaws (infection of parent paths; bug >#52725 lasts for >3 years in bugzilla) and there does not exist a >mechanisms to test it in %scriptlets (which causes problems e.g. in >all the java packages). > >Using %_netsharedpath to disable installation of certain files is not a >good idea. E.g. files in /usr/share/doc are required by cups for its >web-frontend. %_netsharedpath is for situations where the files exist >but are managed externally. > > Yep, all well known. %_netsharedpath is a naive mechanism. OTOH, %_netsharedpath *will* prevent /usr/share/doc from being populated, and the "infection" you speak of, for an empty /usr/share/doc directory, is irrelevant on this thread. > > > >>in /etc/rpm/macros. >> >> > >anaconda does not honor any previous rpm setting. Partially, this is >caused by rpm which makes it really difficultly to override paths of its >configuration. > > Actually, I suspect the problem is that anaconda may be carrying a canned configuration into an empty chroot that is difficult to configure. All paths in rpm are changeable through appropriate configuration, difficulty is in the eye of the beholder. 73 de Jeff From symbiont at berlios.de Sun Jan 23 06:08:36 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sun, 23 Jan 2005 14:08:36 +0800 Subject: further package removals/potential package removals In-Reply-To: <20050123043609.GC1420188@hiwaay.net> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106453486.4591.24.camel@stargrazer.home.awesomeplay.com> <20050123043609.GC1420188@hiwaay.net> Message-ID: <200501231408.37051.symbiont@berlios.de> On Sunday 23 January 2005 12:36, Chris Adams wrote: > In any case, until Fedora Extras fully materializes, I think it is a > moot point. ?I would like to see a release with FC and FE released at > the same time (with FE being based on the current "pre-Extras") and > FE fully operational _before_ packages start migrating from Core to > Extras. +1 -- -jeff From elanthis at awesomeplay.com Sun Jan 23 06:13:45 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Sun, 23 Jan 2005 01:13:45 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <56A1B454-6CFC-11D9-86B4-000D9352858E@linuxmail.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106410993.15391.42.camel@jdub.homelinux.org> <200501231136.22648.symbiont@berlios.de> <604aa79105012220026740af36@mail.gmail.com> <1106453309.4591.20.camel@stargrazer.home.awesomeplay.com> <56A1B454-6CFC-11D9-86B4-000D9352858E@linuxmail.org> Message-ID: <1106460826.4591.30.camel@stargrazer.home.awesomeplay.com> On Sun, 2005-01-23 at 06:05 +0100, Felipe Alfaro Solana wrote: > Ubuntu for x86 is two CD's: one is x86 install and the other one is x86 > Live CD. I'm not 100% sure, but I think only x86 Live CD can be used as > a rescue CD but x86 install not. No, I wasn't talking about the Live CD. Further reading indicates that the rescue mode is only part of the Hoary pre-release CDs, and not part of the stable Warty release, which is the only CD I have to play with. That said, I'm pretty sure the secret is to just keep cutting down the distro enough. Jeff is afraid that a one-CD install disk won't leave from for a rescue - that would happen only if you can manage to get a good desktop install into ~650MB but no less. Evidence indicates that you can in fact get smaller than that with a desktop install. I suppose one of Ubuntu's tricks is to just not include KDE, though... (They include it in Universe or Supported, which are similar to Fedora's Extras, only split between unofficial and official extra packages, respectively.) From fedora-devel at tlarson.com Sun Jan 23 05:13:27 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Sat, 22 Jan 2005 22:13:27 -0700 Subject: further package removals/potential package removals In-Reply-To: <604aa79105012220422a3f4b48@mail.gmail.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> Message-ID: <41F33277.4080102@tlarson.com> Jeff Spaleta wrote: > gnome-vfs2-smb package requires samba-common through a library dep > libsmbclient.so.0 > However, nautilus requires gnome-vfs2-smb though an explicit requires > on gnome-vfs2-smb, a decision made by the packager to ensure that the > runtime detectable smb support is always available when nautilus is > installed to provide a perfectly reasonable and recommended default > behavior for the average gnome desktop user. Some would argue doing > this is bending the purpose of 'requires' field out of necessity to > be used as a 'suggests' or 'recommends' field which rpm doesn't yet > have support for. The problem here is that the "recommended default" then becomes a forced necessity. Suddenly, instead of a cool feature, you've got bloat. "Defaults" should be handled by anaconda, not RPM. In the absence of a more elegant way of "recommending" a package other than with a dependancy, the recommendation should simply be left off. If you're going to require an add-on package, then there's really no point to putting it in a separate package anyway. The whole situation is nonsense, really. But then, this isn't the first time we've had this discussion. However, certain key individuals are convinced that things are fine the way they are, and need no fixing. Yes, dependacy bloat is a problem, but it's not going to be fixed until the responsible persons are convinced that a problem actually exists. From hp at redhat.com Sun Jan 23 06:30:29 2005 From: hp at redhat.com (Havoc Pennington) Date: Sun, 23 Jan 2005 01:30:29 -0500 Subject: further package removals/potential package removals In-Reply-To: <20050123041600.GB1420188@hiwaay.net> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <20050123041600.GB1420188@hiwaay.net> Message-ID: <1106461830.29183.183.camel@localhost.localdomain> On Sat, 2005-01-22 at 22:16 -0600, Chris Adams wrote: > > nautilus has an explicit dependency in the spec file on gnome-vfs2-smb. > It does not have any apparent dependency on libsmb.so that is provided > by gnome-vfs2-smb (nothing seems to have such a dependency). If I don't > have any need to browse Windows networks, why do I need the software > installed? libsmb.so is dlopen'd, so no ldd dependency. > Features are great; _required_ features are not. The reason for a Requires here (and in similar cases) is to suck in gnome-vfs2-smb when anaconda upgrades a system. Comes up with some package in most releases, and there are a fair number of Requires: that exist purely for that reason. Havoc From russell at coker.com.au Sun Jan 23 07:34:40 2005 From: russell at coker.com.au (Russell Coker) Date: Sun, 23 Jan 2005 18:34:40 +1100 Subject: Fedora Core 4 In-Reply-To: <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> References: <20050114223020.GA7168@nostromo.devel.redhat.com> <1105803157.17503.2.camel@stargrazer.home.awesomeplay.com> Message-ID: <200501231834.43110.russell@coker.com.au> On Sunday 16 January 2005 02:32, Sean Middleditch wrote: > On Sat, 2005-01-15 at 17:29 +0530, Rahul Sundaram wrote: > > > - SELinux Episode III: Revenge of the AVC > > > > how about gui integration with gnome by letting nautllus show security > > contexts and manipulate them using chcon, fixfiles etc as the backend. > > That sounds like a pretty bad idea in general, actually - the last thing > you need is for the state of your file contexts to ever get out of sync Launching fixfiles at the request of the user is certainly a bad idea. But allowing the user to use a GUI to see the context (equivalent of "ls -Z") and change the context (equivalent of "chcon") would be handy and not cause any security issues. Generally it's nice to allow people to perform all user actions through a GUI that they can do through the command-line. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From rc040203 at freenet.de Sun Jan 23 08:30:15 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 23 Jan 2005 09:30:15 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106408277.15391.17.camel@jdub.homelinux.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> Message-ID: <1106469019.7211.567.camel@mccallum.corsepiu.local> On Sat, 2005-01-22 at 09:37 -0600, Josh Boyer wrote: > On Sat, 2005-01-22 at 16:09 +0530, Rahul Sundaram wrote: > > Hi > > > > > > > > > > no. fvwm2 is not a typical DE. > > > X+fvwm2 had been the Linux standard desktop environment for many, many > > > years and is still being used by more folks that you might assume. > > > > its not the default DE nor part of fedora at all now. > > No, it's not and I'm not advocating that it should be. It was just a > "devils advocate" type of statement. Right. Besides this, those who'll need it will know how to install it. > > > Despite some folke here don't seem to get tired to reiterate this idea, > > > I have to object: That won't be better, It's naive to move KDE out of > > > Core. > > > > I dont see any technical objections here > > That's because it's not always a technical issue. It's about choice. Partially yes. But it's also a technical, a management and a political issue. Whether RH or Gnome folks like it or not, it is a matter of fact that KDE is a Linux Core technology, which can't be ignored by anybody, comprising Fedora and RH. Moving KDE to Extras would mean to close out any KDE application from Core. From a user's perspective this can't be in anybody's interest. Technically this would raise a lot of problems, esp. for KDE users (E.g. there would not be any konqueror, kdm until you get Fedora Extras). RH wants FE to be the a technology preview platform for their products. To achieve a better desktop integration they will have to take the lead in their desktop integration. IMO, until now, they did a pretty good job on that. Compare RH/Fedora's KDE/Gnome interaction with that of other distributions, and you'll probably understand what I am referring to. If RH moves KDE out of Core, this will set a "bad" political signal, which probably will be interpreted as "RH declaring war on KDE". This can't be in anybody's interest. Another aspect I consider to be naive is users believing into the community being able to provide "better KDE packages" than RH does. Experience tells, this won't work. > Now that's not to say that all the non-base KDE packages have to be > included with Core. I could see having kdegames, kdepim, kdemultimedia, > etc all in Extras. Same goes for the non-base GNOME packages as well. Fully agreed. One should try to reduce the number of desktop (both KDE and Gnome) *applications* in Core and move them to Extras. E.g. I would not be opposed to moving mozilla, thunderbird, evolution, openoffice, {k,x,g} to Extras, but their infrastructure should remain in Core. > If there isn't a desktop environment choice in the Core ISOs, then > people will either deal with it, or switch to a different distro. > Personally, I'd rather see more people come to Fedora. Exactly. Feeling disattracted from SuSE's Gnome integration was one of the main reasons, why I decided to switch to using RHL-8.0 after having used SuSE for ca. 8 years. Now I don't want to see Fedora falling into the same trap as SuSE did. Ralf From rahulsundaram at gmail.com Sun Jan 23 08:52:22 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sun, 23 Jan 2005 14:22:22 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <1106469019.7211.567.camel@mccallum.corsepiu.local> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106469019.7211.567.camel@mccallum.corsepiu.local> Message-ID: Hi > But it's also a technical, a management and a political issue. > > Whether RH or Gnome folks like it or not, it is a matter of fact that > KDE is a Linux Core technology, which can't be ignored by anybody, > comprising Fedora and RH. > nobody is proposing to *ignore* KDE. we are talking about moving KDE into extras. nobody is questioning the importance of KDE nor is anybody stating that KDE is not good software. > Moving KDE to Extras would mean to close out any KDE application from > Core. From a user's perspective this can't be in anybody's interest. its both in the users interest as well as in the interest of fedora project for having fedora *core* only provide the default stuff > Technically this would raise a lot of problems, esp. for KDE users (E.g. > there would not be any konqueror, kdm until you get Fedora Extras). if fedora installer (anaconda) provides a option to install stuff from extras and if a subset of fedora extras including KDE is provided as ISO images, would that satisfy you? > > RH wants FE to be the a technology preview platform for their products. > To achieve a better desktop integration they will have to take the lead > in their desktop integration. IMO, until now, they did a pretty good job > on that. Compare RH/Fedora's KDE/Gnome interaction with that of other > distributions, and you'll probably understand what I am referring to. they also had to suffer a lot of flames for doing this. see kde-redhat.sf.net for an effort to provide upstream packages removing the redhat integration bits. also, one of the integration efforts was moving the gnome panel to the bottom. this has already been reverted to the upstream default. so fedora is already moving in the direction of having upstream supply whatever integration is required. if you are interested then take a look at freedesktop.org. thats where integration work belongs and *not* just redhat > > If RH moves KDE out of Core, this will set a "bad" political signal, > which probably will be interpreted as "RH declaring war on KDE". > This can't be in anybody's interest. you are over dramatising this. again if anaconda and kickstart provides an easy way to install stuff from fedora extras this point becomes moot IMO > Experience tells, this won't work. why not?. > > If there isn't a desktop environment choice in the Core ISOs, then > > people will either deal with it, or switch to a different distro. > > Personally, I'd rather see more people come to Fedora. no. they wouldnt switch if making the choice is easy > Exactly. Feeling disattracted from SuSE's Gnome integration was one of > the main reasons, why I decided to switch to using RHL-8.0 after having > used SuSE for ca. 8 years. thats because suse allegedly did a poor job. someone else stepped up to provide upstream gnome packages for GNOME http://usr-local-bin.org/rpms/usr-local-bin.php this is similar to the kde-redhat.sf.net effort. so instead of having two different teams repackaging the same thing, we invite the kde-redhat.sf.net team and others to step up and maintain the packages in fedora extras by staying close to upstream -- Regards, Rahul Sundaram From czar at czarc.net Sun Jan 23 09:13:23 2005 From: czar at czarc.net (Gene C.) Date: Sun, 23 Jan 2005 04:13:23 -0500 Subject: further package removals/potential package removals In-Reply-To: <20050123043609.GC1420188@hiwaay.net> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106453486.4591.24.camel@stargrazer.home.awesomeplay.com> <20050123043609.GC1420188@hiwaay.net> Message-ID: <200501230413.23380.czar@czarc.net> On Saturday 22 January 2005 23:36, Chris Adams wrote: > Once upon a time, Sean Middleditch said: > > So install it from Extras. It's preclusion from Core will not cause a > > retroactive obliteration of every copy of joe in the known world, nor > > hinder you in the least from installing it whenever you want from > > Extras. > > > > Why is this not getting through to people? Is "extras" a synonym for > > "/dev/null" in half the world or something? ;-) > > Just because _you_ don't think it should be in Core doesn't mean that it > in fact should be removed. Why do you think you get to dictate what > gets moved to Extras and anyone that disagrees with you is wrong? > > To quote from the Fedora website: > > Objectives of Fedora Core: > 1. Create a complete general-purpose operating system with > capabilities equivalent to competing operating systems, built for > and by a community -- those who not only consume, but also produce > for the good of other community members. > ... > 8. Include a range of popular packages, beyond those included in Red > Hat's commercially supported products. (Limited, of course, to > packages that Red Hat can legally provide; also limited to quality > packages as defined by our standards.) > > These are objectives of Fedora _Core_, not Fedora Extras. > > Do "competing operating systems" include joe? I would say yes; joe has > been included in most Linux distributions for years. If you install the > Solaris 9 "Sun Freeware" collection, you get joe. > > Is it a popular package? It sounds like it. > > Is it already included in Red Hat's commecially support products? It is > in RHEL 3. > > In any case, until Fedora Extras fully materializes, I think it is a > moot point. I would like to see a release with FC and FE released at > the same time (with FE being based on the current "pre-Extras") and FE > fully operational _before_ packages start migrating from Core to Extras. > We need to see how well FE really works before pushing a bunch of > packages out of FC. I think we also need anaconda to handle installing > from FE ISOs during install to make things as seamless as possible. Agree! Agree! With all of this discussion of moving packages from Core to Extras, I thought I better take another look at Extras (last time I looked, Extras for FC3 was empty). So there is now an Extras for FC3 ... BUT where are the corresponding SRPMS??!! Let me go further and say that if Fedora Extras is to be the "partner" of Fedora Core, then it should be on the same mirrors as Fedora Core. I am not sure what a good structure should be but the Fedora directory tree should inlcude a Core branch and an Extras branch. -- Gene From czar at czarc.net Sun Jan 23 09:56:30 2005 From: czar at czarc.net (Gene C.) Date: Sun, 23 Jan 2005 04:56:30 -0500 Subject: further package removals/potential package removals In-Reply-To: <855C1D68-6CE1-11D9-86B4-000D9352858E@linuxmail.org> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <855C1D68-6CE1-11D9-86B4-000D9352858E@linuxmail.org> Message-ID: <200501230456.30391.czar@czarc.net> On Saturday 22 January 2005 20:53, Felipe Alfaro Solana wrote: > On 22 Jan 2005, at 20:39, Peter Backlund wrote: > > This discussion is turning a bit absurd, imo. Just because a package is > > lifted out of Core doesn't mean it will vanish from the face of the > > earth. You can still install it from Extras if you need it. > > I think what some people is discussing here is not the fact that some > packages will end up in Core or Extras repository: it's the fact that > Anaconda installer should allow to install packages from the Extras > repository easily and automatically, if told so, as it is able to > install packages from the Core repository. > > Particularly, I don't mind if KDE, XFCE or whatever ends up in the > Extras repository, but I want to be able to install Fedora Core 4 and > install packages from both Core and Extras in a single pass, during the > installation process. Also, I do want packages in the Extras repository > to be maintained and be bound to the same QA process as Core packages. I disagree here that it should all be under anaconda. If Core is really small (no nedit, no KDE, no mysql, no postgresql, etc.) but then during firstboot I can add what I want from Extras. And yes, there should be iso images of Extras cut when the Core is cut. And yes, when Core goes "gold", there is a gold version of Extras. Handling of updates for Extras is another consideration ... like Core (with base and updates) or just make it the latest (like development). -- Gene From ville.skytta at iki.fi Sun Jan 23 09:59:01 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 23 Jan 2005 11:59:01 +0200 Subject: further package removals/potential package removals In-Reply-To: <200501230413.23380.czar@czarc.net> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106453486.4591.24.camel@stargrazer.home.awesomeplay.com> <20050123043609.GC1420188@hiwaay.net> <200501230413.23380.czar@czarc.net> Message-ID: <1106474341.18887.101.camel@bobcat.mine.nu> On Sun, 2005-01-23 at 04:13 -0500, Gene C. wrote: > With all of this discussion of moving packages from Core to Extras, I thought > I better take another look at Extras (last time I looked, Extras for FC3 was > empty). So there is now an Extras for FC3 ... BUT where are the > corresponding SRPMS??!! The content in download.fedora.us is just a mirror primarily for the benefit of apt users. The pre-extras master site has the source RPMS, see http://fedoraproject.org/pre-extras/3/, i386/srpms, and x86_64/srpms. No, I don't know why it was made this way, and I hope it's a temporary arrangement that will change in the near future (meaning both availability of the SRPMS in the fedora.us mirror as well as moving the SRPMS into a dir where users expect to see them in the master). > Let me go further and say that if Fedora Extras is to be the "partner" of > Fedora Core, then it should be on the same mirrors as Fedora Core. I am not > sure what a good structure should be but the Fedora directory tree should > inlcude a Core branch and an Extras branch. This is being worked on. From rdieter at math.unl.edu Sun Jan 23 10:23:45 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 23 Jan 2005 04:23:45 -0600 (CST) Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106469019.7211.567.camel@mccallum.corsepiu.local> Message-ID: On Sun, 23 Jan 2005, Rahul Sundaram wrote: >> Moving KDE to Extras would mean to close out any KDE application from >> Core. From a user's perspective this can't be in anybody's interest. > > its both in the users interest as well as in the interest of fedora > project for having fedora *core* only provide the default stuff Who is saying the the "default stuff" can't include any kde (or even qt?) applications or integration? Gone will be ooo-kde, Bluecurve-kde (redhat-artwork), and anything else that uses qt/kdelibs *at all*. > they also had to suffer a lot of flames for doing this. see > kde-redhat.sf.net for an effort to provide upstream packages removing > the redhat integration bits. Correction: kde-redhat is primarily about adding features that redhat (purposely or not) doesn't include. We're doing our best to get many of these mods accepted upstream by redhat (see bugzilla.redhat.com's #121769, #121769, #136533; bugzilla.fedora.us's #1904) Other goals had included removing the (hard) dependancies on redhat-artwork and redhat-menus, which could be considerred "removing redhat integration bits)". These last 2 goals have, for the most part, been dropped, since 1. it is now pretty much impossible to have a redhat-artwork-free system (though we still remove the hard Requires: redhat-artwork from kdebase, much good that does) 2. redhat-menus has gotten good enough (*), IMO, so providing an alternative kde-menus isn't worth the extra hassle (*) except for http://bugzilla.redhat.com/bugzilla/122181 >> If RH moves KDE out of Core, this will set a "bad" political signal, >> which probably will be interpreted as "RH declaring war on KDE". >> This can't be in anybody's interest. > > you are over dramatising this. IMO, no. The perception from many people will be *exactly* that RH has declared all-out war on KDE, true or not. Everyone, please stop the mere suggestion of removing KDE from Core, at least not in the near future... until there is very tight integration with Extras. When/If that happens first, only then the possibility of discussing it is an option. -- Rex From arjanv at redhat.com Sun Jan 23 10:31:59 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 23 Jan 2005 11:31:59 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106469019.7211.567.camel@mccallum.corsepiu.local> Message-ID: <1106476319.6129.5.camel@laptopd505.fenrus.org> > IMO, no. The perception from many people will be *exactly* that RH has > declared all-out war on KDE, true or not. > > Everyone, please stop the mere suggestion of removing KDE from Core, at > least not in the near future... that sounds almost like Fedora is taken hostage... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rahulsundaram at gmail.com Sun Jan 23 10:31:55 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sun, 23 Jan 2005 16:01:55 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106469019.7211.567.camel@mccallum.corsepiu.local> Message-ID: Hi > > Correction: kde-redhat is primarily about adding features that redhat > (purposely or not) doesn't include. > > Other goals had included removing the (hard) dependancies on > redhat-artwork and redhat-menus, which could be considerred "removing > redhat integration bits)". yes. thats what I was talking about. its not a negative remark on anyone though. Just emphasising that integration bits are better done upstream instead of by invidual distributions > IMO, no. The perception from many people will be *exactly* that RH has > declared all-out war on KDE, true or not. I dont think so. it depends on how easy it is to add KDE. has the perception been that ubuntu has declared war on KDE?. > > Everyone, please stop the mere suggestion of removing KDE from Core, at > least not in the near future... until there is very tight > integration with Extras. for your information we are not just discussing moving KDE to extras but also other packages. we are also discussing how much integration with extras is necessary and the methodology to do it. so asking everyone to stop discussing these issues is IMO ill advised -- Regards, Rahul Sundaram From n3npq at nc.rr.com Sun Jan 23 11:16:59 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sun, 23 Jan 2005 06:16:59 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106461830.29183.183.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <20050123041600.GB1420188@hiwaay.net> <1106461830.29183.183.camel@localhost.localdomain> Message-ID: <41F387AB.4060604@nc.rr.com> Havoc Pennington wrote: >On Sat, 2005-01-22 at 22:16 -0600, Chris Adams wrote: > > >>nautilus has an explicit dependency in the spec file on gnome-vfs2-smb. >>It does not have any apparent dependency on libsmb.so that is provided >>by gnome-vfs2-smb (nothing seems to have such a dependency). If I don't >>have any need to browse Windows networks, why do I need the software >>installed? >> >> > >libsmb.so is dlopen'd, so no ldd dependency. > > And so the problem really is too many dependencies, or -- alternatively expressed -- too few sonames. Perhaps Requires: libsmbclient.so.0 is perhaps a more obvious statement of the dependency. Not that the mode of expression really matters, nautilus has way way too many dependencies. > > >>Features are great; _required_ features are not. >> >> > >The reason for a Requires here (and in similar cases) >is to suck in gnome-vfs2-smb when anaconda upgrades >a system. > > Yep. Or anaconda might, perhaps, someday, wish to actually run nautilus at install/erase time, and so the dependency is added as a place holder, reserving a bloat slot for future development. Seriously, dependencies have a context, and it's highly unlikely that the dependency is actually needed by anaconda to install or remove nautilus. The hint to depsolvers like anaconda necessary with current implementations to discover an additional edge in the dependency tree graph could be handled in other ways, if nautilus were prepared to deal with the dlopen failure at run-time. >Comes up with some package in most releases, and there >are a fair number of Requires: that exist purely for >that reason. > > Yep. Existence of other examples does not imply that dlopen'd module dependencies necessarily have to be expressed as a Requires: however. The current practice of using a manual Requires: to hint of an edge on a dependency graph has the side affect of forcing packages to be installed whose contents may never be used. A "missingok" (or "dlopen") context marker on a Requires: would provide the hint of an edge in the dependency graph to existing depsolvers, and yet mark the context of the dependency as "optional" in the sense that an application like nautilus was prepared to deal with a dlopen failure from libsmbclient.so.0 at run-time, rather than during install/erase. The net effect of a "missingok" (or "dlopen") context marker would be that nautilus could be installed without dragging in the samba sub-tree, with similar effect for other dlopen'd modules. 73 de Jeff From Axel.Thimm at ATrpms.net Sun Jan 23 11:11:51 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 23 Jan 2005 12:11:51 +0100 Subject: kernel-devel: should yum install, not update? In-Reply-To: <41F32901.7080003@insitesinc.com> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> <20050123003639.GA28104@redhat.com> <41F32901.7080003@insitesinc.com> Message-ID: <20050123111151.GB31380@neu.nirvana> On Sat, Jan 22, 2005 at 10:33:05PM -0600, Michael Favia wrote: > Dave Jones wrote: > > On Sat, Jan 22, 2005 at 03:22:53PM -0500, Jeff Spaleta wrote: > > > > > Providing 'kernel-modules' on the other hand... i don't think anything > > > requires 'kernel-modules' so it might be okay to make kernel-devel > > > provide that but i still seems to me like potential double-meaning to > > > what 'kernel-modules' means since kernel-devel doesnt actually include > > > a single kernel-module. > > > > > > Maybe Dave Jones can be poked into making a comment about this. > > > > Adding either of the provides seems like a rather ugly hack. > > up2date already has the smarts to installonly the -devel package, > > so I'm of the opinion yum should be fixed to do the right thing too. > > Jeremy is rebuilding yum as I type for tomorrows rawhide to > > take care of this issue. > > Yes but the real question is "Where does this information belong?" I > dont think that these things should be managed ad-hoc by each competing > package manager but instead internalized into the packages themselves > somehow for scalabiltiy and adaptability purposes. It has often been suggested to add a new rpm tag for this purpose. E.g. you could have UpdateMode: (installation|alwaysupgrade) or AutoUpgrade: no rpm 4.4 would be a good candidate to get this in. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Nicolas.Mailhot at laPoste.net Sun Jan 23 11:43:03 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 23 Jan 2005 12:43:03 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106446332l.21465l.0l@devel.mpeters.us> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <1106446332l.21465l.0l@devel.mpeters.us> Message-ID: <1106480583.6306.34.camel@rousalka.dyndns.org> Le dimanche 23 janvier 2005 ? 02:12 +0000, Michael A. Peters a ?crit : > IMHO it should be easy for an OEM to start with a smaller base, rip > either KDE or GNOME out (depending upon what their staff is trained > in), rip the dev tools out, add some patented stuff (like GStreamer > plugins from fluendo or whoever) and have well under a gig of packages. > > They can do that now, but it is harder because there is a lot more to > sift through. What I want (and at at a point anaconda was real close to providing this) is the following process : 1. boot on the first FC or RHEL disk 2. have an alphabetical list of the packages available where I can check the core packages I need 3. have anaconda compute the deps of my core packages, and propose either to pull all of them or let me review them one by one (ie display a list of all the packages it wants to pull in, with the following info for each of those packages: disk number, all the core dep chains that pull it in, summary) 4. maybe a screen with package suggestions (new stuff in this release that's great to have, optional plugins for the stuff I selected) 5. save the resulting ks on floppy or usb flash 6. ability to have the next anaconda release read this ks and restart the selection process from there Right now to achieve the same result you have to do a minimal install, copy the kickstart, manually rpm -e and yum install all the stuff you want, note all your ops and add th packages -packages to your ks copy, boot on it to test it, etc The in-system ks generator is a joke : 1. it's not clear on what steps/parameters are mandatory or not 2. it requires a system install just to generate the ks list 3. it requires the *same* system as the one you want to generate a ks for. Needless to say on even a small network after a few years you have to work with multiple RHEL/FC versions so do you really believe the admins will have a bow with each freaking distro release in just to manage their ks files (and that includes all the RHEL update releases, because the package set is not stable even in those!)? They may even not use a RHEL/FC box themselves ! The general RH bias is/was always to install more stuff when in doubt. Make all optional plugins mandatory via explicit deps. Dumb down anaconda so it's more difficult to trim the default rpm groups. Add a few deps instead of splitting a package when a new release ships a new utility that requires a behemot like openldap, mysql or perl. The result is the massive bloat we have today (just when flash-root systems like mini-itx boxes appear on the market). Plus all the anaconda tricks do not protect from yum installations, nor manual kickstarts, because people *want* to trim the installation and will even go to the package rebuild stage to get it. Really dependencies should be reviewed more carefully in the rawhide/FC beta stage and not worked around via massive package over-selection like it's the case now. Today it's gotten to the point that if one wanted to really untangle the mess it'd take at least two or three FC iterations IMHO. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Sun Jan 23 11:44:51 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 23 Jan 2005 12:44:51 +0100 Subject: further package removals/potential package removals In-Reply-To: <20050122165044.GE2898@devserv.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <1106406829.11656.7.camel@md.local.linuxlobbyist.org> <1106411727.8428.2.camel@jonspc> <20050122165044.GE2898@devserv.devel.redhat.com> Message-ID: <1106480691.6306.36.camel@rousalka.dyndns.org> Le samedi 22 janvier 2005 ? 11:50 -0500, Alan Cox a ?crit : > On Sat, Jan 22, 2005 at 04:35:28PM +0000, Jonathan Andrews wrote: > > > Er...why? Given the number of consumer devices these days that use > > > VFAT, I can't think of a reason why this would belong in Core. > > > > I second that why ? Every USB stick, camera or floppy disk owner will > > be cursing you. > > I'd second that. Its needed for so many things. Including kickstart floppies ;) Or does this work with ext2/3 disks ? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Sun Jan 23 11:50:15 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 23 Jan 2005 12:50:15 +0100 Subject: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106411409.8091.5.camel@one.myworld> <1106412786.4002.58.camel@bree.local.net> Message-ID: <1106481015.6306.40.camel@rousalka.dyndns.org> Le samedi 22 janvier 2005 ? 22:26 +0530, Rahul Sundaram a ?crit : > Hi > > . gcj is really coming along > > impressively in the things it can run now. > > yes. I am impressed on the recent developments on gcj,. that reminds > me is jonas going to be included in fc4? jonas-like package are a bitch to package because they depend on an lot of underlying java infrastructure. There are some jonas bits in jpackage, though I doubt there are tested enough to make in in FC yet. You can try them and give some feedback if you want to speed things up a bit. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From xose at wanadoo.es Sun Jan 23 11:53:03 2005 From: xose at wanadoo.es (Xose Vazquez Perez) Date: Sun, 23 Jan 2005 12:53:03 +0100 Subject: further package removals/potential package removals Message-ID: <41F3901F.5080202@wanadoo.es> hi guys, > Removed and orphaned: > asp2php - does not show any history of usage, not really a core package > > Suggested for removal: > > xloadimage > - there are better apps for displaying images (ImageMagick, > eog, gthumb, kview, etc) > - there are better apps for setting the root window (xsri) > - it's *ancient* code that doesn't even support PNG > nedit > - legacy interface (motif) > - doesn't support Unicode > jed > - doesn't support Unicode > > Opinions? I think that it's easiest to pick the core packages that to select it one by one to be in extras. the right question is: *What's CORE* ? From Nicolas.Mailhot at laPoste.net Sun Jan 23 12:01:52 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 23 Jan 2005 13:01:52 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <41F22A73.6080402@hhs.nl> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> <41F22A73.6080402@hhs.nl> Message-ID: <1106481712.6306.42.camel@rousalka.dyndns.org> Le samedi 22 janvier 2005 ? 11:26 +0100, Hans de Goede a ?crit : > > Paul Ionescu wrote: > > Hi, > > > > I am using right now PAN to send this message. > > Not because I don't want to use something else, but because other news > > programs don't have the functionality of pan yet. > > And is fast too, compared with other options. > > > > Thx, > > Paul > > > > I would like to give a vote for keeping pan in core too, and while we're > at it make it the default news program. pan is the best gui newsreader > for unix, so it deserves to be the default and its gnome, so it fits > well with Fedora's default desktop. +1 Pan was a great app before those alternatives, was one of the first apps to use GTK2, and is generally great (not that it wouldn't need some UI love now) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Sun Jan 23 12:11:48 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 23 Jan 2005 13:11:48 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106482308.6306.52.camel@rousalka.dyndns.org> Le vendredi 21 janvier 2005 ? 15:40 +0100, Enrico Scholz a ?crit : > peter.backlund at home.se (Peter Backlund) writes: > > >> emacs-21.3-20 > >> ------------- > > ... > > Any news on the Gtk Emacs front? > > I would not spend much energy on such a port. A Gtk port means AA > fonts which are really a bad choice for text based applications. A gtk port means fontconfig and AA ie all the users that do not use pure american files on a 75dpi screen can get some mileage out of emacs without ruining their eyes. fontconfig support is the single reason several people (including me) dumped emacs/xemacs altogether for vim/gvim recently. I'm amazed someone can maintain like you that fontconfig is a bad choice for text apps - surely an app that's devoted to displaying text is *more* sensitive to the text rendering tech than your average ogg player. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From josep at imatge-sintetica.com Sun Jan 23 12:17:15 2005 From: josep at imatge-sintetica.com (Josep Puigdemont) Date: Sun, 23 Jan 2005 13:17:15 +0100 Subject: FC4 with localized firefox (wishlist) Message-ID: <1106482635.6173.100.camel@localhost> Hi, Here it is my short wish list for FC4, if I may send one ;-) I don't know if this has been mentioned before or not, but I for one would like to see localized versions of Firefox for each installed language, by default. I don't know if that's technically very hard or not, though. It's a pity to install Fedora (FC3) in your language, and see that the most used application on the desktop is still in English (and Firefox is the default browser). This renders the desktop _unusable_ for many users, imho. A part from that, congratulations, and keep up the good work! /Josep From kyrre at solution-forge.net Sun Jan 23 12:21:12 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 23 Jan 2005 13:21:12 +0100 Subject: Power off In-Reply-To: <41F1BD6C.3000801@tlarson.com> References: <41F1BD6C.3000801@tlarson.com> Message-ID: <1106482853.2655.4.camel@localhost.localdomain> To me it sounds like its overheating. Does the fan start as it should to cool down the CPU, or is it all silent? What happens if you try to upgrade the BIOS again? Kyrre l?r, 22.01.2005 kl. 03.41 skrev Tyler Larson: > I ran into a problem (bug?) that I would like to help solve, but I'm at > a loss as to where to go next. My laptop (Dell C400) used to run Linux > just fine, dual boot with Windows. In the past few months, I've > installed XP SP2 on the Windows side, reinstalled Windows a few times > (it happens), and updated by BIOS image. I somehow managed to trash my > partition table attempting to put GRUB back as my bootloader, then had > to reinstall everything all over again (windows and Linux). I've since > downgraded the BIOS to the previous known-good version to try and fix > the thing. Windows works fine, but on the Linux side.... > > The computer powers itself off without warning--no matter what is, or > isn't, running. Certain things seem to trigger it, and it may be tied to > high CPU load. I can trigger the shutdown fairly reliably by running > aircrack on a packet capture file. To rule out any background services > as being the culprit, I booted with init=/bin/bash, ran aircrack, and > sure enough, it powered off after about 90 seconds. This behavior has > continued no matter what kernel I use--I'ved tried with both the > original FC3 kernel and the most recent one. In fact, the machine > powered itself down a number of times while I was running off the > install CD. It took 10 tries before I got it to complete the install > process. > > So, my question to you all is--how can I possibly get some useful > information to start diagnosing this problem? There's nothing in the > logs on disk, of course. There's no warning, no panic, no nothing. Just > a quick *plink* and it's gone. From rahulsundaram at gmail.com Sun Jan 23 12:22:38 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sun, 23 Jan 2005 17:52:38 +0530 Subject: FC4 with localized firefox (wishlist) In-Reply-To: <1106482635.6173.100.camel@localhost> References: <1106482635.6173.100.camel@localhost> Message-ID: On Sun, 23 Jan 2005 13:17:15 +0100, Josep Puigdemont wrote: > Hi, > > Here it is my short wish list for FC4, if I may send one ;-) > I don't know if this has been mentioned before or not, but I for one > would like to see localized versions of Firefox for each installed > language, by default. file a RFE against firefox in bugzilla.redhat.com -- Regards, Rahul Sundaram From kyrre at solution-forge.net Sun Jan 23 12:34:03 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 23 Jan 2005 13:34:03 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106446332l.21465l.0l@devel.mpeters.us> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <1106446332l.21465l.0l@devel.mpeters.us> Message-ID: <1106483643.2655.8.camel@localhost.localdomain> s?n, 23.01.2005 kl. 03.12 skrev Michael A. Peters: > On 01/22/2005 12:11:32 PM, Jeff Spaleta wrote: > > > > > If there is serious interest in slimming Core down.. then a decision > > has to be made to define a reference usage case or two so we can get > > past personal preference and make decisions based on the design needs > > of the usage case goal. If a reference usage case for Core is > > suppose > > to be a developer oriented workspace thats going to impact the > > decisions as to what is important to include. If a reference usage > > case for Core is suppose to be a desktop for the average human, > > that's > > going to impact the decisions in very different ways. If Core is > > suppose to provide both.. well guess what.. Core will continue to be > > 4+ CD images. > > I definitely want to see Fedora Core shrink. > I want to see Linux on the Desktop really take off - as in someday see > 20% or more marketshare. That only is going to happen with OEM's. > > Other than Apple users, most people I know use the version of the OS > that their PC ships with - they don't bother to buy updates let alone > other operating systems. Corporate desktop is different, there they run > whatever IT trusts - which also often is not latest. > > Anyway - to get Fedora on OEM's it has to be smaller because up the > cost of support - it's cheaper to train support staff for a smaller > base of software. > > IMHO it should be easy for an OEM to start with a smaller base, rip > either KDE or GNOME out (depending upon what their staff is trained > in), rip the dev tools out, add some patented stuff (like GStreamer > plugins from fluendo or whoever) and have well under a gig of packages. > > They can do that now, but it is harder because there is a lot more to > sift through. > Another reason to shrink core, is that a smaller core will make sure each package will get more developer time => higher quality of the "main" stuff. And by moving the more obscure packages into extras, that will make it possible for upstream developers themselves to actually take controll of their own packages (=> higher quality). From alan at redhat.com Sun Jan 23 12:47:52 2005 From: alan at redhat.com (Alan Cox) Date: Sun, 23 Jan 2005 07:47:52 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106452796.7211.491.camel@mccallum.corsepiu.local> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> Message-ID: <20050123124752.GA1974@devserv.devel.redhat.com> On Sun, Jan 23, 2005 at 04:59:56AM +0100, Ralf Corsepius wrote: > On Sat, 2005-01-22 at 12:01 -0500, Alan Cox wrote: > > Possibly joe also ought to go to extras nowdays. > Is there any wordstar compatible editor in Core? > > To me, seeing joe removed would be a severe regression. >15 years of > using wordstar compatible editors can't simply be ignored. Sure but those of use who've been using 15 plus years of w* compatible editors can probably work extras just fine From alan at redhat.com Sun Jan 23 12:51:51 2005 From: alan at redhat.com (Alan Cox) Date: Sun, 23 Jan 2005 07:51:51 -0500 Subject: further package removals/potential package removals In-Reply-To: <87651odavq.fsf@londo.ultra.csn.tu-chemnitz.de> References: <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <41F313F7.7679D847@jwz.org> <41F319D2.6080303@nc.rr.com> <87651odavq.fsf@londo.ultra.csn.tu-chemnitz.de> Message-ID: <20050123125151.GB1974@devserv.devel.redhat.com> On Sun, Jan 23, 2005 at 05:31:37AM +0100, Enrico Scholz wrote: > The gnupg -> (perl,openldap) deps *are* a problem, because they are not > needed for the gnupg core functionality but only for two extra programs, > which are unused on most systems. Agreed. I dislike having perl on systems I run because then people do disgusting things like use it. > problem also. But nevertheless, the deps should be cut. A candidate would > be 'pam' which brings 'glib2' in, or all the packages with 'Requires: glib2 is used by a lot of stuff nowdays because it provides stuff like real string libraries for C - its not too huge either > kernel>=2.6' which should be either removed or rewritten to 'Conflicts: > kernel<2.6'. Perhaps > I might be wrong (I do not have time to verify it now) but afair, on my > last FC3 installation, the language selection in anaconda had no influence > on %_install_langs but sets some value in /etc/sysconfig/i18n only. Correct nowdays. The big problem there is openoffice though > and more the Gnome UI guidelines so that there is no room for useful > features. Existing ones like package selection or detailed progress > reports were removed already. kickstart Alan -- "a complex, complicated design for some facility in a software or hardware product is usually not an indication of great skill and maturity on the part of the designer. Rather, it is typically evidence of lack of maturity, lack of insight, lack of understanding of the costs of complexity, and failure to see the problem in its larger context." -- Dan Murphy From alan at redhat.com Sun Jan 23 12:56:21 2005 From: alan at redhat.com (Alan Cox) Date: Sun, 23 Jan 2005 07:56:21 -0500 Subject: FC4 with localized firefox (wishlist) In-Reply-To: <1106482635.6173.100.camel@localhost> References: <1106482635.6173.100.camel@localhost> Message-ID: <20050123125621.GC1974@devserv.devel.redhat.com> On Sun, Jan 23, 2005 at 01:17:15PM +0100, Josep Puigdemont wrote: > I don't know if this has been mentioned before or not, but I for one > would like to see localized versions of Firefox for each installed > language, by default. Seconded. I've been moaning about this and mozilla for a long time 8) From enrico.scholz at informatik.tu-chemnitz.de Sun Jan 23 12:40:33 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 23 Jan 2005 13:40:33 +0100 Subject: further package removals/potential package removals In-Reply-To: <41F330F5.2020001@nc.rr.com> (Jeff Johnson's message of "Sun, 23 Jan 2005 00:07:01 -0500") References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <41F313F7.7679D847@jwz.org> <41F319D2.6080303@nc.rr.com> <87651odavq.fsf@londo.ultra.csn.tu-chemnitz.de> <41F330F5.2020001@nc.rr.com> Message-ID: <87zmz0b9oe.fsf@londo.ultra.csn.tu-chemnitz.de> Jeff Johnson writes: >>Partially, this is caused by rpm which makes it really difficultly to >>override paths of its configuration.> > > All paths in rpm are changeable through appropriate configuration, > difficulty is in the eye of the beholder. What would be the "appropriate configuration" to change the path of /etc/rpm/platform? Enrico From rdieter at math.unl.edu Sun Jan 23 13:30:26 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 23 Jan 2005 07:30:26 -0600 (CST) Subject: rawhide report: 20050121 changes In-Reply-To: <1106476319.6129.5.camel@laptopd505.fenrus.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87651q3e6g.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106469019.7211.567.camel@mccallum.corsepiu.local> <1106476319.6129.5.camel@laptopd505.fenrus.org> Message-ID: On Sun, 23 Jan 2005, Arjan van de Ven wrote: > >> IMO, no. The perception from many people will be *exactly* that RH has >> declared all-out war on KDE, true or not. >> >> Everyone, please stop the mere suggestion of removing KDE from Core, at >> least not in the near future... > > > that sounds almost like Fedora is taken hostage... Huh? You snipped off the part after ... saying "until Fedora Extras is integrated/ready", does that help? -- Rex From buildsys at redhat.com Sun Jan 23 13:32:47 2005 From: buildsys at redhat.com (Build System) Date: Sun, 23 Jan 2005 08:32:47 -0500 Subject: rawhide report: 20050123 changes Message-ID: <200501231332.j0NDWlO10835@porkchop.devel.redhat.com> Updated Packages: gcc-3.4.3-16 ------------ * Sat Jan 22 2005 Jakub Jelinek 3.4.3-16 - fix PRs middle-end/19551 * Tue Jan 18 2005 Jakub Jelinek 3.4.3-15 - add gcc-gnat and libgnat on ppc, x86_64 and ia64 again - fix Ada bootstrap problems on 64-bit architectures (PR ada/13470) - run ACATS tests under expect, so that if they hang, they'll be timed out * Fri Jan 14 2005 Jakub Jelinek 3.4.3-14 - update from gcc-3_4-branch - PRs bootstrap/18033, target/18987, target/18720, rtl-optimization/19012, rtl-opt/13299, rtl-opt/10692 - fix PRs c++/19263, rtl-optimization/16104, c/17297, middle-end/19164, rtl-optimization/15139, rtl-optimization/19348, middle-end/19084, java/17255 gcc4-4.0.0-0.21 --------------- * Sat Jan 22 2005 Jakub Jelinek 4.0.0-0.21 - update from trunk - fix PRs middle-end/19551, c/18946, c/19342 - allow REFERENCE_TYPEs in place of POINTER_TYPEs in builtins.c koffice-4:1.3.5-2 ----------------- * Sat Jan 22 2005 Than Ngo 4:1.3.5-2 - Apply patch to fix CAN-2005-0064 rpmdb-fedora-1:4-0.20050123 --------------------------- yum-2.1.12-3 ------------ * Sat Jan 22 2005 Jeremy Katz - 2.1.12-2 - allow multiple kernel-devel packages to be installed From rdieter at math.unl.edu Sun Jan 23 13:32:45 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 23 Jan 2005 07:32:45 -0600 (CST) Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106469019.7211.567.camel@mccallum.corsepiu.local> Message-ID: On Sun, 23 Jan 2005, Rahul Sundaram wrote: > >> IMO, no. The perception from many people will be *exactly* that RH has >> declared all-out war on KDE, true or not. > > I dont think so. it depends on how easy it is to add KDE. has the > perception been that ubuntu has declared war on KDE?. ubuntu != redhat, nor does it have a history. Apples/Oranges. >> Everyone, please stop the mere suggestion of removing KDE from Core, at >> least not in the near future... until there is very tight >> integration with Extras. > > for your information we are not just discussing moving KDE to extras > but also other packages. we are also discussing how much integration > with extras is necessary and the methodology to do it. so asking > everyone to stop discussing these issues is IMO ill advised I didn't say stop discussing integration with extras, did I? If I even implied that, I apologize. Please, please keep that part of the discussion going. -- Rex From rahulsundaram at gmail.com Sun Jan 23 13:33:17 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Sun, 23 Jan 2005 19:03:17 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106469019.7211.567.camel@mccallum.corsepiu.local> <1106476319.6129.5.camel@laptopd505.fenrus.org> Message-ID: Hi > > Huh? You snipped off the part after ... saying "until Fedora Extras is > integrated/ready", does that help? not really. read my reply -- Regards, Rahul Sundaram From n3npq at nc.rr.com Sun Jan 23 14:23:38 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sun, 23 Jan 2005 09:23:38 -0500 Subject: further package removals/potential package removals In-Reply-To: <87zmz0b9oe.fsf@londo.ultra.csn.tu-chemnitz.de> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <41F313F7.7679D847@jwz.org> <41F319D2.6080303@nc.rr.com> <87651odavq.fsf@londo.ultra.csn.tu-chemnitz.de> <41F330F5.2020001@nc.rr.com> <87zmz0b9oe.fsf@londo.ultra.csn.tu-chemnitz.de> Message-ID: <41F3B36A.6050107@nc.rr.com> Enrico Scholz wrote: >Jeff Johnson writes: > > > >>>Partially, this is caused by rpm which makes it really difficultly to >>>override paths of its configuration.> >>> >>> >>All paths in rpm are changeable through appropriate configuration, >>difficulty is in the eye of the beholder. >> >> > >What would be the "appropriate configuration" to change the path of >/etc/rpm/platform? > rm -f /etc/rpm/platform and live with uname(2) lies from the kernel. 73 de Jeff From kyrre at solution-forge.net Sun Jan 23 15:41:56 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 23 Jan 2005 16:41:56 +0100 Subject: further package removals/potential package removals In-Reply-To: <20050123125151.GB1974@devserv.devel.redhat.com> References: <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <41F313F7.7679D847@jwz.org> <41F319D2.6080303@nc.rr.com> <87651odavq.fsf@londo.ultra.csn.tu-chemnitz.de> <20050123125151.GB1974@devserv.devel.redhat.com> Message-ID: <1106494916.2655.12.camel@localhost.localdomain> > > I might be wrong (I do not have time to verify it now) but afair, on my > > last FC3 installation, the language selection in anaconda had no influence > > on %_install_langs but sets some value in /etc/sysconfig/i18n only. > > Correct nowdays. The big problem there is openoffice though Isn't that supposed to be resolved for fc4? Splitting OpenOffice-i18n into several different subpackages? Why is this so hard, anyway? From mbneto at gmail.com Sun Jan 23 15:50:40 2005 From: mbneto at gmail.com (mbneto) Date: Sun, 23 Jan 2005 11:50:40 -0400 Subject: rawhide report: 20050121 changes In-Reply-To: <1106410993.15391.42.camel@jdub.homelinux.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410993.15391.42.camel@jdub.homelinux.org> Message-ID: <5cf776b8050123075072835f89@mail.gmail.com> Hi, I think that one of the problems is the dependency issue. I've been using RedHat/Fedora since RH 3 and one thing that makes me sad is that every other distro seems to have a "minimum/firewall like" install and the 'minimum' install for fcX is 700Mb... I'd like to use fc in a CF-card-based installation but was nto possible due to this size. I know we have 1Gb CF now but is still expensive. From enrico.scholz at informatik.tu-chemnitz.de Sun Jan 23 15:06:53 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 23 Jan 2005 16:06:53 +0100 Subject: further package removals/potential package removals In-Reply-To: <41F3B36A.6050107@nc.rr.com> (Jeff Johnson's message of "Sun, 23 Jan 2005 09:23:38 -0500") References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <41F313F7.7679D847@jwz.org> <41F319D2.6080303@nc.rr.com> <87651odavq.fsf@londo.ultra.csn.tu-chemnitz.de> <41F330F5.2020001@nc.rr.com> <87zmz0b9oe.fsf@londo.ultra.csn.tu-chemnitz.de> <41F3B36A.6050107@nc.rr.com> Message-ID: <87vf9ob2wi.fsf@londo.ultra.csn.tu-chemnitz.de> Jeff Johnson writes: >>>All paths in rpm are changeable through appropriate configuration, >>>difficulty is in the eye of the beholder. >> >>What would be the "appropriate configuration" to change the path of >>/etc/rpm/platform? > > rm -f /etc/rpm/platform and live with uname(2) lies from the kernel. ??? How will this help for '--root' installations for i586-redhat-linux guests on an i686-redhat-linux host? Enrico From n3npq at nc.rr.com Sun Jan 23 16:07:43 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sun, 23 Jan 2005 11:07:43 -0500 Subject: further package removals/potential package removals In-Reply-To: <87vf9ob2wi.fsf@londo.ultra.csn.tu-chemnitz.de> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <41F313F7.7679D847@jwz.org> <41F319D2.6080303@nc.rr.com> <87651odavq.fsf@londo.ultra.csn.tu-chemnitz.de> <41F330F5.2020001@nc.rr.com> <87zmz0b9oe.fsf@londo.ultra.csn.tu-chemnitz.de> <41F3B36A.6050107@nc.rr.com> <87vf9ob2wi.fsf@londo.ultra.csn.tu-chemnitz.de> Message-ID: <41F3CBCF.9070106@nc.rr.com> Enrico Scholz wrote: >Jeff Johnson writes: > > > >>>>All paths in rpm are changeable through appropriate configuration, >>>>difficulty is in the eye of the beholder. >>>> >>>> >>>What would be the "appropriate configuration" to change the path of >>>/etc/rpm/platform? >>> >>> >>rm -f /etc/rpm/platform and live with uname(2) lies from the kernel. >> >> > >??? How will this help for '--root' installations for i586-redhat-linux >guests on an i686-redhat-linux host? > > It doesn't. And /etc/rpm/platform is not part of rpm configuration, but rather a replacemnet for uname(2) imho. And yes, arch (and os) in rpm is fabulously useless, always has been. Someday I'll be permitted to change the crap. But we've come quite far from the original thread, haven't we? No matter what %_netsharedpath /usr/share/doc prevents installation of doco files, and is less crude than the the original complaint that the following was needed to reclaim disk space: cd /usr/share/doc rm -f * 73 de Jeff From arjanv at redhat.com Sun Jan 23 16:48:23 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Sun, 23 Jan 2005 17:48:23 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <5cf776b8050123075072835f89@mail.gmail.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106329383.31381.47.camel@support02.civic.twp.ypsilanti.mi.us> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410993.15391.42.camel@jdub.homelinux.org> <5cf776b8050123075072835f89@mail.gmail.com> Message-ID: <1106498904.6129.46.camel@laptopd505.fenrus.org> On Sun, 2005-01-23 at 11:50 -0400, mbneto wrote: > > > I think that one of the problems is the dependency issue. I've been > using RedHat/Fedora since RH 3 and one thing that makes me sad is that > every other distro seems to have a "minimum/firewall like" install and > the 'minimum' install for fcX is 700Mb... well if you try a bit harder you get 300Mb though... still not really small (but if you remove the locales and man pages from that it might get there somewhat) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From laroche at redhat.com Sun Jan 23 17:39:10 2005 From: laroche at redhat.com (Florian La Roche) Date: Sun, 23 Jan 2005 18:39:10 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106498904.6129.46.camel@laptopd505.fenrus.org> References: <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410993.15391.42.camel@jdub.homelinux.org> <5cf776b8050123075072835f89@mail.gmail.com> <1106498904.6129.46.camel@laptopd505.fenrus.org> Message-ID: <20050123173910.GB32562@dudweiler.stuttgart.redhat.com> On Sun, Jan 23, 2005 at 05:48:23PM +0100, Arjan van de Ven wrote: > On Sun, 2005-01-23 at 11:50 -0400, mbneto wrote: > > > > > > I think that one of the problems is the dependency issue. I've been > > using RedHat/Fedora since RH 3 and one thing that makes me sad is that > > every other distro seems to have a "minimum/firewall like" install and > > the 'minimum' install for fcX is 700Mb... > > well if you try a bit harder you get 300Mb though... > still not really small (but if you remove the locales and man pages from > that it might get there somewhat) With xen it could make more sense again to minimize installations and then have smaller images where only few services run. E.g. an image just for mysql, one with bind, ... While kickstart is normally very good for these things, question still comes up if it would be important enough to again put some more selections into the GUI-installer parts for this. greetings, Florian La Roche From jspaleta at gmail.com Sun Jan 23 17:12:18 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 23 Jan 2005 12:12:18 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <5cf776b8050123075072835f89@mail.gmail.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410993.15391.42.camel@jdub.homelinux.org> <5cf776b8050123075072835f89@mail.gmail.com> Message-ID: <604aa79105012309122cafb0c2@mail.gmail.com> On Sun, 23 Jan 2005 11:50:40 -0400, mbneto wrote: > I think that one of the problems is the dependency issue. I've been > using RedHat/Fedora since RH 3 and one thing that makes me sad is that > every other distro seems to have a "minimum/firewall like" install and > the 'minimum' install for fcX is 700Mb... This comes up frequently, and i pretty much say the same thing everytime. So everyone whose seen my rant about this before.. just hit delete now. What is installed in a minimal install is controlled to a great extent by the comps.xml file that defines the groupings of packages. A community of interested users could easily play with rearranging the comps.xml file and produce an alternative minimal install to test and refine. Its not difficult to recreate installable iso images that use a different comps.xml file. The fact is making minimal more minimal is a low priority issue for the current developers. Developers have finite time and you can't blame them for having a set or priorities. But this issue is something willing and motivated community could hack at and experiment with in parallel while Core development continues. Once the community has a comps.xml that impliments a smaller minimal install without impacting the desktop or workstation install types... it could be presented for review and consideration. But its going to take non-zero work from people who is motivated to making the minimal install smaller. The sooner people in the community who are interestied start poking at editing the comps.xml file anaconda uses... the sooner interested people can test the changes. Some people in the community have been focusing on creating a smaller minimal install by using externally defined kickstart files. But if you want anaconda's native 'minimal' install to be smaller.. people will have to start poking at the comps.xml file anaconda uses to see if things can be reorganized. -jef From kyrre at solution-forge.net Sun Jan 23 18:05:55 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 23 Jan 2005 19:05:55 +0100 Subject: FC4 with localized firefox (wishlist) In-Reply-To: References: <1106482635.6173.100.camel@localhost> Message-ID: <1106503555.2655.15.camel@localhost.localdomain> s?n, 23.01.2005 kl. 13.22 skrev Rahul Sundaram: > On Sun, 23 Jan 2005 13:17:15 +0100, Josep Puigdemont > wrote: > > Hi, > > > > Here it is my short wish list for FC4, if I may send one ;-) > > I don't know if this has been mentioned before or not, but I for one > > would like to see localized versions of Firefox for each installed > > language, by default. > > file a RFE against firefox in bugzilla.redhat.com That was done in november sometime... There was set a deadline for 1.december (if my memory serves my well), but there has been no improvement. The translation work is done by upstream for a bunch of languages a looong time ago - it's just not in fedora... From alan at redhat.com Sun Jan 23 18:08:56 2005 From: alan at redhat.com (Alan Cox) Date: Sun, 23 Jan 2005 13:08:56 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: References: <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106469019.7211.567.camel@mccallum.corsepiu.local> Message-ID: <20050123180856.GA32395@devserv.devel.redhat.com> On Sun, Jan 23, 2005 at 07:32:45AM -0600, Rex Dieter wrote: > I didn't say stop discussing integration with extras, did I? If I even > implied that, I apologize. Please, please keep that part of the > discussion going. I don't think KDE into extras is a good idea yet for another reason - extras is with the best will in the world going to show up glitches with FC4. Every programming person here knows that - its better to avoid some of the really hard and big stuff being used as a test target. I'd love to see FC5 or FC6 down to two CD's + extras Alan From hp at redhat.com Sun Jan 23 18:42:31 2005 From: hp at redhat.com (Havoc Pennington) Date: Sun, 23 Jan 2005 13:42:31 -0500 Subject: further package removals/potential package removals In-Reply-To: <41F387AB.4060604@nc.rr.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <20050123041600.GB1420188@hiwaay.net> <1106461830.29183.183.camel@localhost.localdomain> <41F387AB.4060604@nc.rr.com> Message-ID: <1106505752.6065.6.camel@localhost.localdomain> On Sun, 2005-01-23 at 06:16 -0500, Jeff Johnson wrote: > Seriously, dependencies have a context, and it's highly unlikely > that the dependency is actually needed by anaconda to install > or remove nautilus. The hint to depsolvers like anaconda necessary > with current implementations to discover an additional edge in > the dependency tree graph could be handled in other ways, > if nautilus were prepared to deal with the dlopen failure at > run-time. nautilus does not require the SMB backend to work, however we do want it installed by default (even on upgrade). If (as it does now) that means some people have to keep it installed even though they don't want it, then too bad; it's simply more important to get it installed by default. If someone fixes it so there's no tradeoff (we can get it by default, *and* you can uninstall it), then fantastic; of course nobody will object. A "requires(missingok)" sounds fine to me, but the anaconda guys are the ones whose opinion counts. Havoc From carlos.efr at mail.telepac.pt Sun Jan 23 18:53:08 2005 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Sun, 23 Jan 2005 18:53:08 +0000 Subject: further package removals/potential package removals In-Reply-To: <1106453486.4591.24.camel@stargrazer.home.awesomeplay.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106453486.4591.24.camel@stargrazer.home.awesomeplay.com> Message-ID: <41F3F294.8060606@mail.telepac.pt> Sean Middleditch wrote: > So install it from Extras. It's preclusion from Core will not cause a > retroactive obliteration of every copy of joe in the known world, nor > hinder you in the least from installing it whenever you want from > Extras. > > Why is this not getting through to people? Is "extras" a synonym for > "/dev/null" in half the world or something? ;-) I'm a joe user, and I would like to see it removed from Core, but I also have no problem in having it in Extras. However, as it stands now, "extras" is a synonym for "/dev/null". I'll only believe it when I see it. There should be an official "extras" before people start moving core packages onto it. Carlos Rodrigues From tromey at redhat.com Sun Jan 23 18:48:23 2005 From: tromey at redhat.com (Tom Tromey) Date: 23 Jan 2005 11:48:23 -0700 Subject: goals for fc4? In-Reply-To: References: <5cf776b8050108150644336d04@mail.gmail.com> <1105328387.5866.4.camel@one.myworld> <1105493919l.5018l.11l@devel.mpeters.us> <1105964316.5505.13.camel@ulysse.olympe.o2t> <1105968591.933.2.camel@va.local.linuxlobbyist.org> <1105972251.5505.89.camel@ulysse.olympe.o2t> <20050117171149.GB11715@devserv.devel.redhat.com> Message-ID: >>>>> "Pete" == Pete Chown <1 at 234.cx> writes: >> As a practical matter touching on Fedora, gcj remains the "best" way >> to deliver java applications on a free system. In my opinion, other >> free VMs have unacceptable performance, unacceptable platform >> coverage, or both. Pete> Have you tried ikvm? Rhino runs with it successfully, so it must be Pete> fairly complete. I haven't tried anything more demanding, though. I'm aware of IKVM but haven't really used it. In terms of ability to run applications, the important thing to remember is: all the free VMs can run the same things. Writing a java VM is no big deal -- that's why we have 20 of them. The hard part is the libraries, and basically all the free VMs use GNU Classpath (usually with minor VM-specific tweaks). Pete> One nice thing about ikvm is that it's a JIT (or rather, uses a JIT, Pete> either Mono or .NET). This means that in use, it is much more similar to Pete> other Java implementations. Yes, deployment is simpler in this scenario. >From my POV, at least at the moment (based on the benchmarks I've seen -- is that enough qualification? :-), Mono+IKVM falls into the "unacceptable performance" slot. For "jdk-style" deployment, especially if complete platform coverage doesn't matter to you, at the moment I think I would recommend JikesRVM. I remembered another reason we like gcj -- you can debug gcj-compiled code. You have to use gdb (which has its pros and cons), but at least you can do it. AFAIK the other free VMs lack any way to debug the code you're running. (It would be great to be wrong about this, since it would solve a problem we have with eclipse-on-free-VMs.) Tom From n3npq at nc.rr.com Sun Jan 23 18:58:21 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sun, 23 Jan 2005 13:58:21 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106505752.6065.6.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <20050123041600.GB1420188@hiwaay.net> <1106461830.29183.183.camel@localhost.localdomain> <41F387AB.4060604@nc.rr.com> <1106505752.6065.6.camel@localhost.localdomain> Message-ID: <41F3F3CD.6080502@nc.rr.com> Havoc Pennington wrote: >On Sun, 2005-01-23 at 06:16 -0500, Jeff Johnson wrote: > > >>Seriously, dependencies have a context, and it's highly unlikely >>that the dependency is actually needed by anaconda to install >>or remove nautilus. The hint to depsolvers like anaconda necessary >>with current implementations to discover an additional edge in >>the dependency tree graph could be handled in other ways, >>if nautilus were prepared to deal with the dlopen failure at >>run-time. >> >> > >nautilus does not require the SMB backend to work, however >we do want it installed by default (even on upgrade). > >If (as it does now) that means some people have to >keep it installed even though they don't want it, >then too bad; it's simply more important to get it >installed by default. > >If someone fixes it so there's no tradeoff (we can >get it by default, *and* you can uninstall it), >then fantastic; of course nobody will object. > >A "requires(missingok)" sounds fine to me, but >the anaconda guys are the ones whose opinion >counts. > > The mechanism was proposed several months ago, and I'm perfectly willing to commit rpm to a bit the dependency context bit fields that supplies a mechanism of "missingok" (i.e. supply hint to the depsovers, which can do whatever they wish semantically with the bit delivered, on return rpmlib is permitted to blithely ignore the dependency after delivery). I have heard nada, zippo, nil, nothing except from the depsolver maintainers. Open an RFE please, and ask for explicit sign off from the depsolver crowd, if you truly wish the functionality. The implementation is nothing more than testing a bit in 3 places and arguing whether "missingok" is the appropriate token for the mechanism, as the semantic is entirely opaque to rpmlib (which supplies mechanism only). Think: about 3 hours work in rpmlib. 73 de Jeff From kyrre at solution-forge.net Sun Jan 23 20:56:32 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 23 Jan 2005 21:56:32 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <87acr23e7z.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> <87is5q3hdn.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106323352.31381.41.camel@support02.civic.twp.ypsilanti.mi.us> <87ekge3gi1.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106324464.31381.45.camel@support02.civic.twp.ypsilanti.mi.us> <87acr23e7z.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106513792.7794.11.camel@localhost.localdomain> somehow, i see yet another cron job coming around the corner to such the lifeblood out of my laptop battery... mwah hah hahahahaaaa!!! fre, 21.01.2005 kl. 18.05 skrev Enrico Scholz: > elanthis at awesomeplay.com (Sean Middleditch) writes: > > >> > That's why Owen asked you to run gtk-update-icon-cache. > >> > >> I executed this command but it did not help. 'strace' showed that it is > >> nearly a noop: it loads some dynamic libraries and exits then with code > >> 0... > > > > --help is your friend. ;-) > > > > Try gtk-update-icon-cache ~/.icons as your user, or gtk-update-icon- > > cache /usr/share/icons as root. > > Ah... running on /usr/share/icons alone will not help. But after figuring > out the expected 'icon-theme.cache' files, I executed the command for the > 5 requested directories. Then gedit starts significantly faster. > > Unfortunately, the cache must be renewed manually when things change > there and I have ugly 'icon-theme.cache' files which are not covered by > the package-management. > > > > > Enrico From kyrre at solution-forge.net Sun Jan 23 20:52:57 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 23 Jan 2005 21:52:57 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106369288.4002.31.camel@bree.local.net> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <87mzv23jn2.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106320733.31381.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106354487.6775.6.camel@localhost.localdomain> <1106369288.4002.31.camel@bree.local.net> Message-ID: <1106513577.7794.9.camel@localhost.localdomain> yeah yeah. I enabled the devel repo and *pow* there it was. Quite nice thing! BTW - is it in RH bugzilla anywhere? Just want to report two rfe's: - no (default, at least) key for "next/previous" page - would be very nice if it could show pages in a pdf/ps in a continous "stream" (like Adobe reader), instead of having to do "next page" all the time And it does seem to be very buisy sometimes... But, afterall its 0.1 version, and its looking damn nice! good work! Loads in less than a secound, too! :D And the searching + thumbnails are great! Only thing i havent got around to check, is "does it have printer-selection support"? ggv don't, and gnome-pdf borks completely on one of four pdf's... Plus - can i copy/paste text from a pdf to wherever using it? l?r, 22.01.2005 kl. 05.48 skrev Jeremy Katz: > On Sat, 2005-01-22 at 01:41 +0100, Kyrre Ness Sjobak wrote: > > > http://www.gnome.org/projects/evince/ > > > > > > (FC RPMs available at that site) > > > > Ugh.. but they doesn't work - at least not on my computers. fc2 and fc3. > > Do those require rawhide? On the fc3 sys it sais it needs gtk2 >= 2.6, > > but fc3 only has 2.4 ... > > They require gtk+ 2.6. evince is taking advantage of some of the new > functionality provided. And as Jef says, this _is_ the development > list. :-) > > Jeremy From gauret at free.fr Sun Jan 23 21:27:29 2005 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 23 Jan 2005 22:27:29 +0100 Subject: suggests/requires in rpm (was: Re: further package removals/potential package removals) References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > However,??nautilus?requires?gnome-vfs2-smb?though?an?explicit?requires > on gnome-vfs2-smb, a decision made by the packager to ensure that the > runtime detectable smb support is always available when nautilus is > installed to provide a perfectly reasonable and recommended default > behavior for the average gnome desktop user.??Some?would?argue?doing > this is bending the purpose of 'requires' field out of necessity??to > be used as a 'suggests' or 'recommends' field which rpm doesn't yet > have support for. I have run into this kind of problem several times (and I've learned packaging only two years ago). For example with showimg (an image viewer), which can use kipi-plugins to add features, or with psi (a jabber client), which can use qca-tls for SSL support. The main objection I got from the RH folks when I proposed some kind of "recommands" before, is that most of the time the dependancies are set at compile-time, and thus are hardcoded. But I think that more and more applications use a plugin system to add features. Those plugins should remain plugins, and thus should not be set as an hardcoded dependancy. But of course, adding such a feature in RPM would need a very large amount of work to be supported properly from rpm to the user's wrappers. Nevertheless, I think "suggests" support could be added in RPM without breaking the wrappers, and complete support could be added later on. The wrapper which do not know of it yet would just ignore it. Would older implementation of RPM just ignore the tag when asked to rebuild a "suggests"-enabled spec file ? It's a lot of work, but I think it is worth it and it can be done one step at a time without breaking existing software. Of course, that's just my 0.02 and I don't know the inner workings of RPM very well. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours ; and this we should do freely and generously." -- Benjamin Franklin From strange at nsk.no-ip.org Sun Jan 23 21:35:53 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Sun, 23 Jan 2005 21:35:53 +0000 Subject: further package removals/potential package removals In-Reply-To: <20050122170130.GI2898@devserv.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> Message-ID: <20050123213553.GA14440@nsk.no-ip.org> On Sat, Jan 22, 2005 at 12:01:30PM -0500, Alan Cox wrote: > On Sat, Jan 22, 2005 at 05:16:30AM +0100, F?liciano Matias wrote: > > Move to Fedora Extra : > > dosfstools > > Lynx (or elinks) > > lynx is needed for mutt to do html reading on text logins. Its also fairly > important for accessibility for some users. Elinks I wouldn't worry about I prefer to use elinks on mutt: text/html; links -dump -dump-charset iso-8859-1 -default-mime-type text/html %s; copiousoutput; Regards, Luciano Rocha -- 2/16 From n3npq at nc.rr.com Sun Jan 23 22:00:16 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sun, 23 Jan 2005 17:00:16 -0500 Subject: suggests/requires in rpm In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> Message-ID: <41F41E70.6080102@nc.rr.com> Aurelien Bompard wrote: >Jeff Spaleta wrote: > > >>However, nautilus requires gnome-vfs2-smb though an explicit requires >>on gnome-vfs2-smb, a decision made by the packager to ensure that the >>runtime detectable smb support is always available when nautilus is >>installed to provide a perfectly reasonable and recommended default >>behavior for the average gnome desktop user. Some would argue doing >>this is bending the purpose of 'requires' field out of necessity to >>be used as a 'suggests' or 'recommends' field which rpm doesn't yet >>have support for. >> >> > >I have run into this kind of problem several times (and I've learned >packaging only two years ago). For example with showimg (an image viewer), >which can use kipi-plugins to add features, or with psi (a jabber client), >which can use qca-tls for SSL support. >The main objection I got from the RH folks when I proposed some kind of >"recommands" before, is that most of the time the dependancies are set at >compile-time, and thus are hardcoded. >But I think that more and more applications use a plugin system to add >features. Those plugins should remain plugins, and thus should not be set >as an hardcoded dependancy. > > The proposal is for "missingok", not Recommends:, Enhances:, Suggests: or any other goosey-loosey crapola with poorly defined DWIM that is impossible to implement, let alone debug. The specific difference is that dependencies marked with "missingok" are passed to a depsolver, which is entirely at liberty to do whatever it wants with the information. And the other difference is that rpmlib is responsibly only for passing the information to the depsolver, and then ignoring the dependecy. That definition is well defined mechanism, unlike Recommends: et al. >But of course, adding such a feature in RPM would need a very large amount >of work to be supported properly from rpm to the user's wrappers. >Nevertheless, I think "suggests" support could be added in RPM without >breaking the wrappers, and complete support could be added later on. The >wrapper which do not know of it yet would just ignore it. Would older >implementation of RPM just ignore the tag when asked to rebuild a >"suggests"-enabled spec file ? >It's a lot of work, but I think it is worth it and it can be done one step >at a time without breaking existing software. > >Of course, that's just my 0.02 and I don't know the inner workings of RPM >very well. > > I do know the innards of rpm upside down and inside out, and the "missingok" implementation is 3 hours work, with no obvious legacy problems. That is not true for Recommends: et al. 73 de Jeff From wrrhdev at riede.org Sun Jan 23 22:07:07 2005 From: wrrhdev at riede.org (Willem Riede) Date: Sun, 23 Jan 2005 22:07:07 +0000 Subject: environment (/etc/profile) and X In-Reply-To: (from j.underwood@open.ac.uk on Fri Jan 21 11:27:27 2005) References: <1106320335.7601.89.camel@localhost.localdomain> <604aa79105012107394832d2f8@mail.gmail.com> Message-ID: <1106518027l.5898l.1l@serve.riede.org> On 01/21/2005 11:27:27 AM, Jonathan Underwood wrote: > Jeff Spaleta wrote: > > On Fri, 21 Jan 2005 10:12:15 -0500, Havoc Pennington > wrote: > > > >>We spent a lot of time fixing this several years ago, must have gotten > >>busted somehow. > >>Be sure there's a bugzilla... > > > > > > I'm not that sure its busted out-of-the-box ... my delete key works > > just fine in gnome-term and xterm running in a gnome-desktop started > > from gdm out of runlevel 5 using the prefdm mechanism. INPUTRC is set > > and as far as I can tell reading through the prefdm logic... > > /etc/profile gets called exactly once inside the /usr/bin/gdm > > script, assuming the test -f /etc/profile succeeds. Sounds to me > > like someone has made a local change to the script logic either in > > prefdm or in /usr/bin/gdm > > > > Nope, I've made no change to either, and see the same issue on two > different FC3 boxes. To be clear, I'm talking about delete and not > backspace. INPUTRC is definately not set on either box inside of a > gnome-session. Still, this is not an universal problem. On my two FC3 boxes delete works as intended... Also, from gnome-terminal: [wriede at serve ~]$ echo $INPUTRC /etc/inputrc Regards, Willem Riede. From Nicolas.Mailhot at laPoste.net Sun Jan 23 22:46:27 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sun, 23 Jan 2005 23:46:27 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <604aa79105012309122cafb0c2@mail.gmail.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <200501211308.40737.rjune@bravegnuworld.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410993.15391.42.camel@jdub.homelinux.org> <5cf776b8050123075072835f89@mail.gmail.com> <604aa79105012309122cafb0c2@mail.gmail.com> Message-ID: <1106520387.3101.10.camel@rousalka.dyndns.org> Le dimanche 23 janvier 2005 ? 12:12 -0500, Jeff Spaleta a ?crit : > On Sun, 23 Jan 2005 11:50:40 -0400, mbneto wrote: > > I think that one of the problems is the dependency issue. I've been > > using RedHat/Fedora since RH 3 and one thing that makes me sad is that > > every other distro seems to have a "minimum/firewall like" install and > > the 'minimum' install for fcX is 700Mb... > > This comes up frequently, and i pretty much say the same thing > everytime. So everyone whose seen my rant about this before.. just hit > delete now. [snip] The fact is if I want to set up an Oracle box I'll need a minimal install - just not the one you think of, because it'll be defined by Oracle needs. In the same way if I setup a spam filtering box or a pvr box I'll do minimal installs - but again these won't be the same as the first one. The problem is not the comps.xml groups. You won't find a common minimal group for all those wildly different uses (that's why the current minimal install has grown - to encompass everything). The problem is making easier for different people to define the minimal sets they want to use (and not lock them in a setup that tries to be everything for everyone) And I know it's a PITA to support - you just can't assume everyone will have more or less the same setup. But since lots of people end up working around all the well-meaned attempts to have everyone go the same path, the support problems are the same, you only piss off people that have to fight obviously arbitrary installation decisions. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From gauret at free.fr Sun Jan 23 23:04:09 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 00:04:09 +0100 Subject: suggests/requires in rpm References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com> Message-ID: Jeff Johnson wrote: > I do know the innards of rpm upside down and inside out, and the > "missingok" implementation is > 3 hours work, with no obvious legacy problems. > > That is not true for Recommends: et al. Great ! I don't care how it's going to be called, as long as we can solve this situation. That's really good news, thanks a lot ! Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info If one keeps trying, one successes eventually. Therefore, the more one fails, the closer one is to success. -- Shadok moto. From mbneto at gmail.com Sun Jan 23 23:23:20 2005 From: mbneto at gmail.com (mbneto) Date: Sun, 23 Jan 2005 19:23:20 -0400 Subject: rawhide report: 20050121 changes In-Reply-To: <604aa79105012309122cafb0c2@mail.gmail.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410993.15391.42.camel@jdub.homelinux.org> <5cf776b8050123075072835f89@mail.gmail.com> <604aa79105012309122cafb0c2@mail.gmail.com> Message-ID: <5cf776b8050123152339a58b01@mail.gmail.com> Hi jef, I'll try to look at this comps.xml file. Can you provide any extra info or tips regarding this ? The "problem" that I find is that there are so many inter dependencies between packages that I found really hard. The other day after a 'minimum'install I created a list with rpm -a and tried to remove unecesseary packages by hand. I gave up after a lot atempts to remove packages that I don't use but are necessary for others that I do :( Since I am newbie at this forgive any naive (ok stupid) remarks, but would be great to have more packages like php suite where I can select the features that I need (php-mysql etc) without having to install the kitchen sink... - mb On Sun, 23 Jan 2005 12:12:18 -0500, Jeff Spaleta wrote: > What is installed in a minimal install is controlled to a great extent > by the comps.xml file that defines the groupings of packages. A > community of interested users could easily play with rearranging the > comps.xml file and produce an alternative minimal install to test and > refine. Its not difficult to recreate installable iso images that use > a different comps.xml file. The fact is making minimal more minimal > is a low priority issue for the current developers. Developers have > finite time and you can't blame them for having a set or priorities. > But this issue is something willing and motivated community could hack > at and experiment with in parallel while Core development continues. > > Once the community has a comps.xml that impliments a smaller minimal > install without impacting the desktop or workstation install types... > it could be presented for review and consideration. But its going to > take non-zero work from people who is motivated to making the minimal > install smaller. The sooner people in the community who are > interestied start poking at editing the comps.xml file anaconda > uses... the sooner interested people can test the changes. > > Some people in the community have been focusing on creating a smaller > minimal install by using externally defined kickstart files. But if > you want anaconda's native 'minimal' install to be smaller.. people > will have to start poking at the comps.xml file anaconda uses to see > if things can be reorganized. > > -jef > From mbneto at gmail.com Sun Jan 23 23:25:39 2005 From: mbneto at gmail.com (mbneto) Date: Sun, 23 Jan 2005 19:25:39 -0400 Subject: rawhide report: 20050121 changes In-Reply-To: <1106498904.6129.46.camel@laptopd505.fenrus.org> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106345061.8056.12.camel@jdub.homelinux.org> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410993.15391.42.camel@jdub.homelinux.org> <5cf776b8050123075072835f89@mail.gmail.com> <1106498904.6129.46.camel@laptopd505.fenrus.org> Message-ID: <5cf776b80501231525cec0502@mail.gmail.com> Hi, Can you give me a list of those "uneeded" packages ? :) After the minimum install I removed a few packages but nothing really significant (in terms of space at least). -mb On Sun, 23 Jan 2005 17:48:23 +0100, Arjan van de Ven wrote: > > > well if you try a bit harder you get 300Mb though... > still not really small (but if you remove the locales and man pages from > that it might get there somewhat) > > From katzj at redhat.com Sun Jan 23 23:58:02 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 23 Jan 2005 18:58:02 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106505752.6065.6.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <20050123041600.GB1420188@hiwaay.net> <1106461830.29183.183.camel@localhost.localdomain> <41F387AB.4060604@nc.rr.com> <1106505752.6065.6.camel@localhost.localdomain> Message-ID: <1106524682.4002.67.camel@bree.local.net> On Sun, 2005-01-23 at 13:42 -0500, Havoc Pennington wrote: > If someone fixes it so there's no tradeoff (we can > get it by default, *and* you can uninstall it), > then fantastic; of course nobody will object. > > A "requires(missingok)" sounds fine to me, but > the anaconda guys are the ones whose opinion > counts. ... And, of course, there's the ever fun part about if there's anything like this, then _every time you do an upgrade_, you'll get the package added back. At which point, people complain, we turn off the use of the hint on upgrades and we're back to step1. Around and around the mulberry bush we go, where it stops, no one knows. Jeremy From katzj at redhat.com Sun Jan 23 23:58:04 2005 From: katzj at redhat.com (Jeremy Katz) Date: Sun, 23 Jan 2005 18:58:04 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <1106513577.7794.9.camel@localhost.localdomain> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <87mzv23jn2.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106320733.31381.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106354487.6775.6.camel@localhost.localdomain> <1106369288.4002.31.camel@bree.local.net> <1106513577.7794.9.camel@localhost.localdomain> Message-ID: <1106524684.4002.69.camel@bree.local.net> On Sun, 2005-01-23 at 21:52 +0100, Kyrre Ness Sjobak wrote: > yeah yeah. I enabled the devel repo and *pow* there it was. Quite nice > thing! BTW - is it in RH bugzilla anywhere? Just want to report two > rfe's: Should be in bugzilla.gnome.org > - would be very nice if it could show pages in a pdf/ps in a continous > "stream" (like Adobe reader), instead of having to do "next page" all > the time I saw screenshots of this and think Alex was working on it. > Only thing i havent got around to check, is "does it have > printer-selection support"? ggv don't, and gnome-pdf borks completely on > one of four pdf's... Yep, it uses the standard gnome-print stuff to get this. > Plus - can i copy/paste text from a pdf to wherever using it? That should work too afaict. Jeremy > l?r, 22.01.2005 kl. 05.48 skrev Jeremy Katz: > > On Sat, 2005-01-22 at 01:41 +0100, Kyrre Ness Sjobak wrote: > > > > http://www.gnome.org/projects/evince/ > > > > > > > > (FC RPMs available at that site) > > > > > > Ugh.. but they doesn't work - at least not on my computers. fc2 and fc3. > > > Do those require rawhide? On the fc3 sys it sais it needs gtk2 >= 2.6, > > > but fc3 only has 2.4 ... > > > > They require gtk+ 2.6. evince is taking advantage of some of the new > > functionality provided. And as Jef says, this _is_ the development > > list. :-) > > > > Jeremy > From n3npq at nc.rr.com Mon Jan 24 00:06:02 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sun, 23 Jan 2005 19:06:02 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106524682.4002.67.camel@bree.local.net> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <20050123041600.GB1420188@hiwaay.net> <1106461830.29183.183.camel@localhost.localdomain> <41F387AB.4060604@nc.rr.com> <1106505752.6065.6.camel@localhost.localdomain> <1106524682.4002.67.camel@bree.local.net> Message-ID: <41F43BEA.7000203@nc.rr.com> Jeremy Katz wrote: >On Sun, 2005-01-23 at 13:42 -0500, Havoc Pennington wrote: > > >>If someone fixes it so there's no tradeoff (we can >>get it by default, *and* you can uninstall it), >>then fantastic; of course nobody will object. >> >>A "requires(missingok)" sounds fine to me, but >>the anaconda guys are the ones whose opinion >>counts. >> >> > >... >And, of course, there's the ever fun part about if there's anything like >this, then _every time you do an upgrade_, you'll get the package added >back. > >At which point, people complain, we turn off the use of the hint on >upgrades and we're back to step1. Around and around the mulberry bush >we go, where it stops, no one knows. > > Not true. The "missingok" mechanism fails on legacy code/packaging by reproducing the current behavior exactly as is. Meanwhile, new packaging for, say, nautilus which has Requires(missingok): gnome-vfs2-smb and a depsolver that tests RPMSENSE_MISSINGOK drop a sub-tree that is optional. I fail to see a mulberry bush, except in this loopy and endless fretting. Show me the mulberries *please*. 73 de Jeff From jspaleta at gmail.com Mon Jan 24 00:08:30 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 23 Jan 2005 19:08:30 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106524682.4002.67.camel@bree.local.net> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <20050123041600.GB1420188@hiwaay.net> <1106461830.29183.183.camel@localhost.localdomain> <41F387AB.4060604@nc.rr.com> <1106505752.6065.6.camel@localhost.localdomain> <1106524682.4002.67.camel@bree.local.net> Message-ID: <604aa791050123160844696e7e@mail.gmail.com> On Sun, 23 Jan 2005 18:58:02 -0500, Jeremy Katz wrote: > And, of course, there's the ever fun part about if there's anything like > this, then _every time you do an upgrade_, you'll get the package added > back. Thats no different than the current situation with the heavy-handied use of Requires in the case of nautilus. The package maintainers seem hell bent of forcing the install of this smb support even during an upgrade. I'd say any solution that lets an admin uninstall it after an upgrade.. has got to be better than the current situation where you have to break a dep chain to get that gnome-vfs2-smb uninstalled. If all the solutions to choose from are imperfect... the one that provides the local admin any measure of control seems sane to me. If we can't prevent this from being installed during an upgrade at least making it something local admins can remove post upgrade sound good from a system admin perspective. -jef"Oh and can I have a pony with every fedora core install? i want a pony."spaleta From pjones at redhat.com Mon Jan 24 05:55:43 2005 From: pjones at redhat.com (Peter Jones) Date: Mon, 24 Jan 2005 00:55:43 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106452796.7211.491.camel@mccallum.corsepiu.local> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> Message-ID: <1106546143.7129.7.camel@localhost.localdomain> On Sun, 2005-01-23 at 04:59 +0100, Ralf Corsepius wrote: > On Sat, 2005-01-22 at 12:01 -0500, Alan Cox wrote: > > > Possibly joe also ought to go to extras nowdays. > Is there any wordstar compatible editor in Core? > > To me, seeing joe removed would be a severe regression. >15 years of > using wordstar compatible editors can't simply be ignored. The old way of thinking about this has got to go. _Moving_ something to Extras is not the same thing as removing it from the distro. We have got to stop thinking of moving something to Extras as removing it from the distro. Core is not the distro, it is merely a part of the distro. Extras is another part. -- Peter From bclark at redhat.com Mon Jan 24 06:09:18 2005 From: bclark at redhat.com (Bryan Clark) Date: Mon, 24 Jan 2005 01:09:18 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <1106524684.4002.69.camel@bree.local.net> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <87mzv23jn2.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106320733.31381.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106354487.6775.6.camel@localhost.localdomain> <1106369288.4002.31.camel@bree.local.net> <1106513577.7794.9.camel@localhost.localdomain> <1106524684.4002.69.camel@bree.local.net> Message-ID: <1106546958.3385.2.camel@rhbw.boston.redhat.com> On Sun, 2005-01-23 at 18:58 -0500, Jeremy Katz wrote: > > - would be very nice if it could show pages in a pdf/ps in a continous > > "stream" (like Adobe reader), instead of having to do "next page" all > > the time > > I saw screenshots of this and think Alex was working on it. jrb actually ;-) Here's the screenshot: http://www.gnome.org/~jrb/files/Screenshot-test-page-view.png > > Plus - can i copy/paste text from a pdf to wherever using it? > > That should work too afaict. Selection is using a box selection tool right now, but will change eventually. Check out the evince project page for more info: http://www.gnome.org/projects/evince/ ~ Bryan From backes at rhrk.uni-kl.de Mon Jan 24 07:00:05 2005 From: backes at rhrk.uni-kl.de (Joachim Backes) Date: Mon, 24 Jan 2005 08:00:05 +0100 Subject: FTP-Download of the FC3 DVD-ISO with firefox Message-ID: <1106550005.5014.26.camel@sunny.rhrk.uni-kl.de> Hi, did somebody already try to download the DVD iso of FC3, using firefox or mozilla for downloading? The problem is that during the download, (before download is almost done), suddenly the browsers show weird sizes of the from-file (mixed with minus signs). on the other hand, wget runs perfectly. I can reproduce this behaviour under FC3 itself (mozilla/firefox, started in WinXP, show a similar behaviour). -- Regards Joachim Backes Joachim Backes University of Kaiserslautern,Computer Center, High Performance Computing, D-67653 Kaiserslautern, PO Box 3049, Germany -------------------------------------------------- Phone: +49-631-205-2438, FAX: +49-631-205-3056 http://hlrwm.rhrk.uni-kl.de/home/staff/backes.html From symbiont at berlios.de Mon Jan 24 07:18:01 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 24 Jan 2005 15:18:01 +0800 Subject: Alien Night vs ksh (was: rawhide report: 20050121 changes) In-Reply-To: References: <1106329858.12994.25.camel@mentorng.gurulabs.com> Message-ID: <200501241518.01464.symbiont@berlios.de> On Saturday 22 January 2005 02:01, Elliot Lee wrote: > On Fri, 21 Jan 2005, Dax Kelson wrote: > > > Removed package pdksh > > This will be replaced by the Real ksh sometime soon. Recommend remove *after* replacement in place. -- -jeff From laroche at redhat.com Mon Jan 24 07:54:13 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 24 Jan 2005 08:54:13 +0100 Subject: Alien Night vs ksh (was: rawhide report: 20050121 changes) In-Reply-To: <200501241518.01464.symbiont@berlios.de> References: <1106329858.12994.25.camel@mentorng.gurulabs.com> <200501241518.01464.symbiont@berlios.de> Message-ID: <20050124075413.GA6628@dudweiler.stuttgart.redhat.com> On Mon, Jan 24, 2005 at 03:18:01PM +0800, Jeff Pitman wrote: > On Saturday 22 January 2005 02:01, Elliot Lee wrote: > > On Fri, 21 Jan 2005, Dax Kelson wrote: > > > > Removed package pdksh > > > > This will be replaced by the Real ksh sometime soon. > > Recommend remove *after* replacement in place. It's in there now. ;-) greetings, Florian La Roche From rc040203 at freenet.de Mon Jan 24 07:37:04 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 24 Jan 2005 08:37:04 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106546143.7129.7.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> Message-ID: <1106552224.7211.623.camel@mccallum.corsepiu.local> On Mon, 2005-01-24 at 00:55 -0500, Peter Jones wrote: > On Sun, 2005-01-23 at 04:59 +0100, Ralf Corsepius wrote: > > On Sat, 2005-01-22 at 12:01 -0500, Alan Cox wrote: > > > > > Possibly joe also ought to go to extras nowdays. > > Is there any wordstar compatible editor in Core? > > > > To me, seeing joe removed would be a severe regression. >15 years of > > using wordstar compatible editors can't simply be ignored. > > The old way of thinking about this has got to go. _Moving_ something to > Extras is not the same thing as removing it from the distro. Well, that's not the problem. The problem is removing "joe" means abandoning a whole family of editors, which once had been the world's dominating family of editors and had sustainably influenced a whole generation of users. I.e. the problem is not RH moving a package from Core to Extras, the problem is RH abandoning a Core system feature (Here: wordstar- compatible ascii text editors.) On the other hand, RH/Core seems to be wanting to continue shipping various other editors, such as vim (which has had a lot of problems in the past), and bloated blobs like emacs and xemacs. IMO, if you want to remove joe from Core, you should be consequent and remove vi, emacs, xemacs, etc. too and let only ship one single, small and statically linked ascii text-editor remain in Core, may-be nano. Otherwise I would recommend to remove nano, because I don't see any reason why it should be integrated into Core. > We have got to stop thinking of moving something to Extras as removing > it from the distro. Core is not the distro, it is merely a part of the > distro. Extras is another part. ATM, Extras isn't much more than a "promise", ... we will see if it will come and if when it will work out. Ralf From arjanv at redhat.com Mon Jan 24 08:02:15 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Mon, 24 Jan 2005 09:02:15 +0100 Subject: further package removals/potential package removals In-Reply-To: <41F43BEA.7000203@nc.rr.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <20050123041600.GB1420188@hiwaay.net> <1106461830.29183.183.camel@localhost.localdomain> <41F387AB.4060604@nc.rr.com> <1106505752.6065.6.camel@localhost.localdomain> <1106524682.4002.67.camel@bree.local.net> <41F43BEA.7000203@nc.rr.com> Message-ID: <1106553735.4172.33.camel@laptopd505.fenrus.org> > Meanwhile, new packaging for, say, nautilus which has > Requires(missingok): gnome-vfs2-smb > and a depsolver that tests RPMSENSE_MISSINGOK drop a sub-tree that > is optional. > > I fail to see a mulberry bush, except in this loopy and endless fretting. > > Show me the mulberries *please*. user goes from package-1.0-1.0 to package-1.1-1.0 which now had a Requires(missingok): gnome-vfs2-smp. Fine; yum (for the sake of argument) grabs gnome-vfs2-smp as well and everything is happy. Now the user gets annoyed by the "bloat" and removes gnome-vfs2-smp. Still fine. Then a security update comes out, package-1.1-1.1 and the user of course upgrades to that. yum will *AGAIN* pull in gnome-vfs2-smp. User gets really annoyed and considers this not-fine. Would there be a way to version the missingok such that it's a hint to the depsolver to only solve the dep if the old package is matching the versioning ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From laroche at redhat.com Mon Jan 24 08:50:16 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 24 Jan 2005 09:50:16 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106553735.4172.33.camel@laptopd505.fenrus.org> References: <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <20050123041600.GB1420188@hiwaay.net> <1106461830.29183.183.camel@localhost.localdomain> <41F387AB.4060604@nc.rr.com> <1106505752.6065.6.camel@localhost.localdomain> <1106524682.4002.67.camel@bree.local.net> <41F43BEA.7000203@nc.rr.com> <1106553735.4172.33.camel@laptopd505.fenrus.org> Message-ID: <20050124085016.GA7147@dudweiler.stuttgart.redhat.com> On Mon, Jan 24, 2005 at 09:02:15AM +0100, Arjan van de Ven wrote: > > > Meanwhile, new packaging for, say, nautilus which has > > Requires(missingok): gnome-vfs2-smb > > and a depsolver that tests RPMSENSE_MISSINGOK drop a sub-tree that > > is optional. > > > > I fail to see a mulberry bush, except in this loopy and endless fretting. > > > > Show me the mulberries *please*. > > > user goes from package-1.0-1.0 to package-1.1-1.0 which now had a > Requires(missingok): gnome-vfs2-smp. Fine; yum (for the sake of > argument) grabs gnome-vfs2-smp as well and everything is happy. > Now the user gets annoyed by the "bloat" and removes gnome-vfs2-smp. > Still fine. > > Then a security update comes out, package-1.1-1.1 and the user of course > upgrades to that. yum will *AGAIN* pull in gnome-vfs2-smp. User gets > really annoyed and considers this not-fine. > > Would there be a way to version the missingok such that it's a hint to > the depsolver to only solve the dep if the old package is matching the > versioning ? > Sounds to me like we should install gnome-vfs2-smb via comps.xml to provide it per default for new installs, but also let people de-install it. Then the remaining item is to look at updates. I think with good error messages and maybe some release notes this should be ok, not that much more rpm deps can solve for this situation. greetings, Florian La Roche From n3npq at nc.rr.com Mon Jan 24 08:20:09 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 03:20:09 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106553735.4172.33.camel@laptopd505.fenrus.org> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <20050123041600.GB1420188@hiwaay.net> <1106461830.29183.183.camel@localhost.localdomain> <41F387AB.4060604@nc.rr.com> <1106505752.6065.6.camel@localhost.localdomain> <1106524682.4002.67.camel@bree.local.net> <41F43BEA.7000203@nc.rr.com> <1106553735.4172.33.camel@laptopd505.fenrus.org> Message-ID: <41F4AFB9.4080904@nc.rr.com> Arjan van de Ven wrote: >>Meanwhile, new packaging for, say, nautilus which has >> Requires(missingok): gnome-vfs2-smb >>and a depsolver that tests RPMSENSE_MISSINGOK drop a sub-tree that >>is optional. >> >>I fail to see a mulberry bush, except in this loopy and endless fretting. >> >>Show me the mulberries *please*. >> >> > > >user goes from package-1.0-1.0 to package-1.1-1.0 which now had a >Requires(missingok): gnome-vfs2-smp. Fine; yum (for the sake of >argument) grabs gnome-vfs2-smp as well and everything is happy. >Now the user gets annoyed by the "bloat" and removes gnome-vfs2-smp. >Still fine. > >Then a security update comes out, package-1.1-1.1 and the user of course >upgrades to that. yum will *AGAIN* pull in gnome-vfs2-smp. User gets >really annoyed and considers this not-fine. > >Would there be a way to version the missingok such that it's a hint to >the depsolver to only solve the dep if the old package is matching the >versioning ? > > The "missingok" bit is passed to yum. Yum can of course choose to treat the "missingok" dependency as a mandatory Requires:, in which case the beahavior is as you describe. Or yum, and anaconda, and up2date might perhaps do something more intelligent. You never know, do ya? 73 de Jeff From peter.backlund at home.se Mon Jan 24 09:17:23 2005 From: peter.backlund at home.se (Peter Backlund) Date: Mon, 24 Jan 2005 10:17:23 +0100 Subject: further package removals/potential package removals In-Reply-To: <20050124085016.GA7147@dudweiler.stuttgart.redhat.com> References: <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <20050123041600.GB1420188@hiwaay.net> <1106461830.29183.183.camel@localhost.localdomain> <41F387AB.4060604@nc.rr.com> <1106505752.6065.6.camel@localhost.localdomain> <1106524682.4002.67.camel@bree.local.net> <41F43BEA.7000203@nc.rr.com> <1106553735.4172.33.camel@laptopd505.fenrus.org> <20050124085016.GA7147@dudweiler.stuttgart.redhat.com> Message-ID: <1106558243.26412.4.camel@localhost.localdomain> m?n 2005-01-24 klockan 09:50 +0100 skrev Florian La Roche: > On Mon, Jan 24, 2005 at 09:02:15AM +0100, Arjan van de Ven wrote: > > > > > Meanwhile, new packaging for, say, nautilus which has > > > Requires(missingok): gnome-vfs2-smb > > > and a depsolver that tests RPMSENSE_MISSINGOK drop a sub-tree that > > > is optional. > > > > > > I fail to see a mulberry bush, except in this loopy and endless fretting. > > > > > > Show me the mulberries *please*. > > > > > > user goes from package-1.0-1.0 to package-1.1-1.0 which now had a > > Requires(missingok): gnome-vfs2-smp. Fine; yum (for the sake of > > argument) grabs gnome-vfs2-smp as well and everything is happy. > > Now the user gets annoyed by the "bloat" and removes gnome-vfs2-smp. > > Still fine. > > > > Then a security update comes out, package-1.1-1.1 and the user of course > > upgrades to that. yum will *AGAIN* pull in gnome-vfs2-smp. User gets > > really annoyed and considers this not-fine. > > > > Would there be a way to version the missingok such that it's a hint to > > the depsolver to only solve the dep if the old package is matching the > > versioning ? > > > > > Sounds to me like we should install gnome-vfs2-smb via comps.xml to > provide it per default for new installs, but also let people de-install it. > Then the remaining item is to look at updates. I think with good error > messages and maybe some release notes this should be ok, not that much > more rpm deps can solve for this situation. To me, this seems to be the best and simplest solution. The requirement for gnome-vfs2-smb is apparently there to make sure the default install has certain funcionality, so why not delegate that responsibility to the installation program (i.e. Anaconda)? If the user wants to remove it later, fine. On upgrades, gnome-vfs2-smb will be upgraded if it's installed, otherwise it won't be installed. +1 for letting Anaconda define the default install package set, instead of using "Requires". /Peter From tmraz at redhat.com Mon Jan 24 10:25:25 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 24 Jan 2005 11:25:25 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106369540.4002.34.camel@bree.local.net> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <1106369540.4002.34.camel@bree.local.net> Message-ID: <1106562325.5621.24.camel@perun.redhat.usu> On Fri, 2005-01-21 at 23:52 -0500, Jeremy Katz wrote: > On Sat, 2005-01-22 at 05:16 +0100, F?liciano Matias wrote: > > dosfstools > > dosfstools is needed for anaconda. Certain architectures > (*cough*ia64*cough*) require a vfat partition for booting. > > Also, it's helpful in a lot of cases where you have things like USB > keys. +1 to that -- Tomas Mraz From harald at redhat.com Mon Jan 24 10:31:50 2005 From: harald at redhat.com (Harald Hoyer) Date: Mon, 24 Jan 2005 11:31:50 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <20050121234943.GA6392@nostromo.devel.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> Message-ID: <41F4CE96.5070102@redhat.com> Bill Nottingham wrote: > Not sure: > - diskcheck mine! why are you not sure? From gauret at free.fr Mon Jan 24 10:34:03 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 11:34:03 +0100 Subject: RFC: Soname in rpm name Message-ID: Hi all A question to packagers: what would you think of a policy to add the library soname in package libraries ? For example, I have a libkexif package, which provides libkexif.so.0, and at least 3 applications depend on it. Now there is an update to libkexif, which provides libkexif.so.1. I can't update libkexif without updating the applications depending on it. OK, this is probably something that you know much better than me, and that you've run into several times before, so you probably already know the solution. I've searched a bit, and it seems that Mandrake and Debian both have a policy to include the library soname in the package name : http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowToAdvanced#Library_policy http://www.debian.org/doc/debian-policy/ch-sharedlibs.html How about a similar policy for Fedora ? Is it the best solution to this problem ? Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in: we're computer professionals. We cause accidents." -- Nathaniel Borenstein From peter.backlund at home.se Mon Jan 24 10:45:30 2005 From: peter.backlund at home.se (Peter Backlund) Date: Mon, 24 Jan 2005 11:45:30 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: Message-ID: <1106563530.26412.15.camel@localhost.localdomain> [snip] > solution. I've searched a bit, and it seems that Mandrake and Debian both > have a policy to include the library soname in the package name : > http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowToAdvanced#Library_policy Unrelated, but I have to ask: what is the purpose of defining name/version/release like this: %define name gtkmm %define version 1.2.4 %define release 1mdk and then: Name: %{name} Version: %{version} Release: %{release} I've seen it in a number of spec files. And please no "Well, Mandrake sucks!". /Peter From jos at xos.nl Mon Jan 24 10:43:44 2005 From: jos at xos.nl (Jos Vos) Date: Mon, 24 Jan 2005 11:43:44 +0100 Subject: RFC: Soname in rpm name In-Reply-To: ; from gauret@free.fr on Mon, Jan 24, 2005 at 11:34:03AM +0100 References: Message-ID: <20050124114344.A7757@xos037.xos.nl> On Mon, Jan 24, 2005 at 11:34:03AM +0100, Aurelien Bompard wrote: > A question to packagers: what would you think of a policy to add the library > soname in package libraries ? [...] If I understand your question correct: this is all done automatically when rpm calculates the provides/requires (using the "find-provides" script) when building the package. Look at the package you generated with "rpm -qp --provides package.rpm" and see what it shows. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From fedora-devel at camperquake.de Mon Jan 24 10:42:58 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Mon, 24 Jan 2005 11:42:58 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <1106563530.26412.15.camel@localhost.localdomain> References: <1106563530.26412.15.camel@localhost.localdomain> Message-ID: <20050124114258.113f6245@nausicaa.camperquake.de> Hi. Peter Backlund wrote: > I've seen it in a number of spec files. I'm doing this in my spec files so these three variables are at the very top of the file, while "Name: ..." and the others may be some way further down. -- "Don't be too impatient, Comrade Engineer. We've come very far, very fast." -- from "Doctor Zhivago" From jos at xos.nl Mon Jan 24 10:46:31 2005 From: jos at xos.nl (Jos Vos) Date: Mon, 24 Jan 2005 11:46:31 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <1106563530.26412.15.camel@localhost.localdomain>; from peter.backlund@home.se on Mon, Jan 24, 2005 at 11:45:30AM +0100 References: <1106563530.26412.15.camel@localhost.localdomain> Message-ID: <20050124114631.B7757@xos037.xos.nl> On Mon, Jan 24, 2005 at 11:45:30AM +0100, Peter Backlund wrote: > Unrelated, but I have to ask: what is the purpose of defining > name/version/release like this: > > %define name gtkmm > %define version 1.2.4 > %define release 1mdk > > and then: > > Name: %{name} > Version: %{version} > Release: %{release} > > I've seen it in a number of spec files. Technically useless, except that the idea probably is that the %define's are in top of the spec file and can be found (even) more easy than the corresponding headers when you want to change them. It's a matter of taste (and I personally don't like this). -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From lfarkas at bppiac.hu Mon Jan 24 10:48:32 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Mon, 24 Jan 2005 11:48:32 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <41F4CE96.5070102@redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> <41F4CE96.5070102@redhat.com> Message-ID: <41F4D280.2020901@bppiac.hu> Harald Hoyer wrote: > Bill Nottingham wrote: > >> Not sure: >> - diskcheck > > > mine! why are you not sure? do you know any replacement? -- Levente "Si vis pacem para bellum!" From tmraz at redhat.com Mon Jan 24 10:52:24 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 24 Jan 2005 11:52:24 +0100 Subject: further package removals/potential package removals In-Reply-To: <87651odavq.fsf@londo.ultra.csn.tu-chemnitz.de> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <41F313F7.7679D847@jwz.org> <41F319D2.6080303@nc.rr.com> <87651odavq.fsf@londo.ultra.csn.tu-chemnitz.de> Message-ID: <1106563944.5621.32.camel@perun.redhat.usu> On Sun, 2005-01-23 at 05:31 +0100, Enrico Scholz wrote: > Yes, the stupid kernel packaging which brings 30 MB of bloat into / is a > problem also. But nevertheless, the deps should be cut. A candidate would > be 'pam' which brings 'glib2' in, or all the packages with 'Requires: > kernel>=2.6' which should be either removed or rewritten to 'Conflicts: > kernel<2.6'. The problem is pam_console (and maybe others) modules (which are by default configured to be used) require glib2. And I don't see any possibility to make the pam_console optional. So you can tune your minimum install so the pam_console is removed from all /etc/pam.d/... configs and then you can remove glib2. Or you can write a patch for all pam modules in redhat which use glib2 which replace the functionality provided by glib2 by another means and if it's good it will be applied. But I won't write it as I have many more useful things to do. -- Tomas Mraz From feliciano.matias at free.fr Mon Jan 24 10:57:20 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 24 Jan 2005 11:57:20 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: Message-ID: <1106564240.5600.67.camel@one.myworld> Le lundi 24 janvier 2005 ? 11:34 +0100, Aurelien Bompard a ?crit : > Hi all > > A question to packagers: what would you think of a policy to add the library > soname in package libraries ? For example, I have a libkexif package, which > provides libkexif.so.0, and at least 3 applications depend on it. Now there > is an update to libkexif, which provides libkexif.so.1. I can't update > libkexif without updating the applications depending on it. > OK, this is probably something that you know much better than me, and that > you've run into several times before, so you probably already know the > solution. I've searched a bit, and it seems that Mandrake and Debian both > have a policy to include the library soname in the package name : > http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowToAdvanced#Library_policy > http://www.debian.org/doc/debian-policy/ch-sharedlibs.html > > How about a similar policy for Fedora ? Is it the best solution to this > problem ? > This is done when needed. Example for FC3 : gtkhtml2-2.6.2-1.i386.rpm ; gtkhtml3-3.3.2-3.i386.rpm btw : [fmatias at one i386]$ rpm -q --provides -p gtkhtml2-2.6.2-1.i386.rpm libgtkhtml-2.so.0 <=== gtkhtml2 = 2.6.2-1 [fmatias at one i386]$ rpm -q --provides -p gtkhtml3-3.3.2-3.i386.rpm libgnome-gtkhtml-editor-3.1.so libgtkhtml-3.1.so.11 <=== gtkhtml3 = 3.3.2-3 Other packages must use "Requires : libgtkhtml-2.so" and not "libgtkhtml3" or "gtkhtml3". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From gauret at free.fr Mon Jan 24 10:58:42 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 11:58:42 +0100 Subject: RFC: Soname in rpm name References: <20050124114344.A7757@xos037.xos.nl> Message-ID: Jos Vos wrote: >> A question to packagers: what would you think of a policy to add the >> library soname in package libraries ? [...] > > If I understand your question correct: this is all done automatically > when rpm calculates the provides/requires (using the "find-provides" > script) when building the package. > > Look at the package you generated with "rpm -qp --provides package.rpm" > and see what it shows. $ rpm -qp --provides libkexif-0.2.1-0.fdr.1.i386.rpm libkexif.so.1 libkexif = 0:0.2.1-0.fdr.1 $ sudo rpm -Uvh libkexif-0.2.1-0.fdr.1.i386.rpm libkexif-devel-0.2.1-0.fdr.1.i386.rpm erreur: D?pendances requises: libkexif.so.0 est n?cessaire pour (d?j? install?) kipi-plugins-0.1-0.fdr.0.1.beta1 libkexif.so.0 est n?cessaire pour (d?j? install?) digikam-0.7-0.fdr.1 libkexif.so.0 est n?cessaire pour (d?j? install?) showimg-0.9.4.1-0.fdr.1.2 My point is that if the rpm name contained the soname, version 0.1 and version 0.2 could be installed at the same time, and I would not have to update all the packages depending on it immediatly. With only 3 applications, it's not a very big problem, but it could be a lot worse with a more important library. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info Passwords are like underwear. You shouldn't leave them out where people can see them. You should change them regularly. And you shouldn't loan them out to strangers. From n3npq at nc.rr.com Mon Jan 24 10:59:20 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 05:59:20 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <1106563530.26412.15.camel@localhost.localdomain> References: <1106563530.26412.15.camel@localhost.localdomain> Message-ID: <41F4D508.1080403@nc.rr.com> Peter Backlund wrote: >[snip] > > > >>solution. I've searched a bit, and it seems that Mandrake and Debian both >>have a policy to include the library soname in the package name : >>http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowToAdvanced#Library_policy >> >> > >Unrelated, but I have to ask: what is the purpose of defining >name/version/release like this: > >%define name gtkmm >%define version 1.2.4 >%define release 1mdk > >and then: > >Name: %{name} >Version: %{version} >Release: %{release} > >I've seen it in a number of spec files. > > The is the "Marc Ewing School of Packaging" style, adopted by GNOME, and one of the first attempts at generating *.spec files automagically from scripts, that still flourishes (like a milk weed does. There is no reason whatsoever to use %define's for name/version/release however. >And please no "Well, Mandrake sucks!". > > MDK is RHEL optimized for the i686! Perhaps MDK would be willing to tak over hosting of the endless optimization discussion from fedora-devel too. 73 de Jeff From n3npq at nc.rr.com Mon Jan 24 11:00:58 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 06:00:58 -0500 Subject: RFC: Soname in rpm name In-Reply-To: References: Message-ID: <41F4D56A.1060708@nc.rr.com> Aurelien Bompard wrote: >Hi all > >A question to packagers: what would you think of a policy to add the library >soname in package libraries ? For example, I have a libkexif package, which >provides libkexif.so.0, and at least 3 applications depend on it. Now there >is an update to libkexif, which provides libkexif.so.1. I can't update >libkexif without updating the applications depending on it. >OK, this is probably something that you know much better than me, and that >you've run into several times before, so you probably already know the >solution. I've searched a bit, and it seems that Mandrake and Debian both >have a policy to include the library soname in the package name : >http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowToAdvanced#Library_policy >http://www.debian.org/doc/debian-policy/ch-sharedlibs.html > >How about a similar policy for Fedora ? Is it the best solution to this >problem ? > > Ick. I see the entropic death of packaging, one file per-package. Silly. 73 de Jeff From feliciano.matias at free.fr Mon Jan 24 11:01:01 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 24 Jan 2005 12:01:01 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <1106563530.26412.15.camel@localhost.localdomain> References: <1106563530.26412.15.camel@localhost.localdomain> Message-ID: <1106564461.5600.71.camel@one.myworld> Le lundi 24 janvier 2005 ? 11:45 +0100, Peter Backlund a ?crit : > [snip] > > > solution. I've searched a bit, and it seems that Mandrake and Debian both > > have a policy to include the library soname in the package name : > > http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowToAdvanced#Library_policy > > Unrelated, but I have to ask: what is the purpose of defining > name/version/release like this: > > %define name gtkmm > %define version 1.2.4 > %define release 1mdk > > and then: > > Name: %{name} > Version: %{version} > Release: %{release} > > I've seen it in a number of spec files. What about : %define _name gtkmm %define _version 1.2.4 %define _release 1mdk and then: %define name _name %define version _version %define release _release and then: Name: %{name} Version: %{version} Release: %{release} > > And please no "Well, Mandrake sucks!". > And please no "Well, you suck!". > /Peter > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From gauret at free.fr Mon Jan 24 11:05:46 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 12:05:46 +0100 Subject: RFC: Soname in rpm name References: <41F4D56A.1060708@nc.rr.com> Message-ID: Jeff Johnson wrote: > Ick. I see the entropic death of packaging, one file per-package. Silly. Of course not :) Shared libraries are a different problem however, and it may be nice to install different versions at the same time. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info It is by caffeine alone that I set my mind in motion. It is by the beans of java that the thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone that I set my mind in motion. From n3npq at nc.rr.com Mon Jan 24 11:16:24 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 06:16:24 -0500 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D56A.1060708@nc.rr.com> Message-ID: <41F4D908.5080007@nc.rr.com> Aurelien Bompard wrote: >Jeff Johnson wrote: > > >>Ick. I see the entropic death of packaging, one file per-package. Silly. >> >> > >Of course not :) > I shall have to find the package in Debian that not only added the libraray soname, but every Provides: and configure flag, to the package name as well. The final package name is >4Kb. Seriously, there are othere metadata elements than package name, even if Debian is still confused. >Shared libraries are a different problem however, and it may be nice to >install different versions at the same time. > > Installing multiple libraries with different sonames, and adding sonames to package NEVR, are very different issues. 73 de Jeff From laroche at redhat.com Mon Jan 24 11:54:47 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 24 Jan 2005 12:54:47 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106563944.5621.32.camel@perun.redhat.usu> References: <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <41F313F7.7679D847@jwz.org> <41F319D2.6080303@nc.rr.com> <87651odavq.fsf@londo.ultra.csn.tu-chemnitz.de> <1106563944.5621.32.camel@perun.redhat.usu> Message-ID: <20050124115447.GB6006@dudweiler.stuttgart.redhat.com> On Mon, Jan 24, 2005 at 11:52:24AM +0100, Tomas Mraz wrote: > On Sun, 2005-01-23 at 05:31 +0100, Enrico Scholz wrote: > > Yes, the stupid kernel packaging which brings 30 MB of bloat into / is a > > problem also. But nevertheless, the deps should be cut. A candidate would > > be 'pam' which brings 'glib2' in, or all the packages with 'Requires: > > kernel>=2.6' which should be either removed or rewritten to 'Conflicts: > > kernel<2.6'. For the kernel requires you should file bz requests, glib2 looks small enough to not worry about it IMNSHO. (Just like we don't make pam optional or similar things. ;-) greetings, Florian La Roche > > The problem is pam_console (and maybe others) modules (which are by > default configured to be used) require glib2. And I don't see any > possibility to make the pam_console optional. So you can tune your > minimum install so the pam_console is removed from all /etc/pam.d/... > configs and then you can remove glib2. Or you can write a patch for all > pam modules in redhat which use glib2 which replace the functionality > provided by glib2 by another means and if it's good it will be applied. > But I won't write it as I have many more useful things to do. > > -- > Tomas Mraz > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From feliciano.matias at free.fr Mon Jan 24 11:44:05 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 24 Jan 2005 12:44:05 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: <20050124114344.A7757@xos037.xos.nl> Message-ID: <1106567045.5600.100.camel@one.myworld> Le lundi 24 janvier 2005 ? 11:58 +0100, Aurelien Bompard a ?crit : > $ sudo rpm -Uvh libkexif-0.2.1-0.fdr.1.i386.rpm Try with "rpm -i". > My point is that if the rpm name contained the soname, version 0.1 and > version 0.2 could be installed at the same time, and I would not have to > update all the packages depending on it immediatly. It packages don't conflit you can install multiple packages with the same name. This is done with the kernel package : [fmatias at one i386]$ rpm -q kernel kernel-2.6.10-1.736_FC3.mat.1 kernel-2.6.10-1.750_FC3.mat.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From gauret at free.fr Mon Jan 24 11:44:36 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 12:44:36 +0100 Subject: RFC: Soname in rpm name References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> Message-ID: Jeff Johnson wrote: > Installing multiple libraries with different sonames, and adding sonames > to package NEVR, are very different issues. Really ? How could I install two different versions of the same library without changing the package name then ? Thanks Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info Unix IS user-friendly. It is just very picky about who his friends are. From n3npq at nc.rr.com Mon Jan 24 11:54:09 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 06:54:09 -0500 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> Message-ID: <41F4E1E1.3060708@nc.rr.com> Aurelien Bompard wrote: >Jeff Johnson wrote: > > >>Installing multiple libraries with different sonames, and adding sonames >>to package NEVR, are very different issues. >> >> > >Really ? How could I install two different versions of the same library >without changing the package name then ? > > Try with rpm -i. 73 de Jeff From gauret at free.fr Mon Jan 24 11:59:57 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 12:59:57 +0100 Subject: RFC: Soname in rpm name References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> Message-ID: Jeff Johnson wrote: > Try with rpm -i. Yeah OK. How about something that would be understood by depsolvers then ? This must be a common problem, isn't it ? What do you do when an important library changes its soname in the next version ? Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin From fedora-devel at camperquake.de Mon Jan 24 12:03:56 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Mon, 24 Jan 2005 13:03:56 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <41F4E1E1.3060708@nc.rr.com> References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> Message-ID: <20050124130356.2bb0201e@nausicaa.camperquake.de> Hi. Jeff Johnson wrote: > Try with rpm -i. Try updating that. -- Ray's Rule of Precision: Measure with a micrometer. Mark with chalk. Cut with an axe. Brian's Corollary: Hope like hell. From pknirsch at redhat.com Mon Jan 24 12:04:43 2005 From: pknirsch at redhat.com (Phil Knirsch) Date: Mon, 24 Jan 2005 13:04:43 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> Message-ID: <41F4E45B.6050004@redhat.com> Aurelien Bompard wrote: > Jeff Johnson wrote: > >>Try with rpm -i. > > > Yeah OK. How about something that would be understood by depsolvers then ? > > This must be a common problem, isn't it ? What do you do when an important > library changes its soname in the next version ? > 1) Rebuild all packages that depend on that lib with the new library 2) Every sane depresolver will then pick up the new packages, solve those deps and update the depending packages (the whole deptree) too. If you don't have any updated packages you're screwed anyway, no depsolver can help you with that (and i can't see a depsolver then deciding: "Oh, a new library has some out, lets grab the srpms, automatically rebuild and install them".... *shudder*) Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From feliciano.matias at free.fr Mon Jan 24 12:13:11 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 24 Jan 2005 13:13:11 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> Message-ID: <1106568791.5600.125.camel@one.myworld> Le lundi 24 janvier 2005 ? 12:59 +0100, Aurelien Bompard a ?crit : > Jeff Johnson wrote: > > Try with rpm -i. > > Yeah OK. How about something that would be understood by depsolvers then ? > > This must be a common problem, isn't it ? What do you do when an important > library changes its soname in the next version ? > OK, look at Mandrake : libglib1.2-1.2.10-14mdk.i586.rpm libglib2.0_0-2.4.6-1mdk.i586.rpm Fedora : glib-1.2.10-15.i386.rpm glib2-2.4.7-1.i386.rpm C'est blanc bonnet et bonnet blanc :-) > Aur?lien > -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From n3npq at nc.rr.com Mon Jan 24 12:13:38 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 07:13:38 -0500 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> Message-ID: <41F4E672.3020103@nc.rr.com> Aurelien Bompard wrote: >Jeff Johnson wrote: > > >>Try with rpm -i. >> >> > >Yeah OK. How about something that would be understood by depsolvers then ? > > Depsolvers (at least correctly written ones) use Provides:, not Name:, for choosing what packages to install. The only reason for ornamenting the package name with gunk is to attempt to provide a clue of differences through primitive HTTP/FTP browser GUI's. >This must be a common problem, isn't it ? What do you do when an important >library changes its soname in the next version ? > > Usually a soname is slam-dunked, the library and every package that uses the library are changed at the same time. That works for the distro itself. 73 de Jeff From n3npq at nc.rr.com Mon Jan 24 12:14:47 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 07:14:47 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <20050124130356.2bb0201e@nausicaa.camperquake.de> References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <20050124130356.2bb0201e@nausicaa.camperquake.de> Message-ID: <41F4E6B7.1000900@nc.rr.com> Ralf Ertzinger wrote: >Hi. > >Jeff Johnson wrote: > > > >>Try with rpm -i. >> >> > >Try updating that. > > rpm -e N-V-R && rpm -i N-V-R.A.rpm is exactly an update. 73 de Jeff From fedora at wir-sind-cool.org Mon Jan 24 12:21:38 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 24 Jan 2005 13:21:38 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <41F4E672.3020103@nc.rr.com> References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E672.3020103@nc.rr.com> Message-ID: <20050124132138.2bdbc4c9.fedora@wir-sind-cool.org> On Mon, 24 Jan 2005 07:13:38 -0500, Jeff Johnson wrote: > Aurelien Bompard wrote: > > >Jeff Johnson wrote: > > > > > >>Try with rpm -i. > >> > >> > > > >Yeah OK. How about something that would be understood by depsolvers then ? > > > > > > Depsolvers (at least correctly written ones) use Provides:, not Name:, > for choosing > what packages to install. We need to support what we do have right now. And neither Yum nor "rpm -Uvh" would _not_ upgrade package libfoo to a newer libfoo. > The only reason for ornamenting the package name with gunk is to attempt > to provide > a clue of differences through primitive HTTP/FTP browser GUI's. > > >This must be a common problem, isn't it ? What do you do when an important > >library changes its soname in the next version ? > > > > > > Usually a soname is slam-dunked, the library and every package that uses > the library > are changed at the same time. That works for the distro itself. Does it? Then why do we have packages like openmotif21 and openmotif, libpng10, libpng10-devel, libpng, libpng-devel in the distro? It's not different from what we've done in fedora.us packages. Include parts of the soname version in the package name to make multiple library versions coexist nicely, i.e. also during upgrades. Package resolvers pick the right package based on automatic Provides/Requires. From gauret at free.fr Mon Jan 24 12:23:30 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 13:23:30 +0100 Subject: RFC: Soname in rpm name References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> Message-ID: Phil Knirsch wrote: > 1) Rebuild all packages that depend on that lib with the new library > 2) Every sane depresolver will then pick up the new packages, solve > those deps and update the depending packages (the whole deptree) too. > > If you don't have any updated packages you're screwed anyway, no > depsolver can help you with that (and i can't see a depsolver then > deciding: "Oh, a new library has some out, lets grab the srpms, > automatically rebuild and install them".... shudder) Well, I think that adding the soname to the rpm name could help with that: dependant apps will still require the old package, until they are rebuilt and automatically require the new package. The only con I see is that there may be libraries around which are not required anymore. But that can easily be solved. I think that this problem should be all the more adressed that Fedora is becoming a community-open distribution: the maintainer of the library is not necessarily the maintainer of the dependant apps. There must be an easy upgrade path for those situations. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info No, I coded it crappily on purpose, just so that I could say "There's plenty of room for optimization." From rdieter at math.unl.edu Mon Jan 24 12:30:45 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 24 Jan 2005 06:30:45 -0600 (CST) Subject: RFC: Soname in rpm name In-Reply-To: <1106563530.26412.15.camel@localhost.localdomain> References: <1106563530.26412.15.camel@localhost.localdomain> Message-ID: On Mon, 24 Jan 2005, Peter Backlund wrote: > [snip] > >> solution. I've searched a bit, and it seems that Mandrake and Debian both >> have a policy to include the library soname in the package name : >> http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowToAdvanced#Library_policy > > Unrelated, but I have to ask: what is the purpose of defining > name/version/release like this: > > %define name gtkmm > %define version 1.2.4 > %define release 1mdk > > and then: > > Name: %{name} > Version: %{version} > Release: %{release} > > I've seen it in a number of spec files. I don't see the point of defining name/version/release *twice*. ?? Also, this reply didn't really answer the original question, which was, how to release rpm's to provide multiple versions of the same shared library. -- Rex From gauret at free.fr Mon Jan 24 12:24:42 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 13:24:42 +0100 Subject: RFC: Soname in rpm name References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <1106568791.5600.125.camel@one.myworld> Message-ID: F?liciano Matias wrote: > C'est blanc bonnet et bonnet blanc :-) Agreed, we already do that. If it's considered "good", then could it be a packaging policy ? Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info Programmer: A biological system designed to convert coffee and pizza into code. From n3npq at nc.rr.com Mon Jan 24 12:33:24 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 07:33:24 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <20050124132138.2bdbc4c9.fedora@wir-sind-cool.org> References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E672.3020103@nc.rr.com> <20050124132138.2bdbc4c9.fedora@wir-sind-cool.org> Message-ID: <41F4EB14.3040302@nc.rr.com> Michael Schwendt wrote: >On Mon, 24 Jan 2005 07:13:38 -0500, Jeff Johnson wrote: > > > >>Aurelien Bompard wrote: >> >> >> >>>Jeff Johnson wrote: >>> >>> >>> >>> >>>>Try with rpm -i. >>>> >>>> >>>> >>>> >>>Yeah OK. How about something that would be understood by depsolvers then ? >>> >>> >>> >>> >>Depsolvers (at least correctly written ones) use Provides:, not Name:, >>for choosing >>what packages to install. >> >> > >We need to support what we do have right now. And neither Yum nor >"rpm -Uvh" would _not_ upgrade package libfoo to a newer libfoo. > From multiply installed rpm -i? Sure, no application gets that right. I question "need" however, as "Don't do that." is workable alternative many years now, and there are other techiques, like readline43 and compat-db, that are sufficient for the MUSTHAVE problems. And after incompatible sonames, comes issues with --relocate that noone has ever attempted to solve the upgrade cases for. But I'm sure the java heads will break *.rpm packaging with --relocate for their *.jar files if/when they discover --relocate. Again , there's invariably something along the lines of "Don't do that." that can be devised. > > >>The only reason for ornamenting the package name with gunk is to attempt >>to provide >>a clue of differences through primitive HTTP/FTP browser GUI's. >> >> >> >>>This must be a common problem, isn't it ? What do you do when an important >>>library changes its soname in the next version ? >>> >>> >>> >>> >>Usually a soname is slam-dunked, the library and every package that uses >>the library >>are changed at the same time. That works for the distro itself. >> >> > >Does it? Then why do we have packages like openmotif21 and openmotif, >libpng10, libpng10-devel, libpng, libpng-devel in the distro? > > Because while it works for the distro, slam dunking does not work for 3rd party packing. In fact, slam-dunking is not gonna work for 2nd party packaging like Fedora Extras. What will happen instead (imho) is that library sonames simply won't change, even if they should. >It's not different from what we've done in fedora.us packages. >Include parts of the soname version in the package name to make >multiple library versions coexist nicely, i.e. also during upgrades. >Package resolvers pick the right package based on automatic >Provides/Requires. > > So put sonames into package names if that floats your fedora.us boat. Sooner or later you will run into kernel file system imposed limits on package file names. 73 de Jeff From rdieter at math.unl.edu Mon Jan 24 12:34:10 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 24 Jan 2005 06:34:10 -0600 (CST) Subject: RFC: Soname in rpm name In-Reply-To: References: Message-ID: On Mon, 24 Jan 2005, Aurelien Bompard wrote: > Hi all > > A question to packagers: what would you think of a policy to add the library > soname in package libraries ? For example, I have a libkexif package, which > provides libkexif.so.0, and at least 3 applications depend on it. Now there > is an update to libkexif, which provides libkexif.so.1. I can't update > libkexif without updating the applications depending on it. In this particular case, my suggestion would be to bite the bullet and upgrade libkexif and all apps that depend on it. While were on the subjet of exif, any reason fedora-devel hasn't upgraded to libexif-0.6.x yet? libkexif-0.2.1's configure scriptlet strongly recommends it. -- Rex From rdieter at math.unl.edu Mon Jan 24 12:39:55 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 24 Jan 2005 06:39:55 -0600 (CST) Subject: RFC: Soname in rpm name In-Reply-To: References: Message-ID: On Mon, 24 Jan 2005, Aurelien Bompard wrote: > Hi all > > A question to packagers: what would you think of a policy to add the library > soname in package libraries ? For example, I have a libkexif package, which If it *must* be done, you need to follow (appoximately at least) Mandrake's style, and build libkexif0 libkexif1 ... etc With each (ideally) including Provides: libkexif = %{version} Also, doing it this way, You can't ever have a *real* libkexif rpm pkg anymore due to a recent rpm bug... err... feature: http://bugzilla.redhat.com/bugzilla/130352 http://bugzilla.redhat.com/bugzilla/111071 -- Rex From Nicolas.Mailhot at laPoste.net Mon Jan 24 12:41:23 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 24 Jan 2005 13:41:23 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> Message-ID: <1106570484.32065.1.camel@ulysse.olympe.o2t> Le lundi 24 janvier 2005 ? 13:23 +0100, Aurelien Bompard a ?crit : > Phil Knirsch wrote: > > 1) Rebuild all packages that depend on that lib with the new library > > 2) Every sane depresolver will then pick up the new packages, solve > > those deps and update the depending packages (the whole deptree) too. > > > > If you don't have any updated packages you're screwed anyway, no > > depsolver can help you with that (and i can't see a depsolver then > > deciding: "Oh, a new library has some out, lets grab the srpms, > > automatically rebuild and install them".... shudder) > > Well, I think that adding the soname to the rpm name could help with that: > dependant apps will still require the old package, until they are rebuilt > and automatically require the new package. > The only con I see is that there may be libraries around which are not > required anymore. But that can easily be solved. Well if it can be easily solved how come we still have this problem ? There are several packages that use the soname approach in FC and they are the ones that are a PITA to cleanup now and then Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fedora at wir-sind-cool.org Mon Jan 24 12:45:24 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 24 Jan 2005 13:45:24 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <1106568791.5600.125.camel@one.myworld> Message-ID: <20050124134524.4fe72501.fedora@wir-sind-cool.org> On Mon, 24 Jan 2005 13:24:42 +0100, Aurelien Bompard wrote: > F?liciano Matias wrote: > > C'est blanc bonnet et bonnet blanc :-) > > Agreed, we already do that. If it's considered "good", then could it be a > packaging policy ? Do what's necessary. If you no longer need the older libkexif, because you would rebuild its dependencies against the newer libkexif, you could simply upgrade and need not worry about moving the old one into a package like likexif0. Also note that multiple -devel packages often conflict (e.g. gpgme03-devel, gpgme-devel in pre-extras). Unless you moved libraries _and headers into separate versioned sub-directories. From rdieter at math.unl.edu Mon Jan 24 12:45:01 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 24 Jan 2005 06:45:01 -0600 (CST) Subject: RFC: Soname in rpm name In-Reply-To: <1106570484.32065.1.camel@ulysse.olympe.o2t> References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> Message-ID: On Mon, 24 Jan 2005, Nicolas Mailhot wrote: > Le lundi 24 janvier 2005 ? 13:23 +0100, Aurelien Bompard a ?crit : >> >> Well, I think that adding the soname to the rpm name could help with that: ... > Well if it can be easily solved how come we still have this problem ? > There are several packages that use the soname approach in FC and they > are the ones that are a PITA to cleanup now and then Agreed. Avoid the extra hassle of multiply installed libfoo.so's unless absolutely necessary. Otherwise, it's added complexity and bloat for relatively little gain. -- Rex From Nicolas.Mailhot at laPoste.net Mon Jan 24 12:45:48 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 24 Jan 2005 13:45:48 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <41F4EB14.3040302@nc.rr.com> References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E672.3020103@nc.rr.com> <20050124132138.2bdbc4c9.fedora@wir-sind-cool.org> <41F4EB14.3040302@nc.rr.com> Message-ID: <1106570748.32065.4.camel@ulysse.olympe.o2t> Le lundi 24 janvier 2005 ? 07:33 -0500, Jeff Johnson a ?crit : > But I'm sure the java heads will break *.rpm packaging with --relocate for > their *.jar files if/when they discover --relocate. Again , > there's invariably > something along the lines of "Don't do that." that can be devised. Actually java is so bad at searching jars they'll be the last thing anyone wants to relocate. Too many hardcoded classpathes everywhere... -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From gauret at free.fr Mon Jan 24 12:48:01 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 13:48:01 +0100 Subject: RFC: Soname in rpm name References: Message-ID: Rex Dieter wrote: > In this particular case, my suggestion would be to bite the bullet and > upgrade libkexif and all apps that depend on it. Well, that's what I'm going to do, because by chance I also maintain the apps depending on it. But in a community-open distribution, it does not have to be the case. My very own particular problem is not significant, I'd just like to raise the general issue so that we could work out a general solution. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Make everything as simple as possible, but not simpler." -- Albert Einstein From fedora at wir-sind-cool.org Mon Jan 24 12:51:44 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 24 Jan 2005 13:51:44 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <41F4EB14.3040302@nc.rr.com> References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E672.3020103@nc.rr.com> <20050124132138.2bdbc4c9.fedora@wir-sind-cool.org> <41F4EB14.3040302@nc.rr.com> Message-ID: <20050124135144.7dae23a7.fedora@wir-sind-cool.org> On Mon, 24 Jan 2005 07:33:24 -0500, Jeff Johnson wrote: > >>>Jeff Johnson wrote: > >>> > >>> > >>> > >>> > >>>>Try with rpm -i. > >>>> > >>>> > >>>> > >>>> > >>>Yeah OK. How about something that would be understood by depsolvers then ? > >>> > >>> > >>> > >>> > >>Depsolvers (at least correctly written ones) use Provides:, not Name:, > >>for choosing > >>what packages to install. > >> > >> > > > >We need to support what we do have right now. And neither Yum nor > >"rpm -Uvh" would _not_ upgrade package libfoo to a newer libfoo. > > > > From multiply installed rpm -i? Sure, no application gets that right. No. The scenario is like this: Installed is: libfoo-0.9-3 (which provides libfoo.so.0) Packager releases: libfoo-1.0-1 (which provides libfoo.so.1) Then "rpm -ivh libfoo-1.0-1.i386.rpm" works just fine and installs the new library package in parallel, provided that no file conflicts between libfoo-0.9-3 and libfoo-1.0-1 exist. On the contrary, "rpm -Uvh libfoo-1.0-1.i386.rpm" and "yum -y update" would get rid of the old libfoo, running into broken dependencies if other installed packages still require the libfoo.so.0 soname. > >It's not different from what we've done in fedora.us packages. > >Include parts of the soname version in the package name to make > >multiple library versions coexist nicely, i.e. also during upgrades. > >Package resolvers pick the right package based on automatic > >Provides/Requires. > > > > > > So put sonames into package names if that floats your fedora.us boat. > Sooner or later you > will run into kernel file system imposed limits on package file names. > From n3npq at nc.rr.com Mon Jan 24 12:51:57 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 07:51:57 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <1106570748.32065.4.camel@ulysse.olympe.o2t> References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E672.3020103@nc.rr.com> <20050124132138.2bdbc4c9.fedora@wir-sind-cool.org> <41F4EB14.3040302@nc.rr.com> <1106570748.32065.4.camel@ulysse.olympe.o2t> Message-ID: <41F4EF6D.8090308@nc.rr.com> Nicolas Mailhot wrote: >Le lundi 24 janvier 2005 ? 07:33 -0500, Jeff Johnson a ?crit : > > > >>But I'm sure the java heads will break *.rpm packaging with --relocate for >>their *.jar files if/when they discover --relocate. Again , >>there's invariably >>something along the lines of "Don't do that." that can be devised. >> >> > >Actually java is so bad at searching jars they'll be the last thing >anyone wants to relocate. Too many hardcoded classpathes everywhere... > > So I hear. What's sad is that "hardcoded classpaths" is exactly what rpm (and packaging) might help rationalize, mapping the classpath mechanism into package dependencies. rpm will get to java dependencies some day. I'm not gonna hold my breath, though, because java culture is so vastly different than other coding, and the java heads seem to wish to exist separate-but-equal until they get around to writing a kernel in java that runs everywhere. 73 de Jeff From gauret at free.fr Mon Jan 24 12:54:43 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 13:54:43 +0100 Subject: RFC: Soname in rpm name References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E672.3020103@nc.rr.com> <20050124132138.2bdbc4c9.fedora@wir-sind-cool.org> <41F4EB14.3040302@nc.rr.com> Message-ID: Jeff Johnson wrote: > So put sonames into package names if that floats your fedora.us boat. > Sooner or later you will run into kernel file system imposed limits on > package file names. How many characters could it add ? 2 digits ? 3 digits max ? How about that : $ rpm -q bash-completion bash-completion-0.0-0.fdr.4.20041017 I see your point, adding something else than the name into the package Name tag is opening the door to crazy things, like configure tags (is there really a Debian package with configure tags in the name ???). Still, I think that it could be very beneficial to provide easy upgrade paths. I think that the advantages overcome the shorcomings in this situation. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Science sans conscience n'est que ruine de l'?me." -- Rabelais From fedora at wir-sind-cool.org Mon Jan 24 13:01:00 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 24 Jan 2005 14:01:00 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: Message-ID: <20050124140100.65a87410.fedora@wir-sind-cool.org> On Mon, 24 Jan 2005 06:39:55 -0600 (CST), Rex Dieter wrote: > On Mon, 24 Jan 2005, Aurelien Bompard wrote: > > > Hi all > > > > A question to packagers: what would you think of a policy to add the library > > soname in package libraries ? For example, I have a libkexif package, which > > If it *must* be done, you need to follow (appoximately at least) > Mandrake's style, and build > libkexif0 > libkexif1 > ... etc > > With each (ideally) including > Provides: libkexif = %{version} > > Also, doing it this way, You can't ever have a *real* libkexif rpm pkg > anymore due to a recent rpm bug... err... feature: > http://bugzilla.redhat.com/bugzilla/130352 > http://bugzilla.redhat.com/bugzilla/111071 Add this one to the list: https://bugzilla.redhat.com/145091#c6 From gauret at free.fr Mon Jan 24 13:06:56 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 14:06:56 +0100 Subject: RFC: Soname in rpm name References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> Message-ID: Nicolas Mailhot wrote: > Well if it can be easily solved how come we still have this problem ? > There are several packages that use the soname approach in FC and they > are the ones that are a PITA to cleanup now and then I did not know, is it possible to have a tool find the rpms that no rpms depend on, and ask to remove them ? For this task, Debian has something called deborphan (which might do more than that) and Mandrake has "urpm-find-leaves" IIRC. Maybe that could be a start. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info A Black Hole is where God divided by zero. From darrint at progeny.com Mon Jan 24 13:14:20 2005 From: darrint at progeny.com (Darrin Thompson) Date: Mon, 24 Jan 2005 08:14:20 -0500 Subject: suggests/requires in rpm In-Reply-To: <41F41E70.6080102@nc.rr.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com> Message-ID: <1106572460.3877.8.camel@localhost.localdomain> On Sun, 2005-01-23 at 17:00 -0500, Jeff Johnson wrote: > The specific difference is that dependencies marked with "missingok" are > passed to > a depsolver, which is entirely at liberty to do whatever it wants with > the information. > > And the other difference is that rpmlib is responsibly only for passing > the information > to the depsolver, and then ignoring the dependecy. > > That definition is well defined mechanism, unlike Recommends: et al. > You've made the "definition" easy to implement but left the whole question of what the user can expect to happen undefined. Choosing not to define is clever, but it isn't the same as defining something. "missingok" may be superior to the Debian headers, but calling it well defined is a poor argument, at least based on what you've said here. -- Darrin From gauret at free.fr Mon Jan 24 13:12:45 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 14:12:45 +0100 Subject: RFC: Soname in rpm name References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <1106568791.5600.125.camel@one.myworld> <20050124134524.4fe72501.fedora@wir-sind-cool.org> Message-ID: Michael Schwendt wrote: > Do what's necessary. If you no longer need the older libkexif, because > you would rebuild its dependencies against the newer libkexif, you > could simply upgrade and need not worry about moving the old one into > a package like likexif0. I see. That's what I'm going to do beacause by chance I also maintain the applications depending on libkexif. The point of my post is not to solve my own problem, but rather to extract a policy for new packagers running into this problem. So the unofficial "policy" about this is to keep the regular name across upgrades, and to provide an rpm with the soname in the "Name" tag for older versions (if needed). OK, fine. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info L'exp?rience est quelquechose que l'on acquiert juste apr?s en avoir eu besoin. From symbiont at berlios.de Mon Jan 24 13:17:26 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 24 Jan 2005 21:17:26 +0800 Subject: RFC: Soname in rpm name In-Reply-To: References: <1106570484.32065.1.camel@ulysse.olympe.o2t> Message-ID: <200501242117.27158.symbiont@berlios.de> On Monday 24 January 2005 21:06, Aurelien Bompard wrote: > Nicolas Mailhot wrote: > > Well if it can be easily solved how come we still have this problem > > ? There are several packages that use the soname approach in FC and > > they are the ones that are a PITA to cleanup now and then > > I did not know, is it possible to have a tool find the rpms that no > rpms depend on, and ask to remove them ? For this task, Debian has > something called deborphan (which might do more than that) and > Mandrake has "urpm-find-leaves" IIRC. Maybe that could be a start. It'll be slow to materialize. Key factor is that this is usually a result of: 1. Using third party repositories. 2. Doing dist upgrades. Neither of which finds amicable or fruitful discussion. Bad-blood carryover from earlier days. -- -jeff From feliciano.matias at free.fr Mon Jan 24 13:21:24 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 24 Jan 2005 14:21:24 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <1106568791.5600.125.camel@one.myworld> Message-ID: <1106572884.5600.136.camel@one.myworld> Le lundi 24 janvier 2005 ? 13:24 +0100, Aurelien Bompard a ?crit : > F?liciano Matias wrote: > > C'est blanc bonnet et bonnet blanc :-) > > Agreed, we already do that. If it's considered "good", then could it be a > packaging policy ? > Why not. But : http://fedora.redhat.com/about/objectives.html Non-Objectives of Fedora Core: (...) 3-Being a dumping ground for unmaintained or poorly designed software. The objectives of fedora is not to provide support for legacy libraries. I use RH/Fedora for many years and personally, I don't really care about multi lib.so. I don't remember to be annoyed by this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rdieter at math.unl.edu Mon Jan 24 13:23:24 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 24 Jan 2005 07:23:24 -0600 (CST) Subject: suggests/requires in rpm In-Reply-To: <1106572460.3877.8.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com> <1106572460.3877.8.camel@localhost.localdomain> Message-ID: On Mon, 24 Jan 2005, Darrin Thompson wrote: > On Sun, 2005-01-23 at 17:00 -0500, Jeff Johnson wrote: >> The specific difference is that dependencies marked with "missingok" are >> passed to >> a depsolver, which is entirely at liberty to do whatever it wants with ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> the information. ^^^^^^^^^^^^^^^^^^ > You've made the "definition" easy to implement but left the whole > question of what the user can expect to happen undefined. Choosing not I, for one, thought Jeff was clear that it's the job of depsolvers (anaconda, yum, smart, apt) to decide what to do with the extra information. -- Rex From feliciano.matias at free.fr Mon Jan 24 13:26:31 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 24 Jan 2005 14:26:31 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> Message-ID: <1106573191.5600.140.camel@one.myworld> Le lundi 24 janvier 2005 ? 14:06 +0100, Aurelien Bompard a ?crit : > > I did not know, is it possible to have a tool find the rpms that no rpms > depend on, and ask to remove them ? For this task, Debian has something > called deborphan (which might do more than that) and Mandrake has > "urpm-find-leaves" IIRC. Maybe that could be a start. > Not perfect : $ rpm -q -a | xargs -i bash -c "rpm -e --test {} > /dev/null 2>&1 && echo {}" -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From n3npq at nc.rr.com Mon Jan 24 13:25:56 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 08:25:56 -0500 Subject: suggests/requires in rpm In-Reply-To: <1106572460.3877.8.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com> <1106572460.3877.8.camel@localhost.localdomain> Message-ID: <41F4F764.9000005@nc.rr.com> Darrin Thompson wrote: >On Sun, 2005-01-23 at 17:00 -0500, Jeff Johnson wrote: > > >>The specific difference is that dependencies marked with "missingok" are >>passed to >>a depsolver, which is entirely at liberty to do whatever it wants with >>the information. >> >>And the other difference is that rpmlib is responsibly only for passing >>the information >>to the depsolver, and then ignoring the dependecy. >> >>That definition is well defined mechanism, unlike Recommends: et al. >> >> >> > >You've made the "definition" easy to implement but left the whole >question of what the user can expect to happen undefined. Choosing not >to define is clever, but it isn't the same as defining something. >"missingok" may be superior to the Debian headers, but calling it well >defined is a poor argument, at least based on what you've said here. > > OK, so call the scheme "implementable" rather than "well defined". Unlike Suggests: Enhances: Recommends: which all cater to user expectations, and have never been well implemented, even in apt. "Not implemented." has never stopped user expectations before, "missingok" will be exactly the same. 73 de Jeff From skvidal at phy.duke.edu Mon Jan 24 13:35:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 24 Jan 2005 08:35:33 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106552224.7211.623.camel@mccallum.corsepiu.local> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> <1106552224.7211.623.camel@mccallum.corsepiu.local> Message-ID: <1106573733.3597.31.camel@cutter> > ATM, Extras isn't much more than a "promise", ... we will see if it will > come and if when it will work out. just consider pre-extras as 'extras' for now. -sv From symbiont at berlios.de Mon Jan 24 13:34:30 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 24 Jan 2005 21:34:30 +0800 Subject: RFC: Soname in rpm name In-Reply-To: <1106572884.5600.136.camel@one.myworld> References: <1106572884.5600.136.camel@one.myworld> Message-ID: <200501242134.32494.symbiont@berlios.de> On Monday 24 January 2005 21:21, F?liciano Matias wrote: > I don't remember to be annoyed by this. You probably didn't remember because non-participation in making apps requiring older libs makes it a bit difficult. When upstream doesn't update API calls in time for full dist release, then it's gonna be a problem. Consider openssl; other examples abound. -- -jeff From buildsys at redhat.com Mon Jan 24 13:36:00 2005 From: buildsys at redhat.com (Build System) Date: Mon, 24 Jan 2005 08:36:00 -0500 Subject: rawhide report: 20050124 changes Message-ID: <200501241336.j0ODa0R07510@porkchop.devel.redhat.com> Updated Packages: NetworkManager-0.3.3-1.cvs20050112.4 ------------------------------------ * Mon Jan 24 2005 Than Ngo 0.3.3-1.cvs20050112.4 - rebuilt against new wireless tool dump-0.4b39-1 ------------- * Mon Jan 24 2005 Jindrich Novy 0.10.9-1 - release fixes the following security-related issues: - The COPS dissector could go into an infinite loop. (CAN-2005-0006) - The DLSw dissector could cause an assertion, making Ethereal exit prematurely. (CAN-2005-0007) - The DNP dissector could cause memory corruption. (CAN-2005-0008) - The Gnutella dissector could cause an assertion, making Ethereal exit prematurely. (CAN-2005-0009) - The MMSE dissector could free static memory. (CAN-2005-0010) - The X11 protocol dissector is vulnerable to a string buffer overflow. (CAN-2005-0084) - (#145482) * Tue Jan 18 2005 Radek Vokal 0.10.8-4 - plugins are back * Thu Jan 06 2005 Radek Vokal 0.10.8-3 - fixed spec file, removed libs renaming file-4.12-3 ----------- * Mon Jan 24 2005 Radek Vokal - 4.12-3 - core64 patch fixing output on core files (#145354) - minor change in magic patch gimp-2:2.2.3-1 -------------- * Mon Jan 24 2005 Nils Philippsen - version 2.2.3 - remove exifmarkerlength patch (improved version applied upstream) kdenetwork-7:3.3.2-0.3 ---------------------- * Mon Jan 24 2005 Than Ngo 7:3.3.2-0.3 - rebuilt against new wireless tools kernel-2.6.10-1.1109_FC4 ------------------------ * Sun Jan 23 2005 Dave Jones - Updated periodic slab debug check from Manfred. - Enable PAGE_ALLOC debugging again, it should now be fixed. - 2.6.11-rc2-bk1 libxfce4mcs-4.2.0-1 ------------------- * Sun Jan 23 2005 Than Ngo 4.2.0-1 - update to 4.2.0 libxfce4util-4.2.0-1 -------------------- * Sun Jan 23 2005 Than Ngo 4.2.0-1 - update to 4.2.0 release libxfcegui4-4.2.0-1 ------------------- * Sun Jan 23 2005 Than Ngo 4.2.0-1 - update to 4.2.0 reiserfs-utils-2:3.6.19-1 ------------------------- * Sun Jan 23 2005 Florian La Roche - 3.6.19 rpmdb-fedora-1:4-0.20050124 --------------------------- xfce-mcs-manager-4.2.0-1 ------------------------ * Sun Jan 23 2005 Than Ngo 4.2.0-1 - update to 4.2.0 From darrint at progeny.com Mon Jan 24 13:53:49 2005 From: darrint at progeny.com (Darrin Thompson) Date: Mon, 24 Jan 2005 08:53:49 -0500 Subject: suggests/requires in rpm In-Reply-To: <41F4F764.9000005@nc.rr.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com> <1106572460.3877.8.camel@localhost.localdomain> <41F4F764.9000005@nc.rr.com> Message-ID: <1106574829.3877.11.camel@localhost.localdomain> On Mon, 2005-01-24 at 08:25 -0500, Jeff Johnson wrote: > OK, so call the scheme "implementable" rather than "well defined". > > Unlike Suggests: Enhances: Recommends: which all cater to user expectations, > and have never been well implemented, even in apt. > > "Not implemented." has never stopped user expectations before, "missingok" > will be exactly the same. > Fair enough. As long as no depsolver is confused into leaving out a security update there shouldn't be too much complaining. -- Darrin From pmatilai at welho.com Mon Jan 24 13:26:11 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Mon, 24 Jan 2005 15:26:11 +0200 (EET) Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> Message-ID: On Mon, 24 Jan 2005, Aurelien Bompard wrote: > Nicolas Mailhot wrote: >> Well if it can be easily solved how come we still have this problem ? >> There are several packages that use the soname approach in FC and they >> are the ones that are a PITA to cleanup now and then > > I did not know, is it possible to have a tool find the rpms that no rpms > depend on, and ask to remove them ? For this task, Debian has something > called deborphan (which might do more than that) and Mandrake has > "urpm-find-leaves" IIRC. Maybe that could be a start. Check out this for example: http://lists.freshrpms.net/pipermail/freshrpms-list/2003-March/003391.html - Panu - From fedora-devel at camperquake.de Mon Jan 24 14:11:36 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Mon, 24 Jan 2005 15:11:36 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> Message-ID: <20050124151136.31801589@nausicaa.camperquake.de> Hi. Aurelien Bompard wrote: > I did not know, is it possible to have a tool find the rpms that no rpms > depend on, and ask to remove them ? The problem with this is that RPM does not indicate whether a package has "end user value" (a command line or GUI program, or a daemon), or is just a support library needed by said end user programs, which can be removed if not needed by anyone. -- <@Zeroth>Frickelsoftware! <@pretec>Kommunistische! <@Zeroth>Von bekifften, stinkenden, Langzeitlanghaarstudenten in Bastelbudenkellern programmiert -- #lug-kiel, Oct 13 2004 From elanthis at awesomeplay.com Mon Jan 24 14:15:14 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 24 Jan 2005 09:15:14 -0500 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> Message-ID: <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> On Mon, 2005-01-24 at 06:45 -0600, Rex Dieter wrote: > On Mon, 24 Jan 2005, Nicolas Mailhot wrote: > > > Le lundi 24 janvier 2005 ? 13:23 +0100, Aurelien Bompard a ?crit : > >> > >> Well, I think that adding the soname to the rpm name could help with that: > ... > > Well if it can be easily solved how come we still have this problem ? > > There are several packages that use the soname approach in FC and they > > are the ones that are a PITA to cleanup now and then > > Agreed. Avoid the extra hassle of multiply installed libfoo.so's unless > absolutely necessary. Otherwise, it's added complexity and bloat for > relatively little gain. It's the entire reason why _have_ library sonames... We _have_ had this problem, btw. The problem is that it's not generally developers that notice it. It's the user that just want to have their machine work. I go to install third party app Foo from Foo's web site, it needs libbar.so.2, Fedora only has libbar.so.1, and many other apps on the net require libbar.so.1. You can't just upgrade apps to use libbar.so.2 because it's a *different library*, it might require massive code changes in order to use - if it were something compatible there wouldn't be a problem at all. Both libraries can be installed at once (again, the whole bloody reason we _have_ sonames), but because the packaging creates an artificial incompatibility that only exists because the package is, put plainly, braindead and broken, the user can't install Foo. Now you, as a developer or experienced Linux admin, can easily solve this. Maybe you install the library from source. Maybe you rpm -i the new library package. Both are things that the average person - even if they _are_ an experienced Linux user - shouldn't have the waste time doing. Every hour of your life that you spend working around broken, lazy, braindead library packaging is an hour you could have spent with your family, friends, doing something you enjoy, working on some new Free Software, etc. The system is designed so that multiple libraries that are incompatible can be installed at the same time. Let's not have the packaging system continue to break that because of something so incredibly trite and meaningless as the aesthetics of the rpm -qa output when you have the two versions installed. > > -- Rex > -- fedora-devel-list mailing list fedora-devel-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list From n3npq at nc.rr.com Mon Jan 24 14:16:52 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 09:16:52 -0500 Subject: suggests/requires in rpm In-Reply-To: <1106574829.3877.11.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com> <1106572460.3877.8.camel@localhost.localdomain> <41F4F764.9000005@nc.rr.com> <1106574829.3877.11.camel@localhost.localdomain> Message-ID: <41F50354.2030108@nc.rr.com> Darrin Thompson wrote: >On Mon, 2005-01-24 at 08:25 -0500, Jeff Johnson wrote: > > > >Fair enough. As long as no depsolver is confused into leaving out a >security update there shouldn't be too much complaining. > A busted mirror or a missing dependency will stop a seurity update far more effectively than "missingok", don't fool yerself. 73 de Jeff From skvidal at phy.duke.edu Mon Jan 24 14:32:17 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 24 Jan 2005 09:32:17 -0500 Subject: suggests/requires in rpm In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com> <1106572460.3877.8.camel@localhost.localdomain> Message-ID: <1106577137.3597.36.camel@cutter> > I, for one, thought Jeff was clear that it's the job of depsolvers > (anaconda, yum, smart, apt) to decide what to do with the extra > information. All that's really been done is to push the decision-making process off on the depsolvers. It hasn't resolved the problem, just resolved the problem for rpm. -sv From seyman at wanadoo.fr Mon Jan 24 14:39:53 2005 From: seyman at wanadoo.fr (Emmanuel Seyman) Date: Mon, 24 Jan 2005 15:39:53 +0100 Subject: suggests/requires in rpm In-Reply-To: <1106577137.3597.36.camel@cutter> References: <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com> <1106572460.3877.8.camel@localhost.localdomain> <1106577137.3597.36.camel@cutter> Message-ID: <20050124143953.GA9444@orient.maison.moi> On Mon, Jan 24, 2005 at 09:32:17AM -0500, seth vidal wrote: > > All that's really been done is to push the decision-making process off > on the depsolvers. Am I the only one who finds this is the right thing to do? (tm) Depsolvers solve dependencies. This is just a special kind of dependency (one amongst many). Emmanuel From n3npq at nc.rr.com Mon Jan 24 14:40:19 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 09:40:19 -0500 Subject: suggests/requires in rpm In-Reply-To: <1106577137.3597.36.camel@cutter> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com> <1106572460.3877.8.camel@localhost.localdomain> <1106577137.3597.36.camel@cutter> Message-ID: <41F508D3.7060409@nc.rr.com> seth vidal wrote: >>I, for one, thought Jeff was clear that it's the job of depsolvers >>(anaconda, yum, smart, apt) to decide what to do with the extra >>information. >> >> > >All that's really been done is to push the decision-making process off >on the depsolvers. > >It hasn't resolved the problem, just resolved the problem for rpm. > > Au contraire. Change no yum code, i.e. don't look at the RPMSENSE_MISSINGOK bit, and you have exactly the existing behavior. Meanwhile, rpm -e becomes possible for end-users, albeit at the expense of flip-flop through anaconda. That appears to be progress forward. OTOH -- without an RFE in bugzilla -- I shall not waste 3 hours on an implementation, and so no problem whatsoever has been, or will be, resolved. Criminey, how hard is it to check a bit that marks an edge in a graph "optional"? You'ld think this was NPTL or SELinux. 73 de Jeff From jspaleta at gmail.com Mon Jan 24 14:43:42 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Jan 2005 09:43:42 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106552224.7211.623.camel@mccallum.corsepiu.local> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> <1106552224.7211.623.camel@mccallum.corsepiu.local> Message-ID: <604aa791050124064359d477fe@mail.gmail.com> On Mon, 24 Jan 2005 08:37:04 +0100, Ralf Corsepius wrote: > IMO, if you want to remove joe from Core, you should be consequent and > remove vi, emacs, xemacs, etc. too and let only ship one single, small > and statically linked ascii text-editor remain in Core, may-be nano. > Otherwise I would recommend to remove nano, because I don't see any > reason why it should be integrated into Core. There is value in having one ascii editor in Core when doing system troubleshooting. Bugs still happen.. misconfigurations still happen(more than bugs) and when you are trying to walk someone through troubleshooting or workarounds in a mailinglist, forum, or irc... it can be much simplier to have them use an ascii editor to make corrections to system configuration text files and sometimes necessary if there is a misconfiguration that prevents X from starting. -jef From nphilipp at redhat.com Mon Jan 24 14:46:58 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Mon, 24 Jan 2005 15:46:58 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <20050124151136.31801589@nausicaa.camperquake.de> References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> Message-ID: <1106578018.8573.2.camel@gibraltar.stuttgart.redhat.com> On Mon, 2005-01-24 at 15:11 +0100, Ralf Ertzinger wrote: > Hi. > > Aurelien Bompard wrote: > > > I did not know, is it possible to have a tool find the rpms that no rpms > > depend on, and ask to remove them ? > > The problem with this is that RPM does not indicate whether a package has > "end user value" (a command line or GUI program, or a daemon), or is just > a support library needed by said end user programs, which can be removed > if not needed by anyone. Though you won't 100% find out -- at this moment -- whether a library package is needed because the library can be dlopen()ed and this is usually not encoded into package requirements (yet), cf. the current "suggests/requires in rpm" thread. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From cra at WPI.EDU Mon Jan 24 14:47:39 2005 From: cra at WPI.EDU (Charles R. Anderson) Date: Mon, 24 Jan 2005 09:47:39 -0500 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> Message-ID: <20050124144739.GC7619@angus.ind.WPI.EDU> On Mon, Jan 24, 2005 at 12:59:57PM +0100, Aurelien Bompard wrote: > Jeff Johnson wrote: > > Try with rpm -i. > > Yeah OK. How about something that would be understood by depsolvers then ? installonly packages are already well understood by depsolvers. Look at the kernel packages. yum.conf: installonlypkgs= From fedora at wir-sind-cool.org Mon Jan 24 15:01:20 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 24 Jan 2005 16:01:20 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <20050124144739.GC7619@angus.ind.WPI.EDU> References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <20050124144739.GC7619@angus.ind.WPI.EDU> Message-ID: <20050124160120.2f20c1c8.fedora@wir-sind-cool.org> On Mon, 24 Jan 2005 09:47:39 -0500, Charles R. Anderson wrote: > On Mon, Jan 24, 2005 at 12:59:57PM +0100, Aurelien Bompard wrote: > > Jeff Johnson wrote: > > > Try with rpm -i. > > > > Yeah OK. How about something that would be understood by depsolvers then ? > > installonly packages are already well understood by depsolvers. Look > at the kernel packages. > > yum.conf: > > installonlypkgs= > Nah, that's only a work-around. There's no way for a repository to flag packages as install-only. From jspaleta at gmail.com Mon Jan 24 15:02:52 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Jan 2005 10:02:52 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <604aa791050124070243cfe95f@mail.gmail.com> On Mon, 24 Jan 2005 09:15:14 -0500, Sean Middleditch wrote: > We _have_ had this problem, btw. The problem is that it's not generally > developers that notice it. It's the user that just want to have their > machine work. I go to install third party app Foo from Foo's web site, > it needs libbar.so.2, Fedora only has libbar.so.1, and many other apps > on the net require libbar.so.1. A third part website is packaging libbar.so.2 in a package of the same package name as Feodora's libbar.so.1? Why would a third party site do that? Unless the intention was to replace the Fedora package? Isn't this an example of the care 3rd party packagers should be taking to make sure their packages work well with Core? And I might add.. that while users and admins.. might want to install many other apps from anywhere on the net that the find them... this is not necessarily advisable behavior. You continue to cater to this sort of thing and you will end up with people install very old libraries that are no longer being maintained so that they can install very old applications that are no longer being maintained and could have unresolved but well understood security problems. I'm really not sure its in anyones best interest to make it really drop-dead easy to install unmaintained software that might be expoitable simply because the package was created in 2000. -jef From darrint at progeny.com Mon Jan 24 15:06:30 2005 From: darrint at progeny.com (Darrin Thompson) Date: Mon, 24 Jan 2005 10:06:30 -0500 Subject: suggests/requires in rpm In-Reply-To: <41F50354.2030108@nc.rr.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com> <1106572460.3877.8.camel@localhost.localdomain> <41F4F764.9000005@nc.rr.com> <1106574829.3877.11.camel@localhost.localdomain> <41F50354.2030108@nc.rr.com> Message-ID: <1106579190.3877.33.camel@localhost.localdomain> On Mon, 2005-01-24 at 09:16 -0500, Jeff Johnson wrote: > A busted mirror or a missing dependency will stop a seurity update far > more effectively > than "missingok", don't fool yerself. Certainly. But could missingok ever ever ever stop a security update? Of course not, so long as packagers or package manager authors don't do anything stupid. :-D I think what bothers me about this is that I'm having trouble identifying what I trust in the before missingok scenario vs. what I mistrust in the after scenario. I think it's that the correct use of the feature is distributed so widely that it would be hard for me to reestablish trust in the new regime. My guess is that you are right about this. It's just that there's a lot more to it than meets the eye. I have a little trouble getting my head around all of it. I have to be cautious because I have customers who want their precious, (pant pant) PRECIOUS security updates. -- Darrin From symbiont at berlios.de Mon Jan 24 15:08:05 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 24 Jan 2005 23:08:05 +0800 Subject: suggests/requires in rpm In-Reply-To: <1106577137.3597.36.camel@cutter> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106577137.3597.36.camel@cutter> Message-ID: <200501242308.07535.symbiont@berlios.de> On Monday 24 January 2005 22:32, seth vidal wrote: > > I, for one, thought Jeff was clear that it's the job of depsolvers > > (anaconda, yum, smart, apt) to decide what to do with the extra > > information. > > All that's really been done is to push the decision-making process > off on the depsolvers. Which is what it should do. Depsolvers are becoming the defacto interface to the packaging system; responsibility may feel burdensome at times, but it's a pretty clear distinction to implement these processes at this level. The less magic RPM does, the better. Depsolvers are more fluid than RPM, which is why they should acquire the necessary complex logic. Heretofore mentioned bugzillas already clearly show why magic is a BadThing at the RPM level and that the depsolvers should be charged to make these decisions: > http://bugzilla.redhat.com/bugzilla/130352 > http://bugzilla.redhat.com/bugzilla/111071 > https://bugzilla.redhat.com/145091#c6 -- -jeff From elanthis at awesomeplay.com Mon Jan 24 15:10:17 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 24 Jan 2005 10:10:17 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <20050124160120.2f20c1c8.fedora@wir-sind-cool.org> References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <20050124144739.GC7619@angus.ind.WPI.EDU> <20050124160120.2f20c1c8.fedora@wir-sind-cool.org> Message-ID: <1106579417.2365.15.camel@support02.civic.twp.ypsilanti.mi.us> On Mon, 2005-01-24 at 16:01 +0100, Michael Schwendt wrote: > On Mon, 24 Jan 2005 09:47:39 -0500, Charles R. Anderson wrote: > > > On Mon, Jan 24, 2005 at 12:59:57PM +0100, Aurelien Bompard wrote: > > > Jeff Johnson wrote: > > > > Try with rpm -i. > > > > > > Yeah OK. How about something that would be understood by depsolvers then ? > > > > installonly packages are already well understood by depsolvers. Look > > at the kernel packages. > > > > yum.conf: > > > > installonlypkgs= > > > > Nah, that's only a work-around. There's no way for a repository to flag > packages as install-only. Using the rpm install method also breaks upgrades. Say you have libfoo-1.0 and libfoo-2.0. Many apps use libfoo-1.0 and will continue to do so because it's a massive API upgrade to libfoo-2.0. think gtk1 vs gtk2. Now a security bug is found in the 1.0 branch, and the developers realize that a lot of users are stuck with apps using that branch, so they release 1.1 with the security update (as the version indicates, it's backwards compatible with 1.0), so libfoo-1.1 is released. With rpm install-only packages libfoo-1.1 would not be installed unless the user manually told the system to do it, since libfoo-2.0 is installed and is newer. The only way for this to work is make RPM recognize that libfoo-1.0 and libfoo-2.0 are completely different packages. Just because they're both libfoo is irrelevant, they are different APIs and different ABIs. In GTK's case the second version just got a two appended. Packages are gtk and gtk2. While that works, in the general case, using the soversion probably just makes more sense. The packages could be, for example, libfoo1.0 and libfoo2.0. The specifics aren't that important, just so long as it works. From skvidal at phy.duke.edu Mon Jan 24 15:11:59 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 24 Jan 2005 10:11:59 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <20050124144739.GC7619@angus.ind.WPI.EDU> References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <20050124144739.GC7619@angus.ind.WPI.EDU> Message-ID: <1106579519.25770.0.camel@opus.phy.duke.edu> On Mon, 2005-01-24 at 09:47 -0500, Charles R. Anderson wrote: > On Mon, Jan 24, 2005 at 12:59:57PM +0100, Aurelien Bompard wrote: > > Jeff Johnson wrote: > > > Try with rpm -i. > > > > Yeah OK. How about something that would be understood by depsolvers then ? > > installonly packages are already well understood by depsolvers. Look > at the kernel packages. > > yum.conf: > > installonlypkgs= I'd recommend finding a way to specify this in the packaging information, though. otherwise you'll be editing that line all the time. :( -sv From symbiont at berlios.de Mon Jan 24 15:16:39 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 24 Jan 2005 23:16:39 +0800 Subject: suggests/requires in rpm In-Reply-To: <1106579190.3877.33.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <41F50354.2030108@nc.rr.com> <1106579190.3877.33.camel@localhost.localdomain> Message-ID: <200501242316.39856.symbiont@berlios.de> On Monday 24 January 2005 23:06, Darrin Thompson wrote: > I think what bothers me about this is that I'm having trouble > identifying what I trust in the before missingok scenario vs. what I > mistrust in the after scenario. I think it's that the correct use of > the feature is distributed so widely that it would be hard for me to > reestablish trust in the new regime. If you trust the provider, then the package should be trusted to do its job. If not, bugzilla. Barring reference to GPG sigs, using a feature of RPM is not going to affect trust either positively or negatively: it's the provider, how they wield the tool, and their historical performance wielding it. An update may or may not bring in the missing packages in the depsolver--this has yet to be implemented, at all. But, this does nothing but potentially bloat disk space a little. Does that mean you lose trust? I dunno; but, it's readily resolved. RFE or patch depsolver is the best bet. -- -jeff From elanthis at awesomeplay.com Mon Jan 24 15:18:24 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 24 Jan 2005 10:18:24 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <604aa791050124070243cfe95f@mail.gmail.com> References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> Message-ID: <1106579904.2559.7.camel@support02.civic.twp.ypsilanti.mi.us> On Mon, 2005-01-24 at 10:02 -0500, Jeff Spaleta wrote: > On Mon, 24 Jan 2005 09:15:14 -0500, Sean Middleditch > wrote: > > We _have_ had this problem, btw. The problem is that it's not generally > > developers that notice it. It's the user that just want to have their > > machine work. I go to install third party app Foo from Foo's web site, > > it needs libbar.so.2, Fedora only has libbar.so.1, and many other apps > > on the net require libbar.so.1. > > A third part website is packaging libbar.so.2 in a package of the > same package name as Feodora's libbar.so.1? Why would a third party > site do that? Unless the intention was to replace the Fedora package? > Isn't this an example of the care 3rd party packagers should be taking > to make sure their packages work well with Core? Sure, they just make up their own package name. Then FC4 comes along and includes a package that provides the same library, but in a different package name because there's no standard, and the user's system breaks until they magically become experienced enough to fix it. > > And I might add.. that while users and admins.. might want to install > many other apps from anywhere on the net that the find them... this is > not necessarily advisable behavior. You continue to cater to this Because Fedora is going to provide every application that every user could ever want with the latest version with the latest features such that no user will ever, ever need anything not on the Fedora Core/Extras CD, ever, under any circumstance, ever... right? > sort of thing and you will end up with people install very old > libraries that are no longer being maintained so that they can install > very old applications that are no longer being maintained and could > have unresolved but well understood security problems. I'm really not > sure its in anyones best interest to make it really drop-dead easy to > install unmaintained software that might be expoitable simply because > the package was created in 2000. So, because a user might install an old app, you won't to make sure users can't install any app...? Hmm, the user might download an old app from source and install it! Even an inexperienced user can follow a README or HOWTO. I suggest that FC4 disables all Internet access and does not ship with a compiler so that users don't inadvertently install an insecure or buggy app. Advanced users who are knowledgeable about security will still be able to manually configure network access and find compiler binaries off the 'net, so this change won't reduce the usefulness of Fedora, but simply protect users who don't know any better. ;-) > > -jef > From symbiont at berlios.de Mon Jan 24 15:21:40 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 24 Jan 2005 23:21:40 +0800 Subject: RFC: Soname in rpm name In-Reply-To: <1106579519.25770.0.camel@opus.phy.duke.edu> References: <20050124144739.GC7619@angus.ind.WPI.EDU> <1106579519.25770.0.camel@opus.phy.duke.edu> Message-ID: <200501242321.41817.symbiont@berlios.de> On Monday 24 January 2005 23:11, seth vidal wrote: > I'd recommend finding a way to specify this in the packaging > information, though. Munge the release tag! ;) -- -jeff From jspaleta at gmail.com Mon Jan 24 15:25:04 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Jan 2005 10:25:04 -0500 Subject: suggests/requires in rpm In-Reply-To: <200501242308.07535.symbiont@berlios.de> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106577137.3597.36.camel@cutter> <200501242308.07535.symbiont@berlios.de> Message-ID: <604aa79105012407255a07f86c@mail.gmail.com> On Mon, 24 Jan 2005 23:08:05 +0800, Jeff Pitman wrote: > The less magic RPM does, the better. Depsolvers are more fluid than RPM, The less MAGIC we have the better, regardless of where it is. I honestly don't see how throwing the issues in the bugreports you listed up a level to the depresolvers is going to help. Frankly, I think the more and more you ask depresolvers to do in terms of MAGIC, the more difficult things will become, because invaraibly different depresolvers will make different choices leading to different behavior instead of a standardization of behavior. What you suggest is going to make things much much worse... leading to a situation where packagers are designing packages with exactly one high-level depsolver in mind.. instead of focusing on what rpm is going to do with the package. Madness. > which is why they should acquire the necessary complex logic. > Heretofore mentioned bugzillas already clearly show why magic is a > BadThing at the RPM level and that the depsolvers should be charged to > make these decisions: Right.. so we can all yell at the multiple depsolvers when they all make uniquely different bad decisions. Magic is a bad thing... but if magic is going to have to happen.. you only complicate matters by asking the multiple depresolvers to each figure out how to implement it for themselves. -jef From gauret at free.fr Mon Jan 24 14:16:22 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 15:16:22 +0100 Subject: RFC: Soname in rpm name References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> Message-ID: Ralf Ertzinger wrote: > The problem with this is that RPM does not indicate whether a package has > "end user value" (a command line or GUI program, or a daemon), or is just > a support library needed by said end user programs, which can be removed > if not needed by anyone. Panu's script looks in the file list for .so files, that's interesting. He also looks at the RPM Group tag apparently. There is probably room for improvements, but that's a good start. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Never test for an error condition you don't know how to handle." -- Steinbach's Guideline for Systems Programming From n3npq at nc.rr.com Mon Jan 24 15:40:22 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 10:40:22 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <200501242321.41817.symbiont@berlios.de> References: <20050124144739.GC7619@angus.ind.WPI.EDU> <1106579519.25770.0.camel@opus.phy.duke.edu> <200501242321.41817.symbiont@berlios.de> Message-ID: <41F516E6.6090206@nc.rr.com> Jeff Pitman wrote: >On Monday 24 January 2005 23:11, seth vidal wrote: > > >>I'd recommend finding a way to specify this in the packaging >>information, though. >> >> > >Munge the release tag! ;) > > > %post chattr +i `rpm -ql name` should make the package non-upgradeable no matter what. 73 de Jeff From gauret at free.fr Mon Jan 24 15:00:19 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 16:00:19 +0100 Subject: RFC: Soname in rpm name References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <20050124144739.GC7619@angus.ind.WPI.EDU> Message-ID: Charles R. Anderson wrote: > installonly packages are already well understood by depsolvers.??Look > at the kernel packages. True, but we would need something which can be set in the package itself. It looks like something unofficial is already used by Red Hat : if other packages depend on the old library, provide it in a different package containing the library's soname. For example, libpng and libpng10. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." -- Linus Torvalds From aoliva at redhat.com Mon Jan 24 15:59:48 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Jan 2005 13:59:48 -0200 Subject: further package removals/potential package removals In-Reply-To: <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> Message-ID: On Jan 22, 2005, Sean Middleditch wrote: > Removing a utility from Core is not going to in any way stop you from > doing what you need. Only if the installer actually supports installing from extras as well, otherwise an upgrade may be impossible, or leave the system in a broken state. At which point I really fail to see the point of extras: either it's part of the distro, or it isn't. Labeling it as extras just because it's in a separate CD is useful, because then people can choose which CDs to download and burn upfront, but it serves no other purpose. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From symbiont at berlios.de Mon Jan 24 15:59:50 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 24 Jan 2005 23:59:50 +0800 Subject: suggests/requires in rpm In-Reply-To: <604aa79105012407255a07f86c@mail.gmail.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <200501242308.07535.symbiont@berlios.de> <604aa79105012407255a07f86c@mail.gmail.com> Message-ID: <200501242359.50691.symbiont@berlios.de> On Monday 24 January 2005 23:25, Jeff Spaleta wrote: > On Mon, 24 Jan 2005 23:08:05 +0800, Jeff Pitman wrote: > > The less magic RPM does, the better. Depsolvers are more fluid than > > RPM, > What you suggest > is going to make things much much worse... leading to a situation > where packagers are designing packages with exactly one high-level > depsolver in mind.. instead of focusing on what rpm is going to do > with the package. Madness. Leading to? Destination already arrived. Name of high-level depsolver: Anaconda. Name of packagers designing packages with exactly it in mind: Redhat. > > which is why they should acquire the necessary complex logic. > > Heretofore mentioned bugzillas already clearly show why magic is a > > BadThing at the RPM level and that the depsolvers should be charged > > to make these decisions: > > Right.. so we can all yell at the multiple depsolvers when they all > make uniquely different bad decisions. Magic is a bad thing... but > if magic is going to have to happen.. you only complicate matters by > asking the multiple depresolvers to each figure out how to implement > it for themselves. The yelling already started awhile ago. Finding amicable middle ground optimal--not a lot of agreement on what that is, yet. I, for one, am still open to more ideas on it.. What do you think? -- -jeff From laroche at redhat.com Mon Jan 24 16:37:17 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 24 Jan 2005 17:37:17 +0100 Subject: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> Message-ID: <20050124163717.GA8579@dudweiler.stuttgart.redhat.com> > At which point I really fail to see the point of extras: either it's > part of the distro, or it isn't. Labeling it as extras just because > it's in a separate CD is useful, because then people can choose which > CDs to download and burn upfront, but it serves no other purpose. Breaking this on CD-levels will be hard todo and of dubious benefit. I would still expect to have more pressure to keep all software more modular and improve the necessary support for that within our source base. Just be warned that this is too easily confused with only supporting the software in Core and that would be a huge step backwards. greetings, Florian La Roche From aoliva at redhat.com Mon Jan 24 16:07:23 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Jan 2005 14:07:23 -0200 Subject: further package removals/potential package removals In-Reply-To: <1106546143.7129.7.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> Message-ID: On Jan 24, 2005, Peter Jones wrote: > The old way of thinking about this has got to go. _Moving_ something to > Extras is not the same thing as removing it from the distro. Then where's the Extras rawhide tree? Are we going to have Extras ISOs rolled out along with the test releases? Without this, Extras just won't get as much testing because they're not going to work with rawhide or test releases. And for people who depend on packages from Extras, this means they're less likely to run the test releases or track rawhide, which means less testing. Unless Extras is really part of the distro infrastructure, instead of a dump of packages people don't want in the core distro, the quality of the distro as a whole is going to suffer. > We have got to stop thinking of moving something to Extras as removing > it from the distro. Core is not the distro, it is merely a part of the > distro. Extras is another part. +1 I really hope we're going to see FC4 Extras test1 CD go out on the same day as FC4test1, and even have snapshots of them a few days before to sanity-check before the actual test release. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Mon Jan 24 16:08:35 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Jan 2005 14:08:35 -0200 Subject: further package removals/potential package removals In-Reply-To: <1106573733.3597.31.camel@cutter> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> <1106552224.7211.623.camel@mccallum.corsepiu.local> <1106573733.3597.31.camel@cutter> Message-ID: On Jan 24, 2005, seth vidal wrote: >> ATM, Extras isn't much more than a "promise", ... we will see if it will >> come and if when it will work out. > just consider pre-extras as 'extras' for now. I thought current pre-extras was for FC3. Do we have a separate tree I'm not aware of tracking rawhide? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From pmatilai at welho.com Mon Jan 24 16:14:56 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Mon, 24 Jan 2005 18:14:56 +0200 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> Message-ID: <1106583296.4910.7.camel@chip.laiskiainen.org> On Mon, 2005-01-24 at 15:16 +0100, Aurelien Bompard wrote: > Ralf Ertzinger wrote: > > The problem with this is that RPM does not indicate whether a package has > > "end user value" (a command line or GUI program, or a daemon), or is just > > a support library needed by said end user programs, which can be removed > > if not needed by anyone. > > Panu's script looks in the file list for .so files, that's interesting. He > also looks at the RPM Group tag apparently. There is probably room for > improvements, but that's a good start. Run the script with -a option to see why only packages with .so files are considered: without it there are far too many false positives for the output to be useful (never mind dangerous stuff like 'grub' listed as unneeded). One can probably improve the heuristics somewhat but it'll always be just a checklist of *potentially* unneeded stuff. - Panu - From skvidal at phy.duke.edu Mon Jan 24 16:19:46 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 24 Jan 2005 11:19:46 -0500 Subject: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> <1106552224.7211.623.camel@mccallum.corsepiu.local> <1106573733.3597.31.camel@cutter> Message-ID: <1106583586.25770.10.camel@opus.phy.duke.edu> On Mon, 2005-01-24 at 14:08 -0200, Alexandre Oliva wrote: > On Jan 24, 2005, seth vidal wrote: > > >> ATM, Extras isn't much more than a "promise", ... we will see if it will > >> come and if when it will work out. > > > just consider pre-extras as 'extras' for now. > > I thought current pre-extras was for FC3. Do we have a separate tree > I'm not aware of tracking rawhide? > Frankly, I'd be happy to install a rawhide chroot and build from there but we don't have enough people involved to really make it flow. If you'd like to help out in that then figure out what the hold up to getting more people signed on under the CLA. -sv From czar at czarc.net Mon Jan 24 16:23:46 2005 From: czar at czarc.net (Gene C.) Date: Mon, 24 Jan 2005 11:23:46 -0500 Subject: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> Message-ID: <200501241123.46288.czar@czarc.net> On Monday 24 January 2005 10:59, Alexandre Oliva wrote: > Only if the installer actually supports installing from extras as > well, otherwise an upgrade may be impossible, or leave the system in a > broken state. I believe that the installer (anaconda) should support installation ONLY from Core. Additional packages should be installed by the system-config-packages replacement pup which would be invoked during firstboot (or manually after firstboot). Although I have not [yet] voiced my opinion on the, I believe that pup should support all of the same inpout modes as anaconda (e.g., cdrom, nfs, ftp, http, etc.). -- Gene From fedora at wir-sind-cool.org Mon Jan 24 16:30:25 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 24 Jan 2005 17:30:25 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106573733.3597.31.camel@cutter> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> <1106552224.7211.623.camel@mccallum.corsepiu.local> <1106573733.3597.31.camel@cutter> Message-ID: <20050124173025.1d1574d4.fedora@wir-sind-cool.org> On Mon, 24 Jan 2005 08:35:33 -0500, seth vidal wrote: > > ATM, Extras isn't much more than a "promise", ... we will see if it will > > come and if when it will work out. > > just consider pre-extras as 'extras' for now. It's called "pre-Extras", nothing more, and we're still in the middle of nowhere. CVS is a step forward. Pre-Extras is a step backward. At fedora.us we have the stable/testing/unstable classification and the separate "pending" repositories, which we can use rather freely. With pre-Extras, we don't even have a package submission policy. Package updates for pre-Extras are done via bugzilla.fedora.us, because nothing else is documented and CVS has not even been opened for fedora.us trusted developers yet. It is my impression some key people wait for FUDCon and hope for wonders. While that may be an option for those who plan the official Fedora Extras and else have not been involved so far, it is unbearable for the active fedora.us and pre-extras supporters. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at wir-sind-cool.org Mon Jan 24 16:32:02 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 24 Jan 2005 17:32:02 +0100 Subject: further package removals/potential package removals In-Reply-To: <200501241123.46288.czar@czarc.net> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <200501241123.46288.czar@czarc.net> Message-ID: <20050124173202.1a3e577e.fedora@wir-sind-cool.org> On Mon, 24 Jan 2005 11:23:46 -0500, Gene C. wrote: > On Monday 24 January 2005 10:59, Alexandre Oliva wrote: > > Only if the installer actually supports installing from extras as > > well, otherwise an upgrade may be impossible, or leave the system in a > > broken state. > > I believe that the installer (anaconda) should support installation ONLY from > Core. Additional packages should be installed by the system-config-packages > replacement pup which would be invoked during firstboot (or manually after > firstboot). And what's with extra packages which are started before firstboot? From skvidal at phy.duke.edu Mon Jan 24 16:32:20 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 24 Jan 2005 11:32:20 -0500 Subject: further package removals/potential package removals In-Reply-To: <20050124173202.1a3e577e.fedora@wir-sind-cool.org> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <200501241123.46288.czar@czarc.net> <20050124173202.1a3e577e.fedora@wir-sind-cool.org> Message-ID: <1106584341.25770.13.camel@opus.phy.duke.edu> > And what's with extra packages which are started before firstboot? an example of these? I think relying on a package to BOOT that is in extras is exactly the type of package that needs to not be in extras. -sv From jspaleta at gmail.com Mon Jan 24 16:37:25 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Jan 2005 11:37:25 -0500 Subject: further package removals/potential package removals In-Reply-To: <200501241123.46288.czar@czarc.net> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <200501241123.46288.czar@czarc.net> Message-ID: <604aa791050124083726753f9d@mail.gmail.com> On Mon, 24 Jan 2005 11:23:46 -0500, Gene C. wrote: > I believe that the installer (anaconda) should support installation ONLY from > Core. Installation only? or upgrades as well? Cleally the fresh install case isnt the problem... its the Core upgrade case. Doing a 2 stage install is trivial... a 2 stage upgrade on the other hand is somewhat complex, since anconda will have to leave every 3rd party or extras package in place with broken deps until first boot can be run in your scheme. You have to delibrately leave your system in an inconsistent state when you reboot into it and pray that the reboot works even though the system is in an inconsistent state. -jef"if i ruled the world i'd make the act of upgrading a capital punishment and require only fresh installs"spaleta From stuart at terminus.co.uk Mon Jan 24 16:43:57 2005 From: stuart at terminus.co.uk (Stuart Children) Date: Mon, 24 Jan 2005 16:43:57 +0000 Subject: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> Message-ID: <41F525CD.6020001@terminus.co.uk> Alexandre Oliva wrote: > Only if the installer actually supports installing from extras as > well, otherwise an upgrade may be impossible, or leave the system in a > broken state. This is one of my biggest concern with Extras. I have no problem with many of the packages I regularly use being moved to Extras, so long as I can use tools given to me to continue managing a mix of packages from both Core and Extras - and that includes upgrades. I seriously do not consider reinstalling (then adding my Extras packages) a viable option every 6-8 months (Fedora's release cycle). I do not have a problem with an upgrade saying: "You have non-Core packages installed. Please specify repository locations [1] or continue at risk of broken packages." [1] Either "add" a CD ala debian, or point at a local directory, smb or nfs mount point, ftp server, etc of an Extras repository for the version of Fedora you are upgrading to (and any other repositories come to that). > At which point I really fail to see the point of extras: either it's > part of the distro, or it isn't. Labeling it as extras just because > it's in a separate CD is useful, because then people can choose which > CDs to download and burn upfront, but it serves no other purpose. I see Core as "packages managed mainly by RedHat employees and essential to a base [desktop|server] system" (latter is horribly subjective I know), and Extras as "packages mainly packaged by non-RedHat employees", with the extra requirement that no package in Core should depend on a package in Extras. Both are parts of the overall distribution, but Core simply has stricter QC and inclusion requirements. HTH -- Stuart Children From czar at czarc.net Mon Jan 24 16:47:08 2005 From: czar at czarc.net (Gene C.) Date: Mon, 24 Jan 2005 11:47:08 -0500 Subject: further package removals/potential package removals In-Reply-To: <20050124173202.1a3e577e.fedora@wir-sind-cool.org> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <200501241123.46288.czar@czarc.net> <20050124173202.1a3e577e.fedora@wir-sind-cool.org> Message-ID: <200501241147.08607.czar@czarc.net> On Monday 24 January 2005 11:32, Michael Schwendt wrote: > On Mon, 24 Jan 2005 11:23:46 -0500, Gene C. wrote: > > On Monday 24 January 2005 10:59, Alexandre Oliva wrote: > > > Only if the installer actually supports installing from extras as > > > well, otherwise an upgrade may be impossible, or leave the system in a > > > broken state. > > > > I believe that the installer (anaconda) should support installation ONLY > > from Core. ?Additional packages should be installed by the > > system-config-packages replacement pup which would be invoked during > > firstboot (or manually after firstboot). > > And what's with extra packages which are started before firstboot? I am not sure I understand what you mean. To me, Core should provide a working system with additional functionality available in Extras. Once I have completed firstboot and added additional functionality, my system may have some processes which are started before when firstboot is executed when the system is rebooted. Extras should provide optional additional functionality If anaconda is to handle both Core and Extras as input, then the real distribution will be Core+Extras. Is this the intended direction? -- Gene From rdieter at math.unl.edu Mon Jan 24 16:46:28 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 24 Jan 2005 10:46:28 -0600 (CST) Subject: further package removals/potential package removals In-Reply-To: <41F525CD.6020001@terminus.co.uk> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> Message-ID: On Mon, 24 Jan 2005, Stuart Children wrote: > I see Core as "packages managed mainly by RedHat employees and essential to a > base [desktop|server] system" (latter is horribly subjective I know), and > Extras as "packages mainly packaged by non-RedHat employees", with the extra > requirement that no package in Core should depend on a package in Extras. > Both are parts of the overall distribution, but Core simply has stricter QC > and inclusion requirements. (Ironic or not) since Fedora Extras (at least the fedora.us incarnation) actually has QA *before* packages are published, IMO, their packaging quality is at least as good or better than many of those in Core. --Rex From skvidal at phy.duke.edu Mon Jan 24 16:48:20 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 24 Jan 2005 11:48:20 -0500 Subject: further package removals/potential package removals In-Reply-To: <20050124173025.1d1574d4.fedora@wir-sind-cool.org> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> <1106552224.7211.623.camel@mccallum.corsepiu.local> <1106573733.3597.31.camel@cutter> <20050124173025.1d1574d4.fedora@wir-sind-cool.org> Message-ID: <1106585300.25770.17.camel@opus.phy.duke.edu> > It's called "pre-Extras", nothing more, and we're still in the middle > of nowhere. > > CVS is a step forward. Pre-Extras is a step backward. At fedora.us we > have the stable/testing/unstable classification and the separate > "pending" repositories, which we can use rather freely. With > pre-Extras, we don't even have a package submission policy. Package > updates for pre-Extras are done via bugzilla.fedora.us, because > nothing else is documented and CVS has not even been opened for > fedora.us trusted developers yet. Why are package updates for pre-extras done by bugzilla.fedora.us. All the packages in cvs are in red hat's bugzilla. > It is my impression some key people wait for FUDCon and hope for > wonders. While that may be an option for those who plan the official > Fedora Extras and else have not been involved so far, it is unbearable > for the active fedora.us and pre-extras supporters. Where did you get this impression from? I'm sorry to hear you don't like pre-extras, I was trying to help out by building those things and putting them up. -sv From fedora at wir-sind-cool.org Mon Jan 24 16:52:17 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 24 Jan 2005 17:52:17 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106584341.25770.13.camel@opus.phy.duke.edu> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <200501241123.46288.czar@czarc.net> <20050124173202.1a3e577e.fedora@wir-sind-cool.org> <1106584341.25770.13.camel@opus.phy.duke.edu> Message-ID: <20050124175217.5d4a7d65.fedora@wir-sind-cool.org> On Mon, 24 Jan 2005 11:32:20 -0500, seth vidal wrote: > > > And what's with extra packages which are started before firstboot? > > an example of these? Daemons, firewall tools, packages which put stuff into /etc/profile.d, for instance. > I think relying on a package to BOOT that is in extras is exactly the > type of package that needs to not be in extras. "Relying" is the wrong term. It's just not nice to reboot a partial upgrade and possibly see stuff failing before you get the chance to complete the upgrade. From czar at czarc.net Mon Jan 24 16:52:24 2005 From: czar at czarc.net (Gene C.) Date: Mon, 24 Jan 2005 11:52:24 -0500 Subject: further package removals/potential package removals In-Reply-To: <604aa791050124083726753f9d@mail.gmail.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <200501241123.46288.czar@czarc.net> <604aa791050124083726753f9d@mail.gmail.com> Message-ID: <200501241152.24914.czar@czarc.net> On Monday 24 January 2005 11:37, Jeff Spaleta wrote: > On Mon, 24 Jan 2005 11:23:46 -0500, Gene C. wrote: > > I believe that the installer (anaconda) should support installation ONLY > > from Core. > > Installation only? ?or upgrades as well? > Cleally the fresh install case isnt the problem... its the Core upgrade > case. Doing a 2 stage install is trivial... a 2 stage upgrade on the other > hand is somewhat complex, since anconda will have to leave every 3rd party > or extras package in place with broken deps until first boot can be run in > your scheme. ?You have to delibrately leave your system in an inconsistent > state when you reboot into it ?and pray that the > reboot works even though the system is in an inconsistent state. Oops, you are correct that I was not considering an upgrade. If we need to handle upgrades where packages have been moved from Core to Extras but not removed entirely, then a Fedora distribution will need to always be Core+Extras. Is this what we want? Is this the intended direction by Fedora developers? I do not have answers myself and the intended direction by the folks who "control what Fedora is" is not clear to me. -- Gene From gauret at free.fr Mon Jan 24 16:52:22 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 17:52:22 +0100 Subject: RFC: Soname in rpm name References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> <1106583296.4910.7.camel@chip.laiskiainen.org> Message-ID: Panu Matilainen wrote: > One can probably improve the heuristics somewhat but it'll > always be just a checklist of potentially unneeded stuff. Just like what deborphan or urpm-find-leaves does. This is why this list should be proposed to the admin, and he can choose what should be removed and what should be kept. Nothing automatic possible IMHO, but it can still be useful to find leftover packages. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in: we're computer professionals. We cause accidents." -- Nathaniel Borenstein From aoliva at redhat.com Mon Jan 24 16:54:26 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Jan 2005 14:54:26 -0200 Subject: kernel-devel: should yum install, not update? In-Reply-To: <604aa7910501221122724f734c@mail.gmail.com> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> Message-ID: On Jan 22, 2005, Jeff Spaleta wrote: > On Sat, 22 Jan 2005 11:03:39 -0800, Tom London wrote: >> Running latest rawhide. >> >> Yum seems to update the kernel-devel package. >> >> Should it be added to the default 'installonly' packages? > probably... looking at the kernel-devel file payload it seems to be > parallel installable by design. I think its perfectly reasonable to > set this to parallel install by default instead of upgrade. I don't think the default should be to have multiple versions of this package installed. Sure enough, some people might have need for them all, but, unlike kernel and kernel-modules, this one serves no useful purpose for most users, so I'd rather not see them piling up by default. Users with an actual need for multiple kernel-devel packages should be able to tweak the tools to accomplish this. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From toshio at tiki-lounge.com Mon Jan 24 16:54:51 2005 From: toshio at tiki-lounge.com (Toshio Kuratomi) Date: Mon, 24 Jan 2005 08:54:51 -0800 Subject: further package removals/potential package removals In-Reply-To: <1106553735.4172.33.camel@laptopd505.fenrus.org>; from arjanv@redhat.com on Mon, Jan 24, 2005 at 09:02:15AM +0100 References: <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <20050123041600.GB1420188@hiwaay.net> <1106461830.29183.183.camel@localhost.localdomain> <41F387AB.4060604@nc.rr.com> <1106505752.6065.6.camel@localhost.localdomain> <1106524682.4002.67.camel@bree.local.net> <41F43BEA.7000203@nc.rr.com> <1106553735.4172.33.camel@laptopd505.fenrus.org> Message-ID: <20050124085451.A28061@tiki-lounge.com> On Mon, Jan 24, 2005 at 09:02:15AM +0100, Arjan van de Ven wrote: > > > Meanwhile, new packaging for, say, nautilus which has > > Requires(missingok): gnome-vfs2-smb > > and a depsolver that tests RPMSENSE_MISSINGOK drop a sub-tree that > > is optional. > > > > I fail to see a mulberry bush, except in this loopy and endless fretting. > > > > Show me the mulberries *please*. > > > user goes from package-1.0-1.0 to package-1.1-1.0 which now had a > Requires(missingok): gnome-vfs2-smp. Fine; yum (for the sake of > argument) grabs gnome-vfs2-smp as well and everything is happy. > Now the user gets annoyed by the "bloat" and removes gnome-vfs2-smp. > Still fine. > > Then a security update comes out, package-1.1-1.1 and the user of course > upgrades to that. yum will *AGAIN* pull in gnome-vfs2-smp. User gets > really annoyed and considers this not-fine. > As the current answer to "Can I do a yum upgrade of my system?" is "Read the Release Notes to see what special magic anaconda knows about and then do the upgrade at your own risk" I think yum/apt/etc shouldn't default to adding a missingok package when upgrading. This should only be something that anaconda does. Of course, I don't code for any of the package managers so it's not up to me. -Toshio From aoliva at redhat.com Mon Jan 24 17:05:29 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Jan 2005 15:05:29 -0200 Subject: RFC: Soname in rpm name In-Reply-To: <20050124151136.31801589@nausicaa.camperquake.de> References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> Message-ID: On Jan 24, 2005, Ralf Ertzinger wrote: > Hi. > Aurelien Bompard wrote: >> I did not know, is it possible to have a tool find the rpms that no rpms >> depend on, and ask to remove them ? > The problem with this is that RPM does not indicate whether a package has > "end user value" (a command line or GUI program, or a daemon), or is just > a support library needed by said end user programs, which can be removed > if not needed by anyone. Could we perhaps add such a flag to the rpm database? Then the installer and the various other package installation front-ends could mark user- (or comps-)requested packages as having end user value, and everything else brought in to satisfy dependencies such that it is (or can be) removed as soon as no dependencies remain. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Mon Jan 24 17:06:24 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Jan 2005 15:06:24 -0200 Subject: RFC: Soname in rpm name In-Reply-To: <41F4E6B7.1000900@nc.rr.com> References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <20050124130356.2bb0201e@nausicaa.camperquake.de> <41F4E6B7.1000900@nc.rr.com> Message-ID: On Jan 24, 2005, Jeff Johnson wrote: > rpm -e N-V-R && rpm -i N-V-R.A.rpm > is exactly an update. You missed the --nodeps after -e. And it doesn't quite work for rpm itself :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From feliciano.matias at free.fr Mon Jan 24 17:11:08 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 24 Jan 2005 18:11:08 +0100 Subject: further package removals/potential package removals In-Reply-To: <20050124173025.1d1574d4.fedora@wir-sind-cool.org> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> <1106552224.7211.623.camel@mccallum.corsepiu.local> <1106573733.3597.31.camel@cutter> <20050124173025.1d1574d4.fedora@wir-sind-cool.org> Message-ID: <1106586668.9012.3.camel@one.myworld> Le lundi 24 janvier 2005 ? 17:30 +0100, Michael Schwendt a ?crit : > At fedora.us we > have the stable/testing/unstable classification Fedora Core don't have such "stable/testing/unstable classification" and I think it's a good thing. Debian have this "feature" I am not convinced it's very useful. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From roli at israel-jugendtag.ch Mon Jan 24 17:28:29 2005 From: roli at israel-jugendtag.ch (Roland Kaeser) Date: Mon, 24 Jan 2005 18:28:29 +0100 Subject: Package Inspection Message-ID: <41F5303D.8050305@israel-jugendtag.ch> Hi all I know this would rater belong to the user list but I'm not a subscriber of this list so I try to post it here. I need a package inspection tool for a very large firewall project. The ipt_string functionality does not longer exist in the iptables implementation of the kernel 2.6 so I need a other tool which drops all packages or communication parts which contains dangerous contents. I've searched a lot of websites but I couldn't find anything which reliabley implements a such function. Is there somebody which has experiences in these field and can advise me? This functionality should been implemented on a Fedora 2 machine which stands in the front of the application level firewalls to prevent its from traffic which is not productive. Many Thanks Roland Kaeser -- Roland K?ser Fulachstr. 197 8200 Schaffhausen Webmaster www.Israel-Jugendtag.ch ****************************************** ** Schon vom Israel-Jugendtag geh?rt? ** ****************************************** www.israel-jugendtag.ch This e-mail is confidential. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail or by telephoning.Please then delete the e-mail and do not disclose its contents to any person. We believe, but do not warrant, that this e-mail and any attachments are virus free. You should take full responsibility for virus checking. From fedora at wir-sind-cool.org Mon Jan 24 17:29:20 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 24 Jan 2005 18:29:20 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106585300.25770.17.camel@opus.phy.duke.edu> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> <1106552224.7211.623.camel@mccallum.corsepiu.local> <1106573733.3597.31.camel@cutter> <20050124173025.1d1574d4.fedora@wir-sind-cool.org> <1106585300.25770.17.camel@opus.phy.duke.edu> Message-ID: <20050124182920.74b48011.fedora@wir-sind-cool.org> On Mon, 24 Jan 2005 11:48:20 -0500, seth vidal wrote: > > It's called "pre-Extras", nothing more, and we're still in the middle > > of nowhere. > > > > CVS is a step forward. Pre-Extras is a step backward. At fedora.us we > > have the stable/testing/unstable classification and the separate > > "pending" repositories, which we can use rather freely. With > > pre-Extras, we don't even have a package submission policy. Package > > updates for pre-Extras are done via bugzilla.fedora.us, because > > nothing else is documented and CVS has not even been opened for > > fedora.us trusted developers yet. > > Why are package updates for pre-extras done by bugzilla.fedora.us. All > the packages in cvs are in red hat's bugzilla. Please enlighten me. How did the package release procedure change between fedora.us and pre-extras? Who does what? And where? > > It is my impression some key people wait for FUDCon and hope for > > wonders. While that may be an option for those who plan the official > > Fedora Extras and else have not been involved so far, it is unbearable > > for the active fedora.us and pre-extras supporters. > > Where did you get this impression from? > > I'm sorry to hear you don't like pre-extras, I was trying to help out by > building those things and putting them up. No, no, I'm glad that we have your FC3 builds in the pre-extras tree. Surely better than no FC3 builds at all. And e.g. Dave Lawrence's response time on requests for adding bugzilla components is awesome. But let me repeat. I've said before at least once that if Fedora Extras and its buildsystem need more time, we should keep fedora.us running, simplifying procedures where reasonable, continueing to grow. However, with intermediate steps like pre-extras, promises, and no clear guidance we continue to kill off fedora.us while Fedora Extras is not ready. As much as I'd like to migrate to less burdensome procedures (for all of us!), currently some of us "fight" at two fronts. New contributors don't know at all what to do. And existing contributors, including so-called trusted ones at fedora.us, are somewhere inbetween. From fedora at wir-sind-cool.org Mon Jan 24 17:45:02 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 24 Jan 2005 18:45:02 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106586668.9012.3.camel@one.myworld> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> <1106552224.7211.623.camel@mccallum.corsepiu.local> <1106573733.3597.31.camel@cutter> <20050124173025.1d1574d4.fedora@wir-sind-cool.org> <1106586668.9012.3.camel@one.myworld> Message-ID: <20050124184502.779190d4.fedora@wir-sind-cool.org> On Mon, 24 Jan 2005 18:11:08 +0100, F?liciano Matias wrote: > Le lundi 24 janvier 2005 ? 17:30 +0100, Michael Schwendt a ?crit : > > At fedora.us we > > have the stable/testing/unstable classification > > Fedora Core don't have such "stable/testing/unstable classification" and > I think it's a good thing. Sorry that you disagree, but as someone who has reviewed and approved several hundreds of packages at fedora.us, it is my opinion that the classification (at least the split into stable+testing) has been beneficial. Also at rpm.livna.org it permitted test-driving new releases publicly while not disturbing known good releases. It utilises existing community resources, who are interested in contributing community QA, while other parts of the community prefer not to play with fire. Without such a classification, what is accepted into Fedora Extras and when? Fedora Core has an early development stream and multiple test releases. Some of this will likely be discussed at FUDCon. But currently, once a newly added package is added to pre-extras, it's included by definition, and we must deal with the wreckage if there are bug reports and/or complaints. > Debian have this "feature" I am not convinced it's very useful. That's quite a different one. From pjones at redhat.com Mon Jan 24 17:52:23 2005 From: pjones at redhat.com (pjones) Date: Mon, 24 Jan 2005 12:52:23 -0500 Subject: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> Message-ID: <1106589143.7129.12.camel@localhost.localdomain> On Mon, 2005-01-24 at 14:07 -0200, Alexandre Oliva wrote: > On Jan 24, 2005, Peter Jones wrote: > > > The old way of thinking about this has got to go. _Moving_ something to > > Extras is not the same thing as removing it from the distro. > > Then where's the Extras rawhide tree? Are we going to have Extras > ISOs rolled out along with the test releases? Without this, Extras > just won't get as much testing because they're not going to work with > rawhide or test releases. And for people who depend on packages from > Extras, this means they're less likely to run the test releases or > track rawhide, which means less testing. > > Unless Extras is really part of the distro infrastructure, instead of > a dump of packages people don't want in the core distro, the quality > of the distro as a whole is going to suffer. Yes, this is absolutely true. We have to make it part of the same thing, not just call it part of the same thing. > > We have got to stop thinking of moving something to Extras as removing > > it from the distro. Core is not the distro, it is merely a part of the > > distro. Extras is another part. > > +1 > > I really hope we're going to see FC4 Extras test1 CD go out on the > same day as FC4test1, and even have snapshots of them a few days > before to sanity-check before the actual test release. Agreed. -- Peter When privacy is outlawed only outlaws will have privacy. -- Zimmermann From hp at redhat.com Mon Jan 24 17:57:00 2005 From: hp at redhat.com (Havoc Pennington) Date: Mon, 24 Jan 2005 12:57:00 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106563944.5621.32.camel@perun.redhat.usu> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <41F313F7.7679D847@jwz.org> <41F319D2.6080303@nc.rr.com> <87651odavq.fsf@londo.ultra.csn.tu-chemnitz.de> <1106563944.5621.32.camel@perun.redhat.usu> Message-ID: <1106589420.13493.67.camel@localhost.localdomain> On Mon, 2005-01-24 at 11:52 +0100, Tomas Mraz wrote: > > The problem is pam_console (and maybe others) modules (which are by > default configured to be used) require glib2. And I don't see any > possibility to make the pam_console optional. So you can tune your > minimum install so the pam_console is removed from all /etc/pam.d/... > configs and then you can remove glib2. Or you can write a patch for all > pam modules in redhat which use glib2 which replace the functionality > provided by glib2 by another means and if it's good it will be applied. > But I won't write it as I have many more useful things to do. So does everyone else - that's why they use a working, tested, widely- available utility library instead of writing their own string and hash table classes in every single package. Among other things, it's near impossible to write a properly internationalized app without unicode utilities as in GLib. Havoc From hp at redhat.com Mon Jan 24 17:59:51 2005 From: hp at redhat.com (Havoc Pennington) Date: Mon, 24 Jan 2005 12:59:51 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106558243.26412.4.camel@localhost.localdomain> References: <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <20050123041600.GB1420188@hiwaay.net> <1106461830.29183.183.camel@localhost.localdomain> <41F387AB.4060604@nc.rr.com> <1106505752.6065.6.camel@localhost.localdomain> <1106524682.4002.67.camel@bree.local.net> <41F43BEA.7000203@nc.rr.com> <1106553735.4172.33.camel@laptopd505.fenrus.org> <20050124085016.GA7147@dudweiler.stuttgart.redhat.com> <1106558243.26412.4.camel@localhost.localdomain> Message-ID: <1106589591.13493.70.camel@localhost.localdomain> On Mon, 2005-01-24 at 10:17 +0100, Peter Backlund wrote: > > To me, this seems to be the best and simplest solution. The requirement > for gnome-vfs2-smb is apparently there to make sure the default install > has certain funcionality, so why not delegate that responsibility to the > installation program (i.e. Anaconda)? If the user wants to remove it > later, fine. On upgrades, gnome-vfs2-smb will be upgraded if it's > installed, otherwise it won't be installed. This course of action has the priorities backward. Priority 1 is that people get the functionality they expect. Priority 2 is that tweakers and tuners can save a little disk space. Havoc From feliciano.matias at free.fr Mon Jan 24 18:19:26 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 24 Jan 2005 19:19:26 +0100 Subject: further package removals/potential package removals In-Reply-To: <20050124184502.779190d4.fedora@wir-sind-cool.org> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> <1106552224.7211.623.camel@mccallum.corsepiu.local> <1106573733.3597.31.camel@cutter> <20050124173025.1d1574d4.fedora@wir-sind-cool.org> <1106586668.9012.3.camel@one.myworld> <20050124184502.779190d4.fedora@wir-sind-cool.org> Message-ID: <1106590766.9012.19.camel@one.myworld> Le lundi 24 janvier 2005 ? 18:45 +0100, Michael Schwendt a ?crit : > (...) > Sorry that you disagree, but as someone who has reviewed and approved > several hundreds of packages at fedora.us, it is my opinion that the > classification (at least the split into stable+testing) has been > beneficial. I am agree with stable+testing (or stable+rawhide). But testing for testing propose _only_. Mplayer is in "unstable" since many months in livna. Doesn't seems it's for testing only. Since many people use mplayer, many people have "unstable" in their yum.conf. The situation is not the same with FC/Rawhide and update/update_testing. A very few people use Rawhide or update_testing. > > > Debian have this "feature" I am not convinced it's very useful. > > That's quite a different one. Right. From fedora at wir-sind-cool.org Mon Jan 24 18:28:51 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 24 Jan 2005 19:28:51 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106590766.9012.19.camel@one.myworld> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> <1106552224.7211.623.camel@mccallum.corsepiu.local> <1106573733.3597.31.camel@cutter> <20050124173025.1d1574d4.fedora@wir-sind-cool.org> <1106586668.9012.3.camel@one.myworld> <20050124184502.779190d4.fedora@wir-sind-cool.org> <1106590766.9012.19.camel@one.myworld> Message-ID: <20050124192851.0d8441fa.fedora@wir-sind-cool.org> On Mon, 24 Jan 2005 19:19:26 +0100, F?liciano Matias wrote: > Le lundi 24 janvier 2005 ? 18:45 +0100, Michael Schwendt a ?crit : > > (...) > > Sorry that you disagree, but as someone who has reviewed and approved > > several hundreds of packages at fedora.us, it is my opinion that the > > classification (at least the split into stable+testing) has been > > beneficial. > > I am agree with stable+testing (or stable+rawhide). > But testing for testing propose _only_. > > Mplayer is in "unstable" since many months in livna. Doesn't seems it's > for testing only. Actually, the scheme at rpm.livna.org is a revised one. Do you have any comments on the known issues why the packages stay in "testing"? There are a couple of packages which cannot be moved because they cause regression and/or break other packages in "stable". > Since many people use mplayer, many people have "unstable" in their > yum.conf. The key point is they are free to enable these optional upgrades which may not be as trouble-free as stuff in "stable". Those who are happy with the last "stable" release would not like if they were forced to install less stable releases or no mplayer at all. > The situation is not the same with FC/Rawhide and update/update_testing. > A very few people use Rawhide or update_testing. The developers do. And Rawhide is developed long enough to stabilize for a first test release. From fedora at leemhuis.info Mon Jan 24 18:33:36 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 24 Jan 2005 19:33:36 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106590766.9012.19.camel@one.myworld> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> <1106552224.7211.623.camel@mccallum.corsepiu.local> <1106573733.3597.31.camel@cutter> <20050124173025.1d1574d4.fedora@wir-sind-cool.org> <1106586668.9012.3.camel@one.myworld> <20050124184502.779190d4.fedora@wir-sind-cool.org> <1106590766.9012.19.camel@one.myworld> Message-ID: <1106591616.6020.7.camel@localhost.localdomain> Am Montag, den 24.01.2005, 19:19 +0100 schrieb F?liciano Matias: > Le lundi 24 janvier 2005 ? 18:45 +0100, Michael Schwendt a ?crit : > > (...) > > Sorry that you disagree, but as someone who has reviewed and approved > > several hundreds of packages at fedora.us, it is my opinion that the > > classification (at least the split into stable+testing) has been > > beneficial. > > I am agree with stable+testing (or stable+rawhide). > But testing for testing propose _only_. > > Mplayer is in "unstable" since many months in livna. Doesn't seems it's > for testing only. Dependency problem cause of livna bug 147. Any help to track this down is appreciated. I did a short look but did not find anything yet. CU thl -- Thorsten Leemhuis From Axel.Thimm at ATrpms.net Mon Jan 24 18:57:47 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 24 Jan 2005 19:57:47 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> Message-ID: <20050124185747.GI19903@neu.nirvana> On Mon, Jan 24, 2005 at 03:05:29PM -0200, Alexandre Oliva wrote: > On Jan 24, 2005, Ralf Ertzinger wrote: > > > Hi. > > Aurelien Bompard wrote: > > >> I did not know, is it possible to have a tool find the rpms that no rpms > >> depend on, and ask to remove them ? > > > The problem with this is that RPM does not indicate whether a package has > > "end user value" (a command line or GUI program, or a daemon), or is just > > a support library needed by said end user programs, which can be removed > > if not needed by anyone. > > Could we perhaps add such a flag to the rpm database? Then the > installer and the various other package installation front-ends could > mark user- (or comps-)requested packages as having end user value, and > everything else brought in to satisfy dependencies such that it is (or > can be) removed as soon as no dependencies remain. ATrpms has started marking library only packages with Provides: shared-library-package so these packages can be identifies with rpm --whatprovides shared-library-package and be probed for garbage collection. I.e. there is no need to extend rpm, you have everything already in place. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at phy.duke.edu Mon Jan 24 19:01:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 24 Jan 2005 14:01:41 -0500 Subject: suggests/requires in rpm In-Reply-To: <20050124143953.GA9444@orient.maison.moi> References: <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com> <1106572460.3877.8.camel@localhost.localdomain> <1106577137.3597.36.camel@cutter> <20050124143953.GA9444@orient.maison.moi> Message-ID: <1106593302.25770.27.camel@opus.phy.duke.edu> On Mon, 2005-01-24 at 15:39 +0100, Emmanuel Seyman wrote: > On Mon, Jan 24, 2005 at 09:32:17AM -0500, seth vidal wrote: > > > > All that's really been done is to push the decision-making process off > > on the depsolvers. > > Am I the only one who finds this is the right thing to do? (tm) > Depsolvers solve dependencies. This is just a special kind of dependency > (one amongst many). > I never said it's not the right thing to do - I was just explaining that it is not a solution, yet. You just moved where you solve it. -sv From skvidal at phy.duke.edu Mon Jan 24 19:05:37 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 24 Jan 2005 14:05:37 -0500 Subject: suggests/requires in rpm In-Reply-To: <200501242308.07535.symbiont@berlios.de> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106577137.3597.36.camel@cutter> <200501242308.07535.symbiont@berlios.de> Message-ID: <1106593537.25770.30.camel@opus.phy.duke.edu> On Mon, 2005-01-24 at 23:08 +0800, Jeff Pitman wrote: > On Monday 24 January 2005 22:32, seth vidal wrote: > > > I, for one, thought Jeff was clear that it's the job of depsolvers > > > (anaconda, yum, smart, apt) to decide what to do with the extra > > > information. > > > > All that's really been done is to push the decision-making process > > off on the depsolvers. > > Which is what it should do. Depsolvers are becoming the defacto > interface to the packaging system; responsibility may feel burdensome > at times, but it's a pretty clear distinction to implement these > processes at this level. > > The less magic RPM does, the better. Depsolvers are more fluid than RPM, Not arguing with you - but figuring out the correct, default behavior at the depsolver level is not easier :) Anyone who thinks the correct behavior is 'ask the user' is deeply confused about the understanding the average user has about package/dependency issues. We have to have a correct and adequate default state. We can present options, but we must not rely on the user for this. -sv From Axel.Thimm at ATrpms.net Mon Jan 24 19:06:13 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 24 Jan 2005 20:06:13 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: Message-ID: <20050124190613.GJ19903@neu.nirvana> On Mon, Jan 24, 2005 at 11:34:03AM +0100, Aurelien Bompard wrote: > Hi all > > A question to packagers: what would you think of a policy to add the library > soname in package libraries ? Yes, please. This is very important for smooth upgrades, i.e. no pressure to rebuild all dependent packages in one atomic step. This becomes even more important for a community with multiple repos like fedora core is evolving to. > For example, I have a libkexif package, which > provides libkexif.so.0, and at least 3 applications depend on it. Now there > is an update to libkexif, which provides libkexif.so.1. I can't update > libkexif without updating the applications depending on it. > OK, this is probably something that you know much better than me, and that > you've run into several times before, so you probably already know the > solution. I've searched a bit, and it seems that Mandrake and Debian both > have a policy to include the library soname in the package name : > http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowToAdvanced#Library_policy > http://www.debian.org/doc/debian-policy/ch-sharedlibs.html > > How about a similar policy for Fedora ? Is it the best solution to this > problem ? I think this is an area, where other distributions have found nice solutions and Fedora/Red Hat should simply use one of the existing policies (instead of creating one from scratch). I think there aren't that big differences in Mandrake's vs Debian's policies. BTW ATrpms has been converting library packages to use this scheme for quite some time in order to have good gluing components between the various repos. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From feliciano.matias at free.fr Mon Jan 24 19:09:43 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 24 Jan 2005 20:09:43 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106591616.6020.7.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> <1106552224.7211.623.camel@mccallum.corsepiu.local> <1106573733.3597.31.camel@cutter> <20050124173025.1d1574d4.fedora@wir-sind-cool.org> <1106586668.9012.3.camel@one.myworld> <20050124184502.779190d4.fedora@wir-sind-cool.org> <1106590766.9012.19.camel@one.myworld> <1106591616.6020.7.camel@localhost.localdomain> Message-ID: <1106593783.9012.24.camel@one.myworld> Le lundi 24 janvier 2005 ? 19:33 +0100, Thorsten Leemhuis a ?crit : > Am Montag, den 24.01.2005, 19:19 +0100 schrieb F?liciano Matias: > (...) > > Mplayer is in "unstable" since many months in livna. Doesn't seems it's > > for testing only. > > Dependency problem cause of livna bug 147. It's a bug. mplayer is a stable package with one bug (faad2). Fedora Core have many packages like this one. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From caillon at redhat.com Mon Jan 24 19:15:31 2005 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 24 Jan 2005 14:15:31 -0500 Subject: FC4 with localized firefox (wishlist) In-Reply-To: <1106482635.6173.100.camel@localhost> References: <1106482635.6173.100.camel@localhost> Message-ID: <41F54953.7040901@redhat.com> Josep Puigdemont wrote: > Hi, > > Here it is my short wish list for FC4, if I may send one ;-) > I don't know if this has been mentioned before or not, but I for one > would like to see localized versions of Firefox for each installed > language, by default. The version in rawhide does this already, at least for the languages that Firefox have been translated into already. I've just been sort of swamped and haven't had time to backport to fc3 yet. From mike at navi.cx Mon Jan 24 19:21:59 2005 From: mike at navi.cx (Mike Hearn) Date: Mon, 24 Jan 2005 19:21:59 +0000 Subject: RFC: Soname in rpm name References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E672.3020103@nc.rr.com> <20050124132138.2bdbc4c9.fedora@wir-sind-cool.org> <41F4EB14.3040302@nc.rr.com> Message-ID: On Mon, 24 Jan 2005 07:33:24 -0500, Jeff Johnson wrote: > Because while it works for the distro, slam dunking does not work for > 3rd party packing. In fact, slam-dunking is not gonna work for 2nd party > packaging like Fedora Extras. What will happen instead (imho) is that > library sonames simply won't change, even if they should. This whole mess could be avoided if libkexif had not broken backwards compatibility of course ... it's perhaps not too late to go back and do a new release that doesn't do so? From mike at navi.cx Mon Jan 24 19:25:44 2005 From: mike at navi.cx (Mike Hearn) Date: Mon, 24 Jan 2005 19:25:44 +0000 Subject: RFC: Soname in rpm name References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> Message-ID: On Mon, 24 Jan 2005 10:02:52 -0500, Jeff Spaleta wrote: > And I might add.. that while users and admins.. might want to install > many other apps from anywhere on the net that the find them... this is > not necessarily advisable behavior. You continue to cater to this > sort of thing and you will end up with people install very old > libraries that are no longer being maintained so that they can install > very old applications that are no longer being maintained and could > have unresolved but well understood security problems. I'm really not > sure its in anyones best interest to make it really drop-dead easy to > install unmaintained software that might be expoitable simply because > the package was created in 2000. Wow - 2000 is only 5 years ago guys. There are *lots* of people still running programs designed for Windows 95, which is now 10 years old! Face it: people will run the software they want. If you make it difficult or annoying for them out of a misguided sense that security-through-obnoxiousness is OK, they'll just use Windows which doesn't do much for security at all but at least makes it easy for the user to achieve their goal. The best solution is for libraries to not break backwards compatibility every other week, that way security fixes are magically present even for 5 year old apps. Seriously, 5 years is really nothing, it's all about mindset. thanks -mike From n3npq at nc.rr.com Mon Jan 24 19:32:43 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 14:32:43 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <20050124185747.GI19903@neu.nirvana> References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> <20050124185747.GI19903@neu.nirvana> Message-ID: <41F54D5B.1000208@nc.rr.com> Axel Thimm wrote: >On Mon, Jan 24, 2005 at 03:05:29PM -0200, Alexandre Oliva wrote: > > >>On Jan 24, 2005, Ralf Ertzinger wrote: >> >> >> >>>Hi. >>>Aurelien Bompard wrote: >>> >>> >>>>I did not know, is it possible to have a tool find the rpms that no rpms >>>>depend on, and ask to remove them ? >>>> >>>> >>>The problem with this is that RPM does not indicate whether a package has >>>"end user value" (a command line or GUI program, or a daemon), or is just >>>a support library needed by said end user programs, which can be removed >>>if not needed by anyone. >>> >>> >>Could we perhaps add such a flag to the rpm database? Then the >>installer and the various other package installation front-ends could >>mark user- (or comps-)requested packages as having end user value, and >>everything else brought in to satisfy dependencies such that it is (or >>can be) removed as soon as no dependencies remain. >> >> > >ATrpms has started marking library only packages with > > Provides: shared-library-package > >so these packages can be identifies with > > rpm --whatprovides shared-library-package > >and be probed for garbage collection. > >I.e. there is no need to extend rpm, you have everything already in >place. > > And there's no need for the *.spec churn and the marker in dependencies: rpm -qa 'classdict=*shared object*' 73 de Jeff From kyrre at solution-forge.net Mon Jan 24 19:34:30 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 24 Jan 2005 20:34:30 +0100 Subject: FC4 with localized firefox (wishlist) In-Reply-To: <41F54953.7040901@redhat.com> References: <1106482635.6173.100.camel@localhost> <41F54953.7040901@redhat.com> Message-ID: <1106595270.7794.16.camel@localhost.localdomain> man, 24.01.2005 kl. 20.15 skrev Christopher Aillon: > Josep Puigdemont wrote: > > Hi, > > > > Here it is my short wish list for FC4, if I may send one ;-) > > I don't know if this has been mentioned before or not, but I for one > > would like to see localized versions of Firefox for each installed > > language, by default. > > The version in rawhide does this already, at least for the languages > that Firefox have been translated into already. I've just been sort of > swamped and haven't had time to backport to fc3 yet. OK :) Then we are just looking forward for the fc3 port. From feliciano.matias at free.fr Mon Jan 24 19:39:05 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 24 Jan 2005 20:39:05 +0100 Subject: further package removals/potential package removals In-Reply-To: <20050124192851.0d8441fa.fedora@wir-sind-cool.org> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> <1106552224.7211.623.camel@mccallum.corsepiu.local> <1106573733.3597.31.camel@cutter> <20050124173025.1d1574d4.fedora@wir-sind-cool.org> <1106586668.9012.3.camel@one.myworld> <20050124184502.779190d4.fedora@wir-sind-cool.org> <1106590766.9012.19.camel@one.myworld> <20050124192851.0d8441fa.fedora@wir-sind-cool.org> Message-ID: <1106595545.9012.26.camel@one.myworld> Le lundi 24 janvier 2005 ? 19:28 +0100, Michael Schwendt a ?crit : > On Mon, 24 Jan 2005 19:19:26 +0100, F?liciano Matias wrote: > (...) > Do you have any comments on the known issues why the packages stay in > "testing"? > No. I only use Mplayer and it works perfectly (here at least). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From josep at imatge-sintetica.com Mon Jan 24 19:42:33 2005 From: josep at imatge-sintetica.com (Josep Puigdemont) Date: Mon, 24 Jan 2005 20:42:33 +0100 Subject: FC4 with localized firefox (wishlist) In-Reply-To: <41F54953.7040901@redhat.com> References: <1106482635.6173.100.camel@localhost> <41F54953.7040901@redhat.com> Message-ID: <1106595754.5024.3.camel@localhost> El dl 24 de 01 del 2005 a les 14:15 -0500, en/na Christopher Aillon va escriure: > Josep Puigdemont wrote: > > Hi, > > > > Here it is my short wish list for FC4, if I may send one ;-) > > I don't know if this has been mentioned before or not, but I for one > > would like to see localized versions of Firefox for each installed > > language, by default. > > The version in rawhide does this already, at least for the languages > that Firefox have been translated into already. I've just been sort of > swamped and haven't had time to backport to fc3 yet. great news, thanks a lot! I can hardly wait ;-) /Josep From kyrre at solution-forge.net Mon Jan 24 19:50:12 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Mon, 24 Jan 2005 20:50:12 +0100 Subject: suggests/requires in rpm - missingOK In-Reply-To: <1106579190.3877.33.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com> <1106572460.3877.8.camel@localhost.localdomain> <41F4F764.9000005@nc.rr.com> <1106574829.3877.11.camel@localhost.localdomain> <41F50354.2030108@nc.rr.com> <1106579190.3877.33.camel@localhost.localdomain> Message-ID: <1106596212.7794.20.camel@localhost.localdomain> Should the missingOK flag just make you able to *install* a package without the package which "may be missing", but not upgrade - say if you have a libary that needs to be upgraded in paralell to an app, and you upgraded the app but not the lib (because of slow packager etc) - then some functionality would suddenly just wanish... From jspaleta at gmail.com Mon Jan 24 19:57:57 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Jan 2005 14:57:57 -0500 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> Message-ID: <604aa791050124115732488573@mail.gmail.com> On Mon, 24 Jan 2005 19:25:44 +0000, Mike Hearn wrote: > Face it: people will run the software they want. If you make it difficult > or annoying for them out of a misguided sense that > security-through-obnoxiousness is OK, they'll just use Windows which > doesn't do much for security at all but at least makes it easy for the > user to achieve their goal. Yeah... i like AOL's new commercials about virus protection which speak to your point about Windows Acheiving one goal quickly can have very serious long term effects thanks to the insecurity of the quick solution. Design decisions meant to make things easier upfront can have serious security implications. There is always tension between security and quick solutions. Let them use windows... i have no problem with people choosing to use insecure technology. But i do have a problem setting up this project in a way that makes it "very simple" to run old, unmaintained, vulnerable libraries by inexperienced users of Fedora. You can do some pretty flexible things on the commandline with rpm if you really want to do it and I'm not arguing that ability should be taken away. But i don't want encourage the general user base to use packaged libraries from old trees that are no longer being maintained just because it happens to be a package they find on the net in an old ftp. And i definitely want to encourage package builders to rebuild against libraries that are being maintained. > > The best solution is for libraries to not break backwards compatibility > every other week, that way security fixes are magically present even for 5 > year old apps. This is orthogonal to packaging issues... and frankly... not something a distributor of libraries can dictate to each upstream project. Please take your crusade to each and every component project so no package distributor will ever have to deal with these questions. > Seriously, 5 years is really nothing, it's all about mindset. If this were debian... with debian timescales for the development and end-of-life... 5 years isnt that long. But this isn't debian.. and this project doesn't have those sorts of timescales... so with respect to FC's timetable 5 years is definitely a long time. -jef From n3npq at nc.rr.com Mon Jan 24 19:58:09 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 14:58:09 -0500 Subject: suggests/requires in rpm - missingOK In-Reply-To: <1106596212.7794.20.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com> <1106572460.3877.8.camel@localhost.localdomain> <41F4F764.9000005@nc.rr.com> <1106574829.3877.11.camel@localhost.localdomain> <41F50354.2030108@nc.rr.com> <1106579190.3877.33.camel@localhost.localdomain> <1106596212.7794.20.camel@localhost.localdomain> Message-ID: <41F55351.5020700@nc.rr.com> Kyrre Ness Sjobak wrote: >Should the missingOK flag just make you able to *install* a package >without the package which "may be missing", but not upgrade - say if you >have a libary that needs to be upgraded in paralell to an app, and you >upgraded the app but not the lib (because of slow packager etc) - then >some functionality would suddenly just wanish... > > Nah, convoluting install vs upgrade mode behavior changes into "missingok" would make everyone's head hurt. Certainly gives me a headache ;-) Nice and KISSy, "missingok" is a "optional" edge in a dependency graph until the depsolver guys catch up ... 73 de Jeff From aoliva at redhat.com Mon Jan 24 20:29:44 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 24 Jan 2005 18:29:44 -0200 Subject: suggests/requires in rpm In-Reply-To: <41F508D3.7060409@nc.rr.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com> <1106572460.3877.8.camel@localhost.localdomain> <1106577137.3597.36.camel@cutter> <41F508D3.7060409@nc.rr.com> Message-ID: On Jan 24, 2005, Jeff Johnson wrote: > Meanwhile, rpm -e becomes possible for end-users, albeit at the > expense of flip-flop through anaconda. > That appears to be progress forward. IMHO what would be make this undoubtedly forward progress would be some means to adorn the graph arrow with an additional annotation that would aid the depsolver in figuring out whether to bring in the additional package, to avoid the very flip-flop that many might regard as a regression. The annotation I have in mind would go like `if upgrading from V-R <= v-r' (where v-r is presumed to be less than the current package V-R), then bring in the additional dependency. This addresses the issue of updates/upgrades bringing in new functionality, but not forcing them onto the user that chose to live without the new functionality after the upgrade that introduced it. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From ville.skytta at iki.fi Mon Jan 24 20:22:13 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 24 Jan 2005 22:22:13 +0200 Subject: RFC: Soname in rpm name In-Reply-To: <20050124190613.GJ19903@neu.nirvana> References: <20050124190613.GJ19903@neu.nirvana> Message-ID: <1106598133.15146.36.camel@bobcat.mine.nu> On Mon, 2005-01-24 at 20:06 +0100, Axel Thimm wrote: > On Mon, Jan 24, 2005 at 11:34:03AM +0100, Aurelien Bompard wrote: > > > http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowToAdvanced#Library_policy > > http://www.debian.org/doc/debian-policy/ch-sharedlibs.html > > > > How about a similar policy for Fedora ? Is it the best solution to this > > problem ? > > I think this is an area, where other distributions have found nice > solutions and Fedora/Red Hat should simply use one of the existing > policies (instead of creating one from scratch). I sort of agree, but shipping such packages should be done only if absolutely necessary in FC/FE. Carrying backwards compatibility baggage is not something that aligns well with the project's objectives IMO. See eg. points 5 and 7 in Objectives (and maybe 3 in Non-Objectives) at http://fedora.redhat.com/about/objectives.html Of course, there are other distributions with other kinds of focuses than the Fedora one where doing this soname-in-name thing might actually be a good general rule of thumb rather than an ugly exception. From ville.skytta at iki.fi Mon Jan 24 20:27:32 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 24 Jan 2005 22:27:32 +0200 Subject: RFC: Soname in rpm name In-Reply-To: <20050124114258.113f6245@nausicaa.camperquake.de> References: <1106563530.26412.15.camel@localhost.localdomain> <20050124114258.113f6245@nausicaa.camperquake.de> Message-ID: <1106598452.15146.41.camel@bobcat.mine.nu> On Mon, 2005-01-24 at 11:42 +0100, Ralf Ertzinger wrote: > Hi. > > Peter Backlund wrote: > > > I've seen it in a number of spec files. > > I'm doing this in my spec files so these three variables are at the > very top of the file, while "Name: ..." and the others may be some > way further down. Another way to achieve this is to... *drum roll*... place those three real "Name:, Version:, Release:" lines at the very top of the spec file! ;) See eg. the spec templates in fedora-rpmdevtools in pre- extras. From elanthis at awesomeplay.com Mon Jan 24 20:39:49 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 24 Jan 2005 15:39:49 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <604aa791050124115732488573@mail.gmail.com> References: <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <604aa791050124115732488573@mail.gmail.com> Message-ID: <1106599189.2559.59.camel@support02.civic.twp.ypsilanti.mi.us> On Mon, 2005-01-24 at 14:57 -0500, Jeff Spaleta wrote: > Let them use windows... i have no problem with people choosing to use > insecure technology. > But i do have a problem setting up this project in a way that makes it > "very simple" to run old, unmaintained, vulnerable libraries by > inexperienced users of Fedora. You can do some pretty flexible You're not going to stop anyone from installing old libraries; you're just stopping people from running modern applications that depend on last week's libraries. A user's system basically becomes impossible to upgrade and impossible to install new software on until the entire Open Source world recompiles all their packages for the new library. If two libraries could be installed at once the user wouldn't be trapped during the transition - they could just get on with life as normal. > be a package they find on the net in an old ftp. And i definitely > want to encourage package builders to rebuild against libraries that > are being maintained. Is Fedora supposed to be an exercise in speedy RPM rebuilding, or an operating system? > > > > > The best solution is for libraries to not break backwards compatibility > > every other week, that way security fixes are magically present even for 5 > > year old apps. > > This is orthogonal to packaging issues... and frankly... not something > a distributor of libraries can dictate to each upstream project. > Please take your crusade to each and every component project so no > package distributor will ever have to deal with these questions. Oh, but they will, eventually. Looks like Fedora added a gtk2 package instead of just updating the gtk package to the 2.x series. You guys did great with gtk, so what's the problem with other packages? gtk1 is completely unmaintained and not only installed on many users machines, but even shipped with Fedora. ;-) Unfortunately, Fedora seems to be moving towards relying on huge massive centralization of software packages to resolve broken packaging and lazy development. If it isn't shipped with Fedora Core/Extras, users aren't allowed to use it? From seanlkml at sympatico.ca Mon Jan 24 20:54:35 2005 From: seanlkml at sympatico.ca (Sean) Date: Mon, 24 Jan 2005 15:54:35 -0500 (EST) Subject: suggests/requires in rpm In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com><1106422766.16789.55.camel@localhost.localdomain><604aa79105012212112b0b3bee@mail.gmail.com><41F2B7E9.9060305@gmail.com><604aa79105012215234bf32d3f@mail.gmail.com><20050122233856.GA16555@devserv.devel.redhat.com><604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org><41F30E60.5050605@nc.rr.com><604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com><1106572460.3877.8.camel@localhost.localdomain><1106577137.3597.36.camel@cutter> <41F508D3.7060409@nc.rr.com> Message-ID: <34047.10.10.10.28.1106600075.squirrel@linux1> On Mon, January 24, 2005 3:29 pm, Alexandre Oliva said: > The annotation I have in mind would go like `if upgrading from V-R <= > v-r' (where v-r is presumed to be less than the current package V-R), > then bring in the additional dependency. > > This addresses the issue of updates/upgrades bringing in new > functionality, but not forcing them onto the user that chose to live > without the new functionality after the upgrade that introduced it. I think what you are saying is that you want the missingok dependencies installed the first time, but not again if the user subsequently removes them? If so, is this annotation really required? I think the following rules accomplish the same thing: If the currently installed version has the same missingok annotation as is given in the new rpm, then install each dependency only if an early version is currently installed (handle each such dependecy like rpm -F). Otherwise, install each dependant rpm as if it were required, (ie. handle like rpm -U, it must represent new functionality, or been recently made optional). Sean. From feliciano.matias at free.fr Mon Jan 24 21:14:15 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 24 Jan 2005 22:14:15 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <1106599189.2559.59.camel@support02.civic.twp.ypsilanti.mi.us> References: <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <604aa791050124115732488573@mail.gmail.com> <1106599189.2559.59.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1106601256.9012.42.camel@one.myworld> Le lundi 24 janvier 2005 ? 15:39 -0500, Sean Middleditch a ?crit : > Is Fedora supposed to be an exercise in speedy RPM rebuilding, or an > operating system? Fedora is (or try to be) : http://fedora.redhat.com/about/objectives.html Create a complete general-purpose operating system with capabilities equivalent to competing operating systems, built for and by a community ? those who not only consume, but also produce for the good of other community members. * Build the operating system exclusively from open source software. Easy to recompile. * Do as much of the development work as possible directly in the upstream packages. This includes updates; our default policy will be to upgrade to new versions for security as well as for bugfix and new feature update releases of packages. Sync with upstream. * Provide a robust development platform for building software, particularly open source software. Open source (again) * Be on the leading edge of open source technology, by adopting and helping develop new features and version upgrades. Promote new technologies. Fedora is not (or try to avoid) : Non-Objectives of Fedora Core: 1. Slow rate of change. 2. .... 3. Being a dumping ground for unmaintained or poorly designed software. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From czar at czarc.net Mon Jan 24 21:19:22 2005 From: czar at czarc.net (Gene C.) Date: Mon, 24 Jan 2005 16:19:22 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <20050121234943.GA6392@nostromo.devel.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> Message-ID: <200501241619.22682.czar@czarc.net> On Friday 21 January 2005 18:49, Bill Nottingham wrote: > Jeff Spaleta (jspaleta at gmail.com) said: > > If ANY of these packages are not going to be maintained by the > > original Core maintainers as ?part of Extras... tell the community NOW > > so that someone can step up and offer to maintain it. > > You're absolutely correct. This is how it stands, AFAIK: > > Orphaned: > - aumix > - balsa/libesmtp (really, they go together) > - cdp > - comsat > - grip > - gv > - pdksh (then again, it's getting replaced by ksh) > - sylpheed > - xosview > - xsnow > - ytalk > > Not sure: > - diskcheck > - freeciv > - gnuchess > - pan > - xboard I propose that a2ps and its associated psutils is orphaned ... there has been no activity by the originator/maintainer since 2000. The associated mailing list has had little traffic other than spam in years. HOWEVER, I would also propose keeping it in Core since it serves a very useful basic function of pretty-printing many forms of source code files. Nevertheless, I would also agree that it should be moved to Extras when that is more operational. I, personally, would not be willing to step up to maintenance although someone else may be willing ... locale support is missing. -- Gene From elanthis at awesomeplay.com Mon Jan 24 21:23:31 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Mon, 24 Jan 2005 16:23:31 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <1106601256.9012.42.camel@one.myworld> References: <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <604aa791050124115732488573@mail.gmail.com> <1106599189.2559.59.camel@support02.civic.twp.ypsilanti.mi.us> <1106601256.9012.42.camel@one.myworld> Message-ID: <1106601812.2559.66.camel@support02.civic.twp.ypsilanti.mi.us> On Mon, 2005-01-24 at 22:14 +0100, F?liciano Matias wrote: > Fedora is (or try to be) : > > http://fedora.redhat.com/about/objectives.html > Create a complete general-purpose operating system with > capabilities equivalent to competing operating systems, built > for and by a community ? those who not only consume, but also > produce for the good of other community members. "capabilities equivalent to competing operating systems"... does that not include "install stuff" for some reason? The Open Source community is pretty good these days about using sonames properly. It's silly to have packages go and break all that effort. Sonames exist for a reason. > Fedora is not (or try to avoid) : > > Non-Objectives of Fedora Core: > > 1. Slow rate of change. > > 2. .... > > 3. Being a dumping ground for unmaintained or poorly > designed software. Neither of which have I ever asked for, nor would I. The number of incredibly absurd ways people seem to interpret "let's not break stuff pointlessly" is constantly amazing, and starting to become rather dumbfounding. From cmadams at hiwaay.net Mon Jan 24 21:38:38 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 24 Jan 2005 15:38:38 -0600 Subject: rawhide report: 20050121 changes In-Reply-To: <200501241619.22682.czar@czarc.net> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> <200501241619.22682.czar@czarc.net> Message-ID: <20050124213838.GC1488113@hiwaay.net> Once upon a time, Gene C. said: > I propose that a2ps and its associated psutils is orphaned ... there has been > no activity by the originator/maintainer since 2000. The associated mailing > list has had little traffic other than spam in years. What activity is needed for psutils? I have been using psutils for years; I was glad to see it added to RHL back whenever that was. Just because something hasn't changed in a while doesn't mean it should be dropped; AFAIK there is no other utility that does what psutils does. Just because something hasn't changed doesn't mean it should be dropped or moved to Extras. > HOWEVER, I would also propose keeping it in Core since it serves a very > useful basic function of pretty-printing many forms of source code files. As for a2ps, we also have GNU enscript (which does more I believe), so a2ps could move to Extras. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Axel.Thimm at ATrpms.net Mon Jan 24 21:55:58 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 24 Jan 2005 22:55:58 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <1106598133.15146.36.camel@bobcat.mine.nu> References: <20050124190613.GJ19903@neu.nirvana> <1106598133.15146.36.camel@bobcat.mine.nu> Message-ID: <20050124215558.GB31520@neu.nirvana> On Mon, Jan 24, 2005 at 10:22:13PM +0200, Ville Skytt? wrote: > On Mon, 2005-01-24 at 20:06 +0100, Axel Thimm wrote: > > On Mon, Jan 24, 2005 at 11:34:03AM +0100, Aurelien Bompard wrote: > > > > > http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowToAdvanced#Library_policy > > > http://www.debian.org/doc/debian-policy/ch-sharedlibs.html > > > > > > How about a similar policy for Fedora ? Is it the best solution to this > > > problem ? > > > > I think this is an area, where other distributions have found nice > > solutions and Fedora/Red Hat should simply use one of the existing > > policies (instead of creating one from scratch). > > I sort of agree, but shipping such packages should be done only if > absolutely necessary in FC/FE. Carrying backwards compatibility baggage > is not something that aligns well with the project's objectives IMO. But on the contrary it is not directed compatibility, but rather a unilateral, you have a scheme for both forward and backward compatibility packages, so that third parties (as well as Red Hat as a vendor itslef) can easily move forward to the next bleeding edge softwrae release. > See eg. points 5 and 7 in Objectives (and maybe 3 in Non-Objectives) at > http://fedora.redhat.com/about/objectives.html In the sense of the above I would even see them as promoting arguments. Currently if Red Hat ships libfoo.so.2 and you want to have libfoo.so.3, so need to go through a couple of hops, replace core packages with compatibility libs (or even worse, not care about dependencies on libfoo.so.2) and finally called a heretic. Been there, seen that ... If this idiom already existed, one would simply package the new library into libfoo3 and no clashes/replacements with libfoo2 would occur. (But note: the above is slightly simplified, there are a coupdl of controlable issues that must be taken care of). > Of course, there are other distributions with other kinds of focuses > than the Fedora one where doing this soname-in-name thing might actually > be a good general rule of thumb rather than an ugly exception. If we are talking on naming schemes we cannot only consider Fedora, as its bigger brother RHEL will share the same. But I believe that the soname-in-rpmname based approach is both suitable for a stable ABI like RHEL as well as a fast pacing one like Fedora's. At the very end it only adds flexibility at the cost of required garbage collection that can easily be solved. And note that the frame objectives of the two distributions already deploying this scheme are indeed very close to RHEL (infinite release cycles of Debian ;) and Fedora (Mandrake's latest and greatest). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From feliciano.matias at free.fr Mon Jan 24 22:02:02 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 24 Jan 2005 23:02:02 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <1106601812.2559.66.camel@support02.civic.twp.ypsilanti.mi.us> References: <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <604aa791050124115732488573@mail.gmail.com> <1106599189.2559.59.camel@support02.civic.twp.ypsilanti.mi.us> <1106601256.9012.42.camel@one.myworld> <1106601812.2559.66.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1106604123.9012.50.camel@one.myworld> Le lundi 24 janvier 2005 ? 16:23 -0500, Sean Middleditch a ?crit : > "capabilities equivalent to competing operating systems"... does that > not include "install stuff" for some reason? > > The Open Source community is pretty good these days about using sonames > properly. It's silly to have packages go and break all that effort. > Sonames exist for a reason. > I replied to "Fedora supposed to be an exercise in speedy RPM rebuilding, or an operating system?". I don't have any problem with libthis0, libthis1, libthat0, ... If this help, I think this can be a good practise. But it's not the primary focus of Fedora. This does not mean Fedora should ignore compatibility issue. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Axel.Thimm at ATrpms.net Mon Jan 24 22:02:13 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 24 Jan 2005 23:02:13 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <41F54D5B.1000208@nc.rr.com> References: <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> <20050124185747.GI19903@neu.nirvana> <41F54D5B.1000208@nc.rr.com> Message-ID: <20050124220213.GC31520@neu.nirvana> On Mon, Jan 24, 2005 at 02:32:43PM -0500, Jeff Johnson wrote: > Axel Thimm wrote: > > >On Mon, Jan 24, 2005 at 03:05:29PM -0200, Alexandre Oliva wrote: > > > > > >>On Jan 24, 2005, Ralf Ertzinger wrote: > >> > >> > >> > >>>Hi. > >>>Aurelien Bompard wrote: > >>> > >>> > >>>>I did not know, is it possible to have a tool find the rpms that no rpms > >>>>depend on, and ask to remove them ? > >>>> > >>>> > >>>The problem with this is that RPM does not indicate whether a package has > >>>"end user value" (a command line or GUI program, or a daemon), or is just > >>>a support library needed by said end user programs, which can be removed > >>>if not needed by anyone. > >>> > >>> > >>Could we perhaps add such a flag to the rpm database? Then the > >>installer and the various other package installation front-ends could > >>mark user- (or comps-)requested packages as having end user value, and > >>everything else brought in to satisfy dependencies such that it is (or > >>can be) removed as soon as no dependencies remain. > >> > >> > > > >ATrpms has started marking library only packages with > > > > Provides: shared-library-package > > > >so these packages can be identifies with > > > > rpm --whatprovides shared-library-package > > > >and be probed for garbage collection. > > > >I.e. there is no need to extend rpm, you have everything already in > >place. > > > > > > And there's no need for the *.spec churn and the marker in dependencies: > > rpm -qa 'classdict=*shared object*' wow, nice trick, I'm impressed! With rpm one cannot stop learning :) Indeed, if all shared libs were already packaged in the suggested scheme, this would catch them all. I don't think everything should be packaged that way (distribution invariants like glibc for instance not), and such a idiom would also need its time to spread into rawhide, so having the Provides: shared-library-package is a good hook to distinguish leaf-disposable packages from others that are bundling libs and further stuff. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From shiva at sewingwitch.com Mon Jan 24 22:06:00 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 24 Jan 2005 14:06:00 -0800 Subject: Packet Inspection In-Reply-To: <41F5303D.8050305@israel-jugendtag.ch> References: <41F5303D.8050305@israel-jugendtag.ch> Message-ID: --On Monday, January 24, 2005 6:28 PM +0100 Roland Kaeser wrote: > I know this would rater belong to the user list but I'm not a subscriber > of this list so I try to post it here. > I need a package inspection tool for a very large firewall project. The > ipt_string functionality does not longer exist in the iptables > implementation of the kernel 2.6 so I need a other tool which drops all > packages or communication parts which contains dangerous contents. I've > searched a lot of websites but I couldn't find anything which reliabley > implements a such function. Is there somebody which has experiences in > these field and can advise me? This functionality should been implemented > on a Fedora 2 machine which stands in the front of the application level > firewalls to prevent its from traffic which is not productive. I'd strongly recommend asking on the netfilter list. Red Hat has a policy of only adopting kernel features that are part of the upstream core kernel, and doesn't include experimental stuff. So you'll probably need to get the Fedora kernel source RPM and make a custom build with the additional netfilter modules that you need. I've quoted your whole question for those who might be able to answer once they realize you mean IP packets and not RPM packages. I notice a lot of people using "package" instead of "packet" and wonder if this mistranslation is coming from some particular source? How did you come to use the term "package"? Maybe we can go upstream and get the usage corrected. (Mind you, I'm a dumb provincial American so I only speak one language, and this isn't meant as an insult to those of you smart enough to take on English in addition to your native language.) From Axel.Thimm at ATrpms.net Mon Jan 24 22:08:47 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 24 Jan 2005 23:08:47 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <604aa791050124070243cfe95f@mail.gmail.com> References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> Message-ID: <20050124220847.GD31520@neu.nirvana> On Mon, Jan 24, 2005 at 10:02:52AM -0500, Jeff Spaleta wrote: > On Mon, 24 Jan 2005 09:15:14 -0500, Sean Middleditch > wrote: > > We _have_ had this problem, btw. The problem is that it's not generally > > developers that notice it. It's the user that just want to have their > > machine work. I go to install third party app Foo from Foo's web site, > > it needs libbar.so.2, Fedora only has libbar.so.1, and many other apps > > on the net require libbar.so.1. > > A third part website is packaging libbar.so.2 in a package of the > same package name as Feodora's libbar.so.1? Why would a third party > site do that? Unless the intention was to replace the Fedora package? > Isn't this an example of the care 3rd party packagers should be taking > to make sure their packages work well with Core? I would reverse the setup: Shouldn't the core distribution have scheme to allow for doing so without blowing away half of the system? After all sonames were "invented" upstream to allow coexistence of libraries of different sonames, so having the soname-in-rpmname scheme follows this philosophy and allows 3rd party packagers (and the vendor itself) to have clean ways of updating/coinstalling a new library. The current solutions are too hackish to be even considered a natural approach. Look at gcc34 and the required obsoletes in gcc to deal with this cruft. A proper scheme of coexisting packages for certain classes (libraries, compilers, interpreters) layed out once and for all will bring piece here forever ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From czar at czarc.net Mon Jan 24 22:16:43 2005 From: czar at czarc.net (Gene C.) Date: Mon, 24 Jan 2005 17:16:43 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <20050124213838.GC1488113@hiwaay.net> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <200501241619.22682.czar@czarc.net> <20050124213838.GC1488113@hiwaay.net> Message-ID: <200501241716.43609.czar@czarc.net> On Monday 24 January 2005 16:38, Chris Adams wrote: > Once upon a time, Gene C. said: > > I propose that a2ps and its associated psutils is orphaned ... there has > > been no activity by the originator/maintainer since 2000. The associated > > mailing list has had little traffic other than spam in years. > > What activity is needed for psutils? I have been using psutils for > years; I was glad to see it added to RHL back whenever that was. Just > because something hasn't changed in a while doesn't mean it should be > dropped; AFAIK there is no other utility that does what psutils does. psutils is not a problem ... it is a2ps which needs some work (mainly locale support). > > Just because something hasn't changed doesn't mean it should be dropped > or moved to Extras. Dropped ... NO! Moved to Extras, maybe. > > > HOWEVER, I would also propose keeping it in Core since it serves a very > > useful basic function of pretty-printing many forms of source code files. > > As for a2ps, we also have GNU enscript (which does more I believe), so > a2ps could move to Extras. I had not looked at enscript and it does do some of the language support stuff that a2ps does. I like a2ps better but that is a personal preference. -- Gene From rms at 1407.org Mon Jan 24 22:24:30 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Mon, 24 Jan 2005 22:24:30 +0000 Subject: playing with xen... Message-ID: <1106605470.3515.3.camel@roque> Hi, I've been trying out xen... some info that might (or not) be useful: /etc/X11/xorg.conf got rewritten. Now, I'm not using rhgb. My xen environment is, basically, booting into run level 3 (to reduce complexity), and trying to test it, so there's no X anywhere. When I finish being frustrated for not having net yet (must be some quirk between xen and natsemi or something it depends on) I reboot to get my default desktop. A script running on 5 moves /lib/tls.disabled back into /lib/tls Since xen is starting to be integrated, I understand there are weird things until the kernel can stabilise, but the xorg.conf file being rewritten puzzles me. Regards, Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lsomike at futzin.com Mon Jan 24 22:23:26 2005 From: lsomike at futzin.com (Mike Klinke) Date: Mon, 24 Jan 2005 16:23:26 -0600 Subject: Package Inspection In-Reply-To: <41F5303D.8050305@israel-jugendtag.ch> References: <41F5303D.8050305@israel-jugendtag.ch> Message-ID: <200501241623.26642.lsomike@futzin.com> On Monday 24 January 2005 11:28, Roland Kaeser wrote: > Hi all > > I need a package inspection tool for a very large firewall > project. The ipt_string functionality does not longer exist in > the iptables implementation of the kernel 2.6 so I need a other > tool which drops all packages or communication parts which > contains dangerous contents. I've not played with it but perhaps snort with its "inline" mode will help here. >From the docs ... ============== Snort-Inline takes packets from iptables instead of libpcap. It then uses new rule types to help iptables make pass or drop decisions based on snort rules. .... NEW RULE TYPES AND WHAT THEY DO: drop - The drop rule type will tell iptables to drop the packet and log it via usual snort means. reject - The reject rule type will tell iptables to drop the packet, log it via usual snort means, and send a TCP reset if the protocol is TCP or an icmp port unreachable if the protocol is UDP. sdrop - The sdrop rule type will tell iptables to drop the packet. Nothing is logged. =================== Regards, Mike Klinke From gauret at free.fr Mon Jan 24 22:26:02 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 24 Jan 2005 23:26:02 +0100 Subject: RFC: Soname in rpm name References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E672.3020103@nc.rr.com> <20050124132138.2bdbc4c9.fedora@wir-sind-cool.org> <41F4EB14.3040302@nc.rr.com> Message-ID: Mike Hearn wrote: > This whole mess could be avoided if libkexif had not broken backwards > compatibility of course ... it's perhaps not too late to go back and do a > new release that doesn't do so? Well, libkexif is a few months old. We can expect unstability for new projects, and as one of Fedora's aim is to be on the bleeding edge, we will see this problem more and more frequently. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info Recursion: (n.) See "Recursion". From byte at aeon.com.my Mon Jan 24 16:04:02 2005 From: byte at aeon.com.my (Colin Charles) Date: Tue, 25 Jan 2005 00:04:02 +0800 Subject: further package removals/potential package removals In-Reply-To: <20050122165916.GH2898@devserv.devel.redhat.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <1106369463.5183.24.camel@one.myworld> <20050122165916.GH2898@devserv.devel.redhat.com> Message-ID: <1106582643.22263.39.camel@localhost.localdomain> On Sat, 2005-01-22 at 11:59 -0500, Alan Cox wrote: > > I love ddd :-) > > I request to move lesstif and openmotif21 to Fedora Extra. But keep > > openmotif (use by ddd). > > You love ddd but is it a critical base package ? The idea that > "extras" == > "inferior" has to go away to make it work well. Its probably time consuming to change that "extras" == "inferior" idea; because at the moment, we still haven't worked around to define Extras yet All these package removals should go on tandem with us launching Extras officially, imho -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From jspaleta at gmail.com Mon Jan 24 22:29:55 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Jan 2005 17:29:55 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <20050124220847.GD31520@neu.nirvana> References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> Message-ID: <604aa791050124142972c325cc@mail.gmail.com> On Mon, 24 Jan 2005 23:08:47 +0100, Axel Thimm wrote: > The current solutions are too hackish to be even considered a natural > approach. Look at gcc34 and the required obsoletes in gcc to deal with > this cruft. A proper scheme of coexisting packages for certain classes > (libraries, compilers, interpreters) layed out once and for all will > bring piece here forever ;) But is there clean way to indicate to a user that an older version of the library is no longer being maintained and has "expired" and won't be getting any security updates? This is not not just an issue of finding the unused libs. An unmaintained library package could still be in use by an application. How do you make the admin aware that a library package they are using is no longer being maintained so they can review whether or not to keep it and the applications using it installed? Unless there is a mechanism by which admins are informed of an expiring library so they can make an informed decision, i don't feel its worthwhile to encourage the accumulation of older libraries at all. -jef From norm at turing.une.edu.au Mon Jan 24 22:31:04 2005 From: norm at turing.une.edu.au (Norman Gaywood) Date: Tue, 25 Jan 2005 09:31:04 +1100 Subject: further package removals/potential package removals In-Reply-To: <1106582643.22263.39.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <1106369463.5183.24.camel@one.myworld> <20050122165916.GH2898@devserv.devel.redhat.com> <1106582643.22263.39.camel@localhost.localdomain> Message-ID: <20050124223104.GA26096@turing.une.edu.au> On Tue, Jan 25, 2005 at 12:04:02AM +0800, Colin Charles wrote: > because at the moment, we still haven't worked around to define Extras > yet Is there a definition of Core? -- Norman Gaywood, Systems Administrator School of Mathematics, Statistics and Computer Science University of New England, Armidale, NSW 2351, Australia norm at turing.une.edu.au Phone: +61 (0)2 6773 2412 http://turing.une.edu.au/~norm Fax: +61 (0)2 6773 3312 Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html From ville.skytta at iki.fi Mon Jan 24 22:34:27 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 25 Jan 2005 00:34:27 +0200 Subject: RFC: Soname in rpm name In-Reply-To: <20050124215558.GB31520@neu.nirvana> References: <20050124190613.GJ19903@neu.nirvana> <1106598133.15146.36.camel@bobcat.mine.nu> <20050124215558.GB31520@neu.nirvana> Message-ID: <1106606067.15146.87.camel@bobcat.mine.nu> On Mon, 2005-01-24 at 22:55 +0100, Axel Thimm wrote: > On Mon, Jan 24, 2005 at 10:22:13PM +0200, Ville Skytt? wrote: > > I sort of agree, but shipping such packages should be done only if > > absolutely necessary in FC/FE. Carrying backwards compatibility baggage > > is not something that aligns well with the project's objectives IMO. > > But on the contrary it is not directed compatibility, but rather a > unilateral, you have a scheme for both forward and backward > compatibility packages, so that third parties (as well as Red Hat as a > vendor itslef) can easily move forward to the next bleeding edge > softwrae release. Well, I guess it can be seen in many ways. Note that I don't object to a common consistent naming scheme at all, on the contrary. My concern is that such a scheme _when applied as a standard procedure for all library packages_ would probably lower the barrier for including backwards compatibility cruft for which there will probably no interested parties to clean it up nor maintain. And once something is in, it's always hard to drop it; there will always be someone yelling "don't remove fooX.Y.Z, I need it for my ancient baz package". I don't think that stuff belongs in Fedora. From Axel.Thimm at ATrpms.net Mon Jan 24 22:40:43 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 24 Jan 2005 23:40:43 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <604aa791050124142972c325cc@mail.gmail.com> References: <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> Message-ID: <20050124224043.GI31520@neu.nirvana> On Mon, Jan 24, 2005 at 05:29:55PM -0500, Jeff Spaleta wrote: > On Mon, 24 Jan 2005 23:08:47 +0100, Axel Thimm wrote: > > The current solutions are too hackish to be even considered a natural > > approach. Look at gcc34 and the required obsoletes in gcc to deal with > > this cruft. A proper scheme of coexisting packages for certain classes > > (libraries, compilers, interpreters) layed out once and for all will > > bring piece here forever ;) > > But is there clean way to indicate to a user that an older version of > the library is no longer being maintained and has "expired" and won't > be getting any security updates? This is not not just an issue of > finding the unused libs. An unmaintained library package could still > be in use by an application. How do you make the admin aware that a > library package they are using is no longer being maintained so they > can review whether or not to keep it and the applications using it > installed? Unless there is a mechanism by which admins are informed > of an expiring library so they can make an informed decision, i don't > feel its worthwhile to encourage the accumulation of older libraries > at all. Not sure how this fits in here. These are valid points you make, but they are valid for both the current and a soname-in-the-rpmname scheme :) The problem you are addressing is much larger, if you do a RH7.3 -> RH8.0 -> ... -> FC3 upgrade party you'll find that your system has quite a lot of old unsupported cruft left over. Any deprecated not replaced package will be there including its security implications. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Mon Jan 24 22:48:34 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 24 Jan 2005 23:48:34 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <1106606067.15146.87.camel@bobcat.mine.nu> References: <20050124190613.GJ19903@neu.nirvana> <1106598133.15146.36.camel@bobcat.mine.nu> <20050124215558.GB31520@neu.nirvana> <1106606067.15146.87.camel@bobcat.mine.nu> Message-ID: <20050124224834.GJ31520@neu.nirvana> On Tue, Jan 25, 2005 at 12:34:27AM +0200, Ville Skytt? wrote: > On Mon, 2005-01-24 at 22:55 +0100, Axel Thimm wrote: > > On Mon, Jan 24, 2005 at 10:22:13PM +0200, Ville Skytt? wrote: > > > I sort of agree, but shipping such packages should be done only if > > > absolutely necessary in FC/FE. Carrying backwards compatibility baggage > > > is not something that aligns well with the project's objectives IMO. > > > > But on the contrary it is not directed compatibility, but rather a > > unilateral, you have a scheme for both forward and backward > > compatibility packages, so that third parties (as well as Red Hat as a > > vendor itslef) can easily move forward to the next bleeding edge > > softwrae release. > > Well, I guess it can be seen in many ways. Note that I don't object to > a common consistent naming scheme at all, on the contrary. > > My concern is that such a scheme _when applied as a standard procedure > for all library packages_ would probably lower the barrier for including > backwards compatibility cruft for which there will probably no > interested parties to clean it up nor maintain. There's no need to, these packages can be easily marked (see my other replies in this thread) and removed even in cron-jobs. > And once something is in, it's always hard to drop it; there will > always be someone yelling "don't remove fooX.Y.Z, I need it for my > ancient baz package". I don't think that stuff belongs in Fedora. I don't want any backward compatibility _content_ in Fedora, but a proper forward/backward combatibility _mechanism_. Fedora Core (rawhide) should continue its aggressive schedule, it only allows for flexibility when needed. It even allows to skip concerning about creating compatibility libs for selected bits of Fedora Core N-1 and N-2 for Fedora Core N, since the libs from the previous releases can effectively simply be copied over with no renames to compat-this and compat-that, and most importantly no new QA, you know they worked for any ISV. So I guess we are on the same side ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Mon Jan 24 22:54:20 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Jan 2005 17:54:20 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <20050124224043.GI31520@neu.nirvana> References: <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> Message-ID: <604aa791050124145435e5a102@mail.gmail.com> On Mon, 24 Jan 2005 23:40:43 +0100, Axel Thimm wrote: > Not sure how this fits in here. These are valid points you make, but > they are valid for both the current and a soname-in-the-rpmname scheme > :) keeping the package the same name... regardless of the soname means on distro upgrade the old version gets removed. This works to expire an older library package but breaks externally build apps that need the old library. You want to keep those things from breaking and I want to expired libs off the system. I would prefer to use the sonames in the packages as sparingly as possible.. to minimize the amount of deprecated libraries on system...until there is a solution to the larger question of how expiring of a package is suppose to work. -jef From hp at redhat.com Mon Jan 24 23:01:55 2005 From: hp at redhat.com (Havoc Pennington) Date: Mon, 24 Jan 2005 18:01:55 -0500 Subject: slow hard drives crushing interactivity Message-ID: <1106607715.6122.21.camel@localhost.localdomain> Hi, On my IBM X31 laptop, the system entirely locks up when there's a lot of disk access, some common situations are: - when getting heavily into swap due to a runaway process - when running rpm/yum It's not *technically* locked up (i.e. if you wait long enough it will come back) but in practice you have to reboot if a process has a memory leak, and you can't do any work while running yum. I have 512M of physical memory. I tried reducing swap from 1G to 256M so runaway processes wouldn't require a reboot, but I just now had a runaway process and discovered that less swap helps a little bit (you can at least move the mouse pointer) but I still had to reboot because it was taking multiple minutes to get a window open to run "killall" and the root login times out before the Password: prompt comes up. Some people with real hard drives instead of slow-ass laptop drives say this doesn't happen to them. Is there any solution (that we can enable by default/automatically, not much of a solution otherwise)? Right now it's sort of like running an OS without protected memory. A bad solution (since most people won't know about it) might be a hotkey that says "massively lower the priority of any process that's doing a lot of disk access at the moment" or something. Or just a "kill any process using more memory than I have physical memory," I don't know. Maybe a cap on process size, so there can be 1G virtual memory but an individual app can only use 512M? Maybe when a process reaches 512M we could suspend it and ask the user whether to let it grow further? With a kernel event when processes pass a certain size you could even do that heuristically (with races) by implementing the "kill -STOP" in userspace in response to an event. Would it help to mlock() the X server, window manager, and panel ;-) Or is it just VM tuning that's needed? If there's no automatic way to make this work, maybe there's at least a way to key off a single global desktop vs. server flag rather than requiring more detailed tuning? Havoc From ville.skytta at iki.fi Mon Jan 24 23:19:46 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 25 Jan 2005 01:19:46 +0200 Subject: RFC: Soname in rpm name In-Reply-To: <20050124224834.GJ31520@neu.nirvana> References: <20050124190613.GJ19903@neu.nirvana> <1106598133.15146.36.camel@bobcat.mine.nu> <20050124215558.GB31520@neu.nirvana> <1106606067.15146.87.camel@bobcat.mine.nu> <20050124224834.GJ31520@neu.nirvana> Message-ID: <1106608786.15146.98.camel@bobcat.mine.nu> On Mon, 2005-01-24 at 23:48 +0100, Axel Thimm wrote: > On Tue, Jan 25, 2005 at 12:34:27AM +0200, Ville Skytt? wrote: > > My concern is that such a scheme _when applied as a standard procedure > > for all library packages_ would probably lower the barrier for including > > backwards compatibility cruft for which there will probably no > > interested parties to clean it up nor maintain. > > There's no need to, these packages can be easily marked (see my other > replies in this thread) and removed even in cron-jobs. My concern not about that, but about what's included in the distro, as in DVD's, download.fedora.redhat.com etc. From Axel.Thimm at ATrpms.net Mon Jan 24 23:21:13 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jan 2005 00:21:13 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <604aa791050124145435e5a102@mail.gmail.com> References: <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> Message-ID: <20050124232113.GM31520@neu.nirvana> On Mon, Jan 24, 2005 at 05:54:20PM -0500, Jeff Spaleta wrote: > On Mon, 24 Jan 2005 23:40:43 +0100, Axel Thimm wrote: > > Not sure how this fits in here. These are valid points you make, but > > they are valid for both the current and a soname-in-the-rpmname scheme > > :) > > keeping the package the same name... regardless of the soname means > on distro upgrade > the old version gets removed. This works to expire an older library > package but breaks externally build apps that need the old library. > You want to keep those things from breaking and I want to expired libs > off the system. I would prefer to use the sonames in the packages as > sparingly as possible.. to minimize the amount of deprecated libraries > on system...until there is a solution to the larger question of how > expiring of a package is suppose to work. Already posted in different siblings of this thread and implemented at ATrpms. Auto-expiring packages that should be disposed of if there is no dependency on them should simply provide a fake dependency to hook a garbage collector to. The concept is solid, proven on various distros and even within the Red Hat world at ATrpms. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From seanlkml at sympatico.ca Mon Jan 24 23:29:41 2005 From: seanlkml at sympatico.ca (Sean) Date: Mon, 24 Jan 2005 18:29:41 -0500 (EST) Subject: slow hard drives crushing interactivity In-Reply-To: <1106607715.6122.21.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> Message-ID: <34767.10.10.10.28.1106609381.squirrel@linux1> On Mon, January 24, 2005 6:01 pm, Havoc Pennington said: > Maybe a cap on process size, so there can be 1G virtual memory but an > individual app can only use 512M? This already exists of course, you can set a ulimit on RSS and virtual memory size. > If there's no automatic way to make this work, maybe there's at least a > way to key off a single global desktop vs. server flag rather than > requiring more detailed tuning? I wonder if CKRM (http://ckrm.sourceforge.net/) or ilk might help you? Sean From ed at eh3.com Mon Jan 24 23:35:31 2005 From: ed at eh3.com (Ed Hill) Date: Mon, 24 Jan 2005 18:35:31 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <1106607715.6122.21.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> Message-ID: <1106609731.26628.13.camel@localhost.localdomain> On Mon, 2005-01-24 at 18:01 -0500, Havoc Pennington wrote: > > On my IBM X31 laptop, the system entirely locks up when there's a lot of > disk access, some common situations are: > - when getting heavily into swap due to a runaway process > - when running rpm/yum I agree that the above is a real problem as it occasionally happens to me and the reboots can be mighty disruptive. It would be *very* helpful if kernels could provide/enforce enough interactivity to allow users to kill processes with "runaway disk usage". And though I have no way to prove it, I think recent (eg. 2.6) kernels do a slightly worse job in this area than historic ones (eg. 2.4, 2.2). So are there ways to fix it? And if so, how? Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From hp at redhat.com Mon Jan 24 23:43:44 2005 From: hp at redhat.com (Havoc Pennington) Date: Mon, 24 Jan 2005 18:43:44 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <34767.10.10.10.28.1106609381.squirrel@linux1> References: <1106607715.6122.21.camel@localhost.localdomain> <34767.10.10.10.28.1106609381.squirrel@linux1> Message-ID: <1106610224.6122.29.camel@localhost.localdomain> On Mon, 2005-01-24 at 18:29 -0500, Sean wrote: > On Mon, January 24, 2005 6:01 pm, Havoc Pennington said: > > > Maybe a cap on process size, so there can be 1G virtual memory but an > > individual app can only use 512M? > > This already exists of course, you can set a ulimit on RSS and virtual > memory size. The real question of course is whether we can somehow enable this by default on systems where it makes sense... > > If there's no automatic way to make this work, maybe there's at least a > > way to key off a single global desktop vs. server flag rather than > > requiring more detailed tuning? > > I wonder if CKRM (http://ckrm.sourceforge.net/) or ilk might help you? Same thing there. But yeah it could be useful... I think people are looking at virtualization as a better approach for containing server functions, but something like CKRM could be better for e.g. separating the desktop environment components from the apps to maintain interactivity when an app goes haywire. I don't know. Havoc From michael.favia at insitesinc.com Mon Jan 24 23:44:54 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Mon, 24 Jan 2005 17:44:54 -0600 Subject: slow hard drives crushing interactivity In-Reply-To: <1106607715.6122.21.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> Message-ID: <41F58876.6020507@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Havoc Pennington wrote: > Hi, > > On my IBM X31 laptop, the system entirely locks up when there's a lot of > disk access, some common situations are: > - when getting heavily into swap due to a runaway process > - when running rpm/yum > > It's not *technically* locked up (i.e. if you wait long enough it will > come back) but in practice you have to reboot if a process has a memory > leak, and you can't do any work while running yum. It is amazing what we are completely content putting up with until someone mentions they suffer from the same plight. I really like the idea of being able to launch "System Monitor" aka gnome-system-monitor (via hotkey) to graphically kill any runaway processes (or even just advise me as to which one is the culprit so i can make an informed decision). I don't know how to "force reserve" the resources to make it functional in such a situation but it would save tons of unfinished work (multitasking) that is being lost because of 1 wayward app. - -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB9Yh2BVsNYjF2rDYRAvfTAJ4n697fFdmQHgaP4eiIuqL+3F6pnACggVFP T2B1GE+ma+ZKtjKz89tPBcs= =UDfk -----END PGP SIGNATURE----- From michael.favia at insitesinc.com Tue Jan 25 00:05:42 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Mon, 24 Jan 2005 18:05:42 -0600 Subject: suggests/requires in rpm In-Reply-To: <1106593537.25770.30.camel@opus.phy.duke.edu> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106577137.3597.36.camel@cutter> <200501242308.07535.symbiont@berlios.de> <1106593537.25770.30.camel@opus.phy.duke.edu> Message-ID: <41F58D56.5050000@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 seth vidal wrote: > On Mon, 2005-01-24 at 23:08 +0800, Jeff Pitman wrote: > >>On Monday 24 January 2005 22:32, seth vidal wrote: >> >>>>I, for one, thought Jeff was clear that it's the job of depsolvers >>>>(anaconda, yum, smart, apt) to decide what to do with the extra >>>>information. >>> >>>All that's really been done is to push the decision-making process >>>off on the depsolvers. >> >>Which is what it should do. Depsolvers are becoming the defacto >>interface to the packaging system; responsibility may feel burdensome >>at times, but it's a pretty clear distinction to implement these >>processes at this level. >> >>The less magic RPM does, the better. Depsolvers are more fluid than RPM, > > > Not arguing with you - but figuring out the correct, default behavior at > the depsolver level is not easier :) > > Anyone who thinks the correct behavior is 'ask the user' is deeply > confused about the understanding the average user has about > package/dependency issues. > > We have to have a correct and adequate default state. We can present > options, but we must not rely on the user for this. > For once i agree with every statement in a set of replies :). I do think that it should be handled by the depsolvers and i to that end i raised a discussion regarding implementing a feature like this some time ago (nice and vague:) ). Perhaps we could find some sort of way to integrate this type of information into the current work we are doing on cleaning up the yum output? Describing the extra packages as optional and providing additional functionality with perhaps a little blurb that describes what it adds would be a modest first step. Providing the ability to include/deny such optional packages by default and without approval would be another. I could see this framed in our current revision of possible yum outputs for user confirmation of the transaction. - -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB9Y1WBVsNYjF2rDYRAoVNAJsH/YFXrdF2dY5dtJKk5Aez1+QCXgCghgPD Lbc7YMpWS5V5XvJ0oBwnQVU= =tVWk -----END PGP SIGNATURE----- From michael.favia at insitesinc.com Tue Jan 25 00:09:42 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Mon, 24 Jan 2005 18:09:42 -0600 Subject: kernel-devel: should yum install, not update? In-Reply-To: <20050123111151.GB31380@neu.nirvana> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> <20050123003639.GA28104@redhat.com> <41F32901.7080003@insitesinc.com> <20050123111151.GB31380@neu.nirvana> Message-ID: <41F58E46.6030102@insitesinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Axel Thimm wrote: > On Sat, Jan 22, 2005 at 10:33:05PM -0600, Michael Favia wrote: > >>Dave Jones wrote: >> >>>On Sat, Jan 22, 2005 at 03:22:53PM -0500, Jeff Spaleta wrote: >>> >>> > Providing 'kernel-modules' on the other hand... i don't think anything >>> > requires 'kernel-modules' so it might be okay to make kernel-devel >>> > provide that but i still seems to me like potential double-meaning to >>> > what 'kernel-modules' means since kernel-devel doesnt actually include >>> > a single kernel-module. >>> > >>> > Maybe Dave Jones can be poked into making a comment about this. >>> >>>Adding either of the provides seems like a rather ugly hack. >>>up2date already has the smarts to installonly the -devel package, >>>so I'm of the opinion yum should be fixed to do the right thing too. >>>Jeremy is rebuilding yum as I type for tomorrows rawhide to >>>take care of this issue. >> >>Yes but the real question is "Where does this information belong?" I >>dont think that these things should be managed ad-hoc by each competing >>package manager but instead internalized into the packages themselves >>somehow for scalabiltiy and adaptability purposes. > > > It has often been suggested to add a new rpm tag for this > purpose. E.g. you could have > > UpdateMode: (installation|alwaysupgrade) > > or > > AutoUpgrade: no > > rpm 4.4 would be a good candidate to get this in. > this sounds like a much more reasonable solution (in any form it takes) than making each depsolver take on the task individually. - -- Michael Favia michael.favia at insitesinc.com Insites Incorporated http://michael.insitesinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFB9Y5GBVsNYjF2rDYRAuvIAJ0cweh02/fHfXyACT0yhI7oYCy33gCcDQQI a7XGiA6rxZSGTNwimyFhnWU= =ZhBT -----END PGP SIGNATURE----- From Axel.Thimm at ATrpms.net Tue Jan 25 00:10:30 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jan 2005 01:10:30 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <1106608786.15146.98.camel@bobcat.mine.nu> References: <20050124190613.GJ19903@neu.nirvana> <1106598133.15146.36.camel@bobcat.mine.nu> <20050124215558.GB31520@neu.nirvana> <1106606067.15146.87.camel@bobcat.mine.nu> <20050124224834.GJ31520@neu.nirvana> <1106608786.15146.98.camel@bobcat.mine.nu> Message-ID: <20050125001030.GA5190@neu.nirvana> On Tue, Jan 25, 2005 at 01:19:46AM +0200, Ville Skytt? wrote: > On Mon, 2005-01-24 at 23:48 +0100, Axel Thimm wrote: > > On Tue, Jan 25, 2005 at 12:34:27AM +0200, Ville Skytt? wrote: > > > My concern is that such a scheme _when applied as a standard procedure > > > for all library packages_ would probably lower the barrier for including > > > backwards compatibility cruft for which there will probably no > > > interested parties to clean it up nor maintain. > > > > There's no need to, these packages can be easily marked (see my other > > replies in this thread) and removed even in cron-jobs. > > My concern not about that, but about what's included in the distro, as > in DVD's, download.fedora.redhat.com etc. There isn't anything wrong in having these packages follow the soname-in-rpmname idiom. Even if there would be no further need for concurrent libs it would solve the leftover libs of previous Fedora Core/Red Hat Linux installations. I only see added value at no real cost: the required simple garbage collector pays off immediately for not having to obsolete old forward compatibility packages (like the gcc34 example, not a library, but the same packaging issues apply here). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From n3npq at nc.rr.com Tue Jan 25 00:19:11 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 19:19:11 -0500 Subject: kernel-devel: should yum install, not update? In-Reply-To: <20050123111151.GB31380@neu.nirvana> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> <20050123003639.GA28104@redhat.com> <41F32901.7080003@insitesinc.com> <20050123111151.GB31380@neu.nirvana> Message-ID: <41F5907F.8080304@nc.rr.com> Axel Thimm wrote: >On Sat, Jan 22, 2005 at 10:33:05PM -0600, Michael Favia wrote: > > >>Dave Jones wrote: >> >> >>>On Sat, Jan 22, 2005 at 03:22:53PM -0500, Jeff Spaleta wrote: >>> >>> > Providing 'kernel-modules' on the other hand... i don't think anything >>> > requires 'kernel-modules' so it might be okay to make kernel-devel >>> > provide that but i still seems to me like potential double-meaning to >>> > what 'kernel-modules' means since kernel-devel doesnt actually include >>> > a single kernel-module. >>> > >>> > Maybe Dave Jones can be poked into making a comment about this. >>> >>>Adding either of the provides seems like a rather ugly hack. >>>up2date already has the smarts to installonly the -devel package, >>>so I'm of the opinion yum should be fixed to do the right thing too. >>>Jeremy is rebuilding yum as I type for tomorrows rawhide to >>>take care of this issue. >>> >>> >>Yes but the real question is "Where does this information belong?" I >>dont think that these things should be managed ad-hoc by each competing >>package manager but instead internalized into the packages themselves >>somehow for scalabiltiy and adaptability purposes. >> >> > >It has often been suggested to add a new rpm tag for this >purpose. E.g. you could have > >UpdateMode: (installation|alwaysupgrade) > >or > >AutoUpgrade: no > >rpm 4.4 would be a good candidate to get this in. > > Not going to happen in rpm-4.4, or in *.rpm packaging. There is no way for the packager to determine how a package should be installed on client machines, and so the value needs to be dynamic, not static, configuration on the install, not the build, machine. FWIW, the reasoning is exactly the same for no Disttag:, as the package may be included in multiple distro's without rebuild, and so cannot be represented by static elements in metadata. 73 de Jeff From grmoc at yahoo.com Tue Jan 25 00:23:11 2005 From: grmoc at yahoo.com (Roberto Peon) Date: Mon, 24 Jan 2005 16:23:11 -0800 (PST) Subject: slow hard drives crushing interactivity In-Reply-To: <41F58876.6020507@insitesinc.com> Message-ID: <20050125002311.14936.qmail@web41509.mail.yahoo.com> With an old, non-dma (by default, at least) drive I have under heavy IO, the mouse moves in 1/4 screen increments, and so GUIs are not terribly useful (for me) in this situation. Personally, if I could have a hotkey that would attempt to restore activity, the behaviour of the hotkey would be to throttle down all currently running processes to half their current IO and/or CPU maximum allocations for the next X (some reasonably long user time, but not too long) seconds. Pressing the key again would again throttle processes down by half (down to some limit), and reset the timer. I.e. if a process was using 100% cpu, it would be limited to 50% for the next 10 seconds, and if it was reading/writing 10MB/s, it would be allowed to read/write at 5MB/s for the next 10 secodns. Of course, I'm not aware of a way to do this, but it seems like it would be a fun kernel hack. -Roberto JP --- Michael Favia wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Havoc Pennington wrote: > > Hi, > > > > On my IBM X31 laptop, the system entirely locks up when there's a lot of > > disk access, some common situations are: > > - when getting heavily into swap due to a runaway process > > - when running rpm/yum > > > > It's not *technically* locked up (i.e. if you wait long enough it will > > come back) but in practice you have to reboot if a process has a memory > > leak, and you can't do any work while running yum. > > It is amazing what we are completely content putting up with until > someone mentions they suffer from the same plight. I really like the > idea of being able to launch "System Monitor" aka gnome-system-monitor > (via hotkey) to graphically kill any runaway processes (or even just > advise me as to which one is the culprit so i can make an informed > decision). I don't know how to "force reserve" the resources to make it > functional in such a situation but it would save tons of unfinished work > (multitasking) that is being lost because of 1 wayward app. > > - -- > Michael Favia michael.favia at insitesinc.com > Insites Incorporated http://michael.insitesinc.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD8DBQFB9Yh2BVsNYjF2rDYRAvfTAJ4n697fFdmQHgaP4eiIuqL+3F6pnACggVFP > T2B1GE+ma+ZKtjKz89tPBcs= > =UDfk > -----END PGP SIGNATURE----- > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From Axel.Thimm at ATrpms.net Tue Jan 25 00:31:44 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jan 2005 01:31:44 +0100 Subject: kernel-devel: should yum install, not update? In-Reply-To: <41F5907F.8080304@nc.rr.com> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> <20050123003639.GA28104@redhat.com> <41F32901.7080003@insitesinc.com> <20050123111151.GB31380@neu.nirvana> <41F5907F.8080304@nc.rr.com> Message-ID: <20050125003144.GC5190@neu.nirvana> On Mon, Jan 24, 2005 at 07:19:11PM -0500, Jeff Johnson wrote: > Axel Thimm wrote: > > >On Sat, Jan 22, 2005 at 10:33:05PM -0600, Michael Favia wrote: > > > > > >>Dave Jones wrote: > >> > >> > >>>On Sat, Jan 22, 2005 at 03:22:53PM -0500, Jeff Spaleta wrote: > >>> > >>>> Providing 'kernel-modules' on the other hand... i don't think anything > >>>> requires 'kernel-modules' so it might be okay to make kernel-devel > >>>> provide that but i still seems to me like potential double-meaning to > >>>> what 'kernel-modules' means since kernel-devel doesnt actually include > >>>> a single kernel-module. > >>>> > >>>> Maybe Dave Jones can be poked into making a comment about this. > >>> > >>>Adding either of the provides seems like a rather ugly hack. > >>>up2date already has the smarts to installonly the -devel package, > >>>so I'm of the opinion yum should be fixed to do the right thing too. > >>>Jeremy is rebuilding yum as I type for tomorrows rawhide to > >>>take care of this issue. > >>> > >>> > >>Yes but the real question is "Where does this information belong?" I > >>dont think that these things should be managed ad-hoc by each competing > >>package manager but instead internalized into the packages themselves > >>somehow for scalabiltiy and adaptability purposes. > >> > >> > > > >It has often been suggested to add a new rpm tag for this > >purpose. E.g. you could have > > > >UpdateMode: (installation|alwaysupgrade) > > > >or > > > >AutoUpgrade: no > > > >rpm 4.4 would be a good candidate to get this in. > > > > > > Not going to happen in rpm-4.4, or in *.rpm packaging. > > There is no way for the packager to determine how a package should > be installed on client machines, Of course it is. It is the packager's decision whether he will craft a package that will allow concurrent non-conflicting installs of the same package in different versions. This is currently (only) true for the kernel packages, but could easily be extended to gcc and python packages. So if the packager has taken care to allow for concurrent installs he will tag his package appropriately. A higher level resolver has otherwise no chance on deriving this information and the current patching of resolvers to allow certain packages to be installed instead of upgraded will have an end. > and so the value needs to be dynamic, not static, configuration on > the install, not the build, machine. No, it's packaging time that counts. I hope you change your mind and allow for a new tag in rpm. Alternatively it can be modelled with fake Provides instead, but a method on rpm level would standardize this before every distro and its cat uses a different provides mechanics. > FWIW, the reasoning is exactly the same for no Disttag:, as the > package may be included in multiple distro's without rebuild, and so > cannot be represented by static elements in metadata. That's a bit unrelated to this issue. The disttag is to indicate the build environment and to make packages build out of the same specfile on different build environments to align properly in rpm upgrade paths (same specfile, different build environments: make build environments of newer distros win). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Tue Jan 25 00:33:15 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Jan 2005 19:33:15 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <20050124232113.GM31520@neu.nirvana> References: <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> Message-ID: <604aa79105012416337f3de0ce@mail.gmail.com> On Tue, 25 Jan 2005 00:21:13 +0100, Axel Thimm wrote: > Already posted in different siblings of this thread and implemented at > ATrpms. Auto-expiring packages that should be disposed of if there is > no dependency on them should simply provide a fake dependency to hook > a garbage collector to. no.. you missed my point... expiring because nothing depends on them is NOT what im talking about. I'm talking about expiring a package because the package author is no longer maintaining that version of the library regardless of whether an externally built application from somewhere else are still using that version of the library. If i haven't made my point clear enough, I apologize. Your leaf detection mechanism is not going to address this issue. -jef From n3npq at nc.rr.com Tue Jan 25 00:39:07 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 24 Jan 2005 19:39:07 -0500 Subject: kernel-devel: should yum install, not update? In-Reply-To: <20050125003144.GC5190@neu.nirvana> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> <20050123003639.GA28104@redhat.com> <41F32901.7080003@insitesinc.com> <20050123111151.GB31380@neu.nirvana> <41F5907F.8080304@nc.rr.com> <20050125003144.GC5190@neu.nirvana> Message-ID: <41F5952B.6030402@nc.rr.com> Axel Thimm wrote: >On Mon, Jan 24, 2005 at 07:19:11PM -0500, Jeff Johnson wrote: > > >>Axel Thimm wrote: >> >> >> >>>On Sat, Jan 22, 2005 at 10:33:05PM -0600, Michael Favia wrote: >>> >>> >>> >>> >>>>Dave Jones wrote: >>>> >>>> >>>> >>>> >>>>>On Sat, Jan 22, 2005 at 03:22:53PM -0500, Jeff Spaleta wrote: >>>>> >>>>> >>>>> >>>>>>Providing 'kernel-modules' on the other hand... i don't think anything >>>>>>requires 'kernel-modules' so it might be okay to make kernel-devel >>>>>>provide that but i still seems to me like potential double-meaning to >>>>>>what 'kernel-modules' means since kernel-devel doesnt actually include >>>>>>a single kernel-module. >>>>>> >>>>>>Maybe Dave Jones can be poked into making a comment about this. >>>>>> >>>>>> >>>>>Adding either of the provides seems like a rather ugly hack. >>>>>up2date already has the smarts to installonly the -devel package, >>>>>so I'm of the opinion yum should be fixed to do the right thing too. >>>>>Jeremy is rebuilding yum as I type for tomorrows rawhide to >>>>>take care of this issue. >>>>> >>>>> >>>>> >>>>> >>>>Yes but the real question is "Where does this information belong?" I >>>>dont think that these things should be managed ad-hoc by each competing >>>>package manager but instead internalized into the packages themselves >>>>somehow for scalabiltiy and adaptability purposes. >>>> >>>> >>>> >>>> >>>It has often been suggested to add a new rpm tag for this >>>purpose. E.g. you could have >>> >>>UpdateMode: (installation|alwaysupgrade) >>> >>>or >>> >>>AutoUpgrade: no >>> >>>rpm 4.4 would be a good candidate to get this in. >>> >>> >>> >>> >>Not going to happen in rpm-4.4, or in *.rpm packaging. >> >>There is no way for the packager to determine how a package should >>be installed on client machines, >> >> > >Of course it is. It is the packager's decision whether he will craft a >package that will allow concurrent non-conflicting installs of the >same package in different versions. This is currently (only) true for >the kernel packages, but could easily be extended to gcc and python >packages. > >So if the packager has taken care to allow for concurrent installs he >will tag his package appropriately. > >A higher level resolver has otherwise no chance on deriving this >information and the current patching of resolvers to allow certain >packages to be installed instead of upgraded will have an end. > > We disagree, as we do on Disttag:. I won't waste further time arguing the issue with you, you're mistaken. In fact, I will probably slam dunk a pre-emptive implementation for AutoUpgrade: no just as I have for Disttag: in rpm-4.4, because the implementation is easier than wasting my breath discussing. 73 de Jeff > > >>and so the value needs to be dynamic, not static, configuration on >>the install, not the build, machine. >> >> > >No, it's packaging time that counts. > >I hope you change your mind and allow for a new tag in >rpm. Alternatively it can be modelled with fake Provides instead, but >a method on rpm level would standardize this before every distro and >its cat uses a different provides mechanics. > > > >>FWIW, the reasoning is exactly the same for no Disttag:, as the >>package may be included in multiple distro's without rebuild, and so >>cannot be represented by static elements in metadata. >> >> > >That's a bit unrelated to this issue. The disttag is to indicate the >build environment and to make packages build out of the same specfile >on different build environments to align properly in rpm upgrade paths >(same specfile, different build environments: make build environments >of newer distros win). > > From seanlkml at sympatico.ca Tue Jan 25 00:54:30 2005 From: seanlkml at sympatico.ca (Sean) Date: Mon, 24 Jan 2005 19:54:30 -0500 (EST) Subject: RFC: Soname in rpm name In-Reply-To: <604aa79105012416337f3de0ce@mail.gmail.com> References: <41F4E45B.6050004@redhat.com><1106570484.32065.1.camel@ulysse.olympe.o2t><1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us><604aa791050124070243cfe95f@mail.gmail.com><20050124220847.GD31520@neu.nirvana><604aa791050124142972c325cc@mail.gmail.com><20050124224043.GI31520@neu.nirvana><604aa791050124145435e5a102@mail.gmail.com><20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> Message-ID: <35094.10.10.10.28.1106614470.squirrel@linux1> On Mon, January 24, 2005 7:33 pm, Jeff Spaleta said: > no.. you missed my point... expiring because nothing depends on them > is NOT what im talking about. I'm talking about expiring a package > because the package author is no longer maintaining that version of > the library regardless of whether an externally built application from > somewhere else are still using that version of the library. If i > haven't made my point clear enough, I apologize. Your leaf detection > mechanism is not going to address this issue. > Jeff, Why not propose a solution that does what you want instead of imposing this artificial barrier on others trying to solve different problems? Sean From Axel.Thimm at ATrpms.net Tue Jan 25 01:02:51 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jan 2005 02:02:51 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <604aa79105012416337f3de0ce@mail.gmail.com> References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> Message-ID: <20050125010251.GD5190@neu.nirvana> On Mon, Jan 24, 2005 at 07:33:15PM -0500, Jeff Spaleta wrote: > On Tue, 25 Jan 2005 00:21:13 +0100, Axel Thimm wrote: > > Already posted in different siblings of this thread and implemented at > > ATrpms. Auto-expiring packages that should be disposed of if there is > > no dependency on them should simply provide a fake dependency to hook > > a garbage collector to. > > no.. you missed my point... expiring because nothing depends on them > is NOT what im talking about. I'm talking about expiring a package > because the package author is no longer maintaining that version of > the library regardless of whether an externally built application from > somewhere else are still using that version of the library. If i > haven't made my point clear enough, I apologize. Your leaf detection > mechanism is not going to address this issue. OK, neither will the soname-in-the-rpmname address this in any way, positive or negative, and as said the issue you raise is far more involved and w/o any good solution. The leaf detection would circumstantially help here, but that wouldn't be the main focus. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at phy.duke.edu Tue Jan 25 01:27:00 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 24 Jan 2005 20:27:00 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <20050125010251.GD5190@neu.nirvana> References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> Message-ID: <1106616420.23277.1.camel@cutter> > OK, neither will the soname-in-the-rpmname address this in any way, > positive or negative, and as said the issue you raise is far more > involved and w/o any good solution. The leaf detection would > circumstantially help here, but that wouldn't be the main focus. okay I'm going to throw out some silly ideas for gathering info on the 'age' of a package. 1. panu's leaf code - I've used it - it does turn up things that nothing depends on and does it nicely. 2. look for shared objects in the filelists of the things turned up in 1 3. look for packages that have been untouched in > than N days/months/years 4. look for packages whose build date is many many months ago. None of these will get rid of every case - but it will help us identify odd situations and left-over cruft. thoughts? -sv From jspaleta at gmail.com Tue Jan 25 01:17:45 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Jan 2005 20:17:45 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <35094.10.10.10.28.1106614470.squirrel@linux1> References: <41F4E45B.6050004@redhat.com> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <35094.10.10.10.28.1106614470.squirrel@linux1> Message-ID: <604aa79105012417174cc7db6e@mail.gmail.com> On Mon, 24 Jan 2005 19:54:30 -0500 (EST), Sean wrote: > Why not propose a solution that does what you want instead of imposing > this artificial barrier on others trying to solve different problems? I'm explaining a situation that the current naming method handles better than the proposed per soname does. I'm not arguing for any policy change at all, you are. if you want to argue for a policy change I would hope that you are open minded enough to keep other issues other than your primary concern in mind. The soname in package policy you would like to see for all packages... will negatively impact the aspect of packaging I bring up compared to the current method of doing the per sonaming on an as needed basis. Packaging policy is a complex issue, and while you would like to focus on one aspect and build a policy that makes that one aspect easier to deal with... it has consequences for other aspects of packaging. I'd love a perfect solution that everyone will like that solves all problems, but in the meantime I'm not horribly upset with the 'as needed' policy as a compromise no one likes and solves no problems well. How about we backup... and we imagine reasons why historically the per soname scheme hasn't been used by and large by Red Hat... perhaps if we did that there will be other aspects of packaging besides the one I bring up that constrain your soname solution. -jef"but its much more fun to think Red Hat packagers are just stupid or malicious and have chosen a package naming scheme delibrately to irk other people"spaleta From jspaleta at gmail.com Tue Jan 25 01:27:59 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 24 Jan 2005 20:27:59 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <20050125010251.GD5190@neu.nirvana> References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> Message-ID: <604aa7910501241727343f88ae@mail.gmail.com> On Tue, 25 Jan 2005 02:02:51 +0100, Axel Thimm wrote: > OK, neither will the soname-in-the-rpmname address this in any way, > positive or negative, and as said the issue you raise is far more > involved and w/o any good solution. The leaf detection would > circumstantially help here, but that wouldn't be the main focus. On the other hand keeping packages the same name when an older soname expires handles the case i bring up exceedingly well. package libfoo in fc3 provides libfoo.so.1 package libfoo in fc4 provides libfoo.so.2. Upgrades from fc3 to fc4 and libfoo.so.1 is no longer on the system. Works like a charm at keeping unmaintained library versions off the system. It works so well in fact.. that it almost seems like it was a design goal for naming library packages without sonames. And thats the point I'm trying to make. Moving to a per soname when its absolutely not needed has consquences for other aspects of packaging. As soon as the proponents for a soname-in-the-rpmname have a workable proposed solution to the problem I bring up, I'll gladly stop bringing it up. -jef From dag at wieers.com Tue Jan 25 02:16:55 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 25 Jan 2005 03:16:55 +0100 (CET) Subject: RFC: Soname in rpm name In-Reply-To: <20050124151136.31801589@nausicaa.camperquake.de> References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> Message-ID: On Mon, 24 Jan 2005, Ralf Ertzinger wrote: > Aurelien Bompard wrote: > > > I did not know, is it possible to have a tool find the rpms that no rpms > > depend on, and ask to remove them ? > > The problem with this is that RPM does not indicate whether a package has > "end user value" (a command line or GUI program, or a daemon), or is just > a support library needed by said end user programs, which can be removed > if not needed by anyone. That's why a long time ago I proposed to have a policy that forces to use lib%name in case where it was a shared library used by more than 1 application. If these lib%name packages where designed so they would not conflict, smart package managers could handle them identically as kernel packages. Or at least that was the idea back then. Something like this will only work if Red Hat internally sticks to a deterministic naming policy that is coherent. Until today it failed to do that :) Mandrake and Debian are much better in this regard. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From Axel.Thimm at ATrpms.net Tue Jan 25 02:23:31 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jan 2005 03:23:31 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <604aa7910501241727343f88ae@mail.gmail.com> References: <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <604aa7910501241727343f88ae@mail.gmail.com> Message-ID: <20050125022331.GE5190@neu.nirvana> On Mon, Jan 24, 2005 at 08:27:59PM -0500, Jeff Spaleta wrote: > On Tue, 25 Jan 2005 02:02:51 +0100, Axel Thimm wrote: > > OK, neither will the soname-in-the-rpmname address this in any way, > > positive or negative, and as said the issue you raise is far more > > involved and w/o any good solution. The leaf detection would > > circumstantially help here, but that wouldn't be the main focus. > > On the other hand keeping packages the same name when an older > soname expires handles the case i bring up exceedingly well. package > libfoo in fc3 provides libfoo.so.1 package libfoo in fc4 provides > libfoo.so.2. Upgrades from fc3 to fc4 and libfoo.so.1 is no longer on > the system. Works like a charm at keeping unmaintained library > versions off the system. It works so well in fact.. that it almost > seems like it was a design goal for naming library packages without > sonames. That's been taken care of the garbage collection mentioned here. What is not taken care of and is a real problem you touched is if a package becomes deprecated with no upgrade path and rotts in your N times upgraded system. But that off-topic in this context. The soname-in-rpmname neither helps nor hurts. > And thats the point I'm trying to make. Moving to a per soname when > its absolutely not needed Not needed? Let's not reiterate the whole discussion. There is added value in having the libraries coinstallable like they are meant to be. If you need arguments for it just insert arguments for having library verioning at all at this spot. > has consquences for other aspects of packaging. As soon as the > proponents for a soname-in-the-rpmname have a workable proposed > solution to the problem I bring up, I'll gladly stop bringing it up. Well, you raised a topic that is not really related to the soname-in-rpmname. And whatever is indeed tangentially related the Provides: hook and garbage collection method has its ways of dealing with it better than the current compat-whatever packaging. So at the end of the day you have a win-win situation. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dag at wieers.com Tue Jan 25 02:25:18 2005 From: dag at wieers.com (Dag Wieers) Date: Tue, 25 Jan 2005 03:25:18 +0100 (CET) Subject: RFC: Soname in rpm name In-Reply-To: <604aa791050124070243cfe95f@mail.gmail.com> References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> Message-ID: On Mon, 24 Jan 2005, Jeff Spaleta wrote: > On Mon, 24 Jan 2005 09:15:14 -0500, Sean Middleditch > wrote: > > We _have_ had this problem, btw. The problem is that it's not generally > > developers that notice it. It's the user that just want to have their > > machine work. I go to install third party app Foo from Foo's web site, > > it needs libbar.so.2, Fedora only has libbar.so.1, and many other apps > > on the net require libbar.so.1. > > A third part website is packaging libbar.so.2 in a package of the > same package name as Feodora's libbar.so.1? Why would a third party > site do that? Unless the intention was to replace the Fedora package? > Isn't this an example of the care 3rd party packagers should be taking > to make sure their packages work well with Core? Jeff, this implementation forces both 3rd party packagers as well as Red Hat and Fedora Extras to be more strict than it could be. It is technical possible to lift these limitations and that's what I think Sean is talking about. Why a 3rd party packager is updating a core package may be for various reasons, some more valid as others. Not all 3rd party packagers replace core (library) packages because we know it potentially introduces problems. But technically speaking there is no real reason to have this limitation. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From aoliva at redhat.com Tue Jan 25 04:24:06 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 25 Jan 2005 02:24:06 -0200 Subject: RFC: Soname in rpm name In-Reply-To: <20050124185747.GI19903@neu.nirvana> References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> <20050124185747.GI19903@neu.nirvana> Message-ID: On Jan 24, 2005, Axel Thimm wrote: > On Mon, Jan 24, 2005 at 03:05:29PM -0200, Alexandre Oliva wrote: >> On Jan 24, 2005, Ralf Ertzinger wrote: >> > The problem with this is that RPM does not indicate whether a package has >> > "end user value" (a command line or GUI program, or a daemon), or is just >> > a support library needed by said end user programs, which can be removed >> > if not needed by anyone. >> >> Could we perhaps add such a flag to the rpm database? Then the >> installer and the various other package installation front-ends could >> mark user- (or comps-)requested packages as having end user value, and >> everything else brought in to satisfy dependencies such that it is (or >> can be) removed as soon as no dependencies remain. > ATrpms has started marking library only packages with > Provides: shared-library-package > so these packages can be identifies with > rpm --whatprovides shared-library-package > and be probed for garbage collection. The weak point of your argument is that it assumes that the only kind of package that doesn't provide "end user value" is the kind that provides shared-library-package. This is just not true, although I must admit it's the most common case. Having package installers pin user-selected packages, or unpin packages brought in only to satisfy dependencies, would enable all cases to work, not only the shared library case, even without a special provides or the too-inclusive mechanism proposed by jeff. > I.e. there is no need to extend rpm, you have everything already in > place. Not quite. Consider that I might actually want to keep a shared lib around (say libdvdcss, only used as a plugin by libdvdread). With your scheme, there's no way to tell it from any other shared lib-providing package, so it could be garbage collected along with other libs. Sure enough, I could install my own meta-package with an explicit requires to keep the lib-providing package installed, but why should I have to go through these hoops if rpm might instead offer a `user-requested' bit to keep a package installed even if nothing else requires it? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From mpeters at mac.com Tue Jan 25 04:27:52 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 25 Jan 2005 04:27:52 +0000 Subject: RFC: Soname in rpm name In-Reply-To: <1106563530.26412.15.camel@localhost.localdomain> (from peter.backlund@home.se on Mon Jan 24 02:45:30 2005) References: <1106563530.26412.15.camel@localhost.localdomain> Message-ID: <1106627272l.7641l.4l@devel.mpeters.us> > > Unrelated, but I have to ask: what is the purpose of defining > name/version/release like this: > > %define name gtkmm > %define version 1.2.4 > %define release 1mdk I do this - at very top of spec file: %define my_build yjl.1 Then in the normal place Name: foobar Version: 20.12 Release: 3.%{my_build} -=- That makes more sense to me than defining name and then using Name: with the defined %{name} macro. But that's just me. In the future I may define what release/distro it is being built for - but I don't think so, my packages are intended to be installed via yum which should take care of that - by grabbing them from the right directory. From aoliva at redhat.com Tue Jan 25 04:36:42 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 25 Jan 2005 02:36:42 -0200 Subject: kernel-devel: should yum install, not update? In-Reply-To: <20050125003144.GC5190@neu.nirvana> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> <20050123003639.GA28104@redhat.com> <41F32901.7080003@insitesinc.com> <20050123111151.GB31380@neu.nirvana> <41F5907F.8080304@nc.rr.com> <20050125003144.GC5190@neu.nirvana> Message-ID: On Jan 24, 2005, Axel Thimm wrote: > It is the packager's decision whether he will craft a package that > will allow concurrent non-conflicting installs of the same package > in different versions. This is currently (only) true for the kernel > packages, but could easily be extended to gcc and python packages. > So if the packager has taken care to allow for concurrent installs he > will tag his package appropriately. > A higher level resolver has otherwise no chance on deriving this > information and the current patching of resolvers to allow certain > packages to be installed instead of upgraded will have an end. And why couldn't the depsolver itself verify that conflicts do not exist between the installed version and the to-be-installed one? I think it's my turn to show that we don't need additional annotations :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Tue Jan 25 04:26:38 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 25 Jan 2005 02:26:38 -0200 Subject: suggests/requires in rpm In-Reply-To: <34047.10.10.10.28.1106600075.squirrel@linux1> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <604aa79105012220422a3f4b48@mail.gmail.com> <41F41E70.6080102@nc.rr.com> <1106572460.3877.8.camel@localhost.localdomain> <1106577137.3597.36.camel@cutter> <41F508D3.7060409@nc.rr.com> <34047.10.10.10.28.1106600075.squirrel@linux1> Message-ID: On Jan 24, 2005, "Sean" wrote: > If so, is this annotation really required? I think the following rules > accomplish the same thing: > If the currently installed version has the same missingok annotation as is > given in the new rpm, then install each dependency only if an early > version is currently installed (handle each such dependecy like rpm -F). > Otherwise, install each dependant rpm as if it were required, (ie. handle > like rpm -U, it must represent new functionality, or been recently made > optional). Cool, I hadn't considered this possibility. Way to go. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From katzj at redhat.com Tue Jan 25 05:03:16 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 25 Jan 2005 00:03:16 -0500 Subject: Fedora and Xen: A Quick Start Guide Message-ID: <1106629396.28420.92.camel@bree.local.net> As some people have noticed, Xen is now available from the Fedora development repository. More information on Xen itself can be found at http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html. We're following the -unstable Xen tree at the moment which does occasionally lead to things being broken but also lets us track a lot of the more interesting work going on there. Since setting up to run Xen isn't entirely straight-forward, here's a run-through of what should work for setting up a single Xen guest running the Fedora development tree. To run xen on a system pulling strictly from the Fedora devel repository, all of your deps should get satisfied automatically. But, they are explicitly * mkinitrd 4.2.0 * python 2.4 * python-twisted * Using grub as your boot loader [1] * Probably something on the order of 256 MB of RAM with the default setup [2] Then, you should be able to install the xen and kernel-xen0 packages. Once this is done, you should have an entry set up in your grub.conf to boot the xen0 kernel. Now, reboot into your new xen0 kernel [3] Once you've rebooted, you should be running in the dom0 kernel. You'll see a slightly scary looking warning about TLS during bootup and how to disable it, but it shouldn't make things too bad. Then, if you start xend with 'service xend start', you should be able to run 'xm list' and see your domain running. Now, we want to set up a simple base Fedora system. First, you'll want to install the kernel-xenU package (unfortunately, the kernel for your guest domain must currently be kept outside of the guest itself). Next, let's create a file to use as the backing for our Fedora install. For example purposes, I'll create one of a size of 1 GB. dd if=/dev/zero of=/root/fedora.img bs=1M count=1024 Now, create an ext3 filesystem on this image. mke2fs -F -j /root/fedora.img You should now be able to mount your new temporary rootfs on a temporary mountpoint, say /mnt mount -o loop /root/fedora.img /mnt Now, we can install whatever basesystem we want into this chroot. Make sure that your yum configuration points to a valid repository. Then, decide what group(s) you want to install. I'd recommend starting with Base (or for the space constrained, Core, but this is more difficult). Then, run yum --installroot=/mnt -y groupinstall Base Now, go get some coffee and have a snack. It's going to take a little while :-) Come back and if everything went okay, you'll have a minimal install in /mnt. Now, for the ugly part, we need to set up some basic bits on the filesystem that have to be different for xen right now. These include a) creating some required device nodes in /dev since we're not using an initrd and b) setting up an /etc/fstab for i in console null zero ; do MAKEDEV -d /mnt -x $i ; done For the /etc/fstab, something simple like the following should work /dev/sda1 / ext3 defaults 1 1 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 Do any other configuration you want to on the filesystem and then unmount it [4] umount /mnt{/proc,} Now, we just have to create a config file and you should be good to go. I go for a very simple config file like the following which is /etc/xen/rawhide on my machine [5] kernel ="/boot/vmlinuz-2.6.10-1.1103_FC4xenU" memory = 64 name = "rawhide" nics = 1 disk = ['file:/root/fedora.img,sda1,w'] root = "/dev/sda1 ro" Now, create a new domain with 'xm create -c rawhide' and off it goes. At the end, you should see the login prompt at which point you can login as root and begin playing around some. This is pretty early and rough, but it's enough to starting playing with. The next step (for me :) is getting to where you can do actual installs in a Xen guest environment and then being able to boot kernels which are on the guest's filesystem. Jeremy [1] This is required because you actually boot the Xen hypervisor and it then starts the Linux kernel. It does this using the MultiBoot standard [2] You can conceivably get by with less, but you'll have to reduce the dom0_memory line in /boot/grub/grub.conf. The 130000 for dom0 is currently hard-coded by mkinitrd (will get fixed before too long) and can go a little lower. Also, the Xen hypervisor ends up requiring ~ 32 MB. Plus any memory for your unprivileged guests. [3] Note, you may need to disable rhgb and switch to using runlevel 3. There are conflicting reports about X working; I haven't tried [4] And /proc under it, since /proc has to get mounted for a lot of things to get done right. But yum figures that out [5] Substitute /boot/vmlinuz-2.6.10-1.1090_FC4xenU with the xenU kernel you installed. Additionally, the device sda1 listed here as the disk is related to the /etc/fstab you created above From notting at redhat.com Tue Jan 25 05:04:25 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 25 Jan 2005 00:04:25 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <1106607715.6122.21.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> Message-ID: <20050125050425.GK4047@nostromo.devel.redhat.com> Havoc Pennington (hp at redhat.com) said: > Maybe a cap on process size, so there can be 1G virtual memory but an > individual app can only use 512M? Maybe when a process reaches 512M we > could suspend it and ask the user whether to > let it grow further? You can set rlimits; you can also turn off overcommit. Doesn't help the yum/rpm case, of course. Bill From notting at redhat.com Tue Jan 25 05:15:09 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 25 Jan 2005 00:15:09 -0500 Subject: further package removals/potential package removals In-Reply-To: <1106425288.31857.26.camel@stargrazer.home.awesomeplay.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <20050122201706.GA3494@chrys.ms.mff.cuni.cz> <1106425288.31857.26.camel@stargrazer.home.awesomeplay.com> Message-ID: <20050125051509.GM4047@nostromo.devel.redhat.com> Sean Middleditch (elanthis at awesomeplay.com) said: > And the package set included in Core has roughly nothing to do with the > pre-built OS image used by the rescue system. For a rescue CD the > preferred browser would definitely be a text-based one and not > Firefox. ;-) Actually, it does, since it's *built* from the Core tree at treee build time. Bill From n3npq at nc.rr.com Tue Jan 25 06:03:25 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 25 Jan 2005 01:03:25 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <20050125050425.GK4047@nostromo.devel.redhat.com> References: <1106607715.6122.21.camel@localhost.localdomain> <20050125050425.GK4047@nostromo.devel.redhat.com> Message-ID: <41F5E12D.7050807@nc.rr.com> Bill Nottingham wrote: >Havoc Pennington (hp at redhat.com) said: > > >>Maybe a cap on process size, so there can be 1G virtual memory but an >>individual app can only use 512M? Maybe when a process reaches 512M we >>could suspend it and ask the user whether to >>let it grow further? >> >> > >You can set rlimits; you can also turn off overcommit. Doesn't help >the yum/rpm case, of course. > > Well threre's really only a single read(2) and write(2) for all I/O in rpm, I could perhaps add a configgerable and context sensitive nanosleep if I/O is the bottleneck ;-) 73 de Jeff From n3npq at nc.rr.com Tue Jan 25 06:15:50 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 25 Jan 2005 01:15:50 -0500 Subject: kernel-devel: should yum install, not update? In-Reply-To: References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> <20050123003639.GA28104@redhat.com> <41F32901.7080003@insitesinc.com> <20050123111151.GB31380@neu.nirvana> <41F5907F.8080304@nc.rr.com> <20050125003144.GC5190@neu.nirvana> Message-ID: <41F5E416.2000603@nc.rr.com> Alexandre Oliva wrote: >On Jan 24, 2005, Axel Thimm wrote: > > > >>It is the packager's decision whether he will craft a package that >>will allow concurrent non-conflicting installs of the same package >>in different versions. This is currently (only) true for the kernel >>packages, but could easily be extended to gcc and python packages. >> >> > > > >>So if the packager has taken care to allow for concurrent installs he >>will tag his package appropriately. >> >> > > > >>A higher level resolver has otherwise no chance on deriving this >>information and the current patching of resolvers to allow certain >>packages to be installed instead of upgraded will have an end. >> >> > >And why couldn't the depsolver itself verify that conflicts do not >exist between the installed version and the to-be-installed one? I >think it's my turn to show that we don't need additional annotations >:-) > Additional annotations for what? What problem are you trying to solve? Depsolvers can of course do whatever they wish with the information and mechanisms provided by rpmlib. Not that very much is being attempted these days, debugging 1000+ package transactions ain't exactly fun. And there is a desperate need for better install/upgrade package policy choices. What's currently passing for state-of-the-art is little more than arch scoring with a dash of multilib tabasco, if you catch my drift. FWIW, "missingok" generalizes to all dependencies, not just Requires:, and in an equivalently semantic free (from rpmlib POV) fashion. So "optional" annotation mark-up development is quite possible. Just not Disttag: or Autoupdate: no, please. And no matter what, the lack of dependeable analysis tools is the impediment to better depsolver implemnentations. Dry labbing dependency graph analysis is way way easier than debugging 1000+ package transactions in situ. 73 de Jeff From n3npq at nc.rr.com Tue Jan 25 06:23:32 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 25 Jan 2005 01:23:32 -0500 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> <20050124185747.GI19903@neu.nirvana> Message-ID: <41F5E5E4.6010408@nc.rr.com> Alexandre Oliva wrote: >On Jan 24, 2005, Axel Thimm wrote: > > > >>On Mon, Jan 24, 2005 at 03:05:29PM -0200, Alexandre Oliva wrote: >> >> >>>On Jan 24, 2005, Ralf Ertzinger wrote: >>> >>> > > > >>>>The problem with this is that RPM does not indicate whether a package has >>>>"end user value" (a command line or GUI program, or a daemon), or is just >>>>a support library needed by said end user programs, which can be removed >>>>if not needed by anyone. >>>> >>>> >>>Could we perhaps add such a flag to the rpm database? Then the >>>installer and the various other package installation front-ends could >>>mark user- (or comps-)requested packages as having end user value, and >>>everything else brought in to satisfy dependencies such that it is (or >>>can be) removed as soon as no dependencies remain. >>> >>> > > > >>ATrpms has started marking library only packages with >> >> > > > >> Provides: shared-library-package >> >> > > > >>so these packages can be identifies with >> >> > > > >> rpm --whatprovides shared-library-package >> >> > > > >>and be probed for garbage collection. >> >> > >The weak point of your argument is that it assumes that the only kind >of package that doesn't provide "end user value" is the kind that >provides shared-library-package. This is just not true, although I >must admit it's the most common case. > >Having package installers pin user-selected packages, or unpin >packages brought in only to satisfy dependencies, would enable all >cases to work, not only the shared library case, even without a >special provides or the too-inclusive mechanism proposed by jeff. > > The concept of "pinning" can will stop a depsolver from unattended, batch mode, upgrades. But up2date certainly has (at least) the two essential "pinning" concepts: a) Never change this package. b) Never change this file. and yum has (at least) a). > > >>I.e. there is no need to extend rpm, you have everything already in >>place. >> >> > >Not quite. Consider that I might actually want to keep a shared lib >around (say libdvdcss, only used as a plugin by libdvdread). With >your scheme, there's no way to tell it from any other shared >lib-providing package, so it could be garbage collected along with >other libs. Sure enough, I could install my own meta-package with an >explicit requires to keep the lib-providing package installed, but why >should I have to go through these hoops if rpm might instead offer a >`user-requested' bit to keep a package installed even if nothing else >requires it? > > The real problem with "pinning" is one of mechanism vs. policy. The pain that you -- an active nerd ;-) -- might be willing to accomodate and tolerate is very different from what most users are willing to tolerate. An QA on upgrades in the face of "pinning" is way way more complex. Erasing unused packages has never been seriously attempted, mostly because the primary goal of installers and depsolvers is Upgrade! not otherwise. 73 de Jeff From tmraz at redhat.com Tue Jan 25 07:36:47 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 25 Jan 2005 08:36:47 +0100 Subject: further package removals/potential package removals In-Reply-To: <1106589420.13493.67.camel@localhost.localdomain> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106422766.16789.55.camel@localhost.localdomain> <604aa79105012212112b0b3bee@mail.gmail.com> <41F2B7E9.9060305@gmail.com> <604aa79105012215234bf32d3f@mail.gmail.com> <20050122233856.GA16555@devserv.devel.redhat.com> <604aa79105012215547cd6144a@mail.gmail.com> <41F2EF12.E8EF945@jwz.org> <41F30E60.5050605@nc.rr.com> <41F313F7.7679D847@jwz.org> <41F319D2.6080303@nc.rr.com> <87651odavq.fsf@londo.ultra.csn.tu-chemnitz.de> <1106563944.5621.32.camel@perun.redhat.usu> <1106589420.13493.67.camel@localhost.localdomain> Message-ID: <1106638607.5621.10.camel@perun.redhat.usu> On Mon, 2005-01-24 at 12:57 -0500, Havoc Pennington wrote: > On Mon, 2005-01-24 at 11:52 +0100, Tomas Mraz wrote: > > > > The problem is pam_console (and maybe others) modules (which are by > > default configured to be used) require glib2. And I don't see any > > possibility to make the pam_console optional. So you can tune your > > minimum install so the pam_console is removed from all /etc/pam.d/... > > configs and then you can remove glib2. Or you can write a patch for all > > pam modules in redhat which use glib2 which replace the functionality > > provided by glib2 by another means and if it's good it will be applied. > > But I won't write it as I have many more useful things to do. > > So does everyone else - that's why they use a working, tested, widely- > available > utility library instead of writing their own string and hash table > classes > in every single package. Of course I agree with you that it's generaly a good idea to use glib2 instead of writing own string and hash table classes, but as glib2 isn't much used in PAM, it could be replaced. I didn't say that I would like to replace it just if someone wrote a patch which replaces it I would look at it and maybe applied it. -- Tomas Mraz From peter.backlund at home.se Tue Jan 25 07:48:56 2005 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 25 Jan 2005 08:48:56 +0100 Subject: HAL ejects Message-ID: <1106639336.29380.9.camel@localhost.localdomain> Here's something I'd like to see in FC4: unmount-on-eject via HAL. I'm talking about automatic unmounting CD/DVD when you press the eject button, like the ancient "supermount". Is this within the scope of HAL? /Peter From pmatilai at welho.com Tue Jan 25 07:51:24 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 25 Jan 2005 09:51:24 +0200 (EET) Subject: kernel-devel: should yum install, not update? In-Reply-To: <41F5907F.8080304@nc.rr.com> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> <20050123003639.GA28104@redhat.com> <41F32901.7080003@insitesinc.com> <20050123111151.GB31380@neu.nirvana> <41F5907F.8080304@nc.rr.com> Message-ID: On Mon, 24 Jan 2005, Jeff Johnson wrote: > Axel Thimm wrote: >> It has often been suggested to add a new rpm tag for this >> purpose. E.g. you could have >> >> UpdateMode: (installation|alwaysupgrade) >> >> or >> >> AutoUpgrade: no >> >> rpm 4.4 would be a good candidate to get this in. >> > > Not going to happen in rpm-4.4, or in *.rpm packaging. > > There is no way for the packager to determine how a package should be > installed on client machines, and so the value needs to be dynamic, not > static, configuration on the install, not the build, machine. How about putting this info into rpm *configuration*, instead of each and every depsolver's config? The downside of that is of course that customizing your favorite depsolver now consists of tweaking more than just depsolver configuration, but at least a) rpm could ship with reasonable defaults for the distro b) we'd have one definite place where this is set The depsolvers would only need to switch from their internal mechanisms to looking up the configuration from rpm which should be easy enough, rpm itself would need some further modification if it's to honor the config. Me, I don't personally much care where that info comes from... - Panu - From skvidal at phy.duke.edu Tue Jan 25 08:01:18 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 25 Jan 2005 03:01:18 -0500 Subject: suggests/requires in rpm In-Reply-To: <41F58D56.5050000@insitesinc.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106577137.3597.36.camel@cutter> <200501242308.07535.symbiont@berlios.de> <1106593537.25770.30.camel@opus.phy.duke.edu> <41F58D56.5050000@insitesinc.com> Message-ID: <1106640078.23277.51.camel@cutter> > For once i agree with every statement in a set of replies :). I do think > that it should be handled by the depsolvers and i to that end i raised a > discussion regarding implementing a feature like this some time ago > (nice and vague:) ). Perhaps we could find some sort of way to integrate > this type of information into the current work we are doing on cleaning > up the yum output? > > Describing the extra packages as optional and providing additional > functionality with perhaps a little blurb that describes what it adds > would be a modest first step. Providing the ability to include/deny such > optional packages by default and without approval would be another. I > could see this framed in our current revision of possible yum outputs > for user confirmation of the transaction. > You've got to keep user output debug level in mind - not in every case will the user see or want to see that much information - moreover we need to make sure we don't scare the user too much. -sv From sitsofe at yahoo.com Tue Jan 25 08:13:09 2005 From: sitsofe at yahoo.com (Sitsofe Wheeler) Date: Tue, 25 Jan 2005 08:13:09 +0000 Subject: slow hard drives crushing interactivity In-Reply-To: <1106607715.6122.21.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> Message-ID: <1106640790.4341.3.camel@galvatron.localdomain> On Mon, 2005-01-24 at 18:01 -0500, Havoc Pennington wrote: > Hi, > > On my IBM X31 laptop, the system entirely locks up when there's a lot of > disk access, some common situations are: > - when getting heavily into swap due to a runaway process > - when running rpm/yum > > It's not *technically* locked up (i.e. if you wait long enough it will > come back) but in practice you have to reboot if a process has a memory > leak, and you can't do any work while running yum. This is actually an already reported bug (although the reported one was concerned with what openoffice would do to a system when it forced swap): https://bugzilla.redhat.com/beta/show_bug.cgi?id=142809 From gauret at free.fr Tue Jan 25 09:00:20 2005 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 25 Jan 2005 10:00:20 +0100 Subject: RFC: Soname in rpm name References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> Message-ID: seth vidal wrote: > okay I'm going to throw out some silly ideas for gathering info on the > 'age' of a package. > > 1. panu's leaf code - I've used it - it does turn up things that nothing > depends on and does it nicely. > 2. look for shared objects in the filelists of the things turned up in 1 > 3. look for packages that have been untouched in > than N > days/months/years > 4. look for packages whose build date is many many months ago. > > None of these will get rid of every case - but it will help us identify > odd situations and left-over cruft. > > thoughts? Sounds interesting. On the other hand, maybe we could do it manually (from a packager's point of view) : if you package library foo, and you know that version 0.1 is not supported anymore (noone knows that better than you since you maintain it), you can add an Obsoletes tag to your libfoo5 package, and force the removal. Would that solve Jeff's issue ? Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info Programmer: A biological system designed to convert coffee and pizza into code. From i_p_a_u_l at yahoo.com Tue Jan 25 09:01:40 2005 From: i_p_a_u_l at yahoo.com (Paul Ionescu) Date: Tue, 25 Jan 2005 11:01:40 +0200 Subject: HAL ejects References: <1106639336.29380.9.camel@localhost.localdomain> Message-ID: Hi, On Tue, 25 Jan 2005 08:48:56 +0100, Peter Backlund wrote: > Here's something I'd like to see in FC4: unmount-on-eject via HAL. I'm > talking about automatic unmounting CD/DVD when you press the eject button, > like the ancient "supermount". Is this within the scope of HAL? > > /Peter It is already in FC3 I am using it right now. I think it is not in HAL, but in GVM. However, to be able to use it, you have to disable "lock on mount" option of cdrom by "echo 0 > /proc/sys/dev/cdrom/lock" or putting "dev.cdrom.lock = 0" in /etc/sysctl.conf and reloading with sysctl -p. From aoliva at redhat.com Tue Jan 25 09:14:11 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 25 Jan 2005 07:14:11 -0200 Subject: kernel-devel: should yum install, not update? In-Reply-To: <41F5E416.2000603@nc.rr.com> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> <20050123003639.GA28104@redhat.com> <41F32901.7080003@insitesinc.com> <20050123111151.GB31380@neu.nirvana> <41F5907F.8080304@nc.rr.com> <20050125003144.GC5190@neu.nirvana> <41F5E416.2000603@nc.rr.com> Message-ID: On Jan 25, 2005, Jeff Johnson wrote: > Alexandre Oliva wrote: >> On Jan 24, 2005, Axel Thimm wrote: >>> It is the packager's decision whether he will craft a package that >>> will allow concurrent non-conflicting installs of the same package >>> in different versions. This is currently (only) true for the kernel >>> packages, but could easily be extended to gcc and python packages. >> And why couldn't the depsolver itself verify that conflicts do not >> exist between the installed version and the to-be-installed one? I >> think it's my turn to show that we don't need additional annotations >> :-) > Additional annotations for what? What problem are you trying to solve? To indicate whether multiple versions of the same package can coexist peacefully. > FWIW, "missingok" generalizes to all dependencies, not just Requires:, > and in an equivalently semantic free (from rpmlib POV) fashion. That's a different thread (or maybe a different portion of the same thread :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From aoliva at redhat.com Tue Jan 25 09:19:00 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 25 Jan 2005 07:19:00 -0200 Subject: RFC: Soname in rpm name In-Reply-To: <41F5E5E4.6010408@nc.rr.com> References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> <20050124185747.GI19903@neu.nirvana> <41F5E5E4.6010408@nc.rr.com> Message-ID: On Jan 25, 2005, Jeff Johnson wrote: > Alexandre Oliva wrote: >> Having package installers pin user-selected packages, or unpin >> packages brought in only to satisfy dependencies, would enable all >> cases to work, not only the shared library case, even without a >> special provides or the too-inclusive mechanism proposed by jeff. > The concept of "pinning" can will stop a depsolver from unattended, > batch mode, > upgrades. Not the same pinning. I'm talking about adding a bit that would tell whether a particular package was requested by the user or brought in just to satisfy a dependency of another package. Packages of the latter group that no longer have any dependency in the database may be garbage collected. Packages of the former group shouldn't. > The pain that you -- an active nerd ;-) -- might be willing to > accomodate and tolerate is very different from what most users > are willing to tolerate. An QA on upgrades in the face of "pinning" is > way way more complex. We're talking about different sorts of pinning. Please re-read my suggestion with the paragraph I wrote above in mind, and hopefully it will make sense, and not seem too complicated of a concept. > Erasing unused packages has never been seriously attempted, mostly > because the primary goal of installers and depsolvers is > Upgrade! > not otherwise. Yeah, but this discussion got into the topic of removing unused packages. A number of different heuristics were suggested, but all of them were not more than heuristics. What I suggest (marking packages in the database as having been brought in only to satisfy dependencies) would enable such packages to be easily located and removed when other packages that caused them to be brought in are removed. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From peter.backlund at home.se Tue Jan 25 09:37:14 2005 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 25 Jan 2005 10:37:14 +0100 Subject: HAL ejects In-Reply-To: References: <1106639336.29380.9.camel@localhost.localdomain> Message-ID: <1106645834.19325.2.camel@localhost.localdomain> tis 2005-01-25 klockan 11:01 +0200 skrev Paul Ionescu: > Hi, > > On Tue, 25 Jan 2005 08:48:56 +0100, Peter Backlund wrote: > > Here's something I'd like to see in FC4: unmount-on-eject via HAL. I'm > > talking about automatic unmounting CD/DVD when you press the eject button, > > like the ancient "supermount". Is this within the scope of HAL? > > > > /Peter > > It is already in FC3 > I am using it right now. > I think it is not in HAL, but in GVM. > However, to be able to use it, you have to disable "lock on mount" option > of cdrom by "echo 0 > /proc/sys/dev/cdrom/lock" > or putting "dev.cdrom.lock = 0" in /etc/sysctl.conf and reloading with > sysctl -p. Well, that's fantastic. Why isn't this enabled by default? /Peter From hk at isphuset.no Tue Jan 25 09:32:28 2005 From: hk at isphuset.no (Hans Kristian Rosbach) Date: Tue, 25 Jan 2005 10:32:28 +0100 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106629396.28420.92.camel@bree.local.net> References: <1106629396.28420.92.camel@bree.local.net> Message-ID: <1106645548.7318.5.camel@linux.local> On Tue, 2005-01-25 at 06:03, Jeremy Katz wrote: > As some people have noticed, Xen is now available from the Fedora > development repository. More information on Xen itself can be found at > http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html. We're > following the -unstable Xen tree at the moment which does occasionally > lead to things being broken but also lets us track a lot of the more > interesting work going on there. Since setting up to run Xen isn't > entirely straight-forward, here's a run-through of what should work for > setting up a single Xen guest running the Fedora development tree. *snip* Wow, that is an excellent guide! It seems so much simpler now =) This means I'll have to increase "Test XEN" priority on my TODO list. -HK From symbiont at berlios.de Tue Jan 25 10:11:25 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 25 Jan 2005 18:11:25 +0800 Subject: RFC: Soname in rpm name In-Reply-To: <20050125001030.GA5190@neu.nirvana> References: <1106608786.15146.98.camel@bobcat.mine.nu> <20050125001030.GA5190@neu.nirvana> Message-ID: <200501251811.25823.symbiont@berlios.de> On Tuesday 25 January 2005 08:10, Axel Thimm wrote: > I only see added value at no real cost Quick reminder: if Bug 130352 isn't addressed, non of the above discussion is very useful: http://bugzilla.redhat.com/bugzilla/130352 I think the Bug should be re-formulated into an RFE based on Axel's Provides(noupdate): foo syntax. Or, maybe Provides(virtual):, or something. But, this is definitely the first hurdle to jump over, then a more well-rounded discussion on a method for soname rpms can be more effective. take care, -- -jeff From rahulsundaram at gmail.com Tue Jan 25 10:25:04 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Tue, 25 Jan 2005 15:55:04 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <5cf776b80501231525cec0502@mail.gmail.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410993.15391.42.camel@jdub.homelinux.org> <5cf776b8050123075072835f89@mail.gmail.com> <1106498904.6129.46.camel@laptopd505.fenrus.org> <5cf776b80501231525cec0502@mail.gmail.com> Message-ID: On Sun, 23 Jan 2005 19:25:39 -0400, mbneto wrote: > Hi, > > Can you give me a list of those "uneeded" packages ? :) thats not really an easy thing to do. -- Regards, Rahul Sundaram From Axel.Thimm at ATrpms.net Tue Jan 25 10:45:00 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jan 2005 11:45:00 +0100 Subject: kernel-devel: should yum install, not update? In-Reply-To: References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> <20050123003639.GA28104@redhat.com> <41F32901.7080003@insitesinc.com> <20050123111151.GB31380@neu.nirvana> <41F5907F.8080304@nc.rr.com> <20050125003144.GC5190@neu.nirvana> Message-ID: <20050125104500.GA12185@neu.nirvana> On Tue, Jan 25, 2005 at 02:36:42AM -0200, Alexandre Oliva wrote: > On Jan 24, 2005, Axel Thimm wrote: > > > It is the packager's decision whether he will craft a package that > > will allow concurrent non-conflicting installs of the same package > > in different versions. This is currently (only) true for the kernel > > packages, but could easily be extended to gcc and python packages. > > > So if the packager has taken care to allow for concurrent installs he > > will tag his package appropriately. > > > A higher level resolver has otherwise no chance on deriving this > > information and the current patching of resolvers to allow certain > > packages to be installed instead of upgraded will have an end. > > And why couldn't the depsolver itself verify that conflicts do not > exist between the installed version and the to-be-installed one? I > think it's my turn to show that we don't need additional annotations > :-) Common/overlapping filespace is only one criterion, there are more resources a package may consume that is not recorded in the rpm. Just consider netwrok deamon version 1.0 and 2.0 that have the version attached to all the files/dirs. rpms should not happily coinstall both which will try to listen on the same port. It's a packager decision/design, nothing to be left by chance to the system or end-user. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Jan 25 10:52:12 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jan 2005 11:52:12 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> <20050124185747.GI19903@neu.nirvana> Message-ID: <20050125105212.GB12185@neu.nirvana> On Tue, Jan 25, 2005 at 02:24:06AM -0200, Alexandre Oliva wrote: > On Jan 24, 2005, Axel Thimm wrote: > > On Mon, Jan 24, 2005 at 03:05:29PM -0200, Alexandre Oliva wrote: > >> On Jan 24, 2005, Ralf Ertzinger wrote: > >> > The problem with this is that RPM does not indicate whether a package has > >> > "end user value" (a command line or GUI program, or a daemon), or is just > >> > a support library needed by said end user programs, which can be removed > >> > if not needed by anyone. > >> > >> Could we perhaps add such a flag to the rpm database? Then the > >> installer and the various other package installation front-ends could > >> mark user- (or comps-)requested packages as having end user value, and > >> everything else brought in to satisfy dependencies such that it is (or > >> can be) removed as soon as no dependencies remain. > > > ATrpms has started marking library only packages with > > > Provides: shared-library-package > > > so these packages can be identifies with > > > rpm --whatprovides shared-library-package > > > and be probed for garbage collection. > > The weak point of your argument is that it assumes that the only kind > of package that doesn't provide "end user value" is the kind that > provides shared-library-package. This is just not true, although I > must admit it's the most common case. Well, "anems are but sound and smoke". Originally I had "rtp" for runtimepackage, but this sounded like coming from the Windows side of the world. Since the current greatest pain are shared libs I decided to get more specific. I wouldn't mind an alternative suggestion. The important thing is that the mechanism works. > > I.e. there is no need to extend rpm, you have everything already in > > place. > > Not quite. Consider that I might actually want to keep a shared lib > around (say libdvdcss, only used as a plugin by libdvdread). With > your scheme, there's no way to tell it from any other shared > lib-providing package, so it could be garbage collected along with > other libs. Well, make the garbage collector have a config file with a filter with user configurable hold-backs. That isn't rocket science, is it? ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Tue Jan 25 10:54:58 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jan 2005 11:54:58 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <200501251811.25823.symbiont@berlios.de> References: <1106608786.15146.98.camel@bobcat.mine.nu> <20050125001030.GA5190@neu.nirvana> <200501251811.25823.symbiont@berlios.de> Message-ID: <20050125105458.GC12185@neu.nirvana> On Tue, Jan 25, 2005 at 06:11:25PM +0800, Jeff Pitman wrote: > On Tuesday 25 January 2005 08:10, Axel Thimm wrote: > > I only see added value at no real cost > > Quick reminder: if Bug 130352 isn't addressed, non of the above > discussion is very useful: > > http://bugzilla.redhat.com/bugzilla/130352 I agree that this bug needs to be fixed somehow, but in the case of soname-in-rpmtag you don't run into the problem, as the libfooN packages don't share any common provides, neither real nor virtual. Otherwise I would have noticed, multiple libfooN packages have been in ATrpms since ages now, not to think of Mandrake. :) > I think the Bug should be re-formulated into an RFE based on Axel's > Provides(noupdate): foo syntax. Or, maybe Provides(virtual):, or > something. > > But, this is definitely the first hurdle to jump over, then a more > well-rounded discussion on a method for soname rpms can be more > effective. > > take care, -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From teg at pvv.org Tue Jan 25 11:04:31 2005 From: teg at pvv.org (=?ISO-8859-1?Q?Trond_Eivind_Glomsr=F8d?=) Date: Tue, 25 Jan 2005 12:04:31 +0100 Subject: further package removals/potential package removals In-Reply-To: <41F2D02B.30300@insight.rr.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <41F2D02B.30300@insight.rr.com> Message-ID: <41F627BF.6080908@pvv.org> Jim Cornette wrote: > Is the concept of Fedora Extras to push programs off to the side or to > find a better location for programs that are close to the upstream > developers model in containment? Proving the concept/integration before moving a lot of things there would be good. > > Is there work in making compatible iso files for Fedora Extras to > enable installing them during an initial fresh installation? And, FWIW, it should be available during kickstart too. From fedora at wir-sind-cool.org Tue Jan 25 11:19:02 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 25 Jan 2005 12:19:02 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <200501251811.25823.symbiont@berlios.de> References: <1106608786.15146.98.camel@bobcat.mine.nu> <20050125001030.GA5190@neu.nirvana> <200501251811.25823.symbiont@berlios.de> Message-ID: <20050125121902.09b86196.fedora@wir-sind-cool.org> On Tue, 25 Jan 2005 18:11:25 +0800, Jeff Pitman wrote: > On Tuesday 25 January 2005 08:10, Axel Thimm wrote: > > I only see added value at no real cost > > Quick reminder: if Bug 130352 isn't addressed, non of the above > discussion is very useful: > > http://bugzilla.redhat.com/bugzilla/130352 It looks like https://bugzilla.redhat.com/111071 From dwmw2 at infradead.org Tue Jan 25 11:35:52 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 25 Jan 2005 11:35:52 +0000 Subject: kernel-devel: should yum install, not update? In-Reply-To: <20050125003144.GC5190@neu.nirvana> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> <20050123003639.GA28104@redhat.com> <41F32901.7080003@insitesinc.com> <20050123111151.GB31380@neu.nirvana> <41F5907F.8080304@nc.rr.com> <20050125003144.GC5190@neu.nirvana> Message-ID: <1106652953.6480.118.camel@localhost.localdomain> On Tue, 2005-01-25 at 01:31 +0100, Axel Thimm wrote: > That's a bit unrelated to this issue. The disttag is to indicate the > build environment and to make packages build out of the same specfile > on different build environments to align properly in rpm upgrade paths > (same specfile, different build environments: make build environments > of newer distros win). The build environment can make a _lot_ of difference. In the case of bridge-utils, for example, you get entirely different behaviour if sysfsutils happens to be installed when the package was built. Without sysfsutils you get a package which doesn't work on 2.4 kernels but which does work with 32-bit binaries on a 6-bit kernel. With sysfsutils you get a 32-bit package which doesn't work on 64-bit kernels. Personally, I think the use of autotools should be banned in RPM packaging. It adversely affects the reproducability. -- dwmw2 From harald at redhat.com Tue Jan 25 11:45:41 2005 From: harald at redhat.com (Harald Hoyer) Date: Tue, 25 Jan 2005 12:45:41 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <41E6937F.2070904@redhat.com> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> Message-ID: <41F63165.6000405@redhat.com> ok, this is what I came up with for FC4: xargs_simple () { if [ "$1" = "-n" ]; then shift MAXNR="$1" shift else MAXNR=100 fi NR=$MAXNR ARGS="" [ -z "$1" ] && set echo while read line; do if [ $NR -gt 0 ]; then ARGS="$ARGS $line" NR=$[$NR - 1] else "$@" $ARGS NR=$MAXNR ARGS="$line" fi done if [ -n "$ARGS" ]; then "$@" $ARGS fi } make_extra_nodes () { ln -snf /proc/self/fd $udev_root/fd ln -snf /proc/self/fd/0 $udev_root/stdin ln -snf /proc/self/fd/1 $udev_root/stdout ln -snf /proc/self/fd/2 $udev_root/stderr ln -snf /proc/kcore $udev_root/core [ -d $udev_root/pts ] || mkdir -m 0755 $udev_root/pts [ -d $udev_root/shm ] || mkdir -m 0755 $udev_root/shm if [ -x $MAKEDEV ]; then for i in /etc/sysconfig/makedev.d/*.nodes; do cat "$i" | sed -e 's,#.*,,g' | \ xargs_simple -n 100 $MAKEDEV -x done fi for i in /etc/sysconfig/makedev.d/*.symlinks; do cat "$i" | sed -e 's,#.*,,g' | xargs_simple -n 1 ln -snv fi } This should MAKEDEV the nodes from /etc/sysconfig/makedev.d/*.nodes # cat /etc/sysconfig/makedev.d/50-udev.nodes | \ > sed -e 's,#.*,,g' | xargs_simple echo tty1 tty2 tty3 tty4 tty5 tty6 loop0 loop1 loop2 loop3 loop4 loop5 loop6 loop7 lp0 lp1 lp2 lp3 parport0 parport1 parport2 parport3 net/tun ppp console null zero The file can contain comments with "#". Also symlinks described in /etc/sysconfig/makedev.d/*.symlinks are created. Packages can drop their own files in /etc/sysconfig/makedev.d and the definition of the nodes in /etc/makedev.d/. Are the names fine or should we rename /etc/sysconfig/makedev.d in s.th. like /etc/sysconfig/init-makedev.d ?? From rahulsundaram at gmail.com Tue Jan 25 11:57:57 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Tue, 25 Jan 2005 17:27:57 +0530 Subject: kernel-devel: should yum install, not update? In-Reply-To: <1106652953.6480.118.camel@localhost.localdomain> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> <20050123003639.GA28104@redhat.com> <41F32901.7080003@insitesinc.com> <20050123111151.GB31380@neu.nirvana> <41F5907F.8080304@nc.rr.com> <20050125003144.GC5190@neu.nirvana> <1106652953.6480.118.camel@localhost.localdomain> Message-ID: Hi > > Personally, I think the use of autotools should be banned in RPM > packaging. It adversely affects the reproducability. sure. whats the alternative thou? -- Regards, Rahul Sundaram From feliciano.matias at free.fr Tue Jan 25 11:59:03 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 25 Jan 2005 12:59:03 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <41F63165.6000405@redhat.com> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> Message-ID: <1106654343.9957.10.camel@one.myworld> Le mardi 25 janvier 2005 ? 12:45 +0100, Harald Hoyer a ?crit : > ok, this is what I came up with for FC4: > > (snip) > > This should MAKEDEV the nodes from /etc/sysconfig/makedev.d/*.nodes > # cat /etc/sysconfig/makedev.d/50-udev.nodes | \ > > sed -e 's,#.*,,g' | xargs_simple echo > tty1 tty2 tty3 tty4 tty5 tty6 loop0 loop1 loop2 loop3 loop4 loop5 loop6 loop7 > lp0 lp1 lp2 lp3 parport0 parport1 parport2 parport3 net/tun ppp console null zero > > The file can contain comments with "#". Also symlinks described in > /etc/sysconfig/makedev.d/*.symlinks are created. > > Packages can drop their own files in /etc/sysconfig/makedev.d and the > definition of the nodes in /etc/makedev.d/. > Nice. > Are the names fine or should we rename /etc/sysconfig/makedev.d in s.th. like > /etc/sysconfig/init-makedev.d ?? I prefer /etc/sysconfig/init-makedev.d. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From feliciano.matias at free.fr Tue Jan 25 12:02:19 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 25 Jan 2005 13:02:19 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <41F63165.6000405@redhat.com> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> Message-ID: <1106654539.9957.13.camel@one.myworld> Le mardi 25 janvier 2005 ? 12:45 +0100, Harald Hoyer a ?crit : > ok, this is what I came up with for FC4: > (...) > Also symlinks described in > /etc/sysconfig/makedev.d/*.symlinks are created. Could it be possible to have symlinks in the same file ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rahulsundaram at gmail.com Tue Jan 25 12:00:30 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Tue, 25 Jan 2005 17:30:30 +0530 Subject: udev: Directory for custom device nodes. In-Reply-To: <41F63165.6000405@redhat.com> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> Message-ID: On Tue, 25 Jan 2005 12:45:41 +0100, Harald Hoyer wrote: > ok, this is what I came up with for FC4: I am not really fond of moving stuff like into the already crowded /etc/sysconfig. can you please do something thats upstream compatible -- Regards, Rahul Sundaram From dwmw2 at infradead.org Tue Jan 25 12:08:26 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 25 Jan 2005 12:08:26 +0000 Subject: kernel-devel: should yum install, not update? In-Reply-To: References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> <20050123003639.GA28104@redhat.com> <41F32901.7080003@insitesinc.com> <20050123111151.GB31380@neu.nirvana> <41F5907F.8080304@nc.rr.com> <20050125003144.GC5190@neu.nirvana> <1106652953.6480.118.camel@localhost.localdomain> Message-ID: <1106654906.6480.134.camel@localhost.localdomain> On Tue, 2005-01-25 at 17:27 +0530, Rahul Sundaram wrote: > sure. whats the alternative thou? Real makefiles, explicit selection of such radical options as the sysfs vs. non-sysfs one in bridge-utils and, in general, code which is actually portable and doesn't need the stupid hacks which one often sees autoconf trying to select. The real problem with autoconf is that it encourages stupid behaviour and in a lot of cases leads to bad code and broken cross-compilation. It isn't inherently evil; it's just a tool. But it's a tool which is very easy to misuse. I wouldn't let a 5-year-old loose with an electric drill, and I don't like userspace programmers having access to autoconf. -- dwmw2 From harald at redhat.com Tue Jan 25 12:34:05 2005 From: harald at redhat.com (Harald Hoyer) Date: Tue, 25 Jan 2005 13:34:05 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <1106654539.9957.13.camel@one.myworld> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> <1106654539.9957.13.camel@one.myworld> Message-ID: <41F63CBD.5030900@redhat.com> F?liciano Matias wrote: > Le mardi 25 janvier 2005 ? 12:45 +0100, Harald Hoyer a ?crit : > >>ok, this is what I came up with for FC4: >>(...) >> Also symlinks described in >>/etc/sysconfig/makedev.d/*.symlinks are created. > > > Could it be possible to have symlinks in the same file ? hmm, this would require parsing the file... but we could remove the symlinks, cause MAKEDEV understands symlinks like this: # fgrep rfcomm0 /etc/makedev.d/redhat l rfcomm0 ttyUB0 # MAKEDEV -x rfcomm0 # ll /dev/rfcomm0 lrwxrwxrwx 1 root root 6 25. Jan 13:33 /dev/rfcomm0 -> ttyUB0 From harald at redhat.com Tue Jan 25 12:34:48 2005 From: harald at redhat.com (Harald Hoyer) Date: Tue, 25 Jan 2005 13:34:48 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> Message-ID: <41F63CE8.50004@redhat.com> Rahul Sundaram wrote: > On Tue, 25 Jan 2005 12:45:41 +0100, Harald Hoyer wrote: > >>ok, this is what I came up with for FC4: > > > I am not really fond of moving stuff like into the already crowded > /etc/sysconfig. can you please do something thats upstream compatible like what? upstream has no mechanism for manual device creation. From Axel.Thimm at ATrpms.net Tue Jan 25 12:48:59 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 25 Jan 2005 13:48:59 +0100 Subject: kernel-devel: should yum install, not update? In-Reply-To: <1106652953.6480.118.camel@localhost.localdomain> References: <4c4ba15305012211032bde7867@mail.gmail.com> <604aa7910501221122724f734c@mail.gmail.com> <1106422790.3511.2.camel@cutter> <604aa79105012212225b58487b@mail.gmail.com> <20050123003639.GA28104@redhat.com> <41F32901.7080003@insitesinc.com> <20050123111151.GB31380@neu.nirvana> <41F5907F.8080304@nc.rr.com> <20050125003144.GC5190@neu.nirvana> <1106652953.6480.118.camel@localhost.localdomain> Message-ID: <20050125124859.GG12185@neu.nirvana> On Tue, Jan 25, 2005 at 11:35:52AM +0000, David Woodhouse wrote: > On Tue, 2005-01-25 at 01:31 +0100, Axel Thimm wrote: > > That's a bit unrelated to this issue. The disttag is to indicate the > > build environment and to make packages build out of the same specfile > > on different build environments to align properly in rpm upgrade paths > > (same specfile, different build environments: make build environments > > of newer distros win). > > The build environment can make a _lot_ of difference. Nobody denies that. In the context of the disttag discussion, the disttag denotes the distribution which defines part of the build environment (the other part is the selection of active packages during build via BuildRequires) > In the case of bridge-utils, for example, you get entirely different > behaviour if sysfsutils happens to be installed when the package was > built. Without sysfsutils you get a package which doesn't work on > 2.4 kernels but which does work with 32-bit binaries on a 6-bit > kernel. With sysfsutils you get a 32-bit package which doesn't work > on 64-bit kernels. A 6-bit kernel? :) > Personally, I think the use of autotools should be banned in RPM > packaging. It adversely affects the reproducability. Agreed, patches to Makefile.am/configure.ac should also contain patches to the derived files. But you run into the problem of zero-time differences and make will consider recreating Makefile/configure if that timestamp is the same like the one of their sources and fail if no autotools are supplied in the build environment. An ugly hack is %patch0 -b .autotoolsmasterfiles sleep 2 %patch1 -b .autotoolsderivedfiles But we've gotten quite far off the main topic, I guess ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rahulsundaram at gmail.com Tue Jan 25 12:55:08 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Tue, 25 Jan 2005 18:25:08 +0530 Subject: udev: Directory for custom device nodes. In-Reply-To: <41F63F0D.70601@redhat.com> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> <41F63CE8.50004@redhat.com> <41F63F0D.70601@redhat.com> Message-ID: Hi > > right, but this won't make its way in the upstream udev tarball, cause not all > distributions have/use MAKEDEV and the start_udev is fedora specific anyway. ok. are you aware of what other distro do resolve the problem you are currently trying to solve. just curious on how they manage to do without things like makedev and start_udev when you have to manually create device nodes > > that could be changed.. > /etc/udev/init-makedev.d > this looks a better thing to do for me. -- Regards, Rahul Sundaram From rahulsundaram at gmail.com Tue Jan 25 12:57:34 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Tue, 25 Jan 2005 18:27:34 +0530 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106629396.28420.92.camel@bree.local.net> References: <1106629396.28420.92.camel@bree.local.net> Message-ID: On Tue, 25 Jan 2005 00:03:16 -0500, Jeremy Katz wrote: > As some people have noticed, Xen is now available from the Fedora > development repository. More information on Xen itself can be found at > http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html. We're > following the -unstable Xen tree at the moment which does occasionally > lead to things being broken but also lets us track a lot of the more > interesting work going on there. Since setting up to run Xen isn't > entirely straight-forward, here's a run-through of what should work for > setting up a single Xen guest running the Fedora development tree. > looks very useful. can you consider moving this into fedora.redhat.com/docs. it can hold a title like "Getting started with Xen" -- Regards, Rahul Sundaram From skvidal at phy.duke.edu Tue Jan 25 13:26:10 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 25 Jan 2005 08:26:10 -0500 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> <20050124185747.GI19903@neu.nirvana> <41F5E5E4.6010408@nc.rr.com> Message-ID: <1106659570.23277.75.camel@cutter> > Not the same pinning. I'm talking about adding a bit that would tell > whether a particular package was requested by the user or brought in > just to satisfy a dependency of another package. Packages of the > latter group that no longer have any dependency in the database may be > garbage collected. Packages of the former group shouldn't. > Right but the problem is this. sometimes, when I know a dep a package needs i'll request it too. so instead of: yum install rdiff-backup I'll run: yum install rdiff-backup librsync So, I've requested it - but only b/c I know it's a dep. -sv From katzj at redhat.com Tue Jan 25 13:38:38 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 25 Jan 2005 08:38:38 -0500 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: References: <1106629396.28420.92.camel@bree.local.net> Message-ID: <1106660319.28420.100.camel@bree.local.net> On Tue, 2005-01-25 at 18:27 +0530, Rahul Sundaram wrote: > On Tue, 25 Jan 2005 00:03:16 -0500, Jeremy Katz wrote: > > As some people have noticed, Xen is now available from the Fedora > > development repository. More information on Xen itself can be found at > > http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html. We're > > following the -unstable Xen tree at the moment which does occasionally > > lead to things being broken but also lets us track a lot of the more > > interesting work going on there. Since setting up to run Xen isn't > > entirely straight-forward, here's a run-through of what should work for > > setting up a single Xen guest running the Fedora development tree. > looks very useful. can you consider moving this into > fedora.redhat.com/docs. it can hold a title like "Getting started > with Xen" The plan is to put it up, although possibly not under the docs heading. What's described here is mostly the quickstart for starting to use Xen today. Some of the things that I alluded to at the end will make it far less relevant over the course of the next month or so. So I'd prefer to wait until a more final state before calling them docs :) Jeremy From feliciano.matias at free.fr Tue Jan 25 13:38:54 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 25 Jan 2005 14:38:54 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <41F63165.6000405@redhat.com> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> Message-ID: <1106660334.9957.43.camel@one.myworld> Le mardi 25 janvier 2005 ? 12:45 +0100, Harald Hoyer a ?crit : > Are the names fine or should we rename /etc/sysconfig/makedev.d in s.th. like > /etc/sysconfig/init-makedev.d ?? /etc/sysconfig/makedev.d (or init-makedev.d) does not store things like found in /etc/makedev.d/ . proposition : /etc/sysconfig/init-dev.d Another point, sysinit does not provide a way to load a module at boot time (other than using /etc/rc.d/rc.local). For example, I use this driver (with mplayer) : http://www.linuxops.net/~pw/mga_vid/ This module does not support auto-loading. A /etc/sysconfig/init-dev.d/*.module would be appreciated. Last, what about /etc/modprobe.conf.d by default ? Modprobe support "include /etc/modprobe.conf.d" with /etc/modprobe.conf. There is one piece missing "in my dream" : /etc/security/console.perms.d/mga_vid where I can add "=/dev/mga_vid". Suppose I want to package the mga_vid driver, I'll use : /etc/makedev.d/mga_vid # /dev/mga_vid definition /etc/sysconfig/init-dev.d/mga_vid.dev # create /dev/mga_vid /etc/sysconfig/init-dev.d/mga_vid.module # load mga_vid /etc/modprobe.conf.d/mga_vid.conf # configure mga_vid /etc/security/console.perms.d/mga_vid # pam_console configuration -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Tue Jan 25 13:42:43 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 25 Jan 2005 08:42:43 -0500 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106660319.28420.100.camel@bree.local.net> References: <1106629396.28420.92.camel@bree.local.net> <1106660319.28420.100.camel@bree.local.net> Message-ID: <1106660563.23277.77.camel@cutter> On Tue, 2005-01-25 at 08:38 -0500, Jeremy Katz wrote: > On Tue, 2005-01-25 at 18:27 +0530, Rahul Sundaram wrote: > > On Tue, 25 Jan 2005 00:03:16 -0500, Jeremy Katz wrote: > > > As some people have noticed, Xen is now available from the Fedora > > > development repository. More information on Xen itself can be found at > > > http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html. We're > > > following the -unstable Xen tree at the moment which does occasionally > > > lead to things being broken but also lets us track a lot of the more > > > interesting work going on there. Since setting up to run Xen isn't > > > entirely straight-forward, here's a run-through of what should work for > > > setting up a single Xen guest running the Fedora development tree. > > > looks very useful. can you consider moving this into > > fedora.redhat.com/docs. it can hold a title like "Getting started > > with Xen" > > The plan is to put it up, although possibly not under the docs heading. > What's described here is mostly the quickstart for starting to use Xen > today. Some of the things that I alluded to at the end will make it far > less relevant over the course of the next month or so. So I'd prefer to > wait until a more final state before calling them docs :) > Post it on the fedoraproject.org wiki or in some other location there - then people can easily link to it, if you want. -sv From gauret at free.fr Tue Jan 25 13:44:41 2005 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 25 Jan 2005 14:44:41 +0100 Subject: RFC: Soname in rpm name References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> <20050124185747.GI19903@neu.nirvana> <41F5E5E4.6010408@nc.rr.com> <1106659570.23277.75.camel@cutter> Message-ID: seth vidal wrote: > Right but the problem is this. > sometimes, when I know a dep a package needs i'll request it too. > so instead of: > yum install rdiff-backup > I'll run: > yum install rdiff-backup librsync > So, I've requested it - but only b/c I know it's a dep. I don't think many people do that, only those that know what is required by what. Besides, since you've added manually on install, you'll probably add it manually on removal, won't you ? So there will be no lib leftover. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info For external use only From feliciano.matias at free.fr Tue Jan 25 13:47:08 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 25 Jan 2005 14:47:08 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> <41F63CE8.50004@redhat.com> <41F63F0D.70601@redhat.com> Message-ID: <1106660828.9957.51.camel@one.myworld> Le mardi 25 janvier 2005 ? 18:25 +0530, Rahul Sundaram a ?crit : > ok. are you aware of what other distro do resolve the problem you are > currently trying to solve. just curious on how they manage to do > without things like makedev and start_udev when you have to manually > create device nodes There are not a lot of distributions which use a "pure" udev (without a static "/dev"). SuSE use a "pure" udev AFAIK. Other thought ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From harald at redhat.com Tue Jan 25 13:47:55 2005 From: harald at redhat.com (Harald Hoyer) Date: Tue, 25 Jan 2005 14:47:55 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <1106660334.9957.43.camel@one.myworld> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> <1106660334.9957.43.camel@one.myworld> Message-ID: <41F64E0B.3040609@redhat.com> F?liciano Matias wrote: > Le mardi 25 janvier 2005 ? 12:45 +0100, Harald Hoyer a ?crit : > >>Are the names fine or should we rename /etc/sysconfig/makedev.d in s.th. like >>/etc/sysconfig/init-makedev.d ?? > > > > /etc/sysconfig/makedev.d (or init-makedev.d) does not store things like > found in /etc/makedev.d/ . > > proposition : > /etc/sysconfig/init-dev.d > > > Another point, sysinit does not provide a way to load a module at boot > time (other than using /etc/rc.d/rc.local). > > For example, I use this driver (with mplayer) : > http://www.linuxops.net/~pw/mga_vid/ > > This module does not support auto-loading. > A /etc/sysconfig/init-dev.d/*.module would be appreciated. Hmm, there is rc.modules mentioned in rc.sysinit, but I think that is deprecated. > > > Last, what about /etc/modprobe.conf.d by default ? > > Modprobe support "include /etc/modprobe.conf.d" with /etc/modprobe.conf. > > There is one piece missing "in my dream" : > /etc/security/console.perms.d/mga_vid > where I can add "=/dev/mga_vid". > > Suppose I want to package the mga_vid driver, I'll use : > /etc/makedev.d/mga_vid # /dev/mga_vid definition > /etc/sysconfig/init-dev.d/mga_vid.dev # create /dev/mga_vid > /etc/sysconfig/init-dev.d/mga_vid.module # load mga_vid > /etc/modprobe.conf.d/mga_vid.conf # configure mga_vid > /etc/security/console.perms.d/mga_vid # pam_console configuration > Right... that would be cool. From skvidal at phy.duke.edu Tue Jan 25 13:51:23 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 25 Jan 2005 08:51:23 -0500 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> <20050124185747.GI19903@neu.nirvana> <41F5E5E4.6010408@nc.rr.com> <1106659570.23277.75.camel@cutter> Message-ID: <1106661083.23277.79.camel@cutter> On Tue, 2005-01-25 at 14:44 +0100, Aurelien Bompard wrote: > seth vidal wrote: > > Right but the problem is this. > > sometimes, when I know a dep a package needs i'll request it too. > > so instead of: > > yum install rdiff-backup > > I'll run: > > yum install rdiff-backup librsync > > So, I've requested it - but only b/c I know it's a dep. > > I don't think many people do that, only those that know what is required by > what. Besides, since you've added manually on install, you'll probably add > it manually on removal, won't you ? So there will be no lib leftover. No, not necessarily. My point is that marking it based on what you _think_ the user is doing is not going to produce reliable results. -sv From skvidal at phy.duke.edu Tue Jan 25 13:53:17 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 25 Jan 2005 08:53:17 -0500 Subject: RFC: Soname in rpm name In-Reply-To: References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> Message-ID: <1106661197.23277.81.camel@cutter> > Sounds interesting. On the other hand, maybe we could do it manually (from a > packager's point of view) : if you package library foo, and you know that > version 0.1 is not supported anymore (noone knows that better than you > since you maintain it), you can add an Obsoletes tag to your libfoo5 > package, and force the removal. > Would that solve Jeff's issue ? > Obsoletes should be used when a package changes name. Not when someone thinks a new version gets rid of an old version. -sv From buildsys at redhat.com Tue Jan 25 13:52:33 2005 From: buildsys at redhat.com (Build System) Date: Tue, 25 Jan 2005 08:52:33 -0500 Subject: rawhide report: 20050125 changes Message-ID: <200501251352.j0PDqX611704@porkchop.devel.redhat.com> From stuart at terminus.co.uk Tue Jan 25 13:52:38 2005 From: stuart at terminus.co.uk (Stuart Children) Date: Tue, 25 Jan 2005 13:52:38 +0000 Subject: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> Message-ID: <41F64F26.6080708@terminus.co.uk> Rex Dieter wrote: > On Mon, 24 Jan 2005, Stuart Children wrote: > >> I see Core as "packages managed mainly by RedHat employees and >> essential to a base [desktop|server] system" (latter is horribly >> subjective I know), and Extras as "packages mainly packaged by >> non-RedHat employees", with the extra requirement that no package in >> Core should depend on a package in Extras. Both are parts of the >> overall distribution, but Core simply has stricter QC and inclusion >> requirements. > > (Ironic or not) since Fedora Extras (at least the fedora.us incarnation) > actually has QA *before* packages are published, IMO, their packaging > quality is at least as good or better than many of those in Core. Yes, fair point. I certainly did not intend to mark Extras as of poorer quality (nor diminish all the hard work people have done at fedora.us). Clearly all packagers should strive to create packages of the highest quality - whichever repository they happen to be a part of. My emphasis was more on who has control over packaging decisions. For Core, that's Red Hat employees - for Extras it's the individual package owner. Hopefully both would be working to the same guidelines/rules that the Fedora community has agreed upon. I don't think it has to be like that - I'm just making suggestions to try and help form definitions of Core and Extras. Cheers -- Stuart Children From feliciano.matias at free.fr Tue Jan 25 14:00:54 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 25 Jan 2005 15:00:54 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <41F64E0B.3040609@redhat.com> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> <1106660334.9957.43.camel@one.myworld> <41F64E0B.3040609@redhat.com> Message-ID: <1106661654.9957.56.camel@one.myworld> Le mardi 25 janvier 2005 ? 14:47 +0100, Harald Hoyer a ?crit : > > Hmm, there is rc.modules mentioned in rc.sysinit, but I think that is deprecated. > /etc/rc.d/rc.sysinit (FC3) : # Load modules (for backward compatibility with VARs) if [ -f /etc/rc.modules ]; then /etc/rc.modules fi $ ls /etc/rc.modules ls: /etc/rc.modules: No such file or directory It's not better than /etc/rc.d/rc.local . -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From lfarkas at bppiac.hu Tue Jan 25 14:11:40 2005 From: lfarkas at bppiac.hu (Farkas Levente) Date: Tue, 25 Jan 2005 15:11:40 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <1106659570.23277.75.camel@cutter> References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> <20050124185747.GI19903@neu.nirvana> <41F5E5E4.6010408@nc.rr.com> <1106659570.23277.75.camel@cutter> Message-ID: <41F6539C.1090202@bppiac.hu> seth vidal wrote: >>Not the same pinning. I'm talking about adding a bit that would tell >>whether a particular package was requested by the user or brought in >>just to satisfy a dependency of another package. Packages of the >>latter group that no longer have any dependency in the database may be >>garbage collected. Packages of the former group shouldn't. >> > > > Right but the problem is this. > > sometimes, when I know a dep a package needs i'll request it too. > > so instead of: > yum install rdiff-backup > > I'll run: > yum install rdiff-backup librsync > > So, I've requested it - but only b/c I know it's a dep. why did you do so? if anyone you should know that yum will intall it too. is it faster? or? is there _any_ reason for this??? -- Levente "Si vis pacem para bellum!" From symbiont at berlios.de Tue Jan 25 14:36:23 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Tue, 25 Jan 2005 22:36:23 +0800 Subject: RFC: Soname in rpm name In-Reply-To: <20050125121902.09b86196.fedora@wir-sind-cool.org> References: <200501251811.25823.symbiont@berlios.de> <20050125121902.09b86196.fedora@wir-sind-cool.org> Message-ID: <200501252236.23612.symbiont@berlios.de> On Tuesday 25 January 2005 19:19, Michael Schwendt wrote: > > On Tuesday 25 January 2005 08:10, Axel Thimm wrote: > > > I only see added value at no real cost > > > > Quick reminder: if Bug 130352 isn't addressed, non of the above > > discussion is very useful: > > > > http://bugzilla.redhat.com/bugzilla/130352 > > It looks like https://bugzilla.redhat.com/111071 Uh, yeah. 130352 was submitted after discussion between Rex, Axel, and I when 111071 couldn't be found. 111071 was eventually found but we realized it to be a dead-end discussion. 130352 has the trimmings of an RFE, rather than a bug report. Maybe the report should be modified and reworked as such so we can make progress on this. -- -jeff From gauret at free.fr Tue Jan 25 14:46:28 2005 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 25 Jan 2005 15:46:28 +0100 Subject: RFC: Soname in rpm name References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <1106661197.23277.81.camel@cutter> Message-ID: seth vidal wrote: > Obsoletes should be used when a package changes name. Not when someone > thinks a new version gets rid of an old version. But "Obsoletes" could be used for this, couldn't it ? And it's not any "someone" who would use it, but the packager, who knows the lib. Actually, the package *does* change name, since the proposal is to include the soname in it. What are the shortcomings ? Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq' | dc From dhollis at davehollis.com Tue Jan 25 14:47:30 2005 From: dhollis at davehollis.com (David Hollis) Date: Tue, 25 Jan 2005 09:47:30 -0500 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106629396.28420.92.camel@bree.local.net> References: <1106629396.28420.92.camel@bree.local.net> Message-ID: <1106664450.5495.8.camel@dhollis-lnx.centricconsulting.com> On Tue, 2005-01-25 at 00:03 -0500, Jeremy Katz wrote: > > Next, let's create a file to use as the backing for our Fedora install. > For example purposes, I'll create one of a size of 1 GB. > dd if=/dev/zero of=/root/fedora.img bs=1M count=1024 To make a sparse file, I used: dd if=/dev/zero of=fedora.img bs=1M count=1 seek=1024 This way, my file looked like 1GB, but only allocated space upon use. > Now, create an ext3 filesystem on this image. > mke2fs -F -j /root/fedora.img > You should now be able to mount your new temporary rootfs on a temporary > mountpoint, say /mnt > mount -o loop /root/fedora.img /mnt > Now, we can install whatever basesystem we want into this chroot. Make > sure that your yum configuration points to a valid repository. Then, > decide what group(s) you want to install. I'd recommend starting with > Base (or for the space constrained, Core, but this is more difficult). > Then, run > yum --installroot=/mnt -y groupinstall Base > Cool trick! Didn't know that I could do that! I did find that I needed to 'rpm --root /mnt --import to make yum happy. I also needed to create /mnt/var/cache/yum so that it could write the .gpgkeyschecked.yum file. I suppose that if I turned off gpg checking, I would have been fine. > Now, go get some coffee and have a snack. It's going to take a little > while :-) > Using rawhide as of this morning, I had dep issues with dmraid (needs to be rebuilt against new device-mapper) and stunnel (needs words). I excluded dmraid and stunnel and the install went ok. > Come back and if everything went okay, you'll have a minimal install > in /mnt. Now, for the ugly part, we need to set up some basic bits on > the filesystem that have to be different for xen right now. These > include a) creating some required device nodes in /dev > since we're not using an initrd and b) setting up an /etc/fstab > for i in console null zero ; do MAKEDEV -d /mnt -x $i ; done > for i in console null zero; do MAKEDEV -d /mnt/dev -x $i ; done Otherwise, those device files end up in / instead /dev on the filesystem image. > For the /etc/fstab, something simple like the following should work > /dev/sda1 / ext3 defaults > 1 1 > none /dev/pts devpts gid=5,mode=620 > 0 0 > none /dev/shm tmpfs defaults > 0 0 > none /proc proc defaults > 0 0 > none /sys sysfs defaults > 0 0 Would it be necessary to have /sys in fstab? The initscripts mount it automagically themselves. Haven't performed any testing myself to validate with a Xen config. -- David Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From i_p_a_u_l at yahoo.com Tue Jan 25 14:48:14 2005 From: i_p_a_u_l at yahoo.com (Paul Ionescu) Date: Tue, 25 Jan 2005 16:48:14 +0200 Subject: HAL ejects References: <1106639336.29380.9.camel@localhost.localdomain> <1106645834.19325.2.camel@localhost.localdomain> Message-ID: Hi, On Tue, 25 Jan 2005 10:37:14 +0100, Peter Backlund wrote: >> It is already in FC3 >> I am using it right now. >> I think it is not in HAL, but in GVM. However, to be able to use it, you >> have to disable "lock on mount" option of cdrom by "echo 0 > >> /proc/sys/dev/cdrom/lock" or putting "dev.cdrom.lock = 0" in >> /etc/sysctl.conf and reloading with sysctl -p. > > Well, that's fantastic. Why isn't this enabled by default? > > /Peter I don't really know, maybe some people like it the old unix way ? I don't have any kids yet, that tend to press any buttons to see what might happen (see Dee Dee), so for me it is easier to press the eject cdrom button, and actually it ejects, instead of nothing. Anyway, I think this should be an option in gvm. From rdieter at math.unl.edu Tue Jan 25 14:32:05 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jan 2005 08:32:05 -0600 (CST) Subject: RFC: Soname in rpm name In-Reply-To: References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <1106661197.23277.81.camel@cutter> Message-ID: On Tue, 25 Jan 2005, Aurelien Bompard wrote: > seth vidal wrote: >> Obsoletes should be used when a package changes name. Not when someone >> thinks a new version gets rid of an old version. > > But "Obsoletes" could be used for this, couldn't it ? I depends on your definition of Obsoletes. In my mind, it could be used for either purpose. -- Rex From dcbw at redhat.com Tue Jan 25 14:49:57 2005 From: dcbw at redhat.com (Dan Williams) Date: Tue, 25 Jan 2005 09:49:57 -0500 Subject: udev: Directory for custom device nodes. In-Reply-To: <1106660334.9957.43.camel@one.myworld> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> <1106660334.9957.43.camel@one.myworld> Message-ID: <1106664597.18134.0.camel@dcbw.boston.redhat.com> On Tue, 2005-01-25 at 14:38 +0100, F?liciano Matias wrote: > Suppose I want to package the mga_vid driver, I'll use : > /etc/makedev.d/mga_vid # /dev/mga_vid definition > /etc/sysconfig/init-dev.d/mga_vid.dev # create /dev/mga_vid > /etc/sysconfig/init-dev.d/mga_vid.module # load mga_vid > /etc/modprobe.conf.d/mga_vid.conf # configure mga_vid > /etc/security/console.perms.d/mga_vid # pam_console configuration Does it seem utterly _pathetic_ to anyone else but me that there would have to be 5 different places to add information about a particular hardware device, just to get it to load and work? Just a point of observation. Dan From notting at redhat.com Tue Jan 25 14:50:01 2005 From: notting at redhat.com (Bill Nottingham) Date: Tue, 25 Jan 2005 09:50:01 -0500 Subject: udev: Directory for custom device nodes. In-Reply-To: <1106660334.9957.43.camel@one.myworld> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> <1106660334.9957.43.camel@one.myworld> Message-ID: <20050125145001.GD6440@nostromo.devel.redhat.com> F?liciano Matias (feliciano.matias at free.fr) said: > There is one piece missing "in my dream" : > /etc/security/console.perms.d/mga_vid > where I can add "=/dev/mga_vid". This will get done with HAL in the future, FWIW. Bill From skvidal at phy.duke.edu Tue Jan 25 14:52:05 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 25 Jan 2005 09:52:05 -0500 Subject: RFC: Soname in rpm name In-Reply-To: References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <1106661197.23277.81.camel@cutter> Message-ID: <1106664725.25972.0.camel@opus.phy.duke.edu> > I depends on your definition of Obsoletes. In my mind, it could be used > for either purpose. > Using Obsoletes to 'discover' what you should install is such a bad idea. -sv From skvidal at phy.duke.edu Tue Jan 25 14:52:57 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 25 Jan 2005 09:52:57 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <41F6539C.1090202@bppiac.hu> References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> <20050124185747.GI19903@neu.nirvana> <41F5E5E4.6010408@nc.rr.com> <1106659570.23277.75.camel@cutter> <41F6539C.1090202@bppiac.hu> Message-ID: <1106664777.25972.2.camel@opus.phy.duke.edu> > why did you do so? if anyone you should know that yum will intall it > too. is it faster? or? is there _any_ reason for this??? It's not a question of why? It's simply that I did. -sv From cra at WPI.EDU Tue Jan 25 15:04:46 2005 From: cra at WPI.EDU (Charles R. Anderson) Date: Tue, 25 Jan 2005 10:04:46 -0500 Subject: loop device creation [was Re: udev: Directory for custom device nodes.] Message-ID: <20050125150446.GF7619@angus.ind.WPI.EDU> On Tue, Jan 25, 2005 at 12:45:41PM +0100, Harald Hoyer wrote: > tty1 tty2 tty3 tty4 tty5 tty6 loop0 loop1 loop2 loop3 loop4 loop5 loop6 > loop7 lp0 lp1 lp2 lp3 parport0 parport1 parport2 parport3 net/tun ppp > console null zero Why doesn't the loop module cause /dev/loop* device node creation at load time? E.g. I have in /etc/modprobe.conf: options loop max_loop=128 and /etc/fstab I have many of these: /iso/FC3-i386-DVD.iso /mnt/heidelberg-i386-DVD iso9660 ro,loop=/dev/loop59,nosuid,nodev 0 0 Shouldn't rc.sysinit's "mount -a" cause all the loop devices to be created automatically? It seems to not work at boot time, but later a manual "mount -a" does create the devices... From fedora at wir-sind-cool.org Tue Jan 25 15:10:43 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 25 Jan 2005 16:10:43 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <1106661197.23277.81.camel@cutter> References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <1106661197.23277.81.camel@cutter> Message-ID: <20050125161043.6bb64de2.fedora@wir-sind-cool.org> On Tue, 25 Jan 2005 08:53:17 -0500, seth vidal wrote: > > > Sounds interesting. On the other hand, maybe we could do it manually (from a > > packager's point of view) : if you package library foo, and you know that > > version 0.1 is not supported anymore (noone knows that better than you > > since you maintain it), you can add an Obsoletes tag to your libfoo5 > > package, and force the removal. > > Would that solve Jeff's issue ? > > > > Obsoletes should be used when a package changes name. Not when someone > thinks a new version gets rid of an old version. Where are such strict semantics of the "Obsoletes" field defined? Isn't it rather free to use? As in "we don't need that package any longer, it's obsolete and can be erased"? If, for instance, functionality of one package is supplied by another package, that's not a rename, but a relocation of package capabilities. Package "foo" would "Obsoletes: bar <= 1.0". If an old library API/ABI is not used anymore and hence considered obsolete, a new version of the library could "Obsolete: libfoo <= 0.9" just fine. From skvidal at phy.duke.edu Tue Jan 25 15:11:36 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 25 Jan 2005 10:11:36 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <20050125161043.6bb64de2.fedora@wir-sind-cool.org> References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <1106661197.23277.81.camel@cutter> <20050125161043.6bb64de2.fedora@wir-sind-cool.org> Message-ID: <1106665896.25972.12.camel@opus.phy.duke.edu> > Where are such strict semantics of the "Obsoletes" field defined? > > Isn't it rather free to use? As in "we don't need that package > any longer, it's obsolete and can be erased"? > > If, for instance, functionality of one package is supplied by another > package, that's not a rename, but a relocation of package > capabilities. Package "foo" would "Obsoletes: bar <= 1.0". If an old > library API/ABI is not used anymore and hence considered obsolete, a > new version of the library could "Obsolete: libfoo <= 0.9" just fine. Actually I was expressing my opinion on how I think it should be used. that's why I said 'should' -sv From mbneto at gmail.com Tue Jan 25 15:15:58 2005 From: mbneto at gmail.com (mbneto) Date: Tue, 25 Jan 2005 11:15:58 -0400 Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106390092.7211.440.camel@mccallum.corsepiu.local> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410993.15391.42.camel@jdub.homelinux.org> <5cf776b8050123075072835f89@mail.gmail.com> <1106498904.6129.46.camel@laptopd505.fenrus.org> <5cf776b80501231525cec0502@mail.gmail.com> Message-ID: <5cf776b8050125071534da28f0@mail.gmail.com> Ok. But since I was not able to remove myself (due to dependencies...) the packages to this ~300Mb I was hoping I could get (off list) the rpm -qa to compare with mine and simply remove the ones missing.. On Tue, 25 Jan 2005 15:55:04 +0530, Rahul Sundaram wrote: > On Sun, 23 Jan 2005 19:25:39 -0400, mbneto wrote: > > Hi, > > > > Can you give me a list of those "uneeded" packages ? :) > > thats not really an easy thing to do. > > -- > Regards, > Rahul Sundaram > From seanlkml at sympatico.ca Tue Jan 25 15:17:59 2005 From: seanlkml at sympatico.ca (Sean) Date: Tue, 25 Jan 2005 10:17:59 -0500 (EST) Subject: RFC: Soname in rpm name In-Reply-To: <1106665896.25972.12.camel@opus.phy.duke.edu> References: <1106570484.32065.1.camel@ulysse.olympe.o2t><1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us><604aa791050124070243cfe95f@mail.gmail.com><20050124220847.GD31520@neu.nirvana><604aa791050124142972c325cc@mail.gmail.com><20050124224043.GI31520@neu.nirvana><604aa791050124145435e5a102@mail.gmail.com><20050124232113.GM31520@neu.nirvana><604aa79105012416337f3de0ce@mail.gmail.com><20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <1106661197.23277.81.camel@cutter><20050125161043.6bb64de2.fedora@wir-sind-cool.org> <1106665896.25972.12.camel@opus.phy.duke.edu> Message-ID: <36556.10.10.10.28.1106666279.squirrel@linux1> On Tue, January 25, 2005 10:11 am, seth vidal said: >> Where are such strict semantics of the "Obsoletes" field defined? >> >> Isn't it rather free to use? As in "we don't need that package >> any longer, it's obsolete and can be erased"? >> >> If, for instance, functionality of one package is supplied by another >> package, that's not a rename, but a relocation of package >> capabilities. Package "foo" would "Obsoletes: bar <= 1.0". If an old >> library API/ABI is not used anymore and hence considered obsolete, a >> new version of the library could "Obsolete: libfoo <= 0.9" just fine. > > Actually I was expressing my opinion on how I think it should be used. > > that's why I said 'should' > Is there a good reason it shouldn't be used to mark packages as obsoleting others? If so, what is it? Sean From skvidal at phy.duke.edu Tue Jan 25 15:21:56 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 25 Jan 2005 10:21:56 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <36556.10.10.10.28.1106666279.squirrel@linux1> References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <1106661197.23277.81.camel@cutter> <20050125161043.6bb64de2.fedora@wir-sind-cool.org> <1106665896.25972.12.camel@opus.phy.duke.edu> <36556.10.10.10.28.1106666279.squirrel@linux1> Message-ID: <1106666516.25972.16.camel@opus.phy.duke.edu> > Is there a good reason it shouldn't be used to mark packages as obsoleting > others? > If so, what is it? For right now? mostly b/c it's just obsoleting an old version - not a change of package name. we shouldn't use obsoletes to do what a normal version update should do. -sv From katzj at redhat.com Tue Jan 25 15:26:39 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 25 Jan 2005 10:26:39 -0500 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106664450.5495.8.camel@dhollis-lnx.centricconsulting.com> References: <1106629396.28420.92.camel@bree.local.net> <1106664450.5495.8.camel@dhollis-lnx.centricconsulting.com> Message-ID: <1106666799.28420.110.camel@bree.local.net> On Tue, 2005-01-25 at 09:47 -0500, David Hollis wrote: > On Tue, 2005-01-25 at 00:03 -0500, Jeremy Katz wrote: > > Next, let's create a file to use as the backing for our Fedora install. > > For example purposes, I'll create one of a size of 1 GB. > > dd if=/dev/zero of=/root/fedora.img bs=1M count=1024 > > To make a sparse file, I used: > dd if=/dev/zero of=fedora.img bs=1M count=1 seek=1024 > > This way, my file looked like 1GB, but only allocated space upon use. Very reasonable, thanks. Will add to what goes up on the website (or more likely, the wiki as Seth suggested) > > Now, create an ext3 filesystem on this image. > > mke2fs -F -j /root/fedora.img > > You should now be able to mount your new temporary rootfs on a temporary > > mountpoint, say /mnt > > mount -o loop /root/fedora.img /mnt > > Now, we can install whatever basesystem we want into this chroot. Make > > sure that your yum configuration points to a valid repository. Then, > > decide what group(s) you want to install. I'd recommend starting with > > Base (or for the space constrained, Core, but this is more difficult). > > Then, run > > yum --installroot=/mnt -y groupinstall Base > > > > Cool trick! Didn't know that I could do that! I did find that I needed > to 'rpm --root /mnt --import to make yum happy. > I also needed to create /mnt/var/cache/yum so that it could write > the .gpgkeyschecked.yum file. I suppose that if I turned off gpg > checking, I would have been fine. Hmmm, makes sense. I run with gpgchecking disabled since I'm always running the devel tree and pulling from an internal tree :) I'll see how this is with yum 2.1.13 (which I built half an hour ago) and if needed, add a note about it. > > Come back and if everything went okay, you'll have a minimal install > > in /mnt. Now, for the ugly part, we need to set up some basic bits on > > the filesystem that have to be different for xen right now. These > > include a) creating some required device nodes in /dev > > since we're not using an initrd and b) setting up an /etc/fstab > > for i in console null zero ; do MAKEDEV -d /mnt -x $i ; done > > > > for i in console null zero; do MAKEDEV -d /mnt/dev -x $i ; done > > Otherwise, those device files end up in / instead /dev on the filesystem > image. Erk, wonder how I lost that in cutting and pasting. > > For the /etc/fstab, something simple like the following should work [snip] > Would it be necessary to have /sys in fstab? The initscripts mount it > automagically themselves. Haven't performed any testing myself to > validate with a Xen config. Probably not necessary, but trying to get things looking as much like a freshly installed system as possible. And fresh installs write sysfs out. Thanks for the feedback. Jeremy From feliciano.matias at free.fr Tue Jan 25 15:30:36 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 25 Jan 2005 16:30:36 +0100 Subject: loop device creation [was Re: udev: Directory for custom device nodes.] In-Reply-To: <20050125150446.GF7619@angus.ind.WPI.EDU> References: <20050125150446.GF7619@angus.ind.WPI.EDU> Message-ID: <1106667036.9957.59.camel@one.myworld> Le mardi 25 janvier 2005 ? 10:04 -0500, Charles R. Anderson a ?crit : > On Tue, Jan 25, 2005 at 12:45:41PM +0100, Harald Hoyer wrote: > > tty1 tty2 tty3 tty4 tty5 tty6 loop0 loop1 loop2 loop3 loop4 loop5 loop6 > > loop7 lp0 lp1 lp2 lp3 parport0 parport1 parport2 parport3 net/tun ppp > > console null zero > > Why doesn't the loop module cause /dev/loop* device node creation at > load time? E.g. I have in /etc/modprobe.conf: > > options loop max_loop=128 > > and /etc/fstab I have many of these: > > /iso/FC3-i386-DVD.iso /mnt/heidelberg-i386-DVD iso9660 ro,loop=/dev/loop59,nosuid,nodev 0 0 > > Shouldn't rc.sysinit's "mount -a" cause all the loop devices to be > created automatically? > > It seems to not work at boot time, but later a manual "mount -a" does > create the devices... At boot time, loop module is not loaded. After your "mount -a", loop is loaded and nodes are created. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From harald at redhat.com Tue Jan 25 15:31:40 2005 From: harald at redhat.com (Harald Hoyer) Date: Tue, 25 Jan 2005 16:31:40 +0100 Subject: loop device creation [was Re: udev: Directory for custom device nodes.] In-Reply-To: <20050125150446.GF7619@angus.ind.WPI.EDU> References: <20050125150446.GF7619@angus.ind.WPI.EDU> Message-ID: <41F6665C.6030007@redhat.com> Charles R. Anderson wrote: > On Tue, Jan 25, 2005 at 12:45:41PM +0100, Harald Hoyer wrote: > >>tty1 tty2 tty3 tty4 tty5 tty6 loop0 loop1 loop2 loop3 loop4 loop5 loop6 >>loop7 lp0 lp1 lp2 lp3 parport0 parport1 parport2 parport3 net/tun ppp >>console null zero > > > Why doesn't the loop module cause /dev/loop* device node creation at > load time? E.g. I have in /etc/modprobe.conf: > > options loop max_loop=128 > > and /etc/fstab I have many of these: > > /iso/FC3-i386-DVD.iso /mnt/heidelberg-i386-DVD iso9660 ro,loop=/dev/loop59,nosuid,nodev 0 0 > > Shouldn't rc.sysinit's "mount -a" cause all the loop devices to be > created automatically? > > It seems to not work at boot time, but later a manual "mount -a" does > create the devices... > The loop module gets autoloaded by accessing /dev/loop. A program (mount) would have to load the module, if it wants /dev/loop* and wait for udev to create the device. We could load the loop device on system startup, but you may not want to have loaded "every" module, you could possibly use in one session. From fedora at wir-sind-cool.org Tue Jan 25 15:32:51 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Tue, 25 Jan 2005 16:32:51 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <1106666516.25972.16.camel@opus.phy.duke.edu> References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <1106661197.23277.81.camel@cutter> <20050125161043.6bb64de2.fedora@wir-sind-cool.org> <1106665896.25972.12.camel@opus.phy.duke.edu> <36556.10.10.10.28.1106666279.squirrel@linux1> <1106666516.25972.16.camel@opus.phy.duke.edu> Message-ID: <20050125163251.3f6a49ac.fedora@wir-sind-cool.org> On Tue, 25 Jan 2005 10:21:56 -0500, seth vidal wrote: > > > Is there a good reason it shouldn't be used to mark packages as obsoleting > > others? > > If so, what is it? > > For right now? mostly b/c it's just obsoleting an old version - not a > change of package name. > > we shouldn't use obsoletes to do what a normal version update should do. We don't. This is still about libfoo obsoletes libfoo10 isn't it? From rahulsundaram at gmail.com Tue Jan 25 15:39:33 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Tue, 25 Jan 2005 21:09:33 +0530 Subject: rawhide report: 20050121 changes In-Reply-To: <5cf776b8050125071534da28f0@mail.gmail.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410993.15391.42.camel@jdub.homelinux.org> <5cf776b8050123075072835f89@mail.gmail.com> <1106498904.6129.46.camel@laptopd505.fenrus.org> <5cf776b80501231525cec0502@mail.gmail.com> <5cf776b8050125071534da28f0@mail.gmail.com> Message-ID: On Tue, 25 Jan 2005 11:15:58 -0400, mbneto wrote: > Ok. But since I was not able to remove myself (due to > dependencies...) the packages to this ~300Mb I was hoping I could get > (off list) the rpm -qa to compare with mine and simply remove the ones > missing.. I had the impression arjan seems to have to just highlighted that its possible and not that he has a list of packages ready to send you. -- Regards, Rahul Sundaram From kyrre at solution-forge.net Tue Jan 25 15:41:14 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 25 Jan 2005 16:41:14 +0100 Subject: HAL ejects In-Reply-To: References: <1106639336.29380.9.camel@localhost.localdomain> <1106645834.19325.2.camel@localhost.localdomain> Message-ID: <1106667674.2657.6.camel@localhost.localdomain> tir, 25.01.2005 kl. 15.48 skrev Paul Ionescu: > Hi, > > On Tue, 25 Jan 2005 10:37:14 +0100, Peter Backlund wrote: > > >> It is already in FC3 > >> I am using it right now. > >> I think it is not in HAL, but in GVM. However, to be able to use it, you > >> have to disable "lock on mount" option of cdrom by "echo 0 > > >> /proc/sys/dev/cdrom/lock" or putting "dev.cdrom.lock = 0" in > >> /etc/sysctl.conf and reloading with sysctl -p. > > > > Well, that's fantastic. Why isn't this enabled by default? > > > > /Peter > > I don't really know, maybe some people like it the old unix way ? > I don't have any kids yet, that tend to press any buttons to see what > might happen (see Dee Dee), so for me it is easier to press the eject > cdrom button, and actually it ejects, instead of nothing. > Anyway, I think this should be an option in gvm. Hmm.. People liking it "the old unix way" shouln't have any troubles about the eject button, should they? Making it an option could make things really easier for some newbies. And i can accutally then give my mother a understandable explanation about how to eject a cdrom. From kyrre at solution-forge.net Tue Jan 25 15:48:23 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 25 Jan 2005 16:48:23 +0100 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106645548.7318.5.camel@linux.local> References: <1106629396.28420.92.camel@bree.local.net> <1106645548.7318.5.camel@linux.local> Message-ID: <1106668102.2657.9.camel@localhost.localdomain> tir, 25.01.2005 kl. 10.32 skrev Hans Kristian Rosbach: > On Tue, 2005-01-25 at 06:03, Jeremy Katz wrote: > > As some people have noticed, Xen is now available from the Fedora > > development repository. More information on Xen itself can be found at > > http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html. We're > > following the -unstable Xen tree at the moment which does occasionally > > lead to things being broken but also lets us track a lot of the more > > interesting work going on there. Since setting up to run Xen isn't > > entirely straight-forward, here's a run-through of what should work for > > setting up a single Xen guest running the Fedora development tree. > > *snip* > > Wow, that is an excellent guide! > It seems so much simpler now =) > > This means I'll have to increase "Test XEN" priority on my TODO list. > > -HK Yup. And i will guess this will make testing the fc5 beta's *much* simpler! (even if HW won't be tested...) From feliciano.matias at free.fr Tue Jan 25 15:48:28 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 25 Jan 2005 16:48:28 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <1106664597.18134.0.camel@dcbw.boston.redhat.com> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> <1106660334.9957.43.camel@one.myworld> <1106664597.18134.0.camel@dcbw.boston.redhat.com> Message-ID: <1106668108.9957.76.camel@one.myworld> Le mardi 25 janvier 2005 ? 09:49 -0500, Dan Williams a ?crit : > On Tue, 2005-01-25 at 14:38 +0100, F?liciano Matias wrote: > > Suppose I want to package the mga_vid driver, I'll use : > > /etc/makedev.d/mga_vid # /dev/mga_vid definition > > /etc/sysconfig/init-dev.d/mga_vid.dev # create /dev/mga_vid > > /etc/sysconfig/init-dev.d/mga_vid.module # load mga_vid > > /etc/modprobe.conf.d/mga_vid.conf # configure mga_vid > > /etc/security/console.perms.d/mga_vid # pam_console configuration > > Does it seem utterly _pathetic_ to anyone else but me that there would > have to be 5 different places to add information about a particular > hardware device, just to get it to load and work? Just a point of > observation. Do you prefer hacks and "Ooops" in order to configure /etc/modprobe.conf, /etc/rc.d/rc.local, /etc/security/console.perms ? If the driver support udev, doesn't need configuration, do not need pam_console, can be auto-loaded, ... all this stuff is useless. But sometimes... You know, the "real world". > On Tue, 2005-01-25 at 14:38 +0100, F?liciano Matias wrote: > > Suppose I want to package the mga_vid driver, I'll use : Now suppose /etc/modprobe.conf.d/, /etc/sysconfig/init-dev.d/, ... exist and I created a rpm package for mga_vid. Just install it and enjoy. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From n3npq at nc.rr.com Tue Jan 25 15:56:17 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Tue, 25 Jan 2005 10:56:17 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <20050125161043.6bb64de2.fedora@wir-sind-cool.org> References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <1106661197.23277.81.camel@cutter> <20050125161043.6bb64de2.fedora@wir-sind-cool.org> Message-ID: <41F66C21.50401@nc.rr.com> Michael Schwendt wrote: >On Tue, 25 Jan 2005 08:53:17 -0500, seth vidal wrote: > > > >>>Sounds interesting. On the other hand, maybe we could do it manually (from a >>>packager's point of view) : if you package library foo, and you know that >>>version 0.1 is not supported anymore (noone knows that better than you >>>since you maintain it), you can add an Obsoletes tag to your libfoo5 >>>package, and force the removal. >>>Would that solve Jeff's issue ? >>> >>> >>> >>Obsoletes should be used when a package changes name. Not when someone >>thinks a new version gets rid of an old version. >> >> > >Where are such strict semantics of the "Obsoletes" field defined? > > The strict semantics are hard coded in up2date and yum, for starters, hard coded is strict enough for me. >Isn't it rather free to use? As in "we don't need that package >any longer, it's obsolete and can be erased"? > > Sure, feel free to do whatever. Without well defined packaging guidelines, packages will break, but reports will be filed, packages will be fixed and, life as usual. >If, for instance, functionality of one package is supplied by another >package, that's not a rename, but a relocation of package >capabilities. Package "foo" would "Obsoletes: bar <= 1.0". If an old >library API/ABI is not used anymore and hence considered obsolete, a >new version of the library could "Obsolete: libfoo <= 0.9" just fine. > > Obsoletes: has changed to erase a package that contains a virtual provides for exactly this reason. In fact, dependency comparisons don't use package NEVR at all several years now in order to handle functionality shifts that are not package renames. 73 de Jeff From kyrre at solution-forge.net Tue Jan 25 15:56:22 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 25 Jan 2005 16:56:22 +0100 Subject: slow hard drives crushing interactivity In-Reply-To: <1106640790.4341.3.camel@galvatron.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> <1106640790.4341.3.camel@galvatron.localdomain> Message-ID: <1106668581.2657.14.camel@localhost.localdomain> tir, 25.01.2005 kl. 09.13 skrev Sitsofe Wheeler: > On Mon, 2005-01-24 at 18:01 -0500, Havoc Pennington wrote: > > Hi, > > > > On my IBM X31 laptop, the system entirely locks up when there's a lot of > > disk access, some common situations are: > > - when getting heavily into swap due to a runaway process > > - when running rpm/yum > > > > It's not *technically* locked up (i.e. if you wait long enough it will > > come back) but in practice you have to reboot if a process has a memory > > leak, and you can't do any work while running yum. > > This is actually an already reported bug (although the reported one was > concerned with what openoffice would do to a system when it forced > swap): > https://bugzilla.redhat.com/beta/show_bug.cgi?id=142809 > yup. OO went overboard for me yesterday. It finally (after using up all my ram (381 MB) and 768 MB's of swap, took about 10-15 minutes...) got killed by the OOM-killer (which somehow *STARTED* with killing off evolution, firefox, gaim, azureus ETC, not the real culprit - OpenOffice). All i did was right-click a mispelled word! Well, at least it got me to comment out about 95% of the dictionary list (which i have had on my "todo" list for a long time now). But why where all the languages listed twice? Kyrre From rahulsundaram at gmail.com Tue Jan 25 15:56:35 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Tue, 25 Jan 2005 21:26:35 +0530 Subject: udev: Directory for custom device nodes. In-Reply-To: <1106668108.9957.76.camel@one.myworld> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> <1106660334.9957.43.camel@one.myworld> <1106664597.18134.0.camel@dcbw.boston.redhat.com> <1106668108.9957.76.camel@one.myworld> Message-ID: HI > > Now suppose /etc/modprobe.conf.d/, /etc/sysconfig/init-dev.d/, ... exist > and I created a rpm package for mga_vid. replace /etc/sysconfig/init-dev.d/ with /etc/udev/init-dev.d and this looks more good to me -- Regards, Rahul Sundaram From dwmw2 at infradead.org Tue Jan 25 15:59:14 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 25 Jan 2005 15:59:14 +0000 Subject: rawhide report: 20050121 changes In-Reply-To: <1106322108.31381.35.camel@support02.civic.twp.ypsilanti.mi.us> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> <1106322108.31381.35.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1106668755.26551.657.camel@hades.cambridge.redhat.com> On Fri, 2005-01-21 at 10:41 -0500, Sean Middleditch wrote: > gedit's speed in this case would not > affect GTK emacs, since emacs would be _just_ a GTK program, and not > depend on all the GNOME stuff (like gnome-vfs) that gedit does. As long as it doesn't use the GNOME file dialog box, then nobody has to die. -- dwmw2 From rahulsundaram at gmail.com Tue Jan 25 16:03:22 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Tue, 25 Jan 2005 21:33:22 +0530 Subject: HAL ejects In-Reply-To: <1106667674.2657.6.camel@localhost.localdomain> References: <1106639336.29380.9.camel@localhost.localdomain> <1106645834.19325.2.camel@localhost.localdomain> <1106667674.2657.6.camel@localhost.localdomain> Message-ID: Hi > > Hmm.. People liking it "the old unix way" shouln't have any troubles > about the eject button, should they? maybe they wouldnt consider it safe or something. Making it an option could make > things really easier for some newbies. And i can accutally then give my > mother a understandable explanation about how to eject a cdrom. > file a RFE requesting that this be a option in g-v-m and suggest that it be enabled by default -- Regards, Rahul Sundaram From hp at redhat.com Tue Jan 25 16:04:34 2005 From: hp at redhat.com (Havoc Pennington) Date: Tue, 25 Jan 2005 11:04:34 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <20050125050425.GK4047@nostromo.devel.redhat.com> References: <1106607715.6122.21.camel@localhost.localdomain> <20050125050425.GK4047@nostromo.devel.redhat.com> Message-ID: <1106669074.7068.86.camel@localhost.localdomain> On Tue, 2005-01-25 at 00:04 -0500, Bill Nottingham wrote: > Havoc Pennington (hp at redhat.com) said: > > Maybe a cap on process size, so there can be 1G virtual memory but an > > individual app can only use 512M? Maybe when a process reaches 512M we > > could suspend it and ask the user whether to > > let it grow further? > > You can set rlimits; you can also turn off overcommit. Doesn't help > the yum/rpm case, of course. Can we do either of those things by default/automatically in appropriate cases? Havoc From david at fubar.dk Tue Jan 25 16:07:34 2005 From: david at fubar.dk (David Zeuthen) Date: Tue, 25 Jan 2005 11:07:34 -0500 Subject: HAL ejects In-Reply-To: References: <1106639336.29380.9.camel@localhost.localdomain> Message-ID: <1106669254.4166.31.camel@daxter.boston.redhat.com> On Tue, 2005-01-25 at 11:01 +0200, Paul Ionescu wrote: > Hi, > > On Tue, 25 Jan 2005 08:48:56 +0100, Peter Backlund wrote: > > Here's something I'd like to see in FC4: unmount-on-eject via HAL. I'm > > talking about automatic unmounting CD/DVD when you press the eject button, > > like the ancient "supermount". Is this within the scope of HAL? Most drives don't report "eject button pressed" asynchronously - some HP drives do, some others as well, but not a lot. We *could* make hal catch this signal (if the drive supports it) and propagate it all the way of the stack; it would look like this 1. Eject is pressed; door doesn't open 2. (up to 0.999.. seconds later) hald is notified that someone pressed eject; hald broadcasts a signal 3. gnome-vfs (or whatever) catches the signal and sends out the preunmount signals 4. apps close their open files and ACK's the preunmount 5. gnome-vfs unmounts the drive; if there are still apps with open fd's the unmount fails. gnome-vfs puts up nice dialog. 6. door is unlocked; disc is ejected But since only few drives support this I'm not happy about providing two different user experiences. > It is already in FC3 > I am using it right now. > I think it is not in HAL, but in GVM. > However, to be able to use it, you have to disable "lock on mount" option > of cdrom by "echo 0 > /proc/sys/dev/cdrom/lock" > or putting "dev.cdrom.lock = 0" in /etc/sysctl.conf and reloading with > sysctl -p. > No, that's bad advice. What happens in that setup is the following 1. Eject is pressed; door opens 2. hald polls for media; oops no media 3. hald lazy unmounts /dev/cdrom - the media is gone so we have to deal with it somehow; it's better than doing nothing 4. all your programs with open fd's on /media/cdrom is screwed It's get even more fun if you're writing to the CD. The real solution is to use something along the lines of volumagic which is like supermount but only in userspace. David From elanthis at awesomeplay.com Tue Jan 25 16:08:53 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Tue, 25 Jan 2005 11:08:53 -0500 Subject: rawhide report: 20050121 changes In-Reply-To: <1106668755.26551.657.camel@hades.cambridge.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318657.9659.7.camel@dcbw.boston.redhat.com> <87r7ke3jyb.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106321359.30800.7.camel@localhost.localdomain> <1106322108.31381.35.camel@support02.civic.twp.ypsilanti.mi.us> <1106668755.26551.657.camel@hades.cambridge.redhat.com> Message-ID: <1106669333.10097.8.camel@support02.civic.twp.ypsilanti.mi.us> On Tue, 2005-01-25 at 15:59 +0000, David Woodhouse wrote: > On Fri, 2005-01-21 at 10:41 -0500, Sean Middleditch wrote: > > gedit's speed in this case would not > > affect GTK emacs, since emacs would be _just_ a GTK program, and not > > depend on all the GNOME stuff (like gnome-vfs) that gedit does. > > As long as it doesn't use the GNOME file dialog box, then nobody has to > die. There's no such thing as a GNOME file dialog box. Both the old one and the new one are pure GTK widgets. GNOME apps just hook in gnome-vfs to allow users to access all the remote shares they expect their apps to be able to access. > > -- > dwmw2 > From jfontain at free.fr Tue Jan 25 16:18:07 2005 From: jfontain at free.fr (jfontain at free.fr) Date: Tue, 25 Jan 2005 17:18:07 +0100 Subject: stock kernel 2.6.10 reboots after selinux Message-ID: <1106669887.41f6713f51b7b@imp2-q.free.fr> I tried to recompile the stock 2.6.10 kernel (from kernel.org, no patches) on my IBM X40 laptop (very nice machine by the way), by copying the stock .config from the latest Fedora kernel and pruning a few harwdare items that obviously do not exist on my PC. When I boot, I get a bunch of selinux messages, then immediately after a "Restarting system..." message, which indeed does what it says... This is not very important, so please do not spend time on this, but if you could point the right direction in my research for solving this problem... Many thanks in advance, -- Jean-Luc From feliciano.matias at free.fr Tue Jan 25 16:20:15 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 25 Jan 2005 17:20:15 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> <1106660334.9957.43.camel@one.myworld> <1106664597.18134.0.camel@dcbw.boston.redhat.com> <1106668108.9957.76.camel@one.myworld> Message-ID: <1106670015.9957.87.camel@one.myworld> Le mardi 25 janvier 2005 ? 21:26 +0530, Rahul Sundaram a ?crit : > HI > > > > Now suppose /etc/modprobe.conf.d/, /etc/sysconfig/init-dev.d/, ... exist > > and I created a rpm package for mga_vid. > > replace /etc/sysconfig/init-dev.d/ with /etc/udev/init-dev.d and this > looks more good to me > /etc/udev/init-dev.d is /etc/udev/devices/ and it already exist. But it "sucks". /etc/sysconfig/init-dev.d/ will be used by start_udev (AFAIK) and start_udev is called at boot time by /etc/rc.d/rc.sysinit. So for me /etc/sysconfig/... is the right place (until there is something upstream). Note that udev (the daemon) does not use /sbin/start_udev nor /etc/udev/devices/ . These files do not configure udev. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From katzj at redhat.com Tue Jan 25 16:24:45 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 25 Jan 2005 11:24:45 -0500 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106660563.23277.77.camel@cutter> References: <1106629396.28420.92.camel@bree.local.net> <1106660319.28420.100.camel@bree.local.net> <1106660563.23277.77.camel@cutter> Message-ID: <1106670285.28420.126.camel@bree.local.net> On Tue, 2005-01-25 at 08:42 -0500, seth vidal wrote: > > The plan is to put it up, although possibly not under the docs heading. > > What's described here is mostly the quickstart for starting to use Xen > > today. Some of the things that I alluded to at the end will make it far > > less relevant over the course of the next month or so. So I'd prefer to > > wait until a more final state before calling them docs :) > > Post it on the fedoraproject.org wiki or in some other location there - > then people can easily link to it, if you want. Good idea, now available at http://www.fedoraproject.org/wiki/FedoraXenQuickstart Jeremy From feliciano.matias at free.fr Tue Jan 25 16:24:32 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 25 Jan 2005 17:24:32 +0100 Subject: udev: Directory for custom device nodes. In-Reply-To: <20050125145001.GD6440@nostromo.devel.redhat.com> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> <1106660334.9957.43.camel@one.myworld> <20050125145001.GD6440@nostromo.devel.redhat.com> Message-ID: <1106670272.9957.93.camel@one.myworld> Le mardi 25 janvier 2005 ? 09:50 -0500, Bill Nottingham a ?crit : > F?liciano Matias (feliciano.matias at free.fr) said: > > There is one piece missing "in my dream" : > > /etc/security/console.perms.d/mga_vid > > where I can add "=/dev/mga_vid". > > This will get done with HAL in the future, FWIW. > You mean HAL will replace or work with pam_console ? Just an example. With mga_vid and a kernel with framebuffer enabled, I can login in a console (not X11) and launch : $ mplayer -vo mga dvd:// With X11 I use "mplayer -vo xmga ..." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ville.skytta at iki.fi Tue Jan 25 16:28:23 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Tue, 25 Jan 2005 18:28:23 +0200 Subject: udev: Directory for custom device nodes. In-Reply-To: <20050125145001.GD6440@nostromo.devel.redhat.com> References: <41E25EBD.3040800@redhat.com> <20050110215600.GC16171@nostromo.devel.redhat.com> <41E65422.1070409@redhat.com> <1105617996.5578.5.camel@wombat.tiptoe.de> <41E6937F.2070904@redhat.com> <41F63165.6000405@redhat.com> <1106660334.9957.43.camel@one.myworld> <20050125145001.GD6440@nostromo.devel.redhat.com> Message-ID: <1106670503.21005.16.camel@bobcat.mine.nu> On Tue, 2005-01-25 at 09:50 -0500, Bill Nottingham wrote: > F?liciano Matias (feliciano.matias at free.fr) said: > > There is one piece missing "in my dream" : > > /etc/security/console.perms.d/mga_vid > > where I can add "=/dev/mga_vid". > > This will get done with HAL in the future, FWIW. Excellent. Any estimates to what "future" in this context expands to? From rahulsundaram at gmail.com Tue Jan 25 16:37:22 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Tue, 25 Jan 2005 22:07:22 +0530 Subject: stock kernel 2.6.10 reboots after selinux In-Reply-To: <1106669887.41f6713f51b7b@imp2-q.free.fr> References: <1106669887.41f6713f51b7b@imp2-q.free.fr> Message-ID: On Tue, 25 Jan 2005 17:18:07 +0100, jfontain at free.fr wrote: > I tried to recompile the stock 2.6.10 kernel (from kernel.org, no patches) on my > IBM X40 laptop (very nice machine by the way), by copying the stock .config from > the latest Fedora kernel and pruning a few harwdare items that obviously do not > exist on my PC. it seems that the fedora kernel contains a backported patch from 2.6.10-rc1 for selinux support in tmpfs and you either need to apply that or turn off selinux temporariy -- Regards, Rahul Sundaram From rahulsundaram at gmail.com Tue Jan 25 16:38:54 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Tue, 25 Jan 2005 22:08:54 +0530 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106670285.28420.126.camel@bree.local.net> References: <1106629396.28420.92.camel@bree.local.net> <1106660319.28420.100.camel@bree.local.net> <1106660563.23277.77.camel@cutter> <1106670285.28420.126.camel@bree.local.net> Message-ID: Hi > > Good idea, now available at > http://www.fedoraproject.org/wiki/FedoraXenQuickstart thanks -- Regards, Rahul Sundaram From alan at redhat.com Tue Jan 25 16:52:04 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 25 Jan 2005 11:52:04 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <1106669074.7068.86.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> <20050125050425.GK4047@nostromo.devel.redhat.com> <1106669074.7068.86.camel@localhost.localdomain> Message-ID: <20050125165204.GB17028@devserv.devel.redhat.com> On Tue, Jan 25, 2005 at 11:04:34AM -0500, Havoc Pennington wrote: > > You can set rlimits; you can also turn off overcommit. Doesn't help > > the yum/rpm case, of course. > > Can we do either of those things by default/automatically in appropriate > cases? > We should be shipping with overcommit off by default, but I've been saying that for years too 8. You can just drop it into /etc/sysctl.conf From bclark at redhat.com Tue Jan 25 16:52:07 2005 From: bclark at redhat.com (Bryan Clark) Date: Tue, 25 Jan 2005 11:52:07 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <1106668581.2657.14.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> <1106640790.4341.3.camel@galvatron.localdomain> <1106668581.2657.14.camel@localhost.localdomain> Message-ID: <1106671927.3836.5.camel@rhbw.boston.redhat.com> On Tue, 2005-01-25 at 16:56 +0100, Kyrre Ness Sjobak wrote: > yup. OO went overboard for me yesterday. It finally (after using up all > my ram (381 MB) and 768 MB's of swap, took about 10-15 minutes...) got > killed by the OOM-killer (which somehow *STARTED* with killing off > evolution, firefox, gaim, azureus ETC, not the real culprit - > OpenOffice). > > All i did was right-click a mispelled word! > > Well, at least it got me to comment out about 95% of the dictionary list > (which i have had on my "todo" list for a long time now). But why where > all the languages listed twice? I think that's related to this openoffice bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124374 From remco at rvt.com Tue Jan 25 16:59:18 2005 From: remco at rvt.com (Remco Treffkorn) Date: Tue, 25 Jan 2005 08:59:18 -0800 Subject: Packet Inspection In-Reply-To: References: <41F5303D.8050305@israel-jugendtag.ch> Message-ID: <200501250859.18934.remco@rvt.com> On Monday 24 January 2005 14:06, Kenneth Porter wrote: ... > they realize you mean IP packets and not RPM packages. I notice a lot of > people using "package" instead of "packet" and wonder if this > mistranslation is coming from some particular source? How did you come to > use the term "package"? Maybe we can go upstream and get the usage > corrected. (Mind you, I'm a dumb provincial American so I only speak one > language, and this isn't meant as an insult to those of you smart enough to > take on English in addition to your native language.) Very observant. Both 'package' and 'packet' translate into German as 'Packet'. This creates funny problems along the same lines as 'free' does. German has two words for it. One meaning free as in freedom, another one for free as in beer. -- Remco Treffkorn (RT445) HAM DC2XT remco at rvt.com (831) 685-1201 From d.lesca at solinos.it Tue Jan 25 17:16:15 2005 From: d.lesca at solinos.it (Dario Lesca) Date: Tue, 25 Jan 2005 18:16:15 +0100 Subject: Please Help!: Server crash whit kernel BUG at lib/radix-tree.c Message-ID: <1106673374.2722.144.camel@lesca.home.solinos.it> Hi, and sorry for my bad english :-( It is possible, from the follow info take from /var/log/message after a system crash, know why my server crash ? --------------------------------- Jan 25 11:18:00 payprox kernel: ------------[ cut here ]------------ Jan 25 11:18:00 payprox kernel: kernel BUG at lib/radix-tree.c:575! Jan 25 11:18:00 payprox kernel: invalid operand: 0000 [#1] Jan 25 11:18:00 payprox kernel: SMP Jan 25 11:18:00 payprox kernel: Modules linked in: ipt_limit loop tun md5 ipv6 autofs4 i2c_dev i2c_core ipt_TOS ipt_MASQUERADE ipt_REDIRECT ipt_REJECT ipt_pkttype ipt_LOG ipt_state ipt_multiport ipt_conntrack iptable_mangle ip_nat_irc ip_nat_tftp ip_nat_ftp iptable_nat ip_conntrack_irc ip_conntrack_tftp ip_conntrack_ftp ip_conntrack iptable_filter ip_tables sunrpc button battery ac uhci_hcd ehci_hcd snd_via82xx snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore r8169 via_rhine mii sk98lin floppy dm_snapshot dm_zero dm_mirror xfs dm_mod sata_via libata i2o_block i2o_core sd_mod scsi_mod Jan 25 11:18:00 payprox kernel: CPU: 1 Jan 25 11:18:00 payprox kernel: EIP: 0060:[] Not tainted VLI Jan 25 11:18:00 payprox kernel: EFLAGS: 00010046 (2.6.9-1.724_FC3smp) Jan 25 11:18:00 payprox kernel: EIP is at __lookup_tag+0x5e/0x108 Jan 25 11:18:00 payprox kernel: eax: ffffffff ebx: 80000000 ecx: 00000020 edx: 00000000 Jan 25 11:18:00 payprox kernel: esi: c15be900 edi: 01000000 ebp: 00000000 esp: f7c63de8 Jan 25 11:18:00 payprox kernel: ds: 007b es: 007b ss: 0068 Jan 25 11:18:00 payprox kernel: Process pdflush (pid: 47, threadinfo=f7c63000 task=f7c32130) Jan 25 11:18:00 payprox kernel: Stack: 05fffffa f8ae1b04 00000020 00000000 f7c63eac 00000000 0000000e d95dc870 Jan 25 11:18:00 payprox kernel: dc6cc6ac c01b29c2 0000000e f7c63e20 00000000 f7c63eac 00001000 00000000 Jan 25 11:18:00 payprox kernel: d95dc86c f7c63eac f7c63e94 c013a957 0000000e 00000000 f7c63e94 f7c63ea4 Jan 25 11:18:00 payprox kernel: Call Trace: Jan 25 11:18:00 payprox kernel: [] _pagebuf_ioapply+0x288/0x290 [xfs] Jan 25 11:18:00 payprox kernel: [] radix_tree_gang_lookup_tag+0x3d/0x53 Jan 25 11:18:00 payprox kernel: [] find_get_pages_tag+0x28/0x66 Jan 25 11:18:00 payprox kernel: [] pagevec_lookup_tag+0x1b/0x22 Jan 25 11:18:00 payprox kernel: [] mpage_writepages+0x2bb/0x314 Jan 25 11:18:00 payprox kernel: [] xfs_bdstrat_cb+0x35/0x38 [xfs] Jan 25 11:18:00 payprox kernel: [] linvfs_writepage+0x0/0xc6 [xfs] Jan 25 11:18:00 payprox kernel: [] xfs_inode_flush+0x1bd/0x1c9 [xfs] Jan 25 11:18:00 payprox kernel: [] find_busiest_group+0xf1/0x2df Jan 25 11:18:00 payprox kernel: [] __sync_single_inode+0x5f/0x1c0 Jan 25 11:18:00 payprox kernel: [] sync_sb_inodes+0x1a7/0x274 Jan 25 11:18:00 payprox kernel: [] pdflush+0x0/0x1e Jan 25 11:18:00 payprox kernel: [] writeback_inodes+0x91/0xde Jan 25 11:18:00 payprox kernel: [] wb_kupdate+0x7b/0xde Jan 25 11:18:00 payprox kernel: [] __pdflush+0xec/0x180 Jan 25 11:18:00 payprox kernel: [] pdflush+0x1a/0x1e Jan 25 11:18:00 payprox kernel: [] wb_kupdate+0x0/0xde Jan 25 11:18:00 payprox kernel: [] pdflush+0x0/0x1e Jan 25 11:18:00 payprox kernel: [] kthread+0x73/0x9b Jan 25 11:18:00 payprox kernel: [] kthread+0x0/0x9b Jan 25 11:18:00 payprox kernel: [] kernel_thread_helper+0x5/0xb Jan 25 11:18:00 payprox kernel: Code: 83 e5 3f 89 6c 24 08 83 fd 3f 77 49 8b 54 24 30 8b 4c 24 08 8d 04 d6 0f a3 88 04 01 00 00 19 c0 85 c0 74 11 83 7c 8e 04 00 75 2a <0f> 0b 3f 02 3f 82 2d c0 eb 20 b8 01 00 00 00 0f b6 0c 24 d3 e0 Jan 25 16:22:48 payprox syslogd 1.4.1: restart. ---------- Now, after reboot, I get some of this OOPS...... Is a hardware problem? ----------------------------------------------- Jan 25 17:01:02 payprox kernel: Unable to handle kernel paging request at virtual address 01000004 Jan 25 17:01:02 payprox kernel: printing eip: Jan 25 17:01:02 payprox kernel: c015cf8a Jan 25 17:01:02 payprox kernel: *pde = 2e7ef001 Jan 25 17:01:02 payprox kernel: Oops: 0000 [#5] Jan 25 17:01:02 payprox kernel: SMP Jan 25 17:01:02 payprox kernel: Modules linked in: tun md5 ipv6 autofs4 ipt_TOS ipt_MASQUERADE ipt_REDIRECT ipt_REJECT ipt_pkttype ipt_LOG ipt_limit ipt_state ipt_multiport ipt_conntrack iptable_mangle ip_nat_irc ip_nat_tftp ip_nat_ftp iptable_nat ip_conntrack_irc ip_conntrack_tftp ip_conntrack_ftp ip_conntrack iptable_filter ip_tables sunrpc video button battery ac uhci_hcd ehci_hcd i2c_viapro i2c_core snd_via82xx snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore r8169 via_rhine mii sk98lin floppy dm_snapshot dm_zero dm_mirror xfs dm_mod sata_via libata i2o_block i2o_core sd_mod scsi_mod Jan 25 17:01:02 payprox kernel: CPU: 0 Jan 25 17:01:02 payprox kernel: EIP: 0060:[] Not tainted VLI Jan 25 17:01:02 payprox kernel: EFLAGS: 00010206 (2.6.10-1.741_FC3smp) Jan 25 17:01:02 payprox kernel: EIP is at link_path_walk+0x7c5/0xb9c Jan 25 17:01:02 payprox kernel: eax: c196b710 ebx: cbb0569d ecx: 00000000 edx: 01000000 Jan 25 17:01:02 payprox kernel: esi: c1972e50 edi: cbb0569d ebp: edd7af58 esp: edd7aec8 Jan 25 17:01:02 payprox kernel: ds: 007b es: 007b ss: 0068 Jan 25 17:01:02 payprox kernel: Process id (pid: 8018, threadinfo=edd7a000 task=f721e530) Jan 25 17:01:02 payprox kernel: Stack: c01453fb 00000000 ef5c4f28 eee22030 efbaaa6c f7fe8300 00000101 ef63a00c Jan 25 17:01:02 payprox kernel: c1968e00 c196b710 cbb0569d 00000006 ef63a006 00de53a4 edd7a000 edd7af58 Jan 25 17:01:02 payprox kernel: 000001b6 ef63a000 c015d674 ef63a000 00000000 000001b6 edd7af58 c015dcc0 Jan 25 17:01:02 payprox kernel: Call Trace: Jan 25 17:01:02 payprox kernel: [] handle_mm_fault+0xbd/0x175 Jan 25 17:01:02 payprox kernel: [] path_lookup+0x144/0x174 Jan 25 17:01:02 payprox kernel: [] open_namei+0x8d/0x58b Jan 25 17:01:02 payprox kernel: [] filp_open+0x23/0x3c Jan 25 17:01:02 payprox kernel: [] strncpy_from_user+0x37/0x56 Jan 25 17:01:02 payprox kernel: [] sys_open+0x31/0x7d Jan 25 17:01:02 payprox kernel: [] syscall_call+0x7/0xb Jan 25 17:01:02 payprox kernel: Code: c0 84 c0 74 07 89 d0 e8 a9 b3 00 00 89 1e e9 04 ff ff ff 89 ea 89 f0 e8 00 f7 ff ff e9 9a 03 00 00 8b 45 00 8b 50 48 85 d2 74 17 <8b> 4a 04 85 c9 74 10 8d 54 24 28 ff d1 85 c0 89 c3 0f 88 af 03 ------------------------------ Pleas, help me. Many thanks -- Dario Lesca From feliciano.matias at free.fr Tue Jan 25 17:19:54 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 25 Jan 2005 18:19:54 +0100 Subject: stock kernel 2.6.10 reboots after selinux In-Reply-To: References: <1106669887.41f6713f51b7b@imp2-q.free.fr> Message-ID: <1106673594.9957.97.camel@one.myworld> Le mardi 25 janvier 2005 ? 22:07 +0530, Rahul Sundaram a ?crit : > On Tue, 25 Jan 2005 17:18:07 +0100, jfontain at free.fr wrote: > > I tried to recompile the stock 2.6.10 kernel (from kernel.org, no patches) on my > > IBM X40 laptop (very nice machine by the way), by copying the stock .config from > > the latest Fedora kernel and pruning a few harwdare items that obviously do not > > exist on my PC. > > it seems that the fedora kernel contains a backported patch from > 2.6.10-rc1 for selinux support in tmpfs and you either need to apply > that or turn off selinux temporariy > jfontain should try the Alan Cox tree : http://www.kernel.org/pub/linux/kernel/people/alan/linux-2.6/2.6.10/ WARNING WARNING : Alan Cox works for Red Hat/Fedora :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From feliciano.matias at free.fr Tue Jan 25 17:24:46 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 25 Jan 2005 18:24:46 +0100 Subject: Please Help!: Server crash whit kernel BUG at lib/radix-tree.c In-Reply-To: <1106673374.2722.144.camel@lesca.home.solinos.it> References: <1106673374.2722.144.camel@lesca.home.solinos.it> Message-ID: <1106673886.9957.100.camel@one.myworld> Le mardi 25 janvier 2005 ? 18:16 +0100, Dario Lesca a ?crit : > Hi, and sorry for my bad english :-( > > It is possible, from the follow info take from /var/log/message after a > system crash, know why my server crash ? > > (...) > Jan 25 11:18:00 payprox kernel: [] _pagebuf_ioapply+0x288/0x290 [xfs] > (...) Too bad. Fedora does not support xfs. xfs is provided "as is". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dcbw at redhat.com Tue Jan 25 17:25:45 2005 From: dcbw at redhat.com (Dan Williams) Date: Tue, 25 Jan 2005 12:25:45 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <1106668581.2657.14.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> <1106640790.4341.3.camel@galvatron.localdomain> <1106668581.2657.14.camel@localhost.localdomain> Message-ID: <1106673945.16105.5.camel@dcbw.boston.redhat.com> On Tue, 2005-01-25 at 16:56 +0100, Kyrre Ness Sjobak wrote: > Well, at least it got me to comment out about 95% of the dictionary list > (which i have had on my "todo" list for a long time now). But why where > all the languages listed twice? Bug in the ooo-package-langs script upstream at ooo-build. However, the dictionary code shouldn't load the dictionary in more than once anyway. Later builds of OOo than you have 'cat dictionary.lst | sort | uniq' to get rid of this problem too. Dan From kyrre at solution-forge.net Tue Jan 25 17:42:33 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 25 Jan 2005 18:42:33 +0100 Subject: HAL ejects In-Reply-To: References: <1106639336.29380.9.camel@localhost.localdomain> <1106645834.19325.2.camel@localhost.localdomain> <1106667674.2657.6.camel@localhost.localdomain> Message-ID: <1106674952.2657.18.camel@localhost.localdomain> tir, 25.01.2005 kl. 17.03 skrev Rahul Sundaram: > Hi > > > > > Hmm.. People liking it "the old unix way" shouln't have any troubles > > about the eject button, should they? > > maybe they wouldnt consider it safe or something. > > Making it an option could make > > things really easier for some newbies. And i can accutally then give my > > mother a understandable explanation about how to eject a cdrom. > > > > file a RFE requesting that this be a option in g-v-m and suggest that > it be enabled by default Yeah-people wanting it "the old unix way" would know it is a tunable parameter. So i shall do that :) Just a thougth - what would happen if somebody should be as unlucky to push "eject" when there is an open file on the device? The message we all love (not!) would pop up? From d.lesca at solinos.it Tue Jan 25 17:43:10 2005 From: d.lesca at solinos.it (Dario Lesca) Date: Tue, 25 Jan 2005 18:43:10 +0100 Subject: Please Help!: Server crash whit kernel BUG at lib/radix-tree.c In-Reply-To: <1106673886.9957.100.camel@one.myworld> References: <1106673374.2722.144.camel@lesca.home.solinos.it> <1106673886.9957.100.camel@one.myworld> Message-ID: <1106674989.2722.149.camel@lesca.home.solinos.it> Il mar, 2005-01-25 alle 18:24, F?liciano Matias ha scritto: > Too bad. Fedora does not support xfs. xfs is provided "as is". therefore this can be the cause of my problem? I must change the type of filesystem xfs in ext3? Sig! I have install 15 servers whit this filesystem :-( -- Dario Lesca From feliciano.matias at free.fr Tue Jan 25 17:52:07 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 25 Jan 2005 18:52:07 +0100 Subject: Please Help!: Server crash whit kernel BUG at lib/radix-tree.c In-Reply-To: <1106674989.2722.149.camel@lesca.home.solinos.it> References: <1106673374.2722.144.camel@lesca.home.solinos.it> <1106673886.9957.100.camel@one.myworld> <1106674989.2722.149.camel@lesca.home.solinos.it> Message-ID: <1106675528.9957.103.camel@one.myworld> Le mardi 25 janvier 2005 ? 18:43 +0100, Dario Lesca a ?crit : > Il mar, 2005-01-25 alle 18:24, F?liciano Matias ha scritto: > > > Too bad. Fedora does not support xfs. xfs is provided "as is". > > therefore this can be the cause of my problem? Perhaps. I can not say more. > I must change the type of filesystem xfs in ext3? > > Sig! I have install 15 servers whit this filesystem :-( > > -- > Dario Lesca > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From kyrre at solution-forge.net Tue Jan 25 17:53:36 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 25 Jan 2005 18:53:36 +0100 Subject: slow hard drives crushing interactivity In-Reply-To: <1106671927.3836.5.camel@rhbw.boston.redhat.com> References: <1106607715.6122.21.camel@localhost.localdomain> <1106640790.4341.3.camel@galvatron.localdomain> <1106668581.2657.14.camel@localhost.localdomain> <1106671927.3836.5.camel@rhbw.boston.redhat.com> Message-ID: <1106675616.2657.26.camel@localhost.localdomain> tir, 25.01.2005 kl. 17.52 skrev Bryan Clark: > On Tue, 2005-01-25 at 16:56 +0100, Kyrre Ness Sjobak wrote: > > yup. OO went overboard for me yesterday. It finally (after using up all > > my ram (381 MB) and 768 MB's of swap, took about 10-15 minutes...) got > > killed by the OOM-killer (which somehow *STARTED* with killing off > > evolution, firefox, gaim, azureus ETC, not the real culprit - > > OpenOffice). > > > > All i did was right-click a mispelled word! > > > > Well, at least it got me to comment out about 95% of the dictionary list > > (which i have had on my "todo" list for a long time now). But why where > > all the languages listed twice? > > I think that's related to this openoffice bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124374 kinda seen that one, i have comment #7 :) There was some promise in it: """ Additional Comment #14 From Dan Williams (dcbw at redhat.com) on 2004-12-03 11:59 ------- As an update, new RPMS will take the dictionary.lst file and do a: cat dictionary.lst | sort | uniq """ Not yet... And those: """ ------- Additional Comment #7 From Kyrre Ness Sj?b?k (kyrsjo at solution-forge.net) on 2004-11-07 08:28 ------- Why not simply just install dictionaries for the languages selected to be installed in anaconda? Or better: only load the dictionary which is selected as the current language... I really don't care if a misspelled word happens to be correct in polish or welsh... I had the kernel kill off OO on a 320 MB + enough swap once... After five minutes of waiting. And yes, i lot my data. ------- Additional Comment #8 From Dan Williams (dcbw at redhat.com) on 2004-11-07 10:06 ------- Kyrre: because stuff isn't broken out by language yet. You can't do this unless there are additional packages for each language you wish to support. That's going to happen for FC4. The whole reason this started was because people whined about "I wan't my dictionary installed and working by default", which is fine, but not possible with a monolithic language package, which was being done for other reasons. This is targetted to be fixed for FC4 by splitting up -i18n into language packs. I'm working on finding a fix for FC3 that I hope to push as an update. Dan """ Yup. Ages ago. Btw. OpenOffice 1.1.4 is upstream - why are we still running 1.1.2 And some of the norwegian translation stuff is still in German... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137487 *complain complain* If there is anything i can do to help, like testing out some beta etc, i will be happy to do that. Any (resonably stable) OO testing versions (i.e upstream stable but not RH stable - if you understand my meaning. Rawhide etc.) From kyrre at solution-forge.net Tue Jan 25 17:55:57 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 25 Jan 2005 18:55:57 +0100 Subject: slow hard drives crushing interactivity In-Reply-To: <1106671927.3836.5.camel@rhbw.boston.redhat.com> References: <1106607715.6122.21.camel@localhost.localdomain> <1106640790.4341.3.camel@galvatron.localdomain> <1106668581.2657.14.camel@localhost.localdomain> <1106671927.3836.5.camel@rhbw.boston.redhat.com> Message-ID: <1106675674.2657.28.camel@localhost.localdomain> tir, 25.01.2005 kl. 17.52 skrev Bryan Clark: > On Tue, 2005-01-25 at 16:56 +0100, Kyrre Ness Sjobak wrote: > > yup. OO went overboard for me yesterday. It finally (after using up all > > my ram (381 MB) and 768 MB's of swap, took about 10-15 minutes...) got > > killed by the OOM-killer (which somehow *STARTED* with killing off > > evolution, firefox, gaim, azureus ETC, not the real culprit - > > OpenOffice). > > > > All i did was right-click a mispelled word! > > > > Well, at least it got me to comment out about 95% of the dictionary list > > (which i have had on my "todo" list for a long time now). But why where > > all the languages listed twice? > > I think that's related to this openoffice bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124374 kinda seen that one, i have comment #7 :) There was some promise in it: """ Additional Comment #14 From Dan Williams (dcbw at redhat.com) on 2004-12-03 11:59 ------- As an update, new RPMS will take the dictionary.lst file and do a: cat dictionary.lst | sort | uniq """ Not yet... And those: """ ------- Additional Comment #7 From Kyrre Ness Sj?b?k (kyrsjo at solution-forge.net) on 2004-11-07 08:28 ------- Why not simply just install dictionaries for the languages selected to be installed in anaconda? Or better: only load the dictionary which is selected as the current language... I really don't care if a misspelled word happens to be correct in polish or welsh... I had the kernel kill off OO on a 320 MB + enough swap once... After five minutes of waiting. And yes, i lot my data. ------- Additional Comment #8 From Dan Williams (dcbw at redhat.com) on 2004-11-07 10:06 ------- Kyrre: because stuff isn't broken out by language yet. You can't do this unless there are additional packages for each language you wish to support. That's going to happen for FC4. The whole reason this started was because people whined about "I wan't my dictionary installed and working by default", which is fine, but not possible with a monolithic language package, which was being done for other reasons. This is targetted to be fixed for FC4 by splitting up -i18n into language packs. I'm working on finding a fix for FC3 that I hope to push as an update. Dan """ Yup. Ages ago. Btw. OpenOffice 1.1.4 is upstream - why are we still running 1.1.2 And some of the norwegian translation stuff is still in German... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137487 *complain complain* If there is anything i can do to help, like testing out some beta etc, i will be happy to do that. Any (resonably stable) OO testing versions (i.e upstream stable but not RH stable - if you understand my meaning. Rawhide etc.) out, that needs more q&a? Kyrre From cra at WPI.EDU Tue Jan 25 17:56:45 2005 From: cra at WPI.EDU (Charles R. Anderson) Date: Tue, 25 Jan 2005 12:56:45 -0500 Subject: loop device creation [was Re: udev: Directory for custom device nodes.] In-Reply-To: <41F6665C.6030007@redhat.com> References: <20050125150446.GF7619@angus.ind.WPI.EDU> <41F6665C.6030007@redhat.com> Message-ID: <20050125175645.GV11938@angus.ind.WPI.EDU> On Tue, Jan 25, 2005 at 04:31:40PM +0100, Harald Hoyer wrote: > The loop module gets autoloaded by accessing /dev/loop. > A program (mount) would have to load the module, if it wants /dev/loop* and > wait for udev to create the device. > We could load the loop device on system startup, but you may not want to > have loaded "every" module, you could possibly use in one session. How about calling "mount -a" twice? Once to touch any devices that may need to have nodes created by udev, and again to actually succeed on mounting those devices? From dcbw at redhat.com Tue Jan 25 18:18:17 2005 From: dcbw at redhat.com (Dan Williams) Date: Tue, 25 Jan 2005 13:18:17 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <1106675674.2657.28.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> <1106640790.4341.3.camel@galvatron.localdomain> <1106668581.2657.14.camel@localhost.localdomain> <1106671927.3836.5.camel@rhbw.boston.redhat.com> <1106675674.2657.28.camel@localhost.localdomain> Message-ID: <1106677097.16105.22.camel@localhost.localdomain> On Tue, 2005-01-25 at 18:55 +0100, Kyrre Ness Sjobak wrote: > Btw. OpenOffice 1.1.4 is upstream - why are we still running 1.1.2 > > And some of the norwegian translation stuff is still in German... > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137487 > > *complain complain* > > If there is anything i can do to help, like testing out some beta etc, > i will be happy to do that. Any (resonably stable) OO testing versions > (i.e upstream stable but not RH stable - if you understand my meaning. > Rawhide etc.) out, that needs more q&a? 1.1.3 is in rawhide since last week, and we don't have full 1.1.4 support yet in upstream ooo-build, so we can't package that up for FC. As soon as people think Rawhide's 1.1.3 is OK, I'll push it as an update to FC3. Split out language support is still targetted at FC4 timeframe. Dan From hp at redhat.com Tue Jan 25 18:22:54 2005 From: hp at redhat.com (Havoc Pennington) Date: Tue, 25 Jan 2005 13:22:54 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <20050125165204.GB17028@devserv.devel.redhat.com> References: <1106607715.6122.21.camel@localhost.localdomain> <20050125050425.GK4047@nostromo.devel.redhat.com> <1106669074.7068.86.camel@localhost.localdomain> <20050125165204.GB17028@devserv.devel.redhat.com> Message-ID: <1106677374.8977.0.camel@localhost.localdomain> On Tue, 2005-01-25 at 11:52 -0500, Alan Cox wrote: > On Tue, Jan 25, 2005 at 11:04:34AM -0500, Havoc Pennington wrote: > > > You can set rlimits; you can also turn off overcommit. Doesn't help > > > the yum/rpm case, of course. > > > > Can we do either of those things by default/automatically in appropriate > > cases? > > > > We should be shipping with overcommit off by default, but I've been saying > that for years too 8. You can just drop it into /etc/sysctl.conf > So I have: [root at localhost ~]# cat /proc/sys/vm/overcommit_memory 0 [root at localhost ~]# cat /proc/sys/vm/overcommit_ratio 50 I'm assuming those are the current defaults... what should the default be to address this problem? (or what should I try first and report back on?) Havoc From mbneto at gmail.com Tue Jan 25 19:06:26 2005 From: mbneto at gmail.com (mbneto) Date: Tue, 25 Jan 2005 15:06:26 -0400 Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106408277.15391.17.camel@jdub.homelinux.org> <1106410993.15391.42.camel@jdub.homelinux.org> <5cf776b8050123075072835f89@mail.gmail.com> <1106498904.6129.46.camel@laptopd505.fenrus.org> <5cf776b80501231525cec0502@mail.gmail.com> <5cf776b8050125071534da28f0@mail.gmail.com> Message-ID: <5cf776b8050125110697e08e1@mail.gmail.com> Could be, but who knows and he would have such list.... - Mb > > I had the impression arjan seems to have to just highlighted that its > possible and not that he has a list of packages ready to send you. > > -- > Regards, > Rahul Sundaram > From sopwith at redhat.com Tue Jan 25 19:44:43 2005 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 25 Jan 2005 14:44:43 -0500 (EST) Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: <41F64F26.6080708@terminus.co.uk> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> Message-ID: Hey, I really appreciate all the discussion about packages that could be removed. Is there someone who's willing to read through the thread and collecte all the proposed removals so we can examine move forward with them? Cheers, -- Elliot From alan at redhat.com Tue Jan 25 19:53:59 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 25 Jan 2005 14:53:59 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <1106677374.8977.0.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> <20050125050425.GK4047@nostromo.devel.redhat.com> <1106669074.7068.86.camel@localhost.localdomain> <20050125165204.GB17028@devserv.devel.redhat.com> <1106677374.8977.0.camel@localhost.localdomain> Message-ID: <20050125195359.GA1219@devserv.devel.redhat.com> On Tue, Jan 25, 2005 at 01:22:54PM -0500, Havoc Pennington wrote: > [root at localhost ~]# cat /proc/sys/vm/overcommit_memory > 0 > [root at localhost ~]# cat /proc/sys/vm/overcommit_ratio > 50 > > I'm assuming those are the current defaults... what should the default > be to address this problem? (or what should I try first and report back > on?) 2 and 50 assuming you have swap. In that mode the system will refuse to let you create anything that might drive the box into overcommit. It works better yet in 2.6.10 as Andries modified the kernel to pre-reserve the pages for a typical stack so that programs didn't get killed occasionally by stack expand failure (it reserves the space not allocates the memory so its impact on performance is nil) Alan From fedora-devel at camperquake.de Tue Jan 25 20:02:00 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Tue, 25 Jan 2005 21:02:00 +0100 Subject: slow hard drives crushing interactivity In-Reply-To: <20050125195359.GA1219@devserv.devel.redhat.com> References: <1106607715.6122.21.camel@localhost.localdomain> <20050125050425.GK4047@nostromo.devel.redhat.com> <1106669074.7068.86.camel@localhost.localdomain> <20050125165204.GB17028@devserv.devel.redhat.com> <1106677374.8977.0.camel@localhost.localdomain> <20050125195359.GA1219@devserv.devel.redhat.com> Message-ID: <20050125210200.316b4479@nausicaa.camperquake.de> Hi. Alan Cox wrote: > 2 and 50 assuming you have swap. In that mode the system will refuse to > let you create anything that might drive the box into overcommit. I know it'd be suicide to try and correct you on linux kernel issues, but reading the kernel documentation in Documentation/filesystems/proc.txt I had guessed that "0" means "no overcommit". -- If high heels were so wonderful, men would be wearing them. -- Sue Grafton From alan at redhat.com Tue Jan 25 20:08:18 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 25 Jan 2005 15:08:18 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <20050125210200.316b4479@nausicaa.camperquake.de> References: <1106607715.6122.21.camel@localhost.localdomain> <20050125050425.GK4047@nostromo.devel.redhat.com> <1106669074.7068.86.camel@localhost.localdomain> <20050125165204.GB17028@devserv.devel.redhat.com> <1106677374.8977.0.camel@localhost.localdomain> <20050125195359.GA1219@devserv.devel.redhat.com> <20050125210200.316b4479@nausicaa.camperquake.de> Message-ID: <20050125200818.GG1219@devserv.devel.redhat.com> On Tue, Jan 25, 2005 at 09:02:00PM +0100, Ralf Ertzinger wrote: > I know it'd be suicide to try and correct you on linux kernel issues, > but reading the kernel documentation in Documentation/filesystems/proc.txt > I had guessed that "0" means "no overcommit". 0 - heuristic no overcommit (guess) 1 - overcommit arbitarily (some scientific workloads) 2 - no overcommit The 0/1/2 is because modes 0/1 existed long before we added strict no overcommit to the RHEL3 product and 2.6 upstream From tadams-lists at myrealbox.com Tue Jan 25 20:13:01 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Tue, 25 Jan 2005 13:13:01 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106334872.3809.3.camel@nexus.verbum.private> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> Message-ID: <1106683981.3394.4.camel@localhost.localdomain> On Fri, 2005-01-21 at 14:14 -0500, Colin Walters wrote: > On Fri, 2005-01-21 at 11:49 -0700, Trever L. Adams wrote: > > So, why is grip being removed? > > > > Sound Juicer does not yet allow quality selection. > > It will; grip is a good candidate for extras. Will and does are very different. IF it isn't there by FC4, FC4 should include grip. However, I see all critical functionality, and most non- critical, in RhythmBox. xmms uses gtk1 and doesn't seem to be needed; should it be removed? Trever -- "One Woman can make you fly like an eagle Another can give you the strength of a lion But only One in the cycle of life can fill your heart with wonder And the wisdom that you have known a singular joy." -- Unknown From skvidal at phy.duke.edu Tue Jan 25 20:14:11 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 25 Jan 2005 15:14:11 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106683981.3394.4.camel@localhost.localdomain> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> Message-ID: <1106684051.30714.9.camel@opus.phy.duke.edu> > Will and does are very different. IF it isn't there by FC4, FC4 should > include grip. However, I see all critical functionality, and most non- > critical, in RhythmBox. xmms uses gtk1 and doesn't seem to be needed; > should it be removed? Yes, it should. -sv From hp at redhat.com Tue Jan 25 20:26:17 2005 From: hp at redhat.com (Havoc Pennington) Date: Tue, 25 Jan 2005 15:26:17 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <20050125195359.GA1219@devserv.devel.redhat.com> References: <1106607715.6122.21.camel@localhost.localdomain> <20050125050425.GK4047@nostromo.devel.redhat.com> <1106669074.7068.86.camel@localhost.localdomain> <20050125165204.GB17028@devserv.devel.redhat.com> <1106677374.8977.0.camel@localhost.localdomain> <20050125195359.GA1219@devserv.devel.redhat.com> Message-ID: <1106684777.9418.0.camel@localhost.localdomain> On Tue, 2005-01-25 at 14:53 -0500, Alan Cox wrote: > On Tue, Jan 25, 2005 at 01:22:54PM -0500, Havoc Pennington wrote: > > [root at localhost ~]# cat /proc/sys/vm/overcommit_memory > > 0 > > [root at localhost ~]# cat /proc/sys/vm/overcommit_ratio > > 50 > > > > I'm assuming those are the current defaults... what should the default > > be to address this problem? (or what should I try first and report back > > on?) > > 2 and 50 assuming you have swap. In that mode the system will refuse to > let you create anything that might drive the box into overcommit. It works > better yet in 2.6.10 as Andries modified the kernel to pre-reserve the > pages for a typical stack so that programs didn't get killed occasionally > by stack expand failure (it reserves the space not allocates the memory so > its impact on performance is nil) > Hmm, that made evolution exit within 2 minutes of enabling it ;-) Maybe I need the 2.6.10 fix... Havoc From alan at redhat.com Tue Jan 25 20:47:24 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 25 Jan 2005 15:47:24 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <1106684777.9418.0.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> <20050125050425.GK4047@nostromo.devel.redhat.com> <1106669074.7068.86.camel@localhost.localdomain> <20050125165204.GB17028@devserv.devel.redhat.com> <1106677374.8977.0.camel@localhost.localdomain> <20050125195359.GA1219@devserv.devel.redhat.com> <1106684777.9418.0.camel@localhost.localdomain> Message-ID: <20050125204724.GC4088@devserv.devel.redhat.com> On Tue, Jan 25, 2005 at 03:26:17PM -0500, Havoc Pennington wrote: > Hmm, that made evolution exit within 2 minutes of enabling it ;-) Maybe > I need the 2.6.10 fix... Maybe its telling you something about evolution From train at voicenet.com Tue Jan 25 20:14:28 2005 From: train at voicenet.com (Herbert Rutledge) Date: Tue, 25 Jan 2005 15:14:28 -0500 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> Message-ID: <1106684068.28430.52.camel@trilon> On Tue, 2005-01-25 at 14:44 -0500, Elliot Lee wrote: > Hey, I really appreciate all the discussion about packages that could be > removed. Is there someone who's willing to read through the thread and > collecte all the proposed removals so we can examine move forward with > them? If you don't need the list immediately, I would be happy to volunteer, but I won't be able to get to it until the weekend. Is that OK? -train From fedora-devel at camperquake.de Tue Jan 25 20:52:11 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Tue, 25 Jan 2005 21:52:11 +0100 Subject: slow hard drives crushing interactivity In-Reply-To: <20050125204724.GC4088@devserv.devel.redhat.com> References: <1106607715.6122.21.camel@localhost.localdomain> <20050125050425.GK4047@nostromo.devel.redhat.com> <1106669074.7068.86.camel@localhost.localdomain> <20050125165204.GB17028@devserv.devel.redhat.com> <1106677374.8977.0.camel@localhost.localdomain> <20050125195359.GA1219@devserv.devel.redhat.com> <1106684777.9418.0.camel@localhost.localdomain> <20050125204724.GC4088@devserv.devel.redhat.com> Message-ID: <20050125215211.663d5c5c@nausicaa.camperquake.de> Hi. Alan Cox wrote: > Maybe its telling you something about evolution Nothing we did not know already, though. -- Although robust enough for general use, adventures into the esoteric periphery of the C shell may reveal unexpected quirks. -- Sun's man page for "csh" From nbargnesi at gmail.com Tue Jan 25 20:55:27 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Tue, 25 Jan 2005 15:55:27 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106684051.30714.9.camel@opus.phy.duke.edu> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> Message-ID: <3077b8a005012512555adc9e3c@mail.gmail.com> Second that - lose xmms. On Tue, 25 Jan 2005 15:14:11 -0500, seth vidal wrote: > > > Will and does are very different. IF it isn't there by FC4, FC4 should > > include grip. However, I see all critical functionality, and most non- > > critical, in RhythmBox. xmms uses gtk1 and doesn't seem to be needed; > > should it be removed? > > Yes, it should. > -sv > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From enrico.scholz at informatik.tu-chemnitz.de Tue Jan 25 21:07:13 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 25 Jan 2005 22:07:13 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106683981.3394.4.camel@localhost.localdomain> (Trever L. Adams's message of "Tue, 25 Jan 2005 13:13:01 -0700") References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> Message-ID: <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> tadams-lists at myrealbox.com ("Trever L. Adams") writes: > xmms uses gtk1 and doesn't seem to be needed; should it be removed? No, there is no other nice-looking mp3/ogg/... player in FC. Enrico From arjanv at redhat.com Tue Jan 25 21:11:54 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Tue, 25 Jan 2005 22:11:54 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: References: <1106408277.15391.17.camel@jdub.homelinux.org> <1106410993.15391.42.camel@jdub.homelinux.org> <5cf776b8050123075072835f89@mail.gmail.com> <1106498904.6129.46.camel@laptopd505.fenrus.org> <5cf776b80501231525cec0502@mail.gmail.com> <5cf776b8050125071534da28f0@mail.gmail.com> Message-ID: <20050125211154.GC14149@devserv.devel.redhat.com> On Tue, Jan 25, 2005 at 09:09:33PM +0530, Rahul Sundaram wrote: > On Tue, 25 Jan 2005 11:15:58 -0400, mbneto wrote: > > Ok. But since I was not able to remove myself (due to > > dependencies...) the packages to this ~300Mb I was hoping I could get > > (off list) the rpm -qa to compare with mine and simply remove the ones > > missing.. > > I had the impression arjan seems to have to just highlighted that its > possible and not that he has a list of packages ready to send you. actually I do have a list of packages; I'll send it tomorrow when I power the box that has them on ;) From kyrre at solution-forge.net Tue Jan 25 21:24:01 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 25 Jan 2005 22:24:01 +0100 Subject: slow hard drives crushing interactivity In-Reply-To: <1106677097.16105.22.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> <1106640790.4341.3.camel@galvatron.localdomain> <1106668581.2657.14.camel@localhost.localdomain> <1106671927.3836.5.camel@rhbw.boston.redhat.com> <1106675674.2657.28.camel@localhost.localdomain> <1106677097.16105.22.camel@localhost.localdomain> Message-ID: <1106688241.2657.33.camel@localhost.localdomain> tir, 25.01.2005 kl. 19.18 skrev Dan Williams: > On Tue, 2005-01-25 at 18:55 +0100, Kyrre Ness Sjobak wrote: > > Btw. OpenOffice 1.1.4 is upstream - why are we still running 1.1.2 > > > > And some of the norwegian translation stuff is still in German... > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137487 > > > > *complain complain* > > > > If there is anything i can do to help, like testing out some beta etc, > > i will be happy to do that. Any (resonably stable) OO testing versions > > (i.e upstream stable but not RH stable - if you understand my meaning. > > Rawhide etc.) out, that needs more q&a? > > 1.1.3 is in rawhide since last week, and we don't have full 1.1.4 > support yet in upstream ooo-build, so we can't package that up for FC. > As soon as people think Rawhide's 1.1.3 is OK, I'll push it as an update > to FC3. Split out language support is still targetted at FC4 timeframe. > > Dan Ok. Ill try to update my fc3 running computer to 1.1.3, and ill come back yelling if it ain't working! :) What do you mean with "not full upstream support"? the "make icons nice" stuff, or something else? Linux support not up2date? From dcbw at redhat.com Tue Jan 25 21:26:01 2005 From: dcbw at redhat.com (Dan Williams) Date: Tue, 25 Jan 2005 16:26:01 -0500 (EST) Subject: slow hard drives crushing interactivity In-Reply-To: <1106688241.2657.33.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> <1106640790.4341.3.camel@galvatron.localdomain> <1106668581.2657.14.camel@localhost.localdomain> <1106671927.3836.5.camel@rhbw.boston.redhat.com> <1106675674.2657.28.camel@localhost.localdomain> <1106677097.16105.22.camel@localhost.localdomain> <1106688241.2657.33.camel@localhost.localdomain> Message-ID: On Tue, 25 Jan 2005, Kyrre Ness Sjobak wrote: > What do you mean with "not full upstream support"? the "make icons nice" > stuff, or something else? Linux support not up2date? No, there are a ton of patches in ooo-build against 1.1.x line of OpenOffice.org, and those have to be re-verfied against each new version that comes out, including removing those patches that have been pushed upstream. Sometimes the patches have to be rediffed as well. That's basically what I mean, ensuring the patch set still applies. Dan From hp at redhat.com Tue Jan 25 21:37:46 2005 From: hp at redhat.com (Havoc Pennington) Date: Tue, 25 Jan 2005 16:37:46 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <20050125204724.GC4088@devserv.devel.redhat.com> References: <1106607715.6122.21.camel@localhost.localdomain> <20050125050425.GK4047@nostromo.devel.redhat.com> <1106669074.7068.86.camel@localhost.localdomain> <20050125165204.GB17028@devserv.devel.redhat.com> <1106677374.8977.0.camel@localhost.localdomain> <20050125195359.GA1219@devserv.devel.redhat.com> <1106684777.9418.0.camel@localhost.localdomain> <20050125204724.GC4088@devserv.devel.redhat.com> Message-ID: <1106689066.9418.32.camel@localhost.localdomain> On Tue, 2005-01-25 at 15:47 -0500, Alan Cox wrote: > On Tue, Jan 25, 2005 at 03:26:17PM -0500, Havoc Pennington wrote: > > Hmm, that made evolution exit within 2 minutes of enabling it ;-) Maybe > > I need the 2.6.10 fix... > > Maybe its telling you something about evolution > Evolution does alloc a lot of memory (especially with as much mail as I have!) but it's well under 200M on a 512M system with swap, so ... ;-) Havoc From tadams-lists at myrealbox.com Tue Jan 25 21:44:39 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Tue, 25 Jan 2005 14:44:39 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106689480.3393.0.camel@localhost.localdomain> On Tue, 2005-01-25 at 22:07 +0100, Enrico Scholz wrote: > tadams-lists at myrealbox.com ("Trever L. Adams") writes: > > > xmms uses gtk1 and doesn't seem to be needed; should it be removed? > > No, there is no other nice-looking mp3/ogg/... player in FC. > > > > Enrico > I think xmms is ugly, no matter what theme you put on it. RhythmBox is at least organized in a nice way. Trever -- "I do not fear computers. I fear the lack of them." -- Isaac Asimov From rdieter at math.unl.edu Tue Jan 25 21:51:28 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 25 Jan 2005 15:51:28 -0600 (CST) Subject: slow hard drives crushing interactivity In-Reply-To: <1106688241.2657.33.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> <1106640790.4341.3.camel@galvatron.localdomain> <1106668581.2657.14.camel@localhost.localdomain> <1106671927.3836.5.camel@rhbw.boston.redhat.com> <1106675674.2657.28.camel@localhost.localdomain> <1106677097.16105.22.camel@localhost.localdomain> <1106688241.2657.33.camel@localhost.localdomain> Message-ID: On Tue, 25 Jan 2005, Kyrre Ness Sjobak wrote: > What do you mean with "not full upstream support"? the "make icons nice" > stuff, or something else? ooo-build from ooo.ximian.com doesn't do ooo-1.1.4 yet. -- Rex From brugolsky at telemetry-investments.com Tue Jan 25 22:01:05 2005 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Tue, 25 Jan 2005 17:01:05 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <1106607715.6122.21.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> Message-ID: <20050125220105.GA12702@ti64.telemetry-investments.com> On Mon, Jan 24, 2005 at 06:01:55PM -0500, Havoc Pennington wrote: > On my IBM X31 laptop, the system entirely locks up when there's a lot of > disk access, some common situations are: > - when getting heavily into swap due to a runaway process > - when running rpm/yum > > It's not *technically* locked up (i.e. if you wait long enough it will > come back) but in practice you have to reboot if a process has a memory > leak, and you can't do any work while running yum. What kernel are you running? Over the past two months I've put together our 2.6.10-based production kernel from lots of VM, scheduler, and latency patches cherry-picked from -mm and lkml; most of them (especially the VM fixes) are now in 2.6.11-rc2. I do some testing on my Fujitsu laptop (Pentium M 1.6GHz, 768M RAM, 4500 RPM disk), and 2.6.10-mm*-derived kernels respond much better than vanilla 2.6.10 under load, or when doing a massive set of package updates. So trying the Rawhide kernel might be an option, though the 2.6.11-bk tree has had quite a lot breakage of late, including memory leaks. :-/ [I haven't been tracking Fedora/Rawhide kernels since around 2.6.7-1.492, so I don't know how things are working there.] If you feel like doing some patching, you might also want to have a look at Ingo's swapspace-layout-improvements patch, which AKPM added to 2.6.11-rc1-mm2, Andrea's new OOM-killer patches [since long delays killing a process make the OOM killer go a bit berserk], http://groups-beta.google.com/group/linux.kernel/browse_frm/thread/9091db6e91a07f0c and Jens's CFQ time-slice elevator, http://www.kernel.org/pub/linux/kernel/people/axboe/patches/v2.6/2.6.11-rc1/cfq-time-slices-20.bz2 Regards, Bill Rugolsky From cpedersen at c-note.dk Tue Jan 25 22:03:36 2005 From: cpedersen at c-note.dk (Casper Pedersen) Date: Tue, 25 Jan 2005 23:03:36 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106689480.3393.0.camel@localhost.localdomain> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> Message-ID: <41F6C238.2050201@c-note.dk> >I think xmms is ugly, no matter what theme you put on it. RhythmBox is >at least organized in a nice way. > > > Depends on how you see it; xmms is nice, small, and might not be pretty, but it works. RythmBox is big and slow to use with very large collections of files, but it is pretty. It's a personal opinion, and there should be a choice for all. Sometimes there have to be compromises. I for example would not be happy to loose Grip and xmms, but then again, I might be old fasion:-) Regards/Casper -- GPG Public key is available from: http://www.keyserver.net/ Fingerprint = 56ED 74A4 7B00 20E2 B493 0C1A 6B4E BF8F A086 FE57 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature URL: From kyrre at solution-forge.net Tue Jan 25 22:27:04 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Tue, 25 Jan 2005 23:27:04 +0100 Subject: FC4 with localized firefox (wishlist) In-Reply-To: <1106595754.5024.3.camel@localhost> References: <1106482635.6173.100.camel@localhost> <41F54953.7040901@redhat.com> <1106595754.5024.3.camel@localhost> Message-ID: <1106692024.2657.51.camel@localhost.localdomain> man, 24.01.2005 kl. 20.42 skrev Josep Puigdemont: > El dl 24 de 01 del 2005 a les 14:15 -0500, en/na Christopher Aillon va > escriure: > > Josep Puigdemont wrote: > > > Hi, > > > > > > Here it is my short wish list for FC4, if I may send one ;-) > > > I don't know if this has been mentioned before or not, but I for one > > > would like to see localized versions of Firefox for each installed > > > language, by default. > > > > The version in rawhide does this already, at least for the languages > > that Firefox have been translated into already. I've just been sort of > > swamped and haven't had time to backport to fc3 yet. > > great news, thanks a lot! I can hardly wait ;-) > > /Josep > Just installed it - here are my reactions: - It seems a bit faster - The gnomish'ed icons which i think are new, and noticed immediatly without really knowing what i noticed, are pretty. Especially the bookmark-icon! - smooth scrolling is smooth! But: It's still in english. While i personally don't have any problem with it, the rest of my desktop are in norwegian. Somehow the OSS crowd manages to make really nice translations. Usefull ones. (anjuta being the baaad exeption that marks the rule) Kyrre From peter.backlund at home.se Tue Jan 25 22:34:24 2005 From: peter.backlund at home.se (Peter Backlund) Date: Tue, 25 Jan 2005 23:34:24 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F6C238.2050201@c-note.dk> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> Message-ID: <1106692464.26459.3.camel@localhost.localdomain> tis 2005-01-25 klockan 23:03 +0100 skrev Casper Pedersen: > >I think xmms is ugly, no matter what theme you put on it. RhythmBox is > >at least organized in a nice way. > > > > > > > Depends on how you see it; xmms is nice, small, and might not be pretty, > but it works. RythmBox is big and slow to use with very large > collections of files, but it is pretty. > > It's a personal opinion, and there should be a choice for all. Sometimes > there have to be compromises. > > I for example would not be happy to loose Grip and xmms, but then again, > I might be old fasion:-) > > Regards/Casper For a Gtk2 replacement of xmms, take a look at Beep Media Player: http://www.sosdg.org/~larne/w/BMP_Homepage It's in QA over at livna: http://bugzilla.livna.org/show_bug.cgi?id=54 mp3 subpackage could be created if it's decided that it replaces xmms, or is included in Extras. It even uses the Bluecurve xmms skin :-) /Peter From hp at redhat.com Tue Jan 25 22:33:23 2005 From: hp at redhat.com (Havoc Pennington) Date: Tue, 25 Jan 2005 17:33:23 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <20050125220105.GA12702@ti64.telemetry-investments.com> References: <1106607715.6122.21.camel@localhost.localdomain> <20050125220105.GA12702@ti64.telemetry-investments.com> Message-ID: <1106692403.9418.44.camel@localhost.localdomain> On Tue, 2005-01-25 at 17:01 -0500, Bill Rugolsky Jr. wrote: > > What kernel are you running? > Oscillating back and forth between FC3 update and rawhide. Good to hear fixes are in the works, for sure. Havoc From mike at navi.cx Tue Jan 25 22:48:26 2005 From: mike at navi.cx (Mike Hearn) Date: Tue, 25 Jan 2005 22:48:26 +0000 Subject: RFC: Soname in rpm name References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E672.3020103@nc.rr.com> <20050124132138.2bdbc4c9.fedora@wir-sind-cool.org> <41F4EB14.3040302@nc.rr.com> Message-ID: On Mon, 24 Jan 2005 23:26:02 +0100, Aurelien Bompard wrote: > Well, libkexif is a few months old. We can expect unstability for new > projects, and as one of Fedora's aim is to be on the bleeding edge, we will > see this problem more and more frequently. If it's so unstable just statically link it. Nobody should be dynamically linking against very unstable libraries (libICU *ahem*) thanks -mike From jspaleta at gmail.com Tue Jan 25 22:45:15 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 25 Jan 2005 17:45:15 -0500 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> Message-ID: <604aa79105012514452c79558@mail.gmail.com> On Tue, 25 Jan 2005 14:44:43 -0500 (EST), Elliot Lee wrote: > Hey, I really appreciate all the discussion about packages that could be > removed. Is there someone who's willing to read through the thread and > collecte all the proposed removals so we can examine move forward with > them? Read through the "further removals/potential package removals" thread Here's the summary list of suggested removals/moves and the person who made them. Bill Notting: xloadimage nedit jed Peter Robinson: Can we also get rid / move to extras all the non GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK 1 cruft as well? F?liciano Matias: move to extras dosfstools move to extras Lynx (or elinks) move to extras lesstif and/or openmotif21 leave openmotif which is used by: stardict, ddd, xpdf, nedit, iiimf-le-chinput move to extras xpdf move to extras ddd Remove rpmdb. move experimental gcc (gcc4 in FC3 for example) to Fedora Extra. Alax Cox: Possibly joe into extras Nicolas Mailhot : Even better : get rid of all the stuff that doesn't use fontconfig yet -jef From strange at nsk.no-ip.org Tue Jan 25 20:20:12 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Tue, 25 Jan 2005 20:20:12 +0000 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106629396.28420.92.camel@bree.local.net> References: <1106629396.28420.92.camel@bree.local.net> Message-ID: <20050125202012.GA9010@nsk.no-ip.org> xen-2-20050124.src.rpm has no BuildRequire on xorg-x11-devel or python-devel, and it breaks without those. BTW, does it require python-2.4? I have the stock xen sources running happily in python 2.3, but your documentation refers specifically to python 2.4. Regards, Luciano Rocha From felipe_alfaro at linuxmail.org Tue Jan 25 22:50:39 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Tue, 25 Jan 2005 23:50:39 +0100 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106629396.28420.92.camel@bree.local.net> References: <1106629396.28420.92.camel@bree.local.net> Message-ID: <88C3252C-6F23-11D9-B78E-000D9352858E@linuxmail.org> On 25 Jan 2005, at 06:03, Jeremy Katz wrote: > Once you've rebooted, you should be running in the dom0 kernel. You'll > see a slightly scary looking warning about TLS during bootup and how to > disable it, but it shouldn't make things too bad. In my case, I need to: mv /lib/tls /lib/tls.disabled or Xen will hang during boot. From katzj at redhat.com Tue Jan 25 22:51:29 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 25 Jan 2005 17:51:29 -0500 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <20050125202012.GA9010@nsk.no-ip.org> References: <1106629396.28420.92.camel@bree.local.net> <20050125202012.GA9010@nsk.no-ip.org> Message-ID: <1106693489.28420.136.camel@bree.local.net> On Tue, 2005-01-25 at 20:20 +0000, Luciano Miguel Ferreira Rocha wrote: > xen-2-20050124.src.rpm has no BuildRequire on xorg-x11-devel or > python-devel, and it breaks without those. Added to the spec file in CVS, will be included the next time we do a build. Thanks. > BTW, does it require python-2.4? I have the stock xen sources running > happily in python 2.3, but your documentation refers specifically to > python 2.4. It calls out python 2.4 as the binary packages require them. Yes, rebuilding the src.rpm will let you get around that. Jeremy From felipe_alfaro at linuxmail.org Tue Jan 25 22:54:56 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Tue, 25 Jan 2005 23:54:56 +0100 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106629396.28420.92.camel@bree.local.net> References: <1106629396.28420.92.camel@bree.local.net> Message-ID: <21FCA8D9-6F24-11D9-B78E-000D9352858E@linuxmail.org> On 25 Jan 2005, at 06:03, Jeremy Katz wrote: > Then, you should be able to install the xen and kernel-xen0 packages. > Once this is done, you should have an entry set up in your grub.conf to > boot the xen0 kernel. Now, reboot into your new xen0 kernel [3] Does kernel-xen0 still install the wrong entries into grub.conf? I'm bk pulling directly from the -unstable branch of Xen, so I can't test this currently. The correct entries are, for example: title Xen root (hd0,1) kernel /boot/xen.gz dom0_mem=400000 module /boot/vmlinuz-2.6.10-xen0 ro root=/dev/hda2 module /boot/initrd-2.6.10-xen0.img However, older versions did install: title Xen root (hd0,1) kernel /boot/vmlinuz-2.6.10-xen0 ro root=/dev/hda2 initrd /boot/initrd-2.6.10-xen0.img which is plain wrong. From mike at navi.cx Tue Jan 25 23:06:57 2005 From: mike at navi.cx (Mike Hearn) Date: Tue, 25 Jan 2005 23:06:57 +0000 Subject: RFC: Soname in rpm name References: <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <604aa791050124115732488573@mail.gmail.com> Message-ID: On Mon, 24 Jan 2005 14:57:57 -0500, Jeff Spaleta wrote: > Yeah... i like AOL's new commercials about virus protection which > speak to your point about Windows I'll skip the "backwards compatibility == viruses" stuff as it really isn't relevant here and doesn't stand up to close inspection anyway (hint: is it useful to prevent people who rely on a particular program from getting *any* security updates at all, because one breaks their program? no other desktop OS vendor has said yes here). > Let them use windows... i have no problem with people choosing to use > insecure technology. > But i do have a problem setting up this project in a way that makes it > "very simple" to run old, unmaintained, vulnerable libraries by > inexperienced users of Fedora. You can do some pretty flexible things > on the commandline with rpm if you really want to do it and I'm not > arguing that ability should be taken away. But i don't want encourage > the general user base to use packaged libraries from old trees that are > no longer being maintained just because it happens to be a package they > find on the net in an old ftp. And i definitely want to encourage > package builders to rebuild against libraries that are being maintained. Since when is this just about "rebuilding" stuff? Do you think apps are magically ported to GTK+ 2 by running gcc on them? What about OpenSSL? This is not simply a matter of running gcc or rebuilding packages. It's a much deeper issue. > This is orthogonal to packaging issues... Not in the slightest, it's fundamental to packaging issues. > and frankly... not something a > distributor of libraries can dictate to each upstream project. Why is Fedora including unstable libraries as discrete packages at all? Why not just statically link them into the packages that need them? Yes I'm aware of the disadvantages of static linking. Are you aware of the disadvantages of dynamic linking? > If this were debian... with debian timescales for the development and > end-of-life... 5 years isnt that long. But this isn't debian.. and this > project doesn't have those sorts of timescales... so with respect to > FC's timetable 5 years is definitely a long time. Outside of the Linux community (ie, in the *desktop world*) the current rate of instability is simply unacceptable. Why do you think Red Hat make money by selling what is essentially an old version of Fedora? I don't know why I bother, really, Sean is quite right - the number of ways people justify massive "platform" (haha) instability to themselves is astonishing. I should keep a note of them all or something. This sort of thing keeps coming up again and again because it causes users *pain*, and each time it does people write it off as "not our problem", "unfixable", "only proprietary software needs that" or "DO YOU HATE INNOVATION!?!" type crap. thanks -mike From alan at redhat.com Tue Jan 25 23:01:41 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 25 Jan 2005 18:01:41 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <1106689066.9418.32.camel@localhost.localdomain> References: <1106607715.6122.21.camel@localhost.localdomain> <20050125050425.GK4047@nostromo.devel.redhat.com> <1106669074.7068.86.camel@localhost.localdomain> <20050125165204.GB17028@devserv.devel.redhat.com> <1106677374.8977.0.camel@localhost.localdomain> <20050125195359.GA1219@devserv.devel.redhat.com> <1106684777.9418.0.camel@localhost.localdomain> <20050125204724.GC4088@devserv.devel.redhat.com> <1106689066.9418.32.camel@localhost.localdomain> Message-ID: <20050125230141.GA18641@devserv.devel.redhat.com> On Tue, Jan 25, 2005 at 04:37:46PM -0500, Havoc Pennington wrote: > > Maybe its telling you something about evolution > > Evolution does alloc a lot of memory (especially with as much mail as I > have!) but it's well under 200M on a 512M system with swap, so ... ;-) Memory or address space. The overcommit is basically ensuring you don't exceed Swap + 50%RAM of virtual address space allocated. From kzak at redhat.com Tue Jan 25 23:16:49 2005 From: kzak at redhat.com (Karel Zak) Date: Wed, 26 Jan 2005 00:16:49 +0100 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <21FCA8D9-6F24-11D9-B78E-000D9352858E@linuxmail.org> References: <1106629396.28420.92.camel@bree.local.net> <21FCA8D9-6F24-11D9-B78E-000D9352858E@linuxmail.org> Message-ID: <1106695009.3552.109.camel@petra> On Tue, 2005-01-25 at 23:54 +0100, Felipe Alfaro Solana wrote: > On 25 Jan 2005, at 06:03, Jeremy Katz wrote: > > > Then, you should be able to install the xen and kernel-xen0 packages. > > Once this is done, you should have an entry set up in your grub.conf to > > boot the xen0 kernel. Now, reboot into your new xen0 kernel [3] > > Does kernel-xen0 still install the wrong entries into grub.conf? > I'm bk pulling directly from the -unstable branch of Xen, so I can't > test this currently. > > The correct entries are, for example: > > title Xen > root (hd0,1) > kernel /boot/xen.gz dom0_mem=400000 > module /boot/vmlinuz-2.6.10-xen0 ro root=/dev/hda2 > module /boot/initrd-2.6.10-xen0.img > > However, older versions did install: > > title Xen > root (hd0,1) > kernel /boot/vmlinuz-2.6.10-xen0 ro root=/dev/hda2 > initrd /boot/initrd-2.6.10-xen0.img > > which is plain wrong. It's already fixed in latest FC4 xen0 kernel. Karel -- Karel Zak From mike at navi.cx Tue Jan 25 23:24:08 2005 From: mike at navi.cx (Mike Hearn) Date: Tue, 25 Jan 2005 23:24:08 +0000 Subject: slow hard drives crushing interactivity References: <1106607715.6122.21.camel@localhost.localdomain> Message-ID: On Mon, 24 Jan 2005 18:01:55 -0500, Havoc Pennington wrote: > On my IBM X31 laptop, the system entirely locks up when there's a lot of > disk access, some common situations are: > - when getting heavily into swap due to a runaway process > - when running rpm/yum Yum == swap access, essentially. It uses enormous amounts of memory while doing dep resolution. > I have 512M of physical memory. I have 256. Welcome to my hell ;) Seriously, I use apt these days because it's just not possible to sensibly run yum without flushing nearly everything in memory to disk. Apt is rather better behaved with RAM but still not wonderful. RPM does make the whole system unresponsive while it's installing, but it's fairly fast and doesn't eat memory. Interestingly autopackage (collection of shell scripts, essentially) has the opposite effect. It never makes the system unresponsive but if the system is under load it runs *much* slower. I guess that is because when the system is bogged down process creation time goes through the roof so it's sort of automatically rate limiting. > Is there any solution (that we can enable by default/automatically, not > much of a solution otherwise)? Right now it's sort of like running an OS > without protected memory. It's probably possible to improve the kernels behaviour under pathological loads but when a friend was using my laptop which isn't that old I had to do the following for her: - Replace OpenOffice with AbiWord. - Use apt instead of yum for updates, and only when she wasn't using it - Disable the desktop wallpaper (!) in order to get memory usage down to an acceptable level. And she didn't use Evolution. Another problem is that Firefox/Gecko apparently leaks memory like a sieve. Try opening a new browser instance, set memory cache to zero (or something very low) and start opening lots of tabs in a typical web browsing session. Observe that memory usage never goes down. Why? Not sure. There are some other really sloppy leaks in FC3 too. Eg somehow I got spamd enabled (is that the default) and when Evolution filters my inbox Spam-Assassin ends up using a quarter of my memory. I have the GNOME applet thingy running and "killall spamd" makes memory usage drop off a cliff for a few minutes. thanks -mike From thuforuk at yahoo.co.uk Tue Jan 25 23:18:15 2005 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Tue, 25 Jan 2005 23:18:15 +0000 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106692464.26459.3.camel@localhost.localdomain> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <1106692464.26459.3.camel@localhost.localdomain> Message-ID: <41F6D3B7.807@yahoo.co.uk> On 01/25/2005 10:34 PM, Peter Backlund wrote: > tis 2005-01-25 klockan 23:03 +0100 skrev Casper Pedersen: > >>>I think xmms is ugly, no matter what theme you put on it. RhythmBox is >>>at least organized in a nice way. >> >>Depends on how you see it; xmms is nice, small, and might not be pretty, >>but it works. RythmBox is big and slow to use with very large >>collections of files, but it is pretty. >>I for example would not be happy to loose Grip and xmms, but then again, >>I might be old fasion:-) +1 > For a Gtk2 replacement of xmms, take a look at Beep Media Player: > mp3 subpackage could be created if it's decided that it replaces xmms, > or is included in Extras. It even uses the Bluecurve xmms skin :-) Unfortunately it does not have "double size" feature of xmms. This makes it problematic for around 100dpi screens (1600x1200 at 20" or 1280x1024 at 17") My case exactly :( Regards, Dariusz From jspaleta at gmail.com Tue Jan 25 23:22:48 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 25 Jan 2005 18:22:48 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106684051.30714.9.camel@opus.phy.duke.edu> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> Message-ID: <604aa7910501251522372fd08e@mail.gmail.com> On Tue, 25 Jan 2005 15:14:11 -0500, seth vidal wrote: > > > Will and does are very different. IF it isn't there by FC4, FC4 should > > include grip. However, I see all critical functionality, and most non- > > critical, in RhythmBox. xmms uses gtk1 and doesn't seem to be needed; > > should it be removed? > > Yes, it should. I'm clueless... but is there an application in Core for playing audio cds that can duplicate xmms's "digital audio extraction" option? I still notice a lot of people who run into this problem when trying to play audio cds and the only application I know in Core that doesn't require the analog audio cable from the cd drive to the sound card is xmms. Right now the best workaround I know of is to use xmms for audio cd playing and configuring xmms to do digital audio extraction instead of analog. Seems gnome's cd player in fc3 doesn't know anything about this which makes keeping xmms somewhat compelling as a cd player even if rhythmbox has equivalent media library capabilities. -jef"yeah i know.. actually using audio cds instead of ripping them to oggs is sooooo 1990's"spaleta From enrico.scholz at informatik.tu-chemnitz.de Tue Jan 25 23:41:30 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 26 Jan 2005 00:41:30 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106482308.6306.52.camel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Sun, 23 Jan 2005 13:11:48 +0100") References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106482308.6306.52.camel@rousalka.dyndns.org> Message-ID: <878y6hrs9h.fsf@kosh.ultra.csn.tu-chemnitz.de> Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) writes: >> >> emacs-21.3-20 >> >> ------------- >> > ... >> > Any news on the Gtk Emacs front? >> >> I would not spend much energy on such a port. A Gtk port means AA >> fonts which are really a bad choice for text based applications. > > A gtk port means fontconfig and AA ie all the users that do not use pure > american files on a 75dpi screen can get some mileage out of emacs > without ruining their eyes. > > fontconfig support is the single reason several people (including me) > dumped emacs/xemacs altogether for vim/gvim recently. I'm amazed someone > can maintain like you that fontconfig is a bad choice for text apps - > surely an app that's devoted to displaying text is *more* sensitive to > the text rendering tech than your average ogg player. Ok, some assumptions: * text apps used by me (XEmacs, xterm) are configured for 10pt fonts. I want to see much information and do not want larger fonts therefore, but fonts <10pt are too small for me * fonts <=10pt should not be anti-aliased. This is stated in the font-howto [1] also. These fonts are so small that stepping can not be seen, and antialiasing would add blurriness, remove information and slow down processing. * free TrueType fonts (bitstream vera) in 10pt look unacceptably without antialiasing (lots of disrupted lines), antialiased ones are far away from being perfect. E.g. 'e', 'a' or 's' look somehow dirty, some lines are thicker than other ones, the white room in the upper half of 'e' is not white but gray, letters are melt together, ... * unfree TrueType fonts are ... mmh ... not free and not available in FC therefore. Using full power of them would need patented technology (TT bytecode interpreter) which is unavailable also * standard bitmap fonts for 10pt are of perfect quality (I am using them currently and do not know how they could be enhanced) AA fonts might be ok for applications with large fonts (graphic or presentation programs, ogg players), but bitmap fonts are the best for pure text based apps. Enrico Footnotes: [1] http://ldp.openskills.info/HOWTO/Font-HOWTO/fix.html From tadams-lists at myrealbox.com Wed Jan 26 00:10:29 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Tue, 25 Jan 2005 17:10:29 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <604aa7910501251522372fd08e@mail.gmail.com> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <604aa7910501251522372fd08e@mail.gmail.com> Message-ID: <1106698229.3393.2.camel@localhost.localdomain> On Tue, 2005-01-25 at 18:22 -0500, Jeff Spaleta wrote: > I'm clueless... but is there an application in Core for playing audio > cds that can duplicate xmms's "digital audio extraction" option? I > still notice a lot of people who run into this problem when trying to > play audio cds and the only application I know in Core that doesn't > require the analog audio cable from the cd drive to the sound card is > xmms. Right now the best workaround I know of is to use xmms for > audio cd playing and configuring xmms to do digital audio extraction > instead of analog. Seems gnome's cd player in fc3 doesn't know > anything about this which makes keeping xmms somewhat compelling as a > cd player even if rhythmbox has equivalent media library capabilities. > > -jef"yeah i know.. actually using audio cds instead of ripping them to > oggs is sooooo 1990's"spaleta > For someone who understands gstreamer, this should be a VERY simple plugin to write I would think. Trever -- "The secret of being miserable is to have leisure to bother about whether you are happy or not. The cure for it is occupation." -- George Bernard Shaw (1856-1950) From perbj at stanford.edu Wed Jan 26 00:12:12 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Tue, 25 Jan 2005 16:12:12 -0800 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <604aa7910501251522372fd08e@mail.gmail.com> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <604aa7910501251522372fd08e@mail.gmail.com> Message-ID: <1106698332.6602.2.camel@localhost.localdomain> On Tue, 2005-01-25 at 18:22 -0500, Jeff Spaleta wrote: > I'm clueless... but is there an application in Core for playing audio > cds that can duplicate xmms's "digital audio extraction" option? I > still notice a lot of people who run into this problem when trying to > play audio cds and the only application I know in Core that doesn't > require the analog audio cable from the cd drive to the sound card is > xmms. Totem should be able to do that. Even though it's labeled 'Movie player' it plays all kinds of media stuff. /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From jspaleta at gmail.com Wed Jan 26 00:21:23 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 25 Jan 2005 19:21:23 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106698229.3393.2.camel@localhost.localdomain> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <604aa7910501251522372fd08e@mail.gmail.com> <1106698229.3393.2.camel@localhost.localdomain> Message-ID: <604aa7910501251621c61be03@mail.gmail.com> On Tue, 25 Jan 2005 17:10:29 -0700, Trever L. Adams wrote: > For someone who understands gstreamer, this should be a VERY simple > plugin to write I would think. shrug.. i was just pointing out one of the primary reasons i see fc3 users are still using xmms. I'll let other people decide if this is an important enough reason to keep xmms in Core or not. Perhaps the gtk2 based beep can be used instead to fill the same role so that the older gtk libs can be removed from core. And i'm not even sure this is a simple gst plugin fix. Does rhythmbox even play audio cds? Typically what i see happening when novice users try to play cds on their gnome fc3 desktops is gnome-cd will open up and start accessing the audio cd. If their system doesn't have an analog audio connection between the soundcard and the cd unit .... there is no sound.... gnome-cd plays.. but there is no sound. Seems to afflict a number of users who have integrated audio hardware instead of an actual soundcard.. but I can't speak first hand since I don't have any systems with integrated audio. And doing a quick ldd against gnome-cd and i'm not seeing any obvious libgst* references that would indicate gnome-cd is actually using gst at all. So I'm not sure this is an easy gst plugin fix. -jef From feliciano.matias at free.fr Wed Jan 26 00:26:16 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Wed, 26 Jan 2005 01:26:16 +0100 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: <604aa79105012514452c79558@mail.gmail.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> Message-ID: <1106699176.13951.24.camel@one.myworld> Le mardi 25 janvier 2005 ? 17:45 -0500, Jeff Spaleta a ?crit : > On Tue, 25 Jan 2005 14:44:43 -0500 (EST), Elliot Lee wrote: > > Hey, I really appreciate all the discussion about packages that could be > > removed. Is there someone who's willing to read through the thread and > > collecte all the proposed removals so we can examine move forward with > > them? > > Read through the "further removals/potential package removals" thread > Here's the summary list of suggested removals/moves and the person who > made them. > > Bill Notting: > xloadimage > nedit > jed > Peter Robinson: > Can we also get rid / move to extras all the non > GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK > 1 cruft as well? > F?liciano Matias: Humm. > move to extras dosfstools Forget this one. It seems very useful for too many people. > move to extras Lynx (or elinks) There are some objections : m g : - "Also, both are key parts of my "ssh in and fix an HTML-interface- onlyuter" toolbox. Depending on the HTML/authentication/router, one will work and one will not. In my experience in Freenode's #fedora, I'm not alone in this use. Alan Cox : - "lynx is needed for mutt to do html reading on text logins. Its also fairlyportant for accessibility for some users." But Luciano Miguel Ferreira Rocha reply with : - "I prefer to use elinks on mutt: text/html; links -dump -dump-charset iso-8859-1 -default-mime-type text/html %s; copiousoutput;" > move to extras lesstif and/or openmotif21 Or remove. No package in FC use lesstif or openmotif21. > leave openmotif which is used by: > stardict, ddd, xpdf, nedit, iiimf-le-chinput > move to extras xpdf Depend on the status evince : http://www.gnome.org/projects/evince/ btw, if evince "rocks" perhaps gpdf can also be moved to extras. > move to extras ddd > Remove rpmdb. Or rpmdb should not provide /usr/lib/rpmdb/i386-redhat-linux/redhat/ (97 Mo) but a tool to generate the rpmdb base (like rpmdb-fedora.spec does). > move experimental gcc (gcc4 in FC3 for example) to Fedora Extra. Depend if experimental gcc is _only_ an experimental compiler. In FC3 java seems to depend on gcc4. Jeremy Katz : - "Unfortunately, a lot of the java stuff right now is depending on gcc4 just because that's where the work is happening. Thus, tough call. On the note of the free java stuff... gcj is really coming along impressively in the things it can run now." > Alax Cox: > Possibly joe into extras > Nicolas Mailhot : > Even better : get rid of all the stuff that doesn't use fontconfig > yet > > > -jef > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From barryn at pobox.com Wed Jan 26 00:34:58 2005 From: barryn at pobox.com (Barry K. Nathan) Date: Tue, 25 Jan 2005 16:34:58 -0800 Subject: rawhide report: 20050121 changes In-Reply-To: <878y6hrs9h.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106482308.6306.52.camel@rousalka.dyndns.org> <878y6hrs9h.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20050126003458.GA5867@ip68-4-98-123.oc.oc.cox.net> On Wed, Jan 26, 2005 at 12:41:30AM +0100, Enrico Scholz wrote: > Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) writes: > > > A gtk port means fontconfig and AA ie all the users that do not use pure ^^^^^^^^^^ > > american files on a 75dpi screen can get some mileage out of emacs ^^^^^^^^^^^^^^ > > without ruining their eyes. I've added emphasis here... think about people who are not using a 75dpi-100dpi screen. e.g. think about a 135 DPI (or so) screen. > Ok, some assumptions: > > * text apps used by me (XEmacs, xterm) are configured for 10pt fonts. I > want to see much information and do not want larger fonts therefore, > but fonts <10pt are too small for me [snip...] Are you assuming that 10 points == 10 pixels, or at least that 10 points is the same number of pixels on all screens? > * standard bitmap fonts for 10pt are of perfect quality (I am using them > currently and do not know how they could be enhanced) Now, find perfect quality bitmap fonts that will display at 10 points on a 135DPI display... IME, bitmap fonts for text editors are the height of perfection on a 15" 1024x768 LCD and the bane of my existence on a 15" 1600x1200 LCD. (Incidentally I no longer have the latter screen; it was in a notebook, and when I replaced that notebook, I decided to give up some DPI in order to have a built-in wacom tablet instead.) > AA fonts might be ok for applications with large fonts (graphic or > presentation programs, ogg players), but bitmap fonts are the best for > pure text based apps. On a high-res screen, a 10-point font has as many pixels as a 16- or 18-point font on a more typical screen... (Or even more if we're talking about a 200+ DPI screen, although I've never owned one and probably won't be buying one anytime soon.) -Barry K. Nathan From burn at goldweb.com.au Wed Jan 26 00:40:13 2005 From: burn at goldweb.com.au (Burn Alting) Date: Wed, 26 Jan 2005 11:40:13 +1100 Subject: Problems with SG_IO ioctls on sd device (verses sg device) Message-ID: <1106700013.26384.1.camel@swtf.comptex.com.au> All, I need help. I am using ftp.kernel.org's linux-2.6.10 on a Fedora Core 3 system. I eventually want my code to work on a 'clean' Fedora Core system, but I have put the ftp.kernel.org's kernel up so I can cross-test the same devices with /dev/sgX. I have a problem when I use /dev/sdX as opposed to /dev/sgX (eg /dev/sda compared to /dev/sg0). I am setting up SCSI write commands of arbitrary size, in an sg_io_hdr_t and sending the command to the device with a SG_IO ioctl call. I am using a LSI Logic LSIFC929 as the HBA in a Dual Xeon server and a raid as the target. I can issue writes up to 2048 blocks in size to /dev/sg0 but when I write this many to /dev/sda (with the same code), it fails. The failure has something to do with the __bio_add_page() routine in fs/bio.c. I am sailing in totally uncharted waters in this code, hence my call for help. Firstly, SHOULD an SG_IO ioctl() call sent to a /dev/sg device work fine and NOT work when the same SG_IO ioctl() call be sent to /dev/sda. I realise that the ioctl() calls execute different code, but conceptually should they both generate the same command to the device? If they should, then I include some debug output below of a simple program that set's the SG_RESERVED_SIZE to: 4194304, allocates paged aligned memory and then forms a 512 block write to location 1 on the target. Directly after a reboot of the kernel, the ioctl() write to /dev/sda works, but the next time it fails with an EINVAL result. The following occurs when my write of say 512 blocks is sent to /dev/sda. drivers/block/scsi_ioctl.c:scsi_cmd_ioctl() gets called which in the switch calls drivers/block/scsi_ioctl.c:sg_io(). Everything in sg_io() is fine until the call to blk_rq_map_user() which returns -22 (EINVAL). In the test of q->max_sectors is ok as is the length and buffer existance. rq = blk_get_request(q, rw, __GFP_WAIT); is fine but bio = bio_map_user(q, NULL, uaddr, len, rw == READ); returns an error status. We get into fs/bio.c:bio_map_user() which calls __bio_map_user() which is the problem. For a 512 block write, we require 64 * PAGE_SIZE (it's 4K) so the code in fs/bio.c:__bio_map_user() looks like ... /* * transfer and buffer must be aligned to at least hardsector * size for now, in the future we can relax this restriction */ if ((uaddr & queue_dma_alignment(q)) || (len & queue_dma_alignment (q))) { printk("Q %p bad alignment\n", q); return ERR_PTR(-EINVAL); } bio = bio_alloc(GFP_KERNEL, nr_pages); if (!bio) { printk("Q %p - no bio_alloc\n", q); return ERR_PTR(-ENOMEM); } ret = -ENOMEM; pages = kmalloc(nr_pages * sizeof(struct page *), GFP_KERNEL); if (!pages) { printk("Q %p - no kmalloc\n", q); goto out; } down_read(¤t->mm->mmap_sem); ret = get_user_pages(current, current->mm, uaddr, nr_pages, write_to_vm, 0, pages, NULL); up_read(¤t->mm->mmap_sem); if (ret < nr_pages) { printk("ret %d < nr_pages %d\n", ret, nr_pages); goto out; } bio->bi_bdev = bdev; offset = uaddr & ~PAGE_MASK; printk("ret = %d offset = %d, nr_pages = %d, len = %u\n", ret, offset, nr_pages, len); for (i = 0; i < nr_pages; i++) { unsigned int bytes = PAGE_SIZE - offset; printk("i = %2d bytes %u len %u\n", i, bytes, len); if (len <= 0) break; if (bytes > len) bytes = len; /* * sorry... */ k = __bio_add_page(q, bio, pages[i], bytes, offset); printk("__bio_add_page() returns = %d and bytes is %d\n", k, bytes); if (k < bytes) break; len -= bytes; offset = 0; } printk("i = %d, nr_pages = %d, PAGE_SIZE %lu\n", i, nr_pages, PAGE_SIZE); /* * release the pages we didn't map into the bio, if any */ while (i < nr_pages) page_cache_release(pages[i++]); kfree(pages); /* * set data direction, and check if mapped pages need bouncing */ if (!write_to_vm) bio->bi_rw |= (1 << BIO_RW); bio->bi_flags |= (1 << BIO_USER_MAPPED); return bio; out: kfree(pages); bio_put(bio); printk("returns bad q %p\n", q); return ERR_PTR(ret); and the printk's show (for two successive 512 block writes - the first works, but the second fails) ... Jan 26 00:49:17 swtf2 kernel: ret = 64 offset = 0, nr_pages = 64, len = 262144 Jan 26 00:49:17 swtf2 kernel: i = 0 bytes 4096 len 262144 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 1 bytes 4096 len 258048 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 2 bytes 4096 len 253952 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 3 bytes 4096 len 249856 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 4 bytes 4096 len 245760 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 5 bytes 4096 len 241664 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 6 bytes 4096 len 237568 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 7 bytes 4096 len 233472 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 8 bytes 4096 len 229376 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 9 bytes 4096 len 225280 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 10 bytes 4096 len 221184 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 11 bytes 4096 len 217088 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 12 bytes 4096 len 212992 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 13 bytes 4096 len 208896 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 14 bytes 4096 len 204800 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 15 bytes 4096 len 200704 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 16 bytes 4096 len 196608 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 17 bytes 4096 len 192512 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 18 bytes 4096 len 188416 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 19 bytes 4096 len 184320 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 20 bytes 4096 len 180224 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 21 bytes 4096 len 176128 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 22 bytes 4096 len 172032 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 23 bytes 4096 len 167936 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 24 bytes 4096 len 163840 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 25 bytes 4096 len 159744 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 26 bytes 4096 len 155648 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 27 bytes 4096 len 151552 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 28 bytes 4096 len 147456 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 29 bytes 4096 len 143360 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 30 bytes 4096 len 139264 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 31 bytes 4096 len 135168 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 32 bytes 4096 len 131072 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 33 bytes 4096 len 126976 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 34 bytes 4096 len 122880 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 35 bytes 4096 len 118784 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 36 bytes 4096 len 114688 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 37 bytes 4096 len 110592 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 38 bytes 4096 len 106496 Jan 26 00:49:17 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:17 swtf2 kernel: i = 39 bytes 4096 len 102400 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 40 bytes 4096 len 98304 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 41 bytes 4096 len 94208 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 42 bytes 4096 len 90112 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 43 bytes 4096 len 86016 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 44 bytes 4096 len 81920 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 45 bytes 4096 len 77824 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 46 bytes 4096 len 73728 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 47 bytes 4096 len 69632 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 48 bytes 4096 len 65536 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 49 bytes 4096 len 61440 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 50 bytes 4096 len 57344 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 51 bytes 4096 len 53248 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 52 bytes 4096 len 49152 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 53 bytes 4096 len 45056 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 54 bytes 4096 len 40960 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 55 bytes 4096 len 36864 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 56 bytes 4096 len 32768 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 57 bytes 4096 len 28672 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 58 bytes 4096 len 24576 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 59 bytes 4096 len 20480 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 60 bytes 4096 len 16384 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 61 bytes 4096 len 12288 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 62 bytes 4096 len 8192 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 63 bytes 4096 len 4096 Jan 26 00:49:18 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:18 swtf2 kernel: i = 64, nr_pages = 64, PAGE_SIZE 4096 Jan 26 00:49:21 swtf2 kernel: ret = 64 offset = 0, nr_pages = 64, len = 262144 Jan 26 00:49:21 swtf2 kernel: i = 0 bytes 4096 len 262144 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 1 bytes 4096 len 258048 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 2 bytes 4096 len 253952 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 3 bytes 4096 len 249856 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 4 bytes 4096 len 245760 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 5 bytes 4096 len 241664 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 6 bytes 4096 len 237568 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 7 bytes 4096 len 233472 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 8 bytes 4096 len 229376 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 9 bytes 4096 len 225280 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 10 bytes 4096 len 221184 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 11 bytes 4096 len 217088 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 12 bytes 4096 len 212992 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 13 bytes 4096 len 208896 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 14 bytes 4096 len 204800 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 15 bytes 4096 len 200704 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 16 bytes 4096 len 196608 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 17 bytes 4096 len 192512 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 18 bytes 4096 len 188416 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 19 bytes 4096 len 184320 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 20 bytes 4096 len 180224 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 21 bytes 4096 len 176128 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 22 bytes 4096 len 172032 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 23 bytes 4096 len 167936 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 24 bytes 4096 len 163840 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 25 bytes 4096 len 159744 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 26 bytes 4096 len 155648 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 27 bytes 4096 len 151552 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 28 bytes 4096 len 147456 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 29 bytes 4096 len 143360 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 30 bytes 4096 len 139264 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 31 bytes 4096 len 135168 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 32 bytes 4096 len 131072 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 33 bytes 4096 len 126976 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 34 bytes 4096 len 122880 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 35 bytes 4096 len 118784 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 36 bytes 4096 len 114688 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 37 bytes 4096 len 110592 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 38 bytes 4096 len 106496 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 39 bytes 4096 len 102400 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 40 bytes 4096 len 98304 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 41 bytes 4096 len 94208 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 42 bytes 4096 len 90112 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 43 bytes 4096 len 86016 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 44 bytes 4096 len 81920 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 45 bytes 4096 len 77824 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 46 bytes 4096 len 73728 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 47 bytes 4096 len 69632 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 48 bytes 4096 len 65536 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 49 bytes 4096 len 61440 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 50 bytes 4096 len 57344 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 51 bytes 4096 len 53248 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 52 bytes 4096 len 49152 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 53 bytes 4096 len 45056 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 54 bytes 4096 len 40960 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 4096 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 55 bytes 4096 len 36864 Jan 26 00:49:21 swtf2 kernel: __bio_add_page() returns = 0 and bytes is 4096 Jan 26 00:49:21 swtf2 kernel: i = 55, nr_pages = 64, PAGE_SIZE 4096 Jan 26 00:49:21 swtf2 kernel: bio->bi_size = 225280 and len = 262144 Jan 26 00:49:21 swtf2 kernel: bio_map_user 2 q f7d5864c Jan 26 00:49:21 swtf2 kernel: bio is the error Jan 26 00:49:21 swtf2 kernel: blk_rq_map_user(Q f7d5864c) returns -22 Is anything more needed? Can anyone help? Regards Burn Alting burn at goldweb.com.au From tadams-lists at myrealbox.com Wed Jan 26 01:10:22 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Tue, 25 Jan 2005 18:10:22 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <604aa7910501251621c61be03@mail.gmail.com> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <604aa7910501251522372fd08e@mail.gmail.com> <1106698229.3393.2.camel@localhost.localdomain> <604aa7910501251621c61be03@mail.gmail.com> Message-ID: <1106701823.3393.4.camel@localhost.localdomain> On Tue, 2005-01-25 at 19:21 -0500, Jeff Spaleta wrote: > On Tue, 25 Jan 2005 17:10:29 -0700, Trever L. Adams > wrote: > > For someone who understands gstreamer, this should be a VERY simple > > plugin to write I would think. > > shrug.. i was just pointing out one of the primary reasons i see fc3 > users are still using xmms. > I'll let other people decide if this is an important enough reason to > keep xmms in Core or not. Perhaps the gtk2 based beep can be used > instead to fill the same role so that the older gtk libs can be > removed from core. > That was my intent, the old libraries would be nice to lose. > And i'm not even sure this is a simple gst plugin fix. Does rhythmbox > even play audio cds? Typically what i see happening when novice users > try to play cds on their gnome fc3 desktops is gnome-cd will open up > and start accessing the audio cd. If their system doesn't have an > analog audio connection between the soundcard and the cd unit .... > there is no sound.... gnome-cd plays.. but there is no sound. Seems > to afflict a number of users who have integrated audio hardware > instead of an actual soundcard.. but I can't speak first hand since I > don't have any systems with integrated audio. And doing a quick ldd > against gnome-cd and i'm not seeing any obvious libgst* references > that would indicate gnome-cd is actually using gst at all. So I'm not > sure this is an easy gst plugin fix. > > -jef > I am afraid you are right, but gnome-cd could be rewritten to use gst framework and play both ways. Trever -- "There is great value in disaster. All our mistakes are burned up. Thank God we can start anew." -- Thomas Alva Edison, December 9, 1914 From katzj at redhat.com Wed Jan 26 01:13:13 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 25 Jan 2005 20:13:13 -0500 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <21FCA8D9-6F24-11D9-B78E-000D9352858E@linuxmail.org> References: <1106629396.28420.92.camel@bree.local.net> <21FCA8D9-6F24-11D9-B78E-000D9352858E@linuxmail.org> Message-ID: <1106701993.28420.138.camel@bree.local.net> On Tue, 2005-01-25 at 23:54 +0100, Felipe Alfaro Solana wrote: > On 25 Jan 2005, at 06:03, Jeremy Katz wrote: > > Then, you should be able to install the xen and kernel-xen0 packages. > > Once this is done, you should have an entry set up in your grub.conf to > > boot the xen0 kernel. Now, reboot into your new xen0 kernel [3] > > Does kernel-xen0 still install the wrong entries into grub.conf? > I'm bk pulling directly from the -unstable branch of Xen, so I can't > test this currently. A combination of grubby and kernel package changes got this working last week (hence the note about mkinitrd 4.2.0). That was part of what I was trying to get done before posting this :) Jeremy From enrico.scholz at informatik.tu-chemnitz.de Wed Jan 26 01:13:16 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 26 Jan 2005 02:13:16 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <20050126003458.GA5867@ip68-4-98-123.oc.oc.cox.net> (Barry K. Nathan's message of "Tue, 25 Jan 2005 16:34:58 -0800") References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106482308.6306.52.camel@rousalka.dyndns.org> <878y6hrs9h.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050126003458.GA5867@ip68-4-98-123.oc.oc.cox.net> Message-ID: <87zmyxq9g3.fsf@kosh.ultra.csn.tu-chemnitz.de> barryn at pobox.com ("Barry K. Nathan") writes: >> > A gtk port means fontconfig and AA ie all the users that do not use pure > ^^^^^^^^^^ >> > american files on a 75dpi screen can get some mileage out of emacs > ^^^^^^^^^^^^^^ >> > without ruining their eyes. > > I've added emphasis here... think about people who are not using a > 75dpi-100dpi screen. e.g. think about a 135 DPI (or so) screen. How common are such resolutions? 19" TFTs with 1280x1024 (90dpi) should be the typical usecase. When the minority with >=135dpi is large enough, bitmap-fonts for this resolution can be created. >> * text apps used by me (XEmacs, xterm) are configured for 10pt fonts. I >> want to see much information and do not want larger fonts therefore, >> but fonts <10pt are too small for me > [snip...] > > Are you assuming that 10 points == 10 pixels, or at least that 10 > points is the same number of pixels on all screens? I am very untalented in font questions... I just know that bitmap-fonts look perfect while AA fonts are crappy. For text based applications I do not need device independent sizes; the text must be only readable. >> * standard bitmap fonts for 10pt are of perfect quality (I am using them >> currently and do not know how they could be enhanced) > > Now, find perfect quality bitmap fonts that will display at 10 points on > a 135DPI display... IME, bitmap fonts for text editors are the height of > perfection on a 15" 1024x768 LCD and the bane of my existence on a 15" > 1600x1200 LCD. I use them on 13" TFT + 15" CRT 1024x768, 17" 1152x768 (CRT) + 1280x1024 (TFT), 19" TFT 1280x1024 and 22" CRT 1600x1200, and bitmap fonts look perfect there. Enrico From barryn at pobox.com Wed Jan 26 02:54:32 2005 From: barryn at pobox.com (Barry K. Nathan) Date: Tue, 25 Jan 2005 18:54:32 -0800 Subject: rawhide report: 20050121 changes In-Reply-To: <87zmyxq9g3.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106482308.6306.52.camel@rousalka.dyndns.org> <878y6hrs9h.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050126003458.GA5867@ip68-4-98-123.oc.oc.cox.net> <87zmyxq9g3.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20050126025432.GB5867@ip68-4-98-123.oc.oc.cox.net> On Wed, Jan 26, 2005 at 02:13:16AM +0100, Enrico Scholz wrote: > How common are such resolutions? 19" TFTs with 1280x1024 (90dpi) should > be the typical usecase. When the minority with >=135dpi is large enough, > bitmap-fonts for this resolution can be created. Yeah, but with those kinds of resolutions, you have enough pixels to work with that you get benefits from AA and subpixel rendering, at least in my experience. (Can subpixel rendering even be done with bitmap fonts?) Fontconfig, AA, etc. gives absolutely beautiful text on these displays *today*. I'm not saying AA should be force-enabled on all text editors and terminals, just that users should have it as an available option. > For text based applications I do not need device independent sizes; the > text must be only readable. On high-DPI displays, my personal experience is that the best way to get readable text is to have device-independent sizes. That's my experience under both Linux and Windows. > > Now, find perfect quality bitmap fonts that will display at 10 points on > > a 135DPI display... IME, bitmap fonts for text editors are the height of > > perfection on a 15" 1024x768 LCD and the bane of my existence on a 15" > > 1600x1200 LCD. > > I use them on 13" TFT + 15" CRT 1024x768, 17" 1152x768 (CRT) + 1280x1024 > (TFT), 19" TFT 1280x1024 and 22" CRT 1600x1200, and bitmap fonts look > perfect there. To clarify what I meant: On a high-DPI display, a "perfect" 9 or 10-point bitmap font is too small, and once you switch to a bitmap font that's large enough, you end up getting a better appearance from antialiased non-bitmap fonts for those sizes anyway. -Barry K. Nathan From shiva at sewingwitch.com Wed Jan 26 03:26:35 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Tue, 25 Jan 2005 19:26:35 -0800 Subject: Packet Inspection In-Reply-To: <200501250859.18934.remco@rvt.com> References: <41F5303D.8050305@israel-jugendtag.ch> <200501250859.18934.remco@rvt.com> Message-ID: <47A55C754044B6D0F47E13CE@[10.0.0.4]> --On Tuesday, January 25, 2005 8:59 AM -0800 Remco Treffkorn wrote: > Very observant. Both 'package' and 'packet' translate into German as > 'Packet'. Aha. Never thought about the etymology before. Here's the entries for the two at my favorite dictionary site: So "package" is something that has been packed, and "packet" is a small package. Does German have something like the English (or is it French?) "ette" suffix for creating diminutives from other words? From katzj at redhat.com Wed Jan 26 04:31:37 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 25 Jan 2005 23:31:37 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106701823.3393.4.camel@localhost.localdomain> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <604aa7910501251522372fd08e@mail.gmail.com> <1106698229.3393.2.camel@localhost.localdomain> <604aa7910501251621c61be03@mail.gmail.com> <1106701823.3393.4.camel@localhost.localdomain> Message-ID: <1106713897.28420.142.camel@bree.local.net> On Tue, 2005-01-25 at 18:10 -0700, Trever L. Adams wrote: > I am afraid you are right, but gnome-cd could be rewritten to use gst > framework and play both ways. I thought gnome-cd was using gstreamer these days... Aha, looking at the source, it was done but disabled right before the GNOME 2.8 release. Looking in CVS, it looks to be re-enabled [1] for gnome-media 2.9.x (which, since we should be including GNOME 2.10 in FC4, will be included) so we actually should be good on this count for FC4. Jeremy [1] Relevant changelog entry... 2004-11-26 Ronald S. Bultje * gnome-cd/Makefile.am: * gnome-cd/gnome-cd.c: (main): * gnome-cd/gst-cdparanoia-cdrom.c: (cb_error), (build_pipeline): Add CDDA-based CD (as default). For those poor Mac/Dell users whose computer suppliers are too crapped to add a cable between CD drive and soundcard (#51152). From tibbs at math.uh.edu Wed Jan 26 04:48:30 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Tue, 25 Jan 2005 22:48:30 -0600 Subject: rawhide report: 20050121 changes In-Reply-To: <87zmyxq9g3.fsf@kosh.ultra.csn.tu-chemnitz.de> (Enrico Scholz's message of "Wed, 26 Jan 2005 02:13:16 +0100") References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106482308.6306.52.camel@rousalka.dyndns.org> <878y6hrs9h.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050126003458.GA5867@ip68-4-98-123.oc.oc.cox.net> <87zmyxq9g3.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: >>>>> "ES" == Enrico Scholz writes: ES> I use them on 13" TFT + 15" CRT 1024x768, 17" 1152x768 (CRT) + ES> 1280x1024 (TFT), 19" TFT 1280x1024 and 22" CRT 1600x1200, and ES> bitmap fonts look perfect there. I simply can't agree. I run emacs through Konsole just so that I can get good looking antialiased fonts with subpixel rendering. Occasionally I forget to specify "-nw" and I get this nasty pixelated crap-looking text. When I use a windows machine I'm always repulsed by the horrible looking small pixelated fonts when that's the size where subpixel rendering is needed the most. For the font sizes I use (9 point Andale Mono on a 21" 1600x1200 LCD), there is simply no substitute for tripling the effective horizontal resolution. Without subpixel rendering there simply aren't enough dots to render an '@', but it looks really nice on my screen. Things may be different on CRTs; I haven't tried to use one in years. However, the mere suggestion that the possibility of using antialiased fonts in text applications should be avoided simply because you think bitmaps are sufficient is ludicrous. You can still use bitmap fonts through fontconfig if you like, so you don't lose anything. - J< From jspaleta at gmail.com Wed Jan 26 05:24:24 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 26 Jan 2005 00:24:24 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106713897.28420.142.camel@bree.local.net> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <604aa7910501251522372fd08e@mail.gmail.com> <1106698229.3393.2.camel@localhost.localdomain> <604aa7910501251621c61be03@mail.gmail.com> <1106701823.3393.4.camel@localhost.localdomain> <1106713897.28420.142.camel@bree.local.net> Message-ID: <604aa791050125212438b47c33@mail.gmail.com> On Tue, 25 Jan 2005 23:31:37 -0500, Jeremy Katz wrote: > Aha, looking at the source, it was done but disabled right before the > GNOME 2.8 release. Looking in CVS, it looks to be re-enabled [1] for > gnome-media 2.9.x (which, since we should be including GNOME 2.10 in > FC4, will be included) so we actually should be good on this count for > FC4. if its not disabled again right before release you mean.... mutter, grumble. hopefully when the gnome-media 2.9.x packages hit rawhide.. someone using the affected hardware will test this to make sure the issue is dead. -jef"if I had a nickel for every time this 'my cds won't play' issue has come up...."spaleta From richard.hubbell at gmail.com Wed Jan 26 05:31:49 2005 From: richard.hubbell at gmail.com (Richard Hubbell) Date: Tue, 25 Jan 2005 21:31:49 -0800 Subject: gcc bug in fc 3 Message-ID: I installed a plain vanilla FC3, it only has xdm and xfce, no gnome or kde. I was unable to run neither mozilla (dies in PR_dtoa) nor firefox (dies in JS_dtostr). Digging and digging I found out that gcc seems to be the problem, maybe. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17560 The only part that doesn't fit is that I wasn't using any optimizations as far as I know, unless the they occur even with --enable-debug I tried a Makefile patch I ran across that explicitly turns off optimizations for prdtoa.c. The problem shows up later during the build when PR_dtoa gets used by shlibsign. Anyone know what's going wrong? Please tell me I just need to install some package to fix this. tia, Richard From lux at diesel-research.com Wed Jan 26 07:34:43 2005 From: lux at diesel-research.com (Kim Lux) Date: Wed, 26 Jan 2005 00:34:43 -0700 Subject: 2.6.10-1.737 smp kernel crashes SOLVED. In-Reply-To: <1105497343.5833.8.camel@localhost.localdomain> References: <1105460226.6007.5.camel@localhost.localdomain> <20050111221558.0ec6d94b@python2> <20050111212115.GB1393@nostromo.devel.redhat.com> <1105496070.5833.3.camel@localhost.localdomain> <1105497343.5833.8.camel@localhost.localdomain> Message-ID: <1106724883.7307.3.camel@localhost.localdomain> I resolved this problem after downloading and installing kernel 2.6.10-1.753 and having it crash. I think the problem was that I was running ndiswrapper-0.12 with a kernel using a 4K stack. I happened to notice the ndiswrapper warning message scroll by when I built it for 2.6.10-1.753. After it crashed like all the other kernels, I downloaded its source and built it stock without the 4K stack. It has not crashed since. It appears that ndiswrapper will crash kernels built with 4K stacks. This means one must build a custom kernel every time there is a kernel update. On Tue, 2005-01-11 at 19:35 -0700, Kim Lux wrote: > cpuinfo was run when running 2.6.9-1.727 NON SMP. If/When I run it with > an smp kernel, it shows 2 kernels, kernel 0 and kernel 1. > > On Tue, 2005-01-11 at 19:14 -0700, Kim Lux wrote: > > Yep. It is an HP zd7280 which has a 3.2 GHz P4 HT processor. The > > battery life isn't good, but I don't wait long for compiles. > > > > > > $ cat cpuinfo > > processor : 0 > > vendor_id : GenuineIntel > > cpu family : 15 > > model : 2 > > model name : Intel(R) Pentium(R) 4 CPU 3.20GHz > > stepping : 9 > > cpu MHz : 3192.370 > > cache size : 512 KB > > fdiv_bug : no > > hlt_bug : no > > f00f_bug : no > > coma_bug : no > > fpu : yes > > fpu_exception : yes > > cpuid level : 2 > > wp : yes > > flags : fpu vme de tsc msr pae mce cx8 apic mtrr pge mca cmov > > pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr > > bogomips : 6324.22 > > > > > > > > On Tue, 2005-01-11 at 16:21 -0500, Bill Nottingham wrote: > > > Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > > > > Anyway... the 2.6.10-1.737 smp kernel is NOT stable on my laptop. > > > > > > > > SMP kernel on a laptop? I'm not sure I get the point :-) > > > > > > Laptop with non-mobile P4 with HT? > > > > > > Bill > > > > > -- > > Kim Lux, Diesel Research Inc. > > > > > -- > Kim Lux, Diesel Research Inc. > > -- Kim Lux, Diesel Research Inc. From i_p_a_u_l at yahoo.com Wed Jan 26 07:56:13 2005 From: i_p_a_u_l at yahoo.com (Paul Ionescu) Date: Wed, 26 Jan 2005 09:56:13 +0200 Subject: HAL ejects References: <1106639336.29380.9.camel@localhost.localdomain> <1106669254.4166.31.camel@daxter.boston.redhat.com> Message-ID: Hi, > Most drives don't report "eject button pressed" asynchronously - some HP > drives do, some others as well, but not a lot. We *could* make hal catch > this signal (if the drive supports it) and propagate it all the way of > the stack; it would look like this > > 1. Eject is pressed; door doesn't open 2. (up to 0.999.. seconds later) > hald is notified that someone > pressed eject; hald broadcasts a signal > 3. gnome-vfs (or whatever) catches the signal and sends out the > preunmount signals > 4. apps close their open files and ACK's the preunmount 5. gnome-vfs > unmounts the drive; if there are still apps with > open fd's the unmount fails. gnome-vfs puts up nice dialog. > 6. door is unlocked; disc is ejected > > But since only few drives support this I'm not happy about providing two > different user experiences. > >> It is already in FC3 >> I am using it right now. >> I think it is not in HAL, but in GVM. However, to be able to use it, >> you have to disable "lock on mount" option of cdrom by "echo 0 > >> /proc/sys/dev/cdrom/lock" or putting "dev.cdrom.lock = 0" in >> /etc/sysctl.conf and reloading with sysctl -p. >> >> > No, that's bad advice. What happens in that setup is the following > > 1. Eject is pressed; door opens > 2. hald polls for media; oops no media 3. hald lazy unmounts /dev/cdrom > - the media is gone so we have to > deal with it somehow; it's better than doing nothing > 4. all your programs with open fd's on /media/cdrom is screwed Yes, but M$ Windows users are expecting this behavior. Windows does the same thing, and there are a lot of people who are used to this. Besides, there are a lot of programs that will not be ever able to be notified about an event like this. And usually, in my 5 months experience with it, the "screwed" programs will just say something about unable to read some file or directory. > It's get even more fun if you're writing to the CD. The writing program can take care of this by locking the CD door when writing, and restoring after that. If it is packet writing, then it should be locked on mounting it rw. > The real solution is to use something along the lines of volumagic > which is like supermount but only in userspace. There is no such thing yet. From i_p_a_u_l at yahoo.com Wed Jan 26 08:01:32 2005 From: i_p_a_u_l at yahoo.com (Paul Ionescu) Date: Wed, 26 Jan 2005 10:01:32 +0200 Subject: HAL ejects References: <1106639336.29380.9.camel@localhost.localdomain> <1106645834.19325.2.camel@localhost.localdomain> <1106667674.2657.6.camel@localhost.localdomain> <1106674952.2657.18.camel@localhost.localdomain> Message-ID: Hi, On Tue, 25 Jan 2005 18:42:33 +0100, Kyrre Ness Sjobak wrote: > > Just a thougth - what would happen if somebody should be as unlucky to > push "eject" when there is an open file on the device? The message we all > love (not!) would pop up? Well, depend on what application has this open file. Usually, the cdrom gets lazy unmounted, and the application will still try to access that file, and finally you will probably get an error from that application that is unable to read the file. IMO is better than having to search in 20 windows where is that app that uses the cdrom and I cannot unmount the cdrom because of it, and I am in a hurry and I want my cd out NOW. From Axel.Thimm at ATrpms.net Wed Jan 26 08:31:31 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Wed, 26 Jan 2005 09:31:31 +0100 Subject: rpm definitions of Obsoletes/Provides/... (was: RFC: Soname in rpm name) In-Reply-To: <41F66C21.50401@nc.rr.com> References: <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <1106661197.23277.81.camel@cutter> <20050125161043.6bb64de2.fedora@wir-sind-cool.org> <41F66C21.50401@nc.rr.com> Message-ID: <20050126083131.GF25537@neu.nirvana> On Tue, Jan 25, 2005 at 10:56:17AM -0500, Jeff Johnson wrote: > Obsoletes: has changed to erase a package that contains a virtual > provides for exactly this reason. Unless it is provided by the same package like the usual Provides: foo Obsoletes: foo [<= ...] But it is even worse, if two different packages provide/obsolete foo, now they obsolete each-other, too. That's unexpected behaviour IMHO. Furthermore Provides: currently also effectively implies Obsoletes, but only for non-virtual Provides (e.g. a package name). That's the bug^Wfeature that has troubled PyVault and others so much. So I agree with Jeff. There is a high need for strict definitions of what these semantics express and what rpm (and thus rpm-based resolvers) should do with it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Nicolas.Mailhot at laPoste.net Wed Jan 26 08:59:00 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 26 Jan 2005 09:59:00 +0100 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: <604aa79105012514452c79558@mail.gmail.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> Message-ID: <1106729940.7301.9.camel@ulysse.olympe.o2t> Le mardi 25 janvier 2005 ? 17:45 -0500, Jeff Spaleta a ?crit : > On Tue, 25 Jan 2005 14:44:43 -0500 (EST), Elliot Lee wrote: > F?liciano Matias: > move to extras lesstif and/or openmotif21 > leave openmotif which is used by: > stardict, ddd, xpdf, nedit, iiimf-le-chinput I'm afraid openmotif21 is still used by big closed packages like Oracle. Not that is matters much for FC, but it almost ensured a continued RHEL existence, and at this point if a package is in RHEL it can as well be kept in FC (since it will be maintained by RH, and it's nice to allow people to experiment replacing RHEL with FC for test setups even if certification grids force the use of RHEL in prod) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jakub at redhat.com Wed Jan 26 09:17:09 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 26 Jan 2005 04:17:09 -0500 Subject: gcc bug in fc 3 In-Reply-To: References: Message-ID: <20050126091709.GA10340@devserv.devel.redhat.com> On Tue, Jan 25, 2005 at 09:31:49PM -0800, Richard Hubbell wrote: > I installed a plain vanilla FC3, it only has xdm and xfce, no gnome or kde. > I was unable to run neither mozilla (dies in PR_dtoa) nor firefox > (dies in JS_dtostr). > > Digging and digging I found out that gcc seems to be the problem, maybe. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17560 Are you building your code with gcc4 or g++4? If not, PR17560 certainly is not related to your problems. Jakub From Nicolas.Mailhot at laPoste.net Wed Jan 26 09:37:12 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 26 Jan 2005 10:37:12 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106482308.6306.52.camel@rousalka.dyndns.org> <878y6hrs9h.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050126003458.GA5867@ip68-4-98-123.oc.oc.cox.net> <87zmyxq9g3.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106732233.7301.15.camel@ulysse.olympe.o2t> Le mardi 25 janvier 2005 ? 22:48 -0600, Jason L Tibbitts III a ?crit : > Things may be different on CRTs; I haven't tried to use one in years. > However, the mere suggestion that the possibility of using antialiased > fonts in text applications should be avoided simply because you think > bitmaps are sufficient is ludicrous. You can still use bitmap fonts > through fontconfig if you like, so you don't lose anything. Anyway the whole argument doesn't stand because you have all the tunables needed in fontconfig to fine-tune what kind of AA you want at what sizes in a per-user and per-font basis. 8 14 false (elapsed time : 3 min in google) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Wed Jan 26 09:47:05 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 26 Jan 2005 10:47:05 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106732826.7301.21.camel@ulysse.olympe.o2t> Le mardi 25 janvier 2005 ? 22:07 +0100, Enrico Scholz a ?crit : > tadams-lists at myrealbox.com ("Trever L. Adams") writes: > > > xmms uses gtk1 and doesn't seem to be needed; should it be removed? > > No, there is no other nice-looking mp3/ogg/... player in FC. It's not nice looking It's a disaster as soon as you change to a resolution differing from the one the author thought of Its track display can not handle half the characters you find in id3 tags these days. The controls are badly organised and only be mastered by people heavily exposed to non-standard randomized bitmap interfaces (ie Windows gamers) Do I need to continue ? -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From gauret at free.fr Wed Jan 26 10:09:37 2005 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 26 Jan 2005 11:09:37 +0100 Subject: RFC: Soname in rpm name References: <41F4D56A.1060708@nc.rr.com> <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E672.3020103@nc.rr.com> <20050124132138.2bdbc4c9.fedora@wir-sind-cool.org> <41F4EB14.3040302@nc.rr.com> Message-ID: Mike Hearn wrote: > If it's so unstable just statically link it. Nobody should be dynamically > linking against very unstable libraries I'm not really talking about my particular package here, I can deal with 4 rebuilds at the same time (actually I've already done so). I'm trying to extract some kind of packaging policy for other libraries, on which many more packages could depend. Soname changes happen, sometimes, even with stable libraries. See for example the libpng mess that occured a few years ago. Statically linking should be an exception, and I'm trying to propose a general solution. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Never trust a computer you can't throw out a window." -- Steve Wozniak From rodd at clarkson.id.au Wed Jan 26 09:54:21 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 26 Jan 2005 20:54:21 +1100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <604aa7910501251621c61be03@mail.gmail.com> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <604aa7910501251522372fd08e@mail.gmail.com> <1106698229.3393.2.camel@localhost.localdomain> <604aa7910501251621c61be03@mail.gmail.com> Message-ID: <1106733261.5235.17.camel@localhost.localdomain> On Tue, 2005-01-25 at 19:21 -0500, Jeff Spaleta wrote: > On Tue, 25 Jan 2005 17:10:29 -0700, Trever L. Adams > wrote: > > For someone who understands gstreamer, this should be a VERY simple > > plugin to write I would think. > > shrug.. i was just pointing out one of the primary reasons i see fc3 > users are still using xmms. personally, I still use grip because I have all my music sorted neatly into folders with M3U's for each album and xmms lets me just double click the file and play the album. I really don't like the interface for Rhythmbox. However, I'd be more than happy to see xmms slip into extras. Assuming Extras is done well it should still be easy to install, and I usually use 3rd party xmms installs anyway because of the lack of MP3 support in FC3. Rodd. PS. And I hope this PS doesn't start a riot but I'm going to ask anyway, I understand and respect Redhats' decision not to include MP3 support due to licensing issues. RHEL is after all a 'paid for' product and the licensing regarding MP3's is somewhat vague. However, given that Fedora Core is a download only product and that no money is exchanged for it, I can't understand why MP3 support isn't included in FC as the licensing issues for FC shouldn't be an issue. The only sane reason I can think of is that FC is used as a feeder for RHEL. This concerns me, because if this is the case, then I'm not sure how this whole community process thing for FC is going to work. It seems to me that there is a conflict if the community wants support for MP3 (which FC could have due to it being 'free of charge', or am I wrong) and RH's needs to have FC ready for use in RHEL. This is only one example, but I just wonder how this will be managed in the future as it's more than like that the 'community' will want things included that RHEL doesn't. Anyhow, I'm tuck my head in and try not to open any more cans of worms (like the whole community participation stuff which has been discussed occassionally on this list ;-] ) -- >From the pain come the dream >From the dream come the vision >From the vision come the people >From the people come the power >From this power come the change - Peter Gabriel From enrico.scholz at informatik.tu-chemnitz.de Wed Jan 26 11:00:37 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 26 Jan 2005 12:00:37 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: (Jason L. Tibbitts, III's message of "Tue, 25 Jan 2005 22:48:30 -0600") References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106482308.6306.52.camel@rousalka.dyndns.org> <878y6hrs9h.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050126003458.GA5867@ip68-4-98-123.oc.oc.cox.net> <87zmyxq9g3.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <87vf9kqwtm.fsf@kosh.ultra.csn.tu-chemnitz.de> tibbs at math.uh.edu (Jason L Tibbitts III) writes: >>>>>> "ES" == Enrico Scholz writes: > > ES> I use them on 13" TFT + 15" CRT 1024x768, 17" 1152x768 (CRT) + > ES> 1280x1024 (TFT), 19" TFT 1280x1024 and 22" CRT 1600x1200, and > ES> bitmap fonts look perfect there. > > For the font sizes I use (9 point Andale Mono on a 21" 1600x1200 LCD), never heared about this font, nor used it... Have you tried 'fixed' (which is probably Courier)? As said, it looks perfectly both in XEmacs and xterm. Enrico From enrico.scholz at informatik.tu-chemnitz.de Wed Jan 26 11:06:35 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 26 Jan 2005 12:06:35 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106732233.7301.15.camel@ulysse.olympe.o2t> (Nicolas Mailhot's message of "Wed, 26 Jan 2005 10:37:12 +0100") References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106482308.6306.52.camel@rousalka.dyndns.org> <878y6hrs9h.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050126003458.GA5867@ip68-4-98-123.oc.oc.cox.net> <87zmyxq9g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106732233.7301.15.camel@ulysse.olympe.o2t> Message-ID: <87r7k8qwjo.fsf@kosh.ultra.csn.tu-chemnitz.de> Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) writes: >> Things may be different on CRTs; I haven't tried to use one in years. >> However, the mere suggestion that the possibility of using antialiased >> fonts in text applications should be avoided simply because you think >> bitmaps are sufficient is ludicrous. You can still use bitmap fonts >> through fontconfig if you like, so you don't lose anything. > > Anyway the whole argument doesn't stand because you have all the > tunables needed in fontconfig to fine-tune what kind of AA you want at > what sizes in a per-user and per-font basis. > > > ... > > false > > > > (elapsed time : 3 min in google) and crap... this is just an argument of pro-AA people who want to demonstrate how ugly non-AA fonts are. The statements above turn just off antialiasing but still use the same render technology. With the available free fonts (bitstream), this creates disrupted lines and makes it look yet more ugly than AA. The real solution would be to use bitmap fonts. Enrico From linux00 at kornet.net Wed Jan 26 11:09:10 2005 From: linux00 at kornet.net (sangu) Date: Wed, 26 Jan 2005 20:09:10 +0900 Subject: rawhide report: 20050121 changes In-Reply-To: <1106732260106516.0.ppp8@ppp8> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106482308.6306.52.camel@rousalka.dyndns.org> <878y6hrs9h.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050126003458.GA5867@ip68-4-98-123.oc.oc.cox.net> <87zmyxq9g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106732260106516.0.ppp8@ppp8> Message-ID: <1106737750.4047.10.camel@sangu.sangu.net> Use pixelsize than size because of https://bugzilla.mozilla.org/show_bug.cgi?id=236739#c5 2005-01-26 (?), 10:37 +0100, Nicolas Mailhot ???: > Le mardi 25 janvier 2005 ? 22:48 -0600, Jason L Tibbitts III a ?crit : > > > Things may be different on CRTs; I haven't tried to use one in years. > > However, the mere suggestion that the possibility of using antialiased > > fonts in text applications should be avoided simply because you think > > bitmaps are sufficient is ludicrous. You can still use bitmap fonts > > through fontconfig if you like, so you don't lose anything. > > Anyway the whole argument doesn't stand because you have all the > tunables needed in fontconfig to fine-tune what kind of AA you want at > what sizes in a per-user and per-font basis. > > > > 8 > > > 14 > > > false > > > > (elapsed time : 3 min in google) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list From pozsy at uhulinux.hu Wed Jan 26 11:24:11 2005 From: pozsy at uhulinux.hu (Pozsar Balazs) Date: Wed, 26 Jan 2005 12:24:11 +0100 Subject: HAL ejects In-Reply-To: <1106669254.4166.31.camel@daxter.boston.redhat.com> References: <1106639336.29380.9.camel@localhost.localdomain> <1106669254.4166.31.camel@daxter.boston.redhat.com> Message-ID: <20050126112411.GD8485@unicorn.sch.bme.hu> On Tue, Jan 25, 2005 at 11:07:34AM -0500, David Zeuthen wrote: > No, that's bad advice. What happens in that setup is the following > > 1. Eject is pressed; door opens > 2. hald polls for media; oops no media > 3. hald lazy unmounts /dev/cdrom - the media is gone so we have to > deal with it somehow; it's better than doing nothing > 4. all your programs with open fd's on /media/cdrom is screwed I do not understand why they are screwed. They cannot read (or write) them anymore, but programs should really handle this... -- pozsy From enrico.scholz at informatik.tu-chemnitz.de Wed Jan 26 11:30:36 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 26 Jan 2005 12:30:36 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106732826.7301.21.camel@ulysse.olympe.o2t> (Nicolas Mailhot's message of "Wed, 26 Jan 2005 10:47:05 +0100") References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106732826.7301.21.camel@ulysse.olympe.o2t> Message-ID: <87mzuwqvfn.fsf@kosh.ultra.csn.tu-chemnitz.de> Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) writes: >> > xmms uses gtk1 and doesn't seem to be needed; should it be removed? >> >> No, there is no other nice-looking mp3/ogg/... player in FC. > ... > The controls are badly organised what would be the alternatives? Some Gnome UI crap where half of the important options can be configured with regedit only? I looked at rhythmbox and it is catastrophic for simple music listening... a huge window which requires at least the half of my screen width (the minimal window size seems to be 670x293). No way to turn off the window title, no 'pause' control, no control to influence the position within the song, a volume control where 3 small curves show the volume... As said... a typical Gnome2 application which tries to follow blindly a UI guideline without taking care about ergonomic. BMP looks good on the first glance (the screenshots); I just hope that it is a 1:1 gtk2 rewrite of xmms, and not something which tries to bring Gnome2 ideas into it (like galeon 1.3 vs. 1.2)... Enrico From peter.backlund at home.se Wed Jan 26 11:45:07 2005 From: peter.backlund at home.se (Peter Backlund) Date: Wed, 26 Jan 2005 12:45:07 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <87mzuwqvfn.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106732826.7301.21.camel@ulysse.olympe.o2t> <87mzuwqvfn.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106739907.19595.1.camel@localhost.localdomain> ons 2005-01-26 klockan 12:30 +0100 skrev Enrico Scholz: > Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) writes: > > >> > xmms uses gtk1 and doesn't seem to be needed; should it be removed? > >> > >> No, there is no other nice-looking mp3/ogg/... player in FC. > > ... > > The controls are badly organised > > what would be the alternatives? Some Gnome UI crap where half of the > important options can be configured with regedit only? > > I looked at rhythmbox and it is catastrophic for simple music listening... a > huge window which requires at least the half of my screen width (the minimal > window size seems to be 670x293). No way to turn off the window title, no > 'pause' control, no control to influence the position within the song, a > volume control where 3 small curves show the volume... As said... a typical > Gnome2 application which tries to follow blindly a UI guideline without > taking care about ergonomic. http://petrix.se/fedora/rb.png It has a pause button, it has a slider for controlling position in the songs, and the size of the window is 350x85. Pause and the slider do not appear until you play a song, which is in line with the UI guidelines. /Peter From enrico.scholz at informatik.tu-chemnitz.de Wed Jan 26 12:11:26 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 26 Jan 2005 13:11:26 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106739907.19595.1.camel@localhost.localdomain> (Peter Backlund's message of "Wed, 26 Jan 2005 12:45:07 +0100") References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106732826.7301.21.camel@ulysse.olympe.o2t> <87mzuwqvfn.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106739907.19595.1.camel@localhost.localdomain> Message-ID: <87is5kqtjl.fsf@kosh.ultra.csn.tu-chemnitz.de> peter.backlund at home.se (Peter Backlund) writes: >> I looked at rhythmbox and it is catastrophic for simple music listening... a >> huge window which requires at least the half of my screen width (the minimal >> window size seems to be 670x293). No way to turn off the window title, no >> 'pause' control, no control to influence the position within the song, a >> volume control where 3 small curves show the volume... As said... a typical >> Gnome2 application which tries to follow blindly a UI guideline without >> taking care about ergonomic. > > http://petrix.se/fedora/rb.png > > It has a pause button, it has a slider for controlling position in the > songs, and the size of the window is 350x85. > > Pause and the slider do not appear until you play a song, which is in > line with the UI guidelines. Oh... I never brought rhythmbox to play a sound -- it segfaulted shortly before (probably related with the gconf error-messages and the failed %post scriptlet). But: UI guidelines which allow that a start-button becomes a stop-button are crap (probably copied from M$ Windoze). I do not want to count how often I pressed 'stop': there should be silence regardless if I pressed 1, 23 or 42 times the 'stop' button. Enrico From thuforuk at yahoo.co.uk Wed Jan 26 12:12:30 2005 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Wed, 26 Jan 2005 12:12:30 +0000 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106739907.19595.1.camel@localhost.localdomain> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106732826.7301.21.camel@ulysse.olympe.o2t> <87mzuwqvfn.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106739907.19595.1.camel@localhost.localdomain> Message-ID: <41F7892E.2050307@yahoo.co.uk> On 01/26/2005 11:45 AM, Peter Backlund wrote: > ons 2005-01-26 klockan 12:30 +0100 skrev Enrico Scholz: > >>Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) writes: >> >> >>>>>xmms uses gtk1 and doesn't seem to be needed; should it be removed? >>>> >>>>No, there is no other nice-looking mp3/ogg/... player in FC. >>> >>>... >>>The controls are badly organised >> >>what would be the alternatives? Some Gnome UI crap where half of the >>important options can be configured with regedit only? >> >>I looked at rhythmbox and it is catastrophic for simple music listening... a >>huge window which requires at least the half of my screen width (the minimal >>window size seems to be 670x293). No way to turn off the window title, no >>'pause' control, no control to influence the position within the song, a >>volume control where 3 small curves show the volume... As said... a typical >>Gnome2 application which tries to follow blindly a UI guideline without >>taking care about ergonomic. > > > http://petrix.se/fedora/rb.png > > It has a pause button, it has a slider for controlling position in the > songs, and the size of the window is 350x85. > > Pause and the slider do not appear until you play a song, which is in > line with the UI guidelines. Yet when the window is made very wide, slider does not take advantage of additional space, it's fixed size :( Also, rhythmbox freezes when I click any of the radio stations: buffering displays for a second or two and the program freezes. When I select "small display", only title bar is displayed, window content is not there (this is the first app that does this sort of thing, I use IceWM as my window manager). Additionally usage paradigm of rhythmbox just does not "click" with me. I installed Beep Media Player yesterday and used it for a day. So far the only issue with it I have is removed "double feature", which makes it (and all the buttons) really tiny on my 1600x1200 at 21" CRT and 1280x1024 at 17" LCD (96 dpi). It may be a good replacement for xmms (although I still don't see why to seek for one ;-) Regards, Dariusz From Nicolas.Mailhot at laPoste.net Wed Jan 26 12:22:52 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 26 Jan 2005 13:22:52 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <87r7k8qwjo.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106482308.6306.52.camel@rousalka.dyndns.org> <878y6hrs9h.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050126003458.GA5867@ip68-4-98-123.oc.oc.cox.net> <87zmyxq9g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106732233.7301.15.camel@ulysse.olympe.o2t> <87r7k8qwjo.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106742173.9044.11.camel@ulysse.olympe.o2t> Le mercredi 26 janvier 2005 ? 12:06 +0100, Enrico Scholz a ?crit : > Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) writes: > > >> Things may be different on CRTs; I haven't tried to use one in years. > >> However, the mere suggestion that the possibility of using antialiased > >> fonts in text applications should be avoided simply because you think > >> bitmaps are sufficient is ludicrous. You can still use bitmap fonts > >> through fontconfig if you like, so you don't lose anything. > > > > Anyway the whole argument doesn't stand because you have all the > > tunables needed in fontconfig to fine-tune what kind of AA you want at > > what sizes in a per-user and per-font basis. > > > > > > ... > > > > false > > > > > > > > (elapsed time : 3 min in google) > > and crap... this is just an argument of pro-AA people who want to > demonstrate how ugly non-AA fonts are. > > The statements above turn just off antialiasing but still use the same > render technology. With the available free fonts (bitstream), this > creates disrupted lines and makes it look yet more ugly than AA. > > The real solution would be to use bitmap fonts. The real solution would be to use AA with a high-dpi screen like the 1999 medium-cost one I have on my desk (and have seen in countless times in other places). Hint: most screens on the market can do at least 100dpi easily, because consumers do look at the spec sheet before buying even if they end up using a ridiculously low resolution to work around broken systems like windows or emacs that still use by default the bitmap fonts chosen by their authors circa 1992. And I'm not even talking about the resolutions one would achieve if he were dumb enough to allow his screen to drop frequencies below 85 - 90 Hz. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fedora at wir-sind-cool.org Wed Jan 26 12:24:58 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Wed, 26 Jan 2005 13:24:58 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <87is5kqtjl.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106732826.7301.21.camel@ulysse.olympe.o2t> <87mzuwqvfn.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106739907.19595.1.camel@localhost.localdomain> <87is5kqtjl.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20050126132458.44ba7cb8.fedora@wir-sind-cool.org> On Wed, 26 Jan 2005 13:11:26 +0100, Enrico Scholz wrote: > Oh... I never brought rhythmbox to play a sound -- it segfaulted shortly > before (probably related with the gconf error-messages and the failed > %post scriptlet). Damn. There are various reports about such incidents with other packages, too. Maybe related. And I think it's still not known under which circumstances gconf post-install scripts fail. When that happens, gconf defaults are not created, and applications which are programmed to not handle missing defaults, give fatal errors or segfault. The quite common practise to redirect stdout/stderr of scriptlets to /dev/null is not helpful in such cases. From thuforuk at yahoo.co.uk Wed Jan 26 12:26:20 2005 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Wed, 26 Jan 2005 12:26:20 +0000 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <87mzuwqvfn.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106732826.7301.21.camel@ulysse.olympe.o2t> <87mzuwqvfn.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <41F78C6C.7060103@yahoo.co.uk> On 01/26/2005 11:30 AM, Enrico Scholz wrote: > Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) writes: > > >>>>xmms uses gtk1 and doesn't seem to be needed; should it be removed? >>> >>>No, there is no other nice-looking mp3/ogg/... player in FC. >> >>... >>The controls are badly organised > > what would be the alternatives? Some Gnome UI crap where half of the > important options can be configured with regedit only? > > BMP looks good on the first glance (the screenshots); I just hope that > it is a 1:1 gtk2 rewrite of xmms, and not something which tries to bring > Gnome2 ideas into it (like galeon 1.3 vs. 1.2)... You can get BMP from newrpms repository: bmp bmp-mp3 bmp-extra-plugins Apparently BMP is a fork of xmms and it feels like in many ways. Hint: do not try to run it when xmms is running -- it won't start. Quit xmms first. Regards, Dariusz From Nicolas.Mailhot at laPoste.net Wed Jan 26 12:28:41 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 26 Jan 2005 13:28:41 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F7892E.2050307@yahoo.co.uk> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106732826.7301.21.camel@ulysse.olympe.o2t> <87mzuwqvfn.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106739907.19595.1.camel@localhost.localdomain> <41F7892E.2050307@yahoo.co.uk> Message-ID: <1106742521.9044.16.camel@ulysse.olympe.o2t> Le mercredi 26 janvier 2005 ? 12:12 +0000, Dariusz J. Garbowski a ?crit : > and > 1280x1024 at 17" LCD (96 dpi). A real 1280*960 at 17" screen is 100dpi (you can do the math if you want). The reason windows is stuck at 96dpi is lots of first-gen 17" makers cheated and their products were either a bit smaller or could not fill all the glass space (you were stuck with a black band around the picture) At 100dpi AA looks good in all reasonable sizes (I'm not talking about the people that burn their eyes on < 10pt fonts) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From roli at israel-jugendtag.ch Wed Jan 26 12:42:39 2005 From: roli at israel-jugendtag.ch (Roland Kaeser) Date: Wed, 26 Jan 2005 13:42:39 +0100 Subject: Packet Inspection In-Reply-To: <47A55C754044B6D0F47E13CE@[10.0.0.4]> References: <41F5303D.8050305@israel-jugendtag.ch> <200501250859.18934.remco@rvt.com> <47A55C754044B6D0F47E13CE@[10.0.0.4]> Message-ID: <41F7903F.4000003@israel-jugendtag.ch> Hello Sorry I didn't got all replays to My email. Yes I ment "package inspection". Sorry this was a mispelling in the heat of the work. Does somebody know anything about this "TCP/IP Package inspection?" I really depend on a such function. Many thanks. Roland Kenneth Porter schrieb: > --On Tuesday, January 25, 2005 8:59 AM -0800 Remco Treffkorn > wrote: > >> Very observant. Both 'package' and 'packet' translate into German as >> 'Packet'. > > > Aha. Never thought about the etymology before. Here's the entries for > the two at my favorite dictionary site: > > > > > > So "package" is something that has been packed, and "packet" is a > small package. Does German have something like the English (or is it > French?) "ette" suffix for creating diminutives from other words? > -- Roland K?ser Fulachstr. 197 8200 Schaffhausen Webmaster www.Israel-Jugendtag.ch ****************************************** ** Schon vom Israel-Jugendtag geh?rt? ** ****************************************** www.israel-jugendtag.ch This e-mail is confidential. It may be read, copied and used only by the intended recipient. If you have received it in error, please contact the sender immediately by return e-mail or by telephoning.Please then delete the e-mail and do not disclose its contents to any person. We believe, but do not warrant, that this e-mail and any attachments are virus free. You should take full responsibility for virus checking. From thuforuk at yahoo.co.uk Wed Jan 26 12:51:24 2005 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Wed, 26 Jan 2005 12:51:24 +0000 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106742521.9044.16.camel@ulysse.olympe.o2t> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106732826.7301.21.camel@ulysse.olympe.o2t> <87mzuwqvfn.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106739907.19595.1.camel@localhost.localdomain> <41F7892E.2050307@yahoo.co.uk> <1106742521.9044.16.camel@ulysse.olympe.o2t> Message-ID: <41F7924C.1070600@yahoo.co.uk> On 01/26/2005 12:28 PM, Nicolas Mailhot wrote: > Le mercredi 26 janvier 2005 ? 12:12 +0000, Dariusz J. Garbowski a > ?crit : > >> and >>1280x1024 at 17" LCD (96 dpi). > > > A real 1280*960 at 17" screen is 100dpi (you can do the math if you want). I did the math ;-) Looks like: displaysize should be 13.58" x 10.19" (assuming 4:3 display ratio). So horizontal: 1280/13.58 = 94.25 dpi vertical: 1024/10.19 = 100.49 dpi Correct me if I am wrong -- this was quick calc. X reports that my display is 96 dpi, which looks like some "average" of what I just calculated. > The reason windows is stuck at 96dpi is lots of first-gen 17" makers > cheated and their products were either a bit smaller or could not fill > all the glass space (you were stuck with a black band around the > picture) > > At 100dpi AA looks good in all reasonable sizes (I'm not talking about > the people that burn their eyes on < 10pt fonts) It does look ok on LCD. However I still like my xterms with bitmap fonts -- they are superior sharp. I use other apps with AA and it's ok (e.g. Eclipse with Courier). Regards, thufor From lsomike at futzin.com Wed Jan 26 13:02:49 2005 From: lsomike at futzin.com (Mike Klinke) Date: Wed, 26 Jan 2005 07:02:49 -0600 Subject: Packet Inspection In-Reply-To: <41F7903F.4000003@israel-jugendtag.ch> References: <41F5303D.8050305@israel-jugendtag.ch> <47A55C754044B6D0F47E13CE@[10.0.0.4]> <41F7903F.4000003@israel-jugendtag.ch> Message-ID: <200501260702.49397.lsomike@futzin.com> On Wednesday 26 January 2005 06:42, Roland Kaeser wrote: > Hello > > Sorry I didn't got all replays to My email. Yes I ment "package > inspection". Sorry this was a mispelling in the heat of the work. > Does somebody know anything about this "TCP/IP Package > inspection?" I really depend on a such function. > > Many thanks. > > Roland > Any replies you may have missed can be found here: http://marc.theaimsgroup.com/?l=fedora-devel-list&r=1&w=2 Regards, Mike Klinke From rahulsundaram at yahoo.co.in Wed Jan 26 10:44:04 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Wed, 26 Jan 2005 02:44:04 -0800 (PST) Subject: slow hard drives crushing interactivity In-Reply-To: <1106610224.6122.29.camel@localhost.localdomain> Message-ID: <20050126104404.64075.qmail@web8510.mail.in.yahoo.com> Hi > > > > I wonder if CKRM (http://ckrm.sourceforge.net/) or > ilk might help you? is crkm being planned for inclusion in the upstream or fedora kernel? ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 From arjanv at redhat.com Wed Jan 26 13:23:02 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 26 Jan 2005 14:23:02 +0100 Subject: Problems with SG_IO ioctls on sd device (verses sg device) In-Reply-To: <1106700013.26384.1.camel@swtf.comptex.com.au> References: <1106700013.26384.1.camel@swtf.comptex.com.au> Message-ID: <1106745783.6307.98.camel@laptopd505.fenrus.org> On Wed, 2005-01-26 at 11:40 +1100, Burn Alting wrote: > All, > > I need help. I am using ftp.kernel.org's linux-2.6.10 on a Fedora > Core 3 system. I eventually want my code to work on a 'clean' > Fedora Core system, but I have put the ftp.kernel.org's kernel > up so I can cross-test the same devices with /dev/sgX. > > I have a problem when I use /dev/sdX as opposed to /dev/sgX (eg /dev/sda > compared to /dev/sg0). I am setting up SCSI write commands of arbitrary > size, in an sg_io_hdr_t and sending the command to the device with a > SG_IO ioctl call. I am using a LSI Logic LSIFC929 as the HBA in a Dual > Xeon server and a raid as the target. I can issue writes up to 2048 > blocks in size to /dev/sg0 but when I write this many to /dev/sda (with > the same code), it fails. this is a bug in /dev/sg0; it accepts data bigger than the device advertised it could take. The result is that it either sends it anyway (which may well blow up) or silently splits it up internally (at which point you should wonder if your app shouldn't be the one splitting it up) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From Nicolas.Mailhot at laPoste.net Wed Jan 26 13:23:45 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 26 Jan 2005 14:23:45 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F7924C.1070600@yahoo.co.uk> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106732826.7301.21.camel@ulysse.olympe.o2t> <87mzuwqvfn.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106739907.19595.1.camel@localhost.localdomain> <41F7892E.2050307@yahoo.co.uk> <1106742521.9044.16.camel@ulysse.olympe.o2t> <41F7924C.1070600@yahoo.co.uk> Message-ID: <1106745825.9044.20.camel@ulysse.olympe.o2t> Le mercredi 26 janvier 2005 ? 12:51 +0000, Dariusz J. Garbowski a ?crit : > On 01/26/2005 12:28 PM, Nicolas Mailhot wrote: > > Le mercredi 26 janvier 2005 ? 12:12 +0000, Dariusz J. Garbowski a > > ?crit : > > > >> and > >>1280x1024 at 17" LCD (96 dpi). > > > > > > A real 1280*960 at 17" screen is 100dpi (you can do the math if you want). > > I did the math ;-) Looks like: > > displaysize should be 13.58" x 10.19" (assuming 4:3 display ratio). Don't assume, measure it yourself ;) What this means of course is not all 17" screens are created equal, and sometimes the manufacturer will round to 17" when it's really a bit smaller. I have a 17" 322x241 millimeters screen. In 1280*960 thats 101x101 dpi Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rahulsundaram at yahoo.co.in Wed Jan 26 11:42:13 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Wed, 26 Jan 2005 03:42:13 -0800 (PST) Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <87mzuwqvfn.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20050126114213.50873.qmail@web8504.mail.in.yahoo.com> Hi > > what would be the alternatives? Some Gnome UI crap > where half of the > important options can be configured with regedit > only? there is no such thing as regedit in gnome. gconf is not even close. > > BMP looks good on the first glance (the > screenshots); I just hope that > it is a 1:1 gtk2 rewrite of xmms, and not something > which tries to bring > Gnome2 ideas into it (like galeon 1.3 vs. 1.2)... bmp seems worse than xmms other than looks from the discussions we had previously in this list ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From arjanv at redhat.com Wed Jan 26 13:26:09 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Wed, 26 Jan 2005 14:26:09 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <20050125211154.GC14149@devserv.devel.redhat.com> References: <1106408277.15391.17.camel@jdub.homelinux.org> <1106410993.15391.42.camel@jdub.homelinux.org> <5cf776b8050123075072835f89@mail.gmail.com> <1106498904.6129.46.camel@laptopd505.fenrus.org> <5cf776b80501231525cec0502@mail.gmail.com> <5cf776b8050125071534da28f0@mail.gmail.com> <20050125211154.GC14149@devserv.devel.redhat.com> Message-ID: <1106745969.6307.99.camel@laptopd505.fenrus.org> On Tue, 2005-01-25 at 22:11 +0100, Arjan van de Ven wrote: > On Tue, Jan 25, 2005 at 09:09:33PM +0530, Rahul Sundaram wrote: > > On Tue, 25 Jan 2005 11:15:58 -0400, mbneto wrote: > > > Ok. But since I was not able to remove myself (due to > > > dependencies...) the packages to this ~300Mb I was hoping I could get > > > (off list) the rpm -qa to compare with mine and simply remove the ones > > > missing.. > > > > I had the impression arjan seems to have to just highlighted that its > > possible and not that he has a list of packages ready to send you. > > actually I do have a list of packages; I'll send it tomorrow when I power > the box that has them on ;) > see attached list -------------- next part -------------- filesystem termcap basesystem glibc-common mktemp zlib libtermcap cracklib words iproute mount e2fsprogs libattr pcre bzip2-libs mingetty iputils ncurses grep gpm findutils pam which SysVinit modutils rpm sysklogd setup rpmdb-fedora libgcc tzdata glibc chkconfig shadow-utils bash popt cracklib-dicts beecrypt net-tools ethtool libacl elfutils-libelf db4 info sed psmisc gawk coreutils dev util-linux procps initscripts mkinitrd libstdc++ glib2 tar gzip dev cpio dev lvm2 kernel libselinux module-init-tools less device-mapper rpm-libs libsepol udev readline MAKEDEV hotplug hwdata usbutils fedora-release db4-utils -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Wed Jan 26 13:47:00 2005 From: buildsys at redhat.com (Build System) Date: Wed, 26 Jan 2005 08:47:00 -0500 Subject: rawhide report: 20050126 changes Message-ID: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> New package cryptix Java crypto package New package cryptix-asn1 Cryptix ASN1 implementation New package gnu.getopt Java getopt implementation New package jakarta-commons-beanutils Jakarta Commons BeanUtils Package New package jakarta-commons-collections Jakarta Commons Collections Package New package jakarta-commons-daemon Jakarta Commons Daemon Package New package jakarta-commons-dbcp Jakarta Commons DataBase Pooling Package New package jakarta-commons-digester Jakarta Commons Digester Package New package jakarta-commons-el The Jakarta Commons Extension Language New package jakarta-commons-fileupload Jakarta Commons Fileupload Package New package jakarta-commons-lang Jakarta Commons Lang Package New package jakarta-commons-launcher The Launcher Component is designed to be a cross platform Java application launcher. New package jakarta-commons-pool Jakarta Commons Pool Package New package jakarta-commons-validator Jakarta Commons Validator New package jakarta-taglibs-standard An open-source implementation of the JSP Standard Tag Library New package ldapjdk The Mozilla LDAP Java SDK New package puretls Java implementation of SSLv3 and TLSv1 New package struts11 Web application framework Updated Packages: NetworkManager-0.3.3-1.cvs20050125.3.1 -------------------------------------- * Tue Jan 25 2005 Dan Williams 0.3.3-1.cvs20050125 - Play nice with dbus 0.23 - Update our list of Allowed Wireless Networks more quickly anaconda-10.2.0.13-1 -------------------- * Tue Jan 25 2005 Peter Jones - 10.2.0.13-1 - Hopefully fix LVM size bug (#145183) - Support multiple iso sets in the same directory (#146053) at-3.1.8-64 ----------- * Tue Jan 25 2005 Jason Vas Dias 3.1.8-64 - bugs 5160/146132: add PAM authentication control to atd * Tue Oct 05 2004 Jason Vas Dias 3.1.8-60 - fix bug 131510: no_export env. var. blacklisting should not - remove 'SHELL' when only 'SHELLOPTS' is blacklisted. - at(1) man-page should not say 'commands are run with /bin/sh' - and should explain usage of SHELL environement variable and - details of blacklisted variables. * Tue Sep 28 2004 Rik van Riel 3.1.8-58 - fix typo in man page, bug 112303 - (regenerated at-3.1.8-man-timespec-path.patch with fix) desktop-printing-0.18-2 ----------------------- * Tue Jan 25 2005 Dan Williams 0.18-2 - Rebuild for dbus 0.23 dictd-1.9.7-5 ------------- * Tue Jan 25 2005 Karsten Hopp 1.9.7-5 - don't install config file, leave it to the dictionary packages to populate it. (#135920) dmraid-1.0.0.rc5f-3 ------------------- * Fri Jan 21 2005 Alasdair Kergon 1.0.0.rc5f-2 - Rebuild to pick up new libdevmapper. * Fri Nov 26 2004 Heinz Mauelshagen 1.0.0.rc5f - specfile cleanup eclipse-1:3.0.1_fc-8 -------------------- * Tue Jan 25 2005 Andrew Overholt 1:3.0.1_fc-8 - add eclipse.db to libswt3-gtk2 files list * Tue Jan 25 2005 Andrew Overholt 1:3.0.1_fc-7 - add missing jar-so combinations to lists - add libswt3-gtk2 jar-so combinations - use native ecj instead of interpreted gcc-3.4.3-17 ------------ * Tue Jan 25 2005 Jakub Jelinek 3.4.3-17 - update from gcc-3_4-branch - PRs c++/19258, c++/19375, libstdc++/19510, other/16403, rtl-optimization/19296, target/16304, target/19548 - fix PR rtl-optimization/19579 - remove Java *.a libraries, issue error for gcj -static (#145829) gcc4-4.0.0-0.22 --------------- * Tue Jan 25 2005 Jakub Jelinek 4.0.0-0.22 - update from trunk - fix PR rtl-optimization/19579 - remove Java *.a libraries, issue error for gcj -static (#145829) gdm-1:2.6.0.5-11 ---------------- * Tue Jan 25 2005 Ray Strode 1:2.6.0.5-11 - Fix bug in greeter sort-session-list patch where selecting a session did nothing (bug 145626) isdn4k-utils-3.2-22 ------------------- * Tue Jan 25 2005 Than Ngo 3.2-22 - fix the bug in isdn startup script, #146057 kernel-2.6.10-1.1110_FC4 ------------------------ * Tue Jan 25 2005 Dave Jones - 2.6.11-rc2-bk3 pciutils-2.1.99.test8-6 ----------------------- * Tue Jan 25 2005 Bill Nottingham - 2.1.99.test8-6 - remove explicit kernel dep (#146153) pygtk2-2.5.3-1 -------------- * Tue Jan 25 2005 Jeremy Katz - 2.5.3-1 - 2.5.3 rhpl-0.153-1 ------------ * Tue Jan 25 2005 Peter Jones - 0.153-1 - add Russian unicode keyboard (#146009) - revert glibc-kernheaders fix. rpmdb-fedora-1:4-0.20050126 --------------------------- ruby-1.8.2-4 ------------ * Tue Jan 25 2005 Akira TAGOH - 1.8.2-4 - fixed the wrong generation of file manifest. (#146055) - spec file clean up. selinux-policy-strict-1.21.3-3 ------------------------------ * Tue Jan 25 2005 Dan Walsh 1.21.3-3 - Fix crond to run in unconfined_domain on targeted policy - Eliminate execmod from gpg selinux-policy-targeted-1.21.3-3 -------------------------------- * Tue Jan 25 2005 Dan Walsh 1.21.3-3 - Fix crond to run in unconfined_domain on targeted policy - Eliminate execmod from gpg squid-7:2.5.STABLE7-3 --------------------- * Tue Jan 25 2005 Jay Fenlason 7:2.5.STABLE7-3 - Include more upstream patches, including two for security holes. tn5250-0.16.5-3 --------------- * Tue Jan 25 2005 Karsten Hopp 0.16.5-3 - add BuildRequires ncurses-devel (#137558) vixie-cron-1:4.1-22 ------------------- * Tue Jan 25 2005 Jason Vas Dias - 4.1-22 - Fix bug 146073 - allow the 'pam_access' module to be used with - cron - set 'PAM_TTY' item to 'cron' . xfce-mcs-plugins-4.2.0-1 ------------------------ * Mon Jan 24 2005 Than Ngo 4.2.0-1 - 4.2.0 xfce4-panel-4.2.0-1 ------------------- * Tue Jan 25 2005 Than Ngo 4.2.0-1 - 4.2.0 * Wed Dec 08 2004 Than Ngo 4.0.6-2 - add patch to use lauchmail/htmlview #142160 yum-2.1.13-1 ------------ * Tue Jan 25 2005 Jeremy Katz - 2.1.13-1 - update to 2.1.13 From kyrre at solution-forge.net Wed Jan 26 13:57:04 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 26 Jan 2005 14:57:04 +0100 Subject: slow hard drives crushing interactivity In-Reply-To: References: <1106607715.6122.21.camel@localhost.localdomain> <1106640790.4341.3.camel@galvatron.localdomain> <1106668581.2657.14.camel@localhost.localdomain> <1106671927.3836.5.camel@rhbw.boston.redhat.com> <1106675674.2657.28.camel@localhost.localdomain> <1106677097.16105.22.camel@localhost.localdomain> <1106688241.2657.33.camel@localhost.localdomain> Message-ID: <1106747823.3330.1.camel@localhost.localdomain> tir, 25.01.2005 kl. 22.51 skrev Rex Dieter: > On Tue, 25 Jan 2005, Kyrre Ness Sjobak wrote: > > > What do you mean with "not full upstream support"? the "make icons nice" > > stuff, or something else? > > ooo-build from ooo.ximian.com doesn't do ooo-1.1.4 yet. > > -- Rex I see. Guessed it was something like that... BTW - i tried to pull OO 1.1.3 from rawhide this morning to my fc3 computer, and it wanted to update about 50% of my packages (just before hitting a broken dep and refusing to anything). Why so much trouble? Do i have to recompile the srpm? From harald at redhat.com Wed Jan 26 14:04:41 2005 From: harald at redhat.com (Harald Hoyer) Date: Wed, 26 Jan 2005 15:04:41 +0100 Subject: loop device creation [was Re: udev: Directory for custom device nodes.] In-Reply-To: <20050125175645.GV11938@angus.ind.WPI.EDU> References: <20050125150446.GF7619@angus.ind.WPI.EDU> <41F6665C.6030007@redhat.com> <20050125175645.GV11938@angus.ind.WPI.EDU> Message-ID: <41F7A379.6010304@redhat.com> Charles R. Anderson wrote: > On Tue, Jan 25, 2005 at 04:31:40PM +0100, Harald Hoyer wrote: > >>The loop module gets autoloaded by accessing /dev/loop. >>A program (mount) would have to load the module, if it wants /dev/loop* and >>wait for udev to create the device. >>We could load the loop device on system startup, but you may not want to >>have loaded "every" module, you could possibly use in one session. > > > How about calling "mount -a" twice? Once to touch any devices that > may need to have nodes created by udev, and again to actually succeed > on mounting those devices? > "Once to touch any devices that may need to have nodes created by udev" This does not work, because either the device node is there, then mount can use it to loop mount, because an open(2) triggers module autoloading *or* the device node isn't there, mount cannot open it, module autoloading cannot be triggered... the module has to be loaded manually, udev gets called by hotplug events, creates the devices as propagated by the module in /sys. It's like egg and chicken. You have to manually: a) create the device nodes, or b) load the module From felipe_alfaro at linuxmail.org Wed Jan 26 14:11:06 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Wed, 26 Jan 2005 15:11:06 +0100 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106701993.28420.138.camel@bree.local.net> References: <1106629396.28420.92.camel@bree.local.net> <21FCA8D9-6F24-11D9-B78E-000D9352858E@linuxmail.org> <1106701993.28420.138.camel@bree.local.net> Message-ID: <1EC7737D-6FA4-11D9-B66E-000D9352858E@linuxmail.org> On 26 Jan 2005, at 02:13, Jeremy Katz wrote: > On Tue, 2005-01-25 at 23:54 +0100, Felipe Alfaro Solana wrote: >> On 25 Jan 2005, at 06:03, Jeremy Katz wrote: >>> Then, you should be able to install the xen and kernel-xen0 packages. >>> Once this is done, you should have an entry set up in your grub.conf >>> to >>> boot the xen0 kernel. Now, reboot into your new xen0 kernel [3] >> >> Does kernel-xen0 still install the wrong entries into grub.conf? >> I'm bk pulling directly from the -unstable branch of Xen, so I can't >> test this currently. > > A combination of grubby and kernel package changes got this working > last > week (hence the note about mkinitrd 4.2.0). That was part of what I > was > trying to get done before posting this :) Yeah! Thanks :-) From enrico.scholz at informatik.tu-chemnitz.de Wed Jan 26 14:12:08 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 26 Jan 2005 15:12:08 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <1106742173.9044.11.camel@ulysse.olympe.o2t> (Nicolas Mailhot's message of "Wed, 26 Jan 2005 13:22:52 +0100") References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106482308.6306.52.camel@rousalka.dyndns.org> <878y6hrs9h.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050126003458.GA5867@ip68-4-98-123.oc.oc.cox.net> <87zmyxq9g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106732233.7301.15.camel@ulysse.olympe.o2t> <87r7k8qwjo.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106742173.9044.11.camel@ulysse.olympe.o2t> Message-ID: <87is5kb7pj.fsf@kosh.ultra.csn.tu-chemnitz.de> Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) writes: >> and crap... this is just an argument of pro-AA people who want to >> demonstrate how ugly non-AA fonts are. >> >> The statements above turn just off antialiasing but still use the same >> render technology. With the available free fonts (bitstream), this >> creates disrupted lines and makes it look yet more ugly than AA. >> >> The real solution would be to use bitmap fonts. > > The real solution would be to use AA with a high-dpi screen DDC reports 34x27 cm^2 for my 17" TFT which is driven with a 1280x1024 resolution (96x96 dpi^2). More modern 19" TFT are even below this 96 dpi mark, and 21.3" TFT with 1600x1200 are <100dpi also. Bitmap fonts for text-based application are perfect for the these resolutions. Monitors with printer resolutions might be an argument from the marketing people, but I do not need them. Enrico From tarjei.knapstad at predichem.com Wed Jan 26 14:24:48 2005 From: tarjei.knapstad at predichem.com (Tarjei Knapstad) Date: Wed, 26 Jan 2005 15:24:48 +0100 Subject: rawhide report: 20050126 changes In-Reply-To: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> Message-ID: <1106749487.31283.5.camel@tarjei.predichem.nett> On Wed, 2005-01-26 at 14:47, Build System wrote: > > New package jakarta-commons-beanutils > Jakarta Commons BeanUtils Package > Hmm, I thought you were striving to reduce the amount of packages going into Core? Just asking really, but is Jakarta and Struts something that should be in Core? If so, why? What makes them important "base distribution" packages? (Sorry if I missed something and this is something that'll be moved to Pre-Extras) -- Tarjei From peter.backlund at home.se Wed Jan 26 14:41:39 2005 From: peter.backlund at home.se (Peter Backlund) Date: Wed, 26 Jan 2005 15:41:39 +0100 Subject: rawhide report: 20050126 changes In-Reply-To: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> Message-ID: <1106750499.19595.4.camel@localhost.localdomain> > New package jakarta-commons-* > Jakarta Commons Package Are these packages built with gcj into native .so libraries? > eclipse-1:3.0.1_fc-8 > -------------------- Why the downgrade from 3.1M4? /Peter From Nicolas.Mailhot at laPoste.net Wed Jan 26 14:38:53 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 26 Jan 2005 15:38:53 +0100 Subject: rawhide report: 20050126 changes In-Reply-To: <1106749487.31283.5.camel@tarjei.predichem.nett> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106749487.31283.5.camel@tarjei.predichem.nett> Message-ID: <1106750334.27642.8.camel@ulysse.olympe.o2t> Le mercredi 26 janvier 2005 ? 15:24 +0100, Tarjei Knapstad a ?crit : > On Wed, 2005-01-26 at 14:47, Build System wrote: > > > > > New package jakarta-commons-beanutils > > Jakarta Commons BeanUtils Package > > > > > > Hmm, I thought you were striving to reduce the amount of packages going > into Core? Just asking really, but is Jakarta and Struts something that > should be in Core? If so, why? What makes them important "base > distribution" packages? > > (Sorry if I missed something and this is something that'll be moved to > Pre-Extras) Obviously that's a lot of stuff that will be used in RHEL. It's nice to see that FC users will have access to the same java infrastructure (unlike before when the stuff Red Hat did for paying customers and the one dumped on FC people had nothing in common). Plus given the spread of java in academic circles we might expect some nice student projects to come out of it once there is a good gcj base in FC. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From elanthis at awesomeplay.com Wed Jan 26 14:42:41 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Wed, 26 Jan 2005 09:42:41 -0500 Subject: RFC: Soname in rpm name In-Reply-To: References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> <20050124185747.GI19903@neu.nirvana> Message-ID: <1106750561.11558.9.camel@support02.civic.twp.ypsilanti.mi.us> On Tue, 2005-01-25 at 02:24 -0200, Alexandre Oliva wrote: > Having package installers pin user-selected packages, or unpin > packages brought in only to satisfy dependencies, would enable all > cases to work, not only the shared library case, even without a > special provides or the too-inclusive mechanism proposed by jeff. The pacman package manager from Arch Linux (which I used to package GNOME for) seems to have recently gained a feature like this. It's fortunately better then just pinning; pinning means the package can't be upgraded. Basically, pacman marks for each installed package whether the package was pulled in explicitly by the user or as a dependency of another package. There is then a command that can remove any package which was not explicitly requested by the user and which is not depended on. If this was combined and made a little smarter to deal with RPM groups (something else that pacman supports, albeit in a much different way) then the method could be used in rpm and would probably work very well. Debian also has the deborphan utility, although it isn't very intelligent at all; it just bases its decisions on whether a package has dependencies, which can lead to a lot of manual intervention after it generates a package removal list. I think the model used by pacman is superior here. From overholt at redhat.com Wed Jan 26 14:46:36 2005 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 26 Jan 2005 09:46:36 -0500 Subject: rawhide report: 20050126 changes In-Reply-To: <1106750499.19595.4.camel@localhost.localdomain> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> Message-ID: <20050126144636.GA7010@redhat.com> * Peter Backlund [2005-01-26 09:40]: > > eclipse-1:3.0.1_fc-8 > > -------------------- > > Why the downgrade from 3.1M4? We were having some stability issues with 3.1M4 natively compiled. I'm hoping to go back to a 3.1 milestone build before FC4. Andrew From rdieter at math.unl.edu Wed Jan 26 14:48:05 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 26 Jan 2005 08:48:05 -0600 Subject: rawhide report: 20050126 changes In-Reply-To: <1106750499.19595.4.camel@localhost.localdomain> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> Message-ID: <41F7ADA5.6060805@math.unl.edu> Peter Backlund wrote: >>New package jakarta-commons-* >> Jakarta Commons Package > > > Are these packages built with gcj into native .so libraries? How else would they get built on/for Fedora Core? (-: -- Rex From alan at redhat.com Wed Jan 26 14:59:40 2005 From: alan at redhat.com (Alan Cox) Date: Wed, 26 Jan 2005 09:59:40 -0500 Subject: Problems with SG_IO ioctls on sd device (verses sg device) In-Reply-To: <1106700013.26384.1.camel@swtf.comptex.com.au> References: <1106700013.26384.1.camel@swtf.comptex.com.au> Message-ID: <20050126145940.GA6625@devserv.devel.redhat.com> On Wed, Jan 26, 2005 at 11:40:13AM +1100, Burn Alting wrote: > allocates paged aligned memory and then forms a 512 block write to > location 1 on the target. Directly after a reboot of the kernel, > the ioctl() write to /dev/sda works, but the next time it fails > with an EINVAL result. This is an expected and known limitation of the ioctl interface currently. From tibbs at math.uh.edu Wed Jan 26 15:15:24 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Wed, 26 Jan 2005 09:15:24 -0600 Subject: rawhide report: 20050121 changes In-Reply-To: <87vf9kqwtm.fsf@kosh.ultra.csn.tu-chemnitz.de> (Enrico Scholz's message of "Wed, 26 Jan 2005 12:00:37 +0100") References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <1106314637.16789.24.camel@localhost.localdomain> <87vf9q3kw5.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106482308.6306.52.camel@rousalka.dyndns.org> <878y6hrs9h.fsf@kosh.ultra.csn.tu-chemnitz.de> <20050126003458.GA5867@ip68-4-98-123.oc.oc.cox.net> <87zmyxq9g3.fsf@kosh.ultra.csn.tu-chemnitz.de> <87vf9kqwtm.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: >>>>> "ES" == Enrico Scholz writes: ES> never heared about this font, nor used it... Have you tried ES> 'fixed' (which is probably Courier)? Yes. I honestly think that it looks rather poor. ES> As said, it looks perfectly both in XEmacs and xterm. Your definition of "perfect" and mine differ greatly. It's simply personal taste, so the only logical thing to do is to stop telling others that your tastes should apply to them. They don't. - J< From peter.backlund at home.se Wed Jan 26 15:23:10 2005 From: peter.backlund at home.se (Peter Backlund) Date: Wed, 26 Jan 2005 16:23:10 +0100 Subject: rawhide report: 20050126 changes In-Reply-To: <41F7ADA5.6060805@math.unl.edu> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <41F7ADA5.6060805@math.unl.edu> Message-ID: <1106752990.19595.10.camel@localhost.localdomain> ons 2005-01-26 klockan 08:48 -0600 skrev Rex Dieter: > Peter Backlund wrote: > >>New package jakarta-commons-* > >> Jakarta Commons Package > > > > > > Are these packages built with gcj into native .so libraries? > > How else would they get built on/for Fedora Core? (-: With gcj into bytecode, or with ecj into bytecode :-) /Peter From rdieter at math.unl.edu Wed Jan 26 15:19:16 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 26 Jan 2005 09:19:16 -0600 Subject: rawhide report: 20050126 changes In-Reply-To: <1106752990.19595.10.camel@localhost.localdomain> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <41F7ADA5.6060805@math.unl.edu> <1106752990.19595.10.camel@localhost.localdomain> Message-ID: <41F7B4F4.2060800@math.unl.edu> Peter Backlund wrote: > ons 2005-01-26 klockan 08:48 -0600 skrev Rex Dieter: > >>Peter Backlund wrote: >> >>>>New package jakarta-commons-* >>>> Jakarta Commons Package >>> >>> >>>Are these packages built with gcj into native .so libraries? >> >>How else would they get built on/for Fedora Core? (-: > > > With gcj into bytecode, or with ecj into bytecode :-) I wasn't aware one could run/use bytecode with gcj. -- Rex From hp at redhat.com Wed Jan 26 15:23:11 2005 From: hp at redhat.com (Havoc Pennington) Date: Wed, 26 Jan 2005 10:23:11 -0500 Subject: slow hard drives crushing interactivity In-Reply-To: <20050125230141.GA18641@devserv.devel.redhat.com> References: <1106607715.6122.21.camel@localhost.localdomain> <20050125050425.GK4047@nostromo.devel.redhat.com> <1106669074.7068.86.camel@localhost.localdomain> <20050125165204.GB17028@devserv.devel.redhat.com> <1106677374.8977.0.camel@localhost.localdomain> <20050125195359.GA1219@devserv.devel.redhat.com> <1106684777.9418.0.camel@localhost.localdomain> <20050125204724.GC4088@devserv.devel.redhat.com> <1106689066.9418.32.camel@localhost.localdomain> <20050125230141.GA18641@devserv.devel.redhat.com> Message-ID: <1106752991.9579.15.camel@localhost.localdomain> On Tue, 2005-01-25 at 18:01 -0500, Alan Cox wrote: > On Tue, Jan 25, 2005 at 04:37:46PM -0500, Havoc Pennington wrote: > > > Maybe its telling you something about evolution > > > > Evolution does alloc a lot of memory (especially with as much mail as I > > have!) but it's well under 200M on a 512M system with swap, so ... ;-) > > Memory or address space. The overcommit is basically ensuring you don't > exceed Swap + 50%RAM of virtual address space allocated. > How much larger can the address space be than memory numbers from top? If it can be a lot larger in unpredictable ways that would keep us from turning on this setting by default. Havoc From dcbw at redhat.com Wed Jan 26 15:25:08 2005 From: dcbw at redhat.com (Dan Williams) Date: Wed, 26 Jan 2005 10:25:08 -0500 (EST) Subject: rawhide report: 20050126 changes In-Reply-To: <41F7B4F4.2060800@math.unl.edu> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <41F7ADA5.6060805@math.unl.edu> <1106752990.19595.10.camel@localhost.localdomain> <41F7B4F4.2060800@math.unl.edu> Message-ID: On Wed, 26 Jan 2005, Rex Dieter wrote: > I wasn't aware one could run/use bytecode with gcj. That would be the 'gij' program (which I assume stands for GNU Interpreter for Java). Dan From sysadmin at cokzl.rusautogaz.ru Wed Jan 26 15:29:08 2005 From: sysadmin at cokzl.rusautogaz.ru (Sysadmin cokzl) Date: Wed, 26 Jan 2005 18:29:08 +0300 Subject: Help correct Fedora s390 running under VM Message-ID: <008301c503bb$c78cd370$580310ac@rusautogaz.ru> > I am run (Fedora Core release Rawhide (Rawhide)Kernel 2.6.10-1.1103_FC4 on > an s390) > from vm/esa on s390, and i am see on console: > > **************************************************************************** > *********** > Booting default (linux)... > Linux version 2.6.10-1.1103_FC4 (bhcompile at spade.z900.redhat.com) (gcc > version > .4.3 20050113 (Red Hat 3.4.3-15)) #1 SMP Wed Jan 19 20:40:50 EST 2005 > We are running under VM (31 bit mode) > This machine has no IEEE fpu > Built 1 zonelists > Kernel command line: root=LABEL=/1 BOOT_IMAGE=0 > PID hash table entries: 1024 (order: 10, 16384 bytes) > Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) > Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) > Memory: 124544k/131072k available (1874k kernel code, 0k reserved, 605k > data, 1 > 8k init) > Security Framework v1.0.0 initialized > SELinux: Initializing. > SELinux: Starting in permissive mode > selinux_register_security: Registering secondary module capability > Capability LSM initialized as secondary > Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > Detected 1 CPU's > Boot cpu address 0 > cpu 0 phys_idx=0 vers=FF ident=100003 machine=9672 unused=0000 > Brought up 1 CPUs > checking if image is initramfs... it is > Freeing initrd memory: 899k freed > debug: Initialization complete > NET: Registered protocol family 16 > **************************************************************************** > *************** > and here cycling > i am do command vm/esa: > trace all > and i see: > TRACE ALL > HCPTRI1027I An active trace set has turned RUN off. > B > -> 001D196E' SLR 1F33 CC 2 > B > 001D1970' CS BA342000 002E8454 CC 1 > B > 001D1974' ???? A744FFFB 0057AD33 CC 1 > B > -> 001D196A' DIAG 83000044 00000044 CC 1 > B > 001D196E' SLR 1F33 CC 2 > B > 001D1970' CS BA342000 002E8454 CC 1 > B > 001D1974' ???? A744FFFB 0057AD33 CC 1 > B > -> 001D196A' DIAG 83000044 00000044 CC 1 > B > 001D196E' SLR 1F33 CC 2 > B > 001D1970' CS BA342000 002E8454 CC 1 > B > 001D1974' ???? A744FFFB 0057AD33 CC 1 > B > -> 001D196A' DIAG 83000044 00000044 CC 1 > B > 001D196E' SLR 1F33 CC 2 > B > 001D1970' CS BA342000 002E8454 CC 1 > B > 001D1974' ???? A744FFFB 0057AD33 CC 1 > > i am do command vm/esa: > STORE 001D1974 A7440002: > and i see: > CP ST 001D1974 A7440002 > Store complete. > > cio: Was not able to determine available CHSCs, cc=2. > chsc_get_sch_descriptions: Error -22 while doing chsc; processing some > machine c > hecks may not work > appldata info: mem-ops registered] > appldata info: os-ops registered] > appldata info: net_sum-ops registered] > audit: initializing netlink socket (disabled) > audit(1106763062.926:0): initialized > VFS: Disk quotas dquot_6.5.1 > Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) > SELinux: Registering netfilter hooks > Initializing Cryptographic API > ksign: Installing public key data > Loading keyring > - Added public key A151D8E9D3A0BB > - User ID: Red Hat, Inc. (Kernel Module GPG key) > io scheduler noop registered > io scheduler anticipatory registered > io scheduler deadline registered > io scheduler cfq registered > RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize > md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27 > Channel measurement facility using basic format (autodetected) > cpi: no system name specified > NET: Registered protocol family 2 > IP: routing cache hash table of 1024 buckets, 8Kbytes > TCP established hash table entries: 8192 (order: 5, 131072 bytes) > TCP bind hash table entries: 8192 (order: 4, 65536 bytes) > TCP: Hash tables configured (established 8192 bind 8192) > Initializing IPsec netlink socket > NET: Registered protocol family 1 > NET: Registered protocol family 17 > Freeing unused kernel memory: 108k freed > Red Hat nash version 4.2.0.1 starting > Mounted /proc filesystem ........................................ > and so on > > and i see: > Fedora Core release Rawhide (Rawhide) > Kernel 2.6.10-1.1103_FC4 on an s390 > > cokzlb login: > HELP correct; improve; reform; repair BUG > From tadams-lists at myrealbox.com Wed Jan 26 16:06:28 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Wed, 26 Jan 2005 09:06:28 -0700 Subject: HAL features needed Message-ID: <1106755588.3357.9.camel@localhost.localdomain> My examples are going to be somewhat bad, but please see through them for the reasoning and the necessity of these features. 1) We need a way to know if someone, using HAL, is logged in either in a terminal or an X session. Think of a situation where you have a piece of software that needs to do tasks from time to time (changing of runlevels is likely). You want to automate this, or at least be able to tell the machine to do it. However, this process should wait (or the shell script that does all the running) until no one is logged in. Yes, yes, who and w might provide that, but I find this a cleaner solution. 2) We need a way to know if some critical process, such as up2date, is being run at shutdown and allow the app, as long as it response every X amount of time (2 minutes or so) to continue to run. Think of a network environment and someone is doing an up2date via cron or ssh. Someone finishes using the computer and turns it off. This should pause, in a test or graphical shut down, showing a list of such processes. It should not execute any shut down sequences until this list is empty, or they programs all cease to respond. These processes should notify HAL, that they need to complete and that they have completed, and have an event handler to respond to HAL. I have a few ideas about the VNC features as well, but those will come later. What do you all think? Is this possible (I am fairly sure it is)? Is it a good thing... I think so? Trever Adams -- "...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning." -- Matt Welsh From walters at redhat.com Wed Jan 26 16:20:37 2005 From: walters at redhat.com (Colin Walters) Date: Wed, 26 Jan 2005 11:20:37 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <87is5kqtjl.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106732826.7301.21.camel@ulysse.olympe.o2t> <87mzuwqvfn.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106739907.19595.1.camel@localhost.localdomain> <87is5kqtjl.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <1106756437.4353.23.camel@nexus.verbum.private> On Wed, 2005-01-26 at 13:11 +0100, Enrico Scholz wrote: > But: UI guidelines which allow that a start-button becomes a stop-button > are crap (probably copied from M$ Windoze). I do not want to count how > often I pressed 'stop': there should be silence regardless if I pressed > 1, 23 or 42 times the 'stop' button. Actually, recent versions of the GNOME HIG specify that there should be separate buttons. Rhythmbox just hasn't implemented it yet. From sysadmin at cokzl.rusautogaz.ru Wed Jan 26 15:15:48 2005 From: sysadmin at cokzl.rusautogaz.ru (Sysadmin cokzl) Date: Wed, 26 Jan 2005 18:15:48 +0300 Subject: Help correct Fedora s390 running under VM Message-ID: <007701c503ba$e84566f0$580310ac@rusautogaz.ru> I am run (Fedora Core release Rawhide (Rawhide)Kernel 2.6.10-1.1103_FC4 on an s390) from vm/esa on s390, and i am see on console: **************************************************************************** *********** Booting default (linux)... Linux version 2.6.10-1.1103_FC4 (bhcompile at spade.z900.redhat.com) (gcc version .4.3 20050113 (Red Hat 3.4.3-15)) #1 SMP Wed Jan 19 20:40:50 EST 2005 We are running under VM (31 bit mode) This machine has no IEEE fpu Built 1 zonelists Kernel command line: root=LABEL=/1 BOOT_IMAGE=0 PID hash table entries: 1024 (order: 10, 16384 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 124544k/131072k available (1874k kernel code, 0k reserved, 605k data, 1 8k init) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Detected 1 CPU's Boot cpu address 0 cpu 0 phys_idx=0 vers=FF ident=100003 machine=9672 unused=0000 Brought up 1 CPUs checking if image is initramfs... it is Freeing initrd memory: 899k freed debug: Initialization complete NET: Registered protocol family 16 **************************************************************************** *************** and here cycling i am do command vm/esa: trace all and i see: TRACE ALL HCPTRI1027I An active trace set has turned RUN off. B -> 001D196E' SLR 1F33 CC 2 B 001D1970' CS BA342000 002E8454 CC 1 B 001D1974' ???? A744FFFB 0057AD33 CC 1 B -> 001D196A' DIAG 83000044 00000044 CC 1 B 001D196E' SLR 1F33 CC 2 B 001D1970' CS BA342000 002E8454 CC 1 B 001D1974' ???? A744FFFB 0057AD33 CC 1 B -> 001D196A' DIAG 83000044 00000044 CC 1 B 001D196E' SLR 1F33 CC 2 B 001D1970' CS BA342000 002E8454 CC 1 B 001D1974' ???? A744FFFB 0057AD33 CC 1 B -> 001D196A' DIAG 83000044 00000044 CC 1 B 001D196E' SLR 1F33 CC 2 B 001D1970' CS BA342000 002E8454 CC 1 B 001D1974' ???? A744FFFB 0057AD33 CC 1 i am do command vm/esa: STORE 001D1974 A7440002: and i see: CP ST 001D1974 A7440002 Store complete. cio: Was not able to determine available CHSCs, cc=2. chsc_get_sch_descriptions: Error -22 while doing chsc; processing some machine c hecks may not work appldata info: mem-ops registered] appldata info: os-ops registered] appldata info: net_sum-ops registered] audit: initializing netlink socket (disabled) audit(1106763062.926:0): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) SELinux: Registering netfilter hooks Initializing Cryptographic API ksign: Installing public key data Loading keyring - Added public key A151D8E9D3A0BB - User ID: Red Hat, Inc. (Kernel Module GPG key) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27 Channel measurement facility using basic format (autodetected) cpi: no system name specified NET: Registered protocol family 2 IP: routing cache hash table of 1024 buckets, 8Kbytes TCP established hash table entries: 8192 (order: 5, 131072 bytes) TCP bind hash table entries: 8192 (order: 4, 65536 bytes) TCP: Hash tables configured (established 8192 bind 8192) Initializing IPsec netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 Freeing unused kernel memory: 108k freed Red Hat nash version 4.2.0.1 starting Mounted /proc filesystem ........................................ and so on and i see: Fedora Core release Rawhide (Rawhide) Kernel 2.6.10-1.1103_FC4 on an s390 cokzlb login: HELP correct; improve; reform; repair BUG From david at fubar.dk Wed Jan 26 16:39:24 2005 From: david at fubar.dk (David Zeuthen) Date: Wed, 26 Jan 2005 11:39:24 -0500 Subject: HAL features needed In-Reply-To: <1106755588.3357.9.camel@localhost.localdomain> References: <1106755588.3357.9.camel@localhost.localdomain> Message-ID: <1106757564.5118.24.camel@daxter.boston.redhat.com> On Wed, 2005-01-26 at 09:06 -0700, Trever L. Adams wrote: > My examples are going to be somewhat bad, but please see through them > for the reasoning and the necessity of these features. > Discussion of hal happens on hal at freedesktop.org > 1) We need a way to know if someone, using HAL, is logged in either in a > terminal or an X session. > > Think of a situation where you have a piece of software that needs to do > tasks from time to time (changing of runlevels is likely). > > You want to automate this, or at least be able to tell the machine to do > it. However, this process should wait (or the shell script that does all > the running) until no one is logged in. Yes, yes, who and w might > provide that, but I find this a cleaner solution. > Uhm, hal is piece of software that keeps a list of your hardware, provides hooks for configuring it, and notifies anyone who is interested when hardware is added/removed. What you suggest has nothing to do with that. > 2) We need a way to know if some critical process, such as up2date, is > being run at shutdown and allow the app, as long as it response every X > amount of time (2 minutes or so) to continue to run. > > Think of a network environment and someone is doing an up2date via cron > or ssh. Someone finishes using the computer and turns it off. This > should pause, in a test or graphical shut down, showing a list of such > processes. It should not execute any shut down sequences until this list > is empty, or they programs all cease to respond. > > These processes should notify HAL, that they need to complete and that > they have completed, and have an event handler to respond to HAL. > Uhm, no, this has nothing to do with hal. It belongs somewhere else. David From johnp at redhat.com Wed Jan 26 16:43:03 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Wed, 26 Jan 2005 11:43:03 -0500 Subject: HAL features needed In-Reply-To: <1106755588.3357.9.camel@localhost.localdomain> References: <1106755588.3357.9.camel@localhost.localdomain> Message-ID: <1106757783.3438.25.camel@localhost.localdomain> On Wed, 2005-01-26 at 11:06, Trever L. Adams wrote: > My examples are going to be somewhat bad, but please see through them > for the reasoning and the necessity of these features. > > 1) We need a way to know if someone, using HAL, is logged in either in a > terminal or an X session. > > Think of a situation where you have a piece of software that needs to do > tasks from time to time (changing of runlevels is likely). > > You want to automate this, or at least be able to tell the machine to do > it. However, this process should wait (or the shell script that does all > the running) until no one is logged in. Yes, yes, who and w might > provide that, but I find this a cleaner solution. > > 2) We need a way to know if some critical process, such as up2date, is > being run at shutdown and allow the app, as long as it response every X > amount of time (2 minutes or so) to continue to run. > > Think of a network environment and someone is doing an up2date via cron > or ssh. Someone finishes using the computer and turns it off. This > should pause, in a test or graphical shut down, showing a list of such > processes. It should not execute any shut down sequences until this list > is empty, or they programs all cease to respond. > > These processes should notify HAL, that they need to complete and that > they have completed, and have an event handler to respond to HAL. > > I have a few ideas about the VNC features as well, but those will come > later. > > What do you all think? Is this possible (I am fairly sure it is)? Is it > a good thing... I think so? > HAL is for hardware. You should create DBUS services to do what you want. DBus provides at_console rules on fedora so you can restrict functionality to users who are logged in locally to X or the terminal. Check out the articles in Red Hat Magazine to get some ideas. http://www.redhat.com/magazine/. -- J5 From tadams-lists at myrealbox.com Wed Jan 26 16:45:50 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Wed, 26 Jan 2005 09:45:50 -0700 Subject: HAL features needed In-Reply-To: <1106757564.5118.24.camel@daxter.boston.redhat.com> References: <1106755588.3357.9.camel@localhost.localdomain> <1106757564.5118.24.camel@daxter.boston.redhat.com> Message-ID: <1106757950.3357.11.camel@localhost.localdomain> Please, forgive me my brainddeadness. I had just a few hours of sleep. I am talking about DBUS not hal. I am so very sorry. I will fix that up and resend it. Trever On Wed, 2005-01-26 at 11:39 -0500, David Zeuthen wrote: > On Wed, 2005-01-26 at 09:06 -0700, Trever L. Adams wrote: > > My examples are going to be somewhat bad, but please see through them > > for the reasoning and the necessity of these features. > > > > Discussion of hal happens on hal at freedesktop.org > > > 1) We need a way to know if someone, using HAL, is logged in either in a > > terminal or an X session. > > > > Think of a situation where you have a piece of software that needs to do > > tasks from time to time (changing of runlevels is likely). > > > > You want to automate this, or at least be able to tell the machine to do > > it. However, this process should wait (or the shell script that does all > > the running) until no one is logged in. Yes, yes, who and w might > > provide that, but I find this a cleaner solution. > > > > Uhm, hal is piece of software that keeps a list of your hardware, > provides hooks for configuring it, and notifies anyone who is > interested when hardware is added/removed. What you suggest has > nothing to do with that. > > > 2) We need a way to know if some critical process, such as up2date, is > > being run at shutdown and allow the app, as long as it response every X > > amount of time (2 minutes or so) to continue to run. > > > > Think of a network environment and someone is doing an up2date via cron > > or ssh. Someone finishes using the computer and turns it off. This > > should pause, in a test or graphical shut down, showing a list of such > > processes. It should not execute any shut down sequences until this list > > is empty, or they programs all cease to respond. > > > > These processes should notify HAL, that they need to complete and that > > they have completed, and have an event handler to respond to HAL. > > > > Uhm, no, this has nothing to do with hal. It belongs somewhere else. > > David > -- "The Master doesn't talk, he acts. When his work is done, the people say, 'Amazing: we did it, all by ourselves!'" -- Lao-tzu From richard.hubbell at gmail.com Wed Jan 26 16:50:07 2005 From: richard.hubbell at gmail.com (Richard Hubbell) Date: Wed, 26 Jan 2005 08:50:07 -0800 Subject: gcc bug in fc 3 In-Reply-To: <20050126091709.GA10340@devserv.devel.redhat.com> References: <20050126091709.GA10340@devserv.devel.redhat.com> Message-ID: On Wed, 26 Jan 2005 04:17:09 -0500, Jakub Jelinek wrote: > On Tue, Jan 25, 2005 at 09:31:49PM -0800, Richard Hubbell wrote: > > I installed a plain vanilla FC3, it only has xdm and xfce, no gnome or kde. > > I was unable to run neither mozilla (dies in PR_dtoa) nor firefox > > (dies in JS_dtostr). > > > > Digging and digging I found out that gcc seems to be the problem, maybe. > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17560 > > Are you building your code with gcc4 or g++4? > If not, PR17560 certainly is not related to your problems. Not,not building with gcc4, sorry missed that, I only saw that the target fix was gcc4. It is interesting to note though that when I did a search for prdtoa.c I found a note in some fedora release about porting a change from RH3.0 http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00148.html So it seems possible that the workaround got in at some point and maybe it never was ported forward. Any ideas? Anyone? thanks, Richard > > Jakub > From rahulsundaram at yahoo.co.in Wed Jan 26 16:09:51 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Wed, 26 Jan 2005 08:09:51 -0800 (PST) Subject: HAL features needed In-Reply-To: <1106755588.3357.9.camel@localhost.localdomain> Message-ID: <20050126160951.4356.qmail@web8501.mail.in.yahoo.com> --- "Trever L. Adams" wrote: > My examples are going to be somewhat bad, but please > see through them > for the reasoning and the necessity of these > features. why are you posting this to this list instead of the hal list? ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From tadams-lists at myrealbox.com Wed Jan 26 17:22:41 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Wed, 26 Jan 2005 10:22:41 -0700 Subject: HAL features needed In-Reply-To: <20050126160951.4356.qmail@web8501.mail.in.yahoo.com> References: <20050126160951.4356.qmail@web8501.mail.in.yahoo.com> Message-ID: <1106760161.3357.20.camel@localhost.localdomain> For all of you who have responded constructively, suggesting that I go elsewhere, or in some cases, realizing I made a mistake and answering a few questions about DBUS, thank you. I have done a little work on Gnome. Most of it was a few years ago and led to different patches (better than mine) being integrated. (mostly in libraries). I do not follow the development like I once did. I am thinking in terms of Desktop OS, not just the desktop. And this is the development mailing list for my favorite distribution. Based on these facts, I find it interesting that you get comments like the ones below. "Why are you posting here...." I may have been STUPID and put HAL instead of DBUS (severe lack of sleep does that, especially to me). Since this is an implementation issue and not some global freedesktop.org issue, at least in my mind, I posted here. If eventually it has to go to freedesktop great, but it should probably be taken by people who are smarter and more up to date than I. Again thank you for those who were reasonably polite, tried to see through my mistake and provided great insights. And again, please accept my apologies for my screw up. Trever Adams On Wed, 2005-01-26 at 08:09 -0800, Rahul Sundaram wrote: > --- "Trever L. Adams" > wrote: > > > My examples are going to be somewhat bad, but please > > see through them > > for the reasoning and the necessity of these > > features. > > why are you posting this to this list instead of the > hal list? > > ===== > Regards > Rahul Sundaram > > > > __________________________________ > Do you Yahoo!? > Meet the all-new My Yahoo! - Try it today! > http://my.yahoo.com > > -- "The best we can hope for concerning the people at large is that they be properly armed." -- Alexander Hamilton, The Federalist Papers at 184-188 From tadams-lists at myrealbox.com Wed Jan 26 17:32:33 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Wed, 26 Jan 2005 10:32:33 -0700 Subject: DBUS features Message-ID: <1106760753.3449.1.camel@localhost.localdomain> My examples are going to be somewhat bad, but please see through them for the reasoning and the necessity of these features. 1) We need a way to know if someone, using DBUS, is logged in either in a terminal or an X session. Think of a situation where you have a piece of software that needs to do tasks from time to time (changing of runlevels is likely). You want to automate this, or at least be able to tell the machine to do it. However, this process should wait (or the shell script that does all the running) until no one is logged in. Yes, yes, who and w might provide that, but I find this a cleaner solution. 2) We need a way to know if some critical process, such as up2date, is being run at shutdown and allow the app, as long as it response every X amount of time (2 minutes or so) to continue to run. Think of a network environment and someone is doing an up2date via cron or ssh. Someone finishes using the computer and turns it off. This should pause, in a test or graphical shut down, showing a list of such processes. It should not execute any shut down sequences until this list is empty, or they programs all cease to respond. These processes should notify DBUS, that they need to complete and that they have completed, and have an event handler to respond to DBUS. I have a few ideas about the VNC features as well, but those will come later. What do you all think? Is this possible (I am fairly sure it is)? Is it a good thing... I think so? Trever Adams P.S. In the thread where I used HAL in the place of DBUS, someone pointed out #1 is probably fairly simple, and the tone made it sound that it may not be a good idea in FC, this is fine if it is the case, but the functionality and core pieces for #2 should still be looked at. -- "Walking on water and developing software to specification are easy as long as both are frozen." --Edward V. Berard From cfk at pacbell.net Wed Jan 26 19:04:48 2005 From: cfk at pacbell.net (cfk) Date: Wed, 26 Jan 2005 11:04:48 -0800 Subject: duplicating a disk In-Reply-To: <1106579417.2365.15.camel@support02.civic.twp.ypsilanti.mi.us> References: <20050124160120.2f20c1c8.fedora@wir-sind-cool.org> <1106579417.2365.15.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <200501261104.48148.cfk@pacbell.net> Gentlemen: I have a situation where I need to make a number of identical computers all with the same fedoraCore2. I have tried putting a second (hdb) disk, doing a "df" on hda and based on the number of 1024 blocks going: dd if=/dev/hda of=/dev/hdb bs=1024 count= and it blinks the light a long time and then croaks. I know I did something similar to this a couple of years ago on a different project. Can someone tell me where I am going awry and perhaps educate me a little bit more. Signed, OldDogTryingToRememberNewTrick From feliciano.matias at free.fr Wed Jan 26 19:17:03 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Wed, 26 Jan 2005 20:17:03 +0100 Subject: rawhide report: 20050126 changes In-Reply-To: <1106750334.27642.8.camel@ulysse.olympe.o2t> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106749487.31283.5.camel@tarjei.predichem.nett> <1106750334.27642.8.camel@ulysse.olympe.o2t> Message-ID: <1106767024.2277.10.camel@one.myworld> Le mercredi 26 janvier 2005 ? 15:38 +0100, Nicolas Mailhot a ?crit : > Le mercredi 26 janvier 2005 ? 15:24 +0100, Tarjei Knapstad a ?crit : > > On Wed, 2005-01-26 at 14:47, Build System wrote: > > > > > > > > New package jakarta-commons-beanutils > > > Jakarta Commons BeanUtils Package > > > > > > > > > > > Hmm, I thought you were striving to reduce the amount of packages going > > into Core? Just asking really, but is Jakarta and Struts something that > > should be in Core? If so, why? What makes them important "base > > distribution" packages? > > > > (Sorry if I missed something and this is something that'll be moved to > > Pre-Extras) > > Obviously that's a lot of stuff that will be used in RHEL. I don't remember Red Hat stating that Fedora *Core* have a direct relationship this RHEL. For me, RHEL can be : FC + FE + other things > It's nice to see that FC users will have access to the same java > infrastructure (unlike before when the stuff Red Hat did for paying > customers and the one dumped on FC people had nothing in common). Plus > given the spread of java in academic circles we might expect some nice > student projects to come out of it once there is a good gcj base in FC. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dwmw2 at infradead.org Wed Jan 26 19:25:28 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 26 Jan 2005 19:25:28 +0000 Subject: DSL modem support in Fedora Core needs system-config-network support. Message-ID: <1106767529.19262.35.camel@hades.cambridge.redhat.com> (Originally sent to fedora-config-list but trapped for moderation, and I may get volunteers here too...) Fedora Core 3 supports PPP over ATM (PPPoA) with any DSL modem which the kernel can use as an ATM device -- currently that's only USB modems based on the Alcatel SpeedTouch chipset, but we're working on more hardware drivers. The updated packages in rawhide also support PPP over Ethernet over ATM. (PPPoE with a real DSL modem, not over _real_ Ethernet to an external DSL modem/bridge). That should work fine in FC3 too if you update your rp-pppoe and install linux-atm packages from the yum repo at ftp://ftp.infradead.org/pub/linux-atm/ To connect, first you need to install the firmware for your modem into /lib/firmware (see the speedtouch-firmware.nosrc.rpm in the same FTP directory) and then you need to configure it. You can just set up an xDSL connection with system-config-network, then modify the resulting configuation file /etc/sysconfig/network-scripts/ifcfg-ppp0 as follows. For PPPoA, remove the 'ETH=' line, and add something like: LINUX_PLUGIN=pppoatm.so VCI=0 VPI=38 Replace the '0' and '38' with the appropriate values for your ISP. There's a table at http://linux- usb.sourceforge.net/SpeedTouch/faq/index.html#q12 which may help. For PPPoE, also remove the 'ETH=' line, and add: LINUX_PLUGIN=rp-pppoe.so BR2684DEV=0 VCI=0 VPI=38 (again with corrected VCI= and VPI= values). It would be useful if system-config-network could do that for you. Any volunteers for doing that? There's an update for the 'New Device' UI at http://david.woodhou.se/ADSLInterfaceDruid.glade but I don't talk Python, and system-config-network from CVS doesn't even build at the moment due to autocrap problems. All we need to do is make 'DSL modem' one of the options in the newly- renamed 'Hardware device' box. Then if 'DSL modem' isn't chosen, shade out the options for VCI, VPI and protocol. If it _is_ chosen, then write out the config file according to the above instructions. The UI for _editing_ devices also wants to be updated similarly. It might also be useful to extend the providerdb with VPI/VCI/proto information for various ISPs. In the longer term, kudzu could perhaps learn to look in /proc/net/atm/devices for ATM-capable devices, but that wouldn't show up a SpeedTouch modem before its firmware is present anyway, so I wouldn't want that to be the _only_ way the user can choose to use a DSL modem. -- dwmw2 -------------- next part -------------- An embedded message was scrubbed... From: David Woodhouse Subject: DSL modem support in Fedora Core needs system-config-network support. Date: Wed, 26 Jan 2005 14:48:28 +0000 Size: 2789 URL: From Nicolas.Mailhot at laPoste.net Wed Jan 26 20:19:09 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 26 Jan 2005 21:19:09 +0100 Subject: duplicating a disk In-Reply-To: <200501261104.48148.cfk@pacbell.net> References: <20050124160120.2f20c1c8.fedora@wir-sind-cool.org> <1106579417.2365.15.camel@support02.civic.twp.ypsilanti.mi.us> <200501261104.48148.cfk@pacbell.net> Message-ID: <1106770749.23956.4.camel@rousalka.dyndns.org> Le mercredi 26 janvier 2005 ? 11:04 -0800, cfk a ?crit : > Gentlemen: > > I have a situation where I need to make a number of identical computers all > with the same fedoraCore2. > > I have tried putting a second (hdb) disk, doing a "df" on hda and based on > the number of 1024 blocks going: > > dd if=/dev/hda of=/dev/hdb bs=1024 count= > > and it blinks the light a long time and then croaks. > > I know I did something similar to this a couple of years ago on a different > project. Can someone tell me where I am going awry and perhaps educate me a > little bit more. If you can setup an nfs or ftp/http server somewhere the fastest method is network install via kickstart (using pxe if you can) It might take a little longer to setup but you'll make up the time very fast. And if you do not have exactly the same hardware (same components & firmware versions) it's way safer. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Wed Jan 26 20:27:50 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 26 Jan 2005 21:27:50 +0100 Subject: rawhide report: 20050126 changes In-Reply-To: <1106767024.2277.10.camel@one.myworld> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106749487.31283.5.camel@tarjei.predichem.nett> <1106750334.27642.8.camel@ulysse.olympe.o2t> <1106767024.2277.10.camel@one.myworld> Message-ID: <1106771270.23956.14.camel@rousalka.dyndns.org> Le mercredi 26 janvier 2005 ? 20:17 +0100, F?liciano Matias a ?crit : > Le mercredi 26 janvier 2005 ? 15:38 +0100, Nicolas Mailhot a ?crit : > > Le mercredi 26 janvier 2005 ? 15:24 +0100, Tarjei Knapstad a ?crit : > > > On Wed, 2005-01-26 at 14:47, Build System wrote: > > > > > > > > > > > New package jakarta-commons-beanutils > > > > Jakarta Commons BeanUtils Package > > > > > > > > > > > > > > > > Hmm, I thought you were striving to reduce the amount of packages going > > > into Core? Just asking really, but is Jakarta and Struts something that > > > should be in Core? If so, why? What makes them important "base > > > distribution" packages? > > > > > > (Sorry if I missed something and this is something that'll be moved to > > > Pre-Extras) > > > > Obviously that's a lot of stuff that will be used in RHEL. > > I don't remember Red Hat stating that Fedora *Core* have a direct > relationship this RHEL. > > For me, RHEL can be : > FC + FE + other things One big reason RH is in Fedora is for the RHEL it makes out of it One big reason a lot of people use Fedora is the RedHat touch they get for free. So it's a symbiotic relationship. I for one would be the last to complain I have access in FC to large parts of RHEL. We're not talking about resources Red Hat is taking from parts of Fedora to reallocate elsewhere (which is IMHO a large part of what's extra is about). We're talking about ressources Red Hat already allocated for its *paying* customers and is sharing for free with FC users (If you just take a peek at who's maintaining the java packages you'll see they're not people already contributing heavily to other parts of FC. So don't worry your packages are safe). Complaining about a free gift is not overly polite. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Wed Jan 26 20:33:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 26 Jan 2005 15:33:06 -0500 Subject: rawhide report: 20050126 changes In-Reply-To: <1106771270.23956.14.camel@rousalka.dyndns.org> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106749487.31283.5.camel@tarjei.predichem.nett> <1106750334.27642.8.camel@ulysse.olympe.o2t> <1106767024.2277.10.camel@one.myworld> <1106771270.23956.14.camel@rousalka.dyndns.org> Message-ID: <1106771586.29597.72.camel@cutter> > Complaining about a free gift is not overly polite. That's funny - from what I can tell it is the mantra of most open source software development. or to put it another way: "Look a gift horse in the mouth" -sv From feliciano.matias at free.fr Wed Jan 26 21:10:29 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Wed, 26 Jan 2005 22:10:29 +0100 Subject: rawhide report: 20050126 changes In-Reply-To: <1106771270.23956.14.camel@rousalka.dyndns.org> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106749487.31283.5.camel@tarjei.predichem.nett> <1106750334.27642.8.camel@ulysse.olympe.o2t> <1106767024.2277.10.camel@one.myworld> <1106771270.23956.14.camel@rousalka.dyndns.org> Message-ID: <1106773829.2277.27.camel@one.myworld> Le mercredi 26 janvier 2005 ? 21:27 +0100, Nicolas Mailhot a ?crit : > Le mercredi 26 janvier 2005 ? 20:17 +0100, F?liciano Matias a ?crit : > > For me, RHEL can be : > > FC + FE + other things > > One big reason RH is in Fedora is for the RHEL it makes out of it > One big reason a lot of people use Fedora is the RedHat touch they get > for free. So it's a symbiotic relationship. > > I for one would be the last to complain I have access in FC to large > parts of RHEL. We're not talking about resources Red Hat is taking from > parts of Fedora to reallocate elsewhere (which is IMHO a large part of > what's extra is about). We're talking about ressources Red Hat already > allocated for its *paying* customers and is sharing for free with FC > users (If you just take a peek at who's maintaining the java packages > you'll see they're not people already contributing heavily to other > parts of FC. So don't worry your packages are safe). > Nice speech. > Complaining about a free gift is not overly polite. What are you talking about ? I just try to figure out why java stuff should be in Fedora Core. I think some java stuff can be push in Fedora Extra. In don't think jakarta is a "core component" for an OS. I do not use java a lot and perhaps I am wrong. If you don't agree with my point, just explain why I am wrong. PS : I use Fedora and I use/buy RHEL. I am really happy with the Red Hat's work and how Red Hat manage business and free software. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From hp at redhat.com Wed Jan 26 21:22:24 2005 From: hp at redhat.com (Havoc Pennington) Date: Wed, 26 Jan 2005 16:22:24 -0500 Subject: DBUS features In-Reply-To: <1106760753.3449.1.camel@localhost.localdomain> References: <1106760753.3449.1.camel@localhost.localdomain> Message-ID: <1106774544.10159.123.camel@localhost.localdomain> On Wed, 2005-01-26 at 10:32 -0700, Trever L. Adams wrote: > > What do you all think? Is this possible (I am fairly sure it is)? Is it > a good thing... I think so? I think it's possible and good yes, the key thing though is to get it coded up. For the first you need either a system daemon that monitors the utmp/wtmp/lastlog/whatever-it-is or you need each user session to register somehow with a dbus-specific thing For the second you probably want a generic "list jobs that are running", "notify when jobs are complete" kind of interface and have cron, up2date, etc. use it. Havoc From feliciano.matias at free.fr Wed Jan 26 21:35:51 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Wed, 26 Jan 2005 22:35:51 +0100 Subject: DSL modem support in Fedora Core needs system-config-network support. In-Reply-To: <1106767529.19262.35.camel@hades.cambridge.redhat.com> References: <1106767529.19262.35.camel@hades.cambridge.redhat.com> Message-ID: <1106775352.2277.44.camel@one.myworld> Le mercredi 26 janvier 2005 ? 19:25 +0000, David Woodhouse a ?crit : > (Originally sent to fedora-config-list but trapped for moderation, and I > may get volunteers here too...) > > Fedora Core 3 supports PPP over ATM (PPPoA) with any DSL modem which the > kernel can use as an ATM device -- currently that's only USB modems > based on the Alcatel SpeedTouch chipset No :-) Fedora Core 3 works near perfectly with Bewan modem. I use a Bewan PCI ST with pppoatm. pppoeth also works but need some tricks. Other people success to use Bewan USB ST modem. Package for Bewan modem : http://feliciano.matias.free.fr/bewan/FC3/ README file is missing :-) The kernel-2.6.10-1.741_FC3.bewan is just because Bewan does not support "CONFIG_REGPARM". I only need to create a /etc/sysconfig/network-scripts/ifcfg-ppp0 file. NB: Bewan is a proprietary driver. > , but we're working on more > hardware drivers. > > The updated packages in rawhide also support PPP over Ethernet over ATM. > (PPPoE with a real DSL modem, not over _real_ Ethernet to an external > DSL modem/bridge). pppoeth with bewan ("real DSL modem") works. In ifcfg-ppp0 I set : ETH=dsl0 > That should work fine in FC3 too if you update your > rp-pppoe and install linux-atm packages from the yum repo at > ftp://ftp.infradead.org/pub/linux-atm/ > > To connect, first you need to install the firmware for your modem > into /lib/firmware (see the speedtouch-firmware.nosrc.rpm in the same > FTP directory) and then you need to configure it. You can just set up an > xDSL connection with system-config-network, then modify the resulting > configuation file /etc/sysconfig/network-scripts/ifcfg-ppp0 as follows. > > For PPPoA, remove the 'ETH=' line, and add something like: > LINUX_PLUGIN=pppoatm.so > VCI=0 > VPI=38 > > Replace the '0' and '38' with the appropriate values for your ISP. > There's > a table at http://linux- > usb.sourceforge.net/SpeedTouch/faq/index.html#q12 > which may help. > > For PPPoE, also remove the 'ETH=' line, and add: > LINUX_PLUGIN=rp-pppoe.so > BR2684DEV=0 > VCI=0 > VPI=38 > > (again with corrected VCI= and VPI= values). > > It would be useful if system-config-network could do that for you. Any > volunteers for doing that? There's an update for the 'New Device' UI at > http://david.woodhou.se/ADSLInterfaceDruid.glade but I don't talk > Python, and system-config-network from CVS doesn't even build at the > moment due to autocrap problems. > > All we need to do is make 'DSL modem' one of the options in the newly- > renamed 'Hardware device' box. Then if 'DSL modem' isn't chosen, shade > out the options for VCI, VPI and protocol. If it _is_ chosen, then write > out the config file according to the above instructions. > > The UI for _editing_ devices also wants to be updated similarly. > > It might also be useful to extend the providerdb with VPI/VCI/proto > information for various ISPs. > > In the longer term, kudzu could perhaps learn to look > in /proc/net/atm/devices for ATM-capable devices, but that wouldn't show > up a SpeedTouch modem before its firmware is present anyway, so I > wouldn't want that to be the _only_ way the user can choose to use a DSL > modem. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From Nicolas.Mailhot at laPoste.net Wed Jan 26 21:40:07 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Wed, 26 Jan 2005 22:40:07 +0100 Subject: rawhide report: 20050126 changes In-Reply-To: <1106773829.2277.27.camel@one.myworld> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106749487.31283.5.camel@tarjei.predichem.nett> <1106750334.27642.8.camel@ulysse.olympe.o2t> <1106767024.2277.10.camel@one.myworld> <1106771270.23956.14.camel@rousalka.dyndns.org> <1106773829.2277.27.camel@one.myworld> Message-ID: <1106775607.9130.24.camel@rousalka.dyndns.org> Le mercredi 26 janvier 2005 ? 22:10 +0100, F?liciano Matias a ?crit : > I just try to figure out why java stuff should be in Fedora Core. > I think some java stuff can be push in Fedora Extra. In don't think > jakarta is a "core component" for an OS. I do not use java a lot and > perhaps I am wrong. All the jakarta (and particularly the commons bits) are infrastructure libraries that are used in an awful lot of java projects (including big apache projects like ant, tomcat, geronimo... but also your run-of-the- mill in-house java development, other big apps like eclipse, etc). The java world is huge, but a large part of its OSS elements united under the apache/jakarta umbrella several years ago. There is no big app named jakarta just like there is no big app named GNU but if you remove the jakarta bits very few large OSS java projects will run (I'm writing large because obviously small student projects care much less about component reuse) Now jakarta is big enough there are probably some bits in it that do not belong in core, but trust me the Red hat people are starting from the ground up and we're far from the point were java games are proposed for inclusion. Right now its strictly core library pool seeding. It will probably reach perl size before apps start trickling in (the difference being free java is split in small interdependent projects instead of a big centralised blob - the (stupid) jpackage counter is showing 1381 packages right now and a big part of the repository is infrastructure stuff not leaf apps) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From strange at nsk.no-ip.org Wed Jan 26 22:37:57 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Wed, 26 Jan 2005 22:37:57 +0000 Subject: problems with xen and kmodule Message-ID: <20050126223757.GB4739@nsk.no-ip.org> On one of my machines, kmodule under xen gets stuck in an infinite loop: rt_sigprocmask(SIG_SETMASK, ~[], [], 8) = 0 vm86old(0x806a94c) = -1 ENOSYS (Function not implemented) rt_sigprocmask(SIG_SETMASK, ~[], [], 8) = 0 vm86old(0x806a94c) = -1 ENOSYS (Function not implemented) .... (I can ^C it, when rc.sysinit starts, causing the script to exit and init to continue to runlevel 3.) Without xen, it outputs the following: OTHER i2c-viapro OTHER parport_pc NETWORK via-rhine AUDIO snd-via82xx USB uhci-hcd USB uhci-hcd lspci: 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02) 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 10) 00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 10) 00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 10) 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 20) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 43) 01:00.0 VGA compatible controller: nVidia Corporation NV5 [RIVA TNT2 Ultra] (rev 15) cat /proc/cpuinfo: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 3 model name : AMD Duron(tm) Processor stepping : 0 cpu MHz : 700.053 cache size : 64 KB fdiv_bug : no hlt_bug : yes f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 mmx fxsr pni syscall mmxext 3dnowext 3dnow bogomips : 1399.19 Regards, Luciano Rocha -- 2/16 From kyrre at solution-forge.net Wed Jan 26 22:40:15 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Wed, 26 Jan 2005 23:40:15 +0100 Subject: duplicating a disk In-Reply-To: <1106770749.23956.4.camel@rousalka.dyndns.org> References: <20050124160120.2f20c1c8.fedora@wir-sind-cool.org> <1106579417.2365.15.camel@support02.civic.twp.ypsilanti.mi.us> <200501261104.48148.cfk@pacbell.net> <1106770749.23956.4.camel@rousalka.dyndns.org> Message-ID: <1106779214.2729.8.camel@localhost.localdomain> ons, 26.01.2005 kl. 21.19 skrev Nicolas Mailhot: > Le mercredi 26 janvier 2005 ? 11:04 -0800, cfk a ?crit : > > Gentlemen: > > > > I have a situation where I need to make a number of identical computers all > > with the same fedoraCore2. > > > > I have tried putting a second (hdb) disk, doing a "df" on hda and based on > > the number of 1024 blocks going: > > > > dd if=/dev/hda of=/dev/hdb bs=1024 count= > > > > and it blinks the light a long time and then croaks. > > > > I know I did something similar to this a couple of years ago on a different > > project. Can someone tell me where I am going awry and perhaps educate me a > > little bit more. > > If you can setup an nfs or ftp/http server somewhere the fastest method > is network install via kickstart (using pxe if you can) > > It might take a little longer to setup but you'll make up the time very > fast. And if you do not have exactly the same hardware (same components > & firmware versions) it's way safer. or you could do the setup you said, just use dd to copy te stuff over. Just boot it off a cdrom. From roland at redhat.com Wed Jan 26 22:42:19 2005 From: roland at redhat.com (Roland McGrath) Date: Wed, 26 Jan 2005 14:42:19 -0800 Subject: problems with xen and kmodule In-Reply-To: Luciano Miguel Ferreira Rocha's message of Wednesday, 26 January 2005 22:37:57 +0000 <20050126223757.GB4739@nsk.no-ip.org> Message-ID: <200501262242.j0QMgJuq029809@magilla.sf.frob.com> Xen doesn't implement the vm86 support as yet. It's useful to enumerate the packages that require it and what they're needed for. From strange at nsk.no-ip.org Wed Jan 26 22:58:59 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Wed, 26 Jan 2005 22:58:59 +0000 Subject: problems with xen and kmodule In-Reply-To: <200501262242.j0QMgJuq029809@magilla.sf.frob.com> References: <20050126223757.GB4739@nsk.no-ip.org> <200501262242.j0QMgJuq029809@magilla.sf.frob.com> Message-ID: <20050126225859.GA5578@nsk.no-ip.org> On Wed, Jan 26, 2005 at 02:42:19PM -0800, Roland McGrath wrote: > Xen doesn't implement the vm86 support as yet. It's useful to enumerate > the packages that require it and what they're needed for. Still, kmodules shouldn't lock the boot process just by lack of vm86 support, should it? Regards, Luciano Rocha -- 2/16 From riel at redhat.com Wed Jan 26 23:11:23 2005 From: riel at redhat.com (Rik van Riel) Date: Wed, 26 Jan 2005 18:11:23 -0500 (EST) Subject: problems with xen and kmodule In-Reply-To: <20050126225859.GA5578@nsk.no-ip.org> References: <20050126223757.GB4739@nsk.no-ip.org> <200501262242.j0QMgJuq029809@magilla.sf.frob.com> <20050126225859.GA5578@nsk.no-ip.org> Message-ID: On Wed, 26 Jan 2005, Luciano Miguel Ferreira Rocha wrote: > On Wed, Jan 26, 2005 at 02:42:19PM -0800, Roland McGrath wrote: >> Xen doesn't implement the vm86 support as yet. It's useful to enumerate >> the packages that require it and what they're needed for. > > Still, kmodules shouldn't lock the boot process just by lack of vm86 > support, should it? Interesting, on my test system (toshiba tecra laptop) kmodule gives an oops on startup. I wasn't aware it could get into an infinite loop, too... I'll try Xen on other systems to try and figure out what is going on exactly. Kmodule is near the top of my TODO list ;) -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From riel at redhat.com Wed Jan 26 23:33:29 2005 From: riel at redhat.com (Rik van Riel) Date: Wed, 26 Jan 2005 18:33:29 -0500 (EST) Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <88C3252C-6F23-11D9-B78E-000D9352858E@linuxmail.org> References: <1106629396.28420.92.camel@bree.local.net> <88C3252C-6F23-11D9-B78E-000D9352858E@linuxmail.org> Message-ID: On Tue, 25 Jan 2005, Felipe Alfaro Solana wrote: > In my case, I need to: > > mv /lib/tls /lib/tls.disabled > > or Xen will hang during boot. I have not seen this happen here. Could you get a backtrace and system details needed for me to figure out why the bug is happening or how to reproduce it ? -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan From tadams-lists at myrealbox.com Wed Jan 26 23:38:51 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Wed, 26 Jan 2005 16:38:51 -0700 Subject: DBUS features In-Reply-To: <1106774544.10159.123.camel@localhost.localdomain> References: <1106760753.3449.1.camel@localhost.localdomain> <1106774544.10159.123.camel@localhost.localdomain> Message-ID: <1106782731.3449.11.camel@localhost.localdomain> All hail Havoc... just kidding. I just want you to know I know you are a heck of a lot smarter and more versed in this than I am. On Wed, 2005-01-26 at 16:22 -0500, Havoc Pennington wrote: > On Wed, 2005-01-26 at 10:32 -0700, Trever L. Adams wrote: > > > > What do you all think? Is this possible (I am fairly sure it is)? Is it > > a good thing... I think so? > > I think it's possible and good yes, the key thing though is to get it > coded up. > > For the first you need either a system daemon that monitors the > utmp/wtmp/lastlog/whatever-it-is or you need each user session to > register somehow with a dbus-specific thing > This sounds good. I will look into doing this... maybe I can contribute. > For the second you probably want a generic "list jobs that are running", > "notify when jobs are complete" kind of interface and have cron, > up2date, etc. use it. > > Havoc Well, I would like this to be via dbus if possible, since everything seems to be using it. However, I don't want a generic list. I want programs to know they are critical and to have to acknowledge they are still alive (from time to time up2date locks up for example). Some sort of emit a message or respond to a check message. Maybe, if this is like multicast with dbus... shut down scripts ask "Anyone important alive" and the program respond "Sure, my name is up2date, pid blah blah blah, doing blah blah blah" When no one responds, shutdown continues. Sound good or am I foolish? Trever -- "What we Are is God's gift to us. What we Become is our gift to God." -- Unknown From rms at 1407.org Wed Jan 26 23:42:45 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Wed, 26 Jan 2005 23:42:45 +0000 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: References: <1106629396.28420.92.camel@bree.local.net> <88C3252C-6F23-11D9-B78E-000D9352858E@linuxmail.org> Message-ID: <1106782965.3593.11.camel@roque> On Wed, 2005-01-26 at 18:33 -0500, Rik van Riel wrote: > On Tue, 25 Jan 2005, Felipe Alfaro Solana wrote: > > > In my case, I need to: > > > > mv /lib/tls /lib/tls.disabled > > > > or Xen will hang during boot. > > I have not seen this happen here. Could you get a backtrace > and system details needed for me to figure out why the bug is > happening or how to reproduce it ? And do you notice xorg.conf being rewritten on a xen kernel boot? Because mine is... Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From hp at redhat.com Thu Jan 27 00:26:39 2005 From: hp at redhat.com (Havoc Pennington) Date: Wed, 26 Jan 2005 19:26:39 -0500 Subject: DBUS features In-Reply-To: <1106782731.3449.11.camel@localhost.localdomain> References: <1106760753.3449.1.camel@localhost.localdomain> <1106774544.10159.123.camel@localhost.localdomain> <1106782731.3449.11.camel@localhost.localdomain> Message-ID: <1106785599.10159.173.camel@localhost.localdomain> On Wed, 2005-01-26 at 16:38 -0700, Trever L. Adams wrote: > > Well, I would like this to be via dbus if possible, since everything > seems to be using it. However, I don't want a generic list. I want > programs to know they are critical and to have to acknowledge they are > still alive (from time to time up2date locks up for example). > > Some sort of emit a message or respond to a check message. Maybe, if > this is like multicast with dbus... shut down scripts ask "Anyone > important alive" and the program respond "Sure, my name is up2date, pid > blah blah blah, doing blah blah blah" > > When no one responds, shutdown continues. > > Sound good or am I foolish? If a process just exits, then you will know that via dbus (because the kernel will close the socket and that generates an event) If it's locked up you'd have to ping it to find out, yes Havoc From katzj at redhat.com Thu Jan 27 00:46:12 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 26 Jan 2005 19:46:12 -0500 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106782965.3593.11.camel@roque> References: <1106629396.28420.92.camel@bree.local.net> <88C3252C-6F23-11D9-B78E-000D9352858E@linuxmail.org> <1106782965.3593.11.camel@roque> Message-ID: <1106786772.17991.43.camel@bree.local.net> On Wed, 2005-01-26 at 23:42 +0000, Rui Miguel Seabra wrote: > And do you notice xorg.conf being rewritten on a xen kernel boot? > > Because mine is... Can you get a diff of old and what gets changed? This might be kudzu auto-reconfiguring things for what it detects Jeremy From erik at cpsc.ucalgary.ca Thu Jan 27 02:57:05 2005 From: erik at cpsc.ucalgary.ca (Erik Williamson) Date: Wed, 26 Jan 2005 19:57:05 -0700 Subject: Stateless Linux - Status Check Message-ID: <41F85881.2010607@cpsc.ucalgary.ca> Hi All, I was looking to evaluate Stateless Linux. Searching the archives of this list didn't turn up anything, and Google really only came up with the announcements in September. I see that the rpms (http://people.redhat.com/dmalcolm/stateless/) haven't been updated in a while, nor are they in the development tree - Is there still work being done on this, has it changed names, etc? Thanks, Erik. -- e r i k w i l l i a m s o n erik at cpsc.ucalgary.ca system admin . department of computer science . university of calgary From kmaraas at broadpark.no Thu Jan 27 03:10:25 2005 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Thu, 27 Jan 2005 04:10:25 +0100 Subject: FC4 with localized firefox (wishlist) In-Reply-To: <1106692024.2657.51.camel@localhost.localdomain> References: <1106482635.6173.100.camel@localhost> <41F54953.7040901@redhat.com> <1106595754.5024.3.camel@localhost> <1106692024.2657.51.camel@localhost.localdomain> Message-ID: <1106795425.4818.5.camel@localhost.localdomain> tir, 25,.01.2005 kl. 23.27 +0100, skrev Kyrre Ness Sjobak: > man, 24.01.2005 kl. 20.42 skrev Josep Puigdemont: > > El dl 24 de 01 del 2005 a les 14:15 -0500, en/na Christopher Aillon va > > escriure: > > > Josep Puigdemont wrote: > > > > Hi, > > > > > > > > Here it is my short wish list for FC4, if I may send one ;-) > > > > I don't know if this has been mentioned before or not, but I for one > > > > would like to see localized versions of Firefox for each installed > > > > language, by default. > > > > > > The version in rawhide does this already, at least for the languages > > > that Firefox have been translated into already. I've just been sort of > > > swamped and haven't had time to backport to fc3 yet. > > > > great news, thanks a lot! I can hardly wait ;-) > > > > /Josep > > > > Just installed it - here are my reactions: > - It seems a bit faster > - The gnomish'ed icons which i think are new, and noticed immediatly > without really knowing what i noticed, are pretty. Especially the > bookmark-icon! > - smooth scrolling is smooth! > > But: It's still in english. While i personally don't have any problem > with it, the rest of my desktop are in norwegian. > > Somehow the OSS crowd manages to make really nice translations. Usefull > ones. (anjuta being the baaad exeption that marks the rule) > Does it bother you enough to take it on yourself? :-) Feel free to contact me off list if you do... Cheers Kjartan From christopher.hotchkiss at gmail.com Thu Jan 27 04:56:57 2005 From: christopher.hotchkiss at gmail.com (Christopher Hotchkiss) Date: Wed, 26 Jan 2005 23:56:57 -0500 Subject: duplicating a disk In-Reply-To: <1106779214.2729.8.camel@localhost.localdomain> References: <20050124160120.2f20c1c8.fedora@wir-sind-cool.org> <1106579417.2365.15.camel@support02.civic.twp.ypsilanti.mi.us> <200501261104.48148.cfk@pacbell.net> <1106770749.23956.4.camel@rousalka.dyndns.org> <1106779214.2729.8.camel@localhost.localdomain> Message-ID: <7f48492a0501262056464a319f@mail.gmail.com> On Wed, 26 Jan 2005 23:40:15 +0100, Kyrre Ness Sjobak wrote: > ons, 26.01.2005 kl. 21.19 skrev Nicolas Mailhot: > > Le mercredi 26 janvier 2005 ? 11:04 -0800, cfk a ?crit : > > > Gentlemen: > > > > > > I have a situation where I need to make a number of identical computers all > > > with the same fedoraCore2. > > > > > > I have tried putting a second (hdb) disk, doing a "df" on hda and based on > > > the number of 1024 blocks going: > > > > > > dd if=/dev/hda of=/dev/hdb bs=1024 count= > > > > > > and it blinks the light a long time and then croaks. > > > > > > I know I did something similar to this a couple of years ago on a different > > > project. Can someone tell me where I am going awry and perhaps educate me a > > > little bit more. > > > > If you can setup an nfs or ftp/http server somewhere the fastest method > > is network install via kickstart (using pxe if you can) > > > > It might take a little longer to setup but you'll make up the time very > > fast. And if you do not have exactly the same hardware (same components > > & firmware versions) it's way safer. > > or you could do the setup you said, just use dd to copy te stuff over. > Just boot it off a cdrom. > Don't use dd for this. If you have different size hard drive, partition or something else down the line, it can really mess you up. I would recommend a simple tar or rsync command to copy them over. This is if you wish to do copy machine to machine. Otherwise a custom kickstart file with pxe is a lot easier if done right. -- Christopher Hotchkiss (813)960-9273 http://www.post227.org From lux at diesel-research.com Thu Jan 27 06:19:56 2005 From: lux at diesel-research.com (Kim Lux) Date: Wed, 26 Jan 2005 23:19:56 -0700 Subject: duplicating a disk In-Reply-To: <1106770749.23956.4.camel@rousalka.dyndns.org> References: <20050124160120.2f20c1c8.fedora@wir-sind-cool.org> <1106579417.2365.15.camel@support02.civic.twp.ypsilanti.mi.us> <200501261104.48148.cfk@pacbell.net> <1106770749.23956.4.camel@rousalka.dyndns.org> Message-ID: <1106806797.7446.2.camel@localhost.localdomain> I wrote this about 2 years ago. I think it is still relevant. One of the ways I would improve it is to use a USB-IDE enclosure for the target drive as you wouldn't have to use Linux rescue nor reboot. FWIW : I just spent about 2 days figuring out how to easily clone a Linux HD. I'm writing this to hopefully save someone else the grief that I've gone through. I'm a relative newbie to Linux. I'm sure the experienced Linux people can enhance/correct/improve what I've written here, but at least this works. My setup is a PC clone with multiple HD bays and a CDROM player. My source drive is a 6.4 GB IDE hard drive with 3 partitions: boot, swap and root. It is nearly full. I'm running RH8.0 using kernel 2.4.18.something. The new drive, herein called the "clone", is a 60 GB IDE hard drive. The major steps to cloning a HD are as follows: 1) partition the clone drive 2) format each partition on the clone drive 3) copy files from the old drive to the clone drive 4) set up grub on the clone drive 5) boot it. The whole process sounds intimidating, but it really isn't any different or harder than cloning a DOS drive. Some people say that one should just install a fresh copy of Linux on the new drive, making it a new install rather than a clone install, but that is MUCH more work than just making a clone. My old drive has numerous patches, updates, installs and data installed just about everywhere. It works exactly as I want it to. I wouldn't want to repeat the work that it took to achieve that, so I'll clone it rather than start afresh with a new drive. We use removable hard drives on our PCs. For absolute data safety, when partitioning and formatting hard drives, I remove all drives except the one that I am working on and run from a boot disk. One could easily perform all this work with the new drive mounted alongside an existing drive, but I don't. Thus, all my commands are based on the clone drive being installed as /hda and running from linux rescue. If you are performing your clone with the clone drive installed alongside an existing drive, your commands will be based on /dev/hdb or /dev/hdc, for example. I also assume that the reader knows how to set up his/her BIOS so that it has the proper boot order when needed, ie boot from CDROM first so that linux rescue can be run. In detail: 1) Partition the clone drive. I partitioned the clone drive by running fdisk from linux rescue booted from the install CDROM. When running linux rescue, I DO NOT let the OS mount the hard drive. I always do that manually from the command line when I am doing system maintenance. Once at the command prompt in linux rescue: #/sbin/fdisk /dev/hda Obviously you will change this to suit your partitions and partition types. REMEMBER THAT I INSTALL THE CLONE DRIVE AS PRIMARY MASTER IE: /dev/hda. IF YOU DON'T DO THIS, YOU NEED TO CHANGE THE DRIVE SPECIFICATION This will start fdisk. From here you are on your own. I created 3 linux partitions: boot, swap and root. I made boot (/dev/hda1) to be 100 MB in size and used ext3 for the file system. I made the swap partition (/dev/hda2) twice as big as my motherboard RAM, or 512MB x 2 = 1 GB. It used the Linux swap file type. I made the root (/dev/hda2) partition consume the rest of the drive and gave it a ext3 file type as well. NOTE: One should set the label of the partitions while using fdisk. I didn't and had to later. The root drive (/dev/hda3), for example, should be given a label of "/" to properly work with grub as we'll see later on. 2) Format the partitions If you are following my drive layout, these are the commands you will use. a) Format the boot partition as ext3: #/sbin/mkfs.ext3 /dev/hda1 b) Format the swap partition as linux swap: #/sbin/mkfs.swap /dev/hda2 c) Format the root partition as ext3: #/sbin/mkfs.ext3 /dev/hda3 Obviously you will change this to suit your partitions and partition types. REMEMBER THAT I INSTALL THE CLONE DRIVE AS PRIMARY MASTER IE: /dev/hda. IF YOU DON'T DO THIS, YOU NEED TO CHANGE THE DRIVE SPECIFICATION 3) Copy the data from the old drive to the clone drive. To do this, I reboot my computer with both the source and the clone drive in the bays. I usually boot with the source drive in /hda (ie primary master) and the clone drive in /hdc (ie secondary master). My reasoning for doing this is that sometimes new drives (ie the clone) have much newer technology than the old drive and the two will not operate properly on the same ide channel. By putting one on the primary channel and the other on the secondary channel, I can clone really old drives (1995 vintage 1 GB, for example) onto new drives (latest 120 GB) without any problems. There are two partions that we need to copy data from: the boot partion and the root partion. I prefer to do these copies as two distinct mounts and copies. One could mount the source drive hierarchically and also the clone drive and then issue one copy command, but for only 2 partitions I prefer to do 2 separate copy commands. Again I boot linux rescue from the CDROM and bypass any automatic mounting of filesystems. First I mount the old boot partion as /oldboot # cd / # mkdir oldboot # mount -text3 /dev/hda1 /oldboot # cd oldboot # ls Next, I mount the new boot partition as /newboot #cd / # mkdir newboot # mount -text3 /dev/hdc1 /newboot # cd newboot # ls Now, I copy the data from the old boot partition to the new boot partition: # cp -aR /oldboot/* /newboot 2>/newboot/error.log The -a attribute tells cp to keep all of the current attributes. The -R attribute tells cp to do a recursive copy. optional: if you want to watch the filenames stream by while they are being copied, add a "-v" to the attributes, ie "-avR" The "2>error.log" tells the OS to redirect the stderror output of cp into the error.log file in /newboot. The boot partition is fairly small, so this shouldn't take very long. When the copy is done, I do the following: # cd /newboot # ls # more error.log < a display of the error.log file should appear. It should be empty or nearly so .> Note: one could write a script that compared the attributes of every file in /newboot to every file in /oldboot, but I haven't found this to be necessary. As long as there are no alarming errors in error.log, the new partition should have all the files that the source drive had. Now I repeat that copy process for the root partition: # cd / # mkdir newroot # mount -text3 /dev/hdc3 /newroot # ls /newroot # mkdir oldroot # mount -text3 /dev/hda3 /oldroot # ls /oldroot # # cp -aR /oldroot/* /newroot 2>/newroot/error.log # cd newroot # ls # more error.log If both error.log files are clean, consider your copy successful. Although the partitions and formated and the data has been copied, the clone drive is still not bootable. BTW: many experienced linux people will tell you to use dd or tar or several other copy processes together with pipes and redirection. They might be faster, but I had trouble with most of them in one or more situations. cp is easy to understand and I've yet to find an instance where it doesn't work. 4) Set up grub on the new drive. Here is where I got hung up and where most people get stuck. First, we need to install grub into the boot sector of the boot drive/partition. This does NOT occur automatically when formating the boot partion, nor when copying the root files. This is akin to performing a >sys c: in Dos. To install grub on the boot sector, we need to run something called grub-install from the command line, but first we must mount our filesystem and set up a new root directory using our new filesystem. Here is how I do that: a) boot linux rescue with the clone drive installed as /hda ie primary master. (It could actually be done with the drive mounted anywhere.) b) mount the new cloned filesystem as it will be in the computer when running, but mount it under /new. NOTE: some people will tell you to mount it under /mnt, which already exists in linux rescue. Don't do this. Why ? Because the command shell for linux rescue appears to be running under /mnt and when/if you mount the new filesystem under /mnt, you will no longer have a shell to run under ! Ie, you won't have access to ls, mount, chroot, etc. So, here are my commands: # mkdir new # mount -text3 /dev/hda3 /new # ls /new

# mount -text3 /dev/hda1 /new/boot # ls /new/boot We've now got our cloned filesystem mounted exactly as it will be in our new system, but under /new. The boot partition (/dev/hda1) is mounted in /boot just like it will be when we run the drive. We didn't really need to do the root hierarchical mounting, but I like it that way. Now, we change the root directory of our filesystem and start a new bash shell. We need to do this because grub-install is not present on the linux rescue shell: # chroot /new /bin/bash This command will make / be what /new/ was. It will also start /bin/bash, which was /new/bin/bash, which is the bash shell on our cloned drive. We can now go to work using all the tools present on our cloned drive, ie all the tools that were present on the old drive. We can actually startX is we need to, although I never have. We need to install grub onto the boot sector of the boot drive, so: # /sbin/grub-install /dve/hda1 BTW: if we want to learn about grub, we can use man grub or info grub now. info grup-install is interesting to read. Neither man nor info are available in linux rescue mode. Grub is now installed on the boot sector, but sometimes it needs to be configured to find grub.conf. Grub.conf is the configuration file that grub runs to know what kernels to offer for booting, where the images are, etc. Grub config is located in hda1/grub/, which is really /boot/grub. (Remember that we mounted hda1 as /new/boot/, but our chroot changed that to /boot/.) "info grub" in the FAQ part contains this nice little gem: I have a separate boot partition and GRUB doesn't recognize it. This is often reported as a "bug", but this is not a bug really. This is a feature. Because GRUB is a boot loader and it normally runs under no operating system, it doesn't know where a partition is mounted under your operating systems. So, if you have the partition `/boot' and you install GRUB images into the directory `/boot/grub', GRUB recognizes that the images lies under the directory `/grub' but not `/boot/grub'. That's fine, since there is no guarantee that all of your operating systems mount the same partition as `/boot'. There are several solutions for this situation. 1. Install GRUB into the directory `/boot/boot/grub' instead of `/boot/grub'. This may sound ugly but should work fine. 2. Create a symbolic link before installing GRUB, like `cd /boot && ln -s . boot'. This works only if the filesystem of the boot partition supports symbolic links and GRUB supports the feature as well. 3. Install GRUB with the command `install', to specify the paths of GRUB images explicitly. Here is an example: grub> root (hd0,1) grub> install /grub/stage1 d (hd0) /grub/stage2 p /grub/grub.conf I like option number 3, so that is what I run. However, my boot drive is /dev/hda1, which is (hd0,0). (See info grub for info on how grub specifies drives. Remember that all drive numbers in grub are base 0, not base 1). I thus run the following commands: # grub grub> root (hd0,0) grub> install /grub/stage1 d (hd0) /grub/stage2 p /grub/grub.conf grub> exit Grub itself is now set up in the boot sector and it knows where grub.conf is. If grub.conf worked well in the source drive, it should work well on the cloned drive. At this point, your drive is bootable, although it probably won't boot. Here is the rub: many of the entries in grub, automount and init files refer to drives by their LABEL. Yes, there are now 3 ways to refer to drives in Linux: 1) by the device ie: /dev/hda1, hda2, etc. see man mount for more on this. 2) by the grub specification ie: (hd0,0) see info grub for more on this. 3) by the drive label. It is handy for certain linux processes to be able to refer to drives by their function (ie root, boot, etc.) rather than have them hardcoded into the /dev/ spec. Thus, certain processes refer to drives by their label, which is chosen to indicate their function. It turns out that certain processes in the boot process refer to the root drive by its label, which they expect to be "/". In order for our clone drive to boot properly, we need to set its label to "/". Issue the following command to do this: # e2label /dev/hda3 "/" There might be other ways to do this, like during fdisk or mkfs, but I am a newbie, remember. I think that labels can be checked with hdparm, but I can't remember. Interestingly enough the clone drive boots with only the label for root changed. I did not have to change the label for the boot partition. However, I'm sure that somewhere there is an application or process that will refer to the boot partition by its label, thus I would set its label to /boot as well: # el2label /dev/hda1 "/boot" Your clone drive should now be an exact image of the source drive and bootable. Using Clones I keep a small, outdated drive with nothing but a clean, uptodate copy of Linux on it. Anytime we need to build a new drive for a new computer or a new process (in an existing computer via installing a new drive), I just clone the "clean" drive. This works really well with new users (friends) because I know how everything is set up and they don't have to muddle through the installation process. The Beauty of Linux This whole process could actually be done as one script, with the grub commands put into a separate grup scrip file. I haven't done it yet, but the whole cloning process would just be a script that could be run at some period of convenience, like just before leaving work for home or just before going to bed. I removed the source drive while formatting and partitioning and rebooted /remounted when setting up grub, but that wouldn't have to be done that way. One more thing: the cloning script could run the new drive and add a few default users as well as initiate the email client. Enjoy !!! possible changes: use mirrordir, but it isn't available on most machines without installing an RPM Change the cp attributes. cp /dir/* won't copy the dot files in /dir/ and this: You are a bit wrong with the cp arguments: the -a arguments archives a whole directory structure, which means: - preserves uig/gid/timestamps, - archives recursively - Doesn't go through symbolic links (it just copies them as well) >From the ls manpage, -a is the same with -dpR So, to mirror your harddisk, just: cp -avx / /mnt/newdisk -v: To view what is being done. -x: To stay to the current filesystem. Lastly, mkdir /proc -- Kim Lux, Diesel Research Inc. From pza at pza.net.au Thu Jan 27 07:01:51 2005 From: pza at pza.net.au (Phil Anderson) Date: Thu, 27 Jan 2005 18:01:51 +1100 Subject: slow hard drives crushing interactivity Message-ID: <20050127070150.GQ31584@harry.pza.net.au> On Mon, 2005-01-24 at 18:29 -0500, Sean wrote: > On Mon, January 24, 2005 6:01 pm, Havoc Pennington said: > > > Maybe a cap on process size, so there can be 1G virtual memory but > > an > > individual app can only use 512M? > > This already exists of course, you can set a ulimit on RSS and virtual > memory size. The kernel doesn't enforce RSS limits. See bug 133675. Phil ---- http://www.pza.net.au/ From byte at aeon.com.my Tue Jan 25 05:01:45 2005 From: byte at aeon.com.my (Colin Charles) Date: Tue, 25 Jan 2005 13:01:45 +0800 Subject: further package removals/potential package removals In-Reply-To: <20050124223104.GA26096@turing.une.edu.au> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <1106369463.5183.24.camel@one.myworld> <20050122165916.GH2898@devserv.devel.redhat.com> <1106582643.22263.39.camel@localhost.localdomain> <20050124223104.GA26096@turing.une.edu.au> Message-ID: <1106629305.5401.16.camel@localhost.localdomain> On Tue, 2005-01-25 at 09:31 +1100, Norman Gaywood wrote: > > because at the moment, we still haven't worked around to define > Extras > > yet > > Is there a definition of Core? http://fedora.redhat.com/participate/terminology.html And we have been releasing Core for the past 3 Fedora Core's that you've been getting, with a schedule for FC-4 out We don't however have a released Extras _yet_ (besides Pre-Extras). After there's a hashing out of the issues to make Extras happen (sure I know there's terminology for it), we can start making sure that nobody thinks of it as "inferior" ... then the task goes on to defining Alternatives :-> -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From byte at aeon.com.my Tue Jan 25 05:07:56 2005 From: byte at aeon.com.my (Colin Charles) Date: Tue, 25 Jan 2005 13:07:56 +0800 Subject: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106452796.7211.491.camel@mccallum.corsepiu.local> <1106546143.7129.7.camel@localhost.localdomain> Message-ID: <1106629676.5401.21.camel@localhost.localdomain> On Mon, 2005-01-24 at 14:07 -0200, Alexandre Oliva wrote: > > The old way of thinking about this has got to go. _Moving_ something to > > Extras is not the same thing as removing it from the distro. > > Then where's the Extras rawhide tree? Are we going to have Extras We haven't gotten around to deciding if Extras should be either a rolling release, or branched off based on how we release Core. As to a Rawhide tree, I don't think we've had the chance to think that far, but we should duly note this down when it comes to discussing about Extras > ISOs rolled out along with the test releases? Without this, Extras There's been thought about this, but no consensus. Let me say this is to be added to the agenda for discussions > just won't get as much testing because they're not going to work with > rawhide or test releases. And for people who depend on packages from > Extras, this means they're less likely to run the test releases or > track rawhide, which means less testing. Agreed, you bring up good points > Unless Extras is really part of the distro infrastructure, instead of > a dump of packages people don't want in the core distro, the quality > of the distro as a whole is going to suffer. The plan is to make it part of the distro infrastructure, rest assured (as per the terminology) > I really hope we're going to see FC4 Extras test1 CD go out on the > same day as FC4test1, and even have snapshots of them a few days > before to sanity-check before the actual test release. A +1 to this, but as reality hits, I don't think this is going to happen in time. But miracles do happen sometimes ;-) So here's hoping there's mighty discussion at FUDCon and we actually have a good outcome from it all, and move forward from there -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From byte at aeon.com.my Tue Jan 25 05:29:28 2005 From: byte at aeon.com.my (Colin Charles) Date: Tue, 25 Jan 2005 13:29:28 +0800 Subject: Fedora PPC things... Message-ID: <1106630968.5401.42.camel@localhost.localdomain> CC'ing fedora-devel-list because there are some things that need to be sorted for a possible FC-4/ppc _release_ Now, a list of known issues: 0. this boot.iso + nfs installation system has to go away - so we need to give anaconda love 1. out of the box video detection - system-config-display needs to be hacked on to recognise all the common Mac hardware bits out there. We can't be pushing Xautoconfig or something similar... but we can lean on it for inspiration if need be 2. anaconda and partitioning - auto partitioning possibly still fails (I don't think the Apple Bootstrap partition gets created); running yabootconfig automatically after installation, with an appropriate initrd and so on needs to happen (we can't depend on users breaking out into a shell) 3. sound is still relatively broken - dmasound_pmac tends to work, but is not the default config. system-config-soundcard definitely needs some work to make it play well with the Macs 4. power management - we need either pmud or pbbuttonsd. The latter has received no love from most fedora/ppc users, so pmud seems to be the winner, I'd guess. We need this included in Core (building only for ppc, and possibly later ppc64). We know yellow dog add some nice patches for disabling the touchpad in pmud - I guess the package maintainer can be free to include such patches at will if need be 5. updates - we can't have david woodhouse (dwmw2) grabbing packages from the RH build system and having to host them at ftp.linux.org.uk - we need a better mechanism. i.e. the normal way package updates go out, can the ppc and ppc64 packages go out with them too? This might involve some policy change at Red Hat, so can someone in the know, speak up? 6. back to the topic of power management; there are some patches out there that help G4 iBooks and newer powerbooks sleep (and wake up). They're not in the upstream kernel.org kernel, but with good benh approval (!), we might consider patching the kernel to make it more useful. dwmw2 currently builds kernels with these patches enabled 7. we'll be upfront about modems and Airport Extreme probably never working for free. Modems have drivers at linuxant (though they still might be flaky with our stack size in the kernel), but the Airport Extreme stuff is probably a no go (not yet at least) 8. 64-bit support. I personally don't have a G5 or anything ppc64, but I know that dwmw2 has one sitting at work, as probably does nasrat. We need more 64-bit testing, and making sure that anaconda boots on them too (if not we need more anaconda hacking). There have been reports that things were (or are still) broken on a 64-bit arch 9. PegasosPPC (Genesi) makers of PPC boards have thought of getting FC4/ppc to work on their machines. I'll be taking a look at this, though does anyone else have such machines around? 10. spanking MiniMac support? I guess this is a list of outstanding issues that we need to fix before Fedora Core 4 gets a PPC release. If I missed anything glaring, do add on the the thread Otherwise, lets get some C and Python hackers hacking on the packages above, and making things "just work" for FC/ppc. PPC specific discussion can take place at fedora-ppc at lists.infradead.org -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From jkeating at j2solutions.net Thu Jan 27 08:11:10 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 27 Jan 2005 00:11:10 -0800 Subject: Fedora PPC things... In-Reply-To: <1106630968.5401.42.camel@localhost.localdomain> References: <1106630968.5401.42.camel@localhost.localdomain> Message-ID: <1106813471.8367.73.camel@localhost.localdomain> On Tue, 2005-01-25 at 13:29 +0800, Colin Charles wrote: > I guess this is a list of outstanding issues that we need to fix > before > Fedora Core 4 gets a PPC release. If I missed anything glaring, do add > on the the thread > Battery Life somewhat sucks right now. Not sure if it's for everybody or just me. Bug in pmud or whatever for my G3 ibook where I have to disable HALd before going to sleep and re-enabling it when coming out of sleep. Patches to airport driver to allow for scanning for wireless networks. Asking around for the essid gets you strange looks sometimes. Graphical boot support? I haven't gotten this to work yet, but haven't spend a lot of cycles. UI to configure mouse button emulation Any work to make video-out function would be VERY nice. I don't like having to reboot to OS X in order to present on a projector. Some work or status report on Mac-on-Linux. Very handy for media formats ppc-linux doesn't yet handle, w/out having to reboot the entire system. -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From christof at damian.net Thu Jan 27 08:28:39 2005 From: christof at damian.net (Christof Damian) Date: Thu, 27 Jan 2005 09:28:39 +0100 Subject: redhat abe Message-ID: <20050127082839.GE29221@batman.gotham.krass.com> I just read about RedHat ABE (Application Build Environment) which seems to be something similar to mach. Will this be available or work on fedora? Has anyone tried it ? I found some info here: http://people.redhat.com/mwaite/ Christof -- Christof Damian christof at damian.net From caolanm at redhat.com Thu Jan 27 08:42:26 2005 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 27 Jan 2005 08:42:26 +0000 Subject: DSL modem support in Fedora Core needs system-config-network support. In-Reply-To: <1106767529.19262.35.camel@hades.cambridge.redhat.com> References: <1106767529.19262.35.camel@hades.cambridge.redhat.com> Message-ID: <1106815346.9878.5.camel@sheol.homelinux.org> On Wed, 2005-01-26 at 19:25 +0000, David Woodhouse wrote: > (Originally sent to fedora-config-list but trapped for moderation, and I > may get volunteers here too...) > > Fedora Core 3 supports PPP over ATM (PPPoA) with any DSL modem which the > kernel can use as an ATM device -- currently that's only USB modems > based on the Alcatel SpeedTouch chipset, but we're working on more > hardware drivers. A popular irish ISP device is the ZyXEL 630-11 apparently based on the speedtouch. (the driver is hauntingly similiar at least). Available from http://sourceforge.net/projects/zyxel630-11 and has worked well for me, apparently should cover things alternatively branded as... Asus aam600ug, Digicom MichelAngelo USB A, Topcom Webracer 851 PROLiNK Hurricane 8000 C. From byte at aeon.com.my Thu Jan 27 08:36:57 2005 From: byte at aeon.com.my (Colin Charles) Date: Thu, 27 Jan 2005 14:06:57 +0530 Subject: Fedora PPC things... In-Reply-To: <1106813471.8367.73.camel@localhost.localdomain> References: <1106630968.5401.42.camel@localhost.localdomain> <1106813471.8367.73.camel@localhost.localdomain> Message-ID: <1106815018.5598.111.camel@localhost.localdomain> On Thu, 2005-01-27 at 00:11 -0800, Jesse Keating wrote: > Battery Life somewhat sucks right now. Not sure if it's for everybody > or just me. Probably just you. Its always a little worse using Linux than compared to OS X, but thats normal > Bug in pmud or whatever for my G3 ibook where I have to disable HALd > before going to sleep and re-enabling it when coming out of sleep. Hmm, okay. Thats a pmud issue we need to fix > Patches to airport driver to allow for scanning for wireless networks. > Asking around for the essid gets you strange looks sometimes. This is touching the kernel, for Orinoco support... I don't know what davej/arjanv will think about this > Graphical boot support? I haven't gotten this to work yet, but haven't > spend a lot of cycles. Yes, rhgb working on ppc will be nice > UI to configure mouse button emulation Err, the /etc/sysctl.conf entries you mean? I think we need to fix anaconda to make the default the f10/f11 keys to work well > Any work to make video-out function would be VERY nice. I don't like > having to reboot to OS X in order to present on a projector. This is a bit of a hack in Linux/ppc so I don't think we should be integrating it. Though its something we should work towards > Some work or status report on Mac-on-Linux. Very handy for media > formats ppc-linux doesn't yet handle, w/out having to reboot the entire > system. Well, there's qemu ;-) But yes, MOL in Extras/ppc might be nice (don't think we need it in Core, but hey, its okay with me) -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From arjanv at redhat.com Thu Jan 27 09:06:18 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 27 Jan 2005 10:06:18 +0100 Subject: redhat abe In-Reply-To: <20050127082839.GE29221@batman.gotham.krass.com> References: <20050127082839.GE29221@batman.gotham.krass.com> Message-ID: <1106816778.5624.67.camel@laptopd505.fenrus.org> On Thu, 2005-01-27 at 09:28 +0100, Christof Damian wrote: > I just read about Red Hat ABE (Application Build Environment) which > seems to be something similar to mach. the goals are very similar to mach, but mach uses apt which made it not suitable as basis for the ABE > > Will this be available or work on fedora? Has anyone tried it ? it'll work for fc3 for sure; I tested that extensively ;) Older fedoras might need some minor tweaks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Thu Jan 27 09:10:24 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 27 Jan 2005 09:10:24 +0000 Subject: DSL modem support in Fedora Core needs system-config-network support. In-Reply-To: <1106815346.9878.5.camel@sheol.homelinux.org> References: <1106767529.19262.35.camel@hades.cambridge.redhat.com> <1106815346.9878.5.camel@sheol.homelinux.org> Message-ID: <1106817024.783.111.camel@baythorne.infradead.org> On Thu, 2005-01-27 at 08:42 +0000, Caolan McNamara wrote: > A popular irish ISP device is the ZyXEL 630-11 > apparently based on the speedtouch. (the driver is hauntingly similiar > at least). Available from http://sourceforge.net/projects/zyxel630-11 > and has worked well for me, apparently should cover things > alternatively branded as... Needs to get into the kernel. Looking at their CVS I see they've had a go at merging with what I did for the SpeedTouch driver. I'll chase them up. -- dwmw2 From dwmw2 at infradead.org Thu Jan 27 09:15:05 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 27 Jan 2005 09:15:05 +0000 Subject: Fedora PPC things... In-Reply-To: <1106815018.5598.111.camel@localhost.localdomain> References: <1106630968.5401.42.camel@localhost.localdomain> <1106813471.8367.73.camel@localhost.localdomain> <1106815018.5598.111.camel@localhost.localdomain> Message-ID: <1106817305.783.119.camel@baythorne.infradead.org> On Thu, 2005-01-27 at 14:06 +0530, Colin Charles wrote: > On Thu, 2005-01-27 at 00:11 -0800, Jesse Keating wrote: > > > Battery Life somewhat sucks right now. Not sure if it's for everybody > > or just me. > > Probably just you. Its always a little worse using Linux than compared > to OS X, but thats normal Enabling dynamic clocks in the radeon driver might help improve that. > > Bug in pmud or whatever for my G3 ibook where I have to disable HALd > > before going to sleep and re-enabling it when coming out of sleep. > > Hmm, okay. Thats a pmud issue we need to fix I lose the brightness buttons after a suspend/resume cycle. That wouldn't be so annoying, but if I resume on battery, something tends to blank the screen a little while after resume... and then it's a PITA to turn it back on again :) If it ever happened when I was at home (i.e. if it happened when there was power too), I'd have investigated it more by now. > > Patches to airport driver to allow for scanning for wireless networks. > > Asking around for the essid gets you strange looks sometimes. > > This is touching the kernel, for Orinoco support... I don't know what > davej/arjanv will think about this Upstream first. Where? > > Graphical boot support? I haven't gotten this to work yet, but haven't > > spend a lot of cycles. > > Yes, rhgb working on ppc will be nice Works for me. > > Some work or status report on Mac-on-Linux. Very handy for media > > formats ppc-linux doesn't yet handle, w/out having to reboot the entire > > system. I played with MoL last April but never got the kernel bits to build. Possibly a candidate for Extras if anyone has a patience to beat it into submission. > Well, there's qemu ;-) Qemu is nice. Runs i386 acroread relatively sanely -- even runs i386 acroread7 if you install all the gtk/pango stuff in /usr/qemu-i386 for it. RPM support for cross-arch stuff like that would be good; some people need it for i386-on-ia64 anyway. -- dwmw2 From arjanv at redhat.com Thu Jan 27 09:30:54 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 27 Jan 2005 10:30:54 +0100 Subject: redhat abe In-Reply-To: <1106818309.6474.3.camel@localhost.localdomain> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106818309.6474.3.camel@localhost.localdomain> Message-ID: <20050127093054.GA28511@devserv.devel.redhat.com> On Thu, Jan 27, 2005 at 10:31:49AM +0100, Christian Fredrik Kalager Schaller wrote: > On Thu, 2005-01-27 at 10:06 +0100, Arjan van de Ven wrote: > > On Thu, 2005-01-27 at 09:28 +0100, Christof Damian wrote: > > > I just read about Red Hat ABE (Application Build Environment) which > > > seems to be something similar to mach. > > > > the goals are very similar to mach, but mach uses apt which made it not > > suitable as basis for the ABE > > I hope that was not the real reason for doing ABE instead of using mach, > as changing mach to use yum would probably be trivial. Sometimes I feel RHEL does not use yum either, so yum was not an option either. From rms at 1407.org Thu Jan 27 09:46:23 2005 From: rms at 1407.org (Rui Miguel Seabra) Date: Thu, 27 Jan 2005 09:46:23 +0000 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106786772.17991.43.camel@bree.local.net> References: <1106629396.28420.92.camel@bree.local.net> <88C3252C-6F23-11D9-B78E-000D9352858E@linuxmail.org> <1106782965.3593.11.camel@roque> <1106786772.17991.43.camel@bree.local.net> Message-ID: <1106819183.3530.9.camel@roque> On Wed, 2005-01-26 at 19:46 -0500, Jeremy Katz wrote: > On Wed, 2005-01-26 at 23:42 +0000, Rui Miguel Seabra wrote: > > And do you notice xorg.conf being rewritten on a xen kernel boot? > > > > Because mine is... > > Can you get a diff of old and what gets changed? This might be kudzu > auto-reconfiguring things for what it detects I'm almost sure it is. I believe that the xen-itized Linux that boots might detect the hardware differently. Perhaps stuff like diffs of lspci and post-boot dmesg would be more useful? Anyway, my xen-itized Linux boots in runlevel 3 and I don't use rhgb. Rui -- + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From teg at pvv.org Thu Jan 27 09:44:24 2005 From: teg at pvv.org (=?UTF-8?B?VHJvbmQgRWl2aW5kIEdsb21zcsO4ZA==?=) Date: Thu, 27 Jan 2005 10:44:24 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F6C238.2050201@c-note.dk> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> Message-ID: <41F8B7F8.1000304@pvv.org> Casper Pedersen wrote: > >> I think xmms is ugly, no matter what theme you put on it. RhythmBox is >> at least organized in a nice way. >> >> >> > Depends on how you see it; xmms is nice, small, and might not be > pretty, but it works. RythmBox is big and slow to use with very large > collections of files, but it is pretty. Personally, I think xmms looks better. It's plain, but displays what it should and doesn't take a lot of screen estate. Rhythmbox is huge, looks really ugly (not exactly itunes in that respect... it manages to be huge and cluttered while not displaying much) and sloooooooow. When trying to add my music collection (5000 songs or so... got way too many CDs), xmms is finished in an instant. Rhythmbox just stays unresponsive for 30 mins using all CPU, not displaying any progress or letting you do anything. Then I just want my system back and puts it out of its misery. Rhythmbox shouldn't displace better working alternatives until it has gotten useful. From rahulsundaram at yahoo.co.in Thu Jan 27 09:22:55 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Thu, 27 Jan 2005 01:22:55 -0800 (PST) Subject: rawhide report: 20050126 changes In-Reply-To: <1106771586.29597.72.camel@cutter> Message-ID: <20050127092255.47838.qmail@web8507.mail.in.yahoo.com> --- seth vidal wrote: > > > Complaining about a free gift is not overly > polite. > > That's funny - from what I can tell it is the mantra > of most open source > software development. > > > or to put it another way: > "Look a gift horse in the mouth" true. otherwise we wouldnt be able to direct any sort of criticism, constructive or otherwise at the fedora project or even Linux ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From rahulsundaram at yahoo.co.in Thu Jan 27 09:32:23 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Thu, 27 Jan 2005 01:32:23 -0800 (PST) Subject: HAL features needed In-Reply-To: <1106760161.3357.20.camel@localhost.localdomain> Message-ID: <20050127093223.97226.qmail@web8505.mail.in.yahoo.com> Hi . Since this is an > implementation issue and > not some global freedesktop.org issue, at least in > my mind, I posted > here. its a implementation issue but not one which is limited to fedora. IMHO it would be have been better to take it to the corresponding list, either dbus or hal. you dont actually have to be brilliant or something just to initiate a discussion. take me as an example ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From n3npq at nc.rr.com Thu Jan 27 10:55:39 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 27 Jan 2005 05:55:39 -0500 Subject: redhat abe In-Reply-To: <1106816778.5624.67.camel@laptopd505.fenrus.org> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> Message-ID: <41F8C8AB.8070202@nc.rr.com> Arjan van de Ven wrote: >On Thu, 2005-01-27 at 09:28 +0100, Christof Damian wrote: > > >>I just read about Red Hat ABE (Application Build Environment) which >>seems to be something similar to mach. >> >> Hmmm, nice stuff. Finally, someone has packaged up a KISSy chroot based build system, very cool. Watch out for: * rpm-4.1.1 won't create multilib packaging correctly on AS2.1. You ought to lose rpm-4.1.1 at your earliest opportunity. Move to rpm-4.2.2-0.8 (at least), and with external beecrypt and elfutils, and you should be fine. * --aid is as good or bad as the rpmdb used. I don't yet see tools to manage rpmdb headers incrementally, and --justdb from the rpm CLI is a blunderbuss. Much better could be done. In fact has been done ... * perl sux equally as much as python ;-) >the goals are very similar to mach, but mach uses apt which made it not >suitable as basis for the ABE > I suggested to mach developers quite some time ago that --aid was more than enough to populate an empty chroot from rpm packages. Thanks for the manifest proof that, indeed, --aid is sufficient. > > >>Will this be available or work on fedora? Has anyone tried it ? >> >> > >it'll work for fc3 for sure; I tested that extensively ;) >Older fedoras might need some minor tweaks > Aside from the issues above, I dunno of any rpm implementation problems that would prevent rhel-abe from being used for any/all of FCn, but there's a great deal of churn-and-burn packaging and rpm details that need to be accomodated. Probably that's what you mean by "tweaks". There are later versions of rpm built for FC1/FC2/FC3 at ftp://ftp.rpm.org/pub/rpm/test that will never ever be released "officially" (due to lack of interest), but those packages might be useful as starting points for adjusting some of the "tweaks" between fc1/fc2/fc3/fc4. Latest possible common version of rpm for all of fc1/fc2/fc3/fc4 would only help eliminate "tweaks". Disclaimer: I dunno where rhel-abe came from, and I dunno where rhel-abe is going, and I've never used rhel-abe, or knew rhel-abe existed, until an hour ago. So my comments are from examining the srpm, nothing more. Good luck! 73 de Jeff From ivg2 at cornell.edu Thu Jan 27 11:22:52 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 27 Jan 2005 04:22:52 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F8B7F8.1000304@pvv.org> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> Message-ID: <1106824972.3239.32.camel@cobra.ivg2.net> On Thu, 2005-01-27 at 10:44 +0100, Trond Eivind Glomsr?d wrote: > Casper Pedersen wrote: > > > > >> I think xmms is ugly, no matter what theme you put on it. RhythmBox is > >> at least organized in a nice way. > >> > >> > >> > > Depends on how you see it; xmms is nice, small, and might not be > > pretty, but it works. RythmBox is big and slow to use with very large > > collections of files, but it is pretty. > > > Personally, I think xmms looks better. It's plain, but displays what it > should and doesn't take a lot of screen estate. It has awful skins, does not integrate with the rest of the desktop, and does *not* look better. > it manages to be huge > and cluttered while not displaying much) It's not supposed to be on-screen all the time - you're supposed to choose what to play and minimize it, or run it in mini mode. It's a nice browser for music collections. I am just waiting for it to finally integrate with musicbrainz, and support a radio station browser. > and sloooooooow. When trying to > add my music collection (5000 songs or so... got way too many CDs), xmms > is finished in an instant. Does xmms let you search? Does it organize by genre? By album? Does it support drag and drop playlist editing? Radio stations? Does it minimize in the notification area? > Rhythmbox just stays unresponsive for 30 mins > using all CPU, not displaying any progress or letting you do anything. I have about half your collection, and by extrapolating I can tell that this this is a huge exaggeration on any modern machine. Furthermore you're not supposed to be adding your entire collection every time. You do that once, so speed is a non-issue. My main complaint is that for me is starts leaking memory when I try to add that many songs at once, eventually using up all system resources, and getting killed by the OOM killer. Happens 2/3 times. That is a bug, not normal behavior. I'll file a bugzilla some day when I get sufficiently annoyed. > Rhythmbox shouldn't displace better working alternatives until it has > gotten useful. It's a database-backed music player, and cannot be compared to xmms, which is totally different. It's very useful - I use it all the time. xmms is the ancient past. -- Ivan Gyurdiev Cornell University From arjanv at redhat.com Thu Jan 27 11:31:48 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 27 Jan 2005 12:31:48 +0100 Subject: redhat abe In-Reply-To: <41F8C8AB.8070202@nc.rr.com> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <41F8C8AB.8070202@nc.rr.com> Message-ID: <20050127113148.GD28511@devserv.devel.redhat.com> > > * perl sux equally as much as python ;-) think of it as shell script with regexps :) > >it'll work for fc3 for sure; I tested that extensively ;) > >Older fedoras might need some minor tweaks > > > Aside from the issues above, I dunno of any rpm implementation > problems that would prevent rhel-abe from being used for any/all > of FCn, but there's a great deal of churn-and-burn packaging and rpm > details that need to be accomodated. Probably that's what you mean by > "tweaks". the tweaks are mostly in the area of the minimum list of packages needed to bootstrap a distro; that varies. Once this critical mass is installed it'll work fine From dwmw2 at infradead.org Thu Jan 27 11:34:28 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 27 Jan 2005 11:34:28 +0000 Subject: rawhide report: 20050126 changes In-Reply-To: <20050126144636.GA7010@redhat.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> Message-ID: <1106825668.19262.37.camel@hades.cambridge.redhat.com> On Wed, 2005-01-26 at 09:46 -0500, Andrew Overholt wrote: > We were having some stability issues with 3.1M4 natively compiled. > I'm hoping to go back to a 3.1 milestone build before FC4. Hmm. Now there's no PPC package. Is it possible to build 3.0 for PPC? -- dwmw2 From strange at nsk.no-ip.org Thu Jan 27 11:56:27 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Thu, 27 Jan 2005 11:56:27 +0000 Subject: rawhide report: 20050126 changes In-Reply-To: <1106825668.19262.37.camel@hades.cambridge.redhat.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> <1106825668.19262.37.camel@hades.cambridge.redhat.com> Message-ID: <20050127115627.GA30006@nsk.no-ip.org> On Thu, Jan 27, 2005 at 11:34:28AM +0000, David Woodhouse wrote: > On Wed, 2005-01-26 at 09:46 -0500, Andrew Overholt wrote: > > We were having some stability issues with 3.1M4 natively compiled. > > I'm hoping to go back to a 3.1 milestone build before FC4. > > Hmm. Now there's no PPC package. Is it possible to build 3.0 for PPC? If you have a jre, you can use the standard eclipse-SDK-3.0.1-linux-gtk.zip with http://gsd.di.uminho.pt/old/luciano/eclipse-SDK-3.0.1-linux-gtk-x86_ppc.tar.gz on top. Regards, Luciano Rocha -- 2/16 From thomas at apestaart.org Thu Jan 27 12:06:03 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Thu, 27 Jan 2005 13:06:03 +0100 Subject: redhat abe In-Reply-To: <41F8C8AB.8070202@nc.rr.com> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <41F8C8AB.8070202@nc.rr.com> Message-ID: <1106827564.1316.5.camel@otto.amantes> Hi, > * perl sux equally as much as python ;-) Maybe even more :) > >the goals are very similar to mach, but mach uses apt which made it not > >suitable as basis for the ABE > > > I suggested to mach developers quite some time ago that --aid was more than > enough to populate an empty chroot from rpm packages. Thanks for the > manifest > proof that, indeed, --aid is sufficient. If all you want to do is populate an empty chroot then it is. For a system like this you need more. There's no good way to resolve dependencies using only rpm. And when you are trying to do more than just "build against this known set of packages I have locally on my hard disk" it's insufficient. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> when he died all he left us was alone <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From teg at pvv.org Thu Jan 27 12:09:52 2005 From: teg at pvv.org (=?UTF-8?B?VHJvbmQgRWl2aW5kIEdsb21zcsO4ZA==?=) Date: Thu, 27 Jan 2005 13:09:52 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106824972.3239.32.camel@cobra.ivg2.net> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <1106824972.3239.32.camel@cobra.ivg2.net> Message-ID: <41F8DA10.7090809@pvv.org> Ivan Gyurdiev wrote: >On Thu, 2005-01-27 at 10:44 +0100, Trond Eivind Glomsr?d wrote: > > >>Casper Pedersen wrote: >> >> >>>Depends on how you see it; xmms is nice, small, and might not be >>>pretty, but it works. RythmBox is big and slow to use with very large >>>collections of files, but it is pretty. >>> >>> >>Personally, I think xmms looks better. It's plain, but displays what it >>should and doesn't take a lot of screen estate. >> >> > >It has awful skins, does not integrate with the rest of the desktop, >and does *not* look better. > > Taste differs. >>it manages to be huge >>and cluttered while not displaying much) >> >> > >It's not supposed to be on-screen all the time - you're supposed >to choose what to play and minimize it, or run it in mini mode. > > I typically just put it on a screen I never visit. >It's a nice browser for music collections. I am just waiting for >it to finally integrate with musicbrainz, and support a radio station >browser. > > I just don't think it does that in a good way... >>and sloooooooow. When trying to >>add my music collection (5000 songs or so... got way too many CDs), xmms >>is finished in an instant. >> >> > >Does xmms let you search? > Yes. > Does it organize by genre? By album? Does it support drag and drop playlist editing? >Radio stations? Does it minimize in the notification area? > > Do I like ITunes? Yes. I just happen to think that Rhythmbox does it really badly... >> Rhythmbox just stays unresponsive for 30 mins >>using all CPU, not displaying any progress or letting you do anything. >> >> > >I have about half your collection, and by extrapolating I can tell that >this this is a huge exaggeration on any modern machine. > I wish. Unfortunately, I'm not. Maybe its just slower on mp3s? (systems I've tried this on is an Athlon 2200+ and Centrino 1.4 MHz, both with a bit of RAM). > Furthermore >you're not supposed to be adding your entire collection every time. > > I do it because get fed up and kill it eventually, before it finishes... besides, I would do it often anyway, as I encode new CDs with grip/lame and just think it's easier to add the top dir to scan for new files. >You do that once, so speed is a non-issue. > > Not when it is so slow and uninformative that you're convinced it must have crashed. From n3npq at nc.rr.com Thu Jan 27 12:12:12 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 27 Jan 2005 07:12:12 -0500 Subject: redhat abe In-Reply-To: <1106827564.1316.5.camel@otto.amantes> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <41F8C8AB.8070202@nc.rr.com> <1106827564.1316.5.camel@otto.amantes> Message-ID: <41F8DA9C.7040702@nc.rr.com> Thomas Vander Stichele wrote: >>>the goals are very similar to mach, but mach uses apt which made it not >>>suitable as basis for the ABE >>> >>> >>> >>I suggested to mach developers quite some time ago that --aid was more than >>enough to populate an empty chroot from rpm packages. Thanks for the >>manifest >>proof that, indeed, --aid is sufficient. >> >> > >If all you want to do is populate an empty chroot then it is. For a >system like this you need more. There's no good way to resolve >dependencies using only rpm. And when you are trying to do more than >just "build against this known set of packages I have locally on my hard >disk" it's insufficient. > > Not true, but I can see you are still in denial, and with perhaps a different vision of what is needed. Certainly no offense to either you or mach is specifically intended, I'm an equal opportunity offender ;-) Hint: Lose the bleeping subliminal messages in the mach progress bar. ;-) 73 de Jeff From thomas at apestaart.org Thu Jan 27 12:13:12 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Thu, 27 Jan 2005 13:13:12 +0100 Subject: redhat abe In-Reply-To: <1106816778.5624.67.camel@laptopd505.fenrus.org> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> Message-ID: <1106827992.1316.14.camel@otto.amantes> Hi Arjan, > > I just read about Red Hat ABE (Application Build Environment) which > > seems to be something similar to mach. > > the goals are very similar to mach, but mach uses apt which made it not > suitable as basis for the ABE I have to bite here :) Given that a) mach has been used by some people over some time; b) people working on mach have repeatedly tried to discuss with Red Hat and said "hey, we'd like to work with you on a build system to be used by all", as part of the "community" project that is Fedora; but no attempts were made from Red Hat to unify forces; c) nothing more was ever offered as negative feedback on mach than "it uses apt" (a fact that is easily changeable, obviously); d) you could easily have asked "hey, can't mach be made to not use apt, but do (insert random feature you would like)" why did the "NIH" syndrome that Red Hat sometimes displays wins out over the desire to involve the community in the "community" project ? I am behind Red Hat and Fedora 100% of the way, against the flames of friends who really do not understand why this Fedora thing is all talk and no action. Things like this are just one of the many things symptomatic of the fact that Red Hat seems to want us to believe there's a community to be involved in, when in fact there is no such thing. I realize that you probably don't care, and that you have a job to do, and it's already hard enough as it is, and sometimes it's just easier to Do Your Own Thing to Get The Job Done. And this is very much not a personal flame at you, just a flame at Red Hat in general. To put it ghetto-style - when is RH going to stop talking the talk and start walking the walk ? Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Say what you mean or you won't mean a thing to me <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From arjanv at redhat.com Thu Jan 27 12:21:20 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 27 Jan 2005 13:21:20 +0100 Subject: redhat abe In-Reply-To: <1106827992.1316.14.camel@otto.amantes> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> Message-ID: <20050127122120.GA27750@devserv.devel.redhat.com> On Thu, Jan 27, 2005 at 01:13:12PM +0100, Thomas Vander Stichele wrote: > Hi Arjan, > > > > I just read about Red Hat ABE (Application Build Environment) which > > > seems to be something similar to mach. > > > > the goals are very similar to mach, but mach uses apt which made it not > > suitable as basis for the ABE > > I have to bite here :) > > Given that > a) mach has been used by some people over some time; > b) people working on mach have repeatedly tried to discuss with Red Hat > and said "hey, we'd like to work with you on a build system to be used > by all", as part of the "community" project that is Fedora; but no > attempts were made from Red Hat to unify forces; > c) nothing more was ever offered as negative feedback on mach than "it > uses apt" (a fact that is easily changeable, obviously); > d) you could easily have asked "hey, can't mach be made to not use apt, > but do (insert random feature you would like)" > > why did the "NIH" syndrome that Red Hat sometimes displays wins out over > the desire to involve the community in the "community" project ? mach has a different goal than the ABE. Add the apt/yum use of mach (which for the goal mach has, is perfectly fine) and I made the call that using mach for the ABE was not a real option. You call it NIH. Shrug. I started out by looking at mach to see if it could be adjusted, but it didn't look like it could be without compromising what mach was made for. > I realize that you probably don't care, and that you have a job to do, > and it's already hard enough as it is, and sometimes it's just easier to > Do Your Own Thing to Get The Job Done. And this is very much not a > personal flame at you, just a flame at Red Hat in general. In this case it's very much a case of different goals of different tools. They somewhat look the same (and that's why I started by looking at mach) but they really are not. (and the ABE you see today is not the ABE in the projected roadmap) For a fedora buildsystem, mach is 100x better than the ABE will ever be, and I really would suggest anyone here to use mach if they want to build packages for fedora. From jwboyer at jdub.homelinux.org Thu Jan 27 12:24:29 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 27 Jan 2005 06:24:29 -0600 Subject: Fedora PPC things... In-Reply-To: <1106630968.5401.42.camel@localhost.localdomain> References: <1106630968.5401.42.camel@localhost.localdomain> Message-ID: <1106828669.15391.80.camel@jdub.homelinux.org> On Tue, 2005-01-25 at 13:29 +0800, Colin Charles wrote: > > I guess this is a list of outstanding issues that we need to fix before > Fedora Core 4 gets a PPC release. If I missed anything glaring, do add > on the the thread Not saying this has to be in FC4, but getting the PPC tree to work on older rs6ks would be nice. Would liberate quite a few machines from old and crusty SuSE ;). Maybe add that to the "eventual goals for FC PPC tree". josh From fedora-devel at camperquake.de Thu Jan 27 12:28:00 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 27 Jan 2005 13:28:00 +0100 Subject: Fedora PPC things... In-Reply-To: <1106630968.5401.42.camel@localhost.localdomain> References: <1106630968.5401.42.camel@localhost.localdomain> Message-ID: <20050127132800.1b7918ad@nausicaa.camperquake.de> Hi. Colin Charles wrote: > 3. sound is still relatively broken No problems so far on my mac. The microphone does not work. > 10. spanking MiniMac support? Isn't that just an iBook in a different case? 11. We need a working kernel. The last one working for me is 2.6.9-1.667. Later kernels have trouble with ptrace, or do not exist at all. 12. Firewire detection does not work, at least on my iBook. Firewire itself works when you manually load the driver. (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140753) On the positive side, the latest Xorg from rawhide has magically enabled DRI on my iBook (xorg-x11-6.8.1.902-4). 3D is slow (rage128), but definitely faster than software rendering :) Note: all hardware notes above are from a 500MHz iBook2. -- "The academia created 1 day greenwich time is bastardly queer and dooms future youth and nature to a hell" -- www.timecube.com From fedora-devel at camperquake.de Thu Jan 27 12:36:13 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 27 Jan 2005 13:36:13 +0100 Subject: Fedora PPC things... In-Reply-To: <20050127132800.1b7918ad@nausicaa.camperquake.de> References: <1106630968.5401.42.camel@localhost.localdomain> <20050127132800.1b7918ad@nausicaa.camperquake.de> Message-ID: <20050127133613.7eb636f4@nausicaa.camperquake.de> Hi. Ralf Ertzinger wrote: > On the positive side, the latest Xorg from rawhide has magically enabled > DRI on my iBook (xorg-x11-6.8.1.902-4). 3D is slow (rage128), but > definitely faster than software rendering :) bzflag works, celestia works, neverball works, tuxracer crashes and burns :) -- "While boys tend to write nonsense, girls write nonsense neatly underlined." -- St Faith's School prospectus From overholt at redhat.com Thu Jan 27 13:03:18 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 27 Jan 2005 08:03:18 -0500 Subject: rawhide report: 20050126 changes In-Reply-To: <1106825668.19262.37.camel@hades.cambridge.redhat.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> <1106825668.19262.37.camel@hades.cambridge.redhat.com> Message-ID: <20050127130318.GA26855@redhat.com> * David Woodhouse [2005-01-27 06:38]: > On Wed, 2005-01-26 at 09:46 -0500, Andrew Overholt wrote: > > We were having some stability issues with 3.1M4 natively compiled. > > I'm hoping to go back to a 3.1 milestone build before FC4. > > Hmm. Now there's no PPC package. Is it possible to build 3.0 for PPC? Of course. I was planning on doing this today (I have a Fedora iBook myself). Andrew From strange at nsk.no-ip.org Thu Jan 27 13:06:46 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Thu, 27 Jan 2005 13:06:46 +0000 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106629396.28420.92.camel@bree.local.net> References: <1106629396.28420.92.camel@bree.local.net> Message-ID: <20050127130646.GA1523@nsk.no-ip.org> $ readlink /lib/modules/2.6.10-1.1110_FC4xenU/build/include/asm asm-i386 Is this correct? Shouldn't it be asm-xen? Regards, Luciano Rocha -- 2/16 From n3npq at nc.rr.com Thu Jan 27 13:16:55 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 27 Jan 2005 08:16:55 -0500 Subject: redhat abe In-Reply-To: <1106827992.1316.14.camel@otto.amantes> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> Message-ID: <41F8E9C7.8080306@nc.rr.com> Thomas Vander Stichele wrote: >Hi Arjan, > > > >>>I just read about Red Hat ABE (Application Build Environment) which >>>seems to be something similar to mach. >>> >>> >>the goals are very similar to mach, but mach uses apt which made it not >>suitable as basis for the ABE >> >> > >I have to bite here :) > >Given that >a) mach has been used by some people over some time; > True for beehive as well. >b) people working on mach have repeatedly tried to discuss with Red Hat >and said "hey, we'd like to work with you on a build system to be used >by all", as part of the "community" project that is Fedora; but no >attempts were made from Red Hat to unify forces; > Well Red Hat ain't exactly got a mouth, or more specifically, one mouth. I spent several months attempting to unify forces, and I work at Red Hat. That is not "No attempt." And I'm sure there are other, less feeble, attempts from Red Hat to unify than my efforts. >c) nothing more was ever offered as negative feedback on mach than "it >uses apt" (a fact that is easily changeable, obviously); > Well clearly, having mach rely on a package that is not included in any Red Hat product, presents certain logistical difficulties. That should be obvious. >d) you could easily have asked "hey, can't mach be made to not use apt, >but do (insert random feature you would like)" > > I have said repeatedly that mach needs to lose the subliminal messages in the progress bars, even if they're s-o-o-o-o cute! ;-) >why did the "NIH" syndrome that Red Hat sometimes displays wins out over >the desire to involve the community in the "community" project ? > > Assimilating a 3rd -- nay 4th or 5th if I count [rs]-c-p and rpm -- dependency solver into the distro (i.e. apt) in order to accdomodate a poor design choice in mach makes little sense to me. And, FWIW, I have suggested repeatedly that apt be added to FC internally to Red Hat in spite of the cost of attempting to maintain Yet Another Depsolver. The previous line basically summarizes the majority of the feedback that I have heard: FC needs fewer depsolvers that work more reliably. >I am behind Red Hat and Fedora 100% of the way, against the flames of >friends who really do not understand why this Fedora thing is all talk >and no action. Things like this are just one of the many things >symptomatic of the fact that Red Hat seems to want us to believe there's >a community to be involved in, when in fact there is no such thing. > Heh, a casual reading seems to indicate that there is no community for Red Hat to be involved with, perhaps not what you intended. ;-) >I realize that you probably don't care, and that you have a job to do, >and it's already hard enough as it is, and sometimes it's just easier to >Do Your Own Thing to Get The Job Done. And this is very much not a >personal flame at you, just a flame at Red Hat in general. > > So flame away. Do you have any idea what it is like being bathed in flame for months and years, simply because you happen to work for Red Hat? >To put it ghetto-style - when is RH going to stop talking the talk and >start walking the walk ? > > When your momma takes off her combat boots, and not before. ;-) 73 de Jeff From dwmw2 at infradead.org Thu Jan 27 13:17:53 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 27 Jan 2005 13:17:53 +0000 Subject: rawhide report: 20050126 changes In-Reply-To: <20050127130318.GA26855@redhat.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> <1106825668.19262.37.camel@hades.cambridge.redhat.com> <20050127130318.GA26855@redhat.com> Message-ID: <1106831873.19262.80.camel@hades.cambridge.redhat.com> On Thu, 2005-01-27 at 08:03 -0500, Andrew Overholt wrote: > Of course. I was planning on doing this today (I have a Fedora iBook > myself). Cool, thanks. Btw, I did eventually get your flash demo working, by using the package at ftp://ftp.uk.linux.org/pub/people/dwmw2/fc2-mac/RPMS/flash-0.4.10-1.ppc.rpm instead of the swfdec one. -- dwmw2 From skvidal at phy.duke.edu Thu Jan 27 13:26:59 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 27 Jan 2005 08:26:59 -0500 Subject: redhat abe In-Reply-To: <41F8E9C7.8080306@nc.rr.com> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> Message-ID: <1106832419.29597.88.camel@cutter> > Heh, a casual reading seems to indicate that there is no community for > Red Hat > to be involved with, perhaps not what you intended. ;-) You really don't want to start the discussion of what it is that is holding up the devel/community process. Not on a public list. It will be embarrassing to red hat, especially if it got picked up by lwn like one of the last times we had these complaints. But if you'd like that I'd be more than glad to give my not-so-edited- for-television version of it. > So flame away. Do you have any idea what it is like being bathed in > flame for months > and years, simply because you happen to work for Red Hat? Do you have any idea what it's like being bathed in flames for months and years at a time b/c you're trying to VOLUNTEER to help out an organization that appears to actively wish to deter your help? At least you get paid to get flamed. I get flamed and laughed at for free. so pull the other one, its got bells on. -sv From n3npq at nc.rr.com Thu Jan 27 13:39:28 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 27 Jan 2005 08:39:28 -0500 Subject: redhat abe In-Reply-To: <1106832419.29597.88.camel@cutter> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106832419.29597.88.camel@cutter> Message-ID: <41F8EF10.2070202@nc.rr.com> seth vidal wrote: > >Do you have any idea what it's like being bathed in flames for months >and years at a time b/c you're trying to VOLUNTEER to help out an >organization that appears to actively wish to deter your help? At least >you get paid to get flamed. I get flamed and laughed at for free. > > I warned you when I added yum to FC: You are so so doomed! And thanks for shouldering much of the depsolver diagnosis load with yum support. That is personally appreciated. >so pull the other one, its got bells on. > > So you want to get paid to be flamed? I'm sure that can be arranged if/when you wish. Me, I want peace and quiet for a change, there's work to do. 73 de Jeff From dwmw2 at infradead.org Thu Jan 27 13:42:44 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 27 Jan 2005 13:42:44 +0000 Subject: Fedora PPC things... In-Reply-To: <20050127132800.1b7918ad@nausicaa.camperquake.de> References: <1106630968.5401.42.camel@localhost.localdomain> <20050127132800.1b7918ad@nausicaa.camperquake.de> Message-ID: <1106833365.19262.83.camel@hades.cambridge.redhat.com> On Thu, 2005-01-27 at 13:28 +0100, Ralf Ertzinger wrote: > 11. We need a working kernel. The last one working for me is 2.6.9-1.667. > Later kernels have trouble with ptrace, or do not exist at all. Newer kernels for ppc and ppc64 can be found in my yum repo at ftp://ftp.uk.linux.org/pub/people/dwmw2/fc3-kernel-ppc -- dwmw2 From skvidal at phy.duke.edu Thu Jan 27 13:46:27 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 27 Jan 2005 08:46:27 -0500 Subject: redhat abe In-Reply-To: <41F8EF10.2070202@nc.rr.com> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106832419.29597.88.camel@cutter> <41F8EF10.2070202@nc.rr.com> Message-ID: <1106833587.29597.92.camel@cutter> > So you want to get paid to be flamed? No, the flaming will always be there. I'd rather that the idea of 'volunteering' to help out fedora/red hat wasn't a laughably silly idea. braaaaaaaaaaaaaaaaanes. -sv From rc040203 at freenet.de Thu Jan 27 13:44:12 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 27 Jan 2005 14:44:12 +0100 Subject: redhat abe In-Reply-To: <41F8E9C7.8080306@nc.rr.com> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> Message-ID: <1106833452.22312.93.camel@mccallum.corsepiu.local> On Thu, 2005-01-27 at 08:16 -0500, Jeff Johnson wrote: > Thomas Vander Stichele wrote: > > >c) nothing more was ever offered as negative feedback on mach than "it > >uses apt" (a fact that is easily changeable, obviously); > > > > Well clearly, having mach rely on a package that is not included in any Red > Hat product, RH has the ability to change this at any time. > presents certain logistical difficulties. > That should be obvious. It is not - RH has had no problems in adding yum support and has no problem in adding and removing other packages at any time at RH's free will. For example instead of adding yum and keeping up2date, RH could have tried to help apt. - IMO, this is all politics and not at all technically motivated. > And, FWIW, I have suggested repeatedly that apt be added to FC > internally to Red Hat > in spite of the cost of attempting to maintain Yet Another Depsolver. > The previous line > basically summarizes the majority of the feedback that I have heard: > > FC needs fewer depsolvers that work more reliably. Isn't the solution obvious? Implement one unified depsolver into rpm which behaves exactly as you envision it, instead. Ralf From harald at redhat.com Thu Jan 27 13:48:00 2005 From: harald at redhat.com (Harald Hoyer) Date: Thu, 27 Jan 2005 14:48:00 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106824972.3239.32.camel@cobra.ivg2.net> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <1106824972.3239.32.camel@cobra.ivg2.net> Message-ID: <41F8F110.4050908@redhat.com> Ivan Gyurdiev wrote: > Does xmms let you search? Does it organize by genre? > By album? Does it support drag and drop playlist editing? > Radio stations? Does it minimize in the notification area? > > >> Rhythmbox just stays unresponsive for 30 mins >>using all CPU, not displaying any progress or letting you do anything. > > > I have about half your collection, and by extrapolating I can tell that > this this is a huge exaggeration on any modern machine. Furthermore > you're not supposed to be adding your entire collection every time. > You do that once, so speed is a non-issue. > > My main complaint is that for me is starts leaking memory when I try > to add that many songs at once, eventually using up all system > resources, and getting killed by the OOM killer. Happens 2/3 times. > That is a bug, not normal behavior. I'll file a bugzilla some day > when I get sufficiently annoyed. I did not even manage to import my 6000 files... rhythmbox just hang there after a while doing nothing... also there is no UTF-8/ISO-8859-1 recognition... Useless in this state.. From fedora-devel at camperquake.de Thu Jan 27 13:47:34 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 27 Jan 2005 14:47:34 +0100 Subject: Fedora PPC things... In-Reply-To: <1106833365.19262.83.camel@hades.cambridge.redhat.com> References: <1106630968.5401.42.camel@localhost.localdomain> <20050127132800.1b7918ad@nausicaa.camperquake.de> <1106833365.19262.83.camel@hades.cambridge.redhat.com> Message-ID: <20050127144734.23734034@nausicaa.camperquake.de> Hi. David Woodhouse wrote: > Newer kernels for ppc and ppc64 can be found in my yum repo at > ftp://ftp.uk.linux.org/pub/people/dwmw2/fc3-kernel-ppc Do these numbers match those in rawhide? -- "Recognise that you evolved up from a chimp, not down from a deity. There's no reason to expect a chimp-derivative to have their act together and be perfectly balanced in a technological society." -- Aldabra Stoddart From skvidal at phy.duke.edu Thu Jan 27 13:52:37 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 27 Jan 2005 08:52:37 -0500 Subject: redhat abe In-Reply-To: <1106833452.22312.93.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> Message-ID: <1106833957.29597.96.camel@cutter> > RH has the ability to change this at any time. ability? yes. willingness? no. > It is not - RH has had no problems in adding yum support and has no > problem in adding and removing other packages at any time at RH's free > will. Do you know why they had no issue adding yum support? B/c it could be covered internally. If it broke and I wasn't around to fix it - they could take care of it. 100+ lines of C++ they were not interested in maintaining. > For example instead of adding yum and keeping up2date, RH could have > tried to help apt. - IMO, this is all politics and not at all > technically motivated. IMO you don't know what you're talking about. -sv From skvidal at phy.duke.edu Thu Jan 27 13:53:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 27 Jan 2005 08:53:39 -0500 Subject: redhat abe In-Reply-To: <1106833957.29597.96.camel@cutter> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> Message-ID: <1106834019.29597.98.camel@cutter> On Thu, 2005-01-27 at 08:52 -0500, seth vidal wrote: > > RH has the ability to change this at any time. > > ability? yes. willingness? no. > > > > It is not - RH has had no problems in adding yum support and has no > > problem in adding and removing other packages at any time at RH's free > > will. > > Do you know why they had no issue adding yum support? B/c it could be > covered internally. If it broke and I wasn't around to fix it - they > could take care of it. > > 100+ lines of C++ they were not interested in maintaining. That should be 100K+ lines of C++ 100 lines of c++ will just barely get you hello world :) -sv From buildsys at redhat.com Thu Jan 27 13:55:11 2005 From: buildsys at redhat.com (Build System) Date: Thu, 27 Jan 2005 08:55:11 -0500 Subject: rawhide report: 20050127 changes Message-ID: <200501271355.j0RDtB431195@porkchop.devel.redhat.com> From harald at redhat.com Thu Jan 27 13:59:40 2005 From: harald at redhat.com (Harald Hoyer) Date: Thu, 27 Jan 2005 14:59:40 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <20050124232113.GM31520@neu.nirvana> References: <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> Message-ID: <41F8F3CC.2070503@redhat.com> Axel Thimm wrote: > Already posted in different siblings of this thread and implemented at > ATrpms. Auto-expiring packages that should be disposed of if there is > no dependency on them should simply provide a fake dependency to hook > a garbage collector to. > > The concept is solid, proven on various distros and even within the > Red Hat world at ATrpms. > Very nice idea! From dwmw2 at infradead.org Thu Jan 27 14:01:06 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 27 Jan 2005 14:01:06 +0000 Subject: Fedora PPC things... In-Reply-To: <20050127144734.23734034@nausicaa.camperquake.de> References: <1106630968.5401.42.camel@localhost.localdomain> <20050127132800.1b7918ad@nausicaa.camperquake.de> <1106833365.19262.83.camel@hades.cambridge.redhat.com> <20050127144734.23734034@nausicaa.camperquake.de> Message-ID: <1106834467.19262.91.camel@hades.cambridge.redhat.com> On Thu, 2005-01-27 at 14:47 +0100, Ralf Ertzinger wrote: > David Woodhouse wrote: > > > Newer kernels for ppc and ppc64 can be found in my yum repo at > > ftp://ftp.uk.linux.org/pub/people/dwmw2/fc3-kernel-ppc > > Do these numbers match those in rawhide? Not really. They're FC3-derived builds, and they _may_ coincide with FC3 errata. Sometimes I build myself a new PPC kernel when I notice that there's been an erratum for the FC3 kernel, and sometimes I do it just because I feel like it or have a new patch to test. If it do it because of an erratum then it may be the same version, or it may be a slightly later one from CVS. I don't know why Dave stopped building the official kernel packages for FC3, but he seems to have turned it back on now -- the next build should include ppc and ppc64 support again, and hence turn up in my other yum repo at ftp://ftp.uk.linux.org/pub/people/dwmw2/fc3-updates-ppc -- dwmw2 From harald at redhat.com Thu Jan 27 14:01:41 2005 From: harald at redhat.com (Harald Hoyer) Date: Thu, 27 Jan 2005 15:01:41 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> Message-ID: <41F8F445.3080903@redhat.com> Aurelien Bompard wrote: > Sounds interesting. On the other hand, maybe we could do it manually (from a > packager's point of view) : if you package library foo, and you know that > version 0.1 is not supported anymore (noone knows that better than you > since you maintain it), you can add an Obsoletes tag to your libfoo5 > package, and force the removal. > Would that solve Jeff's issue ? Or you release a new release of that version which provides the garbage collector symbol, Axel suggested. From malists at epon.ro Thu Jan 27 14:05:15 2005 From: malists at epon.ro (Marius Andreiana) Date: Thu, 27 Jan 2005 16:05:15 +0200 Subject: rhytmbox vs. xmms (was Re: grip being removed [Re: rawhide report: 20050120 changes]) In-Reply-To: <41F8F110.4050908@redhat.com> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <1106824972.3239.32.camel@cobra.ivg2.net> <41F8F110.4050908@redhat.com> Message-ID: <1106834715.9094.6.camel@marte.biciclete.ro> On Thu, 2005-01-27 at 14:48 +0100, Harald Hoyer wrote: > I did not even manage to import my 6000 files... rhythmbox just hang there > after a while doing nothing... Same here. xmms starts adds 5k files in ~5 seconds and then just works. Jumping works great if files are named "artist-title", and I don't need to enable reading meta-tags in advance. -- Marius Andreiana Epon Business Applications http://www.epon.ro From harald at redhat.com Thu Jan 27 14:06:41 2005 From: harald at redhat.com (Harald Hoyer) Date: Thu, 27 Jan 2005 15:06:41 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <41F54D5B.1000208@nc.rr.com> References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> <20050124185747.GI19903@neu.nirvana> <41F54D5B.1000208@nc.rr.com> Message-ID: <41F8F571.6010302@redhat.com> Jeff Johnson wrote: > And there's no need for the *.spec churn and the marker in dependencies: > > rpm -qa 'classdict=*shared object*' > > 73 de Jeff > which fails on RHEL4 printing PIE packages also... From fedora-devel at camperquake.de Thu Jan 27 14:06:24 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 27 Jan 2005 15:06:24 +0100 Subject: Fedora PPC things... In-Reply-To: <1106834467.19262.91.camel@hades.cambridge.redhat.com> References: <1106630968.5401.42.camel@localhost.localdomain> <20050127132800.1b7918ad@nausicaa.camperquake.de> <1106833365.19262.83.camel@hades.cambridge.redhat.com> <20050127144734.23734034@nausicaa.camperquake.de> <1106834467.19262.91.camel@hades.cambridge.redhat.com> Message-ID: <20050127150624.2b668980@nausicaa.camperquake.de> Hi. David Woodhouse wrote: > I don't know why Dave stopped building the official kernel packages for > FC3, JFI, I am running rawhide (not FC3), and the rawhide kernels are disabled because of the 4 level page table patch, it seems. -- The subscription model of buying music is bankrupt. I think you could make available the Second Coming in a subscription model, and it might not be successful. -- Steve Jobs From n3npq at nc.rr.com Thu Jan 27 14:07:24 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 27 Jan 2005 09:07:24 -0500 Subject: redhat abe In-Reply-To: <1106833452.22312.93.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> Message-ID: <41F8F59C.1000700@nc.rr.com> Ralf Corsepius wrote: >On Thu, 2005-01-27 at 08:16 -0500, Jeff Johnson wrote: > > >>Thomas Vander Stichele wrote: >> >> >> > > > >>>c) nothing more was ever offered as negative feedback on mach than "it >>>uses apt" (a fact that is easily changeable, obviously); >>> >>> >>> >>Well clearly, having mach rely on a package that is not included in any Red >>Hat product, >> >> >RH has the ability to change this at any time. > > So does mach. > > >> presents certain logistical difficulties. >> That should be obvious. >> >> >It is not - RH has had no problems in adding yum support and has no >problem in adding and removing other packages at any time at RH's free >will. > > It's not obvious that mach (as is) will never function on any Red Hat (or Red Hat packages) based distro unless apt is included? I beg to differ. Yum, because in python, and because developed more closely with other Red Hat tools like anaconda originally at YDL and now locally at Duke, was an easier cost/benefit decision. apt, because in C++, with concepts like Suggests: and Recommends: and Enhances: and pinning and a back-tracking depsolver and alien etc etc, is a far far more complicated integration effort with a less clear cost/benefit analysis. Red Hat has very few people able or willing to support apt, for historical, if not for other reasons. >For example instead of adding yum and keeping up2date, RH could have >tried to help apt. - IMO, this is all politics and not at all >technically motivated. > > I have helped apt-rpm, and have helped smartpm, and have helped Red Carpet, and other distros technically with rpm for years. And I work for Red Hat. Does that count? > > >>And, FWIW, I have suggested repeatedly that apt be added to FC >>internally to Red Hat >>in spite of the cost of attempting to maintain Yet Another Depsolver. >>The previous line >>basically summarizes the majority of the feedback that I have heard: >> >> FC needs fewer depsolvers that work more reliably. >> >> >Isn't the solution obvious? Implement one unified depsolver into rpm >which behaves exactly as you envision it, instead. > > What do you think I am trying to do, grow bananas in Chapel Hill? I have been trying to build the infrastructure for a unified package manager for *years*. And so has Red Hat, but the politics are insurmountable imho. Where have you been? 73 de Jeff From davej at redhat.com Thu Jan 27 14:11:09 2005 From: davej at redhat.com (Dave Jones) Date: Thu, 27 Jan 2005 09:11:09 -0500 Subject: Fedora PPC things... In-Reply-To: <20050127150624.2b668980@nausicaa.camperquake.de> References: <1106630968.5401.42.camel@localhost.localdomain> <20050127132800.1b7918ad@nausicaa.camperquake.de> <1106833365.19262.83.camel@hades.cambridge.redhat.com> <20050127144734.23734034@nausicaa.camperquake.de> <1106834467.19262.91.camel@hades.cambridge.redhat.com> <20050127150624.2b668980@nausicaa.camperquake.de> Message-ID: <20050127141109.GC21442@redhat.com> On Thu, Jan 27, 2005 at 03:06:24PM +0100, Ralf Ertzinger wrote: > Hi. > > David Woodhouse wrote: > > > I don't know why Dave stopped building the official kernel packages for > > FC3, > > JFI, I am running rawhide (not FC3), and the rawhide kernels are disabled > because of the 4 level page table patch, it seems. I think that got fixed up a week or so later, sadly a half dozen other things broke, and I lost patience fighting it. I'll retry the build every so often, but right now ppc32 is in a sorry state upstream. Dave From n3npq at nc.rr.com Thu Jan 27 14:17:36 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 27 Jan 2005 09:17:36 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <41F8F571.6010302@redhat.com> References: <41F4D908.5080007@nc.rr.com> <41F4E1E1.3060708@nc.rr.com> <41F4E45B.6050004@redhat.com> <1106570484.32065.1.camel@ulysse.olympe.o2t> <20050124151136.31801589@nausicaa.camperquake.de> <20050124185747.GI19903@neu.nirvana> <41F54D5B.1000208@nc.rr.com> <41F8F571.6010302@redhat.com> Message-ID: <41F8F800.8040102@nc.rr.com> Harald Hoyer wrote: > Jeff Johnson wrote: > >> And there's no need for the *.spec churn and the marker in dependencies: >> >> rpm -qa 'classdict=*shared object*' >> >> 73 de Jeff >> > > which fails on RHEL4 printing PIE packages also... > which is a data problem, maintaining magic with the latest and greatest rules, so that the appropriate rules are used and included in metadata when packages are built. Try file your-favorite-PIE-executable rpm gets the same answer as file, for exactly the same reasons. Patches cheerfully accepted! 73 de Jeff From dwmw2 at infradead.org Thu Jan 27 14:18:55 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 27 Jan 2005 14:18:55 +0000 Subject: Fedora PPC things... In-Reply-To: <20050127141109.GC21442@redhat.com> References: <1106630968.5401.42.camel@localhost.localdomain> <20050127132800.1b7918ad@nausicaa.camperquake.de> <1106833365.19262.83.camel@hades.cambridge.redhat.com> <20050127144734.23734034@nausicaa.camperquake.de> <1106834467.19262.91.camel@hades.cambridge.redhat.com> <20050127150624.2b668980@nausicaa.camperquake.de> <20050127141109.GC21442@redhat.com> Message-ID: <1106835536.19262.92.camel@hades.cambridge.redhat.com> On Thu, 2005-01-27 at 09:11 -0500, Dave Jones wrote: > I think that got fixed up a week or so later, sadly a half dozen other > things broke, and I lost patience fighting it. I'll retry the build > every so often, but right now ppc32 is in a sorry state upstream. Yeah. I poked it last week and sent patches upstream to fix everything that broke. They'll trickle through. I assumed it wasn't worth giving you the patches directly for inclusion in the interim. -- dwmw2 From fedora-devel at camperquake.de Thu Jan 27 14:19:25 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 27 Jan 2005 15:19:25 +0100 Subject: Fedora PPC things... In-Reply-To: <20050127141109.GC21442@redhat.com> References: <1106630968.5401.42.camel@localhost.localdomain> <20050127132800.1b7918ad@nausicaa.camperquake.de> <1106833365.19262.83.camel@hades.cambridge.redhat.com> <20050127144734.23734034@nausicaa.camperquake.de> <1106834467.19262.91.camel@hades.cambridge.redhat.com> <20050127150624.2b668980@nausicaa.camperquake.de> <20050127141109.GC21442@redhat.com> Message-ID: <20050127151925.2847dab8@nausicaa.camperquake.de> Hi. Dave Jones wrote: > I think that got fixed up a week or so later, sadly a half dozen other > things broke, and I lost patience fighting it. I'll retry the build > every so often, but right now ppc32 is in a sorry state upstream. > http://www.redhat.com/mailman/listinfo/fedora-devel-list I tried to rebuild 2.6.10-1.1107 on my iBook. Took ages and does not even start booting. -- Ergometer = Schlussfolgerungsmessgeraet From felipe_alfaro at linuxmail.org Thu Jan 27 14:24:13 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Thu, 27 Jan 2005 15:24:13 +0100 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: References: <1106629396.28420.92.camel@bree.local.net> <88C3252C-6F23-11D9-B78E-000D9352858E@linuxmail.org> Message-ID: On 27 Jan 2005, at 00:33, Rik van Riel wrote: > On Tue, 25 Jan 2005, Felipe Alfaro Solana wrote: > >> In my case, I need to: >> >> mv /lib/tls /lib/tls.disabled >> >> or Xen will hang during boot. > > I have not seen this happen here. Could you get a backtrace > and system details needed for me to figure out why the bug is > happening or how to reproduce it ? I'm sorry I'm unable to test this right now. I'm currently "bk pull"ing from the latest xeno-unstable branch and it seems to work fine with TLS. From felipe_alfaro at linuxmail.org Thu Jan 27 14:24:34 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Thu, 27 Jan 2005 15:24:34 +0100 Subject: Fedora and Xen: A Quick Start Guide In-Reply-To: <1106782965.3593.11.camel@roque> References: <1106629396.28420.92.camel@bree.local.net> <88C3252C-6F23-11D9-B78E-000D9352858E@linuxmail.org> <1106782965.3593.11.camel@roque> Message-ID: On 27 Jan 2005, at 00:42, Rui Miguel Seabra wrote: > On Wed, 2005-01-26 at 18:33 -0500, Rik van Riel wrote: >> On Tue, 25 Jan 2005, Felipe Alfaro Solana wrote: >> >>> In my case, I need to: >>> >>> mv /lib/tls /lib/tls.disabled >>> >>> or Xen will hang during boot. >> >> I have not seen this happen here. Could you get a backtrace >> and system details needed for me to figure out why the bug is >> happening or how to reproduce it ? > > And do you notice xorg.conf being rewritten on a xen kernel boot? > > Because mine is... Kudzu? From rc040203 at freenet.de Thu Jan 27 14:24:14 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 27 Jan 2005 15:24:14 +0100 Subject: redhat abe In-Reply-To: <1106833957.29597.96.camel@cutter> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> Message-ID: <1106835854.22312.101.camel@mccallum.corsepiu.local> On Thu, 2005-01-27 at 08:52 -0500, seth vidal wrote: > > RH has the ability to change this at any time. > > ability? yes. willingness? no. > > > > It is not - RH has had no problems in adding yum support and has no > > problem in adding and removing other packages at any time at RH's free > > will. > > Do you know why they had no issue adding yum support? B/c it could be > covered internally. If it broke and I wasn't around to fix it - they > could take care of it. > > 100+ lines of C++ they were not interested in maintaining. How comes, FE/fedora.us is able to maintain it? I know apt's code is ... ... leaves a lot to be desired, but it doesn't require that much effort to maintain the package. > > For example instead of adding yum and keeping up2date, RH could have > > tried to help apt. - IMO, this is all politics and not at all > > technically motivated. > > IMO you don't know what you're talking about. I guess, I do ... I spent way too much time with rpmlib and apt. Ralf From arjanv at redhat.com Thu Jan 27 14:31:14 2005 From: arjanv at redhat.com (Arjan van de Ven) Date: Thu, 27 Jan 2005 15:31:14 +0100 Subject: redhat abe In-Reply-To: <1106833452.22312.93.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> Message-ID: <1106836275.5624.96.camel@laptopd505.fenrus.org> On Thu, 2005-01-27 at 14:44 +0100, Ralf Corsepius wrote: > On Thu, 2005-01-27 at 08:16 -0500, Jeff Johnson wrote: > > Thomas Vander Stichele wrote: > > > > > >c) nothing more was ever offered as negative feedback on mach than "it > > >uses apt" (a fact that is easily changeable, obviously); > > > > > > > Well clearly, having mach rely on a package that is not included in any Red > > Hat product, > RH has the ability to change this at any time. not for the ABE, that has to work for all past releases which are set in stone. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cmadams at hiwaay.net Thu Jan 27 14:34:34 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 27 Jan 2005 08:34:34 -0600 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106824972.3239.32.camel@cobra.ivg2.net> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <1106824972.3239.32.camel@cobra.ivg2.net> Message-ID: <20050127143434.GA1001457@hiwaay.net> Once upon a time, Ivan Gyurdiev said: > Does xmms let you search? Does it organize by genre? > By album? Does it support drag and drop playlist editing? > Radio stations? Does it minimize in the notification area? Does rhythmbox let me just play a sound file? If I start up xmms, I hit the "eject" button (or right click and choose "Play File") and I get a file selector; I browse to the file I want to play, double click on it and it plays. If I start up rhythmbox, how the heck do I play a sound file? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Peter.Dedecker at vtk2.UGent.be Thu Jan 27 14:34:58 2005 From: Peter.Dedecker at vtk2.UGent.be (Peter Dedecker - FSU) Date: Thu, 27 Jan 2005 14:34:58 +0000 Subject: Stateless Linux - Status Check In-Reply-To: <41F85881.2010607@cpsc.ucalgary.ca> References: <41F85881.2010607@cpsc.ucalgary.ca> Message-ID: <41F8FC12.3030100@VTK.UGent.be> Hi, Erik Williamson wrote: > I was looking to evaluate Stateless Linux. Searching the archives of > this list didn't turn up anything, and Google really only came up > with the announcements in September. I see that the rpms > (http://people.redhat.com/dmalcolm/stateless/) haven't been updated > in a while, nor are they in the development tree - Is there still > work being done on this, has it changed names, etc? As you can see on this message: https://www.redhat.com/archives/fedora-devel-list/2004-December/msg00930.html the fedora statelles project isn't in active development right now. Let's hope RedHat soon has some good news about continuation of this. -- Peter Dedecker The Fedora Stateless @ UGent project http://blog.eikke.com/index.php/fedorastateless From n3npq at nc.rr.com Thu Jan 27 14:36:58 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 27 Jan 2005 09:36:58 -0500 Subject: redhat abe In-Reply-To: <1106835854.22312.101.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> Message-ID: <41F8FC8A.20404@nc.rr.com> Ralf Corsepius wrote: >On Thu, 2005-01-27 at 08:52 -0500, seth vidal wrote: > > >>>RH has the ability to change this at any time. >>> >>> >>ability? yes. willingness? no. >> >> >> >> >>>It is not - RH has had no problems in adding yum support and has no >>>problem in adding and removing other packages at any time at RH's free >>>will. >>> >>> >>Do you know why they had no issue adding yum support? B/c it could be >>covered internally. If it broke and I wasn't around to fix it - they >>could take care of it. >> >>100+ lines of C++ they were not interested in maintaining. >> >> >How comes, FE/fedora.us is able to maintain it? > >I know apt's code is ... ... leaves a lot to be desired, but it doesn't >require that much effort to maintain the package. > > Also not true. The guy who maintained apt-rpm chose to write smartpm instead. That sez' a whole lot about the maintainability of the apt code base. There are many known legacy issues with C++ as well, can't be helped, I'm certainly not complaining. Or perhaps a whole lot about the politics of package management and vendors. One never knows, and one cannot tell. > > >>>For example instead of adding yum and keeping up2date, RH could have >>>tried to help apt. - IMO, this is all politics and not at all >>>technically motivated. >>> >>> >>IMO you don't know what you're talking about. >> >> >I guess, I do ... I spent way too much time with rpmlib and apt. > > Tried smartpm? Best damn depsolver that I've ever seen, does all the (imho) useful stuff that apt does (and yum/up2date do not, at least not yet, like back-tracking), without the C++ baggage and the Debian Borg politics. But, by all means, if *you* like apt, then *you* should use apt. Use what works. 73 de Jeff From skvidal at phy.duke.edu Thu Jan 27 14:49:53 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 27 Jan 2005 09:49:53 -0500 Subject: redhat abe In-Reply-To: <1106835854.22312.101.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> Message-ID: <1106837393.25136.0.camel@opus.phy.duke.edu> > How comes, FE/fedora.us is able to maintain it? they don't. No one is patching apt. It's not being maintained even upstream. How far do you expect it to get? > I know apt's code is ... ... leaves a lot to be desired, but it doesn't > require that much effort to maintain the package. maintaining a package != maintaining the program., > > IMO you don't know what you're talking about. > I guess, I do ... I spent way too much time with rpmlib and apt. really, then you know apt doesn't work, at all, with multilib. You gonna fix that? -sv From n3npq at nc.rr.com Thu Jan 27 15:00:25 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 27 Jan 2005 10:00:25 -0500 Subject: redhat abe In-Reply-To: <1106837393.25136.0.camel@opus.phy.duke.edu> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106837393.25136.0.camel@opus.phy.duke.edu> Message-ID: <41F90209.8060901@nc.rr.com> seth vidal wrote: >really, then you know apt doesn't work, at all, with multilib. > >You gonna fix that? > > I am, one of these days, probably with help from either Gustavo or Panu. But including apt in FC still makes little sense, even though apt makes lots of sense to OSS. JMHO, YMMV, everyone's does. 73 de Jeff From gauret at free.fr Thu Jan 27 15:02:14 2005 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 27 Jan 2005 16:02:14 +0100 Subject: RFC: Soname in rpm name References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com> Message-ID: Harald Hoyer wrote: > Or you release a new release of that version which provides the garbage > collector symbol, Axel suggested. I'd be very happy to do that, but I'd like to know : is this the scheme Red Hat is going to be moving to ? Soname in the package name and a Provides : shared-library-package in the spec file ? Do we agree on this ? I also think it is a great solution, which adresses correctly all the major issues raised here. I'd be very happy to see it become a packaging policy. Thanks Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." -- Rich Cook From fedora-devel at camperquake.de Thu Jan 27 15:13:52 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Thu, 27 Jan 2005 16:13:52 +0100 Subject: Fedora PPC things... In-Reply-To: <1106835536.19262.92.camel@hades.cambridge.redhat.com> References: <1106630968.5401.42.camel@localhost.localdomain> <20050127132800.1b7918ad@nausicaa.camperquake.de> <1106833365.19262.83.camel@hades.cambridge.redhat.com> <20050127144734.23734034@nausicaa.camperquake.de> <1106834467.19262.91.camel@hades.cambridge.redhat.com> <20050127150624.2b668980@nausicaa.camperquake.de> <20050127141109.GC21442@redhat.com> <1106835536.19262.92.camel@hades.cambridge.redhat.com> Message-ID: <20050127161352.278f7b19@nausicaa.camperquake.de> Hi. David Woodhouse wrote: > Yeah. I poked it last week and sent patches upstream to fix everything > that broke. They'll trickle through. I assumed it wasn't worth giving > you the patches directly for inclusion in the interim. Thanks! -- Q. In Malta, on which side of the road do they drive? A. The shady side. From mike at flyn.org Thu Jan 27 15:08:34 2005 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 27 Jan 2005 09:08:34 -0600 Subject: Fedora PPC things... In-Reply-To: <1106630968.5401.42.camel@localhost.localdomain> References: <1106630968.5401.42.camel@localhost.localdomain> Message-ID: <20050127150834.GA4134@imp.flyn.org> [...] > 4. power management - we need either pmud or pbbuttonsd. The latter has > received no love from most fedora/ppc users, so pmud seems to be the > winner, I'd guess. We need this included in Core (building only for ppc, > and possibly later ppc64). We know yellow dog add some nice patches for > disabling the touchpad in pmud - I guess the package maintainer can be > free to include such patches at will if need be [...] > 6. back to the topic of power management; there are some patches out > there that help G4 iBooks and newer powerbooks sleep (and wake up). > They're not in the upstream kernel.org kernel, but with good benh > approval (!), we might consider patching the kernel to make it more > useful. dwmw2 currently builds kernels with these patches enabled See also https://bugzilla.redhat.com/beta/show_bug.cgi?id=140290 for some more notes about the G4 iBook sleep patch. Someone else mentioned mouse-emulation. For a discussion on this, see https://bugzilla.redhat.com/beta/show_bug.cgi?id=108095. [...] -- Mike :wq From rc040203 at freenet.de Thu Jan 27 15:23:42 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 27 Jan 2005 16:23:42 +0100 Subject: redhat abe In-Reply-To: <41F8FC8A.20404@nc.rr.com> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <41F8FC8A.20404@nc.rr.com> Message-ID: <1106839422.22312.145.camel@mccallum.corsepiu.local> On Thu, 2005-01-27 at 09:36 -0500, Jeff Johnson wrote: > Ralf Corsepius wrote: > > >How comes, FE/fedora.us is able to maintain it? > > > >I know apt's code is ... ... leaves a lot to be desired, but it doesn't > >require that much effort to maintain the package. > > > > > > Also not true. The guy who maintained apt-rpm chose to write smartpm > instead. I know. If you're so convinced about smartrpm, why don't you include it into FC and consider to abandon up2date and yum, rsp. to adopt smartrpm's resolver into rpm, rsp. to change yum to use that? > That sez' a whole lot about the maintainability of the apt code base. No disagreement ... as I wrote above ... leaves a lot to be desired. > >>>For example instead of adding yum and keeping up2date, RH could have > >>>tried to help apt. - IMO, this is all politics and not at all > >>>technically motivated. > >>> > >>> > >>IMO you don't know what you're talking about. > >> > >> > >I guess, I do ... I spent way too much time with rpmlib and apt. > > > > > > Tried smartpm? Yes, I tried it for a few hours, a couple of days ago. As I already wrote some days ago, I am not (yet) convinced, at least I could not get familiar with it - Too much black magic involved. May-be I should give it another try and dig a little deeper. > Best damn depsolver that I've ever seen, does all the > (imho) useful > stuff that apt does (and yum/up2date do not, at least not yet, like > back-tracking), Does smartrpm have equivalents to apt-get source apt-get build-dep These are the features I like about apt and which make apt interesting to me. Another feature I am missing in both apt and yum is a usable --download-only operation. apt-get has "-d" but insists on its "package name mangling", (FC3's) yum doesn't support it all, I don't know about smartrpm. > without the C++ baggage and the Debian Borg politics. > > But, by all means, if *you* like apt, then *you* should use apt. Use > what works. It might surprise you: That's what I am doing ;-) Ralf From skvidal at phy.duke.edu Thu Jan 27 15:27:45 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 27 Jan 2005 10:27:45 -0500 Subject: redhat abe In-Reply-To: <1106839422.22312.145.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <41F8FC8A.20404@nc.rr.com> <1106839422.22312.145.camel@mccallum.corsepiu.local> Message-ID: <1106839665.25136.37.camel@opus.phy.duke.edu> > I know. If you're so convinced about smartrpm, why don't you include it > into FC and consider to abandon up2date and yum, rsp. to adopt > smartrpm's resolver into rpm, rsp. to change yum to use that? 1. b/c it's not just his opinion that counts. 2. b/c rh does not control yum development 3. b/c smartrpm, while a nice depsolver, seems to add A LOT of complexity for some highly limited gain to fedora. > Another feature I am missing in both apt and yum is a usable > --download-only operation. > apt-get has "-d" but insists on its "package name mangling", (FC3's) yum > doesn't support it all, I don't know about smartrpm. it's funny, you seem capable of programming except you've not contributed any patches, at all, to yum. Why not add in what you're looking for? It's not like parsing the metadata to do download-only is terribly difficult. -sv From david at fubar.dk Thu Jan 27 15:35:28 2005 From: david at fubar.dk (David Zeuthen) Date: Thu, 27 Jan 2005 10:35:28 -0500 Subject: Fedora PPC things... In-Reply-To: <1106630968.5401.42.camel@localhost.localdomain> References: <1106630968.5401.42.camel@localhost.localdomain> Message-ID: <1106840128.3842.9.camel@daxter.boston.redhat.com> On Tue, 2005-01-25 at 13:29 +0800, Colin Charles wrote: > CC'ing fedora-devel-list because there are some things that need to be > sorted for a possible FC-4/ppc _release_ > > Now, a list of known issues: > > I guess this is a list of outstanding issues that we need to fix before > Fedora Core 4 gets a PPC release. If I missed anything glaring, do add > on the the thread > My Powerbook 12" 867 MHz gets very warm even when idle; I think this is because Hz is set to 1000; if memory serves me right it was a lot better under a kernel with Hz set to 100. Any chance of building the ppc32 kernel with Hz 100? Or did the dynamically set Hz get merged so I may peruse the kernel boot options? Thanks, David From n3npq at nc.rr.com Thu Jan 27 15:33:23 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 27 Jan 2005 10:33:23 -0500 Subject: redhat abe In-Reply-To: <1106839422.22312.145.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <41F8FC8A.20404@nc.rr.com> <1106839422.22312.145.camel@mccallum.corsepiu.local> Message-ID: <41F909C3.1090106@nc.rr.com> Ralf Corsepius wrote: >On Thu, 2005-01-27 at 09:36 -0500, Jeff Johnson wrote: > > >>Ralf Corsepius wrote: >> >> >> > > > >>>How comes, FE/fedora.us is able to maintain it? >>> >>>I know apt's code is ... ... leaves a lot to be desired, but it doesn't >>>require that much effort to maintain the package. >>> >>> >>> >>> >>Also not true. The guy who maintained apt-rpm chose to write smartpm >>instead. >> >> >I know. If you're so convinced about smartrpm, why don't you include it >into FC and consider to abandon up2date and yum, rsp. to adopt >smartrpm's resolver into rpm, rsp. to change yum to use that? > > What do you think I am, the FC God or something? I do think smartpm is a better biscuit, and I have told all the appropriate people. What gets included in FC is an arduous and complicated negotiation, and is usually quite controversial, both with Red Hat and within Fedora. I trust that the right decision will be made in the end. >>Tried smartpm? >> >> >Yes, I tried it for a few hours, a couple of days ago. > > Good. >As I already wrote some days ago, I am not (yet) convinced, at least I >could not get familiar with it - Too much black magic involved. > >May-be I should give it another try and dig a little deeper. > > It's early yet for smartpm, yes. Use what works. > > >> Best damn depsolver that I've ever seen, does all the >>(imho) useful >>stuff that apt does (and yum/up2date do not, at least not yet, like >>back-tracking), >> >> >Does smartrpm have equivalents to > >apt-get source >apt-get build-dep > >These are the features I like about apt and which make apt interesting >to me. > >Another feature I am missing in both apt and yum is a usable >--download-only operation. >apt-get has "-d" but insists on its "package name mangling", (FC3's) yum >doesn't support it all, I don't know about smartrpm. > > No clue, I (blush) do not use apt, and I'm having a good day when the random rpmdb on my box happens to be sufficiently functional and populated that yum does not get too confused. I'm pretty sure Gustavo would be willing to implement new and useful features in smartpm however. 73 de Jeff From notting at redhat.com Thu Jan 27 15:34:10 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 27 Jan 2005 10:34:10 -0500 Subject: Fedora PPC things... In-Reply-To: <1106630968.5401.42.camel@localhost.localdomain> References: <1106630968.5401.42.camel@localhost.localdomain> Message-ID: <20050127153410.GB30139@nostromo.devel.redhat.com> Colin Charles (byte at aeon.com.my) said: > CC'ing fedora-devel-list because there are some things that need to be > sorted for a possible FC-4/ppc _release_ ... > 5. updates - we can't have david woodhouse (dwmw2) grabbing packages > from the RH build system and having to host them at ftp.linux.org.uk - > we need a better mechanism. i.e. the normal way package updates go out, > can the ppc and ppc64 packages go out with them too? This might involve > some policy change at Red Hat, so can someone in the know, speak up? If there is a FC-4/ppc release, this is a nonsensical question; it's a given that the updates will be with the rest. If there's not a PPC release, the updates won't be with x86/x86_64, as that really doesn't make sense (should we push Aurora updates there as well? I don't think so.) It's not really something that requires changes in either case. Bill From laroche at redhat.com Thu Jan 27 16:14:05 2005 From: laroche at redhat.com (Florian La Roche) Date: Thu, 27 Jan 2005 17:14:05 +0100 Subject: redhat abe In-Reply-To: <1106839422.22312.145.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <41F8FC8A.20404@nc.rr.com> <1106839422.22312.145.camel@mccallum.corsepiu.local> Message-ID: <20050127161405.GA15912@dudweiler.stuttgart.redhat.com> > I know. If you're so convinced about smartrpm, why don't you include it > into FC and consider to abandon up2date and yum, rsp. to adopt > smartrpm's resolver into rpm, rsp. to change yum to use that? It is one of the biggest items. Many python-addon tools have additional needs on the depsolver and the transition between rpmlib and python is not easy enough. One of the very good items about yum is that it is actually using the rpmlib depsolver. greetings, Florian La Roche From rc040203 at freenet.de Thu Jan 27 15:50:10 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 27 Jan 2005 16:50:10 +0100 Subject: redhat abe In-Reply-To: <1106839665.25136.37.camel@opus.phy.duke.edu> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <41F8FC8A.20404@nc.rr.com> <1106839422.22312.145.camel@mccallum.corsepiu.local> <1106839665.25136.37.camel@opus.phy.duke.edu> Message-ID: <1106841010.22312.149.camel@mccallum.corsepiu.local> On Thu, 2005-01-27 at 10:27 -0500, seth vidal wrote: > it's funny, you seem capable of programming except you've not > contributed any patches, at all, to yum. Because I have absolutely no clue about python and because I don't have enough spare time to learn it :-) If yum was written in a different language I probably would have provided patches, as I did to many other projects before :-) Ralf From n3npq at nc.rr.com Thu Jan 27 15:55:19 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 27 Jan 2005 10:55:19 -0500 Subject: redhat abe In-Reply-To: <20050127161405.GA15912@dudweiler.stuttgart.redhat.com> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <41F8FC8A.20404@nc.rr.com> <1106839422.22312.145.camel@mccallum.corsepiu.local> <20050127161405.GA15912@dudweiler.stuttgart.redhat.com> Message-ID: <41F90EE7.8060206@nc.rr.com> Florian La Roche wrote: >One of the very good items about yum is that it is actually using the >rpmlib depsolver. > > Ditto wrto smartpm. And up2date, and [rs]-c-p and apt and beehive and rhel-abe, for various definitions of "use" rpmlib, for completeness. up2date is perhaps the most techically close to "using" rpmlib, not that that is any significant or serious advantage, rpmlib is not necessarily the best depsolver in the world. Nor is it very hard to write a goal-driven loop, traversing edges in a dependency graph endlessly, which is all that rpmlib does. What is needed is better policy, not universal "use", for choosing packages to install, from repos, from "cloning" from other machines, etc, as policy is better able to meet user expectations of "works", in a way that stable known mechanism will never be able to achieve. rpmlib (and everything that uses) is quite stupid about choosing between multiple provides, for one obvious example. Multilib, and kernel's, are other known deficiencies in rp[mlib mechanism (or, if you will, the lack of better policy mechanisms for depsolvers). But depsolver policy is a much more complicated topic than using rpmlib ... 73 de Jeff From richard.hubbell at gmail.com Thu Jan 27 15:55:20 2005 From: richard.hubbell at gmail.com (Richard Hubbell) Date: Thu, 27 Jan 2005 07:55:20 -0800 Subject: Stateless Linux - Status Check In-Reply-To: <41F8FC12.3030100@VTK.UGent.be> References: <41F85881.2010607@cpsc.ucalgary.ca> <41F8FC12.3030100@VTK.UGent.be> Message-ID: On Thu, 27 Jan 2005 14:34:58 +0000, Peter Dedecker - FSU wrote: > Hi, > > Erik Williamson wrote: > > I was looking to evaluate Stateless Linux. Searching the archives of > > this list didn't turn up anything, and Google really only came up > > with the announcements in September. I see that the rpms > > (http://people.redhat.com/dmalcolm/stateless/) haven't been updated > > in a while, nor are they in the development tree - Is there still > > work being done on this, has it changed names, etc? > > As you can see on this message: > https://www.redhat.com/archives/fedora-devel-list/2004-December/msg00930.html > the fedora statelles project isn't in active development right now. > Let's hope RedHat soon has some good news about continuation of this. As the message says those outside redhat can continue the work. I just discovered the project by accident recently. Seems to me that if more people knew about it that it would pick up steam. Richard > > -- > Peter Dedecker > The Fedora Stateless @ UGent project > http://blog.eikke.com/index.php/fedorastateless > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From skvidal at phy.duke.edu Thu Jan 27 16:01:58 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 27 Jan 2005 11:01:58 -0500 Subject: redhat abe In-Reply-To: <41F90EE7.8060206@nc.rr.com> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <41F8FC8A.20404@nc.rr.com> <1106839422.22312.145.camel@mccallum.corsepiu.local> <20050127161405.GA15912@dudweiler.stuttgart.redhat.com> <41F90EE7.8060206@nc.rr.com> Message-ID: <1106841719.25136.52.camel@opus.phy.duke.edu> > Ditto wrto smartpm. /me looks at the smartpm code. it doesn't seem like it's using the rpm depsolver overly much. It's using it for the transaction - but it's solving the deps all by itself. > rpmlib (and everything that uses) is quite stupid about choosing between > multiple provides, for one obvious example. Multilib, and kernel's, are > other known deficiencies in rp[mlib mechanism (or, if you will, the > lack of better policy mechanisms for depsolvers). yep - which is why I'm looking forward to using the new check objects that paul was talking about - to better identify the requiring package. -sv From fedora-devel at tlarson.com Thu Jan 27 16:12:07 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Thu, 27 Jan 2005 09:12:07 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F8B7F8.1000304@pvv.org> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> Message-ID: <41F912D7.5080104@tlarson.com> Trond Eivind Glomsr?d wrote: > Personally, I think xmms looks better. It's plain, but displays what it > should and doesn't take a lot of screen estate. Rhythmbox is huge, looks > really ugly (not exactly itunes in that respect... it manages to be huge > and cluttered while not displaying much) and sloooooooow. When trying to > add my music collection (5000 songs or so... got way too many CDs), xmms > is finished in an instant. Rhythmbox just stays unresponsive for 30 mins > using all CPU, not displaying any progress or letting you do anything. > Then I just want my system back and puts it out of its misery. > > Rhythmbox shouldn't displace better working alternatives until it has > gotten useful. > I think we can all agree that no one is against replacing xmms as long as there's a suitable alternative. Rhythmbox, it sounds, is clearly not that alternative. Rhythmbox is a media organization program with a built-in player. Xmms is a media player with some organization capability. The focus of the programs are different, so the interface is different. Clearly, neither one is a direct replacement of the other. Arguments over which one *looks* better are obviously moot--there are enough people on either side of the fence to show that it's simply a matter of taste. If you grew up on Xmms and winamp back in the early days, you'll probably find the Xmms interface perfectly intuitive. If you have a fairly large media collection, you may find Rhythmbox's library-based interface more useful. So, would there be any serious negative consequences of keeping xmms around until a more suitable replacement could be found? What sort of cost/benefit are we talking about in relation to this change? From n3npq at nc.rr.com Thu Jan 27 16:14:25 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Thu, 27 Jan 2005 11:14:25 -0500 Subject: redhat abe In-Reply-To: <1106841719.25136.52.camel@opus.phy.duke.edu> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <41F8FC8A.20404@nc.rr.com> <1106839422.22312.145.camel@mccallum.corsepiu.local> <20050127161405.GA15912@dudweiler.stuttgart.redhat.com> <41F90EE7.8060206@nc.rr.com> <1106841719.25136.52.camel@opus.phy.duke.edu> Message-ID: <41F91361.70006@nc.rr.com> seth vidal wrote: >>Ditto wrto smartpm. >> >> > >/me looks at the smartpm code. > >it doesn't seem like it's using the rpm depsolver overly much. It's >using it for the transaction - but it's solving the deps all by itself. > > > Yep. smartpm has a different, and more elegant, dependency graph and a better depsolver. Nodes in a smartpm dependency graph are packages+operation, not just package. That permits relations (in the topological sort sense) to be explicitly written between identically named nodes, unlike what rpmlib currently does, which is handle install/upgrade/erase operations as a function on the dependency graph. So in a very real sense, smartpm has a better depsolver than rpmlib already. One noticeable deficiency in rpmlib is that erased packages are not topologically sorted, basically because I could not figure how to code the function that traversed the dependency graph with "package" nodes. The solution to ordering erasures and upgrades is obvious (to me anyways) when the nodes are labeled with "package+operation", and so can be ordered more reliably and more correctly. But yes, I can and will teach rpmlib the same trick. Coding with nodes and edges ain't hard at all, what takes thought is the concepts, which smartpm (and Gustavo) does better than rpmlib atm. > > >>rpmlib (and everything that uses) is quite stupid about choosing between >>multiple provides, for one obvious example. Multilib, and kernel's, are >>other known deficiencies in rp[mlib mechanism (or, if you will, the >>lack of better policy mechanisms for depsolvers). >> >> > >yep - which is why I'm looking forward to using the new check objects >that paul was talking about - to better identify the requiring package. > > "check objects" is a mystery to me, just as much of a mystery as rhel-abe was this morning. 73 de Jeff >-sv > > > > From thuforuk at yahoo.co.uk Thu Jan 27 16:19:07 2005 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Thu, 27 Jan 2005 16:19:07 +0000 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106824972.3239.32.camel@cobra.ivg2.net> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <1106824972.3239.32.camel@cobra.ivg2.net> Message-ID: <41F9147B.1060604@yahoo.co.uk> On 01/27/2005 11:22 AM, Ivan Gyurdiev wrote: > On Thu, 2005-01-27 at 10:44 +0100, Trond Eivind Glomsr?d wrote: > >>Casper Pedersen wrote: >> >>>>I think xmms is ugly, no matter what theme you put on it. RhythmBox is >>>>at least organized in a nice way. >>> >>>Depends on how you see it; xmms is nice, small, and might not be >>>pretty, but it works. RythmBox is big and slow to use with very large >>>collections of files, but it is pretty. >> >>Personally, I think xmms looks better. It's plain, but displays what it >>should and doesn't take a lot of screen estate. > > It has awful skins, does not integrate with the rest of the desktop, > and does *not* look better. Matter of taste... >>it manages to be huge >>and cluttered while not displaying much) > > It's not supposed to be on-screen all the time - you're supposed > to choose what to play and minimize it, or run it in mini mode. I have it on my secondary monitor (dual head setup) and have it sit there all the time alongside with gkrellm and whatever else... Who's there to tell me the way I'm supposed to work (or think for that matter)? Not everybody works the same way and forcing it on people is a bad idea. And you can do the same with xmms: select what you want to play and minimize it. > Does xmms let you search? Does it organize by genre? > By album? Does it support drag and drop playlist editing? Don't know, don't use. > Radio stations? Haven't you ever played online radio via xmms? BTW: Rhythmbox freezes on my box when I click on any of the default radio stations... So for me it does not play radio. > Does it minimize in the notification area? Don't know, don't use. >>Rhythmbox shouldn't displace better working alternatives until it has >>gotten useful. +1. > It's a database-backed music player, and cannot be compared to xmms, > which is totally different. Therefore is not an alternative nor replacement. It's rather different application class that happens to play music. Someone mentioned playing a file from filesystem. This is waht I do -- select files or directory from the filesystem and play it. I don't care about database backend. > It's very useful - I use it all the time. I don't. It crashes too often and unfortunately does not work the way I'd like it to :( > xmms is the ancient past. For me it's the present, even if from the past. It just works. In my opinion this discussion shows that there should be place for both programs in FC -- they do things differently and suit different groups of people. Regards, Dariusz From jspaleta at gmail.com Thu Jan 27 16:26:16 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 27 Jan 2005 11:26:16 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F912D7.5080104@tlarson.com> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> Message-ID: <604aa7910501270826672dcfb9@mail.gmail.com> On Thu, 27 Jan 2005 09:12:07 -0700, Tyler Larson wrote: > So, would there be any serious negative consequences of keeping xmms around > until a more suitable replacement could be found? What sort of cost/benefit > are we talking about in relation to this change? I think one underlying goal is to get to a point where the underlying gtk1 libraries are no longer needed in core and can be removed. Being able to remove all of the application that are still using the older gtk libs is a much bigger gain over all. If removing the legacy gtk1 libs is an important goal then replacing xmms with the gtk2 based bmp (aka beep) might be a solution which provides close to enough functionality without getting into complicated discussion about the roles specific music applications are providing, since i believe bmp's objective is to be a gtk2 port of xmms. I could be wrong.. someone with experience using both xmms and bmp should comment about how well bmp matches xmms functionality at this point. If however the goal is to general narrow the number of overlapping applications, thats a tougher discussion, and would have to compare and contrast the music applications in Core across a number of different technical measures...and will end like all of these sorts of discussions end... with a dance dance revolution dance-off between designated champions for each application. -jef"Core should be including pydance as a community oriented decision making tool"spaleta From dpaun at rogers.com Thu Jan 27 16:38:55 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Thu, 27 Jan 2005 11:38:55 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <604aa7910501270826672dcfb9@mail.gmail.com> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> Message-ID: <20050127163855.GB5263@rogers.com> On Thu, Jan 27, 2005 at 11:26:16AM -0500, Jeff Spaleta wrote: > I think one underlying goal is to get to a point where the underlying > gtk1 libraries are no longer needed in core and can be removed. Being > able to remove all of the application that are still using the older > gtk libs is a much bigger gain over all. I beg to differ. I think this is a rather technical argument with zero user benefit. Even a trivial loss in usability (which clearly is the case here) can not be justified with a bit of HDD space saved. xmms is a much better player then rhythmbox IMO, and I don't give a $PROFANITY that it depends on gtk1. Not ideal, I agree, but not having it around would be a major loss of functionality from my POV. -- Dimi. From katzj at redhat.com Thu Jan 27 16:42:21 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 27 Jan 2005 11:42:21 -0500 Subject: Fedora PPC things... In-Reply-To: <1106630968.5401.42.camel@localhost.localdomain> References: <1106630968.5401.42.camel@localhost.localdomain> Message-ID: <1106844141.17991.53.camel@bree.local.net> On Tue, 2005-01-25 at 13:29 +0800, Colin Charles wrote: > 4. power management - we need either pmud or pbbuttonsd. The latter has > received no love from most fedora/ppc users, so pmud seems to be the > winner, I'd guess. We need this included in Core (building only for ppc, > and possibly later ppc64). We know yellow dog add some nice patches for > disabling the touchpad in pmud - I guess the package maintainer can be > free to include such patches at will if need be ... at the same time, we need one set of scripts/configuration being used to control any of apmd, acpid and pmud. It's not that much harder to do that if someone's going to do the pmud work. Jeremy From overholt at redhat.com Thu Jan 27 16:51:39 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 27 Jan 2005 11:51:39 -0500 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <20050126144636.GA7010@redhat.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> Message-ID: <20050127165139.GA30730@redhat.com> * Andrew Overholt [2005-01-26 09:47]: > > I'm hoping to go back to a 3.1 milestone build before FC4. Looking at the schedules for Eclipse 3.1 [1] and FC4 [2], I see the following: Eclipse 3.1 M6 (stable build, API freeze): 2005-04-01 FC4 Absolute devel freeze: 2005-05-02 Eclipse 3.1 M7 (stable build, development freeze, etc.): 2005-05-13 FC4 Release open, announced: 2005-06-16 I'd like to ship a 3.1 M6 (or some stable incremental build between then and FC4 freeze) with FC4 and then update to M7 and 3.1 final as they come out. Choices: a) ship as above b) ship 3.0.x 3.1 Pros: - between now and then we get to spend lots of time testing and getting things pushed upstream - this is where all development is happening - awesome new plugins like Jeff Pound's ongoing work on the Bugzilla plug-in are dependent upon 3.1 (without a tonne of back-porting) - making RPMs will be much simpler than how we're doing the 3.0.1 now - upstream supports many more architectures than they did with 3.0.1 3.1 Cons: - lots of stuff that may not work with libgcj4/gij4 - a lot less tested than 3.0.x 3.0.x Pros: - well-tested, established, stable code - already have RPMs and know they build okay with gcj4 - will be the latest upstream _released_ version 3.0.x Cons: - old code where new features are not being added - will need back-porting if we want new things - build is a bit of a mess (especially for arches that were unsupported upstream) I'd like to go with 3.1, but we'll need to do lots of testing and bug-fixing. The number of gcj/libgcj hackers capable of fixing bugs isn't that high and even getting things down to test cases is not an easy task. I'd like to hear people's opinions. Thanks, Andrew [1] http://fedora.redhat.com/participate/schedule/ [2] http://eclipse.org/eclipse/development/eclipse_project_plan_3_1.html From jkeating at j2solutions.net Thu Jan 27 16:58:05 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 27 Jan 2005 08:58:05 -0800 Subject: Fedora PPC things... In-Reply-To: <1106815018.5598.111.camel@localhost.localdomain> References: <1106630968.5401.42.camel@localhost.localdomain> <1106813471.8367.73.camel@localhost.localdomain> <1106815018.5598.111.camel@localhost.localdomain> Message-ID: <1106845085.5405.289.camel@jkeating2.hq.pogolinux.com> On Thu, 2005-01-27 at 14:06 +0530, Colin Charles wrote: > > Battery Life somewhat sucks right now. Not sure if it's for > everybody > > or just me. > > Probably just you. Its always a little worse using Linux than compared > to OS X, but thats normal Sure, thats the way it was in 2.4, but seems under 2.6 I rapidly lose battery power, and once it hits 45% it suddenly jumps to 0% and shuts me down. I only get an hour or so from a full charge, unlike the 3 hours I got under 2.4 > > UI to configure mouse button emulation > > Err, the /etc/sysctl.conf entries you mean? I think we need to fix > anaconda to make the default the f10/f11 keys to work well Well, here's the thing. ibooks have an extra button that powerbooks don't (or vice versa), the eject button. Since keyboards are different, a default won't work very well. We need to expose a UI to select which button much like Gnomes keyboard shortcut selector (press button for this function, instead of trying to figure out what keycode a button sends). Speaking of Gnome shortcuts, all of a sudden the apple key can't be used as a meta-mod, so it can't be used in combinations such as -left and -right or other things such as that. I think this isn't just a ppc thing because the windows key in x86 can't be used in the same manner. This is a change from FC2 and it annoys the crap out of me as I have to re-learn a lot of keyboard shortcuts I had set up. Fixing this on PPC would have the echo effect of fixing it on x86 and that's not bad (: > > Any work to make video-out function would be VERY nice. I don't > like > > having to reboot to OS X in order to present on a projector. > > This is a bit of a hack in Linux/ppc so I don't think we should be > integrating it. Though its something we should work towards Even if we don't integrate it, having a how-to posted somewhere convenient would be nice. > > Some work or status report on Mac-on-Linux. Very handy for media > > formats ppc-linux doesn't yet handle, w/out having to reboot the > entire > > system. > > Well, there's qemu ;-) > > But yes, MOL in Extras/ppc might be nice (don't think we need it in > Core, but hey, its okay with me) Yes, totally an Extras/ppc thing. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From pmuldoon at redhat.com Thu Jan 27 16:59:10 2005 From: pmuldoon at redhat.com (Phil Muldoon) Date: Thu, 27 Jan 2005 10:59:10 -0600 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <20050127165139.GA30730@redhat.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> <20050127165139.GA30730@redhat.com> Message-ID: <1106845150.7126.2.camel@dhcp-12.hsv.redhat.com> > I'd like to ship a 3.1 M6 (or some stable incremental build between then > and FC4 freeze) with FC4 and then update to M7 and 3.1 final as they come > out. Me too. Because of ... > - awesome new plug-ins like Jeff Pound's ongoing work on the Bugzilla > plug-in are dependent upon 3.1 (without a tonne of back-porting) Thing like that, which would make the development life-cycle process in eclipse more complete .. and .. > - making RPMs will be much simpler than how we're doing the 3.0.1 now Organization of above. > I'd like to go with 3.1, but we'll need to do lots of testing and > bug-fixing. The number of gcj/libgcj hackers capable of fixing bugs isn't > that high and even getting things down to test cases is not an easy task. > I'd like to hear people's opinions. I'll help where I can. In porting the plug-ins (CDT, ChangeLog, RPM import/export, etc) I expect some cross experience to apply. Regards Phil From clumens at redhat.com Thu Jan 27 17:18:07 2005 From: clumens at redhat.com (Chris Lumens) Date: Thu, 27 Jan 2005 12:18:07 -0500 (EST) Subject: DBUS features In-Reply-To: <1106774544.10159.123.camel@localhost.localdomain> References: <1106760753.3449.1.camel@localhost.localdomain> <1106774544.10159.123.camel@localhost.localdomain> Message-ID: On Wed, 26 Jan 2005, Havoc Pennington wrote: > On Wed, 2005-01-26 at 10:32 -0700, Trever L. Adams wrote: >> >> What do you all think? Is this possible (I am fairly sure it is)? Is it >> a good thing... I think so? > > I think it's possible and good yes, the key thing though is to get it > coded up. > > For the first you need either a system daemon that monitors the > utmp/wtmp/lastlog/whatever-it-is or you need each user session to > register somehow with a dbus-specific thing I already have some code to do this by monitoring both the utmp/wtmp file for console logins and by looking through running processes for GDM sessions since (at least at the time and in this particular environment) GDM wasn't writing out *tmp entries. It was sort of hacked together code and would certainly need some reworking before being put into a finished product, but I do have some familiarity with the problem. Unfortunately it was for a school research project and I don't know what the ownership around it would be. I can investigate if needed. - Chris From Nicolas.Mailhot at laPoste.net Thu Jan 27 17:26:05 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Thu, 27 Jan 2005 18:26:05 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050127163855.GB5263@rogers.com> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> Message-ID: <1106846765.13433.10.camel@rousalka.dyndns.org> Le jeudi 27 janvier 2005 ? 11:38 -0500, Dimitrie O. Paun a ?crit : > On Thu, Jan 27, 2005 at 11:26:16AM -0500, Jeff Spaleta wrote: > > I think one underlying goal is to get to a point where the underlying > > gtk1 libraries are no longer needed in core and can be removed. Being > > able to remove all of the application that are still using the older > > gtk libs is a much bigger gain over all. > > I beg to differ. I think this is a rather technical argument with > zero user benefit. The non-latin support of gtk2 (vs gtk1) alone is a clear user benefit. So this is *very* far from an abstract argument with no tangible end- user incidence. And I could easily write a page about gtk1 shortcomings from an end-user POW without even getting into specific xmms problems (that deserve at least a page themselves). I appreciate some people are used to xmms and resigned themselves to its behaviour long ago. That doesn't make it a good app, nor does it mean that someone not exposed to another media player before would chose xmms over rythmbox (which has its own problems, but it's doubtful they are much worse than the problems of xmms and at least rythmbox is still in heavy development and not stagnating like xmms) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From notting at redhat.com Thu Jan 27 17:34:49 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 27 Jan 2005 12:34:49 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F9147B.1060604@yahoo.co.uk> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <1106824972.3239.32.camel@cobra.ivg2.net> <41F9147B.1060604@yahoo.co.uk> Message-ID: <20050127173449.GD2545@nostromo.devel.redhat.com> Dariusz J. Garbowski (thuforuk at yahoo.co.uk) said: > >It's a database-backed music player, and cannot be compared to xmms, > >which is totally different. > > Therefore is not an alternative nor replacement. It's rather different > application class that happens to play music. > > Someone mentioned playing a file from filesystem. This is waht I do -- > select files or directory from the filesystem and play it. I don't care > about database backend. You may be interested in totem as well. Bill From nbargnesi at gmail.com Thu Jan 27 17:48:21 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Thu, 27 Jan 2005 12:48:21 -0500 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <1106845150.7126.2.camel@dhcp-12.hsv.redhat.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> <20050127165139.GA30730@redhat.com> <1106845150.7126.2.camel@dhcp-12.hsv.redhat.com> Message-ID: <3077b8a00501270948de2e9ae@mail.gmail.com> On Thu, 27 Jan 2005 10:59:10 -0600, Phil Muldoon wrote: > > I'd like to ship a 3.1 M6 (or some stable incremental build between then > > and FC4 freeze) with FC4 and then update to M7 and 3.1 final as they come > > out. > > Me too. Because of ... > > > - awesome new plug-ins like Jeff Pound's ongoing work on the Bugzilla > > plug-in are dependent upon 3.1 (without a tonne of back-porting) > > Thing like that, which would make the development life-cycle process in > eclipse more complete .. and .. > > > - making RPMs will be much simpler than how we're doing the 3.0.1 now > > Organization of above. > > > I'd like to go with 3.1, but we'll need to do lots of testing and > > bug-fixing. The number of gcj/libgcj hackers capable of fixing bugs isn't > > that high and even getting things down to test cases is not an easy task. > > I'd like to hear people's opinions. > > I'll help where I can. In porting the plug-ins (CDT, ChangeLog, RPM > import/export, etc) I expect some cross experience to apply. > Love to help with testing. I use Eclipse 3.1M4 daily. > Regards > > Phil > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From overholt at redhat.com Thu Jan 27 17:53:14 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 27 Jan 2005 12:53:14 -0500 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <3077b8a00501270948de2e9ae@mail.gmail.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> <20050127165139.GA30730@redhat.com> <1106845150.7126.2.camel@dhcp-12.hsv.redhat.com> <3077b8a00501270948de2e9ae@mail.gmail.com> Message-ID: <20050127175314.GF30730@redhat.com> * Nick Bargnesi [2005-01-27 12:49]: > > Love to help with testing. I use Eclipse 3.1M4 daily. Awesome! I'll probably get some 3.1 RPMs in there early next week. Testing the 3.0.1 RPMs that are there now would also help. If you have rawhide in your yum sources somewhere (as in [1]), you should just have to: yum --enablerepo=development install eclipse-pde gcc4-java libgcj4-devel Bugs should be filed under Fedora -> devel -> eclipse. Thanks, Andrew [1] [development] name=rawhide baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ enabled=0 From ivg2 at cornell.edu Thu Jan 27 17:58:17 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 27 Jan 2005 10:58:17 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050127173449.GD2545@nostromo.devel.redhat.com> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <1106824972.3239.32.camel@cobra.ivg2.net> <41F9147B.1060604@yahoo.co.uk> <20050127173449.GD2545@nostromo.devel.redhat.com> Message-ID: <1106848698.28103.23.camel@cobra.ivg2.net> On Thu, 2005-01-27 at 12:34 -0500, Bill Nottingham wrote: > Dariusz J. Garbowski (thuforuk at yahoo.co.uk) said: > > >It's a database-backed music player, and cannot be compared to xmms, > > >which is totally different. > > > > Therefore is not an alternative nor replacement. It's rather different > > application class that happens to play music. > > > > Someone mentioned playing a file from filesystem. This is waht I do -- > > select files or directory from the filesystem and play it. I don't care > > about database backend. > > You may be interested in totem as well. Totem's a video player. Using it for music doesn't make sense, since it has a screen that doesn't accomplish anything, and you can't get rid of. -- Ivan Gyurdiev Cornell University From jspaleta at gmail.com Thu Jan 27 18:14:01 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 27 Jan 2005 13:14:01 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050127163855.GB5263@rogers.com> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> Message-ID: <604aa79105012710144dd061ee@mail.gmail.com> On Thu, 27 Jan 2005 11:38:55 -0500, Dimitrie O. Paun wrote: > I beg to differ. I think this is a rather technical argument with > zero user benefit. Even a trivial loss in usability (which clearly > is the case here) can not be justified with a bit of HDD space saved. Shrug.. if you want to look at everything from a very narrow user perspective.. fine... but that's not the only perspective that have to be considered as Core moves forward. There are rather technical arguments and technical goals that will influence decisions, ignoring this fact doesn't make it go away. Maintainability of the underlying codebase is certaintly something that must be considered as part of this fast moving and forward looking project. Its all about trade-offs, and if bmp has enough of xmms's functionality i think its worth be considering as a replacement xmms replacement IF working towards removing gtk1 from Core is a long term goal. > > xmms is a much better player then rhythmbox IMO, and I don't give > a $PROFANITY that it depends on gtk1. Not ideal, I agree, but not > having it around would be a major loss of functionality from my POV. This is why i suggested that someone who has used both xmms and bmp (aka beep) comment about bmp's suitability as a replacement. -jef"has anyone actually used bmp? I dont even use xmms anymore so I'm not in a position to compare"spaleta From toshio at tiki-lounge.com Thu Jan 27 17:49:12 2005 From: toshio at tiki-lounge.com (Toshio) Date: Thu, 27 Jan 2005 12:49:12 -0500 Subject: RFC: Soname in rpm name In-Reply-To: References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106576114.2365.5.camel@support02.civic.twp.ypsilanti.mi.us> <604aa791050124070243cfe95f@mail.gmail.com> <20050124220847.GD31520@neu.nirvana> <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com> Message-ID: <1106848153.22178.16.camel@Madison.badger.com> On Thu, 2005-01-27 at 16:02 +0100, Aurelien Bompard wrote: > Harald Hoyer wrote: > > Or you release a new release of that version which provides the garbage > > collector symbol, Axel suggested. > > I'd be very happy to do that, but I'd like to know : is this the scheme Red > Hat is going to be moving to ? Soname in the package name and a > Provides : shared-library-package > in the spec file ? Do we agree on this ? > > I also think it is a great solution, which adresses correctly all the major > issues raised here. I'd be very happy to see it become a packaging policy. > I missed Axel's original posting so I may well be missing something: I thought the discussion was moving towards how to have the user specify at install time that a package is okay to delete if nothing depends on it. Isn't a "Garbage collector symbol" via a Provides done by the packager at rpm creation time instead? If so, the user will still have to manually intervene with the list of garbage collections. (Although, it might not be as bad as some of the other schemes out there.) I'm also still waiting to see why the current de facto scheme of: current = libname previous = libname[Version] is _compellingly_ wrong... Perhaps there just needs to be a summary of Pros and Cons so we can see the tradeoffs. -Toshio -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thuforuk at yahoo.co.uk Thu Jan 27 18:41:09 2005 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Thu, 27 Jan 2005 18:41:09 +0000 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050127173449.GD2545@nostromo.devel.redhat.com> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <1106824972.3239.32.camel@cobra.ivg2.net> <41F9147B.1060604@yahoo.co.uk> <20050127173449.GD2545@nostromo.devel.redhat.com> Message-ID: <41F935C5.7040102@yahoo.co.uk> On 01/27/2005 05:34 PM, Bill Nottingham wrote: > Dariusz J. Garbowski (thuforuk at yahoo.co.uk) said: > >>>It's a database-backed music player, and cannot be compared to xmms, >>>which is totally different. >> >>Therefore is not an alternative nor replacement. It's rather different >>application class that happens to play music. >> >>Someone mentioned playing a file from filesystem. This is waht I do -- >>select files or directory from the filesystem and play it. I don't care >>about database backend. > > > You may be interested in totem as well. Just tried it again (couldn't use it in any meaningful way on FC2 due to a nasty bug in XOrg 6.7.x that was fixed in 6.8.x). I'm sorry to report that it crashes on my system (up-to-date FC3 + some additional packages from dag's and other repos) when I select no longer existing "recently used" file: error dialog pops up, CPU usage tops 100% and on totem window close I get bug buddy (which I just used to report this problem). One more try, this time avoiding "recently used". Selected open file, and in my foolishness chosen bunch of mp3s. Totem went completely berserk! For some reason it started opening endless number of error dialogs reporting that it doesn't know what to do with those files and before I relised it managed to render my desktop into oblivion. I couldn't select any of the open xterms because new dialogs kept grabbing focus, Alt+F4 to close the dialogs was futile. What saved me from hard reboot was logging from my laptop via ssh and kill -9 the evil app. There must have been dozens if not hundreds of those dialogs because it's taken 45 seconds before the last one vanished from my desktop. - Why does totem keep opening so many dialogs? - Can it be configured to simply ignore (skip) unknown files without displaying error dialog? (like xmms does) - Why does it try to open last successfully (?) used file on startup? The effect is that when I removed that file totem welcomes me with error dialog stating that it could play that file. I am afraid that with this kind of bugs it's hardly usable :( I also agree with Ivan that it feels more like a movie player than generic multimedia player. I think we may need to look closer at beepmp if we really think of replacing xmms. I can't comment much on it since I used it only for a few hours so far. It feels quite like xmms to me. First missing thing I noticed is no double size feature. I'd like to hear what other users of xmms think about beepmp. Is it ready to replace xmms? Regards, Dariusz From kyrre at solution-forge.net Thu Jan 27 18:46:55 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 27 Jan 2005 19:46:55 +0100 Subject: fedora stable branch updates Q&A policy Message-ID: <1106851614.2656.7.camel@localhost.localdomain> What is this policy today? Who does the testing before an update is released for large numbers of users to install via yum? I am wondering, not because there are very many bad updates (99% of them are OK), but i simply wonder - who does this? And who does this for extras? Personally, i would believe a q&a mailinglist and a "testing" repo for yum could be a good idea, in order to get packages as good tested as possible - as fast as possible. Kyrre From thuforuk at yahoo.co.uk Thu Jan 27 18:57:42 2005 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Thu, 27 Jan 2005 18:57:42 +0000 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F935C5.7040102@yahoo.co.uk> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <1106824972.3239.32.camel@cobra.ivg2.net> <41F9147B.1060604@yahoo.co.uk> <20050127173449.GD2545@nostromo.devel.redhat.com> <41F935C5.7040102@yahoo.co.uk> Message-ID: <41F939A6.2050408@yahoo.co.uk> On 01/27/2005 06:41 PM, Dariusz J. Garbowski wrote: > On 01/27/2005 05:34 PM, Bill Nottingham wrote: > >> Dariusz J. Garbowski (thuforuk at yahoo.co.uk) said: >> > - Why does it try to open last successfully (?) used file on startup? > The effect is that when I removed that file totem welcomes me with error > dialog stating that it could play that file. ^^^^^^^^^^ Correction: could *not* play Dariusz From peter.backlund at home.se Thu Jan 27 19:13:44 2005 From: peter.backlund at home.se (Peter Backlund) Date: Thu, 27 Jan 2005 20:13:44 +0100 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <20050127175314.GF30730@redhat.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> <20050127165139.GA30730@redhat.com> <1106845150.7126.2.camel@dhcp-12.hsv.redhat.com> <3077b8a00501270948de2e9ae@mail.gmail.com> <20050127175314.GF30730@redhat.com> Message-ID: <1106853224.19595.76.camel@localhost.localdomain> tor 2005-01-27 klockan 12:53 -0500 skrev Andrew Overholt: > * Nick Bargnesi [2005-01-27 12:49]: > > > > Love to help with testing. I use Eclipse 3.1M4 daily. > > Awesome! I'll probably get some 3.1 RPMs in there early next week. > Testing the 3.0.1 RPMs that are there now would also help. I installed 3.1M4 from rawhide when it was in there. It launched, but performance was so-so and stability less than perfect. It's now been replced with 3.0.1_fc-8, which does not start anymore. This is printed on stdout: -bash-3.00$ eclipse libgcj failure: Duplicate class registration: java.awt.image.RenderedImage Warning: -Xms64M not understood. Ignoring. Warning: -Xmx256M not understood. Ignoring. libgcj failure: Duplicate class registration: java.awt.image.RenderedImage and after ~5-10 seconds of using 100% cpu, a window pops up with the following error: JVM terminated. Exit code=1 /usr/bin/java -Xms64M -Xmx256M -Dorg.eclipse.core.runtime.ignoreLockFile=true -Dgnu.gcj.runtime.VMClassLoader.library_control=never -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db -cp /usr/share/eclipse/startup.jar org.eclipse.core.launcher.Main -os linux -ws gtk -arch x86 -showsplash /usr/share/eclipse/eclipse -showsplash 600 -exitdata /usr/share/eclipse/eclipse -exitdata 2130026 -data /home/builder/workspace -vm /usr/bin/java -vmargs -Xms64M -Xmx256M -Dorg.eclipse.core.runtime.ignoreLockFile=true -Dgnu.gcj.runtime.VMClassLoader.library_control=never -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db -cp /usr/share/eclipse/startup.jar org.eclipse.core.launcher.Main Here's what's installed: -bash-3.00$ rpm -qa | grep "gcj4\|eclipse" eclipse-ecj-3.0.1_fc-8 eclipse-platform-3.0.1_fc-8 eclipse-jdt-3.0.1_fc-8 eclipse-source-3.0.1_fc-8 libgcj4-4.0.0-0.21 eclipse-gtk2-3.0.1_fc-8 eclipse-pde-3.0.1_fc-8 libgcj4-devel-4.0.0-0.21 /Peter From overholt at redhat.com Thu Jan 27 19:13:31 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 27 Jan 2005 14:13:31 -0500 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <1106853224.19595.76.camel@localhost.localdomain> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> <20050127165139.GA30730@redhat.com> <1106845150.7126.2.camel@dhcp-12.hsv.redhat.com> <3077b8a00501270948de2e9ae@mail.gmail.com> <20050127175314.GF30730@redhat.com> <1106853224.19595.76.camel@localhost.localdomain> Message-ID: <20050127191331.GA4325@redhat.com> Hi, * Peter Backlund [2005-01-27 14:11]: > > libgcj failure: Duplicate class registration: > java.awt.image.RenderedImage You'll need to make sure your java and javac alternatives are set to java-1.4.2-gcj4-compat{,-devel}. > -bash-3.00$ rpm -qa | grep "gcj4\|eclipse" > eclipse-ecj-3.0.1_fc-8 > eclipse-platform-3.0.1_fc-8 > eclipse-jdt-3.0.1_fc-8 > eclipse-source-3.0.1_fc-8 > libgcj4-4.0.0-0.21 > eclipse-gtk2-3.0.1_fc-8 > eclipse-pde-3.0.1_fc-8 > libgcj4-devel-4.0.0-0.21 Install the -0.22 gcc4 RPMs and the -9 eclipse RPMs. Andrew From terraformers at gmx.net Thu Jan 27 19:18:19 2005 From: terraformers at gmx.net (Lars) Date: Thu, 27 Jan 2005 20:18:19 +0100 Subject: rawhide report: 20050127 changes References: <200501271355.j0RDtB431195@porkchop.devel.redhat.com> Message-ID: Build System wrote: > hmm... there are lots of updates in rawhide for today and the buildsystem says there are none? L From mbneto at gmail.com Thu Jan 27 19:21:10 2005 From: mbneto at gmail.com (mbneto) Date: Thu, 27 Jan 2005 15:21:10 -0400 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <20050127175314.GF30730@redhat.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> <20050127165139.GA30730@redhat.com> <1106845150.7126.2.camel@dhcp-12.hsv.redhat.com> <3077b8a00501270948de2e9ae@mail.gmail.com> <20050127175314.GF30730@redhat.com> Message-ID: <5cf776b805012711217d9e4372@mail.gmail.com> Well, If you need feedback... My 3.0.1-9 is not working (3.1 was despite the fact the CVS access was not). !SESSION Jan 27, 2005 14:53:32.46 ---------------------------------------------- eclipse.buildId=200409161125 java.version=1.4.2_06 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=pt_BR !ENTRY org.eclipse.osgi Jan 27, 2005 14:53:32.48 !MESSAGE Application error !STACK 1 java.lang.UnsatisfiedLinkError: /usr/lib/eclipse/libswt-pi-gtk-3116.so: /usr/lib/eclipse/libswt-pi-gtk-3116.so: undefined symbol: XTestFakeButtonEvent at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.loadLibrary0(Unknown Source) at java.lang.System.loadLibrary(Unknown Source) at org.eclipse.swt.internal.Library.loadLibrary(Library.java:100) at org.eclipse.swt.internal.gtk.OS.(OS.java:19) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63) at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54) at org.eclipse.swt.widgets.Display.(Display.java:121) at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:268) at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:153) at org.eclipse.ui.internal.ide.IDEApplication.createDisplay(IDEApplication.java:122) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:72) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:335) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:273) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.core.launcher.Main.basicRun(Main.java:185) at org.eclipse.core.launcher.Main.run(Main.java:704) at org.eclipse.core.launcher.Main.main(Main.java:688) !ENTRY org.eclipse.osgi Jan 27, 2005 14:53:32.60 !MESSAGE Bundle update@/usr/share/eclipse/plugins/org.eclipse.swt.gtk_3.0.1/ [43] was not resolved. !SUBENTRY 1 org.eclipse.osgi Jan 27, 2005 14:53:32.60 !MESSAGE Bundle update@/usr/share/eclipse/plugins/org.eclipse.swt.gtk_3.1.0/ was picked instead. !ENTRY org.eclipse.osgi Jan 27, 2005 14:53:32.62 !MESSAGE Bundle update@/usr/share/eclipse/plugins/org.eclipse.platform.source.linux.gtk.x86_3.0.1/ [75] was not resolved. !SUBENTRY 1 org.eclipse.osgi Jan 27, 2005 14:53:32.62 !MESSAGE Missing host org.eclipse.platform.source_[3.0.1,4.0.0). On Thu, 27 Jan 2005 12:53:14 -0500, Andrew Overholt wrote: > * Nick Bargnesi [2005-01-27 12:49]: > > > > Love to help with testing. I use Eclipse 3.1M4 daily. > > Awesome! I'll probably get some 3.1 RPMs in there early next week. > Testing the 3.0.1 RPMs that are there now would also help. > > If you have rawhide in your yum sources somewhere (as in [1]), you should > just have to: > > yum --enablerepo=development install eclipse-pde gcc4-java libgcj4-devel > > Bugs should be filed under Fedora -> devel -> eclipse. > > Thanks, > > Andrew > > [1] > > [development] > name=rawhide > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ > enabled=0 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From david at fubar.dk Thu Jan 27 19:23:23 2005 From: david at fubar.dk (David Zeuthen) Date: Thu, 27 Jan 2005 14:23:23 -0500 Subject: Fedora PPC things... In-Reply-To: <1106844141.17991.53.camel@bree.local.net> References: <1106630968.5401.42.camel@localhost.localdomain> <1106844141.17991.53.camel@bree.local.net> Message-ID: <1106853803.3842.38.camel@daxter.boston.redhat.com> On Thu, 2005-01-27 at 11:42 -0500, Jeremy Katz wrote: > ... at the same time, we need one set of scripts/configuration being > used to control any of apmd, acpid and pmud. It's not that much harder > to do that if someone's going to do the pmud work. > Actually someone is working on putting this into hal - not yet known if it happens in the FC4 timeframe. David From dpaun at rogers.com Thu Jan 27 19:21:08 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Thu, 27 Jan 2005 14:21:08 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106846765.13433.10.camel@rousalka.dyndns.org> References: <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <1106846765.13433.10.camel@rousalka.dyndns.org> Message-ID: <20050127192108.GC5263@rogers.com> On Thu, Jan 27, 2005 at 06:26:05PM +0100, Nicolas Mailhot wrote: > The non-latin support of gtk2 (vs gtk1) alone is a clear user benefit. > So this is *very* far from an abstract argument with no tangible end- > user incidence. I don't dispute that. But this is all tangential to the main purpose of the freaking thing: to play music. You can get me the best non-latin support, perfect HIG compliance, etc. but it it doesn't do a good job playing music, it can't replace xmms. And by now it's painfully obvious that rhythmbox is not, by any measure, an acceptable alternative. It works for some, but it's far from working for all. As such, it's just a bad idea to remove xmms at this point. So what are we debating here? -- Dimi. From kyrre at solution-forge.net Thu Jan 27 19:23:39 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 27 Jan 2005 20:23:39 +0100 Subject: Help correct Fedora s390 running under VM In-Reply-To: <007701c503ba$e84566f0$580310ac@rusautogaz.ru> References: <007701c503ba$e84566f0$580310ac@rusautogaz.ru> Message-ID: <1106853818.2656.15.camel@localhost.localdomain> ons, 26.01.2005 kl. 16.15 skrev Sysadmin cokzl: > I am run (Fedora Core release Rawhide (Rawhide)Kernel 2.6.10-1.1103_FC4 on > an s390) > from vm/esa on s390, and i am see on console: > > **************************************************************************** > *********** > Booting default (linux)... > Linux version 2.6.10-1.1103_FC4 (bhcompile at spade.z900.redhat.com) (gcc > version > .4.3 20050113 (Red Hat 3.4.3-15)) #1 SMP Wed Jan 19 20:40:50 EST 2005 > We are running under VM (31 bit mode) > This machine has no IEEE fpu > Built 1 zonelists > Kernel command line: root=LABEL=/1 BOOT_IMAGE=0 > PID hash table entries: 1024 (order: 10, 16384 bytes) > Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) > Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) > Memory: 124544k/131072k available (1874k kernel code, 0k reserved, 605k > data, 1 > 8k init) > Security Framework v1.0.0 initialized > SELinux: Initializing. > SELinux: Starting in permissive mode > selinux_register_security: Registering secondary module capability > Capability LSM initialized as secondary > Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > Detected 1 CPU's > Boot cpu address 0 > cpu 0 phys_idx=0 vers=FF ident=100003 machine=9672 unused=0000 > Brought up 1 CPUs > checking if image is initramfs... it is > Freeing initrd memory: 899k freed > debug: Initialization complete > NET: Registered protocol family 16 > **************************************************************************** > *************** > and here cycling > i am do command vm/esa: > trace all > and i see: > TRACE ALL > HCPTRI1027I An active trace set has turned RUN off. > B > -> 001D196E' SLR 1F33 CC 2 > B > 001D1970' CS BA342000 002E8454 CC 1 > B > 001D1974' ???? A744FFFB 0057AD33 CC 1 > B > -> 001D196A' DIAG 83000044 00000044 CC 1 > B > 001D196E' SLR 1F33 CC 2 > B > 001D1970' CS BA342000 002E8454 CC 1 > B > 001D1974' ???? A744FFFB 0057AD33 CC 1 > B > -> 001D196A' DIAG 83000044 00000044 CC 1 > B > 001D196E' SLR 1F33 CC 2 > B > 001D1970' CS BA342000 002E8454 CC 1 > B > 001D1974' ???? A744FFFB 0057AD33 CC 1 > B > -> 001D196A' DIAG 83000044 00000044 CC 1 > B > 001D196E' SLR 1F33 CC 2 > B > 001D1970' CS BA342000 002E8454 CC 1 > B > 001D1974' ???? A744FFFB 0057AD33 CC 1 > > i am do command vm/esa: > STORE 001D1974 A7440002: > and i see: > CP ST 001D1974 A7440002 > Store complete. > > cio: Was not able to determine available CHSCs, cc=2. > chsc_get_sch_descriptions: Error -22 while doing chsc; processing some > machine c > hecks may not work > appldata info: mem-ops registered] > appldata info: os-ops registered] > appldata info: net_sum-ops registered] > audit: initializing netlink socket (disabled) > audit(1106763062.926:0): initialized > VFS: Disk quotas dquot_6.5.1 > Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) > SELinux: Registering netfilter hooks > Initializing Cryptographic API > ksign: Installing public key data > Loading keyring > - Added public key A151D8E9D3A0BB > - User ID: Red Hat, Inc. (Kernel Module GPG key) > io scheduler noop registered > io scheduler anticipatory registered > io scheduler deadline registered > io scheduler cfq registered > RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize > md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27 > Channel measurement facility using basic format (autodetected) > cpi: no system name specified > NET: Registered protocol family 2 > IP: routing cache hash table of 1024 buckets, 8Kbytes > TCP established hash table entries: 8192 (order: 5, 131072 bytes) > TCP bind hash table entries: 8192 (order: 4, 65536 bytes) > TCP: Hash tables configured (established 8192 bind 8192) > Initializing IPsec netlink socket > NET: Registered protocol family 1 > NET: Registered protocol family 17 > Freeing unused kernel memory: 108k freed > Red Hat nash version 4.2.0.1 starting > Mounted /proc filesystem ........................................ > and so on > > and i see: > Fedora Core release Rawhide (Rawhide) > Kernel 2.6.10-1.1103_FC4 on an s390 > > cokzlb login: > HELP correct; improve; reform; repair BUG I don't know the first thing about such irons - but when it says cokzlb login: - can't you just login as root, add some users and get started? From bdpepple at ameritech.net Thu Jan 27 19:29:44 2005 From: bdpepple at ameritech.net (Brian Pepple) Date: Thu, 27 Jan 2005 14:29:44 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050127192108.GC5263@rogers.com> References: <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <1106846765.13433.10.camel@rousalka.dyndns.org> <20050127192108.GC5263@rogers.com> Message-ID: <1106854184.21328.1.camel@shuttle.273piedmont.org> On Thu, 2005-01-27 at 14:21 -0500, Dimitrie O. Paun wrote: > As such, it's just a bad idea to remove xmms at this point. > So what are we debating here? Wasn't the discussion about moving xmms to Fedora Extras, and out of Fedora Core? How does this stop you from being able to install xmms? /B -- Brian Pepple -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Thu Jan 27 19:46:01 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 27 Jan 2005 14:46:01 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <1106848153.22178.16.camel@Madison.badger.com> References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com> <1106848153.22178.16.camel@Madison.badger.com> Message-ID: <604aa7910501271146533837ad@mail.gmail.com> On Thu, 27 Jan 2005 12:49:12 -0500, Toshio wrote: > I'm also still waiting to see why the current de facto scheme of: > current = libname > previous = libname[Version] > > is _compellingly_ wrong... Perhaps there just needs to be a summary of > Pros and Cons so we can see the tradeoffs. If i understand the argument that people are making... is that doing it this way... is a burden on 3rd party packagers who have to try to predict when and if Core is going to introduce a libname[Version] for previous versions. And by association also a burden on users who are trying to use applications from outside of current Core that still need the older libs for applications until a 3rd party is able to rebuild a package with the older libs or the application developers retool to support the new library. My counter argument is that doing it this way historically has provided a mechanism by which Core(and rhl before it) explicitly and delibrately chooses to expire older libraries that Core is no longer maintaining and is no longer needed by anything inside Core. Another argument which has been made for continuing in this fashion is that standardizing on using sonames in all library packages potentially lowers the bar to backward-compatibility cruft. Such libraries would linger in an unknown maintainership state and be difficult to drop at any point because there will always be users who are using legacy application that needs that legacy library. -jef From kyrre at solution-forge.net Thu Jan 27 20:07:45 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Thu, 27 Jan 2005 21:07:45 +0100 Subject: duplicating a disk In-Reply-To: <7f48492a0501262056464a319f@mail.gmail.com> References: <20050124160120.2f20c1c8.fedora@wir-sind-cool.org> <1106579417.2365.15.camel@support02.civic.twp.ypsilanti.mi.us> <200501261104.48148.cfk@pacbell.net> <1106770749.23956.4.camel@rousalka.dyndns.org> <1106779214.2729.8.camel@localhost.localdomain> <7f48492a0501262056464a319f@mail.gmail.com> Message-ID: <1106856464.2656.18.camel@localhost.localdomain> tor, 27.01.2005 kl. 05.56 skrev Christopher Hotchkiss: > On Wed, 26 Jan 2005 23:40:15 +0100, Kyrre Ness Sjobak > wrote: > > ons, 26.01.2005 kl. 21.19 skrev Nicolas Mailhot: > > > Le mercredi 26 janvier 2005 ? 11:04 -0800, cfk a ?crit : > > > > Gentlemen: > > > > > > > > I have a situation where I need to make a number of identical computers all > > > > with the same fedoraCore2. > > > > > > > > I have tried putting a second (hdb) disk, doing a "df" on hda and based on > > > > the number of 1024 blocks going: > > > > > > > > dd if=/dev/hda of=/dev/hdb bs=1024 count= > > > > > > > > and it blinks the light a long time and then croaks. > > > > > > > > I know I did something similar to this a couple of years ago on a different > > > > project. Can someone tell me where I am going awry and perhaps educate me a > > > > little bit more. > > > > > > If you can setup an nfs or ftp/http server somewhere the fastest method > > > is network install via kickstart (using pxe if you can) > > > > > > It might take a little longer to setup but you'll make up the time very > > > fast. And if you do not have exactly the same hardware (same components > > > & firmware versions) it's way safer. > > > > or you could do the setup you said, just use dd to copy te stuff over. > > Just boot it off a cdrom. > > > Don't use dd for this. If you have different size hard drive, > partition or something else down the line, it can really mess you up. > I would recommend a simple tar or rsync command to copy them over. > > This is if you wish to do copy machine to machine. Otherwise a custom > kickstart file with pxe is a lot easier if done right. He said they was identical. Anyway, as long as it is properly copied to disk, shouln't kudzu handle any hardware diffs and reconfigure when the disk is booted? From gauret at free.fr Thu Jan 27 20:52:18 2005 From: gauret at free.fr (Aurelien Bompard) Date: Thu, 27 Jan 2005 21:52:18 +0100 Subject: RFC: Soname in rpm name References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com> <1106848153.22178.16.camel@Madison.badger.com> <604aa7910501271146533837ad@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > If i understand the argument that people are making... is that doing > it this way... is a burden on 3rd party packagers who have to try to > predict when and if Core is going to introduce a libname[Version] for > previous versions. I also find it much easier for new contributors to Extra to have a clear policy about this. Since more and more people are going to be contributing to Fedora, I think that we have to agree on policies. > Another argument which has been made for continuing in this fashion is > that??standardizing?on?using?sonames?in?all?library?packages > potentially lowers the bar to backward-compatibility cruft. Such > libraries would linger in an unknown maintainership state and be > difficult to drop at any point because there will always be users who > are using legacy application that needs that legacy library. Very true, and that's what Axel's proposal to introduce a virtual Provides is trying to solve. With it, a simple "rpm --whatprovides shared-library-package" returns all the library packages. Now we need a way to actually expire the old libraries. Proposals have been made in this direction to flag what the user has directly asked for and what was brought in as a dependency. In which case the library could be garbage-collected (if nothing depends on it anymore). This would be great, but I don't know how much work it would require to implement it in rpmlib (and in wrappers maybe ? maybe not needed) Another solution would be to select those of which nothing depend and to ask the user if it has to be removed. This would be much easier to implement of course. Does this sum it up correctly ? I think that both solutions are not mutually exclusive. We could start the slow move to add virtual provides in the shared libs, and sonames in the rpm name, and write the second script. We would have something useable before rpmlib gets the "garbage-collect" feature. Did I miss some points ? Thanks Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info For external use only From nbargnesi at gmail.com Thu Jan 27 21:55:00 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Thu, 27 Jan 2005 16:55:00 -0500 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <20050127175314.GF30730@redhat.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> <20050127165139.GA30730@redhat.com> <1106845150.7126.2.camel@dhcp-12.hsv.redhat.com> <3077b8a00501270948de2e9ae@mail.gmail.com> <20050127175314.GF30730@redhat.com> Message-ID: <3077b8a0050127135548db6d5a@mail.gmail.com> On Thu, 27 Jan 2005 12:53:14 -0500, Andrew Overholt wrote: > * Nick Bargnesi [2005-01-27 12:49]: > > > > Love to help with testing. I use Eclipse 3.1M4 daily. > > Awesome! I'll probably get some 3.1 RPMs in there early next week. > Testing the 3.0.1 RPMs that are there now would also help. Tried the 3.0.1fc9 RPMs, resulted in: libgcj failure: Duplicate class registration: java.awt.image.RenderedImage Warning: -Xms64M not understood. Ignoring. Warning: -Xmx256M not understood. Ignoring. libgcj failure: Duplicate class registration: java.awt.image.RenderedImage JVM terminated. Exit code=1 /usr/bin/java -Xms64M -Xmx256M -Dorg.eclipse.core.runtime.ignoreLockFile=true -Dgnu.gcj.runtime.VMClassLoader.library_control=never -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db -cp /usr/share/eclipse/startup.jar org.eclipse.core.launcher.Main -os linux -ws gtk -arch x86 -showsplash /usr/share/eclipse/eclipse -showsplash 600 -exitdata /usr/share/eclipse/eclipse -exitdata 308005 -data /root/workspace -vm /usr/bin/java -vmargs -Xms64M -Xmx256M -Dorg.eclipse.core.runtime.ignoreLockFile=true -Dgnu.gcj.runtime.VMClassLoader.library_control=never -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db -cp /usr/share/eclipse/startup.jar org.eclipse.core.launcher.Main This was executing the /usr/bin/eclipse shell script the eclipse-platform rpm installed. Looking at the script, the reason for the crash was the vm switch, i.e., ECLIPSE_OPTS="$ECLIPSE_OPTS -vm /usr/bin/java" Unfortunately, that's no good because using the gcj vm is the point correct? I wouldn't know where to look for issues with the gcj vm. > > If you have rawhide in your yum sources somewhere (as in [1]), you should > just have to: > > yum --enablerepo=development install eclipse-pde gcc4-java libgcj4-devel > > Bugs should be filed under Fedora -> devel -> eclipse. > > Thanks, > > Andrew > > [1] > > [development] > name=rawhide > baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearch/ > enabled=0 > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From overholt at redhat.com Thu Jan 27 22:09:50 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 27 Jan 2005 17:09:50 -0500 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <5cf776b805012711217d9e4372@mail.gmail.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> <20050127165139.GA30730@redhat.com> <1106845150.7126.2.camel@dhcp-12.hsv.redhat.com> <3077b8a00501270948de2e9ae@mail.gmail.com> <20050127175314.GF30730@redhat.com> <5cf776b805012711217d9e4372@mail.gmail.com> Message-ID: <20050127220950.GA7867@redhat.com> * mbneto [2005-01-27 14:22]: > > /usr/lib/eclipse/libswt-pi-gtk-3116.so: undefined symbol: > XTestFakeButtonEvent I can't duplicate this. I guess I should make sure to point out that we're compiling these with gcj4 so your java and javac alternatives have to be set to java-1.4.2-gcj4-compat. You do this like this: su - -c "update-alternatives --set java \ /usr/lib/jvm/jre-1.4.2-gcj4/bin/java" su - -c "update-alternatives --set javac \ /usr/lib/jvm/java-1.4.2-gcj4/bin/javac" If you're still having problems after doing this, please file a bug. Thanks, Andrew From jspaleta at gmail.com Thu Jan 27 22:43:40 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 27 Jan 2005 17:43:40 -0500 Subject: RFC: Soname in rpm name In-Reply-To: References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com> <1106848153.22178.16.camel@Madison.badger.com> <604aa7910501271146533837ad@mail.gmail.com> Message-ID: <604aa79105012714437df84250@mail.gmail.com> On Thu, 27 Jan 2005 21:52:18 +0100, Aurelien Bompard wrote: > > Another argument which has been made for continuing in this fashion is > > that standardizing on using sonames in all library packages > > potentially lowers the bar to backward-compatibility cruft. Such > > libraries would linger in an unknown maintainership state and be > > difficult to drop at any point because there will always be users who > > are using legacy application that needs that legacy library. > > Very true, and that's what Axel's proposal to introduce a virtual Provides > is trying to solve. With it, a simple "rpm --whatprovides > shared-library-package" returns all the library packages. I dont think the shared-library-package provides solves the cruft problem from the project perspective. From the user perpective yes the provides hack will be a somewhat useful mechanism for users/admins to cull cruft from their boxes. But i don't think thats what Ville had in mind when making the argument. I think Ville was talking about how the project as a whole prevents itself from accumulating layers and layers of library cruft that become harder and harder to maintain as time goes by because there is less and less upstream interest in maintaining the aging codebase. Its easy to package up an old library and offer it.. it gets harder and harder to 'maintain' such a package with critical and security related patches if the upstream development interest has dried out. I think Ville's arguement is aimed at making sure that whatever policy Core is using doesn't encourage the accumulation of difficult to maintain legacy libraries for which users are expecting to be able to be maintained at a high standard. > > Now we need a way to actually expire the old libraries. Proposals have been > made in this direction to flag what the user has directly asked for and > what was brought in as a dependency. In which case the library could be > garbage-collected (if nothing depends on it anymore). > This would be great, but I don't know how much work it would require to > implement it in rpmlib (and in wrappers maybe ? maybe not needed) Again these solutions have focused on the user's perspective of how to garbage collect unused libraries. That is not the crux of my concern. I've been trying to talk about a mechanism by which the package authors can expire a library.. thus notifying ALL users of that particular package that the author is no longer going to be providing any maintence for that library. And when the package authors have decided to expire the library.. the secure thing to do is to remove that library from the system regardless of what applications are still using it, until a new package author can be found for that library who is willing to 'maintain' the library. This is what effectively happens when core drops libfoo.so.1 from package libfoo and adds libfoo.so.2 instead. When the installer is used to upgrade to the new Core, any package that depends on that old libfoo.so.1 library breaks or gets removed. Sucks for the user that doesn't care about running vulnerable code.... sucks marginally less for a user who wants to make sure they aren't going to be opening themselves up to a future vulnerability that won't get patched with an update. The garbage collecting ideas address a different problem altogether than the 'expiration' issue i see the current core naming scheme being implicitly used for in some situations. Every if you garbage collected.. you still don't have a clue about whether the original author is going to be issuing updates anymore for a libfoo1 package that you are still using for a number of applications in the soname in packagename scheme. Keeping the libfoo package name across soname versions implicitly defines an enforced expiration policy by the package author. -jef From nbargnesi at gmail.com Thu Jan 27 22:49:42 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Thu, 27 Jan 2005 17:49:42 -0500 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <20050127221953.GB7867@redhat.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> <20050127165139.GA30730@redhat.com> <1106845150.7126.2.camel@dhcp-12.hsv.redhat.com> <3077b8a00501270948de2e9ae@mail.gmail.com> <20050127175314.GF30730@redhat.com> <3077b8a00501271352c17d7e9@mail.gmail.com> <20050127221953.GB7867@redhat.com> Message-ID: <3077b8a005012714492abd2fb1@mail.gmail.com> On Thu, 27 Jan 2005 17:19:53 -0500, Andrew Overholt wrote: > * Nick Bargnesi [2005-01-27 16:55]: > > > > Tried the 3.0.1fc9 RPMs, resulted in: > > > > libgcj failure: Duplicate class registration: java.awt.image.RenderedImage > > This is because we've compiled and linked Eclipse with libgcj4's .so but > you're running with gij from the 3.4.x package (which is linked against > libgcj 3.4.x's .so). You just need to set your alternatives to point to > java-1.4.2-gcj4-compat and -devel. See blow: > Even after setting the alternative java and javac, I still see the RenderedImage gcj failure. > > ECLIPSE_OPTS="$ECLIPSE_OPTS -vm /usr/bin/java" > > > > Unfortunately, that's no good because using the gcj vm is the point > > correct? > > Actually, I set it to point to /usr/bin/java so that you can run it with a > proprietary JVM if you want. Are you familiar with the alternatives system > at all? Install java-1.4.2-gcj4-compat (and -devel), and you'll have a > setup similar to a traditional JVM (like any JPackage-style RPM, that is) > with /usr/bin/java, /usr/bin/javac, etc. but built around gcj/gij and ecj > (the Eclipse java compiler). Thus, when running Eclipse we want it to run > with gij. Make sure you set your alternative to java-gcj4-compat and > you'll be set: > > su - -c "update-alternatives --set java \ > /usr/lib/jvm/jre-1.4.2-gcj4/bin/java" > su - -c "update-alternatives --set javac \ > /usr/lib/jvm/java-1.4.2-gcj4/bin/javac" > > > I wouldn't know where to look for issues with the gcj vm. > > Reporting bugs that occur with gcj and do not occur with a proprietary JVM > (or at least you don't expect them to) helps even if you don't know where > in libgcj/gcj/gij the problem is occurring. > > Thanks, > > Andrew > Now using the compat jvm, I've walked in a circle. JVM terminated. Exit code=1 /usr/bin/java -Xms64M -Xmx256M -Dorg.eclipse.core.runtime.ignoreLockFile=true -Dgnu.gcj.runtime.VMClassLoader.library_control=never -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db -cp /usr/share/eclipse/startup.jar org.eclipse.core.launcher.Main -os linux -ws gtk -arch x86 -showsplash /usr/share/eclipse/eclipse -showsplash 600 -exitdata /usr/share/eclipse/eclipse -exitdata 5a800b -data /root/workspace -vm /usr/bin/java -vmargs -Xms64M -Xmx256M -Dorg.eclipse.core.runtime.ignoreLockFile=true -Dgnu.gcj.runtime.VMClassLoader.library_control=never -Dgnu.gcj.precompiled.db.path=/usr/lib/eclipse/eclipse.db -cp /usr/share/eclipse/startup.jar org.eclipse.core.launcher.Main -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From overholt at redhat.com Thu Jan 27 23:05:19 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 27 Jan 2005 18:05:19 -0500 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <3077b8a005012714492abd2fb1@mail.gmail.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> <20050127165139.GA30730@redhat.com> <1106845150.7126.2.camel@dhcp-12.hsv.redhat.com> <3077b8a00501270948de2e9ae@mail.gmail.com> <20050127175314.GF30730@redhat.com> <3077b8a00501271352c17d7e9@mail.gmail.com> <20050127221953.GB7867@redhat.com> <3077b8a005012714492abd2fb1@mail.gmail.com> Message-ID: <20050127230519.GG7867@redhat.com> * Nick Bargnesi [2005-01-27 17:50]: > > This is because we've compiled and linked Eclipse with libgcj4's .so but > > you're running with gij from the 3.4.x package (which is linked against > > libgcj 3.4.x's .so). You just need to set your alternatives to point to > > java-1.4.2-gcj4-compat and -devel. See blow: > > > > Even after setting the alternative java and javac, I still see the > RenderedImage gcj failure. Hmm. Can I see the output of the following commands: rpm -qa | grep eclipse rpm -q gcc4-java rpm -q libgcj4-devel which java java --version which javac javac -version Thanks, Andrew From Nicolas.Mailhot at laPoste.net Thu Jan 27 23:40:38 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 28 Jan 2005 00:40:38 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050127192108.GC5263@rogers.com> References: <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <1106846765.13433.10.camel@rousalka.dyndns.org> <20050127192108.GC5263@rogers.com> Message-ID: <1106869238.16528.29.camel@rousalka.dyndns.org> Le jeudi 27 janvier 2005 ? 14:21 -0500, Dimitrie O. Paun a ?crit : > On Thu, Jan 27, 2005 at 06:26:05PM +0100, Nicolas Mailhot wrote: > > The non-latin support of gtk2 (vs gtk1) alone is a clear user benefit. > > So this is *very* far from an abstract argument with no tangible end- > > user incidence. > > I don't dispute that. But this is all tangential to the main purpose > of the freaking thing: to play music. You can get me the best non-latin > support, perfect HIG compliance, etc. but it it doesn't do a good job > playing music, it can't replace xmms. If you can't even read your playlist because xmms displays garbage, do you really think you'll appreciate the music you can't find ? (and btw xmms is not better at playing music than any other linux player - they all use the same backend libraries for christsakes. In fact the argument could easily be made that xmms is *worse* at playing music - all the stupid badly written eye-candy has been known to load systems enough to cause music skips) I'm not too fond of the rhythmbox UI myself. I'm the last one who'd say it doesn't have room for improvement. I'll even admit there are some parts of xmms' garbage heap of an ui that are better thought than the rhythmbox one. But even if xmms and rhythmbox were on the same level (and they're not - xmms' few qualities do not redeem its numerous problems) rhythmbox is getting better and xmms - not. Which means xmms will leave FC sooner or later and rhythmbox will stay (till it's relegate to history too). If it doesn't happen in FC4 it'll happen in FC5. So I'll stop loosing my time arguing about it here and let software obsolescence follow its natural course. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dpaun at rogers.com Thu Jan 27 23:52:16 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Thu, 27 Jan 2005 18:52:16 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106869238.16528.29.camel@rousalka.dyndns.org> References: <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <1106846765.13433.10.camel@rousalka.dyndns.org> <20050127192108.GC5263@rogers.com> <1106869238.16528.29.camel@rousalka.dyndns.org> Message-ID: <20050127235216.GY5673@rogers.com> On Fri, Jan 28, 2005 at 12:40:38AM +0100, Nicolas Mailhot wrote: > FC5. So I'll stop loosing my time arguing about it here and let software > obsolescence follow its natural course. Which is the only decent course of action. To argue for xmms' removal *now* because rhythmbox will eventually be as good/better then xmms is just plain silly. And completely non-productive. -- Dimi. From seanlkml at sympatico.ca Fri Jan 28 00:08:36 2005 From: seanlkml at sympatico.ca (Sean) Date: Thu, 27 Jan 2005 19:08:36 -0500 (EST) Subject: RFC: Soname in rpm name In-Reply-To: <604aa79105012714437df84250@mail.gmail.com> References: <1106570484.32065.1.camel@ulysse.olympe.o2t><604aa79105012416337f3de0ce@mail.gmail.com><20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com><1106848153.22178.16.camel@Madison.badger.com><604aa7910501271146533837ad@mail.gmail.com> <604aa79105012714437df84250@mail.gmail.com> Message-ID: <41543.10.10.10.28.1106870916.squirrel@linux1> On Thu, January 27, 2005 5:43 pm, Jeff Spaleta said: > I dont think the shared-library-package provides solves the cruft > problem from the project perspective. From the user perpective yes > the provides hack will be a somewhat useful mechanism for users/admins > to cull cruft from their boxes. But i don't think thats what Ville > had in mind when making the argument. I think Ville was talking about > how the project as a whole prevents itself from accumulating layers > and layers of library cruft that become harder and harder to maintain > as time goes by because there is less and less upstream interest in > maintaining the aging codebase. Its easy to package up an old library > and offer it.. it gets harder and harder to 'maintain' such a package > with critical and security related patches if the upstream development > interest has dried out. I think Ville's arguement is aimed at making > sure that whatever policy Core is using doesn't encourage the > accumulation of difficult to maintain legacy libraries for which users > are expecting to be able to be maintained at a high standard. Jeff, What you're talking about is not available today. Except to the extent people only install officially sanctioned core rpms. You're right that making it easier to install 3rd party rpms may lead to some poor user having a few old libraries kicking around. But this should not be an overarching concern. Unless you stop all 3rd party rpms from being installed there will be absolutely no way to know when some arbitrary 3rd party rpm falls into the category of unmaintained. This issue you keep raising just seems like a boondoggle in the face of trying to solve real issues of interoperability. If you want to write an app that scans peoples hard drive or rpm database and warns them of any old unmaintained or security risk software... all the power to you. Can we please get on with the task of making software installation, along with the necessary dependencies easier? If there is really a market for some software to scan for problem software, i'm sure it will get written. Sean From Axel.Thimm at ATrpms.net Fri Jan 28 00:36:06 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 28 Jan 2005 01:36:06 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: <604aa791050124142972c325cc@mail.gmail.com> <20050124224043.GI31520@neu.nirvana> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com> Message-ID: <20050128003606.GD16634@neu.nirvana> On Thu, Jan 27, 2005 at 04:02:14PM +0100, Aurelien Bompard wrote: > Harald Hoyer wrote: > > Or you release a new release of that version which provides the garbage > > collector symbol, Axel suggested. > > I'd be very happy to do that, but I'd like to know : is this the scheme Red > Hat is going to be moving to ? Soname in the package name and a > Provides : shared-library-package > in the spec file ? Do we agree on this ? I hope so. There were no strict arguments against using that scheme. > I also think it is a great solution, which adresses correctly all the major > issues raised here. I'd be very happy to see it become a packaging policy. Just to summarize: %{_libdir}/libfoo.so.N* gets packaged to libfooN %{_libdir}/libfoo-X.Y.so.N* gets packaged to libfoo-X.Y_N (e.g. if the part before ".so.N*" ends with a digit separate the library's major version with an underscore). Both versions have a "Provides: shared-library-package" to help identifying the disposable-if-not-depended-upon packages. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Fri Jan 28 00:59:45 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 27 Jan 2005 19:59:45 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <41543.10.10.10.28.1106870916.squirrel@linux1> References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com> <1106848153.22178.16.camel@Madison.badger.com> <604aa7910501271146533837ad@mail.gmail.com> <604aa79105012714437df84250@mail.gmail.com> <41543.10.10.10.28.1106870916.squirrel@linux1> Message-ID: <604aa79105012716592a8e3546@mail.gmail.com> On Thu, 27 Jan 2005 19:08:36 -0500 (EST), Sean wrote: > This issue you keep raising just seems like a > boondoggle in the face of trying to solve real issues of interoperability. Feel free to read any intent you feel you need to into what I'm saying. I'm looking at what I see as the historical 'implied' usage of library naming scheme in use. I'd love to be told I am wrong, and that this hasn't been a reason why the particular naming scheme has been used in the past. But if this has been an reason in the past.. its worth noting and trying to understand why it was deemed important before. You feel this isn't an important issue... fine... your opinion. But I want to make sure that everyone in this discussion has a competent understanding of WHY we have the current naming scheme... before myopic decisions are made with regard to what to do in the future. You don't think this is an important issue.. fine... but your opinion of its importance doesn't change whether or not the issue of 'expiring' is a reason why the naming scheme is currently in use. Regardless of what you think the correct path forward is... i think its vitally important to have an understanding of WHY the current naming scheme is being used to underpin any competent discussion about how to change it. I'm not sure any of the vocal proponents of the naming policy change have an understanding of why the current naming scheme exists. > Can we please get on with the task of making software > installation, along with the necessary dependencies easier? Once everyone has a good feel for why the current naming scheme exists... maybe... sort of depends on whether the 'right' people's priorities line up with yours. I'm not even sure the 'right' people are even reading this thread any more so any further discussion may very well be moot. -jef"playing the jester to the moot court"spaleta -jef From fedora at wir-sind-cool.org Fri Jan 28 01:06:27 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 28 Jan 2005 02:06:27 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <604aa7910501271146533837ad@mail.gmail.com> References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com> <1106848153.22178.16.camel@Madison.badger.com> <604aa7910501271146533837ad@mail.gmail.com> Message-ID: <20050128020627.0e2df479.fedora@wir-sind-cool.org> On Thu, 27 Jan 2005 14:46:01 -0500, Jeff Spaleta wrote: > On Thu, 27 Jan 2005 12:49:12 -0500, Toshio wrote: > > I'm also still waiting to see why the current de facto scheme of: > > current = libname > > previous = libname[Version] > > > > is _compellingly_ wrong... Perhaps there just needs to be a summary of > > Pros and Cons so we can see the tradeoffs. > > If i understand the argument that people are making... is that doing > it this way... is a burden on 3rd party packagers who have to try to > predict when and if Core is going to introduce a libname[Version] for > previous versions. Whenever that happens - when a Core package is renamed like this - the 3rd party packagers need to update their spec files to make them buildrequire libname[Version]-devel instead. Similarly, when the soname's major library version is put into the package name always, the Core packagers and everyone else, who wants to build rpms with the new library, would need to update the build requirements in all spec files when the major library version is increased. And what does the rule look like with packages which contain multiple libraries with different major versions? > And by association also a burden on users who are trying to use > applications from outside of current Core that still need the older > libs for applications until a 3rd party is able to rebuild a package > with the older libs or the application developers retool to support > the new library. That I don't see. Thanks to automatic dependencies on versioned sonames, the user doesn't need to know where libfoo.so.3 comes from, i.e. whether it is to be found in package libfoo3-3.0.1-1 or libfoo-3.0.3-1. From seanlkml at sympatico.ca Fri Jan 28 01:07:58 2005 From: seanlkml at sympatico.ca (Sean) Date: Thu, 27 Jan 2005 20:07:58 -0500 (EST) Subject: RFC: Soname in rpm name In-Reply-To: <604aa79105012716592a8e3546@mail.gmail.com> References: <1106570484.32065.1.camel@ulysse.olympe.o2t><1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com> <1106848153.22178.16.camel@Madison.badger.com><604aa7910501271146533837ad@mail.gmail.com><604aa79105012714437df84250@mail.gmail.com><41543.10.10.10.28.1106870916.squirrel@linux1> <604aa79105012716592a8e3546@mail.gmail.com> Message-ID: <41740.10.10.10.28.1106874478.squirrel@linux1> On Thu, January 27, 2005 7:59 pm, Jeff Spaleta said: > Feel free to read any intent you feel you need to into what I'm > saying. I'm looking at what I see as the historical 'implied' usage > of library naming scheme in use. I'd love to be told I am wrong, and > that this hasn't been a reason why the particular naming scheme has > been used in the past. But if this has been an reason in the past.. > its worth noting and trying to understand why it was deemed important > before. You feel this isn't an important issue... fine... your > opinion. But I want to make sure that everyone in this discussion has > a competent understanding of WHY we have the current naming scheme... > before myopic decisions are made with regard to what to do in the > future. Perhaps you could come up with some better objections to the proposals beyond some vague concern that someone might have some old software left on their system that might be unmaintained. Perhaps you could elucidate how you intend to make such a determination for every third party rpm in the ether. > You don't think this is an important issue.. fine... but your opinion > of its importance doesn't change whether or not the issue of > 'expiring' is a reason why the naming scheme is currently in use. > Regardless of what you think the correct path forward is... i think > its vitally important to have an understanding of WHY the current > naming scheme is being used to underpin any competent discussion about > how to change it. I'm not sure any of the vocal proponents of the > naming policy change have an understanding of why the current naming > scheme exists. Perhaps a more constructive conversation could ensue if it weren't interrupted by notions of providing protection from "unmaintained" software, that doesn't even exist today. You're demanding features from the proponents of change that don't even exist today. It's not helpful or constructive. > Once everyone has a good feel for why the current naming scheme > exists... maybe... sort of depends on whether the 'right' people's > priorities line up with yours. I'm not even sure the 'right' people > are even reading this thread any more so any further discussion may > very well be moot. Frankly, I don't think this point that seems so dear to you has helped anyone get a feel for why the current naming scheme exists. It sure doesn't protect against unmaintained 3rd party RPMS today. Sean From rdieter at math.unl.edu Fri Jan 28 02:45:47 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 27 Jan 2005 20:45:47 -0600 (CST) Subject: RFC: Soname in rpm name In-Reply-To: <20050128020627.0e2df479.fedora@wir-sind-cool.org> References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com> <1106848153.22178.16.camel@Madison.badger.com> <604aa7910501271146533837ad@mail.gmail.com> <20050128020627.0e2df479.fedora@wir-sind-cool.org> Message-ID: On Fri, 28 Jan 2005, Michael Schwendt wrote: >> If i understand the argument that people are making... is that doing >> it this way... is a burden on 3rd party packagers who have to try to >> predict when and if Core is going to introduce a libname[Version] for >> previous versions. > > Whenever that happens - when a Core package is renamed like this - the 3rd > party packagers need to update their spec files to make them buildrequire > libname[Version]-devel instead. I thought the proposal included that each package include Provides: libname = %version or was that also determined to be problematic? -- Rex From dwmw2 at infradead.org Fri Jan 28 01:32:24 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 28 Jan 2005 01:32:24 +0000 Subject: Fedora PPC things... In-Reply-To: <20050127151925.2847dab8@nausicaa.camperquake.de> References: <1106630968.5401.42.camel@localhost.localdomain> <20050127132800.1b7918ad@nausicaa.camperquake.de> <1106833365.19262.83.camel@hades.cambridge.redhat.com> <20050127144734.23734034@nausicaa.camperquake.de> <1106834467.19262.91.camel@hades.cambridge.redhat.com> <20050127150624.2b668980@nausicaa.camperquake.de> <20050127141109.GC21442@redhat.com> <20050127151925.2847dab8@nausicaa.camperquake.de> Message-ID: <1106875944.6453.1.camel@localhost.localdomain> On Thu, 2005-01-27 at 15:19 +0100, Ralf Ertzinger wrote: > I tried to rebuild 2.6.10-1.1107 on my iBook. Took ages and does not > even start booting. I get similar results on my PowerBook with 2.6.10-1.1112. Will investigate at some point. In the meantime, stick with the FC3 kernels. -- dwmw2 From pbrobinson at gmail.com Fri Jan 28 01:37:22 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 28 Jan 2005 09:37:22 +0800 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106824972.3239.32.camel@cobra.ivg2.net> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <1106824972.3239.32.camel@cobra.ivg2.net> Message-ID: <5256d0b05012717374f993d34@mail.gmail.com> > My main complaint is that for me is starts leaking memory when I try > to add that many songs at once, eventually using up all system > resources, and getting killed by the OOM killer. Happens 2/3 times. > That is a bug, not normal behavior. I'll file a bugzilla some day > when I get sufficiently annoyed. Its been fixed I believe in the devel version, unfortunately there has been no 0.9 release yet so it a go and get a copy out of arch fix. P From fedora at wir-sind-cool.org Fri Jan 28 01:38:43 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 28 Jan 2005 02:38:43 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <604aa791050124145435e5a102@mail.gmail.com> <20050124232113.GM31520@neu.nirvana> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com> <1106848153.22178.16.camel@Madison.badger.com> <604aa7910501271146533837ad@mail.gmail.com> <20050128020627.0e2df479.fedora@wir-sind-cool.org> Message-ID: <20050128023843.0a60d5a6.fedora@wir-sind-cool.org> On Thu, 27 Jan 2005 20:45:47 -0600 (CST), Rex Dieter wrote: > >> If i understand the argument that people are making... is that doing > >> it this way... is a burden on 3rd party packagers who have to try to > >> predict when and if Core is going to introduce a libname[Version] for > >> previous versions. > > > > Whenever that happens - when a Core package is renamed like this - the 3rd > > party packagers need to update their spec files to make them buildrequire > > libname[Version]-devel instead. > > I thought the proposal included that each package include > Provides: libname = %version > or was that also determined to be problematic? Unfortunately, that's a rather short example. Can you extend that a bit, please, or point me to the full-blown proposal? What is %version here? The same old version as we know it? How exactly does it look like in a library package, it's -devel counterpart and a spec file which buildrequires this thing? So far, we've had "Buildrequires: taglib-devel"? What would it look like instead? From pbrobinson at gmail.com Fri Jan 28 01:42:29 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 28 Jan 2005 09:42:29 +0800 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106854184.21328.1.camel@shuttle.273piedmont.org> References: <1106334872.3809.3.camel@nexus.verbum.private> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <1106846765.13433.10.camel@rousalka.dyndns.org> <20050127192108.GC5263@rogers.com> <1106854184.21328.1.camel@shuttle.273piedmont.org> Message-ID: <5256d0b0501271742633bc5@mail.gmail.com> > > As such, it's just a bad idea to remove xmms at this point. > > So what are we debating here? > > Wasn't the discussion about moving xmms to Fedora Extras, and out of > Fedora Core? How does this stop you from being able to install xmms? My thoughts exactly. Its not about removing xmms its about moving it from core to extras. pete From aluchko at redhat.com Fri Jan 28 01:37:01 2005 From: aluchko at redhat.com (Aaron Luchko) Date: Thu, 27 Jan 2005 20:37:01 -0500 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <20050127165139.GA30730@redhat.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <1106750499.19595.4.camel@localhost.localdomain> <20050126144636.GA7010@redhat.com> <20050127165139.GA30730@redhat.com> Message-ID: <1106876221.5700.20.camel@jekyll> On Thu, 2005-01-27 at 11:51 -0500, Andrew Overholt wrote: > * Andrew Overholt [2005-01-26 09:47]: > > > > I'm hoping to go back to a 3.1 milestone build before FC4. > > Looking at the schedules for Eclipse 3.1 [1] and FC4 [2], I see the > following: > > Eclipse 3.1 M6 (stable build, API freeze): 2005-04-01 > FC4 Absolute devel freeze: 2005-05-02 > Eclipse 3.1 M7 (stable build, development freeze, etc.): 2005-05-13 > FC4 Release open, announced: 2005-06-16 > > I'd like to ship a 3.1 M6 (or some stable incremental build between then > and FC4 freeze) with FC4 and then update to M7 and 3.1 final as they come > out. Agreed, I've been using M4 and the integration builds and they're working quite well for me, I don't really see any big issues with eclipse itself coming up that late in the game though libgcj4/gij4 is still a bit of a wild card, hopefully nothing big will pop up in testing. In functionality for Linux particularly I think 3.1 is a big step forward with the permission bits and file permissions issues sorted out along with GTK file chooser now being used. As well I personally find developing upstream eclipse plugins is definitely easier with 3.1 given the number of changes that occur in the code between releases. If we have to go with 3.0 it's not a disaster by any means but given the choice I definitely would prefer 3.1. btw. I ran the rpms quickly and they worked great, awesome work! Aaron From skvidal at phy.duke.edu Fri Jan 28 02:21:11 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 27 Jan 2005 21:21:11 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050127235216.GY5673@rogers.com> References: <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <1106846765.13433.10.camel@rousalka.dyndns.org> <20050127192108.GC5263@rogers.com> <1106869238.16528.29.camel@rousalka.dyndns.org> <20050127235216.GY5673@rogers.com> Message-ID: <1106878871.3607.4.camel@cutter> On Thu, 2005-01-27 at 18:52 -0500, Dimitrie O. Paun wrote: > On Fri, Jan 28, 2005 at 12:40:38AM +0100, Nicolas Mailhot wrote: > > FC5. So I'll stop loosing my time arguing about it here and let software > > obsolescence follow its natural course. > > Which is the only decent course of action. To argue for xmms' removal > *now* because rhythmbox will eventually be as good/better then xmms > is just plain silly. And completely non-productive. > just to be clear. We're talking about 'non-productive' in scope of mp3/ogg players? :) -sv From fedora-devel at tlarson.com Fri Jan 28 02:47:33 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Thu, 27 Jan 2005 19:47:33 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <604aa79105012710144dd061ee@mail.gmail.com> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> Message-ID: <41F9A7C5.6050200@tlarson.com> Jeff Spaleta wrote: > This is why i suggested that someone who has used both xmms and bmp > (aka beep) comment about bmp's suitability as a replacement. > > -jef"has anyone actually used bmp? I dont even use xmms anymore so I'm > not in a position to compare"spaleta > Just installed it (newrpms has an FC3 package for it). When I switched it to use the XMMS-Bluecurve skin, it was (unsurprisingly) indistinguishable from xmms. It even uses xmms plugins. This, too, isn't a surprise, since bmp is just a GTK2 port of xmms. After installing mp3 support (bmp-mp3) I connected to a streaming MP3 internet radio station, and everything worked as expected. Screenshot at http://www.tlarson.com/bmp.png The interface (to the extent that it differs from xmms--program settings and such) is definitely an improvement. Very clean and intuitive. Except, of course, the gnome open-file dialog box. Makes me angry every time I see it. Grrr. If we were to replace xmms with bmp, I doubt anyone would complain. I doubt anyone would even be able to tell the difference. Plus, we'd be able to get rid of the old gtk1 libs. Everyone wins! If you're still holding on to xmms, download bmp and give it a try. I'd be very much surprised if you can find anything you don't like about it. From jspaleta at gmail.com Fri Jan 28 03:06:40 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 27 Jan 2005 22:06:40 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F9A7C5.6050200@tlarson.com> References: <1106333362.3427.19.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> Message-ID: <604aa791050127190670b45173@mail.gmail.com> On Thu, 27 Jan 2005 19:47:33 -0700, Tyler Larson wrote: > If we were to replace xmms with bmp, I doubt anyone would complain. I > doubt anyone would even be able to tell the difference. Plus, we'd be > able to get rid of the old gtk1 libs. Everyone wins! I dont know if xmms is the only thing keeping the old gtk1 libs in. Is it? If it is the only thing in Core that is using the gtk1 stuff that would be a strong reason to take a serious look at bmp as a replacement. Unless of course its deemed that the functionality bmp/xmms needs to be pulled out. So now there are two questions on the table. Is it worth removing xmms from Core? Thats a tough question... and prone to trench warfare. How about we all install scrotched3d and fight it out until there is a clear winner. Or Is it worth replacing xmms with bmp in Core? I think this is an easier question to answer and has a technical win if this allows for the dropping of the gtk1 libs or gets us a step closer to dropping the gtk1 libs. How about more avid xmms users in this discussion give bmp a try and see if its good enough replacement. -jef From rodd at clarkson.id.au Fri Jan 28 03:30:41 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 28 Jan 2005 14:30:41 +1100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <604aa791050127190670b45173@mail.gmail.com> References: <1106333362.3427.19.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> Message-ID: <1106883041.5134.40.camel@trevally.redfishdemo.com> On Thu, 2005-01-27 at 22:06 -0500, Jeff Spaleta wrote: > So now there are two questions on the table. > Is it worth removing xmms from Core? Thats a tough question... and > prone to trench warfare. > Is it worth replacing xmms with bmp in Core? Or maybe we should be asking... 1. Which would be better to use? xmms or bmp? 2. Should it be in Core, or Extras. As a dedicated xmms user I don't mind whether we have xmms or bmp as long as the functionality is roughly equivalent. AND, as a dedicated xmms user I think it should be in extras (people wanting xmms will know how to get it and most other will just use Music Player) This is a hard call, but I'm all for seeing CORE made "really" small and (if possible) fitting onto a single CD. If this means making the hard decisions about having to get a couple of my favorite apps from Extra to get a equivalent desktop setup instead of having to download four ISO's (soon, at this rate, to be five or six) then I'm all for dropping of the apps I use into Extras. These days, yum is so easy to use to add applications that I don't reach for the CDs that much any more. It's far easier to type yum update xmms than to find xmms on on of four cds and then go through the process of shuffling CD for the dependencies. Rodd (two cents poorer) -- >From the pain come the dream >From the dream come the vision >From the vision come the people >From the people come the power >From this power come the change - Peter Gabriel From Axel.Thimm at ATrpms.net Fri Jan 28 04:26:32 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 28 Jan 2005 05:26:32 +0100 Subject: RFC: Soname in rpm name In-Reply-To: References: <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com> <1106848153.22178.16.camel@Madison.badger.com> <604aa7910501271146533837ad@mail.gmail.com> <20050128020627.0e2df479.fedora@wir-sind-cool.org> Message-ID: <20050128042632.GA25435@neu.nirvana> On Thu, Jan 27, 2005 at 08:45:47PM -0600, Rex Dieter wrote: > On Fri, 28 Jan 2005, Michael Schwendt wrote: > > >>If i understand the argument that people are making... is that doing > >>it this way... is a burden on 3rd party packagers who have to try to > >>predict when and if Core is going to introduce a libname[Version] for > >>previous versions. > > > >Whenever that happens - when a Core package is renamed like this - the 3rd > >party packagers need to update their spec files to make them buildrequire > >libname[Version]-devel instead. > > I thought the proposal included that each package include > Provides: libname = %version > or was that also determined to be problematic? That would be a way, but I would be less intrusive right now. Just use foo-devel and have foo-devel require libfoo. I.e. the libfoo package is nowhere explicitly requested outside the package itself. That way all packages can be refactored in asynchronous time w/o changing dependencies of other packages. Example: old: foo-1.2.3-4.src.rpm generates foo-1.2.3-4.i386.rpm foo-devel-1.2.3-4.i386.rpm new: foo-1.2.3-4.src.rpm generates foo-1.2.3-4.i386.rpm libfoo5-1.2.3-4.i386.rpm foo-devel-1.2.3-4.i386.rpm -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sysadmin at cokzl.rusautogaz.ru Fri Jan 28 05:26:08 2005 From: sysadmin at cokzl.rusautogaz.ru (Sysadmin cokzl) Date: Fri, 28 Jan 2005 08:26:08 +0300 Subject: Help correct Fedora s390 running under VM References: <007701c503ba$e84566f0$580310ac@rusautogaz.ru> <1106853818.2656.15.camel@localhost.localdomain> Message-ID: <040501c504f9$df250400$580310ac@rusautogaz.ru> ----- Original Message ----- From: "Kyrre Ness Sjobak" To: "Development discussions related to Fedora Core" Sent: Thursday, January 27, 2005 10:23 PM Subject: Re: Help correct Fedora s390 running under VM > ons, 26.01.2005 kl. 16.15 skrev Sysadmin cokzl: > > I am run (Fedora Core release Rawhide (Rawhide)Kernel 2.6.10-1.1103_FC4 on > > an s390) > > from vm/esa on s390, and i am see on console: > > > > **************************************************************************** > > *********** > > Booting default (linux)... > > Linux version 2.6.10-1.1103_FC4 (bhcompile at spade.z900.redhat.com) (gcc > > version > > .4.3 20050113 (Red Hat 3.4.3-15)) #1 SMP Wed Jan 19 20:40:50 EST 2005 > > We are running under VM (31 bit mode) > > This machine has no IEEE fpu > > Built 1 zonelists > > Kernel command line: root=LABEL=/1 BOOT_IMAGE=0 > > PID hash table entries: 1024 (order: 10, 16384 bytes) > > Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) > > Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) > > Memory: 124544k/131072k available (1874k kernel code, 0k reserved, 605k > > data, 1 > > 8k init) > > Security Framework v1.0.0 initialized > > SELinux: Initializing. > > SELinux: Starting in permissive mode > > selinux_register_security: Registering secondary module capability > > Capability LSM initialized as secondary > > Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > > Detected 1 CPU's > > Boot cpu address 0 > > cpu 0 phys_idx=0 vers=FF ident=100003 machine=9672 unused=0000 > > Brought up 1 CPUs > > checking if image is initramfs... it is > > Freeing initrd memory: 899k freed > > debug: Initialization complete > > NET: Registered protocol family 16 > > **************************************************************************** > > *************** > > and here cycling > > i am do command vm/esa: > > trace all > > and i see: > > TRACE ALL > > HCPTRI1027I An active trace set has turned RUN off. > > B > > -> 001D196E' SLR 1F33 CC 2 > > B > > 001D1970' CS BA342000 002E8454 CC 1 > > B > > 001D1974' ???? A744FFFB 0057AD33 CC 1 > > B > > -> 001D196A' DIAG 83000044 00000044 CC 1 > > B > > 001D196E' SLR 1F33 CC 2 > > B > > 001D1970' CS BA342000 002E8454 CC 1 > > B > > 001D1974' ???? A744FFFB 0057AD33 CC 1 > > B > > -> 001D196A' DIAG 83000044 00000044 CC 1 > > B > > 001D196E' SLR 1F33 CC 2 > > B > > 001D1970' CS BA342000 002E8454 CC 1 > > B > > 001D1974' ???? A744FFFB 0057AD33 CC 1 > > B > > -> 001D196A' DIAG 83000044 00000044 CC 1 > > B > > 001D196E' SLR 1F33 CC 2 > > B > > 001D1970' CS BA342000 002E8454 CC 1 > > B > > 001D1974' ???? A744FFFB 0057AD33 CC 1 > > > > i am do command vm/esa: > > STORE 001D1974 A7440002: > > and i see: > > CP ST 001D1974 A7440002 > > Store complete. > > > > cio: Was not able to determine available CHSCs, cc=2. > > chsc_get_sch_descriptions: Error -22 while doing chsc; processing some > > machine c > > hecks may not work > > appldata info: mem-ops registered] > > appldata info: os-ops registered] > > appldata info: net_sum-ops registered] > > audit: initializing netlink socket (disabled) > > audit(1106763062.926:0): initialized > > VFS: Disk quotas dquot_6.5.1 > > Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) > > SELinux: Registering netfilter hooks > > Initializing Cryptographic API > > ksign: Installing public key data > > Loading keyring > > - Added public key A151D8E9D3A0BB > > - User ID: Red Hat, Inc. (Kernel Module GPG key) > > io scheduler noop registered > > io scheduler anticipatory registered > > io scheduler deadline registered > > io scheduler cfq registered > > RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize > > md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27 > > Channel measurement facility using basic format (autodetected) > > cpi: no system name specified > > NET: Registered protocol family 2 > > IP: routing cache hash table of 1024 buckets, 8Kbytes > > TCP established hash table entries: 8192 (order: 5, 131072 bytes) > > TCP bind hash table entries: 8192 (order: 4, 65536 bytes) > > TCP: Hash tables configured (established 8192 bind 8192) > > Initializing IPsec netlink socket > > NET: Registered protocol family 1 > > NET: Registered protocol family 17 > > Freeing unused kernel memory: 108k freed > > Red Hat nash version 4.2.0.1 starting > > Mounted /proc filesystem ........................................ > > and so on > > > > and i see: > > Fedora Core release Rawhide (Rawhide) > > Kernel 2.6.10-1.1103_FC4 on an s390 > > > > cokzlb login: > > HELP correct; improve; reform; repair BUG > > I don't know the first thing about such irons - but when it says cokzlb > login: - can't you just login as root, add some users and get started? I can come as root, me interest why at loading system there is a cycling!!!!!!!!! And while I directly on shall replace the address of memory, loading will not go further.: > > checking if image is initramfs... it is > > Freeing initrd memory: 899k freed > > debug: Initialization complete > > NET: Registered protocol family 16 > > **************************************************************************** > > *************** > > and here cycling > > i am do command vm/esa: > > trace all > > and i see: > > TRACE ALL > > HCPTRI1027I An active trace set has turned RUN off. > > B > > -> 001D196E SLR 1F33 CC 2 > > B > > 001D1970 CS BA342000 002E8454 CC 1 > > B > > 001D1974 ???? A744FFFB 0057AD33 CC 1 001D1974 ???? A744FFFB 0057AD33 CC 1 <------ This place i replace it on 001D1974 A7440002 and only then loading proceeds!!!! From fedora-devel at tlarson.com Fri Jan 28 06:23:09 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Thu, 27 Jan 2005 23:23:09 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106883041.5134.40.camel@trevally.redfishdemo.com> References: <1106333362.3427.19.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> Message-ID: <41F9DA4D.7040801@tlarson.com> Rodd Clarkson wrote: > This is a hard call, but I'm all for seeing CORE made "really" small and > (if possible) fitting onto a single CD. If this means making the hard > decisions about having to get a couple of my favorite apps from Extra to > get a equivalent desktop setup instead of having to download four ISO's > (soon, at this rate, to be five or six) then I'm all for dropping of the > apps I use into Extras. > Lets face it, if we're really interested in shrinking the size of the distro, cutting a few packages like XMMS isn't going to make a spit of difference. Not even eliminating unused packages is going to do much good. If we want to make an appreciable difference in the size of FC, we've got to cut at least enough to remove a CD or two. If we just cut a few redundant packages, we piss some people off, but gain nearly nothing. If we really want to cut the size of the distro by more than a few hundred meg, we've got to start removing functionality. Plain and simple. Something that lots of people *need* has to go. And you're not going to do it without making a whole lot of people really, really mad. So, what gets the ax? Tough to say. There's only 15 packages in fc3 that are >= 20 Meg. And OOo accounts for almost 200M of that. But can we really ax OpenOffice? Heresy. KDE? Blasphemous. Sure, we could move packages to Extras... if only we had some idea what Extras is. Whatever it is, though, I'm quite certain that the packages *I* use don't belong there, right? But if the Extras CDs are distributed with the core CDs, and if most people will need the Extras CDs to get those last three packages they're rather fond of, what really is the point dividing them up? Other than, of course, to inconvenience the user. I was all for it a few hours ago, but now it doesn't sound like we'll be helping anyone out. The way I see it, we're left with two options: A) Big distro. Deal with it. B) Piss lots of people off because Fedora no longer includes the software they use. Sorry KDE and OOo users. The third option, "remove the stuff people don't use", seems more like a pipe dream than a viable course of action. You can't remove enough fat to keep A from happening without bringing about B. Moving a substantial amount of stuff into an "Extras" category (or whatever it is) seems like a "worst of both worlds" solution. Not only has the total software base not shrunk, but it's now more difficult to find the package you want. What are the chances, really, that the average user *won't* want at least some of the software on the Extras CD(s)? I don't know. The more I think about it, the less excited I get. Perhaps someone can share a more rosy picture of how moving packages to Fedora Extras is supposed to make the users' lives so much easier. Anyone care to bite? From jwz at jwz.org Fri Jan 28 06:28:29 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Thu, 27 Jan 2005 22:28:29 -0800 Subject: grip being removed [Re: rawhide report: 20050120 changes] References: <1106333362.3427.19.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> Message-ID: <41F9DB8D.686FCF33@jwz.org> > How about more avid xmms users in this discussion give bmp > a try and see if its good enough replacement. I'd characterize myself as a "resigned" XMMS user rather than an "avid" XMMS user, but I do use it. I think its UI sucks, but I find that it works. So I tried out BMP, and got nowhere. 1) The fact that it does not have a "double size" option is pretty much a showstopper, because I can't read a damned thing on that sub-postage-stamp-sized window. 2) Perhaps I could fix this by wasting hours finding a less horrid theme to use but A) in five minutes of clicking and googling, I didn't see any easy-to-find collection of BMP themes, and B) I'd really really rather claw out my eyes than dig through those anyway. (Can someone recommend one that isn't totally 'l33t and awful?) 3) and this may be related to "1: can't read the window", I couldn't figure out how to play an Icecast stream at all. xmms has "Play Location" on the menu, BMP does not. Perhaps if I could read the window, the answer would be obvious, but I can't so it's not. 4) "BMP" is a monumentally stupid name (hey, let's name the MP3 player "JPEG"!) and "beep-media-player" is both dumb and too much typing. So then I tried Totem, and it suffers from the canonical Red Hat braindamage of "oh, you haven't installed the mystery secret MP3 plugin, and no, I won't even hint to you where to find it." Frankly, I can't be bothered to go on this snark hunt again, I've done that enough times. So, I'd be thrilled to try out an alternative MP3 player to XMMS, just as soon as someone can point me to one that actually plays MP3s! -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From pbrobinson at gmail.com Fri Jan 28 07:28:30 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 28 Jan 2005 15:28:30 +0800 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <604aa791050127190670b45173@mail.gmail.com> References: <1106333362.3427.19.camel@localhost.localdomain> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> Message-ID: <5256d0b050127232840e0d5c9@mail.gmail.com> > > If we were to replace xmms with bmp, I doubt anyone would complain. I > > doubt anyone would even be able to tell the difference. Plus, we'd be > > able to get rid of the old gtk1 libs. Everyone wins! > > I dont know if xmms is the only thing keeping the old gtk1 libs in. Is it? > If it is the only thing in Core that is using the gtk1 stuff that > would be a strong reason to take a serious look at bmp as a > replacement. Unless of course its deemed that the functionality > bmp/xmms needs to be pulled out. No, probably the other major one is gnucash but then I think they should be moved to extras along with all the gtk1/gnome1 bits and review whether they come back or not once they are up to gtk2. just my 2c pete From rahulsundaram at yahoo.co.in Fri Jan 28 09:10:34 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Fri, 28 Jan 2005 01:10:34 -0800 (PST) Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F9DA4D.7040801@tlarson.com> Message-ID: <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> Hi > > I don't know. The more I think about it, the less > excited I get. Perhaps > someone can share a more rosy picture of how moving > packages to Fedora > Extras is supposed to make the users' lives so much > easier. Anyone care > to bite? > I do. Fedora core should only include one default program for each kind of task overall. there might be a few exceptions like including say nano as well as vim but having 5 different browsers and calling in fedora "core" doesnt make any sense at all Fedora extras and alternatives should have all the other stuff but can be integrated with anaconda if thats going to ease the split up. fedora core being limited to one or two cds has the following advantages * security - people tend to install whatever comes with their distro. users tend to do this because they might not know whats optional. providing the defaults would help having less stuff installed on their machines which is potentialy more secure * updates - fedora provides updates not only for bug fixes and security updates but also for adding new features. basically whenever a new upstream release is being made for stuff included in fedora, the project strives to release that as an update. this tends to add up to gigabytes over a particular release and lifecycle. by reducing the amount of packages, end users will have less stuff to update. this also helps them manage their systems more easily * downloads - fedora core attracts a good amount of users completely new to Linux. they will have be happy to use what is provided within core without having to make a choice between N number of stuff that seems to be providing the same thing. having fedora core limited to a single cd or two is beneficial because users will potentially have less stuff to download * retail redistribution - magazines and books will find it more easy to redistribute a single cd rather than a whole bunch of them. some choose to modify the distribution for this purpose. we will ease their pain and expand the reach of fedora * community access - by giving important packages over to the community, fedora project would demonstrate its commitment to allowing everyone to contribute to it. as a more specific example, KDE tends to have less integration and changes in fedora which many people believe is the result of redhat's focus on gnome. by allowing the community to maintain the KDE packages in extras, fedora core developers can go ahead with what it wants to do with gnome and the rest of the community can take care of KDE well. those who oppose the move because they believe this will become a political fight should note that fedora extras can be integrated very well with anaconda and a subset of fedora extras which includes KDE can be supplied and follow the same release cycle as fedora core itself making the transition easy to follow. fedora extras shouldnt be treated as something less important to fedora core. the fedora project should make sure they have the same kind of quality and support as fedora core itself. policies should be formed so that the core developers takes care of important packages moved to extras till the community steps up or alteast give a buffer period. the project should have a publicly documented clear policy of what core, alternatives and other repos should contain and how the community can involve themselves in the maintainance of packages ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 From byte at aeon.com.my Fri Jan 28 09:43:47 2005 From: byte at aeon.com.my (Colin Charles) Date: Fri, 28 Jan 2005 15:13:47 +0530 Subject: fedora stable branch updates Q&A policy In-Reply-To: <1106851614.2656.7.camel@localhost.localdomain> References: <1106851614.2656.7.camel@localhost.localdomain> Message-ID: <1106905427.5373.57.camel@localhost.localdomain> On Thu, 2005-01-27 at 19:46 +0100, Kyrre Ness Sjobak wrote: > Personally, i would believe a q&a mailinglist and a "testing" repo for > yum could be a good idea, in order to get packages as good tested as > possible - as fast as possible. There is a testing repo, its called updates-testing (look in /etc/yum.repos.d/fedora-updates-testing.repo). Discussion of that happens at fedora-test-list at redhat.com as do the announcements for new packages However, I don't think many folk test it and QA it, and it usually gets pushed out as an update (updates-released) within a couple of days So, whats your issue with an update that Core had? -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From pmatilai at welho.com Fri Jan 28 09:58:00 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 28 Jan 2005 11:58:00 +0200 (EET) Subject: redhat abe In-Reply-To: <1106835854.22312.101.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> Message-ID: On Thu, 27 Jan 2005, Ralf Corsepius wrote: > On Thu, 2005-01-27 at 08:52 -0500, seth vidal wrote: >>> RH has the ability to change this at any time. >> >> ability? yes. willingness? no. >> >> >>> It is not - RH has had no problems in adding yum support and has no >>> problem in adding and removing other packages at any time at RH's free >>> will. >> >> Do you know why they had no issue adding yum support? B/c it could be >> covered internally. If it broke and I wasn't around to fix it - they >> could take care of it. >> >> 100+ lines of C++ they were not interested in maintaining. > How comes, FE/fedora.us is able to maintain it? Fedora.us has/had an upstream apt-rpm developer (some weird masochist sharing my mail-address :) maintaining it and writing all sorts of weird Lua-extensions to it to better fit the world of FC, external kernel-module packages and such. > > I know apt's code is ... ... leaves a lot to be desired, but it doesn't > require that much effort to maintain the package. Maintaining the package ain't hard, but developing apt-rpm into various directions required by FC (multilib, new repodata format) is just about as fun as pulling teeth without anesthesia. The new repodata is something that would be sanely implementable into apt, multilib as used in FC and RHEL (namely packages with same nevr but different arch simultaenously installed) is something that doesn't fit nicely into it's design. And that's putting it somewhat mildly. I've actually tried various approaches to adding multilib support to apt with varying success, however none of work well enough to be actually usable. - Panu - From dag at wieers.com Fri Jan 28 10:09:16 2005 From: dag at wieers.com (Dag Wieers) Date: Fri, 28 Jan 2005 11:09:16 +0100 (CET) Subject: redhat abe In-Reply-To: <1106839422.22312.145.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <41F8FC8A.20404@nc.rr.com> <1106839422.22312.145.camel@mccallum.corsepiu.local> Message-ID: On Thu, 27 Jan 2005, Ralf Corsepius wrote: > On Thu, 2005-01-27 at 09:36 -0500, Jeff Johnson wrote: > > > Best damn depsolver that I've ever seen, does all the > > (imho) useful > > stuff that apt does (and yum/up2date do not, at least not yet, like > > back-tracking), > > Does smartrpm have equivalents to > > apt-get source > apt-get build-dep > > These are the features I like about apt and which make apt interesting > to me. I know Gustavo showed interest in adding this kind of functionality. It may depend on the back-end being used, some repo metadata does not support source packages. In the light of this discussion, it would be nice if Smart developped mach/abe kind of functionality too. Especially since Smart's configuration can be easily manipulated using smart on the commandline and it already includes much of the infrastructure necessary. > Another feature I am missing in both apt and yum is a usable > --download-only operation. > apt-get has "-d" but insists on its "package name mangling", (FC3's) yum > doesn't support it all, I don't know about smartrpm. smart upgrade --download You also have 'smart download' if you just want to download a set of packages by name/glob. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From pmatilai at welho.com Fri Jan 28 10:10:17 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 28 Jan 2005 12:10:17 +0200 (EET) Subject: redhat abe In-Reply-To: <41F90209.8060901@nc.rr.com> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106837393.25136.0.camel@opus.phy.duke.edu> <41F90209.8060901@nc.rr.com> Message-ID: On Thu, 27 Jan 2005, Jeff Johnson wrote: > seth vidal wrote: > >> really, then you know apt doesn't work, at all, with multilib. >> >> You gonna fix that? >> > > I am, one of these days, probably with help from either Gustavo or Panu. I wish you luck :) If you *really* want to mess with apt internals I do have ideas how it could be done (some of which I've tried but got tangled in the implementation details and dropped due to lack of time and interest). But really I think time would be better spent improving yum/smartpm to have the equivalent of build-dep, source and such operations. - Panu - From dag at wieers.com Fri Jan 28 10:22:24 2005 From: dag at wieers.com (Dag Wieers) Date: Fri, 28 Jan 2005 11:22:24 +0100 (CET) Subject: redhat abe In-Reply-To: References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106837393.25136.0.camel@opus.phy.duke.edu> <41F90209.8060901@nc.rr.com> Message-ID: On Fri, 28 Jan 2005, Panu Matilainen wrote: > On Thu, 27 Jan 2005, Jeff Johnson wrote: > > > seth vidal wrote: > > > > > really, then you know apt doesn't work, at all, with multilib. > > > > > > You gonna fix that? > > > > > > > I am, one of these days, probably with help from either Gustavo or Panu. > > I wish you luck :) If you *really* want to mess with apt internals I do have > ideas how it could be done (some of which I've tried but got tangled in the > implementation details and dropped due to lack of time and interest). But > really I think time would be better spent improving yum/smartpm to have the > equivalent of build-dep, source and such operations. And make Smart work on older versions of python and with older rpmlib versions, at least RHEL3. RHN support is also on my wishlist. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From rahulsundaram at yahoo.co.in Fri Jan 28 08:42:21 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Fri, 28 Jan 2005 00:42:21 -0800 (PST) Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F9DB8D.686FCF33@jwz.org> Message-ID: <20050128084221.42676.qmail@web8501.mail.in.yahoo.com> Hi > So then I tried Totem, and it suffers from the > canonical Red Hat > braindamage of "oh, you haven't installed the > mystery secret MP3 plugin, > and no, I won't even hint to you where to find it." > Frankly, I can't be > bothered to go on this snark hunt again, I've done > that enough times. thats not a redhat stupidity. its patent issues over mp3 and pointing out where to find it is a potential patent and DMCA violation for redhat to do ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo From Nicolas.Mailhot at laPoste.net Fri Jan 28 10:48:23 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 28 Jan 2005 11:48:23 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050127235216.GY5673@rogers.com> References: <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <1106846765.13433.10.camel@rousalka.dyndns.org> <20050127192108.GC5263@rogers.com> <1106869238.16528.29.camel@rousalka.dyndns.org> <20050127235216.GY5673@rogers.com> Message-ID: <1106909303.29352.69.camel@ulysse.olympe.o2t> Le jeudi 27 janvier 2005 ? 18:52 -0500, Dimitrie O. Paun a ?crit : > On Fri, Jan 28, 2005 at 12:40:38AM +0100, Nicolas Mailhot wrote: > > FC5. So I'll stop loosing my time arguing about it here and let software > > obsolescence follow its natural course. > > Which is the only decent course of action. To argue for xmms' removal > *now* because rhythmbox will eventually be as good/better then xmms > is just plain silly. And completely non-productive. That's not what I wrote. For me rhythmbox is slightly better _now_. And with it getting better all the time ever die-hard xmms fanatics will have an hard time keep it in-core by FC5 time (not that some of the arguments advanced are not already verging on the outrageous). Which means *I* don't have to make a desesperate last stand today because I know which side will win eventually, if not in FC4 then in FC5. If I were deeply attached to the xmms-way of doing things like you obviously are I'd push for beep/bmp inclusion now because its lead over a more mature totem/rhythmbox might not be so obvious in several months. No sense to put my money (or in this case, my words) on a dying horse. This is advice freely given, you can ignore it if you wish (but do not complain later). -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rahulsundaram at yahoo.co.in Fri Jan 28 09:53:49 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Fri, 28 Jan 2005 01:53:49 -0800 (PST) Subject: fedora stable branch updates Q&A policy In-Reply-To: <1106905427.5373.57.camel@localhost.localdomain> Message-ID: <20050128095349.60116.qmail@web8509.mail.in.yahoo.com> --- Colin Charles wrote: > On Thu, 2005-01-27 at 19:46 +0100, Kyrre Ness Sjobak > wrote: > > Personally, i would believe a q&a mailinglist and > a "testing" repo for > > yum could be a good idea, in order to get packages > as good tested as > > possible - as fast as possible. > > There is a testing repo, its called updates-testing > (look > in /etc/yum.repos.d/fedora-updates-testing.repo). > Discussion of that > happens at fedora-test-list at redhat.com as do the > announcements for new > packages > > However, I don't think many folk test it and QA it, > and it usually gets > pushed out as an update (updates-released) within a > couple of days > > So, whats your issue with an update that core had? there were several regressions. kernels, gui for firewall with relation to selinux, network manager and so on. I am sure many of them are well know if you search in the users list and bugzilla ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From rc040203 at freenet.de Fri Jan 28 10:34:09 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 28 Jan 2005 11:34:09 +0100 Subject: redhat abe In-Reply-To: References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> Message-ID: <1106908449.22312.242.camel@mccallum.corsepiu.local> On Fri, 2005-01-28 at 11:58 +0200, Panu Matilainen wrote: > On Thu, 27 Jan 2005, Ralf Corsepius wrote: > > > On Thu, 2005-01-27 at 08:52 -0500, seth vidal wrote: > >>> RH has the ability to change this at any time. > >> > >> ability? yes. willingness? no. > >> > >> > >>> It is not - RH has had no problems in adding yum support and has no > >>> problem in adding and removing other packages at any time at RH's free > >>> will. > >> > >> Do you know why they had no issue adding yum support? B/c it could be > >> covered internally. If it broke and I wasn't around to fix it - they > >> could take care of it. > >> > >> 100+ lines of C++ they were not interested in maintaining. > > How comes, FE/fedora.us is able to maintain it? > > Fedora.us has/had an upstream apt-rpm developer (some weird masochist > sharing my mail-address :) maintaining it and writing all sorts of weird > Lua-extensions to it to better fit the world of FC, external kernel-module > packages and such. You know, that I know :-) I definitely appreciate this. > > I know apt's code is ... ... leaves a lot to be desired, but it doesn't > > require that much effort to maintain the package. > > Maintaining the package ain't hard, That's what I assume. It's just a package, not much different from others, with bugs, deficiencies and "uniquenesses" of it's own. Nothing more, nothing less. > but developing apt-rpm into various > directions required by FC (multilib, ACK, that's apt's main deficiency. > new repodata format) IMO, this is more a matter of politics and willingness, but a technical requirement. Technically, I don't see any need for apt to adopt yum's repodata format. Politically, this requirement is introduced by RH not wanting to add apt-repositories and fedora.us apparently being unable to set up complete repositories. If apt-repositories are cleverly set up, the additional overhead they introduce in addition to the original files becomes more or less negligible. BTW: Even SuSE is available with apt. I wonder why they don't have the multilib issue - I guess they don't ship multilibs :) Ralf From fedora at wir-sind-cool.org Fri Jan 28 11:03:36 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 28 Jan 2005 12:03:36 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F9DB8D.686FCF33@jwz.org> References: <1106333362.3427.19.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> Message-ID: <20050128120336.21dad318.fedora@wir-sind-cool.org> On Thu, 27 Jan 2005 22:28:29 -0800, Jamie Zawinski wrote: > So then I tried Totem, and it suffers from the canonical Red Hat > braindamage of "oh, you haven't installed the mystery secret MP3 plugin, > and no, I won't even hint to you where to find it." Frankly, I can't be > bothered to go on this snark hunt again, I've done that enough times. Totem uses GStreamer, and hence gstreamer-plugins-mp3 from the same old http://rpm.livna.org repository works just fine. > So, I'd be thrilled to try out an alternative MP3 player to XMMS, just > as soon as someone can point me to one that actually plays MP3s! Amarok (KDE application) as provided in Fedora pre-Extras is quite nice, but needs kdemultimedia-extras as provided by rpm.livna.org before it would play mp3s. From pmatilai at welho.com Fri Jan 28 11:22:23 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 28 Jan 2005 13:22:23 +0200 (EET) Subject: redhat abe In-Reply-To: <1106908449.22312.242.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> Message-ID: On Fri, 28 Jan 2005, Ralf Corsepius wrote: > On Fri, 2005-01-28 at 11:58 +0200, Panu Matilainen wrote: > >> new repodata format) > IMO, this is more a matter of politics and willingness, but a technical > requirement. > > Technically, I don't see any need for apt to adopt yum's repodata > format. Politically, this requirement is introduced by RH not wanting to > add apt-repositories and fedora.us apparently being unable to set up > complete repositories. If apt-repositories are cleverly set up, the > additional overhead they introduce in addition to the original files > becomes more or less negligible. Sure, it can be viewed as politics/willingness or lack of thereof. I personally see the lack of repodata support in apt as an example of the standstill in apt's development which in turn hints that maybe it's time to move forward to something else :) > > BTW: Even SuSE is available with apt. I wonder why they don't have the > multilib issue - I guess they don't ship multilibs :) Apt has zero problems with mixing 32bit and 64bit packages IF the packages have different names. Suse packages their 32bit stuff for x86_64 with something like libfoo32bit names which circumvents the whole problem. Apt just can't sanely support packages having same name but different arch being simultaneously installed (+ a bunch of other misc related details) - Panu - From fedora at wir-sind-cool.org Fri Jan 28 11:30:43 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 28 Jan 2005 12:30:43 +0100 Subject: redhat abe In-Reply-To: <1106908449.22312.242.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> Message-ID: <20050128123043.3a60b213.fedora@wir-sind-cool.org> On Fri, 28 Jan 2005 11:34:09 +0100, Ralf Corsepius wrote: > Technically, I don't see any need for apt to adopt yum's repodata > format. Politically, this requirement is introduced by RH not wanting to > add apt-repositories and fedora.us apparently being unable to set up > complete repositories. Unless I'm misinformed, fedora.us even provides an apt-repository for pre-extras. What do you mean with "unable to set up complete repositories"? > If apt-repositories are cleverly set up, the > additional overhead they introduce in addition to the original files > becomes more or less negligible. From jwz at jwz.org Fri Jan 28 11:38:59 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Fri, 28 Jan 2005 03:38:59 -0800 Subject: grip being removed [Re: rawhide report: 20050120 changes] References: <20050128084221.42676.qmail@web8501.mail.in.yahoo.com> Message-ID: <41FA2453.4E6AEE37@jwz.org> Rahul Sundaram wrote: > > thats not a redhat stupidity. its patent issues over mp3 You know what? Trying to care; failing. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From rahulsundaram at yahoo.co.in Fri Jan 28 09:56:34 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Fri, 28 Jan 2005 01:56:34 -0800 (PST) Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050127173449.GD2545@nostromo.devel.redhat.com> Message-ID: <20050128095634.61208.qmail@web8509.mail.in.yahoo.com> Hi > You may be interested in totem as well. > > Bill > though totem is a media player, its generally thought of as a video player and many people install winamp to hear songs in windows instead of using windows media player for similar reasons. totem as a integrated all in one media player will not much acceptance from the users for many use cases ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 From dag at wieers.com Fri Jan 28 12:28:15 2005 From: dag at wieers.com (Dag Wieers) Date: Fri, 28 Jan 2005 13:28:15 +0100 (CET) Subject: redhat abe In-Reply-To: <1106908449.22312.242.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> Message-ID: On Fri, 28 Jan 2005, Ralf Corsepius wrote: > > new repodata format) > IMO, this is more a matter of politics and willingness, but a technical > requirement. > > Technically, I don't see any need for apt to adopt yum's repodata > format. Politically, this requirement is introduced by RH not wanting to > add apt-repositories and fedora.us apparently being unable to set up > complete repositories. If apt-repositories are cleverly set up, the > additional overhead they introduce in addition to the original files > becomes more or less negligible. Well, generating repositories demands a lot of a system. Generating 3 different repositories (apt, old-yum, new-yum) is really becoming an issue and prevents me from releasing updates flexibly. If I have to wait 30 to 45 minutes before I can starting syncing with a mirror, I delay that sometimes until the next time I'm online which could be 24h later. You have to know that I refuse to work with passphrase-less keys, so signing and syncing is an interactive step and requires my attention. > BTW: Even SuSE is available with apt. I wonder why they don't have the > multilib issue - I guess they don't ship multilibs :) Afaik, they rename the packages. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From rc040203 at freenet.de Fri Jan 28 12:31:01 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 28 Jan 2005 13:31:01 +0100 Subject: redhat abe In-Reply-To: <20050128123043.3a60b213.fedora@wir-sind-cool.org> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <20050128123043.3a60b213.fedora@wir-sind-cool.org> Message-ID: <1106915462.5389.15.camel@mccallum.corsepiu.local> On Fri, 2005-01-28 at 12:30 +0100, Michael Schwendt wrote: > On Fri, 28 Jan 2005 11:34:09 +0100, Ralf Corsepius wrote: > > > Technically, I don't see any need for apt to adopt yum's repodata > > format. Politically, this requirement is introduced by RH not wanting to > > add apt-repositories and fedora.us apparently being unable to set up > > complete repositories. > > Unless I'm misinformed, fedora.us even provides an apt-repository for > pre-extras. What do you mean with "unable to set up complete > repositories"? SRPMS apt-repositories are missing for pre-extras. This renders "apt-get source" and "apt-get build-dep" non-applicable to fedora.us hosted apt-repositories and therefore voids at least these aspects where apt is superior to yum. I had asked Warren Togami to add them on PM and he answered: "There is little good reason to do so. Trying to limit the size of that repository because many mirror administrators see it as redundant." This is not true, SRPMS apt-repositories are not redundant. Not having them implies loss of functionality to apt. As Fedora.US had supplied SRPMS apt-repositories for FC < 3, omitting them for pre-extras also means a regression in functionality of fedora.us having been introduced with the switch from FE2 to pre- extras/FE3. Ralf From alan at redhat.com Fri Jan 28 12:35:42 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 28 Jan 2005 07:35:42 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FA2453.4E6AEE37@jwz.org> References: <20050128084221.42676.qmail@web8501.mail.in.yahoo.com> <41FA2453.4E6AEE37@jwz.org> Message-ID: <20050128123542.GA29056@devserv.devel.redhat.com> On Fri, Jan 28, 2005 at 03:38:59AM -0800, Jamie Zawinski wrote: > Rahul Sundaram wrote: > > thats not a redhat stupidity. its patent issues over mp3 > > You know what? Trying to care; failing. Feel free to buy a patent license, or you could install Real who do have a patent license set and provide RealPlayer10 for Linux (www.real.com/linux) and which has used Gtk since the November RP10 release. That does do MP3. Alan From fedora at wir-sind-cool.org Fri Jan 28 12:47:56 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 28 Jan 2005 13:47:56 +0100 Subject: Apt at fedora.us (was: Re: redhat abe) In-Reply-To: <1106915462.5389.15.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <20050128123043.3a60b213.fedora@wir-sind-cool.org> <1106915462.5389.15.camel@mccallum.corsepiu.local> Message-ID: <20050128134756.70f3a4fb.fedora@wir-sind-cool.org> On Fri, 28 Jan 2005 13:31:01 +0100, Ralf Corsepius wrote: > > > Technically, I don't see any need for apt to adopt yum's repodata > > > format. Politically, this requirement is introduced by RH not wanting to > > > add apt-repositories and fedora.us apparently being unable to set up > > > complete repositories. > > > > Unless I'm misinformed, fedora.us even provides an apt-repository for > > pre-extras. What do you mean with "unable to set up complete > > repositories"? > SRPMS apt-repositories are missing for pre-extras. > > This renders "apt-get source" and "apt-get build-dep" non-applicable to > fedora.us hosted apt-repositories and therefore voids at least these > aspects where apt is superior to yum. > > I had asked Warren Togami to add them on PM and he answered: > "There is little good reason to do so. Trying to limit the size of that > repository because many mirror administrators see it as redundant." > > This is not true, SRPMS apt-repositories are not redundant. Not having > them implies loss of functionality to apt. Well, then I think the Apt community may need to prove him wrong and do some lobbying. If an Apt repository is provided, it ought to be complete. Making "apt-get source" fail is a repository bug, if not an act of sabotage. With many small changes in repository layout and location, we confuse the users and don't benefit from that. Pre-Extras started without Apt support, although the "apt" package is offered. Between FC1 and FC2, the fedora.us Yum repository locations changed. The suggestion to make the FC1 repository mirror the new layout in addition to its old layout, was ignored without comment. As a result, yum config example like provided at fedorafaq.org failed and had to be made distribution-specific, because $releasever could not be used in common config file for all supported distribution versions. This is bad. And the relocation to download.fedora.redhat.com is yet to come. Another change. Sigh. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rahulsundaram at yahoo.co.in Fri Jan 28 12:05:08 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Fri, 28 Jan 2005 04:05:08 -0800 (PST) Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FA2453.4E6AEE37@jwz.org> Message-ID: <20050128120508.2472.qmail@web8501.mail.in.yahoo.com> --- Jamie Zawinski wrote: > Rahul Sundaram wrote: > > > > thats not a redhat stupidity. its patent issues > over mp3 > > You know what? Trying to care; failing. > ok. you dont have to care but finding fault with redhat when there is none is a bad thing to do. how do you expect them to resolve the mp3 issue. you tell me ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From rc040203 at freenet.de Fri Jan 28 13:17:32 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 28 Jan 2005 14:17:32 +0100 Subject: redhat abe In-Reply-To: References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> Message-ID: <1106918252.5389.52.camel@mccallum.corsepiu.local> On Fri, 2005-01-28 at 13:28 +0100, Dag Wieers wrote: > On Fri, 28 Jan 2005, Ralf Corsepius wrote: > > > > new repodata format) > > IMO, this is more a matter of politics and willingness, but a technical > > requirement. > > > > Technically, I don't see any need for apt to adopt yum's repodata > > format. Politically, this requirement is introduced by RH not wanting to > > add apt-repositories and fedora.us apparently being unable to set up > > complete repositories. If apt-repositories are cleverly set up, the > > additional overhead they introduce in addition to the original files > > becomes more or less negligible. > > Well, generating repositories demands a lot of a system. Generating 3 > different repositories (apt, old-yum, new-yum) is really becoming an > issue and prevents me from releasing updates flexibly. If I have to wait > 30 to 45 minutes before I can starting syncing with a mirror, I delay that > sometimes until the next time I'm online which could be 24h later. Try aptate from apt4rpm (http://apt4rpm.sourceforge.net - Try the version from CVS-head, the released tarballs are troublesome) and feel free to ask me on PM in case of problems :-) > You have to know that I refuse to work with passphrase-less keys, so > signing and syncing is an interactive step and requires my attention. > > BTW: Even SuSE is available with apt. I wonder why they don't have the > > multilib issue - I guess they don't ship multilibs :) BTW: The repositories at ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE (semi official SuSE apt repositories) are built by aptate/apt4rpm. Ralf From jspaleta at gmail.com Fri Jan 28 13:20:59 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 28 Jan 2005 08:20:59 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F9DB8D.686FCF33@jwz.org> References: <1106333362.3427.19.camel@localhost.localdomain> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> Message-ID: <604aa791050128052019332617@mail.gmail.com> On Thu, 27 Jan 2005 22:28:29 -0800, Jamie Zawinski wrote: >1) The fact that it does not have a "double size" option is pretty > much a showstopper, because I can't read a damned thing on that > sub-postage-stamp-sized window. I Personally don't consider this a showstopper, but it would be interesting to know if the bmp developers have this feature or similar functionality on their development roadmap. > > 2) Perhaps I could fix this by wasting hours finding a less horrid > theme to use but A) in five minutes of clicking and googling, I > didn't see any easy-to-find collection of BMP themes, and > B) I'd really really rather claw out my eyes than dig through > those anyway. (Can someone recommend one that isn't totally > 'l33t and awful?) bmp's website has a menu entry for skins here's the url http://www.sosdg.org/~larne/w/Skins I think bmp is designed to use most if not all of the available xmms themes out there. So pick your fav xmms theme and drop it into bmp's Skins directory. And the 'default is crap' issue is a red herring, because "if" its going to be re-packaged for core, I'm sure the bluecurve xmms theme core is now using would be used for bmp... which works just fine for bmp from what i can tell. > > 3) and this may be related to "1: can't read the window", I couldn't > figure out how to play an Icecast stream at all. xmms has > "Play Location" on the menu, BMP does not. Perhaps if I could > read the window, the answer would be obvious, but I can't so it's > not. At the moment this is available functionality in the playlist window, as an 'add' option. We'd have to peek into bmp development discussions to see if there are plans and interest to place this functionality back into the > > 4) "BMP" is a monumentally stupid name (hey, let's name the MP3 > player "JPEG"!) and "beep-media-player" is both dumb and too much > typing. No Comment. -jef From Axel.Thimm at ATrpms.net Fri Jan 28 13:29:01 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 28 Jan 2005 14:29:01 +0100 Subject: redhat abe In-Reply-To: References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> Message-ID: <20050128132901.GG29714@neu.nirvana> On Fri, Jan 28, 2005 at 11:58:00AM +0200, Panu Matilainen wrote: > On Thu, 27 Jan 2005, Ralf Corsepius wrote: > >I know apt's code is ... ... leaves a lot to be desired, but it doesn't > >require that much effort to maintain the package. > > Maintaining the package ain't hard, but developing apt-rpm into > various directions required by FC (multilib, new repodata format) is > just about as fun as pulling teeth without anesthesia. The fun depends on whether you are the patient or the doctor ;) > The new repodata is something that would be sanely implementable > into apt, I think that's the least that needs to be done. As you say it is easily fixable, and also until then it can be taken care of server-side (where the question arises, what does the new repodata format really buy us other than being xml? I was under the impression that all depsolvers, rpm and deb and its cat were going to use it, turns out it's yum and up2date only). > multilib as used in FC and RHEL (namely packages with same nevr but > different arch simultaenously installed) is something that doesn't > fit nicely into it's design. And that's putting it somewhat > mildly. I've actually tried various approaches to adding multilib > support to apt with varying success, however none of work well > enough to be actually usable. There is a simple patch by the CERN folks used for ia64 by spliting apt's processing of i386 and ia64 into different package worlds (in apt-rpm's archives). Can that be used as for an initial multilib approach? apt's lack of multilib is a PITA, but you must also consider that apt's development community has only one member coming from the multilib world, the masochist sharing Panu's mail address ... ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rahulsundaram at yahoo.co.in Fri Jan 28 12:38:35 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Fri, 28 Jan 2005 04:38:35 -0800 (PST) Subject: redhat abe In-Reply-To: <1106915462.5389.15.camel@mccallum.corsepiu.local> Message-ID: <20050128123835.84606.qmail@web8506.mail.in.yahoo.com> Hi > > As Fedora.US had supplied SRPMS apt-repositories for > FC < 3, omitting > them for pre-extras also means a regression in > functionality of > fedora.us having been introduced with the switch > from FE2 to pre- > extras/FE3. > > Ralf > there is a reason its called *pre* extras ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 From fedora at wir-sind-cool.org Fri Jan 28 13:39:16 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 28 Jan 2005 14:39:16 +0100 Subject: BMP (was: Re: grip being removed [Re: rawhide report: 20050120 changes]) In-Reply-To: <604aa791050128052019332617@mail.gmail.com> References: <1106333362.3427.19.camel@localhost.localdomain> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <604aa791050128052019332617@mail.gmail.com> Message-ID: <20050128143916.5936f648.fedora@wir-sind-cool.org> On Fri, 28 Jan 2005 08:20:59 -0500, Jeff Spaleta wrote: > On Thu, 27 Jan 2005 22:28:29 -0800, Jamie Zawinski wrote: > >1) The fact that it does not have a "double size" option is pretty > > much a showstopper, because I can't read a damned thing on that > > sub-postage-stamp-sized window. > > I Personally don't consider this a showstopper, but it would be > interesting to know if the bmp developers have this feature or similar > functionality on their development roadmap. The Bluecurve-xmms theme as provided by redhat-artwork package improves readability a lot. When I click the 'D' button in BMP's display, the text "DOUBLESIZE HAS BEEN REMOVED" appears. From rc040203 at freenet.de Fri Jan 28 13:49:08 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 28 Jan 2005 14:49:08 +0100 Subject: redhat abe In-Reply-To: <20050128123835.84606.qmail@web8506.mail.in.yahoo.com> References: <20050128123835.84606.qmail@web8506.mail.in.yahoo.com> Message-ID: <1106920148.5389.56.camel@mccallum.corsepiu.local> On Fri, 2005-01-28 at 04:38 -0800, Rahul Sundaram wrote: > there is a reason its called *pre* extras Yes, identifying and fixing defects like this. Ralf From peter.backlund at home.se Fri Jan 28 13:56:22 2005 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 28 Jan 2005 14:56:22 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <604aa791050128052019332617@mail.gmail.com> References: <1106333362.3427.19.camel@localhost.localdomain> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <604aa791050128052019332617@mail.gmail.com> Message-ID: <1106920582.19595.101.camel@localhost.localdomain> fre 2005-01-28 klockan 08:20 -0500 skrev Jeff Spaleta: > On Thu, 27 Jan 2005 22:28:29 -0800, Jamie Zawinski wrote: > >1) The fact that it does not have a "double size" option is pretty > > much a showstopper, because I can't read a damned thing on that > > sub-postage-stamp-sized window. > > I Personally don't consider this a showstopper, but it would be > interesting to know if the bmp developers have this feature or similar > functionality on their development roadmap. Right-click the clock area, or click the down-arrow in the upper left corner of the player for a context menu. > > > > 2) Perhaps I could fix this by wasting hours finding a less horrid > > theme to use but A) in five minutes of clicking and googling, I > > didn't see any easy-to-find collection of BMP themes, and > > B) I'd really really rather claw out my eyes than dig through > > those anyway. (Can someone recommend one that isn't totally > > 'l33t and awful?) > > bmp's website has a menu entry for skins here's the url > http://www.sosdg.org/~larne/w/Skins > I think bmp is designed to use most if not all of the available xmms > themes out there. So pick your fav xmms theme and drop it into bmp's > Skins directory. And the 'default is crap' issue is a red herring, > because "if" its going to be re-packaged for core, I'm sure the > bluecurve xmms theme core is now using would be used for bmp... which > works just fine for bmp from what i can tell. Yes, it works fine with the Bluecurve xmms skin. There is an environment variable that lists additional directories to look for skins in, which conveniently contains /usr/share/xmms/Skins in the livna.org package (through an /etc/profile.d/ file), so that the BC skin can be used immediately. Same goes for the Industrial skin, from ximian- artwork. > > > > 3) and this may be related to "1: can't read the window", I couldn't > > figure out how to play an Icecast stream at all. xmms has > > "Play Location" on the menu, BMP does not. Perhaps if I could > > read the window, the answer would be obvious, but I can't so it's > > not. > > At the moment this is available functionality in the playlist window, > as an 'add' option. We'd have to peek into bmp development discussions > to see if there are plans and interest to place this functionality > back into the > > > > > 4) "BMP" is a monumentally stupid name (hey, let's name the MP3 > > player "JPEG"!) and "beep-media-player" is both dumb and too much > > typing. Well, if you run a reasonably modern shell such as bash or zsh, you could type "be" and then press tab to automatically complete to "beep- media-player". You may need to supply a few additional letters, if you have more than one binary in your $PATH beginning with "be". /Peter From buildsys at redhat.com Fri Jan 28 13:54:59 2005 From: buildsys at redhat.com (Build System) Date: Fri, 28 Jan 2005 08:54:59 -0500 Subject: rawhide report: 20050128 changes Message-ID: <200501281354.j0SDsxj03782@porkchop.devel.redhat.com> New package mcelog Tool to translate x86-64 CPU Machine Check Exception data. Updated Packages: bash-3.0-26 ----------- * Fri Jan 28 2005 Tim Waugh 3.0-26 - Fixed job handling bug (bug #145124). evolution-data-server-1.1.4.2-1 ------------------------------- * Thu Jan 27 2005 David Malcolm - 1.1.4.2-1 - Update from unstable 1.1.4.1 to unstable 1.1.1.4.2 gaim-1:1.1.2-2 -------------- * Fri Jan 28 2005 Florian La Roche - rebuild * Thu Jan 20 2005 Warren Togami 1:1.1.2-1 - 1.1.2 with more bugfixes * Tue Jan 18 2005 Chip Turner 1:1.1.1-3 - rebuild for new perl gdb-6.3.0.0-0.13 ---------------- * Thu Jan 27 2005 Jeff Johnston 6.3.0.0-0.13 - Fix to allow ia64 gdb to backtrace from syscalls in a corefile. - Bugzilla 145092. gnome-icon-theme-2.9.90-1 ------------------------- * Thu Jan 27 2005 Matthias Clasen - 2.9.90-1 - Update to 2.9.90 - Update icon caches in %post gnome-mag-0.11.13-1 ------------------- * Fri Jan 28 2005 Matthias Clasen 0.11.13-1 - Update to 0.11.13 gnome-mime-data-2.4.2-1 ----------------------- * Thu Jan 27 2005 Matthias Clasen - 2.4.2-1 - Update to 2.4.2 gnome-panel-2.8.1-9 ------------------- * Fri Jan 28 2005 Florian La Roche - rebuild * Thu Jan 27 2005 Jeremy Katz - 2.8.1-8 - really disable e-d-s support gnopernicus-0.10.0-1 -------------------- * Fri Jan 28 2005 Matthias Clasen 0.10.0-1 - Update to 0.10.0 gnumeric-1:1.4.2-1 ------------------ * Thu Jan 27 2005 Caolan McNamara 1.4.2-1 - bump to next version gok-0.12.1-1 ------------ * Fri Jan 28 2005 Matthias Clasen 0.12.1-1 - Update to 0.12.1 hal-0.4.7-2 ----------- * Thu Jan 27 2005 David Zeuthen 0.4.7-2 - Add patch that should close #146316 hicolor-icon-theme-0.5-1 ------------------------ * Thu Jan 27 2005 Matthias Clasen - 0.5-1 - Update to 0.5 kernel-2.6.10-1.1115_FC4 ------------------------ * Thu Jan 27 2005 Dave Jones - Drop VM hack that broke in yesterdays rebase. * Wed Jan 26 2005 Dave Jones - Drop 586-SMP kernels. These are a good candidate for fedora-extras when it appears. The number of people actually using this variant is likely to be very very small. - 2.6.11-rc2-bk4 ldapjdk-0:4.17-1jpp_2fc ----------------------- * Thu Jan 27 2005 Gary Benson 0:4.17-1jpp_2fc - Remove non-distributable files from the source tarball. * Fri Jan 21 2005 Gary Benson 0:4.17-1jpp_1fc - Build into Fedora. * Tue Nov 16 2004 Fernando Nasser 0:4.17-1jpp_1rh - Merge with upstream for upgrade libgnome-2.9.1-1 ---------------- * Thu Jan 27 2005 Matthias Clasen - 2.9.1-1 - Update to 2.9.1 * Thu Nov 04 2004 Dan Walsh - 2.8.0-3 - Stat gnome_user_private_dir before doing chmod, firefox gets - blown up because of this in strict selinux policy. * Mon Oct 18 2004 - 2.8.0-2 - change default browser to firefox libgnomeprint22-2.8.2-1 ----------------------- * Wed Jan 26 2005 Matthias Clasen - 2.8.2-1 - Update to 2.8.2 * Wed Nov 24 2004 Owen Taylor - 2.8.0-4 - Fix problem with Lain glyphs when subsetting some Asian fonts (#140010) libgnomeprintui22-2.8.2-1 ------------------------- * Thu Jan 27 2005 Matthias Clasen - 2.8.2-1 - Update to 2.8.2 libgnomeui-2.9.1-1 ------------------ * Thu Jan 27 2005 Matthias Clasen - 2.9.1-1 - Update to 2.9.1 - Drop upstreamed patches libgtop2-2.9.90-1 ----------------- * Thu Jan 27 2005 Matthias Clasen - 2.9.90-1 - Updaet to 2.9.90 lvm2-cluster-2.00.29-1.22.FC4 ----------------------------- * Thu Jan 27 2005 Florian La Roche - rebuild against current libs mutt-5:1.4.2.1-1 ---------------- * Thu Jan 27 2005 Bill Nottingham 5:1.4.2.1-1 - update to 1.4.2.1 (#141007, ) - include a /etc/Muttrc.local for site config (#123109) - add as a additional help key for terminals that use internally (#139277) ncurses-5.4-15 -------------- * Thu Jan 27 2005 Adrian Havill 5.4-15 - update to newest jumbo monthly patch + weeklies, fixing new line cursor move problem (#140326) * Thu Oct 21 2004 Adrian Havill 5.4-14 - escape rpm macros in the changelog (#135408) pcmcia-cs-3.2.8-4.5 ------------------- * Thu Jan 27 2005 Dave Jones - Update to upstream 3.2.8. policycoreutils-1.21.5-1 ------------------------ * Thu Jan 27 2005 Dan Walsh 1.21.5-1 - Upgrade to latest from NSA * Merged newrole -l support from Darrel Goeddel (TCS). - Fix genhomedircon STARTING_UID * Wed Jan 26 2005 Dan Walsh 1.21.4-1 - Upgrade to latest from NSA * Merged fixfiles patch for file_contexts.local from Dan Walsh. puretls-0.9-0.b4.1jpp_2fc ------------------------- * Wed Jan 26 2005 Florian La Roche 0.9-0.b4.1jpp_2fc - Remove additional "/" from perl path. rpmdb-fedora-1:4-0.20050128 --------------------------- selinux-policy-strict-1.21.4-2 ------------------------------ * Thu Jan 27 2005 Dan Walsh 1.21.4-2 - Fix handling of local.users file * Thu Jan 27 2005 Dan Walsh 1.21.4-1 - Update from NSA * Changed policy Makefile to still generate policy.18 as well, and use it for make load if the kernel doesn't support 19. * Merged enhanced MLS support from Darrel Goeddel (TCS). selinux-policy-targeted-1.21.4-2 -------------------------------- * Thu Jan 27 2005 Dan Walsh 1.21.4-2 - Fix handling of local.users file * Thu Jan 27 2005 Dan Walsh 1.21.4-1 - Update from NSA * Changed policy Makefile to still generate policy.18 as well, and use it for make load if the kernel doesn't support 19. * Merged enhanced MLS support from Darrel Goeddel (TCS). squirrelmail-1.4.4-1 -------------------- * Thu Jan 27 2005 Warren Togami 1.4.4-1 - 1.4.4 startup-notification-0.8-1 -------------------------- * Thu Jan 27 2005 Matthias Clasen 0.8-1 - Update to 0.8 usermode-1.78-1 --------------- * Thu Jan 27 2005 Jindrich Novy 1.78-1 - pam-panel-icon has popup menu to choose to forget/keep authentization by right clicking as usual for other panel applets (#75845) - fix race condition (#142254) vino-2.9.2-1 ------------ * Thu Jan 27 2005 Matthias Clasen 2.9.2-1 - Update to 2.9.2 xfce-utils-4.2.0-1 ------------------ * Thu Jan 27 2005 Than Ngo 4.2.0-1 - 4.2.0 xfdesktop-4.2.0-1 ----------------- * Thu Jan 27 2005 Than Ngo 4.2.0-1 - 4.2.0 xfwm4-4.2.0-1 ------------- * Thu Jan 27 2005 Than Ngo 4.2.0-1 - 4.2.0 * Mon Jul 19 2004 Than Ngo 4.0.6-1 - update to 4.0.6 - use %find_lang macros * Tue Jun 15 2004 Elliot Lee - rebuilt xorg-x11-6.8.1.902-7 -------------------- * Thu Jan 27 2005 Mike A. Harris 6.8.1.902-7 - Renamed build_maintainer macro to build_mharris as it is actually a personal macro and there are actually several developers maintaining the rpm for quite some time now. In case anyone is curious, I use it to tweak the spec file on occasion to build on a customized OS install that does not quite match any of our supported OS configurations. ;o) - Added a %check section to the spec file, to put post build/install sanity checks in place. - Added new post-build sanity check "with_undef_sym_test", did a local test build to confirm it works correctly, fixed a few things, then disabled it by default because Xorg needs a lot of love in order for this to be default. * Wed Jan 26 2005 Mike A. Harris 6.8.1.902-6 - Added xorg-x11-6.8.1.902-lnxLib-tmpl-sharedlibreq-fixes.patch to fix many missing library dependancies in lnxLib.tmpl, detected by examining the build log of a "with_bail_on_undef_syms" build. - Disabled with_bail_on_undef_syms, after determining that there is a bit of work that needs to be done upstream first in order for us to expect X to fully build with these linker options. * Mon Jan 24 2005 Mike A. Harris 6.8.1.902-5 - Removed dead unused i810 update patch. - Enabled with_bail_on_undef_syms, to do a test build. From skvidal at phy.duke.edu Fri Jan 28 14:02:37 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 28 Jan 2005 09:02:37 -0500 Subject: redhat abe In-Reply-To: <20050128132901.GG29714@neu.nirvana> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <20050128132901.GG29714@neu.nirvana> Message-ID: <1106920957.3607.33.camel@cutter> > I think that's the least that needs to be done. As you say it is > easily fixable, and also until then it can be taken care of > server-side (where the question arises, what does the new repodata > format really buy us other than being xml? I was under the impression > that all depsolvers, rpm and deb and its cat were going to use it, > turns out it's yum and up2date only). Do you think that's the way I wanted it? no.The point of the metadata format was to remove the duplicate implementations of the same data. But sometimes you end up that not everyone wants to do any work to implement the functionality in their program. What more can be done to convince them to do that? So it's not a failing of the format, not as far as I've been told. -sv From cmadams at hiwaay.net Fri Jan 28 14:25:32 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 28 Jan 2005 08:25:32 -0600 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> Message-ID: <20050128142531.GA553227@hiwaay.net> Once upon a time, Rahul Sundaram said: > I do. Fedora core should only include one default > program for each kind of task overall. there might be > a few exceptions like including say nano as well as > vim but having 5 different browsers and calling in > fedora "core" doesnt make any sense at all The #1 objective of Fedora Core is "Create a complete general-purpose operating system with capabilities equivalent to competing operating systems". There is _nothing_ in the objectives about providing a minimal OS that pushes all the optional packages to Fedora Extras. It seems that a lot is being read into the word "Core" in the distribution that is not meant (at least according to the Fedora website). It also seems that some people want to push every package they don't personally use 20 times a day to Extras, despite the fact that many others use those packages and that there are not always good alternatives in the distribution. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From harald at redhat.com Fri Jan 28 14:27:25 2005 From: harald at redhat.com (Harald Hoyer) Date: Fri, 28 Jan 2005 15:27:25 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F9A7C5.6050200@tlarson.com> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> Message-ID: <41FA4BCD.5000407@redhat.com> Tyler Larson wrote: > Except, of course, the gnome open-file dialog box. Makes me angry every > time I see it. Grrr. I would like to start a flame war because of this *grins evil* , but this has been discussed enough internal and external. From dag at wieers.com Fri Jan 28 15:02:14 2005 From: dag at wieers.com (Dag Wieers) Date: Fri, 28 Jan 2005 16:02:14 +0100 (CET) Subject: redhat abe In-Reply-To: <1106920957.3607.33.camel@cutter> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <20050128132901.GG29714@neu.nirvana> <1106920957.3607.33.camel@cutter> Message-ID: On Fri, 28 Jan 2005, seth vidal wrote: > > I think that's the least that needs to be done. As you say it is > > easily fixable, and also until then it can be taken care of > > server-side (where the question arises, what does the new repodata > > format really buy us other than being xml? I was under the impression > > that all depsolvers, rpm and deb and its cat were going to use it, > > turns out it's yum and up2date only). > > Do you think that's the way I wanted it? no.The point of the metadata > format was to remove the duplicate implementations of the same data. But > sometimes you end up that not everyone wants to do any work to implement > the functionality in their program. What more can be done to convince > them to do that? > > So it's not a failing of the format, not as far as I've been told. Only apt is not using the new metadata format, so all-in-all it has been very succesful. My only concern is that older distributions have been ignored. (yum 2.0, apt and up2date) And even when apt is fixed, I still need to carry old-yum style metadata support (even though yum-arch is complaining and failing to understand that it is *NOT* obsolete) as long as we have yum 2.0 and up2date around in its current form on RHEL, RH, FC1 and FC2. (everything except FC3 :)) Fixing createrepo to provide old-yum metadata would be an acceptable workaround from the repository maintainer POV. Trying to get rid of repository maintainers is an alternative too :) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From fedora at wir-sind-cool.org Fri Jan 28 15:01:59 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 28 Jan 2005 16:01:59 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106920582.19595.101.camel@localhost.localdomain> References: <1106333362.3427.19.camel@localhost.localdomain> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <604aa791050128052019332617@mail.gmail.com> <1106920582.19595.101.camel@localhost.localdomain> Message-ID: <20050128160159.277368cc.fedora@wir-sind-cool.org> On Fri, 28 Jan 2005 14:56:22 +0100, Peter Backlund wrote: > Yes, it works fine with the Bluecurve xmms skin. There is an environment > variable that lists additional directories to look for skins in, which > conveniently contains /usr/share/xmms/Skins in the livna.org package > (through an /etc/profile.d/ file), so that the BC skin can be used > immediately. Same goes for the Industrial skin, from ximian- > artwork. Would be good if something like this could be added to the profile.d: skin=$(gconftool-2 --get /apps/bmp/skin 2> /dev/null) if [ -z "$skin" -a -f /usr/share/xmms/Skins/Bluecurve-xmms.zip ]; then gconftool-2 --set /apps/bmp/skin --type string \ /usr/share/xmms/Skins/Bluecurve-xmms.zip &> /dev/null fi What it does is to make the Bluecurve skin the default if user has not set a different one already. From dag at wieers.com Fri Jan 28 15:12:41 2005 From: dag at wieers.com (Dag Wieers) Date: Fri, 28 Jan 2005 16:12:41 +0100 (CET) Subject: redhat abe In-Reply-To: <1106918252.5389.52.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <1106918252.5389.52.camel@mccallum.corsepiu.local> Message-ID: On Fri, 28 Jan 2005, Ralf Corsepius wrote: > On Fri, 2005-01-28 at 13:28 +0100, Dag Wieers wrote: > > On Fri, 28 Jan 2005, Ralf Corsepius wrote: > > > > > Technically, I don't see any need for apt to adopt yum's repodata > > > format. Politically, this requirement is introduced by RH not wanting to > > > add apt-repositories and fedora.us apparently being unable to set up > > > complete repositories. If apt-repositories are cleverly set up, the > > > additional overhead they introduce in addition to the original files > > > becomes more or less negligible. > > > > Well, generating repositories demands a lot of a system. Generating 3 > > different repositories (apt, old-yum, new-yum) is really becoming an > > issue and prevents me from releasing updates flexibly. If I have to wait > > 30 to 45 minutes before I can starting syncing with a mirror, I delay that > > sometimes until the next time I'm online which could be 24h later. > > Try aptate from apt4rpm (http://apt4rpm.sourceforge.net - Try the > version from CVS-head, the released tarballs are troublesome) and feel > free to ask me on PM in case of problems :-) Afaics, aptate just calls genbasedir, yum-arch or createrepo. Each of them largely doing the same thing and reading 14GB worth of packages. What I need is either reduce the number of metadata formats that I support (client-side support) or a much more efficient way of generating the metadata in a single run. (incrementally update metadata could work too) -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From eli.carter at inet.com Fri Jan 28 15:19:26 2005 From: eli.carter at inet.com (Eli Carter) Date: Fri, 28 Jan 2005 09:19:26 -0600 Subject: redhat abe In-Reply-To: <1106915462.5389.15.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <20050128123043.3a60b213.fedora@wir-sind-cool.org> <1106915462.5389.15.camel@mccallum.corsepiu.local> Message-ID: <41FA57FE.2080500@inet.com> Ralf Corsepius wrote: > SRPMS apt-repositories are missing for pre-extras. > > This renders "apt-get source" and "apt-get build-dep" non-applicable to > fedora.us hosted apt-repositories and therefore voids at least these > aspects where apt is superior to yum. > > I had asked Warren Togami to add them on PM and he answered: > "There is little good reason to do so. Trying to limit the size of that > repository because many mirror administrators see it as redundant." > > This is not true, SRPMS apt-repositories are not redundant. Not having > them implies loss of functionality to apt. And having them makes it a _lot_ easier to grab a package, fix something, build it, test it, then post a bug report w/patch. SRPMS repositories _are_ important. Eli --------------------. "If it ain't broke now, Eli Carter \ it will be soon." -- crypto-gram eli.carter(a)inet.com `------------------------------------------------- ------------------------------------------------------------------------ Confidentiality Notice: This e-mail transmission may contain confidential and/or privileged information that is intended only for the individual or entity named in the e-mail address. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or reliance upon the contents of this e-mail message is strictly prohibited. If you have received this e-mail transmission in error, please reply to the sender, so that proper delivery can be arranged, and please delete the message from your computer. Thank you. Tektronix Texas, LLC formerly Inet Technologies, Inc. ------------------------------------------------------------------------ From dag at wieers.com Fri Jan 28 15:29:20 2005 From: dag at wieers.com (Dag Wieers) Date: Fri, 28 Jan 2005 16:29:20 +0100 (CET) Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050128142531.GA553227@hiwaay.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> Message-ID: On Fri, 28 Jan 2005, Chris Adams wrote: > Once upon a time, Rahul Sundaram said: > > I do. Fedora core should only include one default > > program for each kind of task overall. there might be > > a few exceptions like including say nano as well as > > vim but having 5 different browsers and calling in > > fedora "core" doesnt make any sense at all > > The #1 objective of Fedora Core is "Create a complete general-purpose > operating system with capabilities equivalent to competing operating > systems". There is _nothing_ in the objectives about providing a > minimal OS that pushes all the optional packages to Fedora Extras. > > It seems that a lot is being read into the word "Core" in the > distribution that is not meant (at least according to the Fedora > website). > > It also seems that some people want to push every package they don't > personally use 20 times a day to Extras, despite the fact that many > others use those packages and that there are not always good > alternatives in the distribution. To me the core of the argument of moving things to Extras is all about responsibility and flexibility to allow outsiders to fix things. Everything inside Core is Red Hat's responsibility and moving things to Extras eases much of the overhead Red Hat has in maintaining Core. The more resources that can help out, leaves Red Hat with extra resources they can spend on something else. Which accelerates Fedora and RHEL and helps out Linux in general. You can see it as a cost-cutting operation. BTW I'm sure everything being removed from Core will exist in Extras when FC4 hits the mirrors, there's no need in predicting it will not. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From ghenry at suretecsystems.com Fri Jan 28 15:27:44 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Fri, 28 Jan 2005 15:27:44 -0000 (GMT) Subject: Our Discussion on Fedora-docs [Fwd: Re: Fedora Documentation Search Engine] Message-ID: <42853.193.195.148.66.1106926064.squirrel@webmail.suretecsystems.com> Dear all, I thought that maybe you guys would have some input on this? Gavin. ---------------------------- Original Message ---------------------------- Subject: Re: Fedora Documentation Search Engine From: "Stuart Ellis" Date: Fri, January 28, 2005 3:24 pm To: "For participants of the docs project" -------------------------------------------------------------------------- On Fri, 28 Jan 2005 14:39:32 -0000 (GMT), "Gavin Henry" said: > > > > > On Fri, 28 Jan 2005 12:56:58 -0000 (GMT), "Gavin Henry" > > said: > >> Dear all, > >> > >> Has there been any discussion about this? > >> > >> I thinking along the lines of htdig/swish-e that indexes all man pages/howto/README after every rpm is installed. > >> > >> Something like a post entry in the spec file, or similar. > > > > I haven't seen any on this list, but essentially this is a function of having a desktop search/indexing engine since there isn't a common format to this stuff. The next release of yelp (GNOME help browser) will display info and man pages, but can't index the random txt, html, pdf etc. that goes into /usr/share/doc/. > > We heavily use Swish-e (www.swish-e.org) for the fileservers we install. This can handle html, xhtml, txt, pdf and the like. I've just looked at the page now, but it looks like a very useful bit of software. > Maybe something like this or a updatedocdb crontab, like slocate has and we just put the standard doc pathnames in a config file. The customize the > web search page. > My understanding is that this is where things become quite technical and problematic. There is always a disjunct between what's actually on the disk and what is listed in the index. On portable computers it's harder to guarantee that batch indexing jobs will be completed regularly as well. Beagle and Spotlight use kernel hooks to update the index as changes occur. I suppose that RPM packages could run post-install scripts that update a document registry (kind of like you suggested) would be a relatively non-invasive way to implement something. I definitely think that the default start page of the Web browser could be used very effectively by the docs project. The details of implementing an index might be a good question for fedora-devel. -- Stuart Ellis s.ellis at fastmail.co.uk -- fedora-docs-list mailing list fedora-docs-list at redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-docs-list From rahulsundaram at yahoo.co.in Fri Jan 28 14:30:23 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Fri, 28 Jan 2005 06:30:23 -0800 (PST) Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050128142531.GA553227@hiwaay.net> Message-ID: <20050128143023.42919.qmail@web8509.mail.in.yahoo.com> Hi > > It seems that a lot is being read into the word > "Core" in the > distribution that is not meant (at least according > to the Fedora > website). there are goals that are stated and then there are policies and objectives to be made more explicit and maybe even redefined. the fact that fedora core doesnt have any stated goal to provide only defaults has already been discussed before > > It also seems that some people want to push every > package they don't > personally use 20 times a day to Extras, despite the > fact that many > others use those packages and that there are not > always good > alternatives in the distribution. you seem to be assuming that I am pushing for changes to fedora core on packages that I dont personally use. You couldnt be more wrong. moving packages into extras doesnt prevent anyone from using it. that has been stated innumerous times before too ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From rc040203 at freenet.de Fri Jan 28 15:30:42 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 28 Jan 2005 16:30:42 +0100 Subject: redhat abe In-Reply-To: References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <1106918252.5389.52.camel@mccallum.corsepiu.local> Message-ID: <1106926242.5389.96.camel@mccallum.corsepiu.local> On Fri, 2005-01-28 at 16:12 +0100, Dag Wieers wrote: > On Fri, 28 Jan 2005, Ralf Corsepius wrote: > > > On Fri, 2005-01-28 at 13:28 +0100, Dag Wieers wrote: > > > On Fri, 28 Jan 2005, Ralf Corsepius wrote: > > > > > > > Technically, I don't see any need for apt to adopt yum's repodata > > > > format. Politically, this requirement is introduced by RH not wanting to > > > > add apt-repositories and fedora.us apparently being unable to set up > > > > complete repositories. If apt-repositories are cleverly set up, the > > > > additional overhead they introduce in addition to the original files > > > > becomes more or less negligible. > > > > > > Well, generating repositories demands a lot of a system. Generating 3 > > > different repositories (apt, old-yum, new-yum) is really becoming an > > > issue and prevents me from releasing updates flexibly. If I have to wait > > > 30 to 45 minutes before I can starting syncing with a mirror, I delay that > > > sometimes until the next time I'm online which could be 24h later. > > > > Try aptate from apt4rpm (http://apt4rpm.sourceforge.net - Try the > > version from CVS-head, the released tarballs are troublesome) and feel > > free to ask me on PM in case of problems :-) > > Afaics, aptate just calls genbasedir, yum-arch or createrepo. Each of them > largely doing the same thing and reading 14GB worth of packages. Not quite. aptate uses a cache to check for which rpms have been added to a repository since the last time it has been run, and then incrementally builds the apt-repositories. Give it a try, initially building the repositories (setting up the cache) takes a lot of time, but updating repositories, after a couple of packages have been added to it is fast. As far as yum is concerned, you are right. yum repositories are re-built instead of being incrementally built, however even they are only built if a package had been added or removed from the repository. I am using it to build local apt repositories of external ftp sites, which do not provide apt repositories. BTW: the GWDG site is several x 10GB in size. They apply a similar procedure as I do. Nightly cron jobs rsync'ing from extern, and running aptate in the end to add the changes. Ralf From pmatilai at welho.com Fri Jan 28 15:33:25 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 28 Jan 2005 17:33:25 +0200 (EET) Subject: redhat abe In-Reply-To: <20050128132901.GG29714@neu.nirvana> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <20050128132901.GG29714@neu.nirvana> Message-ID: On Fri, 28 Jan 2005, Axel Thimm wrote: >> The new repodata is something that would be sanely implementable >> into apt, > > I think that's the least that needs to be done. As you say it is > easily fixable, and also until then it can be taken care of I wouldn't say "easily", but it does fit into apt's design. > server-side (where the question arises, what does the new repodata > format really buy us other than being xml? I was under the impression > that all depsolvers, rpm and deb and its cat were going to use it, > turns out it's yum and up2date only). ..and so does smartpm, dunno about red-carpet and all the gazillion other depsolvers out there. > >> multilib as used in FC and RHEL (namely packages with same nevr but >> different arch simultaenously installed) is something that doesn't >> fit nicely into it's design. And that's putting it somewhat >> mildly. I've actually tried various approaches to adding multilib >> support to apt with varying success, however none of work well >> enough to be actually usable. > > There is a simple patch by the CERN folks used for ia64 by spliting > apt's processing of i386 and ia64 into different package worlds (in > apt-rpm's archives). Can that be used as for an initial multilib > approach? Ugh, no thanks. Feel free to patch your version of apt with it, but from my POV it's just too ugly to live with. > > apt's lack of multilib is a PITA, but you must also consider that > apt's development community has only one member coming from the > multilib world, the masochist sharing Panu's mail address ... ;) ...and even I'm not really from "multilib world" since I don't have x86_64 boxes at home. My next system is going to be that but whether it happens this year, next year or the one after that I dunno :) - Panu - From elanthis at awesomeplay.com Fri Jan 28 15:44:08 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 28 Jan 2005 10:44:08 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050128142531.GA553227@hiwaay.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> Message-ID: <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2005-01-28 at 08:25 -0600, Chris Adams wrote: > Once upon a time, Rahul Sundaram said: > > I do. Fedora core should only include one default > > program for each kind of task overall. there might be > > a few exceptions like including say nano as well as > > vim but having 5 different browsers and calling in > > fedora "core" doesnt make any sense at all > > The #1 objective of Fedora Core is "Create a complete general-purpose > operating system with capabilities equivalent to competing operating > systems". There is _nothing_ in the objectives about providing a > minimal OS that pushes all the optional packages to Fedora Extras. Right. "Operating System." XMMS is not part of an OS, it's an application that nobody strictly needs. You don't need to put XMMS in Fedora Core in order for Core to use or run XMMS, and its removal will not reduce Core's audio capabilities in the least. > > It seems that a lot is being read into the word "Core" in the > distribution that is not meant (at least according to the Fedora > website). > > It also seems that some people want to push every package they don't > personally use 20 times a day to Extras, despite the fact that many > others use those packages and that there are not always good > alternatives in the distribution. Quite a few of us would like to see software we do personally use pushed to Extras. I use Epiphany over Firefox, for example, but if Firefox is the official Fedora Browser, then I want Epiphany in Extras. That would in no way stop me from using Epiphany, since I could just install it from Extras. The impact on my life by moving Epiphany is essentially nil, but it does result in a smaller, leaner, easier to manage, faster to download _Operating System_ for others. > > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > From harald at redhat.com Fri Jan 28 15:52:11 2005 From: harald at redhat.com (Harald Hoyer) Date: Fri, 28 Jan 2005 16:52:11 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <41FA5FAB.1090602@redhat.com> Sean Middleditch wrote: > Right. "Operating System." XMMS is not part of an OS, it's an > application that nobody strictly needs. You don't need to put XMMS in > Fedora Core in order for Core to use or run XMMS, and its removal will > not reduce Core's audio capabilities in the least. hmm, OS... let's deliver the kernel only, the rest is just bloat :) From elanthis at awesomeplay.com Fri Jan 28 15:56:22 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 28 Jan 2005 10:56:22 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FA5FAB.1090602@redhat.com> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <41FA5FAB.1090602@redhat.com> Message-ID: <1106927782.14323.1.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2005-01-28 at 16:52 +0100, Harald Hoyer wrote: > Sean Middleditch wrote: > > Right. "Operating System." XMMS is not part of an OS, it's an > > application that nobody strictly needs. You don't need to put XMMS in > > Fedora Core in order for Core to use or run XMMS, and its removal will > > not reduce Core's audio capabilities in the least. > > hmm, OS... let's deliver the kernel only, the rest is just bloat :) Sounds like a plan. Though maybe we should throw in the boot loader, too. I think those together plus the initial ramdisk should be enough for most Linux users. They can grab auxillary things like binutils and rpm from Extras. ~_^ Manual system bootstrapping is k00l. > From Axel.Thimm at ATrpms.net Fri Jan 28 15:56:10 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 28 Jan 2005 16:56:10 +0100 Subject: redhat abe In-Reply-To: References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <20050128132901.GG29714@neu.nirvana> Message-ID: <20050128155610.GD3741@neu.nirvana> On Fri, Jan 28, 2005 at 05:33:25PM +0200, Panu Matilainen wrote: > >There is a simple patch by the CERN folks used for ia64 by spliting > >apt's processing of i386 and ia64 into different package worlds (in > >apt-rpm's archives). Can that be used as for an initial multilib > >approach? > > Ugh, no thanks. Feel free to patch your version of apt with it, but from > my POV it's just too ugly to live with. Well, uglyness is the essence of coding. ;) But, seriously, would that patch do its job and get apt up to multilib? > >apt's lack of multilib is a PITA, but you must also consider that > >apt's development community has only one member coming from the > >multilib world, the masochist sharing Panu's mail address ... ;) > > ...and even I'm not really from "multilib world" since I don't have x86_64 > boxes at home. My next system is going to be that but whether it happens > this year, next year or the one after that I dunno :) OK, then apt has no developer that could look after multilib support. No wonder that it is still not there (and will probably never make it). It's a catch22 (FC does not support apt, because apt has no multilib, and apt has no multilib, because FC has no (multilib) developers assigned to it :) Thankfully yum and smart are growing fast enough to fill the gap in 64bit world. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora-devel at tlarson.com Fri Jan 28 16:00:22 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Fri, 28 Jan 2005 09:00:22 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106927782.14323.1.camel@support02.civic.twp.ypsilanti.mi.us> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <41FA5FAB.1090602@redhat.com> <1106927782.14323.1.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <41FA6196.10701@tlarson.com> Sean Middleditch wrote: > On Fri, 2005-01-28 at 16:52 +0100, Harald Hoyer wrote: > >>Sean Middleditch wrote: >> >>>Right. "Operating System." XMMS is not part of an OS, it's an >>>application that nobody strictly needs. You don't need to put XMMS in >>>Fedora Core in order for Core to use or run XMMS, and its removal will >>>not reduce Core's audio capabilities in the least. >> >>hmm, OS... let's deliver the kernel only, the rest is just bloat :) > > > Sounds like a plan. Though maybe we should throw in the boot loader, > too. I think those together plus the initial ramdisk should be enough > for most Linux users. They can grab auxillary things like binutils and > rpm from Extras. ~_^ > > Manual system bootstrapping is k00l. > Yeah, I've used that distro. Called somthing like Gen^2 if my memory serves me. From harald at redhat.com Fri Jan 28 16:04:58 2005 From: harald at redhat.com (Harald Hoyer) Date: Fri, 28 Jan 2005 17:04:58 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106927782.14323.1.camel@support02.civic.twp.ypsilanti.mi.us> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <41FA5FAB.1090602@redhat.com> <1106927782.14323.1.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <41FA62AA.6080404@redhat.com> Sean Middleditch wrote: > On Fri, 2005-01-28 at 16:52 +0100, Harald Hoyer wrote: > >>Sean Middleditch wrote: >> >>>Right. "Operating System." XMMS is not part of an OS, it's an >>>application that nobody strictly needs. You don't need to put XMMS in >>>Fedora Core in order for Core to use or run XMMS, and its removal will >>>not reduce Core's audio capabilities in the least. >> >>hmm, OS... let's deliver the kernel only, the rest is just bloat :) > > > Sounds like a plan. Though maybe we should throw in the boot loader, > too. I think those together plus the initial ramdisk should be enough > for most Linux users. They can grab auxillary things like binutils and > rpm from Extras. ~_^ > > Manual system bootstrapping is k00l. Bootloader? Think "boot disk"! :) From elanthis at awesomeplay.com Fri Jan 28 16:08:50 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 28 Jan 2005 11:08:50 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FA62AA.6080404@redhat.com> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <41FA5FAB.1090602@redhat.com> <1106927782.14323.1.camel@support02.civic.twp.ypsilanti.mi.us> <41FA62AA.6080404@redhat.com> Message-ID: <1106928530.14323.4.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2005-01-28 at 17:04 +0100, Harald Hoyer wrote: > Bootloader? Think "boot disk"! :) The PPC users might have an issue with that. ;-) From harald at redhat.com Fri Jan 28 16:15:45 2005 From: harald at redhat.com (Harald Hoyer) Date: Fri, 28 Jan 2005 17:15:45 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106928530.14323.4.camel@support02.civic.twp.ypsilanti.mi.us> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <41FA5FAB.1090602@redhat.com> <1106927782.14323.1.camel@support02.civic.twp.ypsilanti.mi.us> <41FA62AA.6080404@redhat.com> <1106928530.14323.4.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <41FA6531.8070102@redhat.com> Sean Middleditch wrote: > On Fri, 2005-01-28 at 17:04 +0100, Harald Hoyer wrote: > >>Bootloader? Think "boot disk"! :) > > > The PPC users might have an issue with that. ;-) PPC? Bloat! :-) From ivg2 at cornell.edu Fri Jan 28 16:17:18 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 09:17:18 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <1106929038.26304.17.camel@cobra.ivg2.net> > Quite a few of us would like to see software we do personally use pushed > to Extras. Hi, I haven't been following this discussion, but I'd like to say that I don't want to see software I use pushed to extras due to the fact that Extras is not sync-ed to Rawhide. I am a rawhide beta tester, and extras is a pain for me to use. Do you know what kind of hackery is required to get the Nvidia driver from livna properly installed on a rawhide system? That's because Livna, like extras, is not sync-ed to rawhide. I'd like to see a rawhide-tracking extras, and I've asked this question before. I was explained that there are no resources for it. Until resources are found I suggest this be taken into account. By the way, that also implies you will get no testing for extras packages, leading to more bugs not being discovered until release. > I use Epiphany over Firefox, for example, but if Firefox is > the official Fedora Browser, then I want Epiphany in Extras. That would > in no way stop me from using Epiphany, since I could just install it > from Extras. The impact on my life by moving Epiphany is essentially > nil, but it does result in a smaller, leaner, easier to manage, faster > to download _Operating System_ for others. Personally I don't get this whole "move to extras" thing. I assume it has something to do with fitting on fewer CDs, but I don't really care since I never install from CD. P.S. Speaking of the Nvidia driver, will somebody please consider splitting xorg-x11-Mesa-libGL-devel and xorg-x11-Mesa-libGLU-devel in their own packages where they belong. I tried discussing this with the maintainer, but he disappeared in the middle of the discussion and the bug was left unresolved, pending FC4, which makes no sense to me. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145287 -- Ivan Gyurdiev Cornell University From pmatilai at welho.com Fri Jan 28 16:17:27 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Fri, 28 Jan 2005 18:17:27 +0200 (EET) Subject: redhat abe In-Reply-To: <20050128155610.GD3741@neu.nirvana> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <20050128132901.GG29714@neu.nirvana> <20050128155610.GD3741@neu.nirvana> Message-ID: On Fri, 28 Jan 2005, Axel Thimm wrote: > On Fri, Jan 28, 2005 at 05:33:25PM +0200, Panu Matilainen wrote: >>> There is a simple patch by the CERN folks used for ia64 by spliting >>> apt's processing of i386 and ia64 into different package worlds (in >>> apt-rpm's archives). Can that be used as for an initial multilib >>> approach? >> >> Ugh, no thanks. Feel free to patch your version of apt with it, but from >> my POV it's just too ugly to live with. > > Well, uglyness is the essence of coding. ;) > > But, seriously, would that patch do its job and get apt up to multilib? Not IMHO. It's just an ugly workaround to hide 32bit packages from apt making apt rather useless in many ways. I rather have no multilib than a totally broken support for it. The might work for somebodys purposes but not mine :) > >>> apt's lack of multilib is a PITA, but you must also consider that >>> apt's development community has only one member coming from the >>> multilib world, the masochist sharing Panu's mail address ... ;) >> >> ...and even I'm not really from "multilib world" since I don't have x86_64 >> boxes at home. My next system is going to be that but whether it happens >> this year, next year or the one after that I dunno :) > > OK, then apt has no developer that could look after multilib > support. No wonder that it is still not there (and will probably never > make it). It's a catch22 (FC does not support apt, because apt has no > multilib, and apt has no multilib, because FC has no (multilib) > developers assigned to it :) Indeed... :-/ > Thankfully yum and smart are growing fast enough to fill the gap in > 64bit world. ..and both are implemented in a sane language which people can actually understand, unlike C++ :) - Panu - From elanthis at awesomeplay.com Fri Jan 28 16:20:22 2005 From: elanthis at awesomeplay.com (Sean Middleditch) Date: Fri, 28 Jan 2005 11:20:22 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FA6531.8070102@redhat.com> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <41FA5FAB.1090602@redhat.com> <1106927782.14323.1.camel@support02.civic.twp.ypsilanti.mi.us> <41FA62AA.6080404@redhat.com> <1106928530.14323.4.camel@support02.civic.twp.ypsilanti.mi.us> <41FA6531.8070102@redhat.com> Message-ID: <1106929223.14323.8.camel@support02.civic.twp.ypsilanti.mi.us> On Fri, 2005-01-28 at 17:15 +0100, Harald Hoyer wrote: > Sean Middleditch wrote: > > On Fri, 2005-01-28 at 17:04 +0100, Harald Hoyer wrote: > > > >>Bootloader? Think "boot disk"! :) > > > > > > The PPC users might have an issue with that. ;-) > > PPC? Bloat! :-) Hmm, good point. You know, now that I think on it, the kernel itself is pretty big. Got a lot of them drivers in it. Nobody needs all of 'em. I say we compile all drivers as modules and put them all in Extras, too. Then we should be able to ship Fedora Core on a 5,1/4" floppy. (This joke is getting stale, isn't it? ~_^ ) > From harald at redhat.com Fri Jan 28 16:23:38 2005 From: harald at redhat.com (Harald Hoyer) Date: Fri, 28 Jan 2005 17:23:38 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106929223.14323.8.camel@support02.civic.twp.ypsilanti.mi.us> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <41FA5FAB.1090602@redhat.com> <1106927782.14323.1.camel@support02.civic.twp.ypsilanti.mi.us> <41FA62AA.6080404@redhat.com> <1106928530.14323.4.camel@support02.civic.twp.ypsilanti.mi.us> <41FA6531.8070102@redhat.com> <1106929223.14323.8.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <41FA670A.4050307@redhat.com> Sean Middleditch wrote: > Hmm, good point. You know, now that I think on it, the kernel itself is > pretty big. Got a lot of them drivers in it. Nobody needs all of 'em. > I say we compile all drivers as modules and put them all in Extras, too. > > Then we should be able to ship Fedora Core on a 5,1/4" floppy. > > (This joke is getting stale, isn't it? ~_^ ) Fedora Hardcore? :-D From peter.backlund at home.se Fri Jan 28 16:35:41 2005 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 28 Jan 2005 17:35:41 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106929038.26304.17.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> Message-ID: <1106930141.19595.109.camel@localhost.localdomain> fre 2005-01-28 klockan 09:17 -0700 skrev Ivan Gyurdiev: > > Quite a few of us would like to see software we do personally use pushed > > to Extras. > > Hi, I haven't been following this discussion, but I'd like to say that > I don't want to see software I use pushed to extras due to the fact > that Extras is not sync-ed to Rawhide. I am a rawhide beta tester, and > extras is a pain for me to use. Do you know what kind of hackery is > required to get the Nvidia driver from livna properly installed on a > rawhide system? That's because Livna, like extras, is not sync-ed to > rawhide. Would you mind sharing exactly what you had to do? Or perhaps open a bug on bugzilla.livna.org. > P.S. Speaking of the Nvidia driver, will somebody please consider > splitting xorg-x11-Mesa-libGL-devel and xorg-x11-Mesa-libGLU-devel in > their own packages where they belong. I tried discussing this with the > maintainer, but he disappeared in the middle of the discussion and the > bug was left unresolved, pending FC4, which makes no sense to me. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145287 I'm not 100% sure of how runtime linking works, but if you look at a binary like /usr/X11R6/bin/glxgears, it links to the Nvidia libraries when they are installed through the livna.org package, like this: [peter at localhost]~% ldd /usr/X11R6/bin/glxgears libGL.so.1 => /usr/lib/nvidia/libGL.so.1 (0x4a8b4000) libGLcore.so.1 => /usr/lib/nvidia/libGLcore.so.1 (0x4a16d000) libnvidia-tls.so.1 => /usr/lib/nvidia/tls/libnvidia-tls.so.1 (0x4a8b0000) This is accomplished by a file in /etc/ld.so.conf.d/ making libGL* load from /usr/lib/nvidia/ first. AFAIK there are no OpenGL applications in FC that don't pick up the Nvidia libGL.so.1 when it's installed via the livna.org rpms. /Peter From symbiont at berlios.de Fri Jan 28 16:19:17 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sat, 29 Jan 2005 00:19:17 +0800 Subject: redhat abe In-Reply-To: References: <20050127082839.GE29221@batman.gotham.krass.com> Message-ID: <200501290019.17288.symbiont@berlios.de> On Friday 28 January 2005 18:22, Dag Wieers wrote: > On Fri, 28 Jan 2005, Panu Matilainen wrote: > > But really I think time would be better > > spent improving yum/smartpm to have the equivalent of build-dep, > > source and such operations. > > And make Smart work on older versions of python and with older rpmlib > versions, at least RHEL3. RHN support is also on my wishlist. Two things: CVS/SVN and Mailing List. Otherwise, we have no venue to contribute patches. thanks, -- -jeff From skvidal at phy.duke.edu Fri Jan 28 16:47:47 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 28 Jan 2005 11:47:47 -0500 Subject: redhat abe In-Reply-To: <200501290019.17288.symbiont@berlios.de> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290019.17288.symbiont@berlios.de> Message-ID: <1106930867.26755.0.camel@cutter> On Sat, 2005-01-29 at 00:19 +0800, Jeff Pitman wrote: > On Friday 28 January 2005 18:22, Dag Wieers wrote: > > On Fri, 28 Jan 2005, Panu Matilainen wrote: > > > But really I think time would be better > > > spent improving yum/smartpm to have the equivalent of build-dep, > > > source and such operations. > > > > And make Smart work on older versions of python and with older rpmlib > > versions, at least RHEL3. RHN support is also on my wishlist. > > Two things: CVS/SVN and Mailing List. Otherwise, we have no venue to > contribute patches. yum has cvs and a mailing list. hint hint. -sv From ivg2 at cornell.edu Fri Jan 28 16:54:29 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 09:54:29 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106930141.19595.109.camel@localhost.localdomain> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> Message-ID: <1106931269.26564.15.camel@cobra.ivg2.net> On Fri, 2005-01-28 at 17:35 +0100, Peter Backlund wrote: > fre 2005-01-28 klockan 09:17 -0700 skrev Ivan Gyurdiev: > > > Quite a few of us would like to see software we do personally use pushed > > > to Extras. > > > > Hi, I haven't been following this discussion, but I'd like to say that > > I don't want to see software I use pushed to extras due to the fact > > that Extras is not sync-ed to Rawhide. I am a rawhide beta tester, and > > extras is a pain for me to use. Do you know what kind of hackery is > > required to get the Nvidia driver from livna properly installed on a > > rawhide system? That's because Livna, like extras, is not sync-ed to > > rawhide. > > Would you mind sharing exactly what you had to do? Or perhaps open a bug > on bugzilla.livna.org. > Well, If you don't install the livna packages xorg-x11-Mesa-libGL breaks your system at every upgrade, and you can't get rid of it (because it's required). However you can't install the nvidia-glx package, because it depends on the kernel module, which needs to be recompiled per kernel, and Livna does not sync to rawhide. Furthermore the driver distributed is not patched for well-known bugs with the patches here: http://www.minion.de/files/1.0-6629/ So, to summarize, my best option is to use the nvidia-distributed installer, extract, patch the driver, install it, generate a fake provides rpm, install the nvidia-glx package on top of that, and disable the startup script for nvidia (because the module as installed by nvidia is not where the livna rpm puts it, so it doesn't work). Then, there's xorg-x11-devel which owns the libGL.so link, which happens to be a dead link, because the Mesa package is not installed. I have to move the GL devel stuff around and redirect the link to the nvidia files every time xorg-x11-devel is updated, or I can no longer build wine-cvs with openGL support. Really to resolve this the following is needed: - updated livna nvidia package to include more patches - Livna.org sync-ed against Rawhide. - updated xorg-x11 packaging to separate the Mesa GL stuff - some sort of alternatives system or post-install scripts to find correct provider of libGL.so.1 That doesn't include the SElinux bug in the strict policy where udev needs to restorecon devices from /usr/etc/devices. I've filed this in bugzilla and I assume it's being resolved. > I'm not 100% sure of how runtime linking works, but if you look at a > binary like /usr/X11R6/bin/glxgears, it links to the Nvidia libraries > when they are installed through the livna.org package, like this: This is not a runtime issue - it's a compile time issue that I'm talking about. I can't compile stuff against libGL. The runtime issue is that you can't install the livna packages on rawhide systems. -- Ivan Gyurdiev Cornell University From symbiont at berlios.de Fri Jan 28 16:40:16 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sat, 29 Jan 2005 00:40:16 +0800 Subject: Our Discussion on Fedora-docs [Fwd: Re: Fedora Documentation Search Engine] In-Reply-To: <42853.193.195.148.66.1106926064.squirrel@webmail.suretecsystems.com> References: <42853.193.195.148.66.1106926064.squirrel@webmail.suretecsystems.com> Message-ID: <200501290040.16239.symbiont@berlios.de> On Friday 28 January 2005 23:27, Gavin Henry wrote: > I thought that maybe you guys would have some input on this? Doc index generation should not be done in %post. It should be user-driven. That said, FC needs to seriously consider one of the many fledgling desktop search solutions. We may not use it en masse now, but, with more people using google's,et al on other platforms, it may be in more demand at a future date (6 mos to 1 yr maybe). -- -jeff From jspaleta at gmail.com Fri Jan 28 16:59:39 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 28 Jan 2005 11:59:39 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106931269.26564.15.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> Message-ID: <604aa791050128085932f4f675@mail.gmail.com> On Fri, 28 Jan 2005 09:54:29 -0700, Ivan Gyurdiev wrote: > Furthermore the driver distributed is not patched for well-known bugs > with the patches here: > http://www.minion.de/files/1.0-6629/ Or you can work with the livna packager.. to get those patches integrated into the livna rpm. I doubt competent help wouldn't be turned away. thanks for volunteering to help with the packaging effort. -jef From rdieter at math.unl.edu Fri Jan 28 17:00:37 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 28 Jan 2005 11:00:37 -0600 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106931269.26564.15.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> Message-ID: <41FA6FB5.9010808@math.unl.edu> Ivan Gyurdiev wrote: > Really to resolve this the following is needed: > > - updated livna nvidia package to include more patches agreed. I'd suggested poking at bugzilla.livna.org > - Livna.org sync-ed against Rawhide. It's not too hard for rawhide'rs to 'rpmbuild --rebuild'. is it? > - updated xorg-x11 packaging to separate the Mesa GL stuff > - some sort of alternatives system or post-install scripts to > find correct provider of libGL.so.1 Why are these necessary? Just because you don't like the fact they're merely installed, but not used? -- Rex From byte at aeon.com.my Fri Jan 28 17:00:49 2005 From: byte at aeon.com.my (Colin Charles) Date: Fri, 28 Jan 2005 22:30:49 +0530 Subject: Fedora PPC things... In-Reply-To: <20050127133613.7eb636f4@nausicaa.camperquake.de> References: <1106630968.5401.42.camel@localhost.localdomain> <20050127132800.1b7918ad@nausicaa.camperquake.de> <20050127133613.7eb636f4@nausicaa.camperquake.de> Message-ID: <1106931649.9897.4.camel@localhost.localdomain> On Thu, 2005-01-27 at 13:36 +0100, Ralf Ertzinger wrote: > > On the positive side, the latest Xorg from rawhide has magically > enabled > > DRI on my iBook (xorg-x11-6.8.1.902-4). 3D is slow (rage128), but > > definitely faster than software rendering :) > > bzflag works, celestia works, neverball works, tuxracer crashes and > burns :) File a bug, under tuxracer, report that your r128 breaks it (actually, maybe file a bug under xorg), and make sure the arch is powerpc -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From ivg2 at cornell.edu Fri Jan 28 17:07:17 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 10:07:17 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106931269.26564.15.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> Message-ID: <1106932037.26564.21.camel@cobra.ivg2.net> > - some sort of alternatives system or post-install scripts to > find correct provider of libGL.so.1 That should be libGL.so. Let me demonstrate. After today's X upgrades: [root at cobra phantom]# rpm -q --whatprovides libGL.so.1 nvidia-glx-1.0.6629-0.lvn.3.3 [root at cobra phantom]# rpm -qf /usr/lib/libGL.so xorg-x11-devel-6.8.1.902-7 [root at cobra phantom]# ls -l /usr/lib/libGL.so lrwxrwxrwx 1 root root 28 Jan 28 09:43 /usr/lib/libGL.so - > ../../usr/X11R6/lib/libGL.so [root at cobra phantom]# ls -l /usr/X11R6/lib/libGL.so lrwxrwxrwx 1 root root 12 Jan 28 09:43 /usr/X11R6/lib/libGL.so -> libGL.so.1.2 [root at cobra phantom]# ls -l /usr/X11R6/lib/libGL.so.1.2 ls: /usr/X11R6/lib/libGL.so.1.2: No such file or directory [root at cobra phantom]# ld -lGL ld: cannot find -lGL [root at cobra phantom]# ln -sf /usr/lib/nvidia/libGL.so /usr/lib/libGL.so [root at cobra phantom]# cd /usr/include/GL [root at cobra GL]# mv gl.h glx.h glx.h glxext.h glxint.h glxmd.h glxproto.h glxtokens.h osmesa.h mesa -f mv: cannot stat `glx.h': No such file or directory [root at cobra GL]# ln -sf /usr/include/nvidia/GL/* . [root at cobra GL]# cd /usr/X11R6/lib [root at cobra lib]# mv libGL.* libOSMesa* mesa -f [root at cobra lib]# ldconfig bash: ldconfig: command not found [root at cobra lib]# /sbin/ldconfig [root at cobra lib]# ld -lGL ld: warning: cannot find entry symbol _start; not setting start address [root at cobra lib]# rm -f a.out Repeat this every time X is upgraded or don't upgrade X. -- Ivan Gyurdiev Cornell University From symbiont at berlios.de Fri Jan 28 16:27:05 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sat, 29 Jan 2005 00:27:05 +0800 Subject: redhat abe In-Reply-To: References: <20050127082839.GE29221@batman.gotham.krass.com> <1106920957.3607.33.camel@cutter> Message-ID: <200501290027.05357.symbiont@berlios.de> On Friday 28 January 2005 23:02, Dag Wieers wrote: > Fixing createrepo to provide old-yum metadata would be an acceptable > workaround from the repository maintainer POV. Trying to get rid of > repository maintainers is an alternative too :) Almost got me. Fixing for old-yum would be bonus. Though, I think the true bonus would be incremental update. Still thinking about it though. Mass --resign is a burden. Rerun of metadata is a burden. If there could be a MANIFEST from build to sign to metadata to publish incrementally operating on stuff surrounding the list, then managing thousands of packages becomes less of a burden. -- -jeff From byte at aeon.com.my Fri Jan 28 17:06:54 2005 From: byte at aeon.com.my (Colin Charles) Date: Fri, 28 Jan 2005 22:36:54 +0530 Subject: Fedora PPC things... In-Reply-To: <20050127132800.1b7918ad@nausicaa.camperquake.de> References: <1106630968.5401.42.camel@localhost.localdomain> <20050127132800.1b7918ad@nausicaa.camperquake.de> Message-ID: <1106932014.9897.12.camel@localhost.localdomain> On Thu, 2005-01-27 at 13:28 +0100, Ralf Ertzinger wrote: > > 3. sound is still relatively broken > > No problems so far on my mac. The microphone does not work. Okay, will have to verify this later. Is it just arecord thats possibly broken though? > > 10. spanking MiniMac support? > > Isn't that just an iBook in a different case? No, I don't think so. We'll see > 11. We need a working kernel. The last one working for me is 2.6.9-1.667. > Later kernels have trouble with ptrace, or do not exist at all. Use dwmw2's kernels, and rawhide should have ppc32 again > 12. Firewire detection does not work, at least on my iBook. Firewire itself > works when you manually load the driver. > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140753) Funny, worked on my iBook g3 without issue. I'll test this in a week and get back to you > Note: all hardware notes above are from a 500MHz iBook2. iBook 2.2, 800MHz BTW, please cc fedora-ppc list (it accepts postings from everyone, iirc) -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From peter.backlund at home.se Fri Jan 28 17:15:06 2005 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 28 Jan 2005 18:15:06 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106931269.26564.15.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> Message-ID: <1106932506.19595.116.camel@localhost.localdomain> fre 2005-01-28 klockan 09:54 -0700 skrev Ivan Gyurdiev: > On Fri, 2005-01-28 at 17:35 +0100, Peter Backlund wrote: > > fre 2005-01-28 klockan 09:17 -0700 skrev Ivan Gyurdiev: > > > > Quite a few of us would like to see software we do personally use pushed > > > > to Extras. > > > > > > Hi, I haven't been following this discussion, but I'd like to say that > > > I don't want to see software I use pushed to extras due to the fact > > > that Extras is not sync-ed to Rawhide. I am a rawhide beta tester, and > > > extras is a pain for me to use. Do you know what kind of hackery is > > > required to get the Nvidia driver from livna properly installed on a > > > rawhide system? That's because Livna, like extras, is not sync-ed to > > > rawhide. > > > > Would you mind sharing exactly what you had to do? Or perhaps open a bug > > on bugzilla.livna.org. > > > > Well, > > If you don't install the livna packages xorg-x11-Mesa-libGL breaks your > system at every upgrade, and you can't get rid of it (because it's > required). > > However you can't install the nvidia-glx package, because it depends > on the kernel module, which needs to be recompiled per kernel, > and Livna does not sync to rawhide. You can rebuild the src.rpm like this: rpmbuild -bc --target i686 --without driverp nvidia-glx.spec to simply build a new kernel-module-nvidia package when a new kernel is released. > Furthermore the driver distributed is not patched for well-known bugs > with the patches here: > http://www.minion.de/files/1.0-6629/ What are these patches for? > So, to summarize, my best option is to use the nvidia-distributed > installer, extract, patch the driver, install it, generate a fake > provides rpm, install the nvidia-glx package on top of that, > and disable the startup script for nvidia (because the module > as installed by nvidia is not where the livna rpm puts it, > so it doesn't work). Mixing the rpms from livna and the scipt installer is not and will never be supported by livna.org. > Then, there's xorg-x11-devel which owns the libGL.so link, which > happens to be a dead link, because the Mesa package is not installed. > I have to move the GL devel stuff around and redirect the link to the > nvidia files every time xorg-x11-devel is updated, or I can no longer > build wine-cvs with openGL support. > > Really to resolve this the following is needed: > > - updated livna nvidia package to include more patches If there is a good reason to use a certain patch, it will be included. > - Livna.org sync-ed against Rawhide. Won't happen anytime soon, but see above for a very simple fix. > - updated xorg-x11 packaging to separate the Mesa GL stuff > - some sort of alternatives system or post-install scripts to > find correct provider of libGL.so.1 This already works with the rpms. > That doesn't include the SElinux bug in the strict policy where > udev needs to restorecon devices from /usr/etc/devices. I've filed > this in bugzilla and I assume it's being resolved. bz#? > > I'm not 100% sure of how runtime linking works, but if you look at a > > binary like /usr/X11R6/bin/glxgears, it links to the Nvidia libraries > > when they are installed through the livna.org package, like this: > > This is not a runtime issue - it's a compile time issue that I'm talking > about. I can't compile stuff against libGL. If you don't uninstall the Mesa libGL/libGLU rpms, you can compile against those. If you want Nvidia-specific features, use -L/usr/lib/nvidia -I/usr/include/nvidia. /Peter From fedora at wir-sind-cool.org Fri Jan 28 17:10:41 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Fri, 28 Jan 2005 18:10:41 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106929038.26304.17.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> Message-ID: <20050128181041.290b1825.fedora@wir-sind-cool.org> On Fri, 28 Jan 2005 09:17:18 -0700, Ivan Gyurdiev wrote: > > > Quite a few of us would like to see software we do personally use pushed > > to Extras. > > Hi, I haven't been following this discussion, but I'd like to say that > I don't want to see software I use pushed to extras due to the fact > that Extras is not sync-ed to Rawhide. I am a rawhide beta tester, and > extras is a pain for me to use. Do you know what kind of hackery is > required to get the Nvidia driver from livna properly installed on a > rawhide system? That's because Livna, like extras, is not sync-ed to > rawhide. > > I'd like to see a rawhide-tracking extras, and I've asked this question > before. I was explained that there are no resources for it. Until > resources are found I suggest this be taken into account. > > By the way, that also implies you will get no testing for extras > packages, leading to more bugs not being discovered until release. The first is [still] true, the second is not. So far - with the exception of killing fedora.us for FC3 - the extra packages had been rebuilt against at least one FC test release and updated in sync with the test releases. This shall happen again with FC4 Test1. And then will need extra resources who deal with breakage, i.e. developers who run the test releases. This need not be the primary package owners. There should always be room for multiple people maintaining a single package. And when that happens for many packages, and one out of each group of maintainers additionally tracks Rawhide, you can talk about trying to track rawhide with an extras development stream. From ivg2 at cornell.edu Fri Jan 28 17:12:46 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 10:12:46 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FA6FB5.9010808@math.unl.edu> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <41FA6FB5.9010808@math.unl.edu> Message-ID: <1106932366.32563.4.camel@cobra.ivg2.net> On Fri, 2005-01-28 at 11:00 -0600, Rex Dieter wrote: > Ivan Gyurdiev wrote: > > > Really to resolve this the following is needed: > > > > - updated livna nvidia package to include more patches > > agreed. I'd suggested poking at bugzilla.livna.org All right, maybe I will. I like focusing on one bug at a time. Currently I'm messing with SElinux stuff. > > > - Livna.org sync-ed against Rawhide. > > It's not too hard for rawhide'rs to 'rpmbuild --rebuild'. is it? Well had the livna package been patched I suppose I could do that. That creates incentive to help get it patched :) > > - updated xorg-x11 packaging to separate the Mesa GL stuff > > - some sort of alternatives system or post-install scripts to > > find correct provider of libGL.so.1 > > Why are these necessary? Just because you don't like the fact they're > merely installed, but not used? No - because they prevent building things against libGL. libGL.so.1 is a typo - should have been libGL.so - see other mail for detail. -- Ivan Gyurdiev Cornell University From dag at wieers.com Fri Jan 28 17:16:56 2005 From: dag at wieers.com (Dag Wieers) Date: Fri, 28 Jan 2005 18:16:56 +0100 (CET) Subject: redhat abe In-Reply-To: <1106926242.5389.96.camel@mccallum.corsepiu.local> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <1106918252.5389.52.camel@mccallum.corsepiu.local> <1106926242.5389.96.camel@mccallum.corsepiu.local> Message-ID: On Fri, 28 Jan 2005, Ralf Corsepius wrote: > On Fri, 2005-01-28 at 16:12 +0100, Dag Wieers wrote: > > On Fri, 28 Jan 2005, Ralf Corsepius wrote: > > > > > Try aptate from apt4rpm (http://apt4rpm.sourceforge.net - Try the > > > version from CVS-head, the released tarballs are troublesome) and feel > > > free to ask me on PM in case of problems :-) > > > > Afaics, aptate just calls genbasedir, yum-arch or createrepo. Each of them > > largely doing the same thing and reading 14GB worth of packages. > > Not quite. aptate uses a cache to check for which rpms have been added > to a repository since the last time it has been run, and then > incrementally builds the apt-repositories. Could we have this functionality added to genbasedir ? genbasedir already does some caching afaik. > Give it a try, initially building the repositories (setting up the > cache) takes a lot of time, but updating repositories, after a couple of > packages have been added to it is fast. What does the implementation do exactly ? Does it use mtime ? How does it add or replace a single package ? > As far as yum is concerned, you are right. yum repositories are re-built > instead of being incrementally built, however even they are only built > if a package had been added or removed from the repository. Well, in most cases I rebuild 1 package for all distributions, so it affects all repositories. -- dag wieers, dag at wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power] From ivg2 at cornell.edu Fri Jan 28 17:15:13 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 10:15:13 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <604aa791050128085932f4f675@mail.gmail.com> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <604aa791050128085932f4f675@mail.gmail.com> Message-ID: <1106932513.32563.8.camel@cobra.ivg2.net> > I doubt competent help wouldn't be turned away. Well, if that's the Fedora way then I'm surprised it has gotten this far :) I get what you mean though. -- Ivan Gyurdiev Cornell University From peter.backlund at home.se Fri Jan 28 17:26:47 2005 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 28 Jan 2005 18:26:47 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106932037.26564.21.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> Message-ID: <1106933207.19595.121.camel@localhost.localdomain> fre 2005-01-28 klockan 10:07 -0700 skrev Ivan Gyurdiev: > > - some sort of alternatives system or post-install scripts to > > find correct provider of libGL.so.1 > > That should be libGL.so. > > Let me demonstrate. After today's X upgrades: [snip] [root at localhost ~]# rpm -qa \*nvidia\* \*Mesa\* kernel-module-nvidia-2.6.10-1.741_FC3-1.0.6629-0.lvn.6 kernel-module-nvidia-2.6.9-1.724_FC3-1.0.6629-0.lvn.6 xorg-x11-Mesa-libGLU-6.8.1-12.FC3.21 xorg-x11-Mesa-libGL-6.8.1-12.FC3.21 nvidia-glx-1.0.6629-0.lvn.6 nvidia-glx-devel-1.0.6629-0.lvn.6 Both nvidia-glx and Mesa are installed. Follow libGL.so: [root at localhost ~]# ls -l /usr/lib/libGL.so lrwxrwxrwx 1 root root 28 5 jan 18.41 /usr/lib/libGL.so - > ../../usr/X11R6/lib/libGL.so [root at localhost ~]# ls -l /usr/X11R6/lib/libGL.so lrwxrwxrwx 1 root root 12 5 jan 18.41 /usr/X11R6/lib/libGL.so -> libGL.so.1.2 [root at localhost ~]# ls -l /usr/X11R6/lib/libGL.so.1.2 -rwxr-xr-x 1 root root 474388 1 dec 08.36 /usr/X11R6/lib/libGL.so.1.2 Now, a test program that links to libGL: [root at localhost ~]# cat test.c #include #include int main() { return 0; } Compile and look for runtime providers (snipped for brevity): [root at localhost ~]# gcc test.c -lGL [root at localhost ~]# ldd a.out libGL.so.1 => /usr/lib/nvidia/libGL.so.1 (0x4a8b4000) libGLcore.so.1 => /usr/lib/nvidia/libGLcore.so.1 (0x4a16d000) libnvidia-tls.so.1 => /usr/lib/nvidia/tls/libnvidia-tls.so.1 (0x4a8b0000) What's the problem with this setup? /Peter From ivg2 at cornell.edu Fri Jan 28 17:24:43 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 10:24:43 -0700 Subject: Nvidia packaging for Fedora In-Reply-To: <1106932506.19595.116.camel@localhost.localdomain> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932506.19595.116.camel@localhost.localdomain> Message-ID: <1106933084.32563.17.camel@cobra.ivg2.net> > > Furthermore the driver distributed is not patched for well-known bugs > > with the patches here: > > http://www.minion.de/files/1.0-6629/ > > What are these patches for? To tell you the truth I am not entirely sure about most of them. However I know the 18k one fixes a memory leak that improves performance. I can find links for most of those patches on the Nvidia forums posted by Zander, which I believe is the Nvidia Linux contact there. > Mixing the rpms from livna and the scipt installer is not and will never > be supported by livna.org. That's obvious. I suppose if the driver was patched I could rebuild the package like you say and it would be easier. > > - Livna.org sync-ed against Rawhide. > > Won't happen anytime soon, but see above for a very simple fix. This discussion was about pros and cons of extras. That's why I brought this up. This is one great disavantage of extras and livna for me compared to Core. > > - updated xorg-x11 packaging to separate the Mesa GL stuff > > - some sort of alternatives system or post-install scripts to > > find correct provider of libGL.so.1 > > This already works with the rpms. It does not. That should have been libGL.so. See my other mail for details. > > That doesn't include the SElinux bug in the strict policy where > > udev needs to restorecon devices from /usr/etc/devices. I've filed > > this in bugzilla and I assume it's being resolved. > > bz#? 145041 > > If you don't uninstall the Mesa libGL/libGLU rpms, you can compile > against those. If you want Nvidia-specific features, > use -L/usr/lib/nvidia -I/usr/include/nvidia. The Mesa libGL rpms conflict with the Nvidia ones. If they are not uninstalled I get graphical glitches and performance problems. The GL client and server versions differ. I suppose that's because they're both in the linker path -- Ivan Gyurdiev Cornell University From fedora at leemhuis.info Fri Jan 28 17:27:35 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 28 Jan 2005 18:27:35 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106930141.19595.109.camel@localhost.localdomain> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> Message-ID: <1106933255.6087.3.camel@localhost.localdomain> Am Freitag, den 28.01.2005, 17:35 +0100 schrieb Peter Backlund: > fre 2005-01-28 klockan 09:17 -0700 skrev Ivan Gyurdiev: > > > Quite a few of us would like to see software we do personally use pushed > > > to Extras. > > > > Hi, I haven't been following this discussion, but I'd like to say that > > I don't want to see software I use pushed to extras due to the fact > > that Extras is not sync-ed to Rawhide. I am a rawhide beta tester, and > > extras is a pain for me to use. Do you know what kind of hackery is > > required to get the Nvidia driver from livna properly installed on a > > rawhide system? That's because Livna, like extras, is not sync-ed to > > rawhide. > > Would you mind sharing exactly what you had to do? Or perhaps open a bug > on bugzilla.livna.org. FYI: There are some updates suggested for the Livna webpage in livna.org Bug 350; They explain a bit more how to install the nvidia/ati drivers from livna and also describe how to rebuild the kernel-module for a different kernel (e.g. rawhide) using the SRPM from livna. CU thl -- Thorsten Leemhuis From ivg2 at cornell.edu Fri Jan 28 17:28:59 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 10:28:59 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106933207.19595.121.camel@localhost.localdomain> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> Message-ID: <1106933340.32563.21.camel@cobra.ivg2.net> On Fri, 2005-01-28 at 18:26 +0100, Peter Backlund wrote: > fre 2005-01-28 klockan 10:07 -0700 skrev Ivan Gyurdiev: > > > - some sort of alternatives system or post-install scripts to > > > find correct provider of libGL.so.1 > > > > That should be libGL.so. > > > > Let me demonstrate. After today's X upgrades: > > [snip] > > [root at localhost ~]# rpm -qa \*nvidia\* \*Mesa\* > kernel-module-nvidia-2.6.10-1.741_FC3-1.0.6629-0.lvn.6 > kernel-module-nvidia-2.6.9-1.724_FC3-1.0.6629-0.lvn.6 > xorg-x11-Mesa-libGLU-6.8.1-12.FC3.21 > xorg-x11-Mesa-libGL-6.8.1-12.FC3.21 > nvidia-glx-1.0.6629-0.lvn.6 > nvidia-glx-devel-1.0.6629-0.lvn.6 > > Both nvidia-glx and Mesa are installed. Try this: glxinfo|grep version Are the versions the same? -- Ivan Gyurdiev Cornell University From rdieter at math.unl.edu Fri Jan 28 17:29:54 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 28 Jan 2005 11:29:54 -0600 Subject: Nvidia packaging for Fedora In-Reply-To: <1106933084.32563.17.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932506.19595.116.camel@localhost.localdomain> <1106933084.32563.17.camel@cobra.ivg2.net> Message-ID: <41FA7692.5060701@math.unl.edu> Ivan Gyurdiev wrote: >>>- updated xorg-x11 packaging to separate the Mesa GL stuff >>>- some sort of alternatives system or post-install scripts to >>> find correct provider of libGL.so.1 >> >>This already works with the rpms. > > > It does not. That should have been libGL.so. > See my other mail for details. nvidia should *not* be the provider for libGL.so, but MesaGL. Else you end up with binaries that work only on/for nvidia users. > The Mesa libGL rpms conflict with the Nvidia ones. No they don't. > If they are not uninstalled I get graphical glitches and performance > problems. The GL client and server versions differ. I suppose that's > because they're both in the linker path Possibly a packaging bug... but IMO, not caused by the presence of Mesa_GL. again, report it: bugzilla.livna.org -- Rex From peter.backlund at home.se Fri Jan 28 17:40:49 2005 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 28 Jan 2005 18:40:49 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106933340.32563.21.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> Message-ID: <1106934049.19595.126.camel@localhost.localdomain> fre 2005-01-28 klockan 10:28 -0700 skrev Ivan Gyurdiev: > On Fri, 2005-01-28 at 18:26 +0100, Peter Backlund wrote: > > fre 2005-01-28 klockan 10:07 -0700 skrev Ivan Gyurdiev: > > > > - some sort of alternatives system or post-install scripts to > > > > find correct provider of libGL.so.1 > > > > > > That should be libGL.so. > > > > > > Let me demonstrate. After today's X upgrades: > > > > [snip] > > > > [root at localhost ~]# rpm -qa \*nvidia\* \*Mesa\* > > kernel-module-nvidia-2.6.10-1.741_FC3-1.0.6629-0.lvn.6 > > kernel-module-nvidia-2.6.9-1.724_FC3-1.0.6629-0.lvn.6 > > xorg-x11-Mesa-libGLU-6.8.1-12.FC3.21 > > xorg-x11-Mesa-libGL-6.8.1-12.FC3.21 > > nvidia-glx-1.0.6629-0.lvn.6 > > nvidia-glx-devel-1.0.6629-0.lvn.6 > > > > Both nvidia-glx and Mesa are installed. > > Try this: > glxinfo|grep version > > Are the versions the same? No: [peter at localhost]~% glxinfo| grep version server glx version string: 1.2 client glx version string: 1.3 OpenGL version string: 1.2 (1.5 Mesa 6.1) glu version: 1.3 What problems would that create? I've played a number of OpenGL games, such as Quake3 and Doom3, and never seen any glitches in them or in any screensaver, and I always keep Mesa installed btw. Could you provide a real-world example of code that does not build and run the way you want it, so that I can test it? /Peter From fedora-devel at camperquake.de Fri Jan 28 17:35:23 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Fri, 28 Jan 2005 18:35:23 +0100 Subject: Fedora PPC things... In-Reply-To: <1106932014.9897.12.camel@localhost.localdomain> References: <1106630968.5401.42.camel@localhost.localdomain> <20050127132800.1b7918ad@nausicaa.camperquake.de> <1106932014.9897.12.camel@localhost.localdomain> Message-ID: <20050128183523.3ddc418e@nausicaa.camperquake.de> Hi. Colin Charles wrote: > > No problems so far on my mac. The microphone does not work. > > Okay, will have to verify this later. Is it just arecord thats possibly > broken though? /proc/asound/devices does not show any recording stuff. > Use dwmw2's kernels, and rawhide should have ppc32 again Will do. -- I have seen slower people than I am -- and even quieter, and more listless, and lazier people than I am. But they were dead. -- Mark Twain From ivg2 at cornell.edu Fri Jan 28 17:41:13 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 10:41:13 -0700 Subject: Nvidia packaging for Fedora In-Reply-To: <41FA7692.5060701@math.unl.edu> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932506.19595.116.camel@localhost.localdomain> <1106933084.32563.17.camel@cobra.ivg2.net> <41FA7692.5060701@math.unl.edu> Message-ID: <1106934073.32563.32.camel@cobra.ivg2.net> > nvidia should *not* be the provider for libGL.so, but MesaGL. Else you > end up with binaries that work only on/for nvidia users. You fail to see that libGL.so is a dead link on systems which don't have Mesa GL installed. That alone is already a bug - Mesa GL is not required by any package in all of Fedora, and that's because the nvidia- glx package replaces it. So, requiring me to go install Mesa GL is already a bug. > > If they are not uninstalled I get graphical glitches and performance > > problems. The GL client and server versions differ. I suppose that's > > because they're both in the linker path > > Possibly a packaging bug... but IMO, not caused by the presence of > Mesa_GL. again, report it: > bugzilla.livna.org rpm -ql xorg-x11-Mesa-libGL* -p /usr/X11R6/lib/libGL.so.1 /usr/X11R6/lib/libGL.so.1.2 /usr/lib/libGL.so.1 How is this supposed to work? /usr/lib/libGL.so.1 takes precedence over the nvidia folder with the same lib. Even if it didn't, relying on which libGL.so.1 came first seems like a very fragile setup. I recall redirecting that link, and it was still broken since apparently it chose the one in X11R6. Then I redirected that one and it was restoring it on every ldconfig until I got rid of the library itself. Hence, Mesa GL conflicts with nvidia-glx. Btw why is /usr/lib/libGL.so.1 there at all? -- Ivan Gyurdiev Cornell University From peter.backlund at home.se Fri Jan 28 17:45:10 2005 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 28 Jan 2005 18:45:10 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106934049.19595.126.camel@localhost.localdomain> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> Message-ID: <1106934310.6141.0.camel@localhost.localdomain> fre 2005-01-28 klockan 18:40 +0100 skrev Peter Backlund: > fre 2005-01-28 klockan 10:28 -0700 skrev Ivan Gyurdiev: > > On Fri, 2005-01-28 at 18:26 +0100, Peter Backlund wrote: > > > fre 2005-01-28 klockan 10:07 -0700 skrev Ivan Gyurdiev: > > > > > - some sort of alternatives system or post-install scripts to > > > > > find correct provider of libGL.so.1 > > > > > > > > That should be libGL.so. > > > > > > > > Let me demonstrate. After today's X upgrades: > > > > > > [snip] > > > > > > [root at localhost ~]# rpm -qa \*nvidia\* \*Mesa\* > > > kernel-module-nvidia-2.6.10-1.741_FC3-1.0.6629-0.lvn.6 > > > kernel-module-nvidia-2.6.9-1.724_FC3-1.0.6629-0.lvn.6 > > > xorg-x11-Mesa-libGLU-6.8.1-12.FC3.21 > > > xorg-x11-Mesa-libGL-6.8.1-12.FC3.21 > > > nvidia-glx-1.0.6629-0.lvn.6 > > > nvidia-glx-devel-1.0.6629-0.lvn.6 > > > > > > Both nvidia-glx and Mesa are installed. > > > > Try this: > > glxinfo|grep version > > > > Are the versions the same? Actually, I was running the nv driver. With the nvidia driver, I have the same version: [peter at localhost ~]$ glxinfo | grep version server glx version string: 1.3 client glx version string: 1.3 OpenGL version string: 1.5.2 NVIDIA 66.29 glu version: 1.3 /Peter From ivg2 at cornell.edu Fri Jan 28 17:46:15 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 10:46:15 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106934049.19595.126.camel@localhost.localdomain> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> Message-ID: <1106934375.32563.37.camel@cobra.ivg2.net> > > Are the versions the same? > > No: Thank you. That just proves my point. Now try running any 3D game and you will fail. Unreal tournament 2003 will not run at all. Half Life 2 will run with severe graphical glitches and missing textures. I forget what Warcraft 3 does, but it can't be good. Any way, this setup seems like a hack to me, even if it did work. > Could you provide a real-world example of code that does not build and > run the way you want it, so that I can test it? No, I don't do openGL developent (I'd like to, but I haven't gotten around to that class yet) -- Ivan Gyurdiev Cornell University From rdieter at math.unl.edu Fri Jan 28 17:48:50 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 28 Jan 2005 11:48:50 -0600 Subject: Nvidia packaging for Fedora In-Reply-To: <1106934073.32563.32.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932506.19595.116.camel@localhost.localdomain> <1106933084.32563.17.camel@cobra.ivg2.net> <41FA7692.5060701@math.unl.edu> <1106934073.32563.32.camel@cobra.ivg2.net> Message-ID: <41FA7B02.6070105@math.unl.edu> Ivan Gyurdiev wrote: >>nvidia should *not* be the provider for libGL.so, but MesaGL. Else you >>end up with binaries that work only on/for nvidia users. > > > You fail to see that libGL.so is a dead link on systems which don't have > Mesa GL installed. But Mesa GL *should* be installed if you intend to compile anything. That's the point. > So, requiring me to go install Mesa GL is already a bug. I fail to see how/why requiring MesaGL to compile anything is a bug. > rpm -ql xorg-x11-Mesa-libGL* -p > > /usr/X11R6/lib/libGL.so.1 > /usr/X11R6/lib/libGL.so.1.2 > /usr/lib/libGL.so.1 > > How is this supposed to work? > /usr/lib/libGL.so.1 takes precedence over the > nvidia folder with the same lib. ... > Even if it didn't, relying on which libGL.so.1 came first > seems like a very fragile setup. I recall redirecting that link, The nvidia folder is supposed to take precedence at runtime. That is how it is *supposed* to work. Fragile or not, it works for most folks, and is certainly better than what the nvidia installer does. -- Rex From ivg2 at cornell.edu Fri Jan 28 17:48:59 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 10:48:59 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106934310.6141.0.camel@localhost.localdomain> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> Message-ID: <1106934539.32563.40.camel@cobra.ivg2.net> > Actually, I was running the nv driver. With the nvidia driver, I have > the same version: > > [peter at localhost ~]$ glxinfo | grep version > server glx version string: 1.3 > client glx version string: 1.3 > OpenGL version string: 1.5.2 NVIDIA 66.29 > glu version: 1.3 Tsk. Well I don't know what to tell you - I've had different versions for the nvidia driver. Maybe you're right and this is a setup error on my part, but this whole setup seems strange to me. Why would you split a library off from xorg-x11, but not split the headers? -- Ivan Gyurdiev Cornell University From rdieter at math.unl.edu Fri Jan 28 17:56:58 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 28 Jan 2005 11:56:58 -0600 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106934539.32563.40.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> Message-ID: <41FA7CEA.7030804@math.unl.edu> Ivan Gyurdiev wrote: > Why would you split a library off from xorg-x11, but not split the > headers? As I said previously, the MesaGL .so link and headers are required, else you end up with proprietary-ized binaries that work *only* when the nvidia GL libs are installed. MesaGL-linked binaries wor on both MesaGL and Nvidia-GL (supposedly) systems. I say (supposedly) because I don't have/use NVidia cards myself, but I've heard enough success stories from reputable sources to trust the conclusion. -- Rex From peter.backlund at home.se Fri Jan 28 18:03:53 2005 From: peter.backlund at home.se (Peter Backlund) Date: Fri, 28 Jan 2005 19:03:53 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106934539.32563.40.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> Message-ID: <1106935433.6141.12.camel@localhost.localdomain> fre 2005-01-28 klockan 10:48 -0700 skrev Ivan Gyurdiev: > > Actually, I was running the nv driver. With the nvidia driver, I have > > the same version: > > > > [peter at localhost ~]$ glxinfo | grep version > > server glx version string: 1.3 > > client glx version string: 1.3 > > OpenGL version string: 1.5.2 NVIDIA 66.29 > > glu version: 1.3 > > Tsk. Well I don't know what to tell you - I've had different versions > for the nvidia driver. Maybe you're right and this is a setup error on > my part, but this whole setup seems strange to me. Well, according to you, you've fiddled quite a bit with symlinks and whatnot, and using the rpms and the script installer at the same time, or at least not purging the system between switches, so I'd say chances are /very/ good your setup is b0rked. I'd be grateful if you could open a bug at livna with links to information about what the minion patches actually do, and maybe it/they could be included in the rpm. > Why would you split a library off from xorg-x11, but not split the > headers? I agree that the X/Mesa package setup right now is unfortunate. /Peter From nbargnesi at gmail.com Fri Jan 28 18:02:14 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Fri, 28 Jan 2005 13:02:14 -0500 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <20050127230519.GG7867@redhat.com> References: <200501261347.j0QDl0714149@porkchop.devel.redhat.com> <20050126144636.GA7010@redhat.com> <20050127165139.GA30730@redhat.com> <1106845150.7126.2.camel@dhcp-12.hsv.redhat.com> <3077b8a00501270948de2e9ae@mail.gmail.com> <20050127175314.GF30730@redhat.com> <3077b8a00501271352c17d7e9@mail.gmail.com> <20050127221953.GB7867@redhat.com> <3077b8a005012714492abd2fb1@mail.gmail.com> <20050127230519.GG7867@redhat.com> Message-ID: <3077b8a0050128100267a7e0bf@mail.gmail.com> On Thu, 27 Jan 2005 18:05:19 -0500, Andrew Overholt wrote: > * Nick Bargnesi [2005-01-27 17:50]: > > > This is because we've compiled and linked Eclipse with libgcj4's .so but > > > you're running with gij from the 3.4.x package (which is linked against > > > libgcj 3.4.x's .so). You just need to set your alternatives to point to > > > java-1.4.2-gcj4-compat and -devel. See blow: > > > > > > > Even after setting the alternative java and javac, I still see the > > RenderedImage gcj failure. > > Hmm. Can I see the output of the following commands: > > rpm -qa | grep eclipse eclipse-pde-3.0.1_fc-9 eclipse-source-3.0.1_fc-9 eclipse-gtk2-3.0.1_fc-9 eclipse-ecj-3.0.1_fc-9 eclipse-platform-3.0.1_fc-9 eclipse-jdt-3.0.1_fc-9 > rpm -q gcc4-java gcc4-java-4.0.0-0.22 > rpm -q libgcj4-devel libgcj4-devel-4.0.0-0.22 > which java /usr/bin/java > java --version Warning: --version not understood. Ignoring. Usage: gij [OPTION] ... CLASS [ARGS] ... to invoke CLASS.main, or gij -jar [OPTION] ... JARFILE [ARGS] ... to execute a jar file Try `gij --help' for more information. java -version returns: java version "1.4.2" gcj (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > which javac /usr/bin/javac > javac -version Eclipse Java Compiler 0.452_R30x, Copyright IBM Corp 2000, 2004. All rights reserved. > > Thanks, > > Andrew > Thoughts? This is on an x86 platform. I tried on x86_64 last night with same results. -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From kozik1 at o2.pl Fri Jan 28 18:10:30 2005 From: kozik1 at o2.pl (Krzysztof Kozlowski) Date: Fri, 28 Jan 2005 19:10:30 +0100 Subject: Another "Stateless" project for Fedora Message-ID: <20050128191030.327fbc14.kozik1@o2.pl> Hello I wish to introduce my own little "stateless" (actually a kind of NFS-readonly-root) project : http://acn.waw.pl/koziol/projekty/fedora_nfs_readonly_root/index.html I wanted to do this completely from the scratch - to learn something :). Maybe it will be interesting for you :). The goal is to boot Fedora Core 3 by PXE and mount root from NFS (readonly). I've prepared some scripts to create the "initrd.img" for booting. They were designed to work on FreeBSD (which is a server in my case), but I've tested them on Fedora Core 3. Currently only those scripts are published (I think it's the most difficult part) and documentation for initrd.img and the booting process (*only in Polish*, sorry my English is awfull :) ). In the future I will publish another part of scripts - how to prepare NFS server for serving NFS-root... Hope my work will be usefull for someone Krzysztof Koz?owski From ivg2 at cornell.edu Fri Jan 28 18:10:32 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 11:10:32 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FA7CEA.7030804@math.unl.edu> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> Message-ID: <1106935832.32563.56.camel@cobra.ivg2.net> On Fri, 2005-01-28 at 11:56 -0600, Rex Dieter wrote: > Ivan Gyurdiev wrote: > > > Why would you split a library off from xorg-x11, but not split the > > headers? > > As I said previously, the MesaGL .so link and headers are required, else > you end up with proprietary-ized binaries that work *only* when the > nvidia GL libs are installed. MesaGL-linked binaries wor on both MesaGL > and Nvidia-GL (supposedly) systems. > > I say (supposedly) because I don't have/use NVidia cards myself, but > I've heard enough success stories from reputable sources to trust the > conclusion. I am installing xorg-x11-devel and Mesa-libGL right now to test this "supposedly," because I am almost positive something will break. Will let you know in 10 mins. In the mean time, why is xorg-x11-devel not requiring xorg-x11-Mesa- libGL if your claim that it's required is true. If it required the Mesa package it wouldn't be able to install a dead link without consequence. Every other -devel package on Fedora seems to require the parent package. [phantom at cobra ~]$ rpm -q libgtop2-devel --requires glib2-devel >= 2.0.1 libgtop2 = 2.8.0 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 [phantom at cobra ~]$ rpm -q libpng-devel --requires /bin/sh libpng = 2:1.2.8 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 zlib-devel [phantom at cobra ~]$ rpm -q libmng-devel --requires libjpeg-devel libmng = 1.0.8 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 [phantom at cobra ~]$ -- Ivan Gyurdiev Cornell University From shahms at shahms.com Fri Jan 28 18:11:07 2005 From: shahms at shahms.com (Shahms King) Date: Fri, 28 Jan 2005 10:11:07 -0800 Subject: Nvidia packaging for Fedora In-Reply-To: <1106934073.32563.32.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932506.19595.116.camel@localhost.localdomain> <1106933084.32563.17.camel@cobra.ivg2.net> <41FA7692.5060701@math.unl.edu> <1106934073.32563.32.camel@cobra.ivg2.net> Message-ID: <1106935867.30653.123.camel@shahms.mesd.k12.or.us> *snip* > > Possibly a packaging bug... but IMO, not caused by the presence of > > Mesa_GL. again, report it: > > bugzilla.livna.org > > rpm -ql xorg-x11-Mesa-libGL* -p > > /usr/X11R6/lib/libGL.so.1 > /usr/X11R6/lib/libGL.so.1.2 > /usr/lib/libGL.so.1 > > How is this supposed to work? > /usr/lib/libGL.so.1 takes precedence over the > nvidia folder with the same lib. LD_LIBRARY_PATH is an answer. However, assuming your /etc/ld.so.conf is set up correctly, the /etc/ld.so.conf.d/nvidia-glx.conf should take precedence over /usr/lib. I have previously had problems with apps not finding the right GL library, but after correcting my ld.so.conf (and some upstream fixes) everything just works now. At the time, I just prepended "/usr/lib/nvidia" to the LD_LIBRARY_PATH and went merrily on my way. Note: adding libraries to LD_LIBRARY_PATH can be tricky as you don't want to have an "empty" entry, or ld looks in the current directory which is/can be insecure. Below is a bash function for correctly appending and prepending elements to an environment variable: (Note: it might be nice to see something similar shipped with Fedora as these are pretty common operations -- PATH, etc. -- that are strangely difficult to do correctly.) append() { local VARNAME=${1:?"Variable Not Specified"} local EXTRA=${2:?"What to prepend not specified"} local SEP=${3:-":"} local newvar="" local oifs="$IFS" local var=$(eval "echo \$${VARNAME}") IFS="$SEP" local part for part in $var; do if [ "$part" != "$EXTRA" ]; then newvar="${newvar:+${newvar}${SEP}}${part}" fi done IFS="$oifs" eval "$VARNAME='${newvar}${SEP}${EXTRA}'" } prepend() { local VARNAME=${1:?"Variable Not Specified"} local EXTRA=${2:?"What to prepend not specified"} local SEP=${3:-":"} local newvar="$EXTRA" local oifs="$IFS" local var=$(eval "echo \$${VARNAME}") IFS="$SEP" local part for part in $var; do if [ "$part" != "$EXTRA" ]; then newvar="${newvar}${SEP}${part}" fi done IFS="$oifs" eval "$VARNAME='$newvar'" } To put "/usr/lib/nvidia" safely at the front of LD_LIBRARY_PATH call: $ prepend LD_LIBRARY_PATH "/usr/lib/nvidia" Neither of these functions are very efficient as they both completely rebuild the environment variable from its component parts, but the end result is that if you say: append PATH "$HOME/bin" regardless of the earlier state of the PATH variable, your "$HOME/bin" will be listed last and only last. (alternatively, if you don't mind multiple identical entries in your PATH variables using: LD_LIBRARY_PATH=/usr/lib/nvidia${LD_LIBRARY_PATH:+":$LD_LIBRARY_PATH"} will also do the trick) > Even if it didn't, relying on which libGL.so.1 came first > seems like a very fragile setup. I recall redirecting that link, > and it was still broken since apparently it chose the one in X11R6. > Then I redirected that one and it was restoring it on every ldconfig > until I got rid of the library itself. > > Hence, Mesa GL conflicts with nvidia-glx. > > Btw why is /usr/lib/libGL.so.1 there at all? I'm guessing here, but OpenGL isn't technically restricted to just X. (It might be effectively restricted to X at the moment, but given that the long-term plans for X are to implement it on top of libGL, having an X display clearly isn't required for using OpenGL...) > -- > Ivan Gyurdiev > Cornell University > -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From denis at poolshark.org Fri Jan 28 18:27:18 2005 From: denis at poolshark.org (Denis Leroy) Date: Fri, 28 Jan 2005 10:27:18 -0800 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050128120508.2472.qmail@web8501.mail.in.yahoo.com> References: <20050128120508.2472.qmail@web8501.mail.in.yahoo.com> Message-ID: <41FA8406.6020005@poolshark.org> Rahul Sundaram wrote: > --- Jamie Zawinski wrote: > >>Rahul Sundaram wrote: >> >>>thats not a redhat stupidity. its patent issues >> >>over mp3 >> >>You know what? Trying to care; failing. >> > > > > ok. you dont have to care but finding fault with > redhat when there is none is a bad thing to do. how do > you expect them to resolve the mp3 issue. you tell me So out of curiosity, how do Suse and Mandrake deal with this issue ? -d From overholt at redhat.com Fri Jan 28 18:32:04 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 28 Jan 2005 13:32:04 -0500 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <3077b8a0050128100267a7e0bf@mail.gmail.com> References: <20050126144636.GA7010@redhat.com> <20050127165139.GA30730@redhat.com> <1106845150.7126.2.camel@dhcp-12.hsv.redhat.com> <3077b8a00501270948de2e9ae@mail.gmail.com> <20050127175314.GF30730@redhat.com> <3077b8a00501271352c17d7e9@mail.gmail.com> <20050127221953.GB7867@redhat.com> <3077b8a005012714492abd2fb1@mail.gmail.com> <20050127230519.GG7867@redhat.com> <3077b8a0050128100267a7e0bf@mail.gmail.com> Message-ID: <20050128183204.GB19188@redhat.com> * Nick Bargnesi [2005-01-28 13:05]: > java -version returns: > > java version "1.4.2" > gcj (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) [...] > Thoughts? This is on an x86 platform. I tried on x86_64 last night > with same results. Yeah, you need to have your java alternative set to java-1.4.2-gcj4-compat. It looks like it's currently set to java-1.4.2-gcj-compat (which uses gij from the 3.4.x package). Do the following (and note the 4s): su - -c "update-alternatives --set java \ /usr/lib/jvm/jre-1.4.2-gcj4/bin/java" su - -c "update-alternatives --set javac \ /usr/lib/jvm/java-1.4.2-gcj4/bin/javac" Andrew From aaron.bennett at olin.edu Fri Jan 28 18:34:35 2005 From: aaron.bennett at olin.edu (Aaron Bennett) Date: Fri, 28 Jan 2005 13:34:35 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106929223.14323.8.camel@support02.civic.twp.ypsilanti.mi.us> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <41FA5FAB.1090602@redhat.com> <1106927782.14323.1.camel@support02.civic.twp.ypsilanti.mi.us> <41FA62AA.6080404@redhat.com> <1106928530.14323.4.camel@support02.civic.twp.ypsilanti.mi.us> <41FA6531.8070102@redhat.com> <1106929223.14323.8.camel@support02.civic.twp.ypsilanti.mi.us> Message-ID: <41FA85BB.9050909@olin.edu> Sean Middleditch wrote: >On Fri, 2005-01-28 at 17:15 +0100, Harald Hoyer wrote: > > >> >>PPC? Bloat! :-) >> >> > >Hmm, good point. You know, now that I think on it, the kernel itself is >pretty big. Got a lot of them drivers in it. Nobody needs all of 'em. >I say we compile all drivers as modules and put them all in Extras, too. > > How about we just distribute a boot disk, people can use that to partition their system, download the minimum files they need, and then rebuild everything from .src.rpms. We can call it "Fedortoo" :-) -- Aaron Bennett UNIX Administrator Franklin W. Olin College of Engineering From ivg2 at cornell.edu Fri Jan 28 18:35:43 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 11:35:43 -0700 Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: <41FA7CEA.7030804@math.unl.edu> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> Message-ID: <1106937343.734.12.camel@cobra.ivg2.net> On Fri, 2005-01-28 at 11:56 -0600, Rex Dieter wrote: > Ivan Gyurdiev wrote: > > > Why would you split a library off from xorg-x11, but not split the > > headers? > > As I said previously, the MesaGL .so link and headers are required, else > you end up with proprietary-ized binaries that work *only* when the > nvidia GL libs are installed. MesaGL-linked binaries wor on both MesaGL > and Nvidia-GL (supposedly) systems. > > I say (supposedly) because I don't have/use NVidia cards myself, but > I've heard enough success stories from reputable sources to trust the > conclusion. > Allright. I tested this, it works, so I'll admit you're all right, I'm wrong, and from what I've learned from this discussion I even know exactly why - it has to do with symlinks, linker path precedence, and the nvidia script installer, it's not important. Conclusions: ============= - Mesa-libGL can work alongside nvidia-glx, and should be installed if I am to build against libGL or it doesn't work at all. - I should stay away from the nvidia installer, use only livna packages, and rebuild against rawhide. What needs to be done: ====================== - The -devel package should not install dead links on my system - it should require Mesa-libGL. - I still say the libGL devel stuff and libGLU should be split from xorg-x11-devel. - livna needs to be patched for memory leak bug, and other bugs. Patches at www.minion.de/files/1.0-6629/. - There should be a rawhide-sync'ed livna and extras, and not having them makes moving packages to extras evil. - SElinux strict policy bug with /etc/udev/devices to be fixed... Anything else I'm missing? -- Ivan Gyurdiev Cornell University From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jan 28 18:41:14 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 28 Jan 2005 19:41:14 +0100 Subject: rawhide report: 20050121 changes In-Reply-To: <20050122170803.GK2898@devserv.devel.redhat.com> References: <200501211328.j0LDSqH04234@porkchop.devel.redhat.com> <87zmz23ldy.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106318479.9659.5.camel@dcbw.boston.redhat.com> <604aa79105012115166926aec5@mail.gmail.com> <20050121234943.GA6392@nostromo.devel.redhat.com> <20050122170803.GK2898@devserv.devel.redhat.com> Message-ID: <20050128194114.4aa6cc38@python2> Alan Cox wrote : > I'd like to see some newer / better games picked up. Another question for > FC4 maybe "bzflag or bzflag2" Definitely bzflag 2 :-) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145780 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.52 1.09 0.89 From skvidal at phy.duke.edu Fri Jan 28 18:44:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 28 Jan 2005 13:44:39 -0500 Subject: redhat abe In-Reply-To: <200501290027.05357.symbiont@berlios.de> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106920957.3607.33.camel@cutter> <200501290027.05357.symbiont@berlios.de> Message-ID: <1106937879.26755.6.camel@cutter> > Almost got me. Fixing for old-yum would be bonus. Though, I think the > true bonus would be incremental update. Still thinking about it > though. Mass --resign is a burden. Rerun of metadata is a burden. If > there could be a MANIFEST from build to sign to metadata to publish > incrementally operating on stuff surrounding the list, then managing > thousands of packages becomes less of a burden. incremental update may not actually be any faster. Think about it - how would you make sure the incremental update was right? You'd have to: 1. read in all the xml 2. open and checksum(sha1, md5) compare filenames + checksums to what you just obtained add/delete/modify as necessary write back out ALL of the xml. so tell me again how much saving you're going to get? -sv From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Jan 28 18:57:09 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 28 Jan 2005 19:57:09 +0100 Subject: RFC: Soname in rpm name In-Reply-To: <41F516E6.6090206@nc.rr.com> References: <20050124144739.GC7619@angus.ind.WPI.EDU> <1106579519.25770.0.camel@opus.phy.duke.edu> <200501242321.41817.symbiont@berlios.de> <41F516E6.6090206@nc.rr.com> Message-ID: <20050128195709.0e0a4be2@python2> Jeff Johnson wrote : > %post > chattr +i `rpm -ql name` > > should make the package non-upgradeable no matter what. Nice one, "bulldozer style". Never thought of it before :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.753_FC3 Load : 0.10 0.30 0.51 From nbargnesi at gmail.com Fri Jan 28 19:28:56 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Fri, 28 Jan 2005 14:28:56 -0500 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <20050128183204.GB19188@redhat.com> References: <20050126144636.GA7010@redhat.com> <1106845150.7126.2.camel@dhcp-12.hsv.redhat.com> <3077b8a00501270948de2e9ae@mail.gmail.com> <20050127175314.GF30730@redhat.com> <3077b8a00501271352c17d7e9@mail.gmail.com> <20050127221953.GB7867@redhat.com> <3077b8a005012714492abd2fb1@mail.gmail.com> <20050127230519.GG7867@redhat.com> <3077b8a0050128100267a7e0bf@mail.gmail.com> <20050128183204.GB19188@redhat.com> Message-ID: <3077b8a00501281128dcf1752@mail.gmail.com> On Fri, 28 Jan 2005 13:32:04 -0500, Andrew Overholt wrote: > * Nick Bargnesi [2005-01-28 13:05]: > > java -version returns: > > > > java version "1.4.2" > > gcj (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) > [...] > > Thoughts? This is on an x86 platform. I tried on x86_64 last night > > with same results. > > Yeah, you need to have your java alternative set to java-1.4.2-gcj4-compat. > It looks like it's currently set to java-1.4.2-gcj-compat (which uses gij > from the 3.4.x package). > > Do the following (and note the 4s): > > su - -c "update-alternatives --set java \ > /usr/lib/jvm/jre-1.4.2-gcj4/bin/java" > su - -c "update-alternatives --set javac \ > /usr/lib/jvm/java-1.4.2-gcj4/bin/javac" > > Andrew > Using gcj4/bin/java and gcj4/bin/javac worked. Good stuff. I'll start using this as my daily environment and see what kind of bugs I can find... -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From n3npq at nc.rr.com Fri Jan 28 19:30:19 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Fri, 28 Jan 2005 14:30:19 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <20050128195709.0e0a4be2@python2> References: <20050124144739.GC7619@angus.ind.WPI.EDU> <1106579519.25770.0.camel@opus.phy.duke.edu> <200501242321.41817.symbiont@berlios.de> <41F516E6.6090206@nc.rr.com> <20050128195709.0e0a4be2@python2> Message-ID: <41FA92CB.4060000@nc.rr.com> Matthias Saou wrote: >Jeff Johnson wrote : > > > >>%post >>chattr +i `rpm -ql name` >> >>should make the package non-upgradeable no matter what. >> >> > >Nice one, "bulldozer style". Never thought of it before :-) > > You miss the point. There is simply no way for rpm (or any rpmlib based tool) to guarantee package non-upgradeability reliably. There are side effects, not only from opaque scripts, but also from system administrators, and from selinux policy, and more, that are not represented in any metadata that rpm has access to, that are necessary to make a package -- and all the package contents -- non-upgradeable. Meanwhile, it's kinda pointless to attempt to mark a package non-upgradeable imho *without* a bulldozer and more to provide the strongest possible guarantee reliably. Sure, can be done, but is trivially subverted. In fact, there's almost certainly gonna have to be Yet Another Option to rpm to disable (or otherwise manage) packaging mistakes from an advisory Autoupgrade: no marker in packaging. I question whether it's worth the complexity cost in rpm. I hope that clarifies. 73 de Jeff From fedora-devel at camperquake.de Fri Jan 28 20:05:48 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Fri, 28 Jan 2005 21:05:48 +0100 Subject: Fedora PPC things... In-Reply-To: <1106931649.9897.4.camel@localhost.localdomain> References: <1106630968.5401.42.camel@localhost.localdomain> <20050127132800.1b7918ad@nausicaa.camperquake.de> <20050127133613.7eb636f4@nausicaa.camperquake.de> <1106931649.9897.4.camel@localhost.localdomain> Message-ID: <20050128210548.45833701@nausicaa.camperquake.de> Hi. Colin Charles wrote: > File a bug, under tuxracer, report that your r128 breaks it (actually, > maybe file a bug under xorg), and make sure the arch is powerpc Problem solved, kind of. Tuxracer tries to come up in 640x480 full screen, which the LCD panel does not like at all. Hitting Esc repeatedly gets me my shell back, and I can edit the preferences then to disable fullscreen. Works fine in a window. Shouldn't tuxracer ask the X server for supported resolutions? 640x480 is definitely not configured. -- Man is incomplete until he is married. Then he is really finished. From rdieter at math.unl.edu Fri Jan 28 20:06:56 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 28 Jan 2005 14:06:56 -0600 (CST) Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: <1106937343.734.12.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> <1106937343.734.12.camel@cobra.ivg2.net> Message-ID: On Fri, 28 Jan 2005, Ivan Gyurdiev wrote: > - The -devel package should not install dead links on my system - it > should require Mesa-libGL. Agreed (or make Mesa-libGL-devel, as you suggest below, but that gets even more convoluted). > - I still say the libGL devel stuff and libGLU should be split from > xorg-x11-devel. You keep saying that. But, why? There is no other/alternative GL implementation in Core or Extras (Nvidia's doesn't/shouldn't count in this discussion). On the other hand, I thought one of Mike's original motivations for splitting off Mesa-GL was to allow for drop-in replacements. I'm not sure if there is value anymore in packaging these separately. -- Rex From ivg2 at cornell.edu Fri Jan 28 20:46:55 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 13:46:55 -0700 Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> <1106937343.734.12.camel@cobra.ivg2.net> Message-ID: <1106945215.2174.21.camel@cobra.ivg2.net> > > - I still say the libGL devel stuff and libGLU should be split from > > xorg-x11-devel. > > You keep saying that. But, why? There is no other/alternative GL > implementation in Core or Extras (Nvidia's doesn't/shouldn't count in > this discussion). Why do you keep saying that Nvidia's does not count. What exactly is the problem with their GL headers/library? > On the other hand, I thought one of Mike's original motivations for > splitting off Mesa-GL was to allow for drop-in replacements. I'm not sure > if there is value anymore in packaging these separately. I heard X will be modularized for FC5 so all libraries will be split up like that. Is that not the case? -- Ivan Gyurdiev Cornell University From kyrre at solution-forge.net Fri Jan 28 20:53:04 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Fri, 28 Jan 2005 21:53:04 +0100 Subject: fedora stable branch updates Q&A policy In-Reply-To: <1106905427.5373.57.camel@localhost.localdomain> References: <1106851614.2656.7.camel@localhost.localdomain> <1106905427.5373.57.camel@localhost.localdomain> Message-ID: <1106945584.6895.4.camel@localhost.localdomain> fre, 28.01.2005 kl. 10.43 skrev Colin Charles: > On Thu, 2005-01-27 at 19:46 +0100, Kyrre Ness Sjobak wrote: > > Personally, i would believe a q&a mailinglist and a "testing" repo for > > yum could be a good idea, in order to get packages as good tested as > > possible - as fast as possible. > > There is a testing repo, its called updates-testing (look > in /etc/yum.repos.d/fedora-updates-testing.repo). Discussion of that > happens at fedora-test-list at redhat.com as do the announcements for new > packages > > However, I don't think many folk test it and QA it, and it usually gets > pushed out as an update (updates-released) within a couple of days > > So, whats your issue with an update that Core had? Can't remember it rigth now (except my AWE 64 ISA sound board won't work with the fc2 2.6.10 kernel...), but there has been others too. I acctually *am* on the test list and has been for ? a year, but i more or less thought this was a list for the test releases leading up to the release of a stable version - and as a generally "low traffic/high clue" version of the users list when not used for this purpose. Seems like i was wrong. What about informing people on this, having a system where developers from RH (core) and non-RH (extras) can ask for Q&A? A simpler system might also be a bettetr system IMO. From rdieter at math.unl.edu Fri Jan 28 20:55:28 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 28 Jan 2005 14:55:28 -0600 (CST) Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: <1106945215.2174.21.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> <1106937343.734.12.camel@cobra.ivg2.net> <1106945215.2174.21.camel@cobra.ivg2.net> Message-ID: On Fri, 28 Jan 2005, Ivan Gyurdiev wrote: > >>> - I still say the libGL devel stuff and libGLU should be split from >>> xorg-x11-devel. >> >> You keep saying that. But, why? There is no other/alternative GL >> implementation in Core or Extras (Nvidia's doesn't/shouldn't count in >> this discussion). > > Why do you keep saying that Nvidia's does not count. Because it isn't in Core or Extras. > What exactly is the problem with their GL headers/library? Not OpenSource. > I heard X will be modularized for FC5 so all libraries will be split up > like that. Is that not the case? Where did you hear that? So it's going to get even more complicated? -- Rex From jspaleta at gmail.com Fri Jan 28 20:58:51 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 28 Jan 2005 15:58:51 -0500 Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: <1106945215.2174.21.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> <1106937343.734.12.camel@cobra.ivg2.net> <1106945215.2174.21.camel@cobra.ivg2.net> Message-ID: <604aa79105012812581a83353b@mail.gmail.com> On Fri, 28 Jan 2005 13:46:55 -0700, Ivan Gyurdiev wrote: > Why do you keep saying that Nvidia's does not count. > What exactly is the problem with their GL headers/library? nvidia's implements their own extentions to opengl. If you build an application against nvidia's headers and libraries it will most likely not work against other opengl implementations such as mesa. You end up compiling programs that need nvidia's libs... and that's burned a few community packagers in the past using system with nvidia drivers installed via nvidia's installer and then trying to hand those packages over to people using non-nvidia hardware. A fun time was had by all. If you compile against the mesa opengl headers and libs... you can run those applications with nvidia's implementation via runtime detection of the nvidia libraries. But don't take my word for it.. take a some opengl opensource apps and build them using the nvidia headers and libraries.. package them up... give it to someone who runs accelerated non-nvidia 3d hardware and watch as those apps breaks on the non-nvidia hardware. -jef"i guess there is a reason why history is doomed to repeat itself"spaleta From ivg2 at cornell.edu Fri Jan 28 21:00:39 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 14:00:39 -0700 Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> <1106937343.734.12.camel@cobra.ivg2.net> <1106945215.2174.21.camel@cobra.ivg2.net> Message-ID: <1106946039.2666.7.camel@cobra.ivg2.net> > Because it isn't in Core or Extras. So what's your point? That all software not in Core or Extras should be made more difficult to work with the distro? > > I heard X will be modularized for FC5 so all libraries will be split up > > like that. Is that not the case? > > Where did you hear that? So it's going to get even more complicated? Well, I heard this from the X package maintainer. It's also a targeted goal for the next major release on X.org I believe. -- Ivan Gyurdiev Cornell University From jspaleta at gmail.com Fri Jan 28 21:05:14 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 28 Jan 2005 16:05:14 -0500 Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: References: <41F9DA4D.7040801@tlarson.com> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> <1106937343.734.12.camel@cobra.ivg2.net> <1106945215.2174.21.camel@cobra.ivg2.net> Message-ID: <604aa791050128130510f0bc44@mail.gmail.com> On Fri, 28 Jan 2005 14:55:28 -0600 (CST), Rex Dieter wrote: > > I heard X will be modularized for FC5 so all libraries will be split up > > like that. Is that not the case? > > Where did you hear that? So it's going to get even more complicated? i've been hearing mharris wax eloquent about moving away from the 'monolithic' approach to modular pieces for X related libraries for a while now. Catching him when he's actually using eloquent speech however is a refined skill that takes much practice. I'm pretty sure modularization is on X.org's development roadmap moving foward.. but i'm not sure its wise to give a timeline as to when its ready. I have no idea what state the effort is in i dont keep up with xorg related mailinglists. -jef From ivg2 at cornell.edu Fri Jan 28 21:08:58 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 14:08:58 -0700 Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: <604aa79105012812581a83353b@mail.gmail.com> References: <41F9DA4D.7040801@tlarson.com> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> <1106937343.734.12.camel@cobra.ivg2.net> <1106945215.2174.21.camel@cobra.ivg2.net> <604aa79105012812581a83353b@mail.gmail.com> Message-ID: <1106946538.2666.14.camel@cobra.ivg2.net> On Fri, 2005-01-28 at 15:58 -0500, Jeff Spaleta wrote: > On Fri, 28 Jan 2005 13:46:55 -0700, Ivan Gyurdiev wrote: > > Why do you keep saying that Nvidia's does not count. > > What exactly is the problem with their GL headers/library? > > nvidia's implements their own extentions to opengl. If you build an > application against nvidia's headers and libraries it will most likely > not work against other opengl implementations such as mesa. Does 'extensions' not imply that they're optional? If you don't use extensions would it break? How do you make use of the Nvidia extensions with the Mesa headers? -- Ivan Gyurdiev Cornell University From jspaleta at gmail.com Fri Jan 28 21:19:13 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 28 Jan 2005 16:19:13 -0500 Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: <1106946538.2666.14.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> <1106937343.734.12.camel@cobra.ivg2.net> <1106945215.2174.21.camel@cobra.ivg2.net> <604aa79105012812581a83353b@mail.gmail.com> <1106946538.2666.14.camel@cobra.ivg2.net> Message-ID: <604aa7910501281319674b656d@mail.gmail.com> On Fri, 28 Jan 2005 14:08:58 -0700, Ivan Gyurdiev wrote: > Does 'extensions' not imply that they're optional? > If you don't use extensions would it break? you would think that... but as soon as you build applications against the nvidia headers.. you see such a rational thought contradicts reality. Building the apps exactly the same way with exactly the same compile time options...gives you exactly what you don't want.. binaries tied to nvidia's libs. > > How do you make use of the Nvidia extensions with the Mesa headers? You dont. if you really really really want to tie your binary to the existence of nvidia hardware and libs.. you use nvidia's headers and libs at compile time. And with livna's rpms you can do exactly that by setting appropriate -L and -I to point to the nvidia libs and headers when you are building/linking at compile time. This however is seldom something a community contributor wants to do. I think at this point... your questions are best answered by rebuilding sourcecode into binaries for yourself and watching the truth unfold. Or digging into archives and into old bugtickets that have gone over exact this same ground with community packagers. -jef From ivg2 at cornell.edu Fri Jan 28 21:24:12 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 28 Jan 2005 14:24:12 -0700 Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: <604aa7910501281319674b656d@mail.gmail.com> References: <41F9DA4D.7040801@tlarson.com> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> <1106937343.734.12.camel@cobra.ivg2.net> <1106945215.2174.21.camel@cobra.ivg2.net> <604aa79105012812581a83353b@mail.gmail.com> <1106946538.2666.14.camel@cobra.ivg2.net> <604aa7910501281319674b656d@mail.gmail.com> Message-ID: <1106947452.2936.8.camel@cobra.ivg2.net> > you would think that... but as soon as you build applications against > the nvidia headers.. you see such a rational thought contradicts > reality. Well that sucks. Sounds like a bug that should be fixed by Nvidia then. > > How do you make use of the Nvidia extensions with the Mesa headers? > You dont. > > if you really really really want to tie your binary to the existence > of nvidia hardware and libs.. you use nvidia's headers and libs at > compile time. And with livna's rpms you can do exactly that by setting > appropriate -L and -I to point to the nvidia libs and headers when you > are building/linking at compile time. This however is seldom > something a community contributor wants to do. I don't know what kind of extensions are offered. If some of them optimize for nvidia hardware then it makes perfect sense to me. > I think at this point... your questions are best answered by > rebuilding sourcecode into binaries for yourself and watching the > truth unfold. Heh, okay I give up on this. -- Ivan Gyurdiev Cornell University From notting at redhat.com Fri Jan 28 21:27:37 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 28 Jan 2005 16:27:37 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050128160159.277368cc.fedora@wir-sind-cool.org> References: <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <604aa791050128052019332617@mail.gmail.com> <1106920582.19595.101.camel@localhost.localdomain> <20050128160159.277368cc.fedora@wir-sind-cool.org> Message-ID: <20050128212736.GA3808@nostromo.devel.redhat.com> Michael Schwendt (fedora at wir-sind-cool.org) said: > On Fri, 28 Jan 2005 14:56:22 +0100, Peter Backlund wrote: > > > Yes, it works fine with the Bluecurve xmms skin. There is an environment > > variable that lists additional directories to look for skins in, which > > conveniently contains /usr/share/xmms/Skins in the livna.org package > > (through an /etc/profile.d/ file), so that the BC skin can be used > > immediately. Same goes for the Industrial skin, from ximian- > > artwork. > > Would be good if something like this could be added to the profile.d: > > skin=$(gconftool-2 --get /apps/bmp/skin 2> /dev/null) > if [ -z "$skin" -a -f /usr/share/xmms/Skins/Bluecurve-xmms.zip ]; then > gconftool-2 --set /apps/bmp/skin --type string \ > /usr/share/xmms/Skins/Bluecurve-xmms.zip &> /dev/null > fi > > What it does is to make the Bluecurve skin the default if user has > not set a different one already. There's a suitably gross make-bluecurve-the-default skin patch in xmms. Depending on which bits of the xmms architecture they kept, it may apply (haven't looked at bmp.) Bill From jspaleta at gmail.com Fri Jan 28 21:28:22 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 28 Jan 2005 16:28:22 -0500 Subject: fedora stable branch updates Q&A policy In-Reply-To: <1106945584.6895.4.camel@localhost.localdomain> References: <1106851614.2656.7.camel@localhost.localdomain> <1106905427.5373.57.camel@localhost.localdomain> <1106945584.6895.4.camel@localhost.localdomain> Message-ID: <604aa791050128132862225bfe@mail.gmail.com> On Fri, 28 Jan 2005 21:53:04 +0100, Kyrre Ness Sjobak wrote: > What about informing people on this, having a system where developers > from RH (core) and non-RH (extras) can ask for Q&A? A simpler system > might also be a bettetr system IMO. I've seen very little evidence that Red Hat packagers are interested in a policy that enforces specific QA steps as policy for 'all' updates. And be aware that the issue of 'strict' QA policy gets complicated by the existence of security updates. To be fair.. i do believe the kernel packagers have been populating updates-testing tree in a timely manner to get as much community feedback as they can. There is an kernel in updates-testing right now in fact. I do what I can to encourage Core package maintainers to use updates-testing as much as possible, and my encouragement becomes proportionally more aggressive when a notice a regression slip through in an non-security update. My eye-poking stick has become quite blunt and sticky slick with blood from the effort to 'encourage' packagers to use -testing. -jef"place my last sentence here"spaleta From mbneto at gmail.com Fri Jan 28 21:43:33 2005 From: mbneto at gmail.com (mbneto) Date: Fri, 28 Jan 2005 17:43:33 -0400 Subject: Eclipse 3.1 (was Re: rawhide report: 20050126 changes) In-Reply-To: <20050128183204.GB19188@redhat.com> References: <20050126144636.GA7010@redhat.com> <1106845150.7126.2.camel@dhcp-12.hsv.redhat.com> <3077b8a00501270948de2e9ae@mail.gmail.com> <20050127175314.GF30730@redhat.com> <3077b8a00501271352c17d7e9@mail.gmail.com> <20050127221953.GB7867@redhat.com> <3077b8a005012714492abd2fb1@mail.gmail.com> <20050127230519.GG7867@redhat.com> <3077b8a0050128100267a7e0bf@mail.gmail.com> <20050128183204.GB19188@redhat.com> Message-ID: <5cf776b80501281343196d9980@mail.gmail.com> Hi Andrew, I could not find the files needed (i.e the update alternatives fails) rpm -qa | egrep 'java|jdk|jre|j2re|gcj' libgcj-devel-3.4.3-17 jdk-1.5.0-fcs j2re-1.4.2-11.1.fc3.rf libgcj4-4.0.0-0.22 gcc-java-3.4.3-17 libgcj4-devel-4.0.0-0.22 java-1.4.2-gcj4-compat-1.4.2.0-3jpp libgcj-3.4.3-17 gcc4-java-4.0.0-0.22 What's missing ? On Fri, 28 Jan 2005 13:32:04 -0500, Andrew Overholt wrote: > * Nick Bargnesi [2005-01-28 13:05]: > > java -version returns: > > > > java version "1.4.2" > > gcj (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) > [...] > > Thoughts? This is on an x86 platform. I tried on x86_64 last night > > with same results. > > Yeah, you need to have your java alternative set to java-1.4.2-gcj4-compat. > It looks like it's currently set to java-1.4.2-gcj-compat (which uses gij > from the 3.4.x package). > > Do the following (and note the 4s): > > su - -c "update-alternatives --set java \ > /usr/lib/jvm/jre-1.4.2-gcj4/bin/java" > su - -c "update-alternatives --set javac \ > /usr/lib/jvm/java-1.4.2-gcj4/bin/javac" > > Andrew > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > From rdieter at math.unl.edu Fri Jan 28 21:51:20 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 28 Jan 2005 15:51:20 -0600 (CST) Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: <1106946039.2666.7.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> <1106937343.734.12.camel@cobra.ivg2.net> <1106945215.2174.21.camel@cobra.ivg2.net> <1106946039.2666.7.camel@cobra.ivg2.net> Message-ID: On Fri, 28 Jan 2005, Ivan Gyurdiev wrote: >> Because it isn't in Core or Extras. > So what's your point? That all software not in Core or Extras > should be made more difficult to work with the distro? You conveniently snipped the "It's not OpenSource" bit... (-: -- rex From Nicolas.Mailhot at laPoste.net Fri Jan 28 21:57:29 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Fri, 28 Jan 2005 22:57:29 +0100 Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> <1106937343.734.12.camel@cobra.ivg2.net> <1106945215.2174.21.camel@cobra.ivg2.net> Message-ID: <1106949449.25801.36.camel@rousalka.dyndns.org> Le vendredi 28 janvier 2005 ? 14:55 -0600, Rex Dieter a ?crit : > On Fri, 28 Jan 2005, Ivan Gyurdiev wrote: > > I heard X will be modularized for FC5 so all libraries will be split up > > like that. Is that not the case? > > Where did you hear that? So it's going to get even more complicated? Xorg people want to unbundle the big pile of code they inherited from XFree86, so they don't have to ship anymore copies of other people stuff (fontconfig, mesa, xterm...), it builds using mainstream autoconf* scripts, drivers can be released as a different pace than the core package (so no full rebuild each time you need to add a new card), etc It means packaging will probably get easier because you won't have an enormous srpm that generates scores of packages (with a large part of the big archive content disable to use system libraries instead) but lots of different source archives. I doubt they manage to pull it out for FC5 though - it's an enormous task and all the OS are not created equal (some do not have their own fontconfig module...), so some port maintainers push for keeping an unified blob. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From fedora at wir-sind-cool.org Fri Jan 28 23:03:40 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 29 Jan 2005 00:03:40 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050128212736.GA3808@nostromo.devel.redhat.com> References: <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <604aa791050128052019332617@mail.gmail.com> <1106920582.19595.101.camel@localhost.localdomain> <20050128160159.277368cc.fedora@wir-sind-cool.org> <20050128212736.GA3808@nostromo.devel.redhat.com> Message-ID: <20050129000340.04b76dc7.fedora@wir-sind-cool.org> On Fri, 28 Jan 2005 16:27:37 -0500, Bill Nottingham wrote: > > On Fri, 28 Jan 2005 14:56:22 +0100, Peter Backlund wrote: > > > > > Yes, it works fine with the Bluecurve xmms skin. There is an environment > > > variable that lists additional directories to look for skins in, which > > > conveniently contains /usr/share/xmms/Skins in the livna.org package > > > (through an /etc/profile.d/ file), so that the BC skin can be used > > > immediately. Same goes for the Industrial skin, from ximian- > > > artwork. > > > > Would be good if something like this could be added to the profile.d: > > > > skin=$(gconftool-2 --get /apps/bmp/skin 2> /dev/null) > > if [ -z "$skin" -a -f /usr/share/xmms/Skins/Bluecurve-xmms.zip ]; then > > gconftool-2 --set /apps/bmp/skin --type string \ > > /usr/share/xmms/Skins/Bluecurve-xmms.zip &> /dev/null > > fi > > > > What it does is to make the Bluecurve skin the default if user has > > not set a different one already. > > There's a suitably gross make-bluecurve-the-default skin patch in xmms. > Depending on which bits of the xmms architecture they kept, it > may apply (haven't looked at bmp.) Had a look. Doesn't apply. But this one does and works, too, because the skin loader falls back to the "Default" skin if Bluecurve skin isn't found. bmp-0.9.7-default-skin.patch diff -Nur bmp-0.9.7/beep/main.c bmp-0.9.7-modified/beep/main.c --- bmp-0.9.7/beep/main.c 2004-12-04 10:04:24.000000000 +0100 +++ bmp-0.9.7-modified/beep/main.c 2005-01-28 23:54:17.938968912 +0100 @@ -144,7 +144,7 @@ 0.0, /* equalizer preamp */ {0, 0, 0, 0, 0, /* equalizer bands */ 0, 0, 0, 0, 0}, - NULL, /* skin */ + "/usr/share/xmms/Skins/Bluecurve-xmms.zip", /* skin */ NULL, /* output plugin */ NULL, /* file selector path */ NULL, /* playlist path */ From reuben-fedora-devel at reub.net Fri Jan 28 23:59:20 2005 From: reuben-fedora-devel at reub.net (Reuben Farrelly) Date: Sat, 29 Jan 2005 12:59:20 +1300 Subject: Sample initscript/standard Message-ID: <6.2.1.2.2.20050129125000.01c32ea8@tornado.reub.net> Hi, I'm trying to fix up a rather messy looking boot sequence in -devel. Some are just noisy packages such as dhcpd that I'll be filing bugs against in bugzilla soon and others just do silly things like print [OK] or do newlines twice, but others are external packages such as amavisd-new which need to be fixed outside of the distribution. Is there a sample skeleton /etc/init.d/ script anywhere which I can regard as an 'authoritative' script to base work on, and fix up other non-Fedora initscripts from? I had a feeling there was one in /usr/share/doc/initscripts-*/ but seems not... Is there in fact a standard way of writing an initscript file? By looking at some in the init.d directory, it seems like there are a few different 'standards' :( Thanks, Reuben From enrico.scholz at informatik.tu-chemnitz.de Sat Jan 29 00:09:16 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 29 Jan 2005 01:09:16 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050129000340.04b76dc7.fedora@wir-sind-cool.org> (Michael Schwendt's message of "Sat, 29 Jan 2005 00:03:40 +0100") References: <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <604aa791050128052019332617@mail.gmail.com> <1106920582.19595.101.camel@localhost.localdomain> <20050128160159.277368cc.fedora@wir-sind-cool.org> <20050128212736.GA3808@nostromo.devel.redhat.com> <20050129000340.04b76dc7.fedora@wir-sind-cool.org> Message-ID: <87pszpdrkj.fsf@kosh.ultra.csn.tu-chemnitz.de> fedora at wir-sind-cool.org (Michael Schwendt) writes: >> There's a suitably gross make-bluecurve-the-default skin patch in >> xmms. Depending on which bits of the xmms architecture they kept, it >> may apply (haven't looked at bmp.) > > Had a look. Doesn't apply. But this one does and works, too, because the > skin loader falls back to the "Default" skin if Bluecurve skin isn't > found. > > bmp-0.9.7-default-skin.patch I hope, this would not reopen https://bugzilla.redhat.com/beta/show_bug.cgi?id=71009 Enrico From fedora at wir-sind-cool.org Sat Jan 29 00:12:38 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 29 Jan 2005 01:12:38 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <87pszpdrkj.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <604aa791050128052019332617@mail.gmail.com> <1106920582.19595.101.camel@localhost.localdomain> <20050128160159.277368cc.fedora@wir-sind-cool.org> <20050128212736.GA3808@nostromo.devel.redhat.com> <20050129000340.04b76dc7.fedora@wir-sind-cool.org> <87pszpdrkj.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <20050129011238.1332496d.fedora@wir-sind-cool.org> On Sat, 29 Jan 2005 01:09:16 +0100, Enrico Scholz wrote: > >> There's a suitably gross make-bluecurve-the-default skin patch in > >> xmms. Depending on which bits of the xmms architecture they kept, it > >> may apply (haven't looked at bmp.) > > > > Had a look. Doesn't apply. But this one does and works, too, because the > > skin loader falls back to the "Default" skin if Bluecurve skin isn't > > found. > > > > bmp-0.9.7-default-skin.patch > > I hope, this would not reopen > https://bugzilla.redhat.com/beta/show_bug.cgi?id=71009 I fail to see any relationship. From jwz at jwz.org Sat Jan 29 01:11:27 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Fri, 28 Jan 2005 17:11:27 -0800 Subject: grip being removed [Re: rawhide report: 20050120 changes] References: <1106333362.3427.19.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <20050128120336.21dad318.fedora@wir-sind-cool.org> Message-ID: <41FAE2BF.4EF5FD29@jwz.org> Michael Schwendt wrote: > > Totem uses GStreamer, and hence gstreamer-plugins-mp3 from the same > old http://rpm.livna.org repository works just fine. Ok, now that Totem can play MP3s, it seems not-totally-unacceptable, but it's still inferior to xmms/bmp in several ways: - It uses a *huge* amount of CPU. When I was running xmms or bmp, my load was hovering around 0.6; Totem makes it oscillate between 2.8 and 3.8! - When listening to an icecast stream, there is no indication of what URL you are actually listening to ("Movie/Properties" doesn't show anything.) - Likewise, no metadata at all - no channel or song titles. - I don't see a way to turn off the big black "movie display" window. Jeff Spaleta wrote: > > And the 'default is crap' issue is a red herring, > because "if" its going to be re-packaged for core, I'm sure the > bluecurve xmms theme core is now using would be used for bmp... which > works just fine for bmp from what i can tell. BMP is not so bad with the bluecurve-xmms theme, but it's still way, way too small. You must have either bigger pixels or much better eyes than I do, because I just can't read five-point light-gray-on-white type. (Maybe it would work to just double the size of all the image-files in the theme, if a "Double Size" option isn't to be implemented?) BMP also has the problem that when you have an Icecast URL in the playlist window, there's no way to tell what its URL is -- all it will show you is the last title or metadata the stream had, so you know the last song you heard on it, but not what station it is. So, if you want to ditch XMMS, I think some hacking is still needed. Neither of these programs quite cut it yet. (And I don't think I'm making power-user requests here or anything, these are just basic usability regressions.) -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From jspaleta at gmail.com Sat Jan 29 01:21:00 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 28 Jan 2005 20:21:00 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FAE2BF.4EF5FD29@jwz.org> References: <1106333362.3427.19.camel@localhost.localdomain> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <20050128120336.21dad318.fedora@wir-sind-cool.org> <41FAE2BF.4EF5FD29@jwz.org> Message-ID: <604aa7910501281721741be6c4@mail.gmail.com> On Fri, 28 Jan 2005 17:11:27 -0800, Jamie Zawinski wrote: > So, if you want to ditch XMMS, I think some hacking is still needed. > Neither of these programs quite cut it yet. (And I don't think I'm > making power-user requests here or anything, these are just basic > usability regressions.) Sounds to me like inclusion into Fedora Core will help the bmp developers polish up the remaining usability issues by xposing the bmp to a large userbase of users like yourself.. committed to usability excellence. Thanks for volunteering to help the bmp developers work through the remaining usability issues. -jef From ivazquez at ivazquez.net Sat Jan 29 01:32:00 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 28 Jan 2005 20:32:00 -0500 Subject: Sample initscript/standard In-Reply-To: <6.2.1.2.2.20050129125000.01c32ea8@tornado.reub.net> References: <6.2.1.2.2.20050129125000.01c32ea8@tornado.reub.net> Message-ID: <1106962320.17286.1.camel@ignacio.ignacio.lan> On Sat, 2005-01-29 at 12:59 +1300, Reuben Farrelly wrote: > Is there a sample skeleton /etc/init.d/ script anywhere which I can regard > as an 'authoritative' script to base work on, and fix up other non-Fedora > initscripts from? I had a feeling there was one in > /usr/share/doc/initscripts-*/ but seems not... /usr/share/doc/initscripts-*/sysvinitfiles contains both a skeleton script and documentation. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jwz at jwz.org Sat Jan 29 01:37:37 2005 From: jwz at jwz.org (Jamie Zawinski) Date: Fri, 28 Jan 2005 17:37:37 -0800 Subject: grip being removed [Re: rawhide report: 20050120 changes] References: <1106333362.3427.19.camel@localhost.localdomain> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <20050128120336.21dad318.fedora@wir-sind-cool.org> <41FAE2BF.4EF5FD29@jwz.org> <604aa7910501281721741be6c4@mail.gmail.com> Message-ID: <41FAE8E1.6AE64597@jwz.org> Jeff Spaleta wrote: > > Thanks for volunteering to help the bmp developers work > through the remaining usability issues. Yes, by all means, let's improve the Linux user experience by replacing working tools with half-working tools. -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From jspaleta at gmail.com Sat Jan 29 02:48:38 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 28 Jan 2005 21:48:38 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FAE8E1.6AE64597@jwz.org> References: <1106333362.3427.19.camel@localhost.localdomain> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <20050128120336.21dad318.fedora@wir-sind-cool.org> <41FAE2BF.4EF5FD29@jwz.org> <604aa7910501281721741be6c4@mail.gmail.com> <41FAE8E1.6AE64597@jwz.org> Message-ID: <604aa791050128184867367312@mail.gmail.com> On Fri, 28 Jan 2005 17:37:37 -0800, Jamie Zawinski wrote: > Yes, by all means, let's improve the Linux user experience by > replacing working tools with half-working tools. half working? that would be an emacs based media player.. im sure we could dig one up if people are interested. -jef From symbiont at berlios.de Sat Jan 29 01:54:21 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Sat, 29 Jan 2005 09:54:21 +0800 Subject: redhat abe In-Reply-To: <1106937879.26755.6.camel@cutter> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> Message-ID: <200501290954.22339.symbiont@berlios.de> On Saturday 29 January 2005 02:44, seth vidal wrote: > so tell me again how much saving you're going to get? The exercise is to attempt a method in which you save computation of md5 or sha1, as these are one of the time consuming steps of createrepo. The save would be in a 100k package repository: (100,000 - N) * Time(sum_calc), where N equals the number of packages that *need* to generate sums for. A parameterized list of package names passed into createrepo would be sufficient to figure out what composes the N list. An external process, such as a Manifest list, would then be used to mitigate a set of packages through the entire build process. Apt uses a md5sum cache, but having fine-tuned controlled of the process would be more stable and directed. This is how much saving you'd get for #2. Now for #1, to save tremendously on xml read in and write out, would require a re-think for the on-disk format. I know some are looking at a possible sqlite store .. which will be interesting ... berkley db with its binary tree store--allowing fast inserts--would also be interesting .. but I think our real win, at this time, would be #2. -- -jeff From dave at webaugur.com Sat Jan 29 07:02:38 2005 From: dave at webaugur.com (David L Norris) Date: Sat, 29 Jan 2005 02:02:38 -0500 Subject: Our Discussion on Fedora-docs [Fwd: Re: Fedora Documentation Search Engine] In-Reply-To: <42853.193.195.148.66.1106926064.squirrel@webmail.suretecsystems.com> References: <42853.193.195.148.66.1106926064.squirrel@webmail.suretecsystems.com> Message-ID: <1106982158.17012.200.camel@Daneel.WebAugur.com> On Fri, 2005-01-28 at 15:27 +0000, Gavin Henry wrote: > I thought that maybe you guys would have some input on this? > > We heavily use Swish-e (www.swish-e.org) for the fileservers we install. > This can handle html, xhtml, txt, pdf and the like. > > I've just looked at the page now, but it looks like a very useful bit of > software. Swish-e doesn't support incremental indexing very well (yet). Right now you're looking at a complete reindex every night or at least after every change. Swish-e doesn't support Unicode. Although we've been discussing (on swishe-cvs list and privately) a major overhaul for Swish-e 3.0 to fix those things and remove the legacy Swish code. We could use the help of a developer who is familiar with porting applications to Unicode. Swish-e Resources: http://swish-e.org/ http://sourceforge.net/projects/swishe/ http://swishewiki.org/ Also, Josh Rabinowitz wrote a Perl script called sman which uses libswish-e and SWISH::API to provide a more featureful replacement to apropos. If there's interest in getting Swish-e into Fedora Extras then I'd be willing to commit any required changes upstream. There are a few Perl issues that have kept me from completing the RPMs. SWISH::API is particularly difficult to package because it assumes libswish-e is already installed. -- David Norris http://www.webaugur.com/dave/ ICQ - 412039 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at phy.duke.edu Sat Jan 29 07:36:09 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 29 Jan 2005 02:36:09 -0500 Subject: redhat abe In-Reply-To: <200501290954.22339.symbiont@berlios.de> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> Message-ID: <1106984170.1614.34.camel@cutter> > The exercise is to attempt a method in which you save computation of md5 > or sha1, as these are one of the time consuming steps of createrepo. > The save would be in a 100k package repository: (100,000 - N) * > Time(sum_calc), where N equals the number of packages that *need* to > generate sums for. A parameterized list of package names passed into > createrepo would be sufficient to figure out what composes the N list. > An external process, such as a Manifest list, would then be used to > mitigate a set of packages through the entire build process. Apt uses > a md5sum cache, but having fine-tuned controlled of the process would > be more stable and directed. This is how much saving you'd get for #2. Let me know when you've figured it out but as it stands I don't think incrementally updating the metadata is very feasible. -sv From shiva at sewingwitch.com Sat Jan 29 08:09:46 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Sat, 29 Jan 2005 00:09:46 -0800 Subject: Sample initscript/standard In-Reply-To: <1106962320.17286.1.camel@ignacio.ignacio.lan> References: <6.2.1.2.2.20050129125000.01c32ea8@tornado.reub.net> <1106962320.17286.1.camel@ignacio.ignacio.lan> Message-ID: --On Friday, January 28, 2005 8:32 PM -0500 Ignacio Vazquez-Abrams wrote: > /usr/share/doc/initscripts-*/sysvinitfiles contains both a skeleton > script and documentation. Excellent! I was just about to do this for a new package and this is very serendipitous. From byte at aeon.com.my Sat Jan 29 08:41:49 2005 From: byte at aeon.com.my (Colin Charles) Date: Sat, 29 Jan 2005 14:11:49 +0530 Subject: fedora stable branch updates Q&A policy In-Reply-To: <1106945584.6895.4.camel@localhost.localdomain> References: <1106851614.2656.7.camel@localhost.localdomain> <1106905427.5373.57.camel@localhost.localdomain> <1106945584.6895.4.camel@localhost.localdomain> Message-ID: <1106988109.11086.28.camel@localhost.localdomain> On Fri, 2005-01-28 at 21:53 +0100, Kyrre Ness Sjobak wrote: > Can't remember it rigth now (except my AWE 64 ISA sound board won't > work > with the fc2 2.6.10 kernel...), but there has been others too. File a bug in Bugzilla > I acctually *am* on the test list and has been for ? a year, but i > more > or less thought this was a list for the test releases leading up to > the > release of a stable version - and as a generally "low traffic/high > clue" > version of the users list when not used for this purpose. Seems like i > was wrong. updates-testing "advisories" (announcements really) are posted to fedora-test-lits at redhat.com This is the development list, for general development issues and whatever we lead up to FC(n+1) When we do release FC(n+1) test X, those discussions get moved to fedora-test-list at redhat.com -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From ghenry at suretecsystems.com Sat Jan 29 09:19:51 2005 From: ghenry at suretecsystems.com (Gavin Henry) Date: Sat, 29 Jan 2005 09:19:51 +0000 Subject: Our Discussion on Fedora-docs [Fwd: Re: Fedora Documentation Search Engine] In-Reply-To: <1106982158.17012.200.camel@Daneel.WebAugur.com> References: <42853.193.195.148.66.1106926064.squirrel@webmail.suretecsystems.com> <1106982158.17012.200.camel@Daneel.WebAugur.com> Message-ID: <200501290919.51702.ghenry@suretecsystems.com> On Saturday 29 Jan 2005 07:02, David L Norris wrote: > On Fri, 2005-01-28 at 15:27 +0000, Gavin Henry wrote: > > I thought that maybe you guys would have some input on this? > > > > > We heavily use Swish-e (www.swish-e.org) for the fileservers we > > > install. > > > > This can handle html, xhtml, txt, pdf and the like. > > > > I've just looked at the page now, but it looks like a very useful bit of > > software. > > Swish-e doesn't support incremental indexing very well (yet). Right now > you're looking at a complete reindex every night or at least after every > change. Swish-e doesn't support Unicode. Although we've been > discussing (on swishe-cvs list and privately) a major overhaul for > Swish-e 3.0 to fix those things and remove the legacy Swish code. We > could use the help of a developer who is familiar with porting > applications to Unicode. > > Swish-e Resources: > http://swish-e.org/ > http://sourceforge.net/projects/swishe/ > http://swishewiki.org/ > > Also, Josh Rabinowitz wrote a Perl script called sman which uses > libswish-e and SWISH::API to provide a more featureful replacement to > apropos. > > If there's interest in getting Swish-e into Fedora Extras then I'd be > willing to commit any required changes upstream. There are a few Perl > issues that have kept me from completing the RPMs. SWISH::API is > particularly difficult to package because it assumes libswish-e is > already installed. I would be very interested in getting it into Extras and even help with the incremental stuff. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1467 624141 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ From mharris at www.linux.org.uk Sat Jan 29 09:34:46 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Sat, 29 Jan 2005 04:34:46 -0500 Subject: lib{GL, GLU}-devel suggestion (was: Re: grip being removed [Re: rawhide report: 20050120 changes]) In-Reply-To: <1106929038.26304.17.camel@cobra.ivg2.net> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> Message-ID: <41FB58B6.40008@www.linux.org.uk> Ivan Gyurdiev wrote: > P.S. Speaking of the Nvidia driver, will somebody please consider > splitting xorg-x11-Mesa-libGL-devel and xorg-x11-Mesa-libGLU-devel in > their own packages where they belong. As I mentioned in the bug report you've referenced above, this issue will be addressed in a future Fedora Core release after the modularized X.Org X11 is completed and integrated into the distribution. It is hard to say what specific Fedora Core release that will be, as we don't have a specific timetable for X11R7 yet. The issue is deferred until X11R7 is available and we begin integrating it into the distribution. At that point, we'll reopen the bug and set the status to "RAWHIDE" to indicate the change is complete. If I had to hazard a guess, it would be Fedora Core 5 at the earliest, and probably Fedora Core 5 at the latest. > I tried discussing this with the > maintainer, but he disappeared in the middle of the discussion and the > bug was left unresolved, pending FC4, which makes no sense to me. > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145287 After my last comment in the bug, I felt the discussion was over as I had already described the problem, some suggested workarounds, the solution we will be implementing for this, and a rough timeframe, and I didn't (and don't) have anything additional to add, having already provided all of my thoughts on the matter in the bug report. I disappeared at the end of the discussion rather than the middle. ;o) Thanks for your report though, and I hope this clarifies any confusion in the comments in the bug report. Take care, TTYL From rbultje at ronald.bitfreak.net Sat Jan 29 09:39:55 2005 From: rbultje at ronald.bitfreak.net (Ronald S. Bultje) Date: Sat, 29 Jan 2005 10:39:55 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FAE2BF.4EF5FD29@jwz.org> References: <1106333362.3427.19.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <20050128120336.21dad318.fedora@wir-sind-cool.org> <41FAE2BF.4EF5FD29@jwz.org> Message-ID: <1106991595.2896.73.camel@tux.lan> On Sat, 2005-01-29 at 02:11, Jamie Zawinski wrote: > - I don't see a way to turn off the big black "movie display" window. I actually intend to "fix" that sometime soon by simply hiding the window if the media contains no video and there is no visualization. However, that'll probably have to wait for a short while. Feel free to supply a patch, I'll happily accept it (can't be more than a few lines of code). Ronald -- Ronald S. Bultje From reuben-fedora-devel at reub.net Sat Jan 29 09:51:15 2005 From: reuben-fedora-devel at reub.net (Reuben Farrelly) Date: Sat, 29 Jan 2005 22:51:15 +1300 Subject: Sample initscript/standard In-Reply-To: <1106962320.17286.1.camel@ignacio.ignacio.lan> References: <6.2.1.2.2.20050129125000.01c32ea8@tornado.reub.net> <1106962320.17286.1.camel@ignacio.ignacio.lan> Message-ID: <6.2.1.2.2.20050129213229.03d053e0@tornado.reub.net> Hi, At 02:32 p.m. 29/01/2005, Ignacio Vazquez-Abrams wrote: >On Sat, 2005-01-29 at 12:59 +1300, Reuben Farrelly wrote: > > Is there a sample skeleton /etc/init.d/ script anywhere which I can regard > > as an 'authoritative' script to base work on, and fix up other non-Fedora > > initscripts from? I had a feeling there was one in > > /usr/share/doc/initscripts-*/ but seems not... > >/usr/share/doc/initscripts-*/sysvinitfiles contains both a skeleton >script and documentation. True. But it was last modified on June 26 2002 and refers to "Red Hat Linux 7". That makes it 2 1/2 years old, and no doubt somewhat out of date by now. I am certain there have been subtle and slight changes to the way the initscripts work between then and now...such as the use of $RETVAL. It seems to be after having a look through the files today that there is only a loosely documented standard within Redhat/Fedora core for the init files, and perhaps it would be a useful thing for someone to actually define _precisely_ how these scripts are to be written and what format to use. The example in the abovementioned file is very brief. For example, do the functions live at the top, within, or at the bottom of the script? Should a licence be listed at the top like the smartd init script? Should the program be defined as "$PROG" at the top or just substituted all through the script via things like 'daemon $PROG' or just 'daemon xyzd' ? How should the start and stop functions be defined? (smartd, kudzu differ from many others a little) Should ALL scripts display OK when done, and have a corresponding shutdown symlink? As an exercise in tidyness and pedanticism, I have been going through the various init.d scripts today and found a heap of scripts that do not seem to even indicate completion or success with "[ OK ]". Namely: nifd readahead readahead_early rhnsd iptables (if no rules specified - this may be OK) rpcgssd rpcsvcgssd netfs (no [ OK ] message for shutting down but OK for starting up). Bugzilla reports on those to be filed as clearly some should be doing this. Some simply silently start, others say "Starting xyz" and then omit a , some appear to return [ OK ] twice. All obvious if only loading up to runlevel 3 (as my server does) and looks pretty messy. Not everyone goes graphical ;-) I haven't even begun to check how many startup scripts (Sxx) have matching shutdown (Kxx) scripts...not even sure if this is mandatory or not. A good start would be an update to the sysvinitfiles document by someone who knows precisely the format and rules. Someone? reuben From ivazquez at ivazquez.net Sat Jan 29 10:03:18 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 29 Jan 2005 05:03:18 -0500 Subject: Sample initscript/standard In-Reply-To: <6.2.1.2.2.20050129213229.03d053e0@tornado.reub.net> References: <6.2.1.2.2.20050129125000.01c32ea8@tornado.reub.net> <1106962320.17286.1.camel@ignacio.ignacio.lan> <6.2.1.2.2.20050129213229.03d053e0@tornado.reub.net> Message-ID: <1106992998.17286.4.camel@ignacio.ignacio.lan> On Sat, 2005-01-29 at 22:51 +1300, Reuben Farrelly wrote: > I haven't even begun to check how many startup scripts (Sxx) have matching > shutdown (Kxx) scripts...not even sure if this is mandatory or not. Well, any lack of matching symlinks should indicate a failure of the package to call chkconfig --add in %post and not any problem in the init script itself. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mharris at www.linux.org.uk Sat Jan 29 10:04:45 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Sat, 29 Jan 2005 05:04:45 -0500 Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> <1106937343.734.12.camel@cobra.ivg2.net> Message-ID: <41FB5FBD.5060906@www.linux.org.uk> Rex Dieter wrote: >> - I still say the libGL devel stuff and libGLU should be split from >> xorg-x11-devel. > > > You keep saying that. But, why? There is no other/alternative GL > implementation in Core or Extras (Nvidia's doesn't/shouldn't count in > this discussion). > > On the other hand, I thought one of Mike's original motivations for > splitting off Mesa-GL was to allow for drop-in replacements. I'm not > sure if there is value anymore in packaging these separately. The purpose of splitting out libGL and libGLU was indeed to allow 3rd party rpm packages to install alternative implementations of libGL and/or libGLU at the request of a partner. It was a very reasonable request, and so it got implemented a number of OS releases back. It is entirely preferred, to have -devel packages for the libraries shipped in the OS, and to that effect, having -devel packages for libGL and libGLU is no different. When this was implemented however, -devel packages did not get created, however that was not an intentional decision really. It "just happened that way" essentially, and nobody ever reported any problems, or pointed out the fact that the development bits weren't also split out, so it stayed that way over time. Eventually someone did point out the problem, but also pointed out it wasn't a big deal because it was only a problem if you were using unsupported 3rd party drivers, and it was pretty easy to work around the issue. At the time this was discovered in that particular OS development cycle, it was beyond the freeze date to which additional packages or subpackages could be added to the OS, and since it was a low impact issue, which only affected incorrectly installed unsupported 3rd party drivers, it was definitely not a priority to break our freeze for. I don't remember which OS release that was exactly, but there have only been maybe 3 people in 2 years ever even notice the problem and point it out, so it isn't a major flaw in the OS really, but rather just a minor inconvenience for some systems with unsupported software installed. The issue basically fell between the cracks after that, due to the low number of people reporting the issue and it's relative low priority. Having given the background now, I do believe the correct solution is to have separate -devel packages for those libs, for consistency if nothing else, and we will indeed do this in a future OS release. Fixing the issue will have some build dependancy problems in the OS and with some 3rd party rpm packages that do not specify virtual requires for the libGL and libGLU virtual provides, so fixing this in an erratum, will not be considered an option. The time to fix this, is in a development cycle, in which we're updating to a major new release of the X window system (so we can easily share one src.rpm between multiple OS's without major ugly hacks to the spec file for one OS release). When we jump to X11R7, that will be the right time, and there will be quite a few xorg packaging changes, which make the impact of the change much smaller also, and so that's when we'll make the change. Hope this helps. From rahulsundaram at yahoo.co.in Sat Jan 29 09:34:47 2005 From: rahulsundaram at yahoo.co.in (Rahul Sundaram) Date: Sat, 29 Jan 2005 01:34:47 -0800 (PST) Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FA8406.6020005@poolshark.org> Message-ID: <20050129093447.42628.qmail@web8502.mail.in.yahoo.com> Hi > So out of curiosity, how do Suse and Mandrake deal > with this issue ? > > -d afaik suse doesnt ship mp3 stuff anymore. mandrake as a non-US distro might not be affected by the patents enforced in US ===== Regards Rahul Sundaram __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From peter.backlund at home.se Sat Jan 29 10:49:15 2005 From: peter.backlund at home.se (Peter Backlund) Date: Sat, 29 Jan 2005 11:49:15 +0100 Subject: Eclipse 3.0.1_fc-9 Message-ID: <1106995755.6141.18.camel@localhost.localdomain> Hello. Updated eclipse* to 3.0.1_fc-9 today (on FC3, not a full rawhide system), and this happened: About a thousand of these: /var/tmp/rpm-tmp.48338: line 1: 13434 Segmentation fault gcj- dbtool4 -a /usr/lib/eclipse/eclipse.db $j /us r/lib/eclipse/`basename $j`.so error: %post(eclipse-platform-3.0.1_fc-9.i386) scriptlet failed, exit status 139 Then, when I tried to run eclipse, this happened: /usr/bin/eclipse: line 45: 13552 Segmentation fault LD_PRELOAD=/usr/lib/eclipse/xml-commons- apis-1.0.jar.so:/usr/lib/eclipse/xalan- j2-2.6.0.jar.so:/usr/lib/eclipse/xerces- j2-2.6.2.jar.so /usr/share/eclipse/eclipse $ECLIPSE_OPTS $@ $VM_OPTS Here's the relevant packages: [root at localhost ~]# rpm -qa eclipse\* gcc4\* \*gcj4\* java-1.4.2\* java-1.4.2-gcj4-compat-devel-1.4.2.0-3jpp eclipse-jdt-3.0.1_fc-9 eclipse-platform-3.0.1_fc-8 java-1.4.2-gcj-compat-1.4.2.0-39jpp gcc4-4.0.0-0.22 java-1.4.2-gcj4-compat-1.4.2.0-3jpp eclipse-pde-3.0.1_fc-9 eclipse-platform-3.0.1_fc-9 libgcj4-4.0.0-0.21 java-1.4.2-gcj-compat-devel-1.4.2.0-39jpp gcc4-java-4.0.0-0.22 eclipse-source-3.0.1_fc-9 libgcj4-devel-4.0.0-0.21 eclipse-ecj-3.0.1_fc-9 eclipse-gtk2-3.0.1_fc-9 /Peter From jakub at redhat.com Sat Jan 29 10:54:31 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Sat, 29 Jan 2005 05:54:31 -0500 Subject: Eclipse 3.0.1_fc-9 In-Reply-To: <1106995755.6141.18.camel@localhost.localdomain> References: <1106995755.6141.18.camel@localhost.localdomain> Message-ID: <20050129105431.GK11199@devserv.devel.redhat.com> On Sat, Jan 29, 2005 at 11:49:15AM +0100, Peter Backlund wrote: > java-1.4.2-gcj4-compat-devel-1.4.2.0-3jpp > eclipse-jdt-3.0.1_fc-9 > eclipse-platform-3.0.1_fc-8 > java-1.4.2-gcj-compat-1.4.2.0-39jpp > gcc4-4.0.0-0.22 > java-1.4.2-gcj4-compat-1.4.2.0-3jpp > eclipse-pde-3.0.1_fc-9 > eclipse-platform-3.0.1_fc-9 > libgcj4-4.0.0-0.21 > java-1.4.2-gcj-compat-devel-1.4.2.0-39jpp > gcc4-java-4.0.0-0.22 > eclipse-source-3.0.1_fc-9 > libgcj4-devel-4.0.0-0.21 > eclipse-ecj-3.0.1_fc-9 > eclipse-gtk2-3.0.1_fc-9 Try libgcj4-{,devel-}4.0.0-0.22 instead. This is #146271, fixed in package CVS by -Requires: libgcj4 >= %{version}, libgcj4-devel >= %{version}, zlib-devel +Requires: libgcj4 = %{version}-%{release}, libgcj4-devel = %{version}-%{release}, zlib-devel Jakub From mharris at www.linux.org.uk Sat Jan 29 11:01:50 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Sat, 29 Jan 2005 06:01:50 -0500 Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: <1106949449.25801.36.camel@rousalka.dyndns.org> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <1106932037.26564.21.camel@cobra.ivg2.net> <1106933207.19595.121.camel@localhost.localdomain> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> <1106937343.734.12.camel@cobra.ivg2.net> <1106945215.2174.21.camel@cobra.ivg2.net> <1106949449.25801.36.camel@rousalka.dyndns.org> Message-ID: <41FB6D1E.2040203@www.linux.org.uk> Nicolas Mailhot wrote: > Le vendredi 28 janvier 2005 ? 14:55 -0600, Rex Dieter a ?crit : > >>On Fri, 28 Jan 2005, Ivan Gyurdiev wrote: > > >>>I heard X will be modularized for FC5 so all libraries will be split up >>>like that. Is that not the case? >> >>Where did you hear that? So it's going to get even more complicated? > > > Xorg people want to unbundle the big pile of code they inherited from > XFree86, so they don't have to ship anymore copies of other people stuff > (fontconfig, mesa, xterm...), it builds using mainstream autoconf* > scripts, drivers can be released as a different pace than the core > package (so no full rebuild each time you need to add a new card), etc This is perhaps a bit lengthy, but several people have asked me to give a history of X lately from my own eyes, and so now is as good a time as any. If you do not like reading long email postings, please stop reading now, and skip to the next message. You have been warned now, and have no excuse to complain about my verbiage if you don't like it. ;o) Way back when.... The MIT X Consortium was the official standards body that governed the X Window System, and developed the X11 sample implementation (SI). Many different proprietary UNIX vendors used this sample implementation as the basis for their own mostly proprietary X11 implementations. The X11 sample implementation's source code was under an MIT license, which is an open source license. XFree86 sprung to life back somewhere around 1989 or so, I don't remember the specific year, but google probably can find out the details if someone's terribly interested in the history of XFree86 and the X Window System. XFree86, was (and still is) a fork of the X Window System sample implementation. Over the years, XFree86 included many enhancements and features, some of which ended up being fed back into the "official" sample implementation. Also, over the years, The MIT X Consortium became just "X Consortium". At the same time, XFree86 grew in popularity due much to the popularity of Linux itself, and the fact most people running Linux were using PC hardware, and XFree86 being specifically developed for x86 hardware had the best hardware support of any X Window System implementation for x86 PC hardware. So XFree86 sprung into popularity due to better hardware support. However, the XFree86 project was not, is not, and never wanted to be a standards body. The XFree86 project just wanted to provide the best X Window System implementation, and being the defacto X implementation most widely in use, I believe that goal was achieved. Nonetheless, the X Consortium was still the official standards body tasked with stewardship of the X Window System. Over time, and a bit of reorganization, the X Consortium became "X.Org", and continued to be the official X standards body. Unfortunately, over time X.Org contributions to the X Window System slowed down quite significantly, and releases of the sample implementation were becoming further and further apart also. There was a lot of time between the release of X11R6.3, X11R6.4, X11R6.5, and X11R6.6. After X11R6.6, X.Org seemed to almost vanish completely except for the website. There wasn't much activity going on, and X.Org and it's predecessor organizations were not very community oriented, so it seemed that the standards body governing X had perhaps fallen into irrelevance. XFree86.org, continued to incorporate new features and changes from all of the official X Window System sample implementation releases into each new XFree86 release, up to and including X11R6.6. X.Org was relatively motionless for a few years, and (to me anyway) it started to seem like it might stay that way. About a year and a half ago however, there was a desire in the open source community for the development process behind the X Window System to become much more open and public like that of most other open source projects, with open mailing lists, more freely available read/write CVS, and to try to kick-start the X Window System back on track. Many felt that technological advancement of X was moving at a snail's pace, and that in order for improvements to happen at a fast enough pace to meet and continue to meet the needs of the open source community, that new life needed to be breathed not just into X itself, but also into the organizations behind the X Window System, and the processes and policies of how things were done, in hopes that X could benefit from some of the open source lessons learned from the GNOME project, KDE project, and other highly successful projects out there, many of which are considered the leading edge of OSS. There was a lot of discussion about how to do this, but in the end, the decision ended up being to try to gather interest in the X.Org members to revitalize X.Org, and get the X Window System back on track, making it a more open project, with more open and accessible processes, etc. The result of this community effort, was last year, in January 2004 roughly, "The X.Org Foundation" was formed as a non-profit organization, with a goal of turning the "official" X Window System into a completely open community project. The last release of the X.Org sample implementation (X11R6.6) however was a few years old, and hadn't kept up with many of the improvements added to XFree86 over the years. Since the XFree86 codebase, originally forked many many years ago from the official X11 had much better video hardware support, and various other improvements, it would be a shame to throw all that away. It was decided that it would be more work to backport all of the various XFree86 improvements on top of X11R6.6 and some work done since then, than it would be to just start with the last version of XFree86 codebase prior to the XFree86 license change last year, and then incorporate various X.Org sample implementation features back into the new tree, and begin development of X11R6.7 from there. So XFree86 is a fork of the official X Window System, but the new official X Window System is also in a way a fork of XFree86. ;o) Really though, they both stem from the exact same source code, and have developed separately over time, with some of the code trickling back and forth as time has went on. The current X.Org could be instead however, viewed as a major "merge" of the XFree86 code back into the official X Window System, rather than a fork of XFree86, as that would be a bit more accurate IMHO. Now that I've said that... A large portion of the code "inherited" from XFree86, is actually the X.Org original code in the first place. ;o) The current X.Org wants to just improve the code in general, rather than to remove XFree86 contributed things. XFree86 did afterall contribute a lot of great things to the X Window System. The new X.Org Foundation wants to take X now to the next level, and perhaps even to beat Microsoft to the punch with snazzy desktop features before Longhorn ships. ;o) > It means packaging will probably get easier because you won't have an > enormous srpm that generates scores of packages (with a large part of > the big archive content disable to use system libraries instead) but > lots of different source archives. Yep, that is one of the major advantages of having X11 modularized. There are a tonne of advantages, both for developers, distribution packagers, system administrators, and end users. It is a natural evolution taking place which will simplify our lives, and bring world peace. > I doubt they manage to pull it out for FC5 though - it's an enormous > task and all the OS are not created equal (some do not have their own > fontconfig module...), so some port maintainers push for keeping an > unified blob. Fedora Core is on a roughly 6 month devel cycle, so FC5 should be released at roughly the same time in 2005 as FC3 was released in 2004. There is quite a bit of work that needs to b done before the X modularization work is completed, but the process has now officially been accepted by X.Org, and planning has been started. Some X.Org people believe a summer release would be a good goal to aim for, but personally I think (with no disrespect intended) that they are greatly underestimating the work involved and the time it will take to get everything in place, deal with bugs, etc. and finalize the release. My personal voodoo prediction currently, is that the next major release of X.Org (not counting minor 6.8.2 or 6.8.3, etc releases) will be sometime around August or September 2005. Now quick, someone go set up a hockey pool to bet money on who's release date prediction is closest to the official date later this year. ;o) Ok, rest your eyes now before reading any more email. ;) From mharris at www.linux.org.uk Sat Jan 29 11:27:38 2005 From: mharris at www.linux.org.uk (Mike A. Harris) Date: Sat, 29 Jan 2005 06:27:38 -0500 Subject: Nvidia packaging in Fedora (Summary) In-Reply-To: <604aa791050128130510f0bc44@mail.gmail.com> References: <41F9DA4D.7040801@tlarson.com> <1106933340.32563.21.camel@cobra.ivg2.net> <1106934049.19595.126.camel@localhost.localdomain> <1106934310.6141.0.camel@localhost.localdomain> <1106934539.32563.40.camel@cobra.ivg2.net> <41FA7CEA.7030804@math.unl.edu> <1106937343.734.12.camel@cobra.ivg2.net> <1106945215.2174.21.camel@cobra.ivg2.net> <604aa791050128130510f0bc44@mail.gmail.com> Message-ID: <41FB732A.5040205@www.linux.org.uk> Jeff Spaleta wrote: >>>I heard X will be modularized for FC5 so all libraries will be split up >>>like that. Is that not the case? >> >>Where did you hear that? So it's going to get even more complicated? > > > i've been hearing mharris wax eloquent about moving away from the > 'monolithic' approach to modular pieces for X related libraries for a > while now. Catching him when he's actually using eloquent speech > however is a refined skill that takes much practice. I'm pretty sure > modularization is on X.org's development roadmap moving foward.. but > i'm not sure its wise to give a timeline as to when its ready. I have > no idea what state the effort is in i dont keep up with xorg related > mailinglists. A motion to discuss the modularization of the X.Org X Window System was brought to the table and approved recently by the board of directors. The project is currently in the initial planning stages, and the modularization working group is currently being formed. A detailed roadmap including timelines is not presently available, but may be forthcoming at a future juncture now that the wherewithal has been obtained. Parties potentially interested in contributing to the grandoise effort are encouraged to contact the X.Org project and express their intentions and concurrance with limitless exuberance via the xorg at freedesktop.org developmental mailing list. If there are no further questions or concerns, I'll move on to the next agendum. From bclark at redhat.com Sat Jan 29 11:35:04 2005 From: bclark at redhat.com (Bryan Clark) Date: Sat, 29 Jan 2005 06:35:04 -0500 Subject: Our Discussion on Fedora-docs [Fwd: Re: Fedora Documentation Search Engine] In-Reply-To: <42853.193.195.148.66.1106926064.squirrel@webmail.suretecsystems.com> References: <42853.193.195.148.66.1106926064.squirrel@webmail.suretecsystems.com> Message-ID: <1106998504.4770.11.camel@rhbw.boston.redhat.com> Hi ~ I'm not questioning the benefit of the inclusion of swish into extras, but I'm wondering what the end-user benefits are going to be of adding an indexer for the documentation. >From reading the small thread on fedora-docs I understand that you would like people will be able to search all the man-pages/howto/README docs of the installed rpms. What I'm looking for is some more basic details of why this needs to be done and why it needs to be done this way. What type of person do you think is looking for this information (a developer, an office worker, a broker?). What is this person trying to accomplish by searching this information? Why do they need it? Assuming they need it. How are they going to search for this information? Yelp? Web Browser? Something else? Are the mechanisms for searching and reviewing this type of information already built into those things? If we had more of an overview of how this project is going to help people we could possibly look at a way of integrating it's functionality better into our system. Hopefully we then won't be just adding another piece to the stack of tools we have, but an answer to a problem people are having. Thanks, ~ Bryan On Fri, 2005-01-28 at 15:27 +0000, Gavin Henry wrote: > I thought that maybe you guys would have some input on this? > ---------------------------- Original Message ---------------------------- > Subject: Re: Fedora Documentation Search Engine > From: "Stuart Ellis" > Date: Fri, January 28, 2005 3:24 pm > To: "For participants of the docs project" > > -------------------------------------------------------------------------- > > On Fri, 28 Jan 2005 14:39:32 -0000 (GMT), "Gavin Henry" > said: > > > > > > > > On Fri, 28 Jan 2005 12:56:58 -0000 (GMT), "Gavin Henry" > > > said: > > >> Dear all, > > >> > > >> Has there been any discussion about this? > > >> > > >> I thinking along the lines of htdig/swish-e that indexes all man > pages/howto/README after every rpm is installed. > > >> > > >> Something like a post entry in the spec file, or similar. > > > > > > I haven't seen any on this list, but essentially this is a function of > having a desktop search/indexing engine since there isn't a common > format to this stuff. The next release of yelp (GNOME help browser) > will display info and man pages, but can't index the random txt, html, > pdf etc. that goes into /usr/share/doc/. > > > > We heavily use Swish-e (www.swish-e.org) for the fileservers we install. > This can handle html, xhtml, txt, pdf and the like. > > I've just looked at the page now, but it looks like a very useful bit of > software. > > > Maybe something like this or a updatedocdb crontab, like slocate has and > we just put the standard doc pathnames in a config file. The customize > the > > web search page. > > > > My understanding is that this is where things become quite technical and > problematic. There is always a disjunct between what's actually on the > disk and what is listed in the index. On portable computers it's harder > to guarantee that batch indexing jobs will be completed regularly as well. > Beagle and Spotlight use kernel hooks to update the index as changes > occur. I suppose that RPM packages could run post-install scripts that > update a document registry (kind of like you suggested) would be a > relatively non-invasive way to implement something. > > I definitely think that the default start page of the Web browser could be > used very effectively by the docs project. The details of > implementing an index might be a good question for fedora-devel. > > -- > > Stuart Ellis > s.ellis at fastmail.co.uk > > -- > fedora-docs-list mailing list > fedora-docs-list at redhat.com > To unsubscribe: > http://www.redhat.com/mailman/listinfo/fedora-docs-list > > From Axel.Thimm at ATrpms.net Sat Jan 29 11:39:33 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 29 Jan 2005 12:39:33 +0100 Subject: Better repodata performance (was: redhat abe) In-Reply-To: <1106984170.1614.34.camel@cutter> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> Message-ID: <20050129113933.GB16904@neu.nirvana> On Sat, Jan 29, 2005 at 02:36:09AM -0500, seth vidal wrote: > > The exercise is to attempt a method in which you save computation of md5 > > or sha1, as these are one of the time consuming steps of createrepo. > > The save would be in a 100k package repository: (100,000 - N) * > > Time(sum_calc), where N equals the number of packages that *need* to > > generate sums for. A parameterized list of package names passed into > > createrepo would be sufficient to figure out what composes the N list. > > An external process, such as a Manifest list, would then be used to > > mitigate a set of packages through the entire build process. Apt uses > > a md5sum cache, but having fine-tuned controlled of the process would > > be more stable and directed. This is how much saving you'd get for #2. > > Let me know when you've figured it out but as it stands I don't think > incrementally updating the metadata is very feasible. How about having multiple repodatas, the base one and small incremental ones, the incremental ones containing also package cancelations? As a side effect this would also reduce download bandwidth and thus make even clients/users happy (not only repo maintainers). The base repodata and the incremental ones would be merged from time to time, best with a binary load algorithm as done in large sum statistics (for 100K packages you would need only 17 files). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ville.skytta at iki.fi Sat Jan 29 12:27:16 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sat, 29 Jan 2005 14:27:16 +0200 Subject: Sample initscript/standard In-Reply-To: <1106962320.17286.1.camel@ignacio.ignacio.lan> References: <6.2.1.2.2.20050129125000.01c32ea8@tornado.reub.net> <1106962320.17286.1.camel@ignacio.ignacio.lan> Message-ID: <1107001636.4018.32.camel@bobcat.mine.nu> On Fri, 2005-01-28 at 20:32 -0500, Ignacio Vazquez-Abrams wrote: > On Sat, 2005-01-29 at 12:59 +1300, Reuben Farrelly wrote: > > Is there a sample skeleton /etc/init.d/ script anywhere which I can regard > > as an 'authoritative' script to base work on, and fix up other non-Fedora > > initscripts from? I had a feeling there was one in > > /usr/share/doc/initscripts-*/ but seems not... > > /usr/share/doc/initscripts-*/sysvinitfiles contains both a skeleton > script and documentation. Another good (somewhat better than the above IMO) skeleton script is /usr/share/fedora/template.init. It's in the fedora-rpmdevtools package in pre-extras. From buildsys at redhat.com Sat Jan 29 13:23:38 2005 From: buildsys at redhat.com (Build System) Date: Sat, 29 Jan 2005 08:23:38 -0500 Subject: rawhide report: 20050129 changes Message-ID: <200501291323.j0TDNcr22313@porkchop.devel.redhat.com> From laroche at redhat.com Sat Jan 29 14:28:37 2005 From: laroche at redhat.com (Florian La Roche) Date: Sat, 29 Jan 2005 15:28:37 +0100 Subject: checking binary rpm packages Message-ID: <20050129142837.GA8313@dudweiler.stuttgart.redhat.com> Here is a start to check binary rpm packages for consistency: http://people.redhat.com/laroche/pyrpm/ Right now mostly the rpm header is checked to get a feeling how much "strange" binary rpm packages might be out there. It has two modes of checking, one for the current Fedora Development tree with more strict checks and a more relaxed one that should work for all existing rpm packages, also other distributions. I'd be interested to get feedback on what output is generated for rpm addon expositories and non - Red Hat distributions if the script generates warning messages. At least for Fedora Core only very few rpm tags are actually used in the rpm header. Examples usage: ./pyrpm.py --strict /mirror/fedora/development/i386/Fedora/RPMS/*.rpm Checking all rpms: locate .rpm | xargs ./pyrpm.py find /mirror/linux -name "*.rpm" -type f -print0 2>/dev/null | xargs -0 ./pyrpm.py greetings, Florian La Roche From teg at pvv.org Sat Jan 29 14:25:47 2005 From: teg at pvv.org (=?UTF-8?B?VHJvbmQgRWl2aW5kIEdsb21zcsO4ZA==?=) Date: Sat, 29 Jan 2005 15:25:47 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FA6FB5.9010808@math.unl.edu> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <41FA6FB5.9010808@math.unl.edu> Message-ID: <41FB9CEB.3000300@pvv.org> Rex Dieter wrote: > Ivan Gyurdiev wrote: > > >> - Livna.org sync-ed against Rawhide. > > > It's not too hard for rawhide'rs to 'rpmbuild --rebuild'. is it? Building kernel modules from various external repositories has always been an interesting task. Unfortunately. Ideally, they'd not ship kernel modules at all but rebuild on boot if not previously compiled for that kernel (DKMS). From kwade at redhat.com Sat Jan 29 14:32:23 2005 From: kwade at redhat.com (Karsten Wade) Date: Sat, 29 Jan 2005 06:32:23 -0800 Subject: Our Discussion on Fedora-docs [Fwd: Re: Fedora Documentation Search Engine] In-Reply-To: <1106998504.4770.11.camel@rhbw.boston.redhat.com> References: <42853.193.195.148.66.1106926064.squirrel@webmail.suretecsystems.com> <1106998504.4770.11.camel@rhbw.boston.redhat.com> Message-ID: <1107009143.4984.41.camel@erato.phig.org> On Sat, 2005-01-29 at 06:35 -0500, Bryan Clark wrote: > Hi ~ > > I'm not questioning the benefit of the inclusion of swish into extras, > but I'm wondering what the end-user benefits are going to be of adding > an indexer for the documentation. > > >From reading the small thread on fedora-docs I understand that you would > like people will be able to search all the man-pages/howto/README docs > of the installed rpms. What I'm looking for is some more basic details > of why this needs to be done and why it needs to be done this way. > > What type of person do you think is looking for this information (a > developer, an office worker, a broker?). Any end-user on the system. > What is this person trying to accomplish by searching this information? > Why do they need it? Currently, the best way to search for Fedora documentation is via google.com. That in fact is how I search Red Hat docs, using site:redhat.com. Right now, if you install locally all the documentation available, you might have everything you'd be searching Google for but are unable to find locally. Package docs go into /usr/share/doc and the man pages, Red Hat docs packages also go into /usr/share/doc and may have an entry in the 'Foot/'Hat menu. Fedora docs are small enough that an Everything install _could_ include docs packages. That is a *tonne* of local, online documentation. All of this is nearly impossible to search through without an index and search tool. > Assuming they need it. How are they going to search for this > information? Yelp? Web Browser? Something else? Are the mechanisms > for searching and reviewing this type of information already built into > those things? IMO, Yelp. We need to settle on a common help interface and (ab)use it. For example, a document on using kickstart to automate installation might be at the forefront when Yelp is called from system-config- kickstart. If an indexer can do this well, it seems better than hand coding docs to be associated with certain apps and actions. > If we had more of an overview of how this project is going to help > people we could possibly look at a way of integrating it's functionality > better into our system. Hopefully we then won't be just adding another > piece to the stack of tools we have, but an answer to a problem people > are having. I definitely think integrating indexed documentation into Yelp is a good idea for corporate-type end-users. People _used_ to use the local help system more extensively, until Internet search engines proved more useful. The downside of relying upon the Internet is, what do you do when the doc you need is the one that will get your networking going again? Better hope you have a second machine that has connectivity, or that you know how to dig through /usr/share/doc by hand. - Karsten -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 IT executives rate Red Hat #1 for value http://www.redhat.com/promo/vendor/ From rdieter at math.unl.edu Sat Jan 29 16:10:35 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 29 Jan 2005 10:10:35 -0600 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FB9CEB.3000300@pvv.org> References: <41F9DA4D.7040801@tlarson.com> <20050128091034.50424.qmail@web8501.mail.in.yahoo.com> <20050128142531.GA553227@hiwaay.net> <1106927048.13888.29.camel@support02.civic.twp.ypsilanti.mi.us> <1106929038.26304.17.camel@cobra.ivg2.net> <1106930141.19595.109.camel@localhost.localdomain> <1106931269.26564.15.camel@cobra.ivg2.net> <41FA6FB5.9010808@math.unl.edu> <41FB9CEB.3000300@pvv.org> Message-ID: <41FBB57B.10002@math.unl.edu> Trond Eivind Glomsr?d wrote: > Building kernel modules from various external repositories has always > been an interesting task. Unfortunately. True. > Ideally, they'd not ship kernel modules at all but rebuild on boot if > not previously compiled for that kernel (DKMS). Now that would be slick. -- Rex From commonlaw at vtlink.net Sat Jan 29 16:36:52 2005 From: commonlaw at vtlink.net (James Sylvester) Date: Sat, 29 Jan 2005 11:36:52 -0500 (EST) Subject: Firefox, x86_64, unacceptable memory use Message-ID: <58884.64.30.33.170.1107016612.squirrel@mail.vtlink.net> I am sure that the primary browser for the developing Fedora Core 4 edition is not high on your priority list. However, if Fedora Core 4 is released with a memory devouring browser, as the current Fedora Core 4 Firefox is, then the complaints from users, reviewers, and administrators will be a strong reminder that libraries and applications have significant importance to all users of the OS. From mattdm at mattdm.org Sat Jan 29 16:57:40 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 29 Jan 2005 11:57:40 -0500 Subject: checking binary rpm packages In-Reply-To: <20050129142837.GA8313@dudweiler.stuttgart.redhat.com> References: <20050129142837.GA8313@dudweiler.stuttgart.redhat.com> Message-ID: <20050129165740.GA19052@jadzia.bu.edu> On Sat, Jan 29, 2005 at 03:28:37PM +0100, Florian La Roche wrote: > Here is a start to check binary rpm packages for consistency: > http://people.redhat.com/laroche/pyrpm/ Have you looked at rpmlint? -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From mattdm at mattdm.org Sat Jan 29 16:59:48 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 29 Jan 2005 11:59:48 -0500 Subject: Firefox, x86_64, unacceptable memory use In-Reply-To: <58884.64.30.33.170.1107016612.squirrel@mail.vtlink.net> References: <58884.64.30.33.170.1107016612.squirrel@mail.vtlink.net> Message-ID: <20050129165948.GB19052@jadzia.bu.edu> On Sat, Jan 29, 2005 at 11:36:52AM -0500, James Sylvester wrote: > I am sure that the primary browser for the developing Fedora Core 4 > edition is not high on your priority list. However, if Fedora Core 4 > is released with a memory devouring browser, as the current Fedora > Core 4 Firefox is, then the complaints from users, reviewers, and > administrators will be a strong reminder that libraries and > applications have significant importance to all users of the OS. You should bring this up with the Firefox developers, unless there's a specific FC bug you can identify. -- Matthew Miller mattdm at mattdm.org --> Fedora Users & Developers Conference, hosted by Boston University <-- February 18th, 2005 From rdieter at math.unl.edu Sat Jan 29 17:10:18 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 29 Jan 2005 11:10:18 -0600 Subject: Firefox, x86_64, unacceptable memory use In-Reply-To: <58884.64.30.33.170.1107016612.squirrel@mail.vtlink.net> References: <58884.64.30.33.170.1107016612.squirrel@mail.vtlink.net> Message-ID: <41FBC37A.2030204@math.unl.edu> James Sylvester wrote: > if Fedora Core 4 > is released with a memory devouring browser, as the current Fedora > Core 4 Firefox is, then the complaints from users, reviewers, and > administrators will be a strong reminder that libraries and > applications have significant importance to all users of the OS. Perhaps you could provide evidence or a bugzilla report referring to firefox's "memory devouring" behavior? -- Rex From aoliva at redhat.com Sat Jan 29 19:11:06 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 29 Jan 2005 17:11:06 -0200 Subject: Better repodata performance (was: redhat abe) In-Reply-To: <20050129113933.GB16904@neu.nirvana> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> Message-ID: On Jan 29, 2005, Axel Thimm wrote: > How about having multiple repodatas, the base one and small > incremental ones, the incremental ones containing also package > cancelations? As a side effect this would also reduce download > bandwidth and thus make even clients/users happy (not only repo > maintainers). +1. Heck, make it +2. I agree with Axel, for a change :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From skvidal at phy.duke.edu Sat Jan 29 19:23:25 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 29 Jan 2005 14:23:25 -0500 Subject: Better repodata performance (was: redhat abe) In-Reply-To: References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> Message-ID: <1107026606.1614.59.camel@cutter> On Sat, 2005-01-29 at 17:11 -0200, Alexandre Oliva wrote: > On Jan 29, 2005, Axel Thimm wrote: > > > How about having multiple repodatas, the base one and small > > incremental ones, the incremental ones containing also package > > cancelations? As a side effect this would also reduce download > > bandwidth and thus make even clients/users happy (not only repo > > maintainers). > > +1. Heck, make it +2. > > I agree with Axel, for a change :-) > How would it reduce bandwidth - you'd have to download and parse multiple entries and you'd STILL have to do just a much work on the repo-side b/c you'd have to check all the packages for changes. -sv From fedora-devel at tlarson.com Sat Jan 29 19:33:31 2005 From: fedora-devel at tlarson.com (Tyler Larson) Date: Sat, 29 Jan 2005 12:33:31 -0700 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FAE8E1.6AE64597@jwz.org> References: <1106333362.3427.19.camel@localhost.localdomain> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <20050128120336.21dad318.fedora@wir-sind-cool.org> <41FAE2BF.4EF5FD29@jwz.org> <604aa7910501281721741be6c4@mail.gmail.com> <41FAE8E1.6AE64597@jwz.org> Message-ID: <41FBE50B.7090808@tlarson.com> Jamie Zawinski wrote: > Jeff Spaleta wrote: > >>Thanks for volunteering to help the bmp developers work >>through the remaining usability issues. > > > Yes, by all means, let's improve the Linux user experience by > replacing working tools with half-working tools. > Jamie has a point, you know. Albeit cleverly disguised amidst the sarcasm. Progress for progress' sake is an absurd motivation. That is, replacing an app with a functionally inferior one just because it uses old libraries isn't sensible. If you replace an app, the new one should be *better* than the old one. The goal isn't to make new programs better, it's to use the best programs. The underlying drive for every change we make should be an improvement in the overall user experience. Every other goal--simplifying the package selection, decreasing the download size, etc--should be an appendage to the primary goal of making the distro more usable. Any decision that meets one of these lesser goals (like shrinking the distro size) but still runs contrary to the more important principle of improving the user experience is a bad decision to make. Don't destroy the forest to save a tree. From Nicolas.Mailhot at laPoste.net Sat Jan 29 19:39:51 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Sat, 29 Jan 2005 20:39:51 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FBE50B.7090808@tlarson.com> References: <1106333362.3427.19.camel@localhost.localdomain> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <20050128120336.21dad318.fedora@wir-sind-cool.org> <41FAE2BF.4EF5FD29@jwz.org> <604aa7910501281721741be6c4@mail.gmail.com> <41FAE8E1.6AE64597@jwz.org> <41FBE50B.7090808@tlarson.com> Message-ID: <1107027591.3064.1.camel@rousalka.dyndns.org> Le samedi 29 janvier 2005 ? 12:33 -0700, Tyler Larson a ?crit : > Jamie Zawinski wrote: > > Jeff Spaleta wrote: > > > >>Thanks for volunteering to help the bmp developers work > >>through the remaining usability issues. > > > > > > Yes, by all means, let's improve the Linux user experience by > > replacing working tools with half-working tools. > > > > Jamie has a point, you know. Albeit cleverly disguised amidst the sarcasm. > > Progress for progress' sake is an absurd motivation. That is, replacing > an app with a functionally inferior one just because it uses old > libraries isn't sensible. If you replace an app, the new one should be > *better* than the old one. The goal isn't to make new programs better, > it's to use the best programs. In this case it's already been explained the library change directly translates in end-user benefits. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From kyrre at solution-forge.net Sat Jan 29 20:44:51 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 29 Jan 2005 21:44:51 +0100 Subject: fedora stable branch updates Q&A policy In-Reply-To: <1106988109.11086.28.camel@localhost.localdomain> References: <1106851614.2656.7.camel@localhost.localdomain> <1106905427.5373.57.camel@localhost.localdomain> <1106945584.6895.4.camel@localhost.localdomain> <1106988109.11086.28.camel@localhost.localdomain> Message-ID: <1107031490.4174.18.camel@localhost.localdomain> > When we do release FC(n+1) test X, those discussions get moved to > fedora-test-list at redhat.com Where does update testing go then? From kyrre at solution-forge.net Sat Jan 29 20:52:39 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sat, 29 Jan 2005 21:52:39 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106684051.30714.9.camel@opus.phy.duke.edu> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> Message-ID: <1107031959.4174.23.camel@localhost.localdomain> tir, 25.01.2005 kl. 21.14 skrev seth vidal: > > Will and does are very different. IF it isn't there by FC4, FC4 should > > include grip. However, I see all critical functionality, and most non- > > critical, in RhythmBox. xmms uses gtk1 and doesn't seem to be needed; > > should it be removed? > > Yes, it should. > -sv > What about simple "play that .mp3, i want to know what's in it" kind of use? I must admit that i still use XMMS for that - it just works. Having a libary isn't always what you want. So i have xmms as my default player for all audio files. When i want to listen to an album i ripped (etc), i fire up rythmbox, import the files if neccessary, and play it. And rythmbox STILL (as far as i know) dosn't support changing of tag info... Kyrre From Axel.Thimm at ATrpms.net Sat Jan 29 21:22:06 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 29 Jan 2005 22:22:06 +0100 Subject: Better repodata performance (was: redhat abe) In-Reply-To: <1107026606.1614.59.camel@cutter> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> Message-ID: <20050129212206.GA22924@neu.nirvana> On Sat, Jan 29, 2005 at 02:23:25PM -0500, seth vidal wrote: > On Sat, 2005-01-29 at 17:11 -0200, Alexandre Oliva wrote: > > On Jan 29, 2005, Axel Thimm wrote: > > > How about having multiple repodatas, the base one and small > > > incremental ones, the incremental ones containing also package > > > cancelations? As a side effect this would also reduce download > > > bandwidth and thus make even clients/users happy (not only repo > > > maintainers). > > > > +1. Heck, make it +2. > > > > I agree with Axel, for a change :-) > > > > How would it reduce bandwidth - you'd have to download and parse > multiple entries and you'd STILL have to do just a much work on the > repo-side b/c you'd have to check all the packages for changes. For N packages the ballanced load are log_2 N bins. Adding M packages touches only log_2 M bins. And the bins have a max size of 2^i packages where i goes from 0 to N-1. And the good news is you touch the bins with i < M, e.g. the small ones. The statistical net effect is that for M package additions to arbitrary N you get log_2 M downloads of a total of 2M packages. In relevant numbers: o N~=4000, log_2 N~=12 You have 12 bins. o 10 security/bug fix updates, (statistically) only bins 0 to 4 are changed amounting to 32 packages. Clients download only 5 files worth of 32 packages in size. Compare with the current situation, where you need to get the whole lot of N packages for each update. For this to work you need to o introduce package cancelation (anti-packages ;) o introduce multiple repodata components o keep a manifest of the last state and feed the repo creation system with the differences (packages lost, packages gained). It's rather common and very efficient in high performance statistics of large sums. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at phy.duke.edu Sat Jan 29 22:07:00 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 29 Jan 2005 17:07:00 -0500 Subject: Better repodata performance (was: redhat abe) In-Reply-To: <20050129212206.GA22924@neu.nirvana> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> Message-ID: <1107036420.1614.72.camel@cutter> > For N packages the ballanced load are log_2 N bins. Adding M packages > touches only log_2 M bins. And the bins have a max size of 2^i > packages where i goes from 0 to N-1. And the good news is you touch > the bins with i < M, e.g. the small ones. > > The statistical net effect is that for M package additions to > arbitrary N you get log_2 M downloads of a total of 2M packages. > > In relevant numbers: > > o N~=4000, log_2 N~=12 > You have 12 bins. > o 10 security/bug fix updates, (statistically) only bins 0 to 4 are > changed amounting to 32 packages. > Clients download only 5 files worth of 32 packages in size. > > Compare with the current situation, where you need to get the whole > lot of N packages for each update. > > For this to work you need to let's be clear - for this to work YOU need to. > o introduce package cancelation (anti-packages ;) fat chance. > o introduce multiple repodata components which buys us not all that much other than complexity of debugging. > o keep a manifest of the last state and feed the repo creation system > with the differences (packages lost, packages gained). And how do you feed the repo creation system this data? Where do you get it to begin with? The only way you know this information is if you already have it - the only way you have it is if you checked all the packages for what has changed. Are you beginning to see the loop here? As Jeremy recently reminded me - incremental updates to metadata was done a looooooooooong time ago in 'yup'. And it was a mess to keep up with. Not to mention just added cruft on the repo side. But far be it from to halt the steady march of progress - when you get a chance to implement this stuff let me know. Oh and once more - who is it gets the benefit from all this work? It sounds like it's mostly repo maintainers - not the users. If someone wants to combine createrepo and yum-arch into one program so it makes both at the same time that's fine - it's about an hour or two worth of work, what you're describing above is considerably more, not to mention redesigning the depsolvers to deal with the new repository format. -sv From jspaleta at gmail.com Sat Jan 29 22:20:14 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 29 Jan 2005 17:20:14 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41FBE50B.7090808@tlarson.com> References: <1106333362.3427.19.camel@localhost.localdomain> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <20050128120336.21dad318.fedora@wir-sind-cool.org> <41FAE2BF.4EF5FD29@jwz.org> <604aa7910501281721741be6c4@mail.gmail.com> <41FAE8E1.6AE64597@jwz.org> <41FBE50B.7090808@tlarson.com> Message-ID: <604aa7910501291420529978f@mail.gmail.com> On Sat, 29 Jan 2005 12:33:31 -0700, Tyler Larson wrote: > Jamie has a point, you know. Albeit cleverly disguised amidst the sarcasm. calling bmp half-working is a bit over the top. The question has never been is this a perfect replacement.. the question has been is it good enough. I don't feel the objections raised so far are significant barriers to replacing xmms. You are free to disagree with me ( until my army of demonic minions steal your soul and rid you of your pesky free will) but I don't think its particularly rational to expect a perfect replacement of any piece of software when the discussion turns to wholesale replacement. Replacements will have their own strengths and weaknesses that need to be compared. > > Progress for progress' sake is an absurd motivation. No one is arguing that. Progress is a messy non-linear business... trade-offs are made among a a number of factors.. 2 steps forward ...1 step back.. > That is, replacing > an app with a functionally inferior one just because it uses old > libraries isn't sensible. If you replace an app, the new one should be > *better* than the old one. are you saying that gtk2 doesnt have improvements over gtk1? 2 steps forward... 1 step back. If you are looking for monotonic forward progress on ALL aspects ALL the time.. i envy your idealism however naive it is. >The goal isn't to make new programs better, > it's to use the best programs. Is it? I'm not particular sure that is THE goal at all. I think there are a number of competing goals which demand compromise and trade-offs. Everything has an opportunity cost.. the 'best' program 2 years from now may not be the 'best' program today.... and its an absolute WASTE of effort to continue to focus testing manhours through test-releases of core on an application that is a dead-end. If bmp is close enough, and it has a development future that appears to provide better integrations and features into the distributions long term... then its worth considering.. even though its not a perfect replacement for xmms. I think its close enough to be a replacement and that its gtk2 provides inherent benefit. Feel free to disagree. > Any decision that meets one of these lesser goals (like shrinking the > distro size) but still runs contrary to the more important principle of > improving the user experience is a bad decision to make. Don't destroy > the forest to save a tree. A decisions that has a significant and lasting long term benefit can cause short term negative impact. 2 steps forward.. and 1 step back.. is still progress. -jef"doing the progress cha-cha"spaleta From Axel.Thimm at ATrpms.net Sat Jan 29 22:47:45 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 29 Jan 2005 23:47:45 +0100 Subject: Better repodata performance (was: redhat abe) In-Reply-To: <1107036420.1614.72.camel@cutter> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> Message-ID: <20050129224745.GD22924@neu.nirvana> On Sat, Jan 29, 2005 at 05:07:00PM -0500, seth vidal wrote: > > For N packages the ballanced load are log_2 N bins. Adding M > > packages touches only log_2 M bins. And the bins have a max size > > of 2^i packages where i goes from 0 to N-1. And the good news is > > you touch the bins with i < M, e.g. the small ones. > > > > The statistical net effect is that for M package additions to > > arbitrary N you get log_2 M downloads of a total of 2M packages. > > > > In relevant numbers: > > > > o N~=4000, log_2 N~=12 > > You have 12 bins. > > o 10 security/bug fix updates, (statistically) only bins 0 to 4 > > are changed amounting to 32 packages. Clients download only 5 > > files worth of 32 packages in size. > > > > Compare with the current situation, where you need to get the > > whole lot of N packages for each update. > > > > For this to work you need to > > let's be clear - for this to work YOU need to. > [...] > But far be it from to halt the steady march of progress - when you get a > chance to implement this stuff let me know. Hey Seth, relax. This is just a suggested concept for improving things. Someone may pick it up, I didn't enforce it on YOU. ;) > Oh and once more - who is it gets the benefit from all this work? > It sounds like it's mostly repo maintainers - not the users. Did you miss the "User downloads 5 files in size of 32 package metadata _in total_ vs 4000"? E.g. the user will typically download less than 1% of what he's downloading now. It benefits by far more the user base (and perhaps mirror admins) than the repo creator. > > o introduce package cancelation (anti-packages ;) > > fat chance. Sorry, my slang is off, does this mean "no way", or "already in development"? From the context of the rest I'd guess the first. ;) > > o introduce multiple repodata components > > which buys us not all that much other than complexity of debugging. It buys you all the nice things already outlined. > > o keep a manifest of the last state and feed the repo creation system > > with the differences (packages lost, packages gained). > > And how do you feed the repo creation system this data? Where do you get > it to begin with? The only way you know this information is if you > already have it But you do, this is about incremental updates to a repository, right? > - the only way you have it is if you checked all the packages for > what has changed. Are you beginning to see the loop here? No. > If someone wants to combine createrepo and yum-arch into one program so > it makes both at the same time that's fine - it's about an hour or two > worth of work, That's a complete other topic. > what you're describing above is considerably more, not to mention > redesigning the depsolvers to deal with the new repository format. It may even may it simpler, since you don't need to split it into more importnant and less important data and have file dependencies computed in two loops. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dfarning at sbcglobal.net Sat Jan 29 23:54:48 2005 From: dfarning at sbcglobal.net (David Farning) Date: Sat, 29 Jan 2005 17:54:48 -0600 Subject: Better repodata performance In-Reply-To: <1107036420.1614.72.camel@cutter> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> Message-ID: <41FC2248.3010100@sbcglobal.net> seth vidal wrote: > And how do you feed the repo creation system this data? Where do you get > it to begin with? The only way you know this information is if you > already have it - the only way you have it is if you checked all the > packages for what has changed. Are you beginning to see the loop here? > Hey, great work on yum!! Let me see if I a understand the problem and can provide a general solution. When running yum, a check is preformed to insure that the most recent versions of primary.xml is present, based on the timestamp found in repomd.xml. If a more recent version of primary.xml is found then download it. Now, in most situations very few packages have been changed. Therefore, between primary.xml versions few ... have changed thus most of the information in primary.xml is redundant against previous versions of primary.xml. First, add a repo_build_number to repomd.xml. This should should be an integer that increments every time createrepo is run. This allows us to always know what build of a repo we are working with. Createrepo: saves the last runs primary.xml as primary.repo_build_number.xml. Generates new primary.xml as usual. Compares primary.xml to old primary.repo_build_number.xml to create primary.increment-(age).xml. Where age indicates the packages changes required to bring a primary of age or less builds old up to date. A number of primary.increment-(age).xml files could be made available. Ages of 1, 5, 10 could be made available. These files could have a 'rolling' age to cover a majority of updates without wasting too much space. On the Yum side of things: Read local repomd.xml to determine local repo_build_number dl new repomd.xml to determine current repo_build_number. if remote repo_build_number = local repo_build_number = 0 local primary.xml is uptodate if remote repo_build_number = local repo_build_number = 1 dl primary.increment-1.xml merge primary.increment-1.xml with local primary.xml if remote repo_build_number = local repo_build_number <= 5 dl primary.increment-5.xml merge primary.increment-5.xml with local primary.xml if remote repo_build_number = local repo_build_number <= 10 dl primary.increment-10.xml merge primary.increment-1.xml with local primary.xml if remote repo_build_number = local repo_build_number > 10 dl primary.xml -dtf From cra at WPI.EDU Sun Jan 30 00:12:09 2005 From: cra at WPI.EDU (Charles R. Anderson) Date: Sat, 29 Jan 2005 19:12:09 -0500 Subject: Better repodata performance In-Reply-To: <41FC2248.3010100@sbcglobal.net> References: <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> <41FC2248.3010100@sbcglobal.net> Message-ID: <20050130001209.GE21431@angus.ind.WPI.EDU> On Sat, Jan 29, 2005 at 05:54:48PM -0600, David Farning wrote: > Now, in most situations very few packages have been changed. Therefore, > between primary.xml versions few ... have changed > thus most of the information in primary.xml is redundant against > previous versions of primary.xml. Why all the complication when a general-purpose algorithm, rsync, already exists to solve this problem? Using rsync or librsync would require no changes to the repodata... From pbrobinson at gmail.com Sun Jan 30 00:17:49 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Sun, 30 Jan 2005 08:17:49 +0800 Subject: Firefox, x86_64, unacceptable memory use In-Reply-To: <20050129165948.GB19052@jadzia.bu.edu> References: <58884.64.30.33.170.1107016612.squirrel@mail.vtlink.net> <20050129165948.GB19052@jadzia.bu.edu> Message-ID: <5256d0b05012916173eaa3d71@mail.gmail.com> > > I am sure that the primary browser for the developing Fedora Core 4 > > edition is not high on your priority list. However, if Fedora Core 4 > > is released with a memory devouring browser, as the current Fedora > > Core 4 Firefox is, then the complaints from users, reviewers, and > > administrators will be a strong reminder that libraries and > > applications have significant importance to all users of the OS. > > You should bring this up with the Firefox developers, unless there's a > specific FC bug you can identify. I see this with Firefox as well but I see the same behaviour on Firefox for windows and linux x86 so I don't believe its specificly the fedora version at fault. Definately one for upstream. From aoliva at redhat.com Sun Jan 30 00:46:33 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 29 Jan 2005 22:46:33 -0200 Subject: Better repodata performance (was: redhat abe) In-Reply-To: <1107026606.1614.59.camel@cutter> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> Message-ID: On Jan 29, 2005, seth vidal wrote: > How would it reduce bandwidth - you'd have to download and parse > multiple entries and you'd STILL have to do just a much work on the > repo-side b/c you'd have to check all the packages for changes. The reduced bandwidth would be for the thousands of users who could download a 1KiB file with the changes since the last time they checked the repo, instead downloading 4MiB with about 1KiB of new information. Sure, createrepo would have to look at previous versions of the repodata, see what changed since then (it could optionally use only file timestamps and sizes to check that files haven't changed, instead of having to read them entirely to compute checksums) and generate a new, incremental repository format. What I'm thinking is that this incremental repodata tree would contain the relative location of the original repodata tree, such that whoever downloads the incremental repodata can get to the previous states, and so on, by following the paths given. So we could put in a counter-based repository history with the following properties: - after the first run of createrepo, repodata/repomd.xml points to repodata/0, without adding or removing anything. - after the second run of createrepo, repodata/repomd.xml points to repodata/1, with a repomd.xml that points to ../0, and primary.xml et al files adding/removing packages from ../0 and so on. every now and then, one could consolidate the multiple repodata subdirs into a single set of xml files. You could even do this every time, and have repomd.xml indicate that you can either get all the data from this single set of files, or the incremental history from this other file. This sort of indirection in repomd.xml has one interesting additional side effects: if done properly, it would enable us to create composite and/or filtered repositories. Your composite repository would reference a base repository (or a set thereof) in repomd.xml, as well as package removals or additions so as to filter out packages from one repository that are say known to be incompatible, and additions from your own. This may sure add a lot of complexity to the client side, but reducing daily downloads of rawhide/i386's primary.xml.gz and filelists.xml.gz (totaling 4MiB) by however many users track rawhide to a few KiB sounds like a pretty good idea to me. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From dfarning at sbcglobal.net Sun Jan 30 00:50:30 2005 From: dfarning at sbcglobal.net (David Farning) Date: Sat, 29 Jan 2005 18:50:30 -0600 Subject: Better repodata performance In-Reply-To: <20050130001209.GE21431@angus.ind.WPI.EDU> References: <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> <41FC2248.3010100@sbcglobal.net> <20050130001209.GE21431@angus.ind.WPI.EDU> Message-ID: <41FC2F56.8030602@sbcglobal.net> Charles R. Anderson wrote: > On Sat, Jan 29, 2005 at 05:54:48PM -0600, David Farning wrote: > >>Now, in most situations very few packages have been changed. Therefore, >>between primary.xml versions few ... have changed >>thus most of the information in primary.xml is redundant against >>previous versions of primary.xml. > > > Why all the complication when a general-purpose algorithm, rsync, > already exists to solve this problem? Using rsync or librsync would > require no changes to the repodata... > Debugging a rsync base solution would be a nightmare because it would be much harder to track exactly what is happening for a given update. -dtf From mbneto at gmail.com Sun Jan 30 01:34:06 2005 From: mbneto at gmail.com (mbneto) Date: Sat, 29 Jan 2005 21:34:06 -0400 Subject: Better repodata performance (was: redhat abe) In-Reply-To: <1107036420.1614.72.camel@cutter> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> Message-ID: <5cf776b8050129173454d67d78@mail.gmail.com> Hi, I think that if we reduce to amount of metadata necessary to transfer both users and maintainers will benefit. They will consume less bandwidth and be able to serve more clients and the users will have faster downloads. > Oh and once more - who is it gets the benefit from all this work? > It sounds like it's mostly repo maintainers - not the users. > From aoliva at redhat.com Sun Jan 30 01:41:35 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 29 Jan 2005 23:41:35 -0200 Subject: Better repodata performance In-Reply-To: <20050130001209.GE21431@angus.ind.WPI.EDU> References: <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> <41FC2248.3010100@sbcglobal.net> <20050130001209.GE21431@angus.ind.WPI.EDU> Message-ID: On Jan 29, 2005, "Charles R. Anderson" wrote: > Why all the complication when a general-purpose algorithm, rsync, > already exists to solve this problem? It doesn't do very well on compressed files, and there aren't a lot of rsync-enabled web proxies out there. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From skvidal at phy.duke.edu Sun Jan 30 01:45:11 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 29 Jan 2005 20:45:11 -0500 Subject: Better repodata performance (was: redhat abe) In-Reply-To: <5cf776b8050129173454d67d78@mail.gmail.com> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> <5cf776b8050129173454d67d78@mail.gmail.com> Message-ID: <1107049511.1614.91.camel@cutter> On Sat, 2005-01-29 at 21:34 -0400, mbneto wrote: > Hi, > > I think that if we reduce to amount of metadata necessary to transfer > both users and maintainers will benefit. > > They will consume less bandwidth and be able to serve more clients and > the users will have faster downloads. And the people who get hurt are both users AND developers. users b/c problems will be put-near impossible to debug developers b/c they will have lost sanity writing and maintaining this code. "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" - Brian Kernighan -sv From aoliva at redhat.com Sun Jan 30 04:23:29 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 30 Jan 2005 02:23:29 -0200 Subject: Better repodata performance (was: redhat abe) In-Reply-To: <1107049511.1614.91.camel@cutter> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> <5cf776b8050129173454d67d78@mail.gmail.com> <1107049511.1614.91.camel@cutter> Message-ID: On Jan 29, 2005, seth vidal wrote: > users b/c problems will be put-near impossible to debug > developers b/c they will have lost sanity writing and maintaining this > code. In other words, you have somehow proved that it's impossible to both have better behavior and still be maintainable? This is quite a breakthrough in software engineering! :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From skvidal at phy.duke.edu Sun Jan 30 04:29:19 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 29 Jan 2005 23:29:19 -0500 Subject: Better repodata performance (was: redhat abe) In-Reply-To: References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> <5cf776b8050129173454d67d78@mail.gmail.com> <1107049511.1614.91.camel@cutter> Message-ID: <1107059359.1614.96.camel@cutter> > In other words, you have somehow proved that it's impossible to both > have better behavior and still be maintainable? This is quite a > breakthrough in software engineering! :-) No, I'm just trying to keep folks, including myself, from doing a lot of work that ends up being a real serious pain for years on end. -sv From aoliva at redhat.com Sun Jan 30 04:48:22 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 30 Jan 2005 02:48:22 -0200 Subject: Better repodata performance (was: redhat abe) In-Reply-To: <1107059359.1614.96.camel@cutter> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> <5cf776b8050129173454d67d78@mail.gmail.com> <1107049511.1614.91.camel@cutter> <1107059359.1614.96.camel@cutter> Message-ID: On Jan 30, 2005, seth vidal wrote: >> In other words, you have somehow proved that it's impossible to both >> have better behavior and still be maintainable? This is quite a >> breakthrough in software engineering! :-) > No, I'm just trying to keep folks, including myself, from doing a lot of > work that ends up being a real serious pain for years on end. Like trying to get everybody to agree on a format that is specifically designed to get every user to download a multi-megabyte file every time a repository has any change whatsoever? If you're trying to avoid real serious pain for years on end too, we're on the same boat :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From n3npq at nc.rr.com Sun Jan 30 07:03:57 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sun, 30 Jan 2005 02:03:57 -0500 Subject: Better repodata performance In-Reply-To: <1107059359.1614.96.camel@cutter> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> <5cf776b8050129173454d67d78@mail.gmail.com> <1107049511.1614.91.camel@cutter> <1107059359.1614.96.camel@cutter> Message-ID: <41FC86DD.2050100@nc.rr.com> seth vidal wrote: >>In other words, you have somehow proved that it's impossible to both >>have better behavior and still be maintainable? This is quite a >>breakthrough in software engineering! :-) >> >> > >No, I'm just trying to keep folks, including myself, from doing a lot of >work that ends up being a real serious pain for years on end. > > You mean like rpm is a pain? ;-) 73 de Jeff From skvidal at phy.duke.edu Sun Jan 30 07:15:44 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 30 Jan 2005 02:15:44 -0500 Subject: Better repodata performance In-Reply-To: <41FC86DD.2050100@nc.rr.com> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> <5cf776b8050129173454d67d78@mail.gmail.com> <1107049511.1614.91.camel@cutter> <1107059359.1614.96.camel@cutter> <41FC86DD.2050100@nc.rr.com> Message-ID: <1107069344.1614.99.camel@cutter> > > > > You mean like rpm is a pain? ;-) hahah, yes, but that's your pain :) -sv From n3npq at nc.rr.com Sun Jan 30 07:53:27 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sun, 30 Jan 2005 02:53:27 -0500 Subject: Better repodata performance In-Reply-To: <1107069344.1614.99.camel@cutter> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> <5cf776b8050129173454d67d78@mail.gmail.com> <1107049511.1614.91.camel@cutter> <1107059359.1614.96.camel@cutter> <41FC86DD.2050100@nc.rr.com> <1107069344.1614.99.camel@cutter> Message-ID: <41FC9277.1060807@nc.rr.com> seth vidal wrote: >>You mean like rpm is a pain? ;-) >> >> > >hahah, yes, but that's your pain :) > > More seriously, I'm like a weekend's work away from adding a look-aside cache to rpm -4.4.x (which has a relaible http/https stack using neon) that could be invoked asynchronously to yum as rpm -q http://host/path/to/N-V-R.A.rpm and then yum could read the header from the package as it was being downloaded into /var/cache/yum/repo/packages since you already know the header byte range you are interested in from the xml metadata, thereby saving the bandwidth used by reading the header twice. That's a far bigger bandwidth saving than attempting to fragment primary.xml, which already has timestamp checks to avoid downloading the same file repeatedly (I've not looked at yum code, but that's a pretty easy check if not there already). Or, if you don't want to wait for me to get off my butt and add the lookaside cache to rpm, then roll your own helper that permits the same saving, i.e. don't download the header twice. Then perhaps this endless thread can move on to other issues ;-) From www.apple.com: Tip of the Week: Force Quit is Easy! Hehehe ... 73 de Jeff From laroche at redhat.com Sun Jan 30 09:07:53 2005 From: laroche at redhat.com (Florian La Roche) Date: Sun, 30 Jan 2005 10:07:53 +0100 Subject: checking binary rpm packages In-Reply-To: <41FBE89E.9000004@balclutha.org> References: <41FBE89E.9000004@balclutha.org> Message-ID: <20050130090753.GB26512@dudweiler.stuttgart.redhat.com> On Sun, Jan 30, 2005 at 06:48:46AM +1100, Alan Milligan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Florian, > > Just a quick spin up over some of our packages: > > /usr/src/redhat/BUILD/i386/Fedora/RPMS/kernel-2.6.9-1.667.root.i686.rpm: > tag 1147 is marked legacy > /usr/src/redhat/BUILD/i386/Fedora/RPMS/mozilla-1.7.3-17.i386.rpm: tag > 1147 is marked legacy > /usr/src/redhat/BUILD/i386/Fedora/RPMS/mozilla-enigmail-0.89.6-1.i386.rpm: > unknown packager: Alan Milligan > /usr/src/redhat/BUILD/i386/Fedora/RPMS/mozilla-enigmail-0.89.6-1.i386.rpm: > unknown vendor: last-bastion.net > /usr/src/redhat/BUILD/i386/Fedora/RPMS/mozilla-nspr-1.7.3-17.i386.rpm: > tag 1147 is marked legacy > /usr/src/redhat/BUILD/i386/Fedora/RPMS/mozilla-nss-1.7.3-17.i386.rpm: > tag 1147 is marked legacy > /usr/src/redhat/BUILD/i386/Fedora/RPMS/openssl-0.9.7d-12.i386.rpm: tag > 1147 is marked legacy > /usr/src/redhat/BUILD/i386/Fedora/RPMS/PIL-1.1.4-1.i386.rpm: unknown > vendor: Last Bastion Network > /usr/src/redhat/BUILD/i386/Fedora/RPMS/rsync-2.6.3-1.i386.rpm: tag 1147 > is marked legacy > /usr/src/redhat/BUILD/i386/Fedora/RPMS/wxPythonGTK-py2.3-2.4.2.4-2.i386.rpm: > unknown packager: Robin Dunn > /usr/src/redhat/BUILD/i386/Fedora/RPMS/zope-2.7.3b1-7.i386.rpm: unknown > vendor: Last Bastion Network > /usr/src/redhat/BUILD/i386/Fedora/RPMS/zoperl-1.0.1-5.i386.rpm: unknown > vendor: Zope Corporation and Contributors > > How about resolving tag 1147 to it's friendly name? Also, what must be > done to become a 'known packager/vendor'??? Hello Alan, your output comes from "--strict" where a bit more content is checked from rpm packages. Are e.g. vendor fields setup correctly. Tag 1147 has been information on what SELinux filecontexts should be given to included files. We don't include that anymore within binary rpm packages, but keep that in the selinux-policy-* packages. If you want to check your rpm packages about included content and good packaging rules, "rpmlint" has way more checks for this and is a very nice tool (http://people.redhat.com/laroche/ also contains output data from rpmlint, too). greetings, Florian La Roche From ville.skytta at iki.fi Sun Jan 30 08:49:36 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 30 Jan 2005 10:49:36 +0200 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <604aa791050128184867367312@mail.gmail.com> References: <1106333362.3427.19.camel@localhost.localdomain> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DB8D.686FCF33@jwz.org> <20050128120336.21dad318.fedora@wir-sind-cool.org> <41FAE2BF.4EF5FD29@jwz.org> <604aa7910501281721741be6c4@mail.gmail.com> <41FAE8E1.6AE64597@jwz.org> <604aa791050128184867367312@mail.gmail.com> Message-ID: <1107074976.4018.212.camel@bobcat.mine.nu> On Fri, 2005-01-28 at 21:48 -0500, Jeff Spaleta wrote: > [...] emacs based media player.. im sure we could dig one up if people > are interested. http://www.gentei.org/~yuuji/software/mpg123el/ From ville.skytta at iki.fi Sun Jan 30 09:53:04 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Sun, 30 Jan 2005 11:53:04 +0200 Subject: Apt at fedora.us (was: Re: redhat abe) In-Reply-To: <20050128134756.70f3a4fb.fedora@wir-sind-cool.org> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <20050128123043.3a60b213.fedora@wir-sind-cool.org> <1106915462.5389.15.camel@mccallum.corsepiu.local> <20050128134756.70f3a4fb.fedora@wir-sind-cool.org> Message-ID: <1107078784.4018.216.camel@bobcat.mine.nu> On Fri, 2005-01-28 at 13:47 +0100, Michael Schwendt wrote: > On Fri, 28 Jan 2005 13:31:01 +0100, Ralf Corsepius wrote: > > > I had asked Warren Togami to add them on PM and he answered: > > "There is little good reason to do so. Trying to limit the size of that > > repository because many mirror administrators see it as redundant." > > > > This is not true, SRPMS apt-repositories are not redundant. Not having > > them implies loss of functionality to apt. > > Well, then I think the Apt community may need to prove him wrong > and do some lobbying. FWIW, I would like to see the complete apt'table (pre-)Extras SRPMS repos available at fedora.us and its mirrors. The reasons have been outlined in this thread. From rodd at clarkson.id.au Sat Jan 29 02:49:35 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sat, 29 Jan 2005 13:49:35 +1100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <41F9DA4D.7040801@tlarson.com> References: <1106333362.3427.19.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DA4D.7040801@tlarson.com> Message-ID: <1106966975.5678.18.camel@localhost.localdomain> On Thu, 2005-01-27 at 23:23 -0700, Tyler Larson wrote: > Rodd Clarkson wrote: > Lets face it, if we're really interested in shrinking the size of the > distro, cutting a few packages like XMMS isn't going to make a spit of > difference. Not even eliminating unused packages is going to do much good. Sure xmms is small, but it's about 4.8M of RPMS (including devel, flac and skins) On top of this is requires the GTK-1.x libraries so assuming not a lot else uses these libraries you're another step towards not needing them in core anymore. And while 4.8M doesn't sound like much, that's almost 1% of a CD-ROM. It's a start. You only need to find about 120 more little apps that are duplicated in functionality and your well on your way to a CD-ROM being removed. > If we want to make an appreciable difference in the size of FC, we've > got to cut at least enough to remove a CD or two. If we just cut a few > redundant packages, we piss some people off, but gain nearly nothing. Agreed. But as long as these packages are easy to install (yum install package) then this isn't a huge deal. > If we really want to cut the size of the distro by more than a few > hundred meg, we've got to start removing functionality. Plain and > simple. Something that lots of people *need* has to go. And you're not > going to do it without making a whole lot of people really, really mad. Not if you handle it well. I know that's a big ask, but it can be handled well. There a plenty of distros out there that only use a single CD and these users are more than satisfied with what comes on the disk. > So, what gets the ax? Tough to say. There's only 15 packages in fc3 that > are >= 20 Meg. And OOo accounts for almost 200M of that. But can we > really ax OpenOffice? Heresy. KDE? Blasphemous. Sure, stick OOo on a extras CD-ROM. The ISO would be small, so those who want it wouldn't have to download a lot, and most would just yum install it. Since RH really doesn't focus on KDE (all the RH tools use GTK) I don't have any problem with KDE being on a separate Extras disk either. This may sound arrogant, I'll admit that I'm not a KDE user, but haing to grab a single extras disk for KDE (and a lot of KDE users sound like they get their KDE from somewhere else than RH) instead of everyone having to grab four disks is a big win for everyone, even if you want KDE. KDE users grab two ISOs, others grab one. Users of OOo grab another. Sure you might end up with 9 or 10 extras disks (Java, KDE, OOo, etc) but none would fill a disk so you aren't grabbing huge amounts of stuff your aren't ever going to use. Imagine how nice is would be if instead of trying to fit everything onto four disks inside four ISOs with a stack of software you are never going to use so you can get the few bits you do use, you could instead grab on CORE ISO and four or five smaller isos that target the stuff you want. > Sure, we could move packages to Extras... if only we had some idea what > Extras is. Whatever it is, though, I'm quite certain that the packages > *I* use don't belong there, right? But if the Extras CDs are distributed > with the core CDs, and if most people will need the Extras CDs to get > those last three packages they're rather fond of, what really is the > point dividing them up? Other than, of course, to inconvenience the > user. I was all for it a few hours ago, but now it doesn't sound like > we'll be helping anyone out. If people need a few extra packages (like the three number you suggest) it's going to be far easier to just yum install them, rather than download three extra 650MB ISOs for these three, or four, or ten, or twenty packages. > > The way I see it, we're left with two options: > A) Big distro. Deal with it. Little distro, better deal > B) Piss lots of people off because Fedora no longer includes the > software they use. Sorry KDE and OOo users. Well defined ISOs which target users needs and save dramatically on the amount of downloads they need just to install CORE, KDE and OOo. Everyone wins. > The third option, "remove the stuff people don't use", seems more like a > pipe dream than a viable course of action. You can't remove enough fat > to keep A from happening without bringing about B. Moving a substantial > amount of stuff into an "Extras" category (or whatever it is) seems like > a "worst of both worlds" solution. Not only has the total software base > not shrunk, but it's now more difficult to find the package you want. > What are the chances, really, that the average user *won't* want at > least some of the software on the Extras CD(s)? Everyone uses something different so it just wont happen. Personally I would love to just have to download the CORE disk, and the OOo, Java, and Devel disks and then just yum the few other packages I need. What a dream. Having to download over 2GB of disks is a PITA. Of course, the Extras concept has to work well and people have to realize that there is value in having ISOs that don't consume a CD. If all you need for OOo is a 200 ISO, then that's all it should be. The temptation to do OOo and KDE on the one disk should be ignored. Both ISOs won't be much more than a single ISO with both, but users who only want one or the other will be much better off. > I don't know. The more I think about it, the less excited I get. Perhaps > someone can share a more rosy picture of how moving packages to Fedora > Extras is supposed to make the users' lives so much easier. Anyone care > to bite? The more I think about it the more I think this is the way to go. I'd love a distro that offered more than a single disks functionality, but also offered a single disk that functions, along with small(er) downloads to address particular focus areas. Combine this with the ease of using yum to add those one or two other packages and how good would that be. Rodd -- >From the pain come the dream >From the dream come the vision >From the vision come the people >From the people come the power >From this power come the change - Peter Gabriel From felipe_alfaro at linuxmail.org Sun Jan 30 12:30:13 2005 From: felipe_alfaro at linuxmail.org (Felipe Alfaro Solana) Date: Sun, 30 Jan 2005 13:30:13 +0100 Subject: FreeNX SRPMs Message-ID: Hello, I have some custom SRPMs packages for FreeNX, updated to the latest sources from nomachine.com, and built for Rawhide. They support PAM authentication and don't require a separate user database. Also, resuming of suspended sessions works fine, and suspended sessions don't get frozen. Is anyone interesed in them? Thanks. From buildsys at redhat.com Sun Jan 30 12:59:05 2005 From: buildsys at redhat.com (Build System) Date: Sun, 30 Jan 2005 07:59:05 -0500 Subject: rawhide report: 20050130 changes Message-ID: <200501301259.j0UCx5s12326@porkchop.devel.redhat.com> Updated Packages: enscript-1.6.1-29 ----------------- * Sat Jan 29 2005 Tim Waugh 1.6.1-29 - Applied patch to fix CAN-2004-1186 (bug #144684). - Applied patch to fix CAN-2004-1185 (bug #144684). - Backported patch to fix CAN-2004-1184 (bug #144684). * Mon Sep 27 2004 Tim Waugh 1.6.1-28 - Fixed double-free problem (bug #132964). * Tue Jun 15 2004 Elliot Lee - rebuilt gimp-2:2.2.3-2 -------------- * Sat Jan 29 2005 Nils Philippsen - make desktop icon themeable (#146486) * Mon Jan 24 2005 Nils Philippsen - version 2.2.3 - remove exifmarkerlength patch (improved version applied upstream) * Mon Jan 17 2005 Nils Philippsen - clip thumbnail quality at 75 and don't barf on saving images at quality 0 (fix patch for #145100) perl-3:5.8.6-3 -------------- * Sat Jan 29 2005 Warren Togami - 3:5.8.6-3 - bugzilla: 127025, fix strip warnings rpmdb-fedora-1:4-0.20050130 --------------------------- From fedora-devel at camperquake.de Sun Jan 30 14:28:56 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Sun, 30 Jan 2005 15:28:56 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1106966975.5678.18.camel@localhost.localdomain> References: <1106333362.3427.19.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DA4D.7040801@tlarson.com> <1106966975.5678.18.camel@localhost.localdomain> Message-ID: <20050130152856.408462dd@nausicaa.camperquake.de> Hi. Rodd Clarkson wrote: > Sure xmms is small, but it's about 4.8M of RPMS (including devel, flac > and skins) On top of this is requires the GTK-1.x libraries so assuming > not a lot else uses these libraries you're another step towards not > needing them in core anymore. I played with rpm a little today to see what prevents gtk1 being removed. After "rpm -e --test"'ing a whole lot of gtk1 and gnome1 gruft it basically comes down to a handful of applications that are currently in FC (and a quite impressive list of applications from external repos, but that's another story): xmms system-config-proc mtr-gtk and, most important, gnucash. There are some libraries I had to remove of which I am not sure whether there are gtk2 replacements (and what these things are good for, anyway): Guppi gal Please note that the above list just represents what currently is installed on my machine. -- "OK, last one to kill a bad guy buys the beer!" From alan at redhat.com Sun Jan 30 15:01:21 2005 From: alan at redhat.com (Alan Cox) Date: Sun, 30 Jan 2005 10:01:21 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <20050128195709.0e0a4be2@python2> References: <20050124144739.GC7619@angus.ind.WPI.EDU> <1106579519.25770.0.camel@opus.phy.duke.edu> <200501242321.41817.symbiont@berlios.de> <41F516E6.6090206@nc.rr.com> <20050128195709.0e0a4be2@python2> Message-ID: <20050130150121.GA28143@devserv.devel.redhat.com> On Fri, Jan 28, 2005 at 07:57:09PM +0100, Matthias Saou wrote: > > %post > > chattr +i `rpm -ql name` > > > > should make the package non-upgradeable no matter what. > > Nice one, "bulldozer style". Never thought of it before :-) It does tend to make a nasty mess of update tools however. If you want to do this for the normal situation just bump the epoch of your private rebuilds From rdieter at math.unl.edu Sun Jan 30 15:28:16 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 30 Jan 2005 09:28:16 -0600 (CST) Subject: FreeNX In-Reply-To: References: Message-ID: On Sun, 30 Jan 2005, Felipe Alfaro Solana wrote: > I have some custom SRPMs packages for FreeNX, updated to the latest sources Perhaps you could contribute to the FreeNX Fedora Extras submission: http://bugzilla.fedora.us/show_bug.cgi?id=2101 -- Rex From laroche at redhat.com Sun Jan 30 16:45:32 2005 From: laroche at redhat.com (Florian La Roche) Date: Sun, 30 Jan 2005 17:45:32 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050130152856.408462dd@nausicaa.camperquake.de> References: <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DA4D.7040801@tlarson.com> <1106966975.5678.18.camel@localhost.localdomain> <20050130152856.408462dd@nausicaa.camperquake.de> Message-ID: <20050130164532.GA27982@dudweiler.stuttgart.redhat.com> > system-config-proc Just delete this one, we won't release a new version of this one. Not included in Fedora Core anymore. > xmms > mtr-gtk > and, most important, gnucash. These should really get ported to gtk1. Is there any reason why nobody wants to change them over? greetings, Florian La Roche From byte at aeon.com.my Sun Jan 30 16:15:39 2005 From: byte at aeon.com.my (Colin Charles) Date: Sun, 30 Jan 2005 21:45:39 +0530 Subject: fedora stable branch updates Q&A policy In-Reply-To: <1107031490.4174.18.camel@localhost.localdomain> References: <1106851614.2656.7.camel@localhost.localdomain> <1106905427.5373.57.camel@localhost.localdomain> <1106945584.6895.4.camel@localhost.localdomain> <1106988109.11086.28.camel@localhost.localdomain> <1107031490.4174.18.camel@localhost.localdomain> Message-ID: <1107101740.7956.12.camel@localhost.localdomain> On Sat, 2005-01-29 at 21:44 +0100, Kyrre Ness Sjobak wrote: > > When we do release FC(n+1) test X, those discussions get moved to > > fedora-test-list at redhat.com > > Where does update testing go then? Same list as above. If the information at the respective lists aren't clear, please e-mail fedora-test-list-owner at redhat.com, as this is now seriously becomming off-topic -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From fedora-devel at camperquake.de Sun Jan 30 16:20:40 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Sun, 30 Jan 2005 17:20:40 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050130164532.GA27982@dudweiler.stuttgart.redhat.com> References: <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DA4D.7040801@tlarson.com> <1106966975.5678.18.camel@localhost.localdomain> <20050130152856.408462dd@nausicaa.camperquake.de> <20050130164532.GA27982@dudweiler.stuttgart.redhat.com> Message-ID: <20050130172040.1f9f479d@nausicaa.camperquake.de> Hi. Florian La Roche wrote: > These should really get ported to gtk1. Is there any reason why nobody > wants to change them over? Looking at gnucash I think of a number of reasons. This thing is huge. I remember one of the gnucash developers saying that some widgets used in gnucash are simply not there in gtk2. -- "a truly cute computer would have to be upholstered, preferably in mohair or nubuck" -- Iain Georgeson From aoliva at redhat.com Sun Jan 30 17:55:05 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 30 Jan 2005 15:55:05 -0200 Subject: Better repodata performance In-Reply-To: <41FC9277.1060807@nc.rr.com> References: <20050127082839.GE29221@batman.gotham.krass.com> <200501290027.05357.symbiont@berlios.de> <1106937879.26755.6.camel@cutter> <200501290954.22339.symbiont@berlios.de> <1106984170.1614.34.camel@cutter> <20050129113933.GB16904@neu.nirvana> <1107026606.1614.59.camel@cutter> <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> <5cf776b8050129173454d67d78@mail.gmail.com> <1107049511.1614.91.camel@cutter> <1107059359.1614.96.camel@cutter> <41FC86DD.2050100@nc.rr.com> <1107069344.1614.99.camel@cutter> <41FC9277.1060807@nc.rr.com> Message-ID: On Jan 30, 2005, Jeff Johnson wrote: > More seriously, I'm like a weekend's work away from adding a look-aside > cache to rpm -4.4.x (which has a relaible http/https stack using neon) that > could be invoked asynchronously to yum as > rpm -q http://host/path/to/N-V-R.A.rpm > and then yum could read the header from the package as it was being > downloaded Err... By the time yum or any other depsolver decides to download a package, it's already got all the headers for all packages. And I hope you're not suggesting yum to get rpm to download *all* packages just because it needs headers. *That* would be a waste of bandwidth. > into /var/cache/yum/repo/packages since you already know the header > byte range you are interested in from the xml metadata, thereby > saving the bandwidth used by reading the header twice. Hmm... I hope you're not saying yum actually fetches the header portion out of the rpm files for purposes of dep resolution. Although I realize the information in the .xml file makes it perfectly possible, it also makes it (mostly?) redundant. Having to download not only the big xml files but also all of the headers would suck in a big way! I was thinking to myself that having to download only the compressed xml files might be a win (bandwidth-wise) over going though all of the headers like good old yum 2.0 did, at least in the short term, and for a repository that doesn't change too much. But having to download the xml files *and* the rpm's headers upfront would make the repodata format a bit loser, because not only would you waste a lot of bandwidth with the xml files, that are much bigger than the header.info files, but also because fetching only the header portion out of the rpm files with byte-range downloads makes them non-cacheable by say squid. I'd be very surprised if yum 2.1 actually worked this way. I expect far better from Seth, and from what I read during the design period of the metadata format, I understood that the point of the xml files was precisely to avoid having to download the hdr files in the first place. So why would they be needed? To get rpmlib to verify the transaction, perhaps? > That's a far bigger bandwidth saving than attempting to fragment > primary.xml, > which already has timestamp checks to avoid downloading the same file > repeatedly The problem is not downloading the same file repeatedly. The problem is that, after it is updated, you have to download the entire file again to get a very small amount of new information. Assuming a biggish repository like FC updates, development, pre-extras, extras or dag, freshrpms, at-rpms, newrpms, etc, it's a lot of wasted bandwidth. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From laroche at redhat.com Sun Jan 30 18:45:30 2005 From: laroche at redhat.com (Florian La Roche) Date: Sun, 30 Jan 2005 19:45:30 +0100 Subject: Better repodata performance In-Reply-To: References: <20050129212206.GA22924@neu.nirvana> <1107036420.1614.72.camel@cutter> <5cf776b8050129173454d67d78@mail.gmail.com> <1107049511.1614.91.camel@cutter> <1107059359.1614.96.camel@cutter> <41FC86DD.2050100@nc.rr.com> <1107069344.1614.99.camel@cutter> <41FC9277.1060807@nc.rr.com> Message-ID: <20050130184530.GA29044@dudweiler.stuttgart.redhat.com> > I was thinking to myself that having to download only the compressed > xml files might be a win (bandwidth-wise) over going though all of the > headers like good old yum 2.0 did, at least in the short term, and for > a repository that doesn't change too much. Since you need all filelists to look at dependencies, the data is just real big. True, the rpm deps are real nice working to have the correct packages installed. One thing I always wondered: Given you only install from one repository (or maybe several ones where then data is collected for all of them;-) and you create a special dep graph. Can you then use a reduced dep info to know that packages all update to available rpm packages in the newest repository and you can then use the graph to look at deps instead of computing that again on the client side? greetings, Florian La Roche From n3npq at nc.rr.com Sun Jan 30 18:43:59 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sun, 30 Jan 2005 13:43:59 -0500 Subject: Better repodata performance Message-ID: <41FD2AEF.4060008@nc.rr.com> -------------- next part -------------- An embedded message was scrubbed... From: Jeff Johnson Subject: Re: Better repodata performance Date: Sun, 30 Jan 2005 13:33:39 -0500 Size: 2966 URL: From n3npq at nc.rr.com Sun Jan 30 18:55:19 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sun, 30 Jan 2005 13:55:19 -0500 Subject: Better repodata performance Message-ID: <41FD2D97.4010809@nc.rr.com> -------------- next part -------------- An embedded message was scrubbed... From: Jeff Johnson Subject: Re: Better repodata performance Date: Sun, 30 Jan 2005 13:22:00 -0500 Size: 5899 URL: From aoliva at redhat.com Sun Jan 30 20:16:21 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 30 Jan 2005 18:16:21 -0200 Subject: Better repodata performance In-Reply-To: <41FD2D97.4010809@nc.rr.com> References: <41FD2D97.4010809@nc.rr.com> Message-ID: On Jan 30, 2005, Jeff Johnson wrote: > Alexandre Oliva wrote: >> Err... By the time yum or any other depsolver decides to download a >> package, it's already got all the headers for all packages. And I > Yep, "already got" so lets's go get the header again. I see. Still, it's probably unwise to get the transaction verification procedure waiting for all big packages to download, or competing for limited bandwidth, when the headers alone would have sufficed. An idea to overcome this issue without throwing away possible web caching benefits would be to start a download of the entire rpm and, by the time you get to the end of the header, you stop reading from that connection until you've completed the transaction verification. If you have a web proxy, it will likely keep on downloading the entire package, and you'll end up downloading the rest of it very quickly, but the downloads will be competing for bandwidth. If you don't have a web proxy, however, things may get messy: not only will you get competition for bandwidth, you'll also get competition for any limit on open connections that may be imposed on you by upstream (ISP, download server, etc). (My DSL provider, for example, won't let me establish more than 30 TCP connections simultaneously) >> hope you're not suggesting yum to get rpm to download *all* packages >> just because it needs headers. *That* would be a waste of bandwidth > Depends on how yum implements, but we agree that "all" is stupid, > even if we appear to disagree whether headers being downloaded and > then downloaded again is stupid. We do agree on both accounts. >>> into /var/cache/yum/repo/packages since you already know the header >>> byte range you are interested in from the xml metadata, thereby >>> saving the bandwidth used by reading the header twice. >> Hmm... I hope you're not saying yum actually fetches the header >> portion out of the rpm files for purposes of dep resolution. Although >> I realize the information in the .xml file makes it perfectly >> possible, it also makes it (mostly?) redundant. Having to download >> not only the big xml files but also all of the headers would suck in a >> big way! > The rpmlib API requires a header for a ride. So yes, that is exactly what > is happening, yum is using byte ranges to pull headers from discovered > packages where (if discovered, packages are needed) both header+payload > could be pulled togethere and asynchronously. I hope you're really not saying that, if I request to install package foo, that depends on bar, it will also download headers for baz, a totally unrelated package. I can see that we'd need headers for foo and bar, but not for baz. I thought the point of the xml files and the info on provides, filelists, etc, was precisely to enable the depsolver to avoid having to download the headers for every package. I'm wondering if it would be possible for a depsolver to create a (smaller) .hdr file out of info in the .xml files, and feed that to rpmlib for transaction-verification purposes. This would enable it to skip the download-header step before downloading the entire package. > The repo data is a win over previous incarnations of yum becuase > it's one, not hundreds, of files that needs to be downloaded. It's clear to me that it's a win for a one-shot download. What's not clear is that, downloading the entire .xml files 2-3 times a day, or every time it's updated (which rhn-applet would presumably do, although a simple listing of package N-V-Rs would be enough for it), you won't end up wasting more bandwidth than having the .hdr files downloaded once and for all. > filtering the data (i.e. headers have changelogs and more that is > useless baggage) is also a win. Definitely. But couldn't we perhaps do it by intelligently filtering information out of the rpm header and, say, generating a single archive containing all of the info needed for depsolving and for rpmlib's transaction verification? It might still be useful to have something like header.info, but have it compressed, and not only listing N-V-Rs, but also the header ranges should one want to download the headers for individual packages, as opposed to the xml files or equivalent, a previous version of which was downloaded in the past and whose data is still locally-available, and that has undergone very slight changes. > So the suggestion was to download the package, not the header, and then > extract the header from local, not remote storage. I see. Good one, if we can't help downloading the package (e.g., because rpmlib ends up deciding it can't install the packages) >> I'd be very surprised if yum 2.1 actually worked this way. I expect >> far better from Seth, and from what I read during the design period >> of the metadata format, I understood that the point of the xml files >> was precisely to avoid having to download the hdr files in the first >> place. So why would they be needed? To get rpmlib to verify the >> transaction, perhaps? > What do you expect? There is no way to create a transaction using rpmlib > without a header, a header is wired in the rpmlib API. So honk at failed > rpmlib design, not otherwise. I was expecting depsolving wouldn't require all the headers. And from what I gather from your reply, it indeed doesn't. > Look, repos currently change daily, perhaps twice daily. They actually change more often than that. rawhide changes daily, yes. FC updates sometimes change several times in a single day, and then sometimes stay put for a few days. Could be once or twice a day, indeed. Other repos such as dag and freshrpms change more often than that, it seems to me. At least once a day would be an accurate description for them. > Trying to optimize incremenatl updates for something that changes > perhaps twice a day is fluff. Let me try some back-of-the-envelope calculations here. Consider an FC install that remains installed for 40 weeks (~ 9 months), and has a user permanently running rhn-applet, and whose administrator runs up2date once a day on average. Further consider that updates are released, on average, once a day, and that, on average, only two of the 7 weekly update runs actually have new packages to install (i.e., updates are generally published in batches) Let's consider two scenarios: 1) using up2date with yum-2.0 (headers/) repos (whoever claimed up2date supported rpmmd repodata/ misled me :-) and 2) using yum-2.1 (repodata/) repos. 1) yum 2.0 16MiB) initial download, distro's and empty updates's hdrs 8MiB) daily (on average) downloads of header.info for updates, downloaded by rhn-applet, considering an average size of almost 30KiB, for 40 weeks. (both FC2 and FC3 updates for i386 have a header.info this big right now) 16MiB) .hdr files for updates, downloaded by the update installer. Current FC2 i386 headers/ holds 9832KiB, whereas FC3 i386 headers/ holds 8528KiB, but that doesn't count superseded updates, whose .hdr files are removed. The assumption is that each header is downloaded once. 16MiB is a guestimate, that I believe to be inflated. It doesn't take into account the duplicate downloads of header.info for updates, under the assumption that a web proxy would avoid downloading again what rhn-applet has already downloaded. ---- 40MiB) just in metadata over a period of 9 months, total 2) yum 2.1 2.7MiB) initial download, distro's and empty updates' primary.xml.gz and filelists.xml.gz 68MiB) daily (on average) downloads of primary.xml.gz, downloaded by rhn-applet, considering an average size of 250KiB (FC2 updates's is 240KiB, whereas FC3's is 257KiB, plus about 1KiB for repomd.xml) 16MiB) .hdr files for updates, downloaded by the update installer (same as in case 1) 192MiB) filelists.xml.gz for updates, downloaded twice a week on average by the update installer, to solve filename dep. ---- 278.7MiB) just in metadata over a period of 9 months, total Looks like a waste of at least 238.7 MiB per user per 9-month install. Sure, it's not a lot, only 26.5MiB a month, but it's almost 6 times as much data being transferred for the very same purpose. How is that a win? Multiply that by the number of users pounding on your mirrors and it adds up to hundreds of GiB a month. Of course there are some factors that can help minimize the wastage, for example, a web proxy serving multiple machines, one of which is updated before the others, will be able to serve the headers for yum 2.1 out of the cached .rpm files, so you transfer the headers by themselves only once for all machines, instead of once per machine. But then, yum 2.0 enables the web proxy to cache headers anyway, so this would be a win for both, and less so for yum 2.1 if you update multiple boxes in parallel. Another factor is that you probably won't need filelists.xml.gz for every update. Maybe I don't quite understand how often it is needed, but even if I have to download it only once a month, that's still 64MiB over 9 months, more than the 40MiB total metadata downloaded over 9 months by yum 2.0. > The rpm-metadata is already a huge win, as the previous incarnation > checked time stamps on hundreds and thousands of headers, not one > primary file. I don't know how yum 2.0 did it, but up2date surely won't even try to download a .hdr file if it already has it in /var/spool/up2date, so this is not an issue. > Sure there are further improvements, but busting up repo metadata > ain't gonna be where the win is, there's little gold left in that > mine. repodata helps the initial download, granted, but it loses terribly in the long run. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From kyrre at solution-forge.net Sun Jan 30 20:56:55 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 30 Jan 2005 21:56:55 +0100 Subject: rawhide firefox and background colour of webpages (CSS broken?) Message-ID: <1107118615.3866.9.camel@localhost.localdomain> I have installed rawhide firefox on my fc3 computer, and it is pretty nice - exept two thing. Background color on several webpages (phpBB forums f.ex.) are now grayish. Not white (?) as they should be, judging from the white "border" around buttons. Also, it has no norwegian language support. This is version 1.0.8 From peter.backlund at home.se Sun Jan 30 21:11:08 2005 From: peter.backlund at home.se (Peter Backlund) Date: Sun, 30 Jan 2005 22:11:08 +0100 Subject: rawhide firefox and background colour of webpages (CSS broken?) In-Reply-To: <1107118615.3866.9.camel@localhost.localdomain> References: <1107118615.3866.9.camel@localhost.localdomain> Message-ID: <1107119468.5724.0.camel@localhost.localdomain> s?n 2005-01-30 klockan 21:56 +0100 skrev Kyrre Ness Sjobak: > I have installed rawhide firefox on my fc3 computer, and it is pretty > nice - exept two thing. > > Background color on several webpages (phpBB forums f.ex.) are now > grayish. Not white (?) as they should be, judging from the white > "border" around buttons. I've seen this too, downgraded to fc3 firefox. /Peter From skvidal at phy.duke.edu Sun Jan 30 21:14:52 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 30 Jan 2005 16:14:52 -0500 Subject: Better repodata performance In-Reply-To: References: <41FD2D97.4010809@nc.rr.com> Message-ID: <1107119692.1614.116.camel@cutter> > I hope you're really not saying that, if I request to install package > foo, that depends on bar, it will also download headers for baz, a > totally unrelated package. I can see that we'd need headers for foo > and bar, but not for baz. I thought the point of the xml files and > the info on provides, filelists, etc, was precisely to enable the > depsolver to avoid having to download the headers for every package. Just so we don't go off into deeply uninformed space: yum 2.0.X downloaded all the headers in the headers directory that it did NOT have installed. It figured this out by reading header.info. This file stored nevra + rpm location. So yum 2.0.X downloaded this file to see what new headers it needed, downloaded them, then got on with the process at hand. > I'm wondering if it would be possible for a depsolver to create a > (smaller) .hdr file out of info in the .xml files, and feed that to > rpmlib for transaction-verification purposes. This would enable it to > skip the download-header step before downloading the entire package. Talk to Paul Nasrat - he was working on that a while ago but I think he got stuck in some rabbit hole debugging something. > Definitely. But couldn't we perhaps do it by intelligently filtering > information out of the rpm header and, say, generating a single > archive containing all of the info needed for depsolving and for > rpmlib's transaction verification? you can't do that b/c file conflicts CAN NOT be calculated via rpm w/o having the full header and/or all the file information present. > I was expecting depsolving wouldn't require all the headers. And from > what I gather from your reply, it indeed doesn't. it requires all the headers of the packages involved, yes. > Let's consider two scenarios: 1) using up2date with yum-2.0 (headers/) > repos (whoever claimed up2date supported rpmmd repodata/ misled me :-) > and 2) using yum-2.1 (repodata/) repos. > > 1) yum 2.0 > > 16MiB) initial download, distro's and empty updates's hdrs > > 8MiB) daily (on average) downloads of header.info for updates, > downloaded by rhn-applet, considering an average size of almost > 30KiB, for 40 weeks. (both FC2 and FC3 updates for i386 have a > header.info this big right now) > > 16MiB) .hdr files for updates, downloaded by the update installer. > Current FC2 i386 headers/ holds 9832KiB, whereas FC3 i386 > headers/ holds 8528KiB, but that doesn't count superseded > updates, whose .hdr files are removed. The assumption is that > each header is downloaded once. 16MiB is a guestimate, that I > believe to be inflated. It doesn't take into account the > duplicate downloads of header.info for updates, under the > assumption that a web proxy would avoid downloading again what > rhn-applet has already downloaded. > > ---- > > 40MiB) just in metadata over a period of 9 months, total > > 2) yum 2.1 > > 2.7MiB) initial download, distro's and empty updates' > primary.xml.gz and filelists.xml.gz > > 68MiB) daily (on average) downloads of primary.xml.gz, downloaded by > rhn-applet, considering an average size of 250KiB (FC2 updates's > is 240KiB, whereas FC3's is 257KiB, plus about 1KiB for > repomd.xml) > > 16MiB) .hdr files for updates, downloaded by the update installer > (same as in case 1) > > 192MiB) filelists.xml.gz for updates, downloaded twice a week on > average by the update installer, to solve filename dep. > > ---- > > 278.7MiB) just in metadata over a period of 9 months, total > > > Looks like a waste of at least 238.7 MiB per user per 9-month install. > Sure, it's not a lot, only 26.5MiB a month, but it's almost 6 times as > much data being transferred for the very same purpose. How is that a > win? Multiply that by the number of users pounding on your mirrors > and it adds up to hundreds of GiB a month. > Another factor is that you probably won't need filelists.xml.gz for > every update. Maybe I don't quite understand how often it is needed, > but even if I have to download it only once a month, that's still > 64MiB over 9 months, more than the 40MiB total metadata downloaded > over 9 months by yum 2.0. yum 2.1.x ONLY DOWNLOADS THE XML FILES WHEN IT NEEDS THEM. go read the code and stop guessing. it downloads repomd.xml everytime - that's < 1K. it downloads primary.xml.gz if the file has changed - that's typically < 1M. it downloads filelists.xml.gz only when there is a file dep that it cannot resolve with primary.xml.gz. > I don't know how yum 2.0 did it, but up2date surely won't even try to > download a .hdr file if it already has it in /var/spool/up2date, so > this is not an issue. yum 2.0.x certainly DID NOT download a .hdr file it already had. Sheesh, go read the code, stop making suppositions based on anecdotes. > repodata helps the initial download, granted, but it loses terribly in > the long run. only as the number of file deps outside of /etc/* and *bin/* increases. if you keep the file deps in those paths then repodata is a huge win. -sv From skvidal at phy.duke.edu Sun Jan 30 22:03:59 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 30 Jan 2005 17:03:59 -0500 Subject: repository creation Message-ID: <1107122639.1614.130.camel@cutter> After all this absolutely enjoyable discussion of repodata format I figured I'd mention something that would help users tremendously to reducing the amount of data they might have to download. right now when a repository is created for use it's just made on ALL packages in the install tree. so you end up with srpms and debuginfo rpms in there. So you get 2623 pkgs to read through for fc3 base but if you just read through binary rpms you only have 1653 pkgs to read through. A pretty serious savings, almost 1000 packages. Now, yum prunes out the packages it can't use right away, but it is still having to read through all that data. so why not make the repo like this: createrepo -x *.src.rpm -x *.debuginfo* -g Fedora/base/comps.xml . and then make another srpm repository in the SRPMS dir all on its own. Ditto with debuginfo. but then we should add disabled-by-default srpm and debuginfo repos to each .repo file in yum.repos.d fedora.repo: [base] .... enabled=1 [base-srpm] ... enabled=0 [base-debug] .... enabled=0 then the user, if they need the debuginfo rpms, for example, can run: yum --enablerepo=base-debug install foo-debuginfo We should do the same for extras and updates, updates-testing repos, and rawhide too. I think, on the whole, we'd see a huge increase in speed for going through repos b/c we simply would have less data for 95% of the users to go through. -sv From kyrre at solution-forge.net Sun Jan 30 22:24:16 2005 From: kyrre at solution-forge.net (Kyrre Ness Sjobak) Date: Sun, 30 Jan 2005 23:24:16 +0100 Subject: rawhide firefox and background colour of webpages (CSS broken?) In-Reply-To: <1107119468.5724.0.camel@localhost.localdomain> References: <1107118615.3866.9.camel@localhost.localdomain> <1107119468.5724.0.camel@localhost.localdomain> Message-ID: <1107123856.3866.11.camel@localhost.localdomain> s?n, 30.01.2005 kl. 22.11 skrev Peter Backlund: > s?n 2005-01-30 klockan 21:56 +0100 skrev Kyrre Ness Sjobak: > > I have installed rawhide firefox on my fc3 computer, and it is pretty > > nice - exept two thing. > > > > Background color on several webpages (phpBB forums f.ex.) are now > > grayish. Not white (?) as they should be, judging from the white > > "border" around buttons. > > I've seen this too, downgraded to fc3 firefox. > > /Peter > > I have way to little time on my hands atm, would you care to do the bugzilla report? From carlos.efr at mail.telepac.pt Sun Jan 30 21:46:09 2005 From: carlos.efr at mail.telepac.pt (Carlos Rodrigues) Date: Sun, 30 Jan 2005 21:46:09 +0000 Subject: rawhide firefox and background colour of webpages (CSS broken?) In-Reply-To: <1107118615.3866.9.camel@localhost.localdomain> References: <1107118615.3866.9.camel@localhost.localdomain> Message-ID: <41FD55A1.5000601@mail.telepac.pt> Kyrre Ness Sjobak wrote: > I have installed rawhide firefox on my fc3 computer, and it is pretty > nice - exept two thing. > > Background color on several webpages (phpBB forums f.ex.) are now > grayish. Not white (?) as they should be, judging from the white > "border" around buttons. > > Also, it has no norwegian language support. > > This is version 1.0.8 > Edit -> Preferences -> General -> Fonts & Colors -> Turn off "Use system colors" This is a new default in the development packages of firefox, a bad one IMHO. Carlos Rodrigues -- url: http://tudo-sobre-nada.blogspot.com From cra at WPI.EDU Sun Jan 30 22:52:14 2005 From: cra at WPI.EDU (Charles R. Anderson) Date: Sun, 30 Jan 2005 17:52:14 -0500 Subject: repository creation In-Reply-To: <1107122639.1614.130.camel@cutter> References: <1107122639.1614.130.camel@cutter> Message-ID: <20050130225214.GA22101@angus.ind.WPI.EDU> On Sun, Jan 30, 2005 at 05:03:59PM -0500, seth vidal wrote: > so why not make the repo like this: > createrepo -x *.src.rpm -x *.debuginfo* -g Fedora/base/comps.xml . > > and then make another srpm repository in the SRPMS dir all on its own. > Ditto with debuginfo. > > but then we should add disabled-by-default srpm and debuginfo repos to > each .repo file in yum.repos.d +1 From aoliva at redhat.com Sun Jan 30 23:04:57 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 30 Jan 2005 21:04:57 -0200 Subject: Better repodata performance In-Reply-To: <1107119692.1614.116.camel@cutter> References: <41FD2D97.4010809@nc.rr.com> <1107119692.1614.116.camel@cutter> Message-ID: On Jan 30, 2005, seth vidal wrote: >> Definitely. But couldn't we perhaps do it by intelligently filtering >> information out of the rpm header and, say, generating a single >> archive containing all of the info needed for depsolving and for >> rpmlib's transaction verification? > you can't do that b/c file conflicts CAN NOT be calculated via rpm w/o > having the full header and/or all the file information present. You surely don't need the package description and the changelog for any of that, this was my point. >> I was expecting depsolving wouldn't require all the headers. And from >> what I gather from your reply, it indeed doesn't. > it requires all the headers of the packages involved, yes. For solving dependencies (as opposed to testing the transaction)?!? > yum 2.1.x ONLY DOWNLOADS THE XML FILES WHEN IT NEEDS THEM. > go read the code and stop guessing. Go read my e-mail. This is all covered. I'm not guessing. > it downloads repomd.xml everytime - that's < 1K. Check. > it downloads primary.xml.gz if the file has changed - that's typically < > 1M. Check. > it downloads filelists.xml.gz only when there is a file dep that it > cannot resolve with primary.xml.gz. Check. All covered in my e-mail. *You* stop guessing. >> I don't know how yum 2.0 did it, but up2date surely won't even try to >> download a .hdr file if it already has it in /var/spool/up2date, so >> this is not an issue. > yum 2.0.x certainly DID NOT download a .hdr file it already had. Sheesh, > go read the code, stop making suppositions based on anecdotes. I'm not making suppositions. Granted, I didn't read the code, only observed behavior. My analysis is still valid. >> repodata helps the initial download, granted, but it loses terribly in >> the long run. > only as the number of file deps outside of /etc/* and *bin/* increases. So you're saying the factor I put in to account for that too small? How much should it be to match reality? Is repodata still a win? > if you keep the file deps in those paths then repodata is a huge win. I find that very hard to believe, since the downloads of primary.xml.gz alone are enough to get above what yum 2.0 would download. Go read my text! You know, text is supposed to be easier to read than code, that's why we write comments. So instead of fighting I haven't read your code, how about you pay just a little bit of attention that actually matches *exactly* what's in both versions of your code? If you find some passage particularly difficult to understand, I may try to explain it in other words (I'm not a native English speaker, you know), but refraining from reading it just because you *think* it doesn't match what your code does (even though it does match it) is making a fool of yourself. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From skvidal at phy.duke.edu Sun Jan 30 23:15:11 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 30 Jan 2005 18:15:11 -0500 Subject: Better repodata performance In-Reply-To: References: <41FD2D97.4010809@nc.rr.com> <1107119692.1614.116.camel@cutter> Message-ID: <1107126912.1614.137.camel@cutter> > You know, text is supposed to be easier to read than code, that's why > we write comments. So instead of fighting I haven't read your code, > how about you pay just a little bit of attention that actually matches > *exactly* what's in both versions of your code? If you find some > passage particularly difficult to understand, I may try to explain it > in other words (I'm not a native English speaker, you know), but > refraining from reading it just because you *think* it doesn't match > what your code does (even though it does match it) is making a fool of > yourself. Since we've reduced this to name calling I think I'll step away from the conversation. -sv From n3npq at nc.rr.com Mon Jan 31 00:01:05 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Sun, 30 Jan 2005 19:01:05 -0500 Subject: repository creation In-Reply-To: <1107122639.1614.130.camel@cutter> References: <1107122639.1614.130.camel@cutter> Message-ID: <41FD7541.8090909@nc.rr.com> seth vidal wrote: >After all this absolutely enjoyable discussion of repodata format I >figured I'd mention something that would help users tremendously to >reducing the amount of data they might have to download. > > Releasing packages to repo's every other day, or even weekly, would reduce the amount of data as well, as rpm-metadata size is only a small part of the problem, too many package rebuilds with teensy changes is the real problem imho. But yes, splitting packages by usage category, like -debuginfo, and srpm, would only help. Another split might be attempted by "popularity" as objectively measured by number of downloads. "Popular" or "important" packages might be released more often, while other packages less often, another way to reduce the amount of information that flows from repos. Another optimization would be to maintain rpmdb-fedora incrementally on the client, as that's yet a 3rd time that headers are downloaded, and maintaining the yum headers and rpmdb-fedora incremenatlly n parallel on the client. That isn't a hard implementation to do. Not carefully "number of downloads" lest fedora-devel traffic start to rival the bandwidth used to download rpm-metadata discussing the relative importance of packages again again. 73 de Jeff From gauret at free.fr Mon Jan 31 00:06:48 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 31 Jan 2005 01:06:48 +0100 Subject: RFC: Soname in rpm name References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <604aa79105012416337f3de0ce@mail.gmail.com> <20050125010251.GD5190@neu.nirvana> <1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com> <1106848153.22178.16.camel@Madison.badger.com> <604aa7910501271146533837ad@mail.gmail.com> <604aa79105012714437df84250@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > Again these solutions have focused on the user's perspective of how to > garbage collect unused libraries. That is not the crux of my concern. > I've been trying to talk about a mechanism by which the package > authors can expire a library.. thus notifying ALL users of that > particular package that the author is no longer going to be providing > any maintence for that library. I see your point. OK, this is a dirty hack, but could we have, say, the fedora-release package "Conflict" with expiring package libraries ? (Told you it was dirty...) My point is: could we use our existing packages and the Conflicts (or another one) mechanism to expire a library ? I really think that this problem is worth taking some time to solve it. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "Never trust a computer you can't throw out a window." -- Steve Wozniak From rdieter at math.unl.edu Mon Jan 31 00:13:29 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 30 Jan 2005 18:13:29 -0600 (CST) Subject: rawhide firefox and background colour of webpages (CSS broken?) In-Reply-To: <41FD55A1.5000601@mail.telepac.pt> References: <1107118615.3866.9.camel@localhost.localdomain> <41FD55A1.5000601@mail.telepac.pt> Message-ID: On Sun, 30 Jan 2005, Carlos Rodrigues wrote: > Edit -> Preferences -> General -> Fonts & Colors -> Turn off "Use system > colors" > > This is a new default in the development packages of firefox, a bad one IMHO. I humbly disagree. I would argue that all apps should, by default, try to follow/use system colors, including web browsers. -- Rex From seanlkml at sympatico.ca Mon Jan 31 01:23:00 2005 From: seanlkml at sympatico.ca (Sean) Date: Sun, 30 Jan 2005 20:23:00 -0500 (EST) Subject: RFC: Soname in rpm name In-Reply-To: References: <1106570484.32065.1.camel@ulysse.olympe.o2t><604aa79105012416337f3de0ce@mail.gmail.com><20050125010251.GD5190@neu.nirvana><1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com> <1106848153.22178.16.camel@Madison.badger.com><604aa7910501271146533837ad@mail.gmail.com><604aa79105012714437df84250@mail.gmail.com> Message-ID: <46793.10.10.10.28.1107134580.squirrel@linux1> On Sun, January 30, 2005 7:06 pm, Aurelien Bompard said: > I see your point. > OK, this is a dirty hack, but could we have, say, the fedora-release > package > "Conflict" with expiring package libraries ? (Told you it was dirty...) > My point is: could we use our existing packages and the Conflicts (or > another one) mechanism to expire a library ? > > I really think that this problem is worth taking some time to solve it. What exactly is the problem? Users uninstall old applications they no longer use or upgrade to new versions that use new libraries. When nothing references an old library any more it can be garbage collected. Sean From aoliva at redhat.com Mon Jan 31 01:26:54 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 30 Jan 2005 23:26:54 -0200 Subject: Better repodata performance In-Reply-To: <1107126912.1614.137.camel@cutter> References: <41FD2D97.4010809@nc.rr.com> <1107119692.1614.116.camel@cutter> <1107126912.1614.137.camel@cutter> Message-ID: On Jan 30, 2005, seth vidal wrote: > Since we've reduced this to name calling I think I'll step away from the > conversation. Please don't do that before going through the numbers and analysis I posted and telling us what you think is wrong in them. I certainly don't intend this to turn into name calling. You were the one who wrote: ``Just so we don't go off into deeply uninformed space:?? and ``Sheesh, go read the code, stop making suppositions based on anecdotes.??, and then: > it downloads repomd.xml everytime - that's < 1K. > it downloads primary.xml.gz if the file has changed - that's typically < > 1M. > it downloads filelists.xml.gz only when there is a file dep that it > cannot resolve with primary.xml.gz. Which is precisely the model I had in mind when I posted my e-mail. So maybe I had read the code, or didn't have to. But instead of showing whatever you found to be in error in the hard data I posted, you chose to attack points in which either I wasn't sure on how exactly up2date, yum-2.0 and yum-2.1 chose to address a certain issue (and whose exact difference didn't matter at all for purposes of the comparison), or in which I probably wasn't sufficiently clear to expose what I had in mind, because you understood something completely different or missed the analysis relevant to understand that passage that was elsewhere. So let's please go back to the numbers and stop name calling. I apologize if I gave the impression that I wanted to get into this sort of discussion. I don't, and the only way to justify my actions is because I felt attacked when you implied I had no clue on what I was talking about. I'll be the first to admit I don't have complete knowledge, and I'm always eager to learn, but I don't see anything wrong with the analysis I posted, and your posting didn't show absolutely anything wrong with it, which to me shows I wasn't that clueless, after all. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From macfisherman at gmail.com Mon Jan 31 02:00:01 2005 From: macfisherman at gmail.com (Jeff Macdonald) Date: Sun, 30 Jan 2005 21:00:01 -0500 Subject: removing packages in fedora; nedit In-Reply-To: <200501221839.16172.czar@czarc.net> References: <1106338018.4351.17.camel@marte.biciclete.ro> <200501221839.16172.czar@czarc.net> Message-ID: <45ae903705013018005a1ce868@mail.gmail.com> On Sat, 22 Jan 2005 18:39:16 -0500, Gene C. wrote: > Some of us like nedit and would be very disappointed to see it removed. I can > certainly see that nc could be removed/renamed since it conflicts with > netcat's nc but nedit itself ... no, that would be undesirable. > -- Ditto -- Jeff Macdonald Ayer, MA From rodd at clarkson.id.au Mon Jan 31 03:06:43 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 31 Jan 2005 14:06:43 +1100 Subject: repository creation In-Reply-To: <41FD7541.8090909@nc.rr.com> References: <1107122639.1614.130.camel@cutter> <41FD7541.8090909@nc.rr.com> Message-ID: <1107140803.5161.38.camel@trevally.redfishdemo.com> On Sun, 2005-01-30 at 19:01 -0500, Jeff Johnson wrote: > But yes, splitting packages by usage category, like -debuginfo, and > srpm, would > only help. Another split might be attempted by "popularity" as objectively > measured by number of downloads. "Popular" or "important" packages might be > released more often, while other packages less often, another way to reduce > the amount of information that flows from repos. Or maybe splitting repos into different areas of Core. So you could have a CORE repo, and KDE repo, a GNOME repo, a OOo repo, a Java repo, etc so you only have to look through the repos that concern your install base. eh-GADS! That almost sounds like the whole CORE - Extras idea that's being floated ;-] Rodd -- >From the pain come the dream >From the dream come the vision >From the vision come the people >From the people come the power >From this power come the change - Peter Gabriel From aoliva at redhat.com Mon Jan 31 03:08:23 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 31 Jan 2005 01:08:23 -0200 Subject: Better repodata performance In-Reply-To: <41FD2D97.4010809@nc.rr.com> References: <41FD2D97.4010809@nc.rr.com> Message-ID: [added rpm-metadata list] On Jan 30, 2005, Jeff Johnson wrote: > Look, repos currently change daily, perhaps twice daily. Trying to > optimize incremenatl updates for something that changes perhaps > twice a day is fluff. Generating an xdelta from the previous versions of the .xml.gz files to the current versions, along with the relative location of the alternate repomd.xml that described them, modified to indicate they're deltas between the two given timestamps doesn't sound like such a difficult or wasteful thing to do. We'd grow repomd.xml by a few bytes: ... where $P stands for a prefix used to denote the previous generation of the repository. It could be a number, a timestamp, whatever, it doesn't matter. $P-repodata.xml could contain data such as: ... ... ... ... ... ... ... ... ... ... The timestamps would be the same as those in the original repomd.xml file, and the checksums would be such that one could verify that (i) the delta file was downloaded correctly, and that (ii) the expanded original .xml.gz file that they give xdelta to have the delta applied to obtain the newer version of the .xml file matches what the delta expects (although IIRC xdelta already performs this check itself). In this file, $PP would be the prefix for whatever previous version was available in the previous version of the repository, forming a linked list. So anyone can walk the list until they find a delta whose timestamp matches that of the version they have, and then start downloading the xdeltas and applying them until they reach the current version. This extension would be fully backward-compatible, since you're free to not follow the delta-chain if you like. And, if you do, it might turn out that you don't find a timestamp that matches the files you have, which would be unfortunate, but then, you'll only have downloaded a bunch of small .xml files, no big deal. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From skvidal at phy.duke.edu Mon Jan 31 03:12:55 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sun, 30 Jan 2005 22:12:55 -0500 Subject: repository creation In-Reply-To: <1107140803.5161.38.camel@trevally.redfishdemo.com> References: <1107122639.1614.130.camel@cutter> <41FD7541.8090909@nc.rr.com> <1107140803.5161.38.camel@trevally.redfishdemo.com> Message-ID: <1107141175.1614.145.camel@cutter> On Mon, 2005-01-31 at 14:06 +1100, Rodd Clarkson wrote: > On Sun, 2005-01-30 at 19:01 -0500, Jeff Johnson wrote: > > > But yes, splitting packages by usage category, like -debuginfo, and > > srpm, would > > only help. Another split might be attempted by "popularity" as objectively > > measured by number of downloads. "Popular" or "important" packages might be > > released more often, while other packages less often, another way to reduce > > the amount of information that flows from repos. > > Or maybe splitting repos into different areas of Core. So you could > have a CORE repo, and KDE repo, a GNOME repo, a OOo repo, a Java repo, > etc so you only have to look through the repos that concern your install > base. > > eh-GADS! That almost sounds like the whole CORE - Extras idea that's > being floated ;-] The problem there would be making sure the repositories had local dep closure. It's not difficult to do but from an organizational standpoint it'd be a pain in the arse. -sv From symbiont at berlios.de Mon Jan 31 03:33:20 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 31 Jan 2005 11:33:20 +0800 Subject: repository creation In-Reply-To: <1107141175.1614.145.camel@cutter> References: <1107122639.1614.130.camel@cutter> <1107140803.5161.38.camel@trevally.redfishdemo.com> <1107141175.1614.145.camel@cutter> Message-ID: <200501311133.21313.symbiont@berlios.de> On Monday 31 January 2005 11:12, seth vidal wrote: > The problem there would be making sure the repositories had local dep > closure. Downloading available repomd from source repos and crunching on a --justdb maybe using the async hdr stuff jbj was talking about. Something else missing? Yeah, it's another QA step. But, it can be automated in a chroot'd rpmdb, etc. -- -jeff From mricon at gmail.com Mon Jan 31 03:38:34 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Sun, 30 Jan 2005 22:38:34 -0500 Subject: Better repodata performance In-Reply-To: References: <41FD2D97.4010809@nc.rr.com> Message-ID: On 30 Jan 2005 18:16:21 -0200, Alexandre Oliva wrote: > 278.7MiB) just in metadata over a period of 9 months, total That's about 1 megabyte per day. I'm hard pressed to say that it makes much difference in overall end-user traffic, especially seeing as you are probably an exception: it's much less than that for a "generic user" who has base, updates-released, and maybe freshrpms or fedora.us+livna configured. Hell, I get about that much SPAM every day -- ~200 5k messages, that works up to about 1MiB. Now, I had to download and install 180MiB of OpenOffice updates yesterday. THAT sucked. The amount of YUM truffic compared to that is simply inconsequential. Network bandwidth is getting cheaper by the day. I'm not sure it's worth developing ulcers and hernias over each kilobyte. Essentially, it's the same argument as whether it's better to write code in C or in assembler -- at some point the benefit of having an abstracted environment that's easy to maintain wins over the "but it's so much larger in size!". Regards, -- Konstantin Ryabitsev Zlotniks, INC From aoliva at redhat.com Mon Jan 31 04:13:12 2005 From: aoliva at redhat.com (Alexandre Oliva) Date: 31 Jan 2005 02:13:12 -0200 Subject: Better repodata performance In-Reply-To: References: <41FD2D97.4010809@nc.rr.com> Message-ID: On Jan 31, 2005, Konstantin Ryabitsev wrote: > On 30 Jan 2005 18:16:21 -0200, Alexandre Oliva wrote: >> 278.7MiB) just in metadata over a period of 9 months, total > That's about 1 megabyte per day. Yeah. Multiply that by a few thousand users, if you happen to run one of the mirrors... > I'm hard pressed to say that it makes > much difference in overall end-user traffic, especially seeing as you > are probably an exception: it's much less than that for a "generic > user" who has base, updates-released, and maybe freshrpms or > fedora.us+livna configured. How can it be less if you're downloading stuff from more repos? > Hell, I get about that much SPAM every day -- ~200 5k messages, that > works up to about 1MiB. I'm sure I get more than that. But that's not the point. The point is the new repodata format was proposed to improve on what yum had, but I'm convinced it's a step backwards as it stands. It does offer one immediate advantage to the user, namely, the faster download of information needed for an initial dependency resolution, but, in the long run, you end up waiting longer for downloads, on total. > Now, I had to download and install 180MiB of OpenOffice updates > yesterday. THAT sucked. The amount of YUM truffic compared to that is > simply inconsequential. Yeah, it's a pain. It just doesn't *feel* that bad when you spread this wait over 9 months, but it *is* that bad. > Network bandwidth is getting cheaper by the day. Yeah, sure, so let's just waste it to make up? Doesn't sound very clever to me. > at some point the benefit of having an abstracted environment that's > easy to maintain wins over the "but it's so much larger in size!". What if it's smaller and easy to maintain? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From jspaleta at gmail.com Mon Jan 31 04:24:07 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 30 Jan 2005 23:24:07 -0500 Subject: repository creation In-Reply-To: <41FD7541.8090909@nc.rr.com> References: <1107122639.1614.130.camel@cutter> <41FD7541.8090909@nc.rr.com> Message-ID: <604aa79105013020242c96e4a9@mail.gmail.com> On Sun, 30 Jan 2005 19:01:05 -0500, Jeff Johnson wrote: > Another split might be attempted by "popularity" as objectively > measured by number of downloads. "Popular" or "important" packages might be > released more often, while other packages less often, another way to reduce > the amount of information that flows from repos. That's a pretty talk order.. and would require some particularly well communicated and agreed on classifications as to what "important" actually means across the spectrum of package maintainers. Sure we could all probably agree that a security update for a package was "important"... but i doubt you'd get agreement on the issue of whether or not a builddep fix was "important" if the builddep fix was needed so that a "popular" dependant package in Extras needed builds in the automated buildsystem. You make it sound like core package maintainers are shoving out packages on a whim. -jef From oliva at lsd.ic.unicamp.br Mon Jan 31 04:27:57 2005 From: oliva at lsd.ic.unicamp.br (Alexandre Oliva) Date: 31 Jan 2005 02:27:57 -0200 Subject: [Rpm-metadata] Re: Better repodata performance In-Reply-To: <200501311201.25752.symbiont@berlios.de> References: <41FD2D97.4010809@nc.rr.com> <200501311201.25752.symbiont@berlios.de> Message-ID: On Jan 31, 2005, Jeff Pitman wrote: > This could be driven by an optional parameter to createrepo, which > provides a list of packages to create a delta with. Err... Why? We already have repodata/, and we're creating the new version in .repodata. We can use repodata/ however we like, I think. > If it were fully automatic, it would only be a download win for the > user. And the servers. > I would rather not utilize xdelta, because you're still regenerating the > entire thing. Having xmlets that virtually add/substract as a delta > against primary.xml.gz would be optimal for both sides of the equation. But then Seth rejects the idea because it makes for unmaintainable code. And I sort of agree with him now that I see a simpler way to accomplish the same bandwidth savings. > Another advantage of the delta method, is that the on-disk pickled > objects (or whatever back-end store is used) could be updated > incrementally based on xml snippets coming in. Instead of regenerating > the whole thing over again. This is certainly a good point, but it is also trickier to get right. And it might also turn out to be bigger: if you have to list what went away, you're probably emitting more information than xdelta's `skip these many bytes'. It's like comparing diff with xdelta: diff is reversible because it contains what was removed and what as added (plus optional context), whereas xdelta only contains what was inserted and what portions of the original remained. Getting inserts small is trivial; getting removals small might be trickier, and to take advantage of pickling we need the latter. Unless... Does anyone feel like implementing an xml-aware xdelta-like program in Python? :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} From symbiont at berlios.de Mon Jan 31 04:01:25 2005 From: symbiont at berlios.de (Jeff Pitman) Date: Mon, 31 Jan 2005 12:01:25 +0800 Subject: [Rpm-metadata] Re: Better repodata performance In-Reply-To: References: <41FD2D97.4010809@nc.rr.com> Message-ID: <200501311201.25752.symbiont@berlios.de> On Monday 31 January 2005 11:08, Alexandre Oliva wrote: > Generating an xdelta from the previous versions of the .xml.gz files > to the current versions, along with the relative location of the > alternate repomd.xml that described them, modified to indicate > they're deltas between the two given timestamps doesn't sound like > such a difficult or wasteful thing to do. This could be driven by an optional parameter to createrepo, which provides a list of packages to create a delta with. If it were fully automatic, it would only be a download win for the user. If it were maintainer-driven, it would be a win for both user and repo. I would rather not utilize xdelta, because you're still regenerating the entire thing. Having xmlets that virtually add/substract as a delta against primary.xml.gz would be optimal for both sides of the equation. The xml formatting recommended is the way to go. Contents of delta are still up in the air. Another advantage of the delta method, is that the on-disk pickled objects (or whatever back-end store is used) could be updated incrementally based on xml snippets coming in. Instead of regenerating the whole thing over again. So, anyway, we can talk until our faces are blue. What we need is a candidate for this feature that can run against larger repositories. Rawhide and third parties could participate without major borkage with current yum. Anyway, I'll poke at it and see what materializes. -- -jeff From bclark at redhat.com Sun Jan 30 06:22:21 2005 From: bclark at redhat.com (Bryan Clark) Date: Sun, 30 Jan 2005 01:22:21 -0500 Subject: Our Discussion on Fedora-docs [Fwd: Re: Fedora Documentation Search Engine] In-Reply-To: <1107009143.4984.41.camel@erato.phig.org> References: <42853.193.195.148.66.1106926064.squirrel@webmail.suretecsystems.com> <1106998504.4770.11.camel@rhbw.boston.redhat.com> <1107009143.4984.41.camel@erato.phig.org> Message-ID: <1107066142.4770.34.camel@rhbw.boston.redhat.com> Hi ~ Just some more questions to clarify. On Sat, 2005-01-29 at 06:32 -0800, Karsten Wade wrote: > On Sat, 2005-01-29 at 06:35 -0500, Bryan Clark wrote: > > What type of person do you think is looking for this information (a > > developer, an office worker, a broker?). > > Any end-user on the system. So any user of our desktop or workstation product needs to be able to find this information in order to be able to use it? > > What is this person trying to accomplish by searching this information? > > Why do they need it? > > Currently, the best way to search for Fedora documentation is via > google.com. That in fact is how I search Red Hat docs, using > site:redhat.com. Just a thought, but would it be a good idea to integrate Red Hat docs on the web with Fedora. That would mean there is one less indexing program that possibly destroys my system (updatedb) and less packaging / development work. Although if this is an incremental updater it should use less resources. You could still allow for people to install the docs locally, but perhaps we could integrate an online search system for everyone that Red Hat indexes. > Right now, if you install locally all the documentation available, you > might have everything you'd be searching Google for but are unable to > find locally. Package docs go into /usr/share/doc and the man pages, > Red Hat docs packages also go into /usr/share/doc and may have an entry > in the 'Foot/'Hat menu. Fedora docs are small enough that an Everything > install _could_ include docs packages. That is a *tonne* of local, > online documentation. > > All of this is nearly impossible to search through without an index and > search tool. What specific information do you find when you search for this? Help on using an application? What application is that? > > Assuming they need it. How are they going to search for this > > information? Yelp? Web Browser? Something else? Are the mechanisms > > for searching and reviewing this type of information already built into > > those things? > > IMO, Yelp. We need to settle on a common help interface and (ab)use it. > > For example, a document on using kickstart to automate installation > might be at the forefront when Yelp is called from system-config- > kickstart. If an indexer can do this well, it seems better than hand > coding docs to be associated with certain apps and actions. Context sensitive help would be a great thing and I know the Yelp maintainer (Shaun M) is interested in doing that but short on time. > > If we had more of an overview of how this project is going to help > > people we could possibly look at a way of integrating it's functionality > > better into our system. Hopefully we then won't be just adding another > > piece to the stack of tools we have, but an answer to a problem people > > are having. > > I definitely think integrating indexed documentation into Yelp is a good > idea for corporate-type end-users. People _used_ to use the local help > system more extensively, until Internet search engines proved more > useful. The downside of relying upon the Internet is, what do you do > when the doc you need is the one that will get your networking going > again? Better hope you have a second machine that has connectivity, or > that you know how to dig through /usr/share/doc by hand. Ok. This sounds really interesting, I think I'm getting a bigger picture of what's happening. Maybe with a little more clarification I can see what we're aiming at. Thanks, ~ Bryan From byte at aeon.com.my Sun Jan 30 18:51:08 2005 From: byte at aeon.com.my (Colin Charles) Date: Mon, 31 Jan 2005 00:21:08 +0530 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050130152856.408462dd@nausicaa.camperquake.de> References: <1106333362.3427.19.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DA4D.7040801@tlarson.com> <1106966975.5678.18.camel@localhost.localdomain> <20050130152856.408462dd@nausicaa.camperquake.de> Message-ID: <1107111068.7956.27.camel@localhost.localdomain> On Sun, 2005-01-30 at 15:28 +0100, Ralf Ertzinger wrote: > I played with rpm a little today to see what prevents gtk1 being > removed. After > "rpm -e --test"'ing a whole lot of gtk1 and gnome1 gruft it basically > comes down > to a handful of applications that are currently in FC (and a quite > impressive > list of applications from external repos, but that's another story): > > xmms > system-config-proc s-c-proc isn't around in FC3 from what I can tell > mtr-gtk > and, most important, gnucash. Seeing as I was Net-less for a while, the gtk+-1.2.10 package is what I took a look at... bonobo-1.0.22-9.i386 cdicconf-0.2-9.i386 GConf-1.0.9-15.i386 gdk-pixbuf-0.22.0-15.0.i386 gdk-pixbuf-gnome-0.22.0-15.0.i386 gnome-libs-1.4.1.2.90-44.i386 gnome-print-0.37-10.i386 gnome-vfs-1.0.5-21.i386 gnucash-1.8.9-2.i386 gtk+-1.2.10-33.i386 gtk+-devel-1.2.10-33.i386 gtk-engines-0.12-5.i386 gtkhtml-1.1.9-10.i386 Guppi-0.40.3-21.i386 imlib-1.9.13-21.i386 libdv-tools-0.103-1.i386 libgal23-0.24-4.i386 libglade-0.17-15.i386 libgnomeprint15-0.37-10.i386 mtr-gtk-0.54-10.i386 nmap-frontend-3.70-1.i386 sylpheed-0.9.12-1.i386 usbview-1.0-13.i386 w3m-img-0.5.1-4.FC3.1.i386 xmms-1.2.10-9.i386 xmms-flac-1.1.0-7.i386 Those are the depends in Core 3. I have mplayer that depends on it too, from livna -- Colin Charles, byte at aeon.com.my http://www.bytebot.net/ "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mohandas Gandhi From n3npq at nc.rr.com Mon Jan 31 05:34:07 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 31 Jan 2005 00:34:07 -0500 Subject: repository creation In-Reply-To: <604aa79105013020242c96e4a9@mail.gmail.com> References: <1107122639.1614.130.camel@cutter> <41FD7541.8090909@nc.rr.com> <604aa79105013020242c96e4a9@mail.gmail.com> Message-ID: <41FDC34F.7030806@nc.rr.com> Jeff Spaleta wrote: >On Sun, 30 Jan 2005 19:01:05 -0500, Jeff Johnson wrote: > > >>Another split might be attempted by "popularity" as objectively >>measured by number of downloads. "Popular" or "important" packages might be >>released more often, while other packages less often, another way to reduce >>the amount of information that flows from repos. >> >> > >That's a pretty talk order.. and would require some particularly well >communicated and agreed on classifications as to what "important" >actually means across the spectrum of package maintainers. Sure we >could all probably agree that a security update for a package was >"important"... but i doubt you'd get agreement on the issue of whether >or not a builddep fix was "important" if the builddep fix was needed >so that a "popular" dependant package in Extras needed builds in the >automated buildsystem. > > Read what I said. The suggested criteria are there. >You make it sound like core package maintainers are shoving out >packages on a whim. > > No I don't, you are bottom trolling. "Whim" shoving indeed. 73 de Jeff From skvidal at phy.duke.edu Mon Jan 31 06:08:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 31 Jan 2005 01:08:41 -0500 Subject: repository creation In-Reply-To: <200501311133.21313.symbiont@berlios.de> References: <1107122639.1614.130.camel@cutter> <1107140803.5161.38.camel@trevally.redfishdemo.com> <1107141175.1614.145.camel@cutter> <200501311133.21313.symbiont@berlios.de> Message-ID: <1107151721.1614.154.camel@cutter> On Mon, 2005-01-31 at 11:33 +0800, Jeff Pitman wrote: > On Monday 31 January 2005 11:12, seth vidal wrote: > > The problem there would be making sure the repositories had local dep > > closure. > > Downloading available repomd from source repos and crunching on a > --justdb maybe using the async hdr stuff jbj was talking about. > Something else missing? Like I said - not technically hard - but taking the steps on the repo- side to make sure the packages ended up in the right places after they were built would be the only tricky part. And making sure you didn't end up with 20 pkgs in every single repository. you'd also have to make sure you have dep closure when multiple repos are used. and then, of course, keep them all in sync. It's just an organization hurdle. and of course anaconda would need A LOT of modification. -sv From laroche at redhat.com Mon Jan 31 07:37:03 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 31 Jan 2005 08:37:03 +0100 Subject: repository creation In-Reply-To: <20050130225214.GA22101@angus.ind.WPI.EDU> References: <1107122639.1614.130.camel@cutter> <20050130225214.GA22101@angus.ind.WPI.EDU> Message-ID: <20050131073703.GA5243@dudweiler.stuttgart.redhat.com> On Sun, Jan 30, 2005 at 05:52:14PM -0500, Charles R. Anderson wrote: > On Sun, Jan 30, 2005 at 05:03:59PM -0500, seth vidal wrote: > > so why not make the repo like this: > > createrepo -x *.src.rpm -x *.debuginfo* -g Fedora/base/comps.xml . > > > > and then make another srpm repository in the SRPMS dir all on its own. > > Ditto with debuginfo. > > > > but then we should add disabled-by-default srpm and debuginfo repos to > > each .repo file in yum.repos.d > > +1 -1 I would prefer this to be an option for yum.conf with data being written to separate files instead of using a separate repo location. Would allow reading e.g. debuginfo items if such an rpm is actually installed. greetings, Florian La Roche From skvidal at phy.duke.edu Mon Jan 31 07:10:14 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 31 Jan 2005 02:10:14 -0500 Subject: repository creation In-Reply-To: <20050131073703.GA5243@dudweiler.stuttgart.redhat.com> References: <1107122639.1614.130.camel@cutter> <20050130225214.GA22101@angus.ind.WPI.EDU> <20050131073703.GA5243@dudweiler.stuttgart.redhat.com> Message-ID: <1107155414.1614.158.camel@cutter> On Mon, 2005-01-31 at 08:37 +0100, Florian La Roche wrote: > On Sun, Jan 30, 2005 at 05:52:14PM -0500, Charles R. Anderson wrote: > > On Sun, Jan 30, 2005 at 05:03:59PM -0500, seth vidal wrote: > > > so why not make the repo like this: > > > createrepo -x *.src.rpm -x *.debuginfo* -g Fedora/base/comps.xml . > > > > > > and then make another srpm repository in the SRPMS dir all on its own. > > > Ditto with debuginfo. > > > > > > but then we should add disabled-by-default srpm and debuginfo repos to > > > each .repo file in yum.repos.d > > > > +1 > > -1 > > I would prefer this to be an option for yum.conf with data being written > to separate files instead of using a separate repo location. Would allow > reading e.g. debuginfo items if such an rpm is actually installed. > But the only way you're going to know if the debuginfo items are there is by reading through all of the debuginfo metadata. so it's a net loss for users who for I'd be willing to wager >95% of the time do not EVER use debuginfo rpms. and for the 5% of the time they need them they can simply do: yum --enablerepo=base-debug install foo-debuginfo you're cutting off a lot of packages. Also - are you -1'ing the whole idea or just the idea as regards debuginfo packages? We can save a lot of data by pruning out src.rpms. -sv From laroche at redhat.com Mon Jan 31 07:57:07 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 31 Jan 2005 08:57:07 +0100 Subject: repository creation In-Reply-To: <1107155414.1614.158.camel@cutter> References: <1107122639.1614.130.camel@cutter> <20050130225214.GA22101@angus.ind.WPI.EDU> <20050131073703.GA5243@dudweiler.stuttgart.redhat.com> <1107155414.1614.158.camel@cutter> Message-ID: <20050131075707.GA6187@dudweiler.stuttgart.redhat.com> > But the only way you're going to know if the debuginfo items are there > is by reading through all of the debuginfo metadata. > > so it's a net loss for users who for I'd be willing to wager >95% of the > time do not EVER use debuginfo rpms. > > and for the 5% of the time they need them they can simply do: > yum --enablerepo=base-debug install foo-debuginfo > > you're cutting off a lot of packages. > > Also - are you -1'ing the whole idea or just the idea as regards > debuginfo packages? We can save a lot of data by pruning out src.rpms. I think it is correct to move src.rpms and debuginfo out of the default path. Instead of moving this to the user to enable/disable it, I thought to use differently named files within the repodata. All information about src.rpms goes to new filenames and you can trigger reading in the debuginfo files if a "*-debuginfo" package name is needed. This puts the namespace question to the repodata and is adding special interpretation to rpm package names ("*-debuginfo"), but tries to get all this more transparent to the user compared to offering this via configured repo locations. ?? Both ways have their pros and cons. greetings, Florian La Roche From skvidal at phy.duke.edu Mon Jan 31 07:32:04 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 31 Jan 2005 02:32:04 -0500 Subject: repository creation In-Reply-To: <20050131075707.GA6187@dudweiler.stuttgart.redhat.com> References: <1107122639.1614.130.camel@cutter> <20050130225214.GA22101@angus.ind.WPI.EDU> <20050131073703.GA5243@dudweiler.stuttgart.redhat.com> <1107155414.1614.158.camel@cutter> <20050131075707.GA6187@dudweiler.stuttgart.redhat.com> Message-ID: <1107156724.1614.161.camel@cutter> > I think it is correct to move src.rpms and debuginfo out of the default > path. Instead of moving this to the user to enable/disable it, I thought > to use differently named files within the repodata. > All information about src.rpms goes to new filenames and you can trigger > reading in the debuginfo files if a "*-debuginfo" package name is needed. > > This puts the namespace question to the repodata and is adding special > interpretation to rpm package names ("*-debuginfo"), but tries to get > all this more transparent to the user compared to offering this via > configured repo locations. > > ?? Both ways have their pros and cons. The con of doing it the way you're describing is that it implicitly dictates something about the repository structure. Not sure I like that. But i see your point about having them magically enabled. The only problem is that for depsolving it doesn't make it much easier. -sv From mpeters at mac.com Mon Jan 31 07:36:53 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 31 Jan 2005 07:36:53 +0000 Subject: repository creation In-Reply-To: <1107155414.1614.158.camel@cutter> (from skvidal@phy.duke.edu on Sun Jan 30 23:10:14 2005) References: <1107122639.1614.130.camel@cutter> <20050130225214.GA22101@angus.ind.WPI.EDU> <20050131073703.GA5243@dudweiler.stuttgart.redhat.com> <1107155414.1614.158.camel@cutter> Message-ID: <1107157013l.9340l.1l@devel.mpeters.us> On 01/30/2005 11:10:14 PM, seth vidal wrote: > > so it's a net loss for users who for I'd be willing to wager >95% of > the > time do not EVER use debuginfo rpms. > > and for the 5% of the time they need them they can simply do: > yum --enablerepo=base-debug install foo-debuginfo Wouldn't that result in a dependency issue on a yum update though? IE foobar debug package would require a specific version of foobar, so if they enabled base-debug just to get foobar-debug, then later an update to foobar is released, wouldn't the foobar-debug package prevent yum from updating foobar because of dependency - if base-debug was not enabled? From fedora at wir-sind-cool.org Mon Jan 31 07:49:38 2005 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 31 Jan 2005 08:49:38 +0100 Subject: repository creation In-Reply-To: <1107157013l.9340l.1l@devel.mpeters.us> References: <1107122639.1614.130.camel@cutter> <20050130225214.GA22101@angus.ind.WPI.EDU> <20050131073703.GA5243@dudweiler.stuttgart.redhat.com> <1107155414.1614.158.camel@cutter> <1107157013l.9340l.1l@devel.mpeters.us> Message-ID: <20050131084938.235660c2.fedora@wir-sind-cool.org> On Mon, 31 Jan 2005 07:36:53 +0000, Michael A. Peters wrote: > On 01/30/2005 11:10:14 PM, seth vidal wrote: > > > > > so it's a net loss for users who for I'd be willing to wager >95% of > > the > > time do not EVER use debuginfo rpms. > > > > and for the 5% of the time they need them they can simply do: > > yum --enablerepo=base-debug install foo-debuginfo > > Wouldn't that result in a dependency issue on a yum update though? > IE foobar debug package would require a specific version of foobar, so > if they enabled base-debug just to get foobar-debug, then later an > update to foobar is released, wouldn't the foobar-debug package prevent > yum from updating foobar because of dependency - if base-debug was not > enabled? Current debuginfo packages don't have such a dependency on a base package. -- Fedora Core release 3 (Heidelberg) - Linux 2.6.10-1.741_FC3 loadavg: 0.08 0.10 0.09 From laroche at redhat.com Mon Jan 31 08:27:48 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 31 Jan 2005 09:27:48 +0100 Subject: repository creation In-Reply-To: <1107156724.1614.161.camel@cutter> References: <1107122639.1614.130.camel@cutter> <20050130225214.GA22101@angus.ind.WPI.EDU> <20050131073703.GA5243@dudweiler.stuttgart.redhat.com> <1107155414.1614.158.camel@cutter> <20050131075707.GA6187@dudweiler.stuttgart.redhat.com> <1107156724.1614.161.camel@cutter> Message-ID: <20050131082748.GA7238@dudweiler.stuttgart.redhat.com> On Mon, Jan 31, 2005 at 02:32:04AM -0500, seth vidal wrote: > > I think it is correct to move src.rpms and debuginfo out of the default > > path. Instead of moving this to the user to enable/disable it, I thought > > to use differently named files within the repodata. > > All information about src.rpms goes to new filenames and you can trigger > > reading in the debuginfo files if a "*-debuginfo" package name is needed. > > > > This puts the namespace question to the repodata and is adding special > > interpretation to rpm package names ("*-debuginfo"), but tries to get > > all this more transparent to the user compared to offering this via > > configured repo locations. > > > > ?? Both ways have their pros and cons. > > The con of doing it the way you're describing is that it implicitly > dictates something about the repository structure. Not sure I like that. Hmmm, having a full repo, but then only enabling it for yum if actually *-debuginfo packages are installed would be the same as moving the data out to different files. So a "maybe use this repo" based on *-debuginfo is something to look at? > > But i see your point about having them magically enabled. The only > problem is that for depsolving it doesn't make it much easier. But that's what we try to achieve, right? It better should do so... greetings, Florian La Roche From webwurst at gmx.de Mon Jan 31 04:08:07 2005 From: webwurst at gmx.de (Tobias Bradtke) Date: Mon, 31 Jan 2005 05:08:07 +0100 Subject: mono in fedora-core-4? Message-ID: i read in a blog (http://pubcrawler.org/archives/000579.html) that mono will be in fedora-core-4! that would bi great news! :D can someone confirm this? Bill Nottingham (https://www.redhat.com/archives/fedora-devel-list/2005-January/msg00521.html) didn't mention it. Tobias Bradtke From gauret at free.fr Mon Jan 31 10:54:40 2005 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 31 Jan 2005 11:54:40 +0100 Subject: RFC: Soname in rpm name References: <1106570484.32065.1.camel@ulysse.olympe.o2t><604aa79105012416337f3de0ce@mail.gmail.com><20050125010251.GD5190@neu.nirvana><1106616420.23277.1.camel@cutter> <41F8F445.3080903@redhat.com> <1106848153.22178.16.camel@Madison.badger.com><604aa7910501271146533837ad@mail.gmail.com><604aa79105012714437df84250@mail.gmail.com> <46793.10.10.10.28.1107134580.squirrel@linux1> Message-ID: Sean wrote: > What exactly is the problem????Users?uninstall?old?applications?they?no > longer use or upgrade to new versions that use new libraries.???When > nothing references an old library any more it can be garbage collected. I think Jeff wants the garbage-collecting process to be initiated by the distribution, and not to depend on the user running a garbage collector by himself. Aur?lien -- http://gauret.free.fr ~~~~ Jabber : gauret at amessage.info "As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours ; and this we should do freely and generously." -- Benjamin Franklin From warren at togami.com Mon Jan 31 11:10:45 2005 From: warren at togami.com (Warren Togami) Date: Mon, 31 Jan 2005 01:10:45 -1000 Subject: Apt at fedora.us In-Reply-To: <1107078784.4018.216.camel@bobcat.mine.nu> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <20050128123043.3a60b213.fedora@wir-sind-cool.org> <1106915462.5389.15.camel@mccallum.corsepiu.local> <20050128134756.70f3a4fb.fedora@wir-sind-cool.org> <1107078784.4018.216.camel@bobcat.mine.nu> Message-ID: <41FE1235.2010101@togami.com> Ville Skytt? wrote: > On Fri, 2005-01-28 at 13:47 +0100, Michael Schwendt wrote: > >>On Fri, 28 Jan 2005 13:31:01 +0100, Ralf Corsepius wrote: >> >> >>>I had asked Warren Togami to add them on PM and he answered: >>>"There is little good reason to do so. Trying to limit the size of that >>>repository because many mirror administrators see it as redundant." >>> >>>This is not true, SRPMS apt-repositories are not redundant. Not having >>>them implies loss of functionality to apt. >> >>Well, then I think the Apt community may need to prove him wrong >>and do some lobbying. > > > FWIW, I would like to see the complete apt'table (pre-)Extras SRPMS > repos available at fedora.us and its mirrors. The reasons have been > outlined in this thread. I have to admit that I don't understand if there is any purpose in this. "apt-get source" is only a convenience but otherwise is not very useful. "apt-get build-dep" does not need SRPMS at all except the local SRPM, which you already have locally because you want to build it. Is there some aspect of this that I am failing to see? I fail to see the "need" in this. From the perspective of mirror administrators it is somewhat painful to host redundant RPMS. I personally don't have the disk space to do this forever with all distributions. I suppose it is tolerable to do only SRPMS.extras of the latest stable distribution. When FC4 happens, I will wipe the 3 SRPMS.extras. Is this acceptable? I will however not add the base and updates SRPMS. Warren Togami wtogami at redhat.com From rc040203 at freenet.de Mon Jan 31 11:16:01 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 31 Jan 2005 12:16:01 +0100 Subject: repository creation In-Reply-To: <20050131084938.235660c2.fedora@wir-sind-cool.org> References: <1107122639.1614.130.camel@cutter> <20050130225214.GA22101@angus.ind.WPI.EDU> <20050131073703.GA5243@dudweiler.stuttgart.redhat.com> <1107155414.1614.158.camel@cutter> <1107157013l.9340l.1l@devel.mpeters.us> <20050131084938.235660c2.fedora@wir-sind-cool.org> Message-ID: <1107170161.5389.143.camel@mccallum.corsepiu.local> On Mon, 2005-01-31 at 08:49 +0100, Michael Schwendt wrote: > On Mon, 31 Jan 2005 07:36:53 +0000, Michael A. Peters wrote: > > > On 01/30/2005 11:10:14 PM, seth vidal wrote: > > > > > > > > so it's a net loss for users who for I'd be willing to wager >95% of > > > the > > > time do not EVER use debuginfo rpms. > > > > > > and for the 5% of the time they need them they can simply do: > > > yum --enablerepo=base-debug install foo-debuginfo > > > > Wouldn't that result in a dependency issue on a yum update though? > > IE foobar debug package would require a specific version of foobar, so > > if they enabled base-debug just to get foobar-debug, then later an > > update to foobar is released, wouldn't the foobar-debug package prevent > > yum from updating foobar because of dependency - if base-debug was not > > enabled? > > Current debuginfo packages don't have such a dependency on a base package. Which I'd consider to be a bug. IMO, a debuginfo package must depend on those files (Note: files, not package!) a debuginfo package carries the debug info for. Ralf From fedora-devel at camperquake.de Mon Jan 31 11:15:51 2005 From: fedora-devel at camperquake.de (Ralf Ertzinger) Date: Mon, 31 Jan 2005 12:15:51 +0100 Subject: rawhide firefox and background colour of webpages (CSS broken?) In-Reply-To: <1107118615.3866.9.camel@localhost.localdomain> References: <1107118615.3866.9.camel@localhost.localdomain> Message-ID: <20050131121551.524bf76d@nausicaa.camperquake.de> Hi. Kyrre Ness Sjobak wrote: > Background color on several webpages (phpBB forums f.ex.) are now > grayish. Not white (?) as they should be, judging from the white > "border" around buttons. Those web pages are broken. They assume that the default background colour the browser chooses is white. This assumption does not hold. If they want a white background they have to say so. -- No time for love, Doctor Jones! From seanlkml at sympatico.ca Mon Jan 31 11:18:25 2005 From: seanlkml at sympatico.ca (Sean) Date: Mon, 31 Jan 2005 06:18:25 -0500 (EST) Subject: RFC: Soname in rpm name In-Reply-To: References: <1106570484.32065.1.camel@ulysse.olympe.o2t><604aa79105012416337f3de0ce@mail.gmail.com><20050125010251.GD5190@neu.nirvana><1106616420.23277.1.camel@cutter><41F8F445.3080903@redhat.com><1106848153.22178.16.camel@Madison.badger.com><604aa7910501271146533837ad@mail.gmail.com><604aa79105012714437df84250@mail.gmail.com><46793.10.10.10.28.1107134580.squirrel@linux1> Message-ID: <49465.10.10.10.28.1107170305.squirrel@linux1> On Mon, January 31, 2005 5:54 am, Aurelien Bompard said: > I think Jeff wants the garbage-collecting process to be initiated by the > distribution, and not to depend on the user running a garbage collector by > himself. Your idea would work as would a couple other options. It just seems like the wrong time to worry about such a minor corner case that won't really change the end-user experience. If jeff or someone else wants to worry about it now, there are ways they can proceed without needing to interject the demand that it be solved by anyone else working on other improvements to rpm. Cheers, Sean From laroche at redhat.com Mon Jan 31 12:02:59 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 31 Jan 2005 13:02:59 +0100 Subject: repository creation In-Reply-To: <1107170161.5389.143.camel@mccallum.corsepiu.local> References: <1107122639.1614.130.camel@cutter> <20050130225214.GA22101@angus.ind.WPI.EDU> <20050131073703.GA5243@dudweiler.stuttgart.redhat.com> <1107155414.1614.158.camel@cutter> <1107157013l.9340l.1l@devel.mpeters.us> <20050131084938.235660c2.fedora@wir-sind-cool.org> <1107170161.5389.143.camel@mccallum.corsepiu.local> Message-ID: <20050131120259.GA7225@dudweiler.stuttgart.redhat.com> > IMO, a debuginfo package must depend on those files (Note: files, not > package!) a debuginfo package carries the debug info for. The they should be in the base channel as well, otherwise keeping repos in sync will be a pain. Since debuginfo are very special and only needed very seldom, I think the current setup to delete the deps is fine. greetings, Florian La Roche From Nigel.Metheringham at dev.intechnology.co.uk Mon Jan 31 11:32:41 2005 From: Nigel.Metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Mon, 31 Jan 2005 11:32:41 +0000 Subject: rawhide firefox and background colour of webpages (CSS broken?) In-Reply-To: <20050131121551.524bf76d@nausicaa.camperquake.de> References: <1107118615.3866.9.camel@localhost.localdomain> <20050131121551.524bf76d@nausicaa.camperquake.de> Message-ID: <1107171161.5777.11.camel@angua.localnet> On Mon, 2005-01-31 at 12:15 +0100, Ralf Ertzinger wrote: > Kyrre Ness Sjobak wrote: > > Background color on several webpages (phpBB forums f.ex.) are now > > grayish. Not white (?) as they should be, judging from the white > > "border" around buttons. > > Those web pages are broken. They assume that the default background > colour the browser chooses is white. This assumption does not hold. > If they want a white background they have to say so. This is an interesting development, since early web browsers always used to render the default background as a grey colour - I remember seeing this in Mosaic, the NeXTstep browser (can't remember its name) and early Netscape. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From troels at arvin.dk Mon Jan 31 12:06:47 2005 From: troels at arvin.dk (Troels Arvin) Date: Mon, 31 Jan 2005 13:06:47 +0100 Subject: mono in fedora-core-4? References: Message-ID: On Mon, 31 Jan 2005 05:08:07 +0100, Tobias Bradtke wrote: > i read in a blog (http://pubcrawler.org/archives/000579.html) > that mono will be in fedora-core-4! The blog message says that mono is in Rawhide. Well, I can't find it there :-( I wouldn't hold my breath if I were you. -- Greetings from Troels Arvin, Copenhagen, Denmark From buildsys at redhat.com Mon Jan 31 13:02:03 2005 From: buildsys at redhat.com (Build System) Date: Mon, 31 Jan 2005 08:02:03 -0500 Subject: rawhide report: 20050131 changes Message-ID: <200501311302.j0VD23k13497@porkchop.devel.redhat.com> From ziga.mahkovec at klika.si Mon Jan 31 13:17:53 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Mon, 31 Jan 2005 14:17:53 +0100 Subject: mono in fedora-core-4? In-Reply-To: References: Message-ID: <1107177473.11297.14.camel@serenity.klika.si> On Mon, 2005-01-31 at 05:08 +0100, Tobias Bradtke wrote: > i read in a blog (http://pubcrawler.org/archives/000579.html) > that mono will be in fedora-core-4! That would certainly be cool. Last I heard [1], there were patent concerns. On a related note: I noticed the Novell guys now package Mono for FC3 [2]. Not sure why it's not listed on the download page though. [1] http://www.redhat.com/archives/fedora-list/2003-December/msg01979.html [2] http://www.go-mono.com/archive/1.0.5/fedora-3-i386/ -- Ziga From Nicolas.Mailhot at laPoste.net Mon Jan 31 13:21:49 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 31 Jan 2005 14:21:49 +0100 Subject: rawhide firefox and background colour of webpages (CSS broken?) In-Reply-To: <1107171161.5777.11.camel@angua.localnet> References: <1107118615.3866.9.camel@localhost.localdomain> <20050131121551.524bf76d@nausicaa.camperquake.de> <1107171161.5777.11.camel@angua.localnet> Message-ID: <1107177709.9022.17.camel@ulysse.olympe.o2t> Le lundi 31 janvier 2005 ? 11:32 +0000, Nigel Metheringham a ?crit : > On Mon, 2005-01-31 at 12:15 +0100, Ralf Ertzinger wrote: > > Kyrre Ness Sjobak wrote: > > > Background color on several webpages (phpBB forums f.ex.) are now > > > grayish. Not white (?) as they should be, judging from the white > > > "border" around buttons. > > > > Those web pages are broken. They assume that the default background > > colour the browser chooses is white. This assumption does not hold. > > If they want a white background they have to say so. > > This is an interesting development, since early web browsers always used > to render the default background as a grey colour - I remember seeing > this in Mosaic, the NeXTstep browser (can't remember its name) and early > Netscape. All my browsers have a light yellow/orangish default background - very light on the eyes and very good for spotting broken websites (ie not sites that let you use custom colors but sites that assume browser settings - for example when some frames specify white background and others forget about it). This should be mandatory in any web shop IMHO - but even big sites are often broken this way. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jspaleta at gmail.com Mon Jan 31 13:35:50 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 31 Jan 2005 08:35:50 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <49465.10.10.10.28.1107170305.squirrel@linux1> References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106848153.22178.16.camel@Madison.badger.com> <604aa7910501271146533837ad@mail.gmail.com> <604aa79105012714437df84250@mail.gmail.com> <46793.10.10.10.28.1107134580.squirrel@linux1> <49465.10.10.10.28.1107170305.squirrel@linux1> Message-ID: <604aa79105013105356b0e2654@mail.gmail.com> On Mon, 31 Jan 2005 06:18:25 -0500 (EST), Sean wrote: > Your idea would work as would a couple other options. It just seems > like the wrong time to worry about such a minor corner case that won't > really change the end-user experience. If jeff or someone else wants to > worry about it now, there are ways they can proceed without needing to > interject the demand that it be solved by anyone else working on other > improvements to rpm. Yuo keep missing my point. I think some packagers have been worrying about this all along and is one of the reason why soname in packagename hasnt been the norm for Red Hat ever. Whether or not you think its a corner case.. while a fascinating bit of information for me to know... doesn't change whether or not this issue i bring has been an important factor in the past for packagers who are not using the soname-in-packagename model. And if it has been an important factor in the past... i'd like to know what has changed. -jef From rdieter at math.unl.edu Mon Jan 31 13:48:37 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 31 Jan 2005 07:48:37 -0600 (CST) Subject: RFC: Soname in rpm name In-Reply-To: <604aa79105013105356b0e2654@mail.gmail.com> References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <1106848153.22178.16.camel@Madison.badger.com> <604aa7910501271146533837ad@mail.gmail.com> <604aa79105012714437df84250@mail.gmail.com> <46793.10.10.10.28.1107134580.squirrel@linux1> <49465.10.10.10.28.1107170305.squirrel@linux1> <604aa79105013105356b0e2654@mail.gmail.com> Message-ID: On Mon, 31 Jan 2005, Jeff Spaleta wrote: > I think some packagers have been worrying > about this all along and is one of the reason why soname in > packagename hasnt been the norm for Red Hat ever. One reasonable option is to only use the 'Soname in rpm name' scheme when/if the packager ever expects/needs multiple installed versions. If not, keep the status-quo. -- Rex From kyrre at solution-forge.net Mon Jan 31 13:50:44 2005 From: kyrre at solution-forge.net (kyrre at solution-forge.net) Date: Mon, 31 Jan 2005 14:50:44 +0100 (CET) Subject: rawhide firefox and background colour of webpages (CSS broken?) In-Reply-To: <1107177709.9022.17.camel@ulysse.olympe.o2t> References: <1107118615.3866.9.camel@localhost.localdomain> <20050131121551.524bf76d@nausicaa.camperquake.de> <1107171161.5777.11.camel@angua.localnet> <1107177709.9022.17.camel@ulysse.olympe.o2t> Message-ID: <32901.81.191.130.121.1107179444.squirrel@81.191.130.121> > Le lundi 31 janvier 2005 ? 11:32 +0000, Nigel Metheringham a ??crit : >> On Mon, 2005-01-31 at 12:15 +0100, Ralf Ertzinger wrote: >> > Kyrre Ness Sjobak wrote: >> > > Background color on several webpages (phpBB forums f.ex.) are now >> > > grayish. Not white (?) as they should be, judging from the white >> > > "border" around buttons. >> > >> > Those web pages are broken. They assume that the default background >> > colour the browser chooses is white. This assumption does not hold. >> > If they want a white background they have to say so. >> >> This is an interesting development, since early web browsers always used >> to render the default background as a grey colour - I remember seeing >> this in Mosaic, the NeXTstep browser (can't remember its name) and early >> Netscape. > > All my browsers have a light yellow/orangish default background - very > light on the eyes and very good for spotting broken websites (ie not > sites that let you use custom colors but sites that assume browser > settings - for example when some frames specify white background and > others forget about it). > > This should be mandatory in any web shop IMHO - but even big sites are > often broken this way. > > Regards, Yes. But it isn't mandatory. They are broken, but they only look broken in firefox at fc3 - so people believe that firefox is broken. And yes, i do also remember that Mosaic had a gray background. 10 years ago. So, please, please set the *default* settings so that most pages doesn't look broken. From rahulsundaram at gmail.com Mon Jan 31 13:56:16 2005 From: rahulsundaram at gmail.com (Rahul Sundaram) Date: Mon, 31 Jan 2005 19:26:16 +0530 Subject: rawhide firefox and background colour of webpages (CSS broken?) In-Reply-To: <32901.81.191.130.121.1107179444.squirrel@81.191.130.121> References: <1107118615.3866.9.camel@localhost.localdomain> <20050131121551.524bf76d@nausicaa.camperquake.de> <1107171161.5777.11.camel@angua.localnet> <1107177709.9022.17.camel@ulysse.olympe.o2t> <32901.81.191.130.121.1107179444.squirrel@81.191.130.121> Message-ID: Hi > Yes. But it isn't mandatory. They are broken, but they only look broken in > firefox at fc3 - so people believe that firefox is broken. it isnt mandatory. it is just a good design issue. firefox doesnt emulate IE quirks perfectly either. people believe firefox is broken on those IE specific websites too. thats a user education problem. > > And yes, i do also remember that Mosaic had a gray background. 10 years ago. > > So, please, please set the *default* settings so that most pages doesn't > look broken. if this is going to be done, change the gnome system colors on the whole to reflect this inorder to be consistent -- Regards, Rahul Sundaram From dwmw2 at infradead.org Mon Jan 31 14:14:17 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 31 Jan 2005 14:14:17 +0000 Subject: Better repodata performance In-Reply-To: References: <41FD2D97.4010809@nc.rr.com> Message-ID: <1107180857.19262.167.camel@hades.cambridge.redhat.com> On Mon, 2005-01-31 at 02:13 -0200, Alexandre Oliva wrote: > The point is the new repodata format was proposed to improve on what > yum had, but I'm convinced it's a step backwards as it stands. It > does offer one immediate advantage to the user, namely, the faster > download of information needed for an initial dependency resolution, > but, in the long run, you end up waiting longer for downloads, on > total. Please, if we're going to change the repodata _again_, let's keep backwards compatibility this time. It's bad enough that yum in FC3 can't use repositories created on a standard FC2 system; we don't want that again in FC4. -- dwmw2 From andreas at conectiva.com.br Mon Jan 31 14:23:16 2005 From: andreas at conectiva.com.br (Andreas Hasenack) Date: Mon, 31 Jan 2005 12:23:16 -0200 Subject: repository creation In-Reply-To: <1107140803.5161.38.camel@trevally.redfishdemo.com> References: <1107122639.1614.130.camel@cutter> <41FD7541.8090909@nc.rr.com> <1107140803.5161.38.camel@trevally.redfishdemo.com> Message-ID: <20050131142316.GD9599@conectiva.com.br> On Mon, Jan 31, 2005 at 02:06:43PM +1100, Rodd Clarkson wrote: > On Sun, 2005-01-30 at 19:01 -0500, Jeff Johnson wrote: > > > But yes, splitting packages by usage category, like -debuginfo, and > > srpm, would > > only help. Another split might be attempted by "popularity" as objectively > > measured by number of downloads. "Popular" or "important" packages might be > > released more often, while other packages less often, another way to reduce > > the amount of information that flows from repos. > > Or maybe splitting repos into different areas of Core. So you could > have a CORE repo, and KDE repo, a GNOME repo, a OOo repo, a Java repo, > etc so you only have to look through the repos that concern your install > base. Just some food for thought: we have been doing this for quite a while. Some love it, some hate it. For those who hate it (like myself, sometimes) there is an "all" metarepository which contains everything. Source: SRPMS.audio SRPMS.cross SRPMS.database SRPMS.devel SRPMS.doc SRPMS.doctools SRPMS.experimental SRPMS.extra SRPMS.games SRPMS.gnome SRPMS.gnome1 SRPMS.ha SRPMS.i18n-all SRPMS.kde SRPMS.kernel SRPMS.kernel-drivers-encumbered SRPMS.libvga SRPMS.main SRPMS.obsoleted SRPMS.orphan SRPMS.printer SRPMS.testing SRPMS.wmaker SRPMS.x11 And the binary counterpart: RPMS.audio RPMS.cross RPMS.database RPMS.devel RPMS.devel-static RPMS.doc RPMS.doctools RPMS.experimental RPMS.extra RPMS.games RPMS.gnome RPMS.gnome1 RPMS.ha RPMS.i18n RPMS.i18n-all RPMS.i18n-de RPMS.i18n-en RPMS.i18n-es RPMS.i18n-fr RPMS.i18n-it RPMS.i18n-ja RPMS.i18n-nl RPMS.i18n-pt RPMS.i18n-pt_BR RPMS.kde RPMS.kernel RPMS.kernel-drivers-encumbered RPMS.libvga RPMS.main RPMS.obsoleted RPMS.orphan RPMS.printer RPMS.testing RPMS.wmaker RPMS.x11 From seanlkml at sympatico.ca Mon Jan 31 15:12:02 2005 From: seanlkml at sympatico.ca (Sean) Date: Mon, 31 Jan 2005 10:12:02 -0500 (EST) Subject: RFC: Soname in rpm name In-Reply-To: <604aa79105013105356b0e2654@mail.gmail.com> References: <1106570484.32065.1.camel@ulysse.olympe.o2t><1106848153.22178.16.camel@Madison.badger.com><604aa7910501271146533837ad@mail.gmail.com><604aa79105012714437df84250@mail.gmail.com><46793.10.10.10.28.1107134580.squirrel@linux1><49465.10.10.10.28.1107170305.squirrel@linux1> <604aa79105013105356b0e2654@mail.gmail.com> Message-ID: <50653.10.10.10.28.1107184322.squirrel@linux1> On Mon, January 31, 2005 8:35 am, Jeff Spaleta said: > Yuo keep missing my point. I think some packagers have been worrying > about this all along and is one of the reason why soname in > packagename hasnt been the norm for Red Hat ever. Whether or not you > think its a corner case.. while a fascinating bit of information for > me to know... doesn't change whether or not this issue i bring has > been an important factor in the past for packagers who are not using > the soname-in-packagename model. And if it has been an important > factor in the past... i'd like to know what has changed. > Jeff, You keep missing the point. Just because you don't think it's a corner case, while a fascinating bit of information doesn't mean it's important factor for anyone. You continue to miss that people have already offered workable solutions. Anyway, you've failed to show it has ever been an important factor in the past or would even be one in the future. Nothing has changed. Sean From alan at redhat.com Mon Jan 31 15:21:32 2005 From: alan at redhat.com (Alan Cox) Date: Mon, 31 Jan 2005 10:21:32 -0500 Subject: rawhide firefox and background colour of webpages (CSS broken?) In-Reply-To: <20050131121551.524bf76d@nausicaa.camperquake.de> References: <1107118615.3866.9.camel@localhost.localdomain> <20050131121551.524bf76d@nausicaa.camperquake.de> Message-ID: <20050131152132.GC17568@devserv.devel.redhat.com> On Mon, Jan 31, 2005 at 12:15:51PM +0100, Ralf Ertzinger wrote: > Those web pages are broken. They assume that the default background > colour the browser chooses is white. This assumption does not hold. > If they want a white background they have to say so. There are other web browser people who tried things like defaulting to black backgrounds. Its a useful exercise in pedantry but the reality IMHO is that the web is as good as specified to have "slightly off white" as the default background. From riel at redhat.com Mon Jan 31 15:35:56 2005 From: riel at redhat.com (Rik van Riel) Date: Mon, 31 Jan 2005 10:35:56 -0500 (EST) Subject: Virtualisation in Fedora status, jan 2005 Message-ID: Virtualisation in Fedora status, jan 2005 The good news: - working Xen and kernel-xen0/U RPMs available in rawhide - grubby knows how to set up multiboot for the xen0 domain - people are starting to use the available RPMs - the network scripts now work in the presence of ipv6 - a Fedora project page on virtualisation is available: http://fedora.redhat.com/projects/virtualization/ - there is a HOWTO document, explaining how to set up Xen with Fedora http://www.fedoraproject.org/wiki/FedoraXenQuickstart Bugs & limitations: - X does not work on many systems, and appears to cause memory corruption on others - current xen0/U guest kernels are single CPU only - #146571 xen gets stuck at boot with "APIC error on CPU0" - #146575 xen interferes with X acceleration - #142046 XEN Graphical bugs and application instability in Xen dom... - #140847 X inside Xen only works when linux/libint10.a is moved TODO: - update to latest xen-unstable snapshot - apply the AGP patch, to try and remedy the X problems - build and test SMP xen0/U guest kernels - build and test xen and xen0/U kernels for x86-64 From mricon at gmail.com Mon Jan 31 15:40:54 2005 From: mricon at gmail.com (Konstantin Ryabitsev) Date: Mon, 31 Jan 2005 10:40:54 -0500 Subject: Better repodata performance In-Reply-To: References: <41FD2D97.4010809@nc.rr.com> Message-ID: On 31 Jan 2005 03:59:14 -0200, Alexandre Oliva wrote: > >> Yeah. Multiply that by a few thousand users, if you happen to run one > >> of the mirrors... > > > Well, that's not the user's problem, is it? > > But why are you narrowing your focus only on users? > > If users don't care about mirrors, how about letting them all go away? > Will users still not care? As someone who is somewhat involved in running a very large mirror, I will tell you that it's much better to have one request for a 1MB file than 50 requests for 10KB files, since mirrors tend to bog down on disk IO, not on bandwidth. Sequential reads for one request for a large file will cause less load than lots of small requests for many files all over the disk. We have bandwidth out the wazoo: it's always down to seek times. > > I am not. I'm very happy that I no longer have to wait for a half an > > hour for all .hdr files to download after I do a fresh install. > > Yeah, I like that too. But I'm not happy that I have to wait longer > for all the updates, on aggregate, if a minor additional improvement > could make things significantly better for everybody. This is what > I'm talking about. That's not a "minor additional improvement" : that's a major modification that will a) significantly complicate the code, and b) make existing repositories incompatible all over again. > Do the maths. I did the maths not for my own set up, but for what a > user of FC alone would face. Is there any particular point in those > numbers you disagree with? > > Do you actually like to wait for downloads? If you could reduce the > download time before yum starts updating from 10 seconds to 1 second, > wouldn't you like that? Compared to the amount of downloading a typical update or install involves, that makes very little difference to me. It's more or less like "wouldn't you prefer to start off from the top of a truck when climbing mt. Everest?" Besides, startup times are already being addressed in HEAD, with large improvements. > It only speaks for the fact that you may not care about tiny amounts > of time you waste without even realizing, and without realizing that > they add up very quickly. Yes. In fact, very few people seem to care. Let's look at usual complaints about yum. Number one reason regular users bitch at yum is because Seth stubbornly refuses to implement the --magically-resolve-all-packaging-problems feature, next to --use-complex-ai-to-figure-out-what-i-really-want. Then it's "yum is too slow" and "yum takes up too much memory", both problems currently actively worked on. You are the first person to complain about repodata-related bandwidth, and judging from the fact that very few people other than you, me, Seth, and Jeff have joined this conversation, I can tell that it's a non-issue as far as most people are concerned. If you survey the users of Fedora systems (not developers or even those who run rawhide, since that will be a very, very small percentage of Fedora users) about yum, your typical responses will probably be: 90%: Yum? What's yum? Our sysadmin handles all our computers. 9% Yeah, I think it runs nightly when I forget to turn off my machine before going to bed, plus I run "yum update" once or twice a month when I am bored. 0.9%: I run "yum update" daily and use it to install new software all the time. 0.1%: I use yum hourly because I am a developer or repo maintainer, and it sucks my balls through a straw. It's the ~1% of yum users who are the vocal ones, since it doesn't satisfy their level of usage. The rest are either quite happy with it, or don't even know that yum is used on their systems, and I tell you that from my experience supporting quite a number of people running and using Fedora. I'm not sure how much effort is justified to satisfy those with uncommon patterns of usage. Regards, -- Konstantin Ryabitsev Zlotniks, INC From n3npq at nc.rr.com Mon Jan 31 15:54:13 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 31 Jan 2005 10:54:13 -0500 Subject: Better repodata performance In-Reply-To: References: <41FD2D97.4010809@nc.rr.com> Message-ID: <41FE54A5.1040208@nc.rr.com> Konstantin Ryabitsev wrote: >It's the ~1% of yum users who are the vocal ones, since it doesn't >satisfy their level of usage. The rest are either quite happy with it, >or don't even know that yum is used on their systems, and I tell you >that from my experience supporting quite a number of people running >and using Fedora. I'm not sure how much effort is justified to satisfy >those with uncommon patterns of usage. > > Almost entirely correct. Howver (with some trepidation), I point out that user happiness does not always mean that an application is correctly and efficiently implemented. There is lots and lots of room for improvemnet in how package data is distributed, and how yum is implemented. OTOH, yum is sane and reliable, gets the job done with little fuss and muss. 73 de Jeff "Happiness is a warm gun." From dnjinc at wowway.com Mon Jan 31 16:01:23 2005 From: dnjinc at wowway.com (Demond James) Date: Mon, 31 Jan 2005 11:01:23 -0500 Subject: repository creation In-Reply-To: <1107156724.1614.161.camel@cutter> References: <1107122639.1614.130.camel@cutter> <20050130225214.GA22101@angus.ind.WPI.EDU> <20050131073703.GA5243@dudweiler.stuttgart.redhat.com> <1107155414.1614.158.camel@cutter> <20050131075707.GA6187@dudweiler.stuttgart.redhat.com> <1107156724.1614.161.camel@cutter> Message-ID: <41FE5653.4050607@wowway.com> seth vidal wrote: >>I think it is correct to move src.rpms and debuginfo out of the default >>path. Instead of moving this to the user to enable/disable it, I thought >>to use differently named files within the repodata. >>All information about src.rpms goes to new filenames and you can trigger >>reading in the debuginfo files if a "*-debuginfo" package name is needed. >> >>This puts the namespace question to the repodata and is adding special >>interpretation to rpm package names ("*-debuginfo"), but tries to get >>all this more transparent to the user compared to offering this via >>configured repo locations. >> >>?? Both ways have their pros and cons. >> >> > >The con of doing it the way you're describing is that it implicitly >dictates something about the repository structure. Not sure I like that. > >But i see your point about having them magically enabled. The only >problem is that for depsolving it doesn't make it much easier. > >-sv > > > > I have to put a vote in for having separate predefined metadata files in the repo that will be checked only if enabled in the yum.conf file. There will be separate metadata info for binary rpm, srpms and debuginfo rpms. By default only the binary rpms metadata info will be downloaded. Anyone needing srpms or debuginfo rpms can enable it in yum.conf or perhaps an "--enablemetadata=srpms" etc. option can be implemented. I think this is what Florian was talking about instead of having separate repos. Demond -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brian.Edginton at ge.com Mon Jan 31 16:11:29 2005 From: Brian.Edginton at ge.com (Edginton, Brian (GE Healthcare)) Date: Mon, 31 Jan 2005 10:11:29 -0600 Subject: syncing evolution w/ connector in rawhide (and others) Message-ID: <42BB180FA5BC094B8859720526D89B6602ABCB0F@MKEMLVEM04.e2k.ad.ge.com> I think there needs to be some discussion about keeping, at least packages in the same general family, sync'd with each other in rawhide. I know this horse has been beating to near death but it certainly interferes with comprehensive testing and getting the feedback necessary to move fedora forward. Case in point, evolution and evolution-data-server move forward to 2.1.4 in rawhide. Evolution-connector lags behind, because of it's dependencies on old libgal, libe*'s, etc. So now in this test environment mail is completely useless. Is there a way to encourage, or preferably enforce, keeping the wavefront coherent? edge From jspaleta at gmail.com Mon Jan 31 16:30:00 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 31 Jan 2005 11:30:00 -0500 Subject: RFC: Soname in rpm name In-Reply-To: <50653.10.10.10.28.1107184322.squirrel@linux1> References: <1106570484.32065.1.camel@ulysse.olympe.o2t> <604aa7910501271146533837ad@mail.gmail.com> <604aa79105012714437df84250@mail.gmail.com> <46793.10.10.10.28.1107134580.squirrel@linux1> <49465.10.10.10.28.1107170305.squirrel@linux1> <604aa79105013105356b0e2654@mail.gmail.com> <50653.10.10.10.28.1107184322.squirrel@linux1> Message-ID: <604aa7910501310830729b86c0@mail.gmail.com> On Mon, 31 Jan 2005 10:12:02 -0500 (EST), Sean wrote: > You keep missing the point. Just because you don't think it's a corner > case, while a fascinating bit of information doesn't mean it's important > factor for anyone. I don't think i've made a judgement as to whether or not this is a corner case. What I care about is understanding why the current naming scheme was chosen so we can have informed debate. So far no one has told me my obvservations are incorrect. Whether or not this historical usage is an important consideration is a discussion that comes after we have an understanding of what the historical usages are. Without an understanding of why the current naming scheme was chosen, and how its been used.. we are not in a solid position to evaluate a change in policy. I challenge you... as a proponent of change.. to give us your understanding as to why the current naming policy is in place. > You continue to miss that people have already offered > workable solutions. actually.. they havent. There have been proposals to address garbage collecting which is not what I'm talking about at all. Unused libraries...just take up space... and can be garbaged collected. Used but unmaintained libraries could become significant security concerns over time. Its a hard issue.. with no clean solution. How as a package vendor do you do the due diligence to prevent users from running unmaintained libraries unknowingly. It's about being as honest as possible with the users who are relying on updates to packages. I believe that Red Hat's current naming scheme.. is a hacked up attempt.. to be as honest as possible with the userbase (inside the constraints of the packaging system) about the maintainence state of shared library packages. Is it a hack? Yep, absolutely.. but this is the role i see the current naming scheme playing. > Anyway, you've failed to show it has ever been an > important factor in the past or would even be one in the future. Only Red Hat packages who have been using the naming scheme over the multiple releases of rhl, rhel and fedora can give credible insight into why the naming scheme is being used. If I'm wrong.. im wrong. But I think a serious discussion about changing the naming schedule requires a serious understanding of why the current naming scheme is being used. I challenge you as a proponent of change, to give me your understanding of why you think the current naming scheme is being used. >Nothing has changed. Great... nothing has changed... whatever priorities have unpinned the usage of the current naming scheme are still the same and we can can continue to use the current naming scheme. -jef From pmatilai at welho.com Mon Jan 31 17:00:56 2005 From: pmatilai at welho.com (Panu Matilainen) Date: Mon, 31 Jan 2005 19:00:56 +0200 (EET) Subject: Apt at fedora.us In-Reply-To: <41FE1235.2010101@togami.com> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <20050128123043.3a60b213.fedora@wir-sind-cool.org> <1106915462.5389.15.camel@mccallum.corsepiu.local> <20050128134756.70f3a4fb.fedora@wir-sind-cool.org> <1107078784.4018.216.camel@bobcat.mine.nu> <41FE1235.2010101@togami.com> Message-ID: On Mon, 31 Jan 2005, Warren Togami wrote: > Ville Skytt? wrote: >> FWIW, I would like to see the complete apt'table (pre-)Extras SRPMS >> repos available at fedora.us and its mirrors. The reasons have been >> outlined in this thread. > > I have to admit that I don't understand if there is any purpose in this. > "apt-get source" is only a convenience but otherwise is not very useful. Well, 'apt-get install foobar' is only a convenience as well, you could just as well manually locate latest version of, download and install with rpm. I find it a major pain in the ass to manually locate the latest version of a given src.rpm when apt (or any similar tool) can do it automatically for you. > "apt-get build-dep" does not need SRPMS at all except the local SRPM, which > you already have locally because you want to build it. Is there some aspect > of this that I am failing to see? I fail to see the "need" in this. You have to manually locate and download the SRPM first, and then use # apt-get build-dep /path/to/srpms/foobar-1.2-1.src.rpm compared to just # apt-get build-dep foobar It IS a much more convenient for us who deal with SRPMS a lot. Because the lack of the SRPMS I keep a local apt-enabled mirror of FC to be able to access the SRPMS without all the manual work, which feels somewhat ridiculous to me. > > From the perspective of mirror administrators it is somewhat painful to host > redundant RPMS. I personally don't have the disk space to do this forever > with all distributions. > > I suppose it is tolerable to do only SRPMS.extras of the latest stable > distribution. When FC4 happens, I will wipe the 3 SRPMS.extras. Is this > acceptable? I will however not add the base and updates SRPMS. That'd be a definite improvement over not having the SRPMS at all. - Panu - From ville.skytta at iki.fi Mon Jan 31 17:25:00 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 31 Jan 2005 19:25:00 +0200 Subject: Apt at fedora.us In-Reply-To: References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <20050128123043.3a60b213.fedora@wir-sind-cool.org> <1106915462.5389.15.camel@mccallum.corsepiu.local> <20050128134756.70f3a4fb.fedora@wir-sind-cool.org> <1107078784.4018.216.camel@bobcat.mine.nu> <41FE1235.2010101@togami.com> Message-ID: <1107192300.4018.338.camel@bobcat.mine.nu> Oops, I accidentally replied to Warren only, shorter version inline below. (A list copy is fine BTW.) On Mon, 2005-01-31 at 19:00 +0200, Panu Matilainen wrote: > On Mon, 31 Jan 2005, Warren Togami wrote: > > Ville Skytt? wrote: > >> FWIW, I would like to see the complete apt'table (pre-)Extras SRPMS > >> repos available at fedora.us and its mirrors. The reasons have been > >> outlined in this thread. > > > > I have to admit that I don't understand if there is any purpose in this. > > "apt-get source" is only a convenience but otherwise is not very useful. > > Well, 'apt-get install foobar' is only a convenience as well, you could > just as well manually locate latest version of, download and install with > rpm. I find it a major pain in the ass to manually locate the latest > version of a given src.rpm when apt (or any similar tool) can do it > automatically for you. With the current cvs.fedora.redhat.com setup, that's as trivial as typing "cvs up ; make srpm" in the correct package's CVS working dir. That works well enough for me. > > "apt-get build-dep" does not need SRPMS at all except the local SRPM, which > > you already have locally because you want to build it. Is there some aspect > > of this that I am failing to see? I fail to see the "need" in this. > > You have to manually locate and download the SRPM first, and then use > # apt-get build-dep /path/to/srpms/foobar-1.2-1.src.rpm > compared to just > # apt-get build-dep foobar > > It IS a much more convenient for us who deal with SRPMS a lot. Because the > lack of the SRPMS I keep a local apt-enabled mirror of FC to be able to > access the SRPMS without all the manual work, which feels somewhat > ridiculous to me. Seconded. Actually, I'm not personally that interested in the actual SRPMs, my feeble "lobbying" comment above was pretty much inaccurate. But I would _really_ like "apt-get build-dep" to work, not only for Extras, but core, updates, and updates-testing too. All that's required for it are the full apt source indexes; no actual SRPMs need to be available in repositories, right? > > From the perspective of mirror administrators it is somewhat painful to host > > redundant RPMS. I personally don't have the disk space to do this forever > > with all distributions. > > > > I suppose it is tolerable to do only SRPMS.extras of the latest stable > > distribution. When FC4 happens, I will wipe the 3 SRPMS.extras. Is this > > acceptable? I will however not add the base and updates SRPMS. > > That'd be a definite improvement over not having the SRPMS at all. Agreed, but I think for my needs, fedora.us hosting the full apt source indexes for all repo components and no SRPMs at all would be even better compromise. Others may have different requirements though. From dhollis at davehollis.com Mon Jan 31 18:22:06 2005 From: dhollis at davehollis.com (David Hollis) Date: Mon, 31 Jan 2005 13:22:06 -0500 Subject: syncing evolution w/ connector in rawhide (and others) In-Reply-To: <42BB180FA5BC094B8859720526D89B6602ABCB0F@MKEMLVEM04.e2k.ad.ge.com> References: <42BB180FA5BC094B8859720526D89B6602ABCB0F@MKEMLVEM04.e2k.ad.ge.com> Message-ID: <1107195726.5011.1.camel@dhollis-lnx.centricconsulting.com> On Mon, 2005-01-31 at 10:11 -0600, Edginton, Brian (GE Healthcare) wrote: > I think there needs to be some discussion about keeping, at least packages in the same general family, sync'd with each other in rawhide. I know this horse has been beating to near death but it certainly interferes with comprehensive testing and getting the feedback necessary to move fedora forward. > > Case in point, evolution and evolution-data-server move forward to 2.1.4 in rawhide. Evolution-connector lags behind, because of it's dependencies on old libgal, libe*'s, etc. > So now in this test environment mail is completely useless. > > Is there a way to encourage, or preferably enforce, keeping the wavefront coherent? > > edge > If you have an important workstation/server, you really shouldn't be running from Rawhide. Things get out of sync, break, get your cat pregnant, etc. all the time. You can't expect real stability until the few weeks prior to release when everything freezes and the various glitches are worked out. If there was any mandate to keep Rawhide stable at all times, it would be the equivalent of production and they would have to put out Beta/RC releases for Rawhide! Then we'd never see anything go anywhere. -- David Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Mon Jan 31 18:47:50 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 31 Jan 2005 08:47:50 -1000 Subject: Apt at fedora.us In-Reply-To: <1107190755.4018.323.camel@bobcat.mine.nu> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <20050128123043.3a60b213.fedora@wir-sind-cool.org> <1106915462.5389.15.camel@mccallum.corsepiu.local> <20050128134756.70f3a4fb.fedora@wir-sind-cool.org> <1107078784.4018.216.camel@bobcat.mine.nu> <41FE1235.2010101@togami.com> <1107190755.4018.323.camel@bobcat.mine.nu> Message-ID: <41FE7D56.7010808@redhat.com> Ville Skytt? wrote: > >>"apt-get build-dep" does not need SRPMS at all except the local >>SRPM, which you already have locally because you want to build it. > > > Right, but the source _indexes_ need to be available for build-dep to > work in the first place, no? apt-get build-dep TARGET_LOCAL.src.rpm does not require SRPMS in the apt repository. This only resolves and installs stuff from binary RPMS needed to build that local package. Am I missing something else? Warren Togami wtogami at redhat.com From Nicolas.Mailhot at laPoste.net Mon Jan 31 18:57:07 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 31 Jan 2005 19:57:07 +0100 Subject: syncing evolution w/ connector in rawhide (and others) In-Reply-To: <1107195726.5011.1.camel@dhollis-lnx.centricconsulting.com> References: <42BB180FA5BC094B8859720526D89B6602ABCB0F@MKEMLVEM04.e2k.ad.ge.com> <1107195726.5011.1.camel@dhollis-lnx.centricconsulting.com> Message-ID: <1107197827.13660.9.camel@rousalka.dyndns.org> Le lundi 31 janvier 2005 ? 13:22 -0500, David Hollis a ?crit : > If you have an important workstation/server, you really shouldn't be > running from Rawhide. Things get out of sync, break, get your cat > pregnant, etc. all the time. You can't expect real stability until the > few weeks prior to release when everything freezes and the various > glitches are worked out. OTOH there are some regressions you'll never see on a test box (network logins anyone ?) - so rawhide should be kept dogfoodable so the annoying bugs that take a long time to be fixed can be detected soon enough. And yes that does mean the system will be hosed for ~ 1 day/month (except right after the release freeze where you'd be mad to do a sync). For some people that's a cheap price to have FC's work right after release and not a month later. IMHO the tester is right we've passed the post-FC3 phase where it's ok to turn rawhide upside down and it's time to put it in a semi-testable state (this is by no means a demand, just my own POW - if Raw Hide can't be used before test releases it's little use for everyone, Red Hat included) Regards, -- Nicolas Mailhot Raw Hide tester since ~ RH 5.2 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From shiva at sewingwitch.com Mon Jan 31 18:57:17 2005 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 31 Jan 2005 10:57:17 -0800 Subject: rawhide firefox and background colour of webpages (CSS broken?) In-Reply-To: <20050131152132.GC17568@devserv.devel.redhat.com> References: <1107118615.3866.9.camel@localhost.localdomain> <20050131121551.524bf76d@nausicaa.camperquake.de> <20050131152132.GC17568@devserv.devel.redhat.com> Message-ID: --On Monday, January 31, 2005 10:21 AM -0500 Alan Cox wrote: > the reality IMHO is that the web is as good as specified to have > "slightly off white" as the default background. Then shouldn't those pages display "Best viewed with Internet Explorer set to a slightly off-white background"? ;) From tadams-lists at myrealbox.com Mon Jan 31 19:04:15 2005 From: tadams-lists at myrealbox.com (Trever L. Adams) Date: Mon, 31 Jan 2005 12:04:15 -0700 Subject: syncing evolution w/ connector in rawhide (and others) In-Reply-To: <1107195726.5011.1.camel@dhollis-lnx.centricconsulting.com> References: <42BB180FA5BC094B8859720526D89B6602ABCB0F@MKEMLVEM04.e2k.ad.ge.com> <1107195726.5011.1.camel@dhollis-lnx.centricconsulting.com> Message-ID: <1107198255.3402.0.camel@localhost.localdomain> On the same note, when the new (2.9.x) panel for gnome was built, someone it seems forgot to reenable the eds stuff. I do use it. Trever On Mon, 2005-01-31 at 13:22 -0500, David Hollis wrote: > On Mon, 2005-01-31 at 10:11 -0600, Edginton, Brian (GE Healthcare) > wrote: > > I think there needs to be some discussion about keeping, at least packages in the same general family, sync'd with each other in rawhide. I know this horse has been beating to near death but it certainly interferes with comprehensive testing and getting the feedback necessary to move fedora forward. > > > > Case in point, evolution and evolution-data-server move forward to 2.1.4 in rawhide. Evolution-connector lags behind, because of it's dependencies on old libgal, libe*'s, etc. > > So now in this test environment mail is completely useless. > > > > Is there a way to encourage, or preferably enforce, keeping the wavefront coherent? > > > > edge > > > > If you have an important workstation/server, you really shouldn't be > running from Rawhide. Things get out of sync, break, get your cat > pregnant, etc. all the time. You can't expect real stability until the > few weeks prior to release when everything freezes and the various > glitches are worked out. If there was any mandate to keep Rawhide > stable at all times, it would be the equivalent of production and they > would have to put out Beta/RC releases for Rawhide! Then we'd never see > anything go anywhere. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- "If there was strife and contention in the home, very little else in life could compensate for it." -- Lawana Blackwell, The Courtship of the Vicar's Daughter, 1998 From bclark at redhat.com Mon Jan 31 19:10:42 2005 From: bclark at redhat.com (Bryan Clark) Date: Mon, 31 Jan 2005 14:10:42 -0500 Subject: syncing evolution w/ connector in rawhide (and others) In-Reply-To: <1107198255.3402.0.camel@localhost.localdomain> References: <42BB180FA5BC094B8859720526D89B6602ABCB0F@MKEMLVEM04.e2k.ad.ge.com> <1107195726.5011.1.camel@dhollis-lnx.centricconsulting.com> <1107198255.3402.0.camel@localhost.localdomain> Message-ID: <1107198642.3760.9.camel@rhbw.boston.redhat.com> On Mon, 2005-01-31 at 12:04 -0700, Trever L. Adams wrote: > On the same note, when the new (2.9.x) panel for gnome was built, > someone it seems forgot to reenable the eds stuff. I do use it. Actually it seems it was disabled intentionally, not sure why Jeremy did that, but it probably is a temporary fix for something. https://www.redhat.com/archives/fedora-devel-list/2005-January/msg01717.html From notting at redhat.com Mon Jan 31 19:22:38 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 31 Jan 2005 14:22:38 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1107031959.4174.23.camel@localhost.localdomain> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <1107031959.4174.23.camel@localhost.localdomain> Message-ID: <20050131192237.GA3760@nostromo.devel.redhat.com> Kyrre Ness Sjobak (kyrre at solution-forge.net) said: > tir, 25.01.2005 kl. 21.14 skrev seth vidal: > > > Will and does are very different. IF it isn't there by FC4, FC4 should > > > include grip. However, I see all critical functionality, and most non- > > > critical, in RhythmBox. xmms uses gtk1 and doesn't seem to be needed; > > > should it be removed? > > > > Yes, it should. > > -sv > > > > What about simple "play that .mp3, i want to know what's in it" kind of > use? I must admit that i still use XMMS for that - it just works. Having > a libary isn't always what you want. So i have xmms as my default player > for all audio files. When i want to listen to an album i ripped (etc), i > fire up rythmbox, import the files if neccessary, and play it. Commandline? madplay or similar. I'd assume in the filemanager there would be something small that would launch on doubleclick. But I could be wrong. Bill From notting at redhat.com Mon Jan 31 19:24:53 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 31 Jan 2005 14:24:53 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050130152856.408462dd@nausicaa.camperquake.de> References: <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> <41F9DA4D.7040801@tlarson.com> <1106966975.5678.18.camel@localhost.localdomain> <20050130152856.408462dd@nausicaa.camperquake.de> Message-ID: <20050131192453.GB3760@nostromo.devel.redhat.com> Ralf Ertzinger (fedora-devel at camperquake.de) said: > There are some libraries I had to remove of which I am not sure whether there > are gtk2 replacements (and what these things are good for, anyway): > > Guppi > gal Both gnucash dependencies. Bill From jspaleta at gmail.com Mon Jan 31 19:25:13 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 31 Jan 2005 14:25:13 -0500 Subject: syncing evolution w/ connector in rawhide (and others) In-Reply-To: <1107197827.13660.9.camel@rousalka.dyndns.org> References: <42BB180FA5BC094B8859720526D89B6602ABCB0F@MKEMLVEM04.e2k.ad.ge.com> <1107195726.5011.1.camel@dhollis-lnx.centricconsulting.com> <1107197827.13660.9.camel@rousalka.dyndns.org> Message-ID: <604aa7910501311125706ffa5f@mail.gmail.com> On Mon, 31 Jan 2005 19:57:07 +0100, Nicolas Mailhot wrote: > IMHO the tester is right we've passed the post-FC3 phase where it's ok > to turn rawhide upside down and it's time to put it in a semi-testable > state (this is by no means a demand, just my own POW - if Raw Hide can't > be used before test releases it's little use for everyone, Red Hat > included) good thing the orignal poster filed a bug report then so this issue can be tracked accordingly. Aren't we jumping to conclusions here about the maintainer's intent? A quick look at http://cvs.fedora.redhat.com/viewcvs/devel/evolution-connector/ tells me the connector codebase was updated when evolution was, meaning for some reason the rawhide build system isn't building the new evolution-connector updates. Wouldn't it be grand if a rawhide tester interested in helping resolve the issue would check out the cvs tree via anonymous cvs, try to rebuild the package for themselves... identify the problem that is preventing the nightly rawhide build... and report back via bugzilla. Instead making rather unrealistic demands that packages in rawhide build flawlessly on the first attempt... how about we find a way to better communicate to rawhide users the build status of rawhide packages. Clearly, just having the cvs server up and accessible isn't cutting through the inertia. Perhaps if the daily rawhide summary reports also gave a list of packages that failed to build correctly... maybe that would be useful informations to rawhide testers... and inspire them to checkout cvs trees and attempt to identify and help resolve build issues with patches to bugzilla. -jef"i wonder if a bug report as been filed while i write this"spaleta From Brian.Edginton at ge.com Mon Jan 31 19:40:21 2005 From: Brian.Edginton at ge.com (Edginton, Brian (GE Healthcare)) Date: Mon, 31 Jan 2005 13:40:21 -0600 Subject: syncing evolution w/ connector in rawhide (and others) Message-ID: <42BB180FA5BC094B8859720526D89B6602AECA7F@MKEMLVEM04.e2k.ad.ge.com> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com > [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of David Hollis > > If you have an important workstation/server, you really shouldn't be > running from Rawhide. Things get out of sync, break, get your cat > pregnant, etc. all the time. You can't expect real stability > until the > few weeks prior to release when everything freezes and the various > glitches are worked out. If there was any mandate to keep Rawhide > stable at all times, it would be the equivalent of production and they > would have to put out Beta/RC releases for Rawhide! Then > we'd never see > anything go anywhere. In a general sense I totally agree and follow this concept. But when it involves familiar components it tends to break the ability to provide the testing and feedback necessary to move the rawhide model forward. Perhaps the output of the build could be made more accessible (and maybe it is and I just don't know about it). We could then either what until the components we need are back in sync, or we could dive into cvs and provide feedback that is more productive than my whining! ;) edge From cmadams at hiwaay.net Mon Jan 31 19:42:28 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 31 Jan 2005 13:42:28 -0600 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050131192237.GA3760@nostromo.devel.redhat.com> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <1107031959.4174.23.camel@localhost.localdomain> <20050131192237.GA3760@nostromo.devel.redhat.com> Message-ID: <20050131194228.GC1279302@hiwaay.net> Once upon a time, Bill Nottingham said: > Kyrre Ness Sjobak (kyrre at solution-forge.net) said: > > What about simple "play that .mp3, i want to know what's in it" kind of > > use? I must admit that i still use XMMS for that - it just works. Having > > a libary isn't always what you want. So i have xmms as my default player > > for all audio files. When i want to listen to an album i ripped (etc), i > > fire up rythmbox, import the files if neccessary, and play it. > > Commandline? madplay or similar. > > I'd assume in the filemanager there would be something small that > would launch on doubleclick. But I could be wrong. In FC3 (with MP3 support added via livna for xmms and gstreamer)), I opened nautilus and double clicked on an MP3. It brought up the Helix Player Setup Assistant. That just goes through the release notes (kind of dumb), then brings up a box that says that there is a "component missing" with a "Get RealPlayer" button. With all the discussion that rhythmbox makes xmms unneeded (so it should be removed from Core), why do we also have Helix Player in Core (or is Helix Player supposed to replace rhythmbox and xmms)? Is it possible to add plugins to Helix Player to get MP3 (and other format) support as easily as for rhythmbox and xmms? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From walters at redhat.com Mon Jan 31 19:46:51 2005 From: walters at redhat.com (Colin Walters) Date: Mon, 31 Jan 2005 14:46:51 -0500 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050131194228.GC1279302@hiwaay.net> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <1107031959.4174.23.camel@localhost.localdomain> <20050131192237.GA3760@nostromo.devel.redhat.com> <20050131194228.GC1279302@hiwaay.net> Message-ID: <1107200811.3777.41.camel@nexus.verbum.private> On Mon, 2005-01-31 at 13:42 -0600, Chris Adams wrote: > Once upon a time, Bill Nottingham said: > > Kyrre Ness Sjobak (kyrre at solution-forge.net) said: > > > What about simple "play that .mp3, i want to know what's in it" kind of > > > use? I must admit that i still use XMMS for that - it just works. Having > > > a libary isn't always what you want. So i have xmms as my default player > > > for all audio files. When i want to listen to an album i ripped (etc), i > > > fire up rythmbox, import the files if neccessary, and play it. > > > > Commandline? madplay or similar. > > > > I'd assume in the filemanager there would be something small that > > would launch on doubleclick. But I could be wrong. > > In FC3 (with MP3 support added via livna for xmms and gstreamer)), I > opened nautilus and double clicked on an MP3. It brought up the Helix > Player Setup Assistant. That just goes through the release notes (kind > of dumb), then brings up a box that says that there is a "component > missing" with a "Get RealPlayer" button. This is a complex issue, but basically what it boils down to is that /usr/share/applications/defaults.list can only contain one application for each MIME type. Once we fix that, we can ensure that e.g. if you don't have HelixPlayer installed but do have totem, you get totem. > With all the discussion that rhythmbox makes xmms unneeded (so it should > be removed from Core), why do we also have Helix Player in Core (or is > Helix Player supposed to replace rhythmbox and xmms)? Helix and Rhythmbox are pretty different. > Is it possible to > add plugins to Helix Player to get MP3 (and other format) support as > easily as for rhythmbox and xmms? Not as far as I know. From Nicolas.Mailhot at laPoste.net Mon Jan 31 19:46:57 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 31 Jan 2005 20:46:57 +0100 Subject: syncing evolution w/ connector in rawhide (and others) In-Reply-To: <604aa7910501311125706ffa5f@mail.gmail.com> References: <42BB180FA5BC094B8859720526D89B6602ABCB0F@MKEMLVEM04.e2k.ad.ge.com> <1107195726.5011.1.camel@dhollis-lnx.centricconsulting.com> <1107197827.13660.9.camel@rousalka.dyndns.org> <604aa7910501311125706ffa5f@mail.gmail.com> Message-ID: <1107200817.14102.27.camel@rousalka.dyndns.org> Le lundi 31 janvier 2005 ? 14:25 -0500, Jeff Spaleta a ?crit : > On Mon, 31 Jan 2005 19:57:07 +0100, Nicolas Mailhot > wrote: > >(this is by no means a demand, just my own POW - if Raw Hide can't > > be used before test releases it's little use for everyone, Red Hat > > included) > Instead making rather unrealistic demands that packages in rawhide > build flawlessly on the first attempt... Like I said, this is any sort of demand. Please do not put words that I explicitly refused to use in my mouth. I was answering the assertion that " You can't expect real stability until the few weeks prior to release when everything freezes and the various glitches are worked out. If there was any mandate to keep Rawhide stable at all times, it would be the equivalent of production and they would have to put out Beta/RC releases for Rawhide! " A "few weeks prior to release" is way too late to start worrying about stabilising Raw Hide. You know it and I know it. Therefore the first poster was perfectly right to expect the stabilisation to be under way by now (and to fill a bug). Presenting Raw Hide to be so dangerous you can not beta-test it is as counter-productive as expecting it to be perfect. It's more raw than FC, but with a little care it won't eat your brainz either (to quote a famous post on this list). Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From katzj at redhat.com Mon Jan 31 19:55:34 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 31 Jan 2005 14:55:34 -0500 Subject: syncing evolution w/ connector in rawhide (and others) In-Reply-To: <1107198255.3402.0.camel@localhost.localdomain> References: <42BB180FA5BC094B8859720526D89B6602ABCB0F@MKEMLVEM04.e2k.ad.ge.com> <1107195726.5011.1.camel@dhollis-lnx.centricconsulting.com> <1107198255.3402.0.camel@localhost.localdomain> Message-ID: <1107201334.10373.20.camel@bree.local.net> On Mon, 2005-01-31 at 12:04 -0700, Trever L. Adams wrote: > On the same note, when the new (2.9.x) panel for gnome was built, > someone it seems forgot to reenable the eds stuff. I do use it. It looks like it should be enabled according to the spec file... that doesn't mean it's not broken though :-) Jeremy From cmadams at hiwaay.net Mon Jan 31 19:56:11 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 31 Jan 2005 13:56:11 -0600 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1107200811.3777.41.camel@nexus.verbum.private> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <1107031959.4174.23.camel@localhost.localdomain> <20050131192237.GA3760@nostromo.devel.redhat.com> <20050131194228.GC1279302@hiwaay.net> <1107200811.3777.41.camel@nexus.verbum.private> Message-ID: <20050131195610.GD1279302@hiwaay.net> Once upon a time, Colin Walters said: > On Mon, 2005-01-31 at 13:42 -0600, Chris Adams wrote: > > With all the discussion that rhythmbox makes xmms unneeded (so it should > > be removed from Core), why do we also have Helix Player in Core (or is > > Helix Player supposed to replace rhythmbox and xmms)? > > Helix and Rhythmbox are pretty different. Rhythmbox and xmms are pretty different as well. > > Is it possible to > > add plugins to Helix Player to get MP3 (and other format) support as > > easily as for rhythmbox and xmms? > > Not as far as I know. Hmm, dumb question then: why is Helix Player listed as the default MP3 application? I tried to do a little research on Helix Player, but the website appears to be down right now. It would be nice if dropping in a plugin of some type was all it took to add MP3 (and Real) support. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From katzj at redhat.com Mon Jan 31 19:56:37 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 31 Jan 2005 14:56:37 -0500 Subject: syncing evolution w/ connector in rawhide (and others) In-Reply-To: <1107198642.3760.9.camel@rhbw.boston.redhat.com> References: <42BB180FA5BC094B8859720526D89B6602ABCB0F@MKEMLVEM04.e2k.ad.ge.com> <1107195726.5011.1.camel@dhollis-lnx.centricconsulting.com> <1107198255.3402.0.camel@localhost.localdomain> <1107198642.3760.9.camel@rhbw.boston.redhat.com> Message-ID: <1107201397.10373.23.camel@bree.local.net> On Mon, 2005-01-31 at 14:10 -0500, Bryan Clark wrote: > On Mon, 2005-01-31 at 12:04 -0700, Trever L. Adams wrote: > > On the same note, when the new (2.9.x) panel for gnome was built, > > someone it seems forgot to reenable the eds stuff. I do use it. > > Actually it seems it was disabled intentionally, not sure why Jeremy did > that, but it probably is a temporary fix for something. > > https://www.redhat.com/archives/fedora-devel-list/2005-January/msg01717.html That was for gnome-panel 2.8 since it didn't know the API needed for newer e-d-s. 2.9.90-1 looks to me like it should be back enabled Jeremy From johnp at redhat.com Mon Jan 31 19:59:32 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 31 Jan 2005 14:59:32 -0500 Subject: D-BUS 0.30 in my yum repository - porting guide attached Message-ID: <1107201572.32198.34.camel@remedyz.boston.redhat.com> I have D-BUS version 0.30 in my yum repository at [j5utopia] name=J5's Experimental Project Utopia Repository baseurl=http://people.redhat.com/johnp/redhat/experimental/utopia You will have to --force --nodeps the packages for now until all the packages are updated to use the new dbus. Attached is a short porting guide. Ask me if you have any more complicated questions about the new API's. Please patch your rpm's to reflect the new API. We will make the switchover in a couple of weeks or whenever all the packages are done. Send me the srpm's so I can add packages to the repository as they are done. Here is a list of packages in core that need to be updated: gnome-volume-manager - me hal - davidz NetworkManager - dcbw NetworkManager-gnome - dcbw desktop-printing - walters cups - twaugh I'm posting this to fedora-devel so that packagers outside of core can consider themselves warned. Massive API breakage for anything that uses D-BUS is on the horizon as we move closer to 1.0. The 0.30 series should mark the biggest change moving to 1.0 and I don't expect anymore API breakage other than the glib bindings in the future. If there is I'll let you know. Thanks -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com -------------- next part -------------- C API Changes: - s/dbus_bus_acquire_service/dbus_bus_request_name - s/dbus_bus_activate_service/dbus_bus_start_service_by_name - s/dbus_bus_get_base_service/dbus_bus_get_unique_name - s/dbus_bus_service_exists/dbus_bus_name_has_owner - s/DBUS_ACTIVATION_REPLY_ACTIVATED/DBUS_START_REPLY_SUCCESS - s/DBUS_ACTIVATION_REPLY_ALREADY_ACTIVE/DBUS_START_REPLY_ALREADY_RUNNING - s/DBUS_BUS_ACTIVATION/DBUS_BUS_STARTER - If you wish to append to an itterator you must now initalize it with dbus_message_iter_init_append DBUS API Changes: * Methods - s/org.freedesktop.DBus.AquireService/org.freedesktop.DBus.RequestName - s/org.freedesktop.DBus.ListServices/org.freedesktop.DBus.ListNames - s/org.freedesktop.DBus.ServiceExists/org.freedesktop.DBus.NameHasOwner - s/org.freedesktop.DBus.ActivateService/org.freedesktop.DBus.StartServiceByName - s/org.freedesktop.DBus.GetServiceOwner/org.freedesktop.DBus.GetNameOwner * Signals - s/org.freedesktop.DBus.ServiceAcquired/org.freedesktop.DBus.NameAcquired - s/org.freedesktop.DBus.ServiceLost/org.freedesktop.DBus.NameLost - s/org.freedesktop.DBus.ServiceOwnerChanged/org.freedesktop.DBus.NameOwnerChanged Changes to Defaults: - DBUS_HEADER_FLAG_AUTO_START - auto starting(activation) is on by default Types: * New - DBUS_TYPE_INT16 - 16bit integer - DBUS_TYPE_UINT16 - 16bit unsigned integer - DBUS_TYPE_DICT_ENTRY - Dictionaries (array of key value pair structs) - DBUS_TYPE_SIGNATURE - dbus type signature string - DBUS_TYPE_VARIENT - a value that has its signature embeded - DBUS_TYPE_STRUCT - an array of different types * Removed - DBUS_TYPE_NIL - DBUS_TYPE_DICT - DBUS_TYPE_CUSTOM Type Iterator Changes: - All specific type API's have been removed. Use dbus_message_get_basic instead. Example: dbus_int32_t i; . . . /* i = dbus_message_iter_get_int32 (&iter); */ dbus_message_iter_get_basic (&iter, &i); This goes for writting too. Example: dbus_int32_t i; i = 10 . . . /* dbus_message_iter_append_int32 (&iter, i); */ dbus_message_iter_append_basic (&iter, DBUS_TYPE_INT32, &i); - When appending to a message use dbus_message_iter_init_append to get an iterator that can be written to. - Use dbus_message_iter_recurse to read values in a container type such as an array, varient, dict or struct. Example: int arg_type; DBusMessageIter main_iter; . . . arg_type = dbus_message_iter_get_arg_type (&main_iter); /* you should use a switch here */ if (arg_type == DBUS_TYPE_ARRAY) { DBusMessageIter array_iter; /* assuming that we know the array is an array of strings*/ gchar *item; assert (dbus_message_iter_get_element_type (&main_iter) == DBUS_TYPE_STRING); dbus_message_iter_recurse (&main_iter, &array_iter); do { const char *value; char *str; dbus_message_iter_get_basic (&array_iter, &value); str = g_strdup (value); g_print ("The value of the array element is: %s\n", str); g_free (str); } while (dbus_message_iter_next(&array_iter)); } One may also use the convinience function for fixed length arrays: void dbus_message_iter_get_fixed_array (DBusMessageIter *iter, void *value, int *n_elements); - When appending container types to iterators use the dbus_message_iter_open_container and it's complement dbus_message_iter_close_container. Example: DBusMessageIter main_iter, array_iter; int i; . . . /* open an array of strings container */ arg_type = dbus_message_iter_open_container (&main_iter, DBUS_TYPE_ARRAY, DBUS_TYPE_STRING_TO_STRING, &array_iter); for (i = 0; i < 10; i++) { gchar buffer[255]; g_sprintf (buffer, "Array element %i", i); dbus_message_iter_append_basic (&array_iter, DBUS_TYPE_STRING, &buffer); } dbus_message_iter_close_container (&main_iter, &array_iter); One may also use the convinience function for fixed length arrays: void dbus_message_iter_append_fixed_array (DBusMessageIter *iter, int element_type, void *value, int *n_elements); From Nicolas.Mailhot at laPoste.net Mon Jan 31 19:59:51 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 31 Jan 2005 20:59:51 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050131195610.GD1279302@hiwaay.net> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <1107031959.4174.23.camel@localhost.localdomain> <20050131192237.GA3760@nostromo.devel.redhat.com> <20050131194228.GC1279302@hiwaay.net> <1107200811.3777.41.camel@nexus.verbum.private> <20050131195610.GD1279302@hiwaay.net> Message-ID: <1107201591.14102.28.camel@rousalka.dyndns.org> Le lundi 31 janvier 2005 ? 13:56 -0600, Chris Adams a ?crit : > Once upon a time, Colin Walters said: > > On Mon, 2005-01-31 at 13:42 -0600, Chris Adams wrote: > Hmm, dumb question then: why is Helix Player listed as the default MP3 > application? > > I tried to do a little research on Helix Player, but the website appears > to be down right now. It would be nice if dropping in a plugin of some > type was all it took to add MP3 (and Real) support. I'm pretty sure that's the case. Helix + real plugin + mp3 plugin = real player. Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jspaleta at gmail.com Mon Jan 31 20:03:09 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 31 Jan 2005 15:03:09 -0500 Subject: syncing evolution w/ connector in rawhide (and others) In-Reply-To: <1107200817.14102.27.camel@rousalka.dyndns.org> References: <42BB180FA5BC094B8859720526D89B6602ABCB0F@MKEMLVEM04.e2k.ad.ge.com> <1107195726.5011.1.camel@dhollis-lnx.centricconsulting.com> <1107197827.13660.9.camel@rousalka.dyndns.org> <604aa7910501311125706ffa5f@mail.gmail.com> <1107200817.14102.27.camel@rousalka.dyndns.org> Message-ID: <604aa79105013112031e7cc8a0@mail.gmail.com> On Mon, 31 Jan 2005 20:46:57 +0100, Nicolas Mailhot wrote: > Like I said, this is any sort of demand. Please do not put words that I > explicitly refused to use in my mouth. sorry, i apologize. > A "few weeks prior to release" is way too late to start worrying about > stabilising Raw Hide. You know it and I know it. prior to which release? to test1? I know no such thing... in fact the oo.org 1.x versus 2.x pep-rally is still raging. I'd imagine if we applied nominal effort we can hijack that thread and grind that discussion to a halt while we debate the finer points as to which day in the development cycle stablization should turn a corner. Hell.. i even expect to see some major shifts in tree content post-test1. If there are some very very dubious breakages in test1 that have no resolutions on the time scale of full release i fully expect to see some downgrades happening in test2. And packages downgrades are always fun in rawhide.. since there has never been any promise to make rawhide monotonically updatable via the use of epochs. -jef From perbj at stanford.edu Mon Jan 31 20:08:18 2005 From: perbj at stanford.edu (Per Bjornsson) Date: Mon, 31 Jan 2005 12:08:18 -0800 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1107201591.14102.28.camel@rousalka.dyndns.org> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <1107031959.4174.23.camel@localhost.localdomain> <20050131192237.GA3760@nostromo.devel.redhat.com> <20050131194228.GC1279302@hiwaay.net> <1107200811.3777.41.camel@nexus.verbum.private> <20050131195610.GD1279302@hiwaay.net> <1107201591.14102.28.camel@rousalka.dyndns.org> Message-ID: <1107202098.5350.4.camel@localhost.localdomain> On Mon, 2005-01-31 at 20:59 +0100, Nicolas Mailhot wrote: > > I tried to do a little research on Helix Player, but the website appears > > to be down right now. It would be nice if dropping in a plugin of some > > type was all it took to add MP3 (and Real) support. > > I'm pretty sure that's the case. Helix + real plugin + mp3 plugin = real > player. Well, it seems like that's basically true, but can you actually get the plugins needed anywhere other than by getting RealPlayer instead? /Per -- Per Bjornsson Ph.D. Candidate, Department of Applied Physics, Stanford University From seanlkml at sympatico.ca Mon Jan 31 20:31:30 2005 From: seanlkml at sympatico.ca (Sean) Date: Mon, 31 Jan 2005 15:31:30 -0500 (EST) Subject: RFC: Soname in rpm name In-Reply-To: <604aa7910501310830729b86c0@mail.gmail.com> References: <1106570484.32065.1.camel@ulysse.olympe.o2t><604aa7910501271146533837ad@mail.gmail.com><604aa79105012714437df84250@mail.gmail.com><46793.10.10.10.28.1107134580.squirrel@linux1><49465.10.10.10.28.1107170305.squirrel@linux1><604aa79105013105356b0e2654@mail.gmail.com><50653.10.10.10.28.1107184322.squirrel@linux1><604aa7910501310830729b86c0@mail.gmail.com> Message-ID: <51859.10.10.10.28.1107203490.squirrel@linux1> On Mon, January 31, 2005 11:30 am, Jeff Spaleta said: -- I don't think i've made a judgement as to whether or not this is a corner case. What I care about is understanding why the current naming scheme was chosen so we can have informed debate. So far no one has told me my obvservations are incorrect. Whether or not this historical usage is an important consideration is a discussion that comes after we have an understanding of what the historical usages are. Without an understanding of why the current naming scheme was chosen, and how its been used.. we are not in a solid position to evaluate a change in policy. I challenge you... as a proponent of change.. to give us your understanding as to why the current naming policy is in place. -- I'm just a proponent of you coming to terms with the fact that your instinct to become involved in every single thread just wasn't helpful or insightful this time. Perhaps there's a chance... however small... that you might actually be .... gasp .... wrong. Really, a viable option was even presented in this thread to deal with your concern. But if you have no historical insight or judgement of your own on the matter, let someone who does pipe in if they think its important, instead of sidetracking the conversation into oblivion. Not everything has to be explained to _you_ before proceeding. TTN, Sean From Nicolas.Mailhot at laPoste.net Mon Jan 31 20:41:14 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 31 Jan 2005 21:41:14 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1107202098.5350.4.camel@localhost.localdomain> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <1107031959.4174.23.camel@localhost.localdomain> <20050131192237.GA3760@nostromo.devel.redhat.com> <20050131194228.GC1279302@hiwaay.net> <1107200811.3777.41.camel@nexus.verbum.private> <20050131195610.GD1279302@hiwaay.net> <1107201591.14102.28.camel@rousalka.dyndns.org> <1107202098.5350.4.camel@localhost.localdomain> Message-ID: <1107204074.14102.30.camel@rousalka.dyndns.org> Le lundi 31 janvier 2005 ? 12:08 -0800, Per Bjornsson a ?crit : > On Mon, 2005-01-31 at 20:59 +0100, Nicolas Mailhot wrote: > > > I tried to do a little research on Helix Player, but the website appears > > > to be down right now. It would be nice if dropping in a plugin of some > > > type was all it took to add MP3 (and Real) support. > > > > I'm pretty sure that's the case. Helix + real plugin + mp3 plugin = real > > player. > > Well, it seems like that's basically true, but can you actually get the > plugins needed anywhere other than by getting RealPlayer instead? That's the catch of course;) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From rodd at clarkson.id.au Mon Jan 31 20:42:19 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 01 Feb 2005 07:42:19 +1100 Subject: rawhide firefox and background colour of webpages (CSS broken?) In-Reply-To: References: <1107118615.3866.9.camel@localhost.localdomain> <20050131121551.524bf76d@nausicaa.camperquake.de> <1107171161.5777.11.camel@angua.localnet> <1107177709.9022.17.camel@ulysse.olympe.o2t> <32901.81.191.130.121.1107179444.squirrel@81.191.130.121> Message-ID: <1107204139.5316.6.camel@localhost.localdomain> On Mon, 2005-01-31 at 19:26 +0530, Rahul Sundaram wrote: > Hi > > > Yes. But it isn't mandatory. They are broken, but they only look broken in > > firefox at fc3 - so people believe that firefox is broken. > > it isnt mandatory. it is just a good design issue. firefox doesnt > emulate IE quirks perfectly either. people believe firefox is broken > on those IE specific websites too. thats a user education problem. > > > And yes, i do also remember that Mosaic had a gray background. 10 years ago. > > > > So, please, please set the *default* settings so that most pages doesn't > > look broken. > if this is going to be done, change the gnome system colors on the > whole to reflect this inorder to be consistent Actually, a web browser is a little like getting a ream of paper. While you can get paper in a range of colors, when you ask your mate to grab a ream of paper when he's at the office supplies, you expect him to come back with a ream of 'white' paper, and almost all your documents are set up for white paper unless you particularly wanted a different color. The same thing should happen with web-browsers. User's expect a white background. Hell, a lot of bad web designers expect a white background. It might be worth asking the mozilla guys why the default background color changed from grey to white. I suspect that it had something to do with the fact that most users just went and changed the color to white because the grey was annoying (they expected white). Rodd -- >From the pain come the dream >From the dream come the vision >From the vision come the people >From the people come the power >From this power come the change - Peter Gabriel From ville.skytta at iki.fi Mon Jan 31 20:57:32 2005 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 31 Jan 2005 22:57:32 +0200 Subject: Apt at fedora.us In-Reply-To: <41FE7D56.7010808@redhat.com> References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <20050128123043.3a60b213.fedora@wir-sind-cool.org> <1106915462.5389.15.camel@mccallum.corsepiu.local> <20050128134756.70f3a4fb.fedora@wir-sind-cool.org> <1107078784.4018.216.camel@bobcat.mine.nu> <41FE1235.2010101@togami.com> <1107190755.4018.323.camel@bobcat.mine.nu> <41FE7D56.7010808@redhat.com> Message-ID: <1107205052.4018.383.camel@bobcat.mine.nu> On Mon, 2005-01-31 at 08:47 -1000, Warren Togami wrote: > apt-get build-dep TARGET_LOCAL.src.rpm does not require SRPMS in the apt > repository. This only resolves and installs stuff from binary RPMS > needed to build that local package. Am I missing something else? build-dep is useful for non-local SRPMs too. But given that "make srpm ; sudo apt-get build-dep *.src.rpm" from a CVS checkout dir works, it's not actually that big a deal at all. It just means some brutal adjustments to muscle memory :? From thacker at math.cornell.edu Mon Jan 31 21:10:08 2005 From: thacker at math.cornell.edu (John Thacker) Date: Mon, 31 Jan 2005 16:10:08 -0500 Subject: gnome-vfs2 and cdda Message-ID: <20050131211008.GA9414@thacker.dyndns.org> So I created bug #137250 a while back, and no one seems to have claimed it. ( https://bugzilla.redhat.com/beta/show_bug.cgi?id=137250 ) I can understand why, as it's a bit complicated. gnome-vfs2 has a CDDA module which uses cdparanoia. By default, it's enabled in /etc/gnome-vfs-2.0/modules/default-modules.conf. However, it doesn't get built because of the unusual location of the cdparanoia include headers in RedHat and Fedora. They're located in /usr/include/cdda/cdda_paranoia.h and /usr/include/cdda/cdda_interface.h instead of just in /usr/include. Therefore, gnome-vfs2 doesn't build the CDDA module, and, since it's enabled in the default configuration, there are tons and tons of warnings when adding new files in totem or anything else which uses gstreamer and/or gnome-vfs2, and prevents totem from playing audio CDs. (Bug 144803 - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=144803 ) Other programs which use cdparanoia have been patched to detect the header files in their special location. See various bugs dealing with grip and kde ( such as 62852 ) Why is it in a non-standard place? Well, cdparanoia header files include a file called utils.h that includes a couple standard macros. Originally this wasn't included in RHL because of a reluctance to include a file called utils.h in /usr/include. (See bugs 38223 and 62852) As a result, they were put into /usr/include/cdda. (As it turns out, grip doesn't use utils.h anymore, it seems.) So, there are a couple of options: 1) Comment out the cdda plugin in default-modules.conf. Advantages: easy, no more warnings Disadvantages: still can't play audio CDs in totem 2) Patch gnome-vfs2 build process so that it finds the include files in the proper place Advantages: plugin builds, everything works Disadvantages: possibly annoying 3) (Drop utils.h and?) Put cdparanoia includes in the standard place. Advantages: easy, everything works Disadvantages: someone might want utils.h, changes old workaround, reasons for workaround might still exist I'd like to have some sort of fix for this, or at least a comment or two. I imagine that responsibility for the bug or the proper fix is difficult to identify, though, which probably has slowed things. See also bug 102754 for another problem having to do with compiling using cdparanoia. John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From peter.backlund at home.se Mon Jan 31 21:20:56 2005 From: peter.backlund at home.se (Peter Backlund) Date: Mon, 31 Jan 2005 22:20:56 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <20050131195610.GD1279302@hiwaay.net> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <1107031959.4174.23.camel@localhost.localdomain> <20050131192237.GA3760@nostromo.devel.redhat.com> <20050131194228.GC1279302@hiwaay.net> <1107200811.3777.41.camel@nexus.verbum.private> <20050131195610.GD1279302@hiwaay.net> Message-ID: <1107206456.5724.30.camel@localhost.localdomain> > I tried to do a little research on Helix Player, but the website appears > to be down right now. It would be nice if dropping in a plugin of some > type was all it took to add MP3 (and Real) support. I tried dropping the mp3 plugin files from RealPlayer in the HelixPlayer plugin dir, and voil?! mp3 playback enabled. I don't think the mp3 component is non-distributable, only the RealAudio/RealVideo ones. A HelixPlayer-mpeg package might be possible to host at rpm.livna.org, for mp3 and mpeg4 playback. /Peter From notting at redhat.com Mon Jan 31 21:31:10 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 31 Jan 2005 16:31:10 -0500 Subject: repository creation In-Reply-To: <1107122639.1614.130.camel@cutter> References: <1107122639.1614.130.camel@cutter> Message-ID: <20050131213110.GC10803@nostromo.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > so you end up with srpms and debuginfo rpms in there. > > So you get 2623 pkgs to read through for fc3 base > > but if you just read through binary rpms you only have 1653 pkgs to read > through. A pretty serious savings, almost 1000 packages. What is the amount of time/memory/etc used during reading of this extraneous data? Bill From skvidal at phy.duke.edu Mon Jan 31 21:38:00 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 31 Jan 2005 16:38:00 -0500 Subject: repository creation In-Reply-To: <20050131213110.GC10803@nostromo.devel.redhat.com> References: <1107122639.1614.130.camel@cutter> <20050131213110.GC10803@nostromo.devel.redhat.com> Message-ID: <1107207480.5291.17.camel@opus.phy.duke.edu> On Mon, 2005-01-31 at 16:31 -0500, Bill Nottingham wrote: > seth vidal (skvidal at phy.duke.edu) said: > > so you end up with srpms and debuginfo rpms in there. > > > > So you get 2623 pkgs to read through for fc3 base > > > > but if you just read through binary rpms you only have 1653 pkgs to read > > through. A pretty serious savings, almost 1000 packages. > > What is the amount of time/memory/etc used during reading of this > extraneous data? well you're almost doubling the amount of data to read in/sort through. from what I've seen it goes pretty linearly with the number of nodes. So figure something like a 1/3rd or half as much time to iterate over the nodes. memory size I've not estimated. -sv From notting at redhat.com Mon Jan 31 21:43:49 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 31 Jan 2005 16:43:49 -0500 Subject: repository creation In-Reply-To: <1107207480.5291.17.camel@opus.phy.duke.edu> References: <1107122639.1614.130.camel@cutter> <20050131213110.GC10803@nostromo.devel.redhat.com> <1107207480.5291.17.camel@opus.phy.duke.edu> Message-ID: <20050131214348.GB10866@nostromo.devel.redhat.com> seth vidal (skvidal at phy.duke.edu) said: > > What is the amount of time/memory/etc used during reading of this > > extraneous data? > > well you're almost doubling the amount of data to read in/sort through. > > from what I've seen it goes pretty linearly with the number of nodes. > > So figure something like a 1/3rd or half as much time to iterate over > the nodes. But how much is this time related to the other time in processing/dep resolution/etc. I mean, if it ends up shaving only .1 seconds... Bill From mike at netlyncs.com Mon Jan 31 21:44:15 2005 From: mike at netlyncs.com (Mike Chambers) Date: Mon, 31 Jan 2005 15:44:15 -0600 Subject: Starting sshd errors Message-ID: <1107207855.32622.6.camel@scrappy.netlyncs.com> Up until a few weeks (couple I guess) openssh was working fine. But now when trying to start it, I get "initlog not found", which is around line 107, when the /etc/init.d/sshd file has "initlog -c blah blah". Have been away from home last few weeks so haven't really been able to pay attention if this problem already has a fix, so sorry if asking again. Thanks, -- Mike Chambers Madisonville, KY "It's always better to hurt a little now, than to hurt a lot later!" From Nicolas.Mailhot at laPoste.net Mon Jan 31 21:45:42 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 31 Jan 2005 22:45:42 +0100 Subject: grip being removed [Re: rawhide report: 20050120 changes] In-Reply-To: <1107206456.5724.30.camel@localhost.localdomain> References: <1106333362.3427.19.camel@localhost.localdomain> <1106334872.3809.3.camel@nexus.verbum.private> <1106683981.3394.4.camel@localhost.localdomain> <1106684051.30714.9.camel@opus.phy.duke.edu> <1107031959.4174.23.camel@localhost.localdomain> <20050131192237.GA3760@nostromo.devel.redhat.com> <20050131194228.GC1279302@hiwaay.net> <1107200811.3777.41.camel@nexus.verbum.private> <20050131195610.GD1279302@hiwaay.net> <1107206456.5724.30.camel@localhost.localdomain> Message-ID: <1107207942.15146.3.camel@rousalka.dyndns.org> Le lundi 31 janvier 2005 ? 22:20 +0100, Peter Backlund a ?crit : > > I tried to do a little research on Helix Player, but the website appears > > to be down right now. It would be nice if dropping in a plugin of some > > type was all it took to add MP3 (and Real) support. > > I tried dropping the mp3 plugin files from RealPlayer in the HelixPlayer > plugin dir, and voil?! mp3 playback enabled. > > I don't think the mp3 component is non-distributable, only the > RealAudio/RealVideo ones. A HelixPlayer-mpeg package might be possible > to host at rpm.livna.org, for mp3 and mpeg4 playback. Somehow I doubt Real will allow this after their instant of fame claiming they have "secured" an mp3 license for the users of real player. (Of course I may be wrong and they may admit they were talking crap to get quoted by clueless journalists) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at phy.duke.edu Mon Jan 31 21:47:10 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 31 Jan 2005 16:47:10 -0500 Subject: repository creation In-Reply-To: <20050131214348.GB10866@nostromo.devel.redhat.com> References: <1107122639.1614.130.camel@cutter> <20050131213110.GC10803@nostromo.devel.redhat.com> <1107207480.5291.17.camel@opus.phy.duke.edu> <20050131214348.GB10866@nostromo.devel.redhat.com> Message-ID: <1107208030.5291.23.camel@opus.phy.duke.edu> > But how much is this time related to the other time in processing/dep > resolution/etc. I mean, if it ends up shaving only .1 seconds... run: yum clean cache time yum makecache now run that again w/o the srpms in the repo. it's not insignificant for the read in. it varies with cpu speed, of course. -sv From sopwith at redhat.com Mon Jan 31 21:57:57 2005 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 31 Jan 2005 16:57:57 -0500 (EST) Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: <604aa79105012514452c79558@mail.gmail.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> Message-ID: Hey Jef, thanks for compiling this list! On Tue, 25 Jan 2005, Jeff Spaleta wrote: > Bill Notting: > xloadimage > nedit > jed jed to extras once that process works, but probably needs to stick around until then. The others look right. > Peter Robinson: > Can we also get rid / move to extras all the non > GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK > 1 cruft as well? Need specific package nominations. > F?liciano Matias: > move to extras dosfstools This one is needed as mentioned on the list. > move to extras Lynx (or elinks) These (and w3m) each have particular quirks that apparently make them all worthy of inclusion. > move to extras lesstif and/or openmotif21 openmotif21 may be needed for compatibility. lesstif sounds fine so we'll see. > leave openmotif which is used by: > stardict, ddd, xpdf, nedit, iiimf-le-chinput > move to extras xpdf We'll wait until evince gets in. > move to extras ddd I think it needs to be maintained in Core for now, as it's the only graphical debugger worth much. > Remove rpmdb. This is useful to some people and is especially needed for building x86_64 trees. > move experimental gcc (gcc4 in FC3 for example) to Fedora Extra. No, this is needed for java stuff. > Alax Cox: > Possibly joe into extras Same deal as jed, I suspect. > Nicolas Mailhot : > Even better : get rid of all the stuff that doesn't use fontconfig > yet Need specific package nominations, please. The list so far: xloadimage nedit lesstif Cheers, -- Elliot From skvidal at phy.duke.edu Mon Jan 31 22:04:36 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 31 Jan 2005 17:04:36 -0500 Subject: radical suggestion for fc4 release Message-ID: <1107209076.5291.26.camel@opus.phy.duke.edu> Hi folks, this is a touch silly but possibly useful and it would definitely cut down on the old crap blocking up cdroms. how about if we kill all rpm spec file changelog entries OLDER than 2 years. they'll still live on in older srpms and rpms but it'd be a useful reduction and it would make the specfiles that much smaller, along with the rpm headers. thoughts? -sv From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 31 22:09:22 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 31 Jan 2005 23:09:22 +0100 Subject: redhat abe In-Reply-To: <1106915462.5389.15.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Fri, 28 Jan 2005 13:31:01 +0100") References: <20050127082839.GE29221@batman.gotham.krass.com> <1106816778.5624.67.camel@laptopd505.fenrus.org> <1106827992.1316.14.camel@otto.amantes> <41F8E9C7.8080306@nc.rr.com> <1106833452.22312.93.camel@mccallum.corsepiu.local> <1106833957.29597.96.camel@cutter> <1106835854.22312.101.camel@mccallum.corsepiu.local> <1106908449.22312.242.camel@mccallum.corsepiu.local> <20050128123043.3a60b213.fedora@wir-sind-cool.org> <1106915462.5389.15.camel@mccallum.corsepiu.local> Message-ID: <87r7k1cktp.fsf@kosh.ultra.csn.tu-chemnitz.de> rc040203 at freenet.de (Ralf Corsepius) writes: > This renders "apt-get source" and "apt-get build-dep" non-applicable > to fedora.us hosted apt-repositories and therefore voids at least > these aspects where apt is superior to yum. Although I love apt for its powerful configuration, I have to admit that 'apt-get build-dep' is not very usefully in the rpm-world: * it detects only the requirements which were used to build the src.rpm, but not the deps which will be required * extending functionality is a non-trivial task, as the dep-resolving should happen as non-root while the final package removal/installation must happen as root Enrico From jspaleta at gmail.com Mon Jan 31 22:18:07 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 31 Jan 2005 17:18:07 -0500 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> Message-ID: <604aa7910501311418c1c417d@mail.gmail.com> On Mon, 31 Jan 2005 16:57:57 -0500 (EST), Elliot Lee wrote: > > Peter Robinson: > > Can we also get rid / move to extras all the non > > GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK > > 1 cruft as well? > > Need specific package nominations. The gtk1 apps dead horse has been beaten in the grip removal thread. As far as end-user applications that require gtk1 the potential list Peter Robinson would be talking about are: xmms ( gtk2 based bmp exists as replacement for functionality but is not a 100% feature replacement some noted usability deficiencies in moving to bmp ) gnucash ( a beast of a beast and there has been no discussion of a suitable replacement for its functionality) usbview ( no discussion that I've seen ) mtr-gtk ( no discussion that I've seen ) sylpheed ( no discussion that I've seen ) w3m-img (no discussion that I've seen) nmap-frontend (no discussion that I've seen ) as summaried from Colin Charles full list of packages that require the gtk+-1.2.10 package: bonobo-1.0.22-9.i386 cdicconf-0.2-9.i386 GConf-1.0.9-15.i386 gdk-pixbuf-0.22.0-15.0.i386 gdk-pixbuf-gnome-0.22.0-15.0.i386 gnome-libs-1.4.1.2.90-44.i386 gnome-print-0.37-10.i386 gnome-vfs-1.0.5-21.i386 gnucash-1.8.9-2.i386 gtk+-1.2.10-33.i386 gtk+-devel-1.2.10-33.i386 gtk-engines-0.12-5.i386 gtkhtml-1.1.9-10.i386 Guppi-0.40.3-21.i386 imlib-1.9.13-21.i386 libdv-tools-0.103-1.i386 libgal23-0.24-4.i386 libglade-0.17-15.i386 libgnomeprint15-0.37-10.i386 mtr-gtk-0.54-10.i386 nmap-frontend-3.70-1.i386 sylpheed-0.9.12-1.i386 usbview-1.0-13.i386 w3m-img-0.5.1-4.FC3.1.i386 xmms-1.2.10-9.i386 xmms-flac-1.1.0-7.i386 -jef From thacker at math.cornell.edu Mon Jan 31 22:20:16 2005 From: thacker at math.cornell.edu (John Thacker) Date: Mon, 31 Jan 2005 17:20:16 -0500 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: References: <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> Message-ID: <20050131222016.GA9816@thacker.dyndns.org> On Mon, Jan 31, 2005 at 04:57:57PM -0500, Elliot Lee wrote: > > Peter Robinson: > > Can we also get rid / move to extras all the non > > GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK > > 1 cruft as well? > > Need specific package nominations. nmap-frontend is one. gnucash we're waiting on the port to gtk2 John Thacker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pekkas at netcore.fi Mon Jan 31 22:22:30 2005 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 1 Feb 2005 00:22:30 +0200 (EET) Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> Message-ID: On Mon, 31 Jan 2005, Elliot Lee wrote: >> Possibly joe into extras > > Same deal as jed, I suspect. Hopefully not :). Joe is about the only useful text editor out there; pico is too feature-poor, emacs is too big, and Real Men don't want to touch vi if it can be avoided. /runs before someone starts flaming. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From skvidal at phy.duke.edu Mon Jan 31 22:25:33 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 31 Jan 2005 17:25:33 -0500 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106367390.5183.14.camel@one.myworld> <20050122170130.GI2898@devserv.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> Message-ID: <1107210333.5291.40.camel@opus.phy.duke.edu> On Tue, 2005-02-01 at 00:22 +0200, Pekka Savola wrote: > On Mon, 31 Jan 2005, Elliot Lee wrote: > >> Possibly joe into extras > > > > Same deal as jed, I suspect. > > Hopefully not :). Joe is about the only useful text editor out there; > pico is too feature-poor, emacs is too big, and Real Men don't want to > touch vi if it can be avoided. > > /runs before someone starts flaming. it's not going away. it would just be leaving core. going to extras. that's all. heck, YOU could maintain it in extras if you wanted. wouldn't that be cool? -sv From nbargnesi at gmail.com Mon Jan 31 22:26:38 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Mon, 31 Jan 2005 17:26:38 -0500 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> Message-ID: <3077b8a00501311426287845f2@mail.gmail.com> On Mon, 31 Jan 2005 16:57:57 -0500 (EST), Elliot Lee wrote: > Hey Jef, thanks for compiling this list! > > On Tue, 25 Jan 2005, Jeff Spaleta wrote: > > > Bill Notting: > > xloadimage > > nedit > > jed > > jed to extras once that process works, but probably needs to stick around > until then. The others look right. > > > Peter Robinson: > > Can we also get rid / move to extras all the non > > GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK > > 1 cruft as well? > > Need specific package nominations. > > > F?liciano Matias: > > move to extras dosfstools > > This one is needed as mentioned on the list. > > > move to extras Lynx (or elinks) > > These (and w3m) each have particular quirks that apparently make them all > worthy of inclusion. > > > move to extras lesstif and/or openmotif21 > > openmotif21 may be needed for compatibility. lesstif sounds fine so we'll > see. > > > leave openmotif which is used by: > > stardict, ddd, xpdf, nedit, iiimf-le-chinput > > move to extras xpdf > > We'll wait until evince gets in. > > > move to extras ddd > > I think it needs to be maintained in Core for now, as it's the only > graphical debugger worth much. > > > Remove rpmdb. > > This is useful to some people and is especially needed for building x86_64 > trees. > > > move experimental gcc (gcc4 in FC3 for example) to Fedora Extra. > > No, this is needed for java stuff. > > > Alax Cox: > > Possibly joe into extras > > Same deal as jed, I suspect. > > > Nicolas Mailhot : > > Even better : get rid of all the stuff that doesn't use fontconfig > > yet > > Need specific package nominations, please. > > The list so far: xloadimage nedit lesstif > > Cheers, > -- Elliot > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From nbargnesi at gmail.com Mon Jan 31 22:30:05 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Mon, 31 Jan 2005 17:30:05 -0500 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> Message-ID: <3077b8a005013114301a46facb@mail.gmail.com> > On Mon, 31 Jan 2005 16:57:57 -0500 (EST), Elliot Lee wrote: > Hey Jef, thanks for compiling this list! > > On Tue, 25 Jan 2005, Jeff Spaleta wrote: > > > Bill Notting: > > xloadimage > > nedit > > jed > > jed to extras once that process works, but probably needs to stick around > until then. The others look right. > > > Peter Robinson: > > Can we also get rid / move to extras all the non > > GNOME 2 / GTK 2 apps so we can get rid of the remaining GNOME 1 / GTK > > 1 cruft as well? > > Need specific package nominations. > > > F?liciano Matias: > > move to extras dosfstools > > This one is needed as mentioned on the list. > > > move to extras Lynx (or elinks) > > These (and w3m) each have particular quirks that apparently make them all > worthy of inclusion. > > > move to extras lesstif and/or openmotif21 > > openmotif21 may be needed for compatibility. lesstif sounds fine so we'll > see. I know of quite a few applications using openmotif that standardize on Red Hat / Fedora Core distributions. Is the suggestion to remove 2.1 keeping 2.2? > > > leave openmotif which is used by: > > stardict, ddd, xpdf, nedit, iiimf-le-chinput > > move to extras xpdf > > We'll wait until evince gets in. > > > move to extras ddd > > I think it needs to be maintained in Core for now, as it's the only > graphical debugger worth much. > > > Remove rpmdb. > > This is useful to some people and is especially needed for building x86_64 > trees. > > > move experimental gcc (gcc4 in FC3 for example) to Fedora Extra. > > No, this is needed for java stuff. > > > Alax Cox: > > Possibly joe into extras > > Same deal as jed, I suspect. > > > Nicolas Mailhot : > > Even better : get rid of all the stuff that doesn't use fontconfig > > yet > > Need specific package nominations, please. > > The list so far: xloadimage nedit lesstif > > Cheers, > -- Elliot > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From n3npq at nc.rr.com Mon Jan 31 22:30:48 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 31 Jan 2005 17:30:48 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107209076.5291.26.camel@opus.phy.duke.edu> References: <1107209076.5291.26.camel@opus.phy.duke.edu> Message-ID: <41FEB198.7010706@nc.rr.com> seth vidal wrote: >Hi folks, > this is a touch silly but possibly useful and it would definitely cut >down on the old crap blocking up cdroms. > >how about if we kill all rpm spec file changelog entries OLDER than 2 >years. > >they'll still live on in older srpms and rpms but it'd be a useful >reduction and it would make the specfiles that much smaller, along with >the rpm headers. > > +1 73 de Jeff From skvidal at phy.duke.edu Mon Jan 31 22:31:22 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 31 Jan 2005 17:31:22 -0500 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: <3077b8a005013114301a46facb@mail.gmail.com> References: <20050121235849.GA6469@nostromo.devel.redhat.com> <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <3077b8a005013114301a46facb@mail.gmail.com> Message-ID: <1107210682.5291.49.camel@opus.phy.duke.edu> > > > > openmotif21 may be needed for compatibility. lesstif sounds fine so we'll > > see. > > I know of quite a few applications using openmotif that standardize on > Red Hat / Fedora Core distributions. Is the suggestion to remove 2.1 > keeping 2.2? > And there's no reason they can't go on doing this. they'll just to have make sure extras is enabled in their yum repositories and: yum install openmotif\* -sv From nbargnesi at gmail.com Mon Jan 31 22:34:02 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Mon, 31 Jan 2005 17:34:02 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107209076.5291.26.camel@opus.phy.duke.edu> References: <1107209076.5291.26.camel@opus.phy.duke.edu> Message-ID: <3077b8a00501311434a00e0f4@mail.gmail.com> On Mon, 31 Jan 2005 17:04:36 -0500, seth vidal wrote: > Hi folks, > this is a touch silly but possibly useful and it would definitely cut > down on the old crap blocking up cdroms. > > how about if we kill all rpm spec file changelog entries OLDER than 2 > years. > > they'll still live on in older srpms and rpms but it'd be a useful > reduction and it would make the specfiles that much smaller, along with > the rpm headers. > > thoughts? It'd be interesting to see how much space something like this would save first. > > -sv > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From skvidal at phy.duke.edu Mon Jan 31 22:36:04 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Mon, 31 Jan 2005 17:36:04 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <3077b8a00501311434a00e0f4@mail.gmail.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> Message-ID: <1107210964.5291.52.camel@opus.phy.duke.edu> On Mon, 2005-01-31 at 17:34 -0500, Nick Bargnesi wrote: > On Mon, 31 Jan 2005 17:04:36 -0500, seth vidal wrote: > > Hi folks, > > this is a touch silly but possibly useful and it would definitely cut > > down on the old crap blocking up cdroms. > > > > how about if we kill all rpm spec file changelog entries OLDER than 2 > > years. > > > > they'll still live on in older srpms and rpms but it'd be a useful > > reduction and it would make the specfiles that much smaller, along with > > the rpm headers. > > > > thoughts? > > It'd be interesting to see how much space something like this would save first. Why first? What's the loss in doing it and moving along? the changelogs would be in cvs FOR EVER and in old srpms and on old isos and... and... and... it seems like it is an immediate, not-huge win. heck it doesn't even have to happen immediately - just the next time someone edits the spec file - just chop out all the old entries beyond 2 yrs. if we did that right before every release it's easy to keep track of. hell, once a year would be enough. -sv From dpaun at rogers.com Mon Jan 31 22:36:03 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Mon, 31 Jan 2005 17:36:03 -0500 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: References: <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> Message-ID: <20050131223603.GD29819@rogers.com> On Tue, Feb 01, 2005 at 12:22:30AM +0200, Pekka Savola wrote: > pico is too feature-poor, emacs is too big, and Real Men don't want to > touch vi if it can be avoided. ^^^^^^^^ Ahem, err -- I think that should read 'Girly Man' instead... :) -- Dimi. From esr at thyrsus.com Mon Jan 31 22:37:29 2005 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 31 Jan 2005 17:37:29 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <41FEB198.7010706@nc.rr.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> Message-ID: <20050131223729.GA30385@thyrsus.com> Jeff Johnson : > seth vidal wrote: > > >Hi folks, > >this is a touch silly but possibly useful and it would definitely cut > >down on the old crap blocking up cdroms. > > > >how about if we kill all rpm spec file changelog entries OLDER than 2 > >years. > > > >they'll still live on in older srpms and rpms but it'd be a useful > >reduction and it would make the specfiles that much smaller, along with > >the rpm headers. > > > > > > +1 Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. If changelogs are bloating the headers yum has to download, then strip them out when generating the yum headers. -- Eric S. Raymond From johnp at redhat.com Mon Jan 31 22:41:38 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 31 Jan 2005 17:41:38 -0500 Subject: D-BUS 0.30 in my yum repository - porting guide attached In-Reply-To: <1107201572.32198.34.camel@remedyz.boston.redhat.com> References: <1107201572.32198.34.camel@remedyz.boston.redhat.com> Message-ID: <1107211298.32198.77.camel@remedyz.boston.redhat.com> There are some corrections on the porting guide. Get it fresh from here http://people.redhat.com/johnp/files/dbus_0.23_to_0.30_porting_quickref.txt. On Mon, 2005-01-31 at 14:59 -0500, John (J5) Palmieri wrote: > I have D-BUS version 0.30 in my yum repository at > > [j5utopia] > name=J5's Experimental Project Utopia Repository > baseurl=http://people.redhat.com/johnp/redhat/experimental/utopia > > You will have to --force --nodeps the packages for now until all the > packages are updated to use the new dbus. > > Attached is a short porting guide. Ask me if you have any more > complicated questions about the new API's. > > Please patch your rpm's to reflect the new API. We will make the > switchover in a couple of weeks or whenever all the packages are done. > Send me the srpm's so I can add packages to the repository as they are > done. Here is a list of packages in core that need to be updated: > > gnome-volume-manager - me > hal - davidz > NetworkManager - dcbw > NetworkManager-gnome - dcbw > desktop-printing - walters > cups - twaugh > > I'm posting this to fedora-devel so that packagers outside of core can > consider themselves warned. Massive API breakage for anything that uses > D-BUS is on the horizon as we move closer to 1.0. The 0.30 series > should mark the biggest change moving to 1.0 and I don't expect anymore > API breakage other than the glib bindings in the future. If there is > I'll let you know. > > Thanks > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list -- John (J5) Palmieri Associate Software Engineer Desktop Group Red Hat, Inc. Blog: http://martianrock.com From notting at redhat.com Mon Jan 31 22:43:30 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 31 Jan 2005 17:43:30 -0500 Subject: Volunteers? was Re: further package removals/potential package removals In-Reply-To: <604aa7910501311418c1c417d@mail.gmail.com> References: <1106424891.31857.20.camel@stargrazer.home.awesomeplay.com> <41F525CD.6020001@terminus.co.uk> <41F64F26.6080708@terminus.co.uk> <604aa79105012514452c79558@mail.gmail.com> <604aa7910501311418c1c417d@mail.gmail.com> Message-ID: <20050131224330.GG10866@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > usbview ( no discussion that I've seen ) Could probably be very simply ported. > mtr-gtk ( no discussion that I've seen ) A GTK app that only works if run as root. Frankly, it should just be taken out and shot. > sylpheed ( no discussion that I've seen ) I believe this was mentioned along with balsa in an earlier message. Bill From n3npq at nc.rr.com Mon Jan 31 22:43:32 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 31 Jan 2005 17:43:32 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <41FEB198.7010706@nc.rr.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> Message-ID: <41FEB494.3030703@nc.rr.com> Jeff Johnson wrote: > seth vidal wrote: > >> Hi folks, >> this is a touch silly but possibly useful and it would definitely cut >> down on the old crap blocking up cdroms. >> >> how about if we kill all rpm spec file changelog entries OLDER than 2 >> years. >> >> they'll still live on in older srpms and rpms but it'd be a useful >> reduction and it would make the specfiles that much smaller, along with >> the rpm headers. >> >> > > +1 In fact, it's silly to carry changelogs in packages, since packaging changes are far more easily read from e-mail, or from a web-site, or just about any other way than rpm -q --changelog pkg The majority of content (note that there are definite execptions) in package changelogs is rather useless. Here's an example from a random package, util-linux: * Mon Jan 26 2004 Elliot Lee 2.12pre-3 - Provides: mount losetup * Mon Jan 26 2004 Dan Walsh 2.12pre-2 - Add multiple to /etc/pam.d/login for SELinux * Thu Jan 15 2004 Elliot Lee 2.12pre-1 - 2.12pre-1 - Merge mount/losetup packages into the main package (#112324) - Lose separate * Mon Nov 03 2003 Dan Walsh 2.11y-35.sel - remove selinux code from login and use pam_selinux * Thu Oct 30 2003 Dan Walsh 2.11y-34.sel - turn on selinux * Fri Oct 24 2003 Elliot Lee 2.11y-34 - Add BuildRequires: texinfo (from a bug# I don't remember) - Fix #90588 with mountman patch142. * Mon Oct 06 2003 Dan Walsh 2.11y-33 - turn off selinux * Thu Sep 25 2003 Dan Walsh 2.11y-32.sel - turn on selinux - remove context selection * Fri Sep 19 2003 Elliot Lee 2.11y-31 - Add patch140 (alldevs) to fix #101772. Printing the total size of all devices was deemed a lower priority than having all devices (e.g. /dev/ida/c0d9) displayed. * Fri Sep 12 2003 Dan Walsh 2.11y-31 - turn off selinux * Fri Sep 12 2003 Dan Walsh 2.11y-30.sel - turn on selinux * Fri Sep 05 2003 Elliot Lee 2.11y-28 - Fix #103004, #103954 * Fri Sep 05 2003 Dan Walsh 2.11y-27 - turn off selinux * Thu Sep 04 2003 Dan Walsh 2.11y-26.sel - build with selinux * Mon Aug 11 2003 Elliot Lee 2.11y-25 - Use urandom instead for mkcramfs * Tue Jul 29 2003 Dan Walsh 2.11y-24 - add SELINUX 2.5 support * Wed Jul 23 2003 Elliot Lee 2.11y-22 - #100433 patch With no offense whatsoever to anyone, I humbly submit that the comments in the changelog are of rather limited use to any non-redhat developer, and are totally useless to any end-user. So perhaps changelogs should be nuked entirely, and handled ouside of package content, instead. 73 de Jeff From jspaleta at gmail.com Mon Jan 31 22:44:45 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 31 Jan 2005 17:44:45 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <20050131223729.GA30385@thyrsus.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> Message-ID: <604aa791050131144466ce7ed7@mail.gmail.com> On Mon, 31 Jan 2005 17:37:29 -0500, Eric S. Raymond wrote: > Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. > > If changelogs are bloating the headers yum has to download, then > strip them out when generating the yum headers. they bloat the packages as well... which means they bloat the install media and bloat the download times over the network. I'm hard pressed to think of a real-world situation where 2 year old package changelog notations in the packages are needed. Shouldn't access to the cvs server suffice for deep-diving into package changelogs? -jef From jspaleta at gmail.com Mon Jan 31 22:53:34 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 31 Jan 2005 17:53:34 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <41FEB494.3030703@nc.rr.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> Message-ID: <604aa79105013114531c42b2c1@mail.gmail.com> On Mon, 31 Jan 2005 17:43:32 -0500, Jeff Johnson wrote: > With no offense whatsoever to anyone, I humbly submit that the comments in > the changelog are of rather limited use to any non-redhat developer, and are > totally useless to any end-user. I don't know about totally useless. I've refered to changelogs in the past to track down issues when troubleshooting issues concerned when a certain bugfix or security fix have been applied. Changelog entries that refer to specific bug numbers or CAN numbers can be quite helpful in this regard. Limited, but not totally useless value. I will conceed that I could probably use a web lookup for all this information if it were made the primary means of access to changelogs. And I would be more at ease with losing the changelogs in the package completely if package update notification texts containing the information were more closely aligned with package update mechanisms. -jef From shahms at shahms.com Mon Jan 31 22:55:45 2005 From: shahms at shahms.com (Shahms King) Date: Mon, 31 Jan 2005 14:55:45 -0800 Subject: radical suggestion for fc4 release In-Reply-To: <3077b8a00501311434a00e0f4@mail.gmail.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> Message-ID: <1107212145.30653.174.camel@shahms.mesd.k12.or.us> On Mon, 2005-01-31 at 17:34 -0500, Nick Bargnesi wrote: > On Mon, 31 Jan 2005 17:04:36 -0500, seth vidal wrote: > > Hi folks, > > this is a touch silly but possibly useful and it would definitely cut > > down on the old crap blocking up cdroms. > > > > how about if we kill all rpm spec file changelog entries OLDER than 2 > > years. > > > > they'll still live on in older srpms and rpms but it'd be a useful > > reduction and it would make the specfiles that much smaller, along with > > the rpm headers. > > > > thoughts? > > It'd be interesting to see how much space something like this would save first. $ rpm -qa --changelog | wc -c 11597562 That's just a little over 11 megabytes for all change logs on a FC3 system. I've also got non-Core packages installed which would increase that size slightly. That's also (obviously) including changelog entries which would not be stripped. I'm just guessing here, but I suspect that the total savings would be significantly smaller. I don't think the effort or loss of history would really be worth it. -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From feliciano.matias at free.fr Mon Jan 31 22:57:08 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Mon, 31 Jan 2005 23:57:08 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <20050131223729.GA30385@thyrsus.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> Message-ID: <1107212228.17531.6.camel@one.myworld> Le lundi 31 janvier 2005 ? 17:37 -0500, Eric S. Raymond a ?crit : > > If changelogs are bloating the headers yum has to download, then > strip them out when generating the yum headers. changelogs are in repodata/other.xml (seems yum does not use this file). other.xml.gz = 5 Mo FC3 = 2.3 Go -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jos at xos.nl Mon Jan 31 22:58:26 2005 From: jos at xos.nl (Jos Vos) Date: Mon, 31 Jan 2005 23:58:26 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <41FEB494.3030703@nc.rr.com>; from n3npq@nc.rr.com on Mon, Jan 31, 2005 at 05:43:32PM -0500 References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> Message-ID: <20050131235826.A28641@xos037.xos.nl> On Mon, Jan 31, 2005 at 05:43:32PM -0500, Jeff Johnson wrote: > So perhaps changelogs should be nuked entirely, and handled ouside of > package content, instead. Why not just removing the changelog from the rpm header and having them only accessible via the spec file in the src.rpm. There it is useful for packagers (inside and outside RH) and doesn't bother "normal users". -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From dpaun at rogers.com Mon Jan 31 23:01:57 2005 From: dpaun at rogers.com (Dimitrie O. Paun) Date: Mon, 31 Jan 2005 18:01:57 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <20050131223729.GA30385@thyrsus.com> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <20050131223729.GA30385@thyrsus.com> Message-ID: <20050131230157.GE29819@rogers.com> On Mon, Jan 31, 2005 at 05:37:29PM -0500, Eric S. Raymond wrote: > Oh, no. *Bad* idea. It's an attack on the symptom, not the problem. No, it's a *good* idea IMO. Problem is it does't go all the way. WTH are changelogs doing in .spec files?!? This is the job of the version control system, not of packaging specifications. It probably comes from the (misguided) school of thought that includes $Log$ in source files... -- Dimi. From nbargnesi at gmail.com Mon Jan 31 23:02:24 2005 From: nbargnesi at gmail.com (Nick Bargnesi) Date: Mon, 31 Jan 2005 18:02:24 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107212145.30653.174.camel@shahms.mesd.k12.or.us> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107212145.30653.174.camel@shahms.mesd.k12.or.us> Message-ID: <3077b8a00501311502386cd8bb@mail.gmail.com> On Mon, 31 Jan 2005 14:55:45 -0800, Shahms King wrote: > On Mon, 2005-01-31 at 17:34 -0500, Nick Bargnesi wrote: > > On Mon, 31 Jan 2005 17:04:36 -0500, seth vidal wrote: > > > Hi folks, > > > this is a touch silly but possibly useful and it would definitely cut > > > down on the old crap blocking up cdroms. > > > > > > how about if we kill all rpm spec file changelog entries OLDER than 2 > > > years. > > > > > > they'll still live on in older srpms and rpms but it'd be a useful > > > reduction and it would make the specfiles that much smaller, along with > > > the rpm headers. > > > > > > thoughts? > > > > It'd be interesting to see how much space something like this would save first. > > $ rpm -qa --changelog | wc -c > 11597562 > > That's just a little over 11 megabytes for all change logs on a FC3 > system. I've also got non-Core packages installed which would increase > that size slightly. That's also (obviously) including changelog entries > which would not be stripped. I'm just guessing here, but I suspect that > the total savings would be significantly smaller. I don't think the > effort or loss of history would really be worth it. > I'll backpedal and agree with you. 11 MB is very negligible when only concerned with the size of FC3. > -- > Shahms E. King > Multnomah ESD > > Public Key: > http://shahms.mesd.k12.or.us/~sking/shahms.asc > Fingerprint: > 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-devel-list > > > -- Nick Bargnesi http://www.den-4.com Den 4 Software pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0 sub 2048g/56C5D45B 2004-12-02 dd if=/dev/zero of=/dev/hda From feliciano.matias at free.fr Mon Jan 31 23:02:27 2005 From: feliciano.matias at free.fr (=?ISO-8859-1?Q?F=E9liciano?= Matias) Date: Tue, 01 Feb 2005 00:02:27 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107209076.5291.26.camel@opus.phy.duke.edu> References: <1107209076.5291.26.camel@opus.phy.duke.edu> Message-ID: <1107212547.17531.10.camel@one.myworld> Le lundi 31 janvier 2005 ? 17:04 -0500, seth vidal a ?crit : > Hi folks, > this is a touch silly but possibly useful and it would definitely cut > down on the old crap blocking up cdroms. > > how about if we kill all rpm spec file changelog entries OLDER than 2 > years. > > they'll still live on in older srpms and rpms but it'd be a useful > reduction and it would make the specfiles that much smaller, along with > the rpm headers. > > thoughts? > The "problem" I have about changelog is its duplications. [fmatias at one i386]$ rpm -q --changelog xorg-x11 | wc 5369 35773 250956 <= big changelog [fmatias at one i386]$ rpm -q -a | grep xorg-x11 | xargs rpm -q --changelog | wc 75166 500822 3513384 <= very very big changelog (several times the same changelog). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jspaleta at gmail.com Mon Jan 31 23:07:38 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 31 Jan 2005 18:07:38 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <20050131235826.A28641@xos037.xos.nl> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <41FEB198.7010706@nc.rr.com> <41FEB494.3030703@nc.rr.com> <20050131235826.A28641@xos037.xos.nl> Message-ID: <604aa7910501311507711f4e9a@mail.gmail.com> On Mon, 31 Jan 2005 23:58:26 +0100, Jos Vos wrote: > On Mon, Jan 31, 2005 at 05:43:32PM -0500, Jeff Johnson wrote: > > > So perhaps changelogs should be nuked entirely, and handled ouside of > > package content, instead. > > Why not just removing the changelog from the rpm header and having them > only accessible via the spec file in the src.rpm. There it is useful > for packagers (inside and outside RH) and doesn't bother "normal users". and prevents duplication of the changelog across all the binary subpackages from the same srpm, which F?liciano Matias brings up in this thread. Hmmm.... i think i like this. -jef From enrico.scholz at informatik.tu-chemnitz.de Mon Jan 31 23:28:03 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Tue, 01 Feb 2005 00:28:03 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107212145.30653.174.camel@shahms.mesd.k12.or.us> (Shahms King's message of "Mon, 31 Jan 2005 14:55:45 -0800") References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107212145.30653.174.camel@shahms.mesd.k12.or.us> Message-ID: <87mzupch6k.fsf@kosh.ultra.csn.tu-chemnitz.de> shahms at shahms.com (Shahms King) writes: >> [... removal of %changelog from rpms ...] >> It'd be interesting to see how much space something like this would save first. > > $ rpm -qa --changelog | wc -c > 11597562 As they are stored compressed, it is much less: | $ rpm -qpC --nodigest --nosignature *.rpm |LANG=C wc | 511863 2364195 15619260 | $ rpm -qpC --nodigest --nosignature *.rpm | gzip -9 - | LANG=C wc | 12338 67545 3136942 | $ rpm -qpC --nodigest --nosignature *.rpm | bzip2 -9 - | LANG=C wc | 6339 37933 1813872 (FC3 binaries rpms). All this discussion because of 2-3 MB additional space? Enrico From n3npq at nc.rr.com Mon Jan 31 23:32:16 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 31 Jan 2005 18:32:16 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <87mzupch6k.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107212145.30653.174.camel@shahms.mesd.k12.or.us> <87mzupch6k.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <41FEC000.2010406@nc.rr.com> Enrico Scholz wrote: >shahms at shahms.com (Shahms King) writes: > > > >>>[... removal of %changelog from rpms ...] >>>It'd be interesting to see how much space something like this would save first. >>> >>> >>$ rpm -qa --changelog | wc -c >>11597562 >> >> > >As they are stored compressed, it is much less: > Headers are compressed only in yum-2.0.x archives, no place else, certainly not *.rpm files nor in /var/lib/rpm/Packages nor in any transaction set memory. > >| $ rpm -qpC --nodigest --nosignature *.rpm |LANG=C wc >| 511863 2364195 15619260 > >| $ rpm -qpC --nodigest --nosignature *.rpm | gzip -9 - | LANG=C wc >| 12338 67545 3136942 > >| $ rpm -qpC --nodigest --nosignature *.rpm | bzip2 -9 - | LANG=C wc >| 6339 37933 1813872 > >(FC3 binaries rpms). > > >All this discussion because of 2-3 MB additional space? > > > Yep, with the correction above. 73 de Jeff From n3npq at nc.rr.com Mon Jan 31 23:47:56 2005 From: n3npq at nc.rr.com (Jeff Johnson) Date: Mon, 31 Jan 2005 18:47:56 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <87mzupch6k.fsf@kosh.ultra.csn.tu-chemnitz.de> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107212145.30653.174.camel@shahms.mesd.k12.or.us> <87mzupch6k.fsf@kosh.ultra.csn.tu-chemnitz.de> Message-ID: <41FEC3AC.10306@nc.rr.com> Enrico Scholz wrote: >shahms at shahms.com (Shahms King) writes: > > > >>>[... removal of %changelog from rpms ...] >>>It'd be interesting to see how much space something like this would save first. >>> >>> >>$ rpm -qa --changelog | wc -c >>11597562 >> >> > >As they are stored compressed, it is much less: > >| $ rpm -qpC --nodigest --nosignature *.rpm |LANG=C wc >| 511863 2364195 15619260 > >| $ rpm -qpC --nodigest --nosignature *.rpm | gzip -9 - | LANG=C wc >| 12338 67545 3136942 > >| $ rpm -qpC --nodigest --nosignature *.rpm | bzip2 -9 - | LANG=C wc >| 6339 37933 1813872 > >(FC3 binaries rpms). > > >All this discussion because of 2-3 MB additional space? > > > Um, you might try --changelog instead: $ rpm --help | grep changelog --changelog list change logs for this package 73 de Jeff From otaylor at redhat.com Mon Jan 31 23:45:23 2005 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 31 Jan 2005 18:45:23 -0500 Subject: radical suggestion for fc4 release In-Reply-To: <1107209076.5291.26.camel@opus.phy.duke.edu> References: <1107209076.5291.26.camel@opus.phy.duke.edu> Message-ID: <1107215124.21178.41.camel@localhost.localdomain> On Mon, 2005-01-31 at 17:04 -0500, seth vidal wrote: > Hi folks, > this is a touch silly but possibly useful and it would definitely cut > down on the old crap blocking up cdroms. > > how about if we kill all rpm spec file changelog entries OLDER than 2 > years. > > they'll still live on in older srpms and rpms but it'd be a useful > reduction and it would make the specfiles that much smaller, along with > the rpm headers. I like having the full changelogs in the spec files. Perhaps with the new CVS setup we could switch to having external changelogs and the same benefits.I wouldn't like to just go through all the packages and lop them off. But I'd agree that shipping the whole changelog in the RPM header is silly. I wonder if it's possible to strip all but the last 10 entries / 6 months (whichever is more) as part of the build process? Regards, Owen I'm always a vaguely amused by the gtk2 changelog ... it has 630 lines of %changelog over 7 years, and finishes with: * Thu Mar 12 1998 Marc Ewing - Reworked to integrate into gtk+ source tree - Truncated ChangeLog. Previous Authors: Trond Eivind Glomsrod Michael K. Johnson Otto Hammersmith It can't have been more than 50 lines long at that point. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ziga.mahkovec at klika.si Mon Jan 31 23:59:53 2005 From: ziga.mahkovec at klika.si (Ziga Mahkovec) Date: Tue, 01 Feb 2005 00:59:53 +0100 Subject: radical suggestion for fc4 release In-Reply-To: <1107212145.30653.174.camel@shahms.mesd.k12.or.us> References: <1107209076.5291.26.camel@opus.phy.duke.edu> <3077b8a00501311434a00e0f4@mail.gmail.com> <1107212145.30653.174.camel@shahms.mesd.k12.or.us> Message-ID: <1107215993.14233.5.camel@serenity.klika.si> On Mon, 2005-01-31 at 14:55 -0800, Shahms King wrote: > On Mon, 2005-01-31 at 17:34 -0500, Nick Bargnesi wrote: > > It'd be interesting to see how much space something like this would save first. > > $ rpm -qa --changelog | wc -c > 11597562 > > That's just a little over 11 megabytes for all change logs on a FC3 > system. I've also got non-Core packages installed which would increase > that size slightly. That's also (obviously) including changelog entries > which would not be stripped. I'm just guessing here, but I suspect that > the total savings would be significantly smaller. I don't think the > effort or loss of history would really be worth it. For sake of completeness: $ rpm -qa --changelog | LANG=C wc 246340 1183597 7835570 $ rpm -qa --changelog | sed -n '/^* .\+ 200[45]/,/^* .\+ 200[0-3]/p' | LANG=C wc 63836 321574 2182535 The thing that fascinates me though: $ rpm -qa --changelog | grep -ic "To be, or not to be" 0 -- Ziga From jwz at dnalounge.com Fri Jan 28 06:21:58 2005 From: jwz at dnalounge.com (Jamie Zawinski) Date: Fri, 28 Jan 2005 06:21:58 -0000 Subject: grip being removed [Re: rawhide report: 20050120 changes] References: <1106333362.3427.19.camel@localhost.localdomain> <87d5vtrzem.fsf@kosh.ultra.csn.tu-chemnitz.de> <1106689480.3393.0.camel@localhost.localdomain> <41F6C238.2050201@c-note.dk> <41F8B7F8.1000304@pvv.org> <41F912D7.5080104@tlarson.com> <604aa7910501270826672dcfb9@mail.gmail.com> <20050127163855.GB5263@rogers.com> <604aa79105012710144dd061ee@mail.gmail.com> <41F9A7C5.6050200@tlarson.com> <604aa791050127190670b45173@mail.gmail.com> <1106883041.5134.40.camel@trevally.redfishdemo.com> Message-ID: <41F9D9F9.7F27132C@dnalounge.com> > How about more avid xmms users in this discussion give bmp > a try and see if its good enough replacement. I'd characterize myself as a "resigned" XMMS user rather than an "avid" XMMS user, but I do use it. I think its UI sucks, but I find that it works. So I tried out BMP, and got nowhere. 1) The fact that it does not have a "double size" option is pretty much a showstopper, because I can't read a damned thing on that sub-postage-stamp-sized window. 2) Perhaps I could fix this by wasting hours finding a less horrid theme to use but A) in five minutes of clicking and googling, I didn't see any easy-to-find collection of BMP themes, and B) I'd really really rather claw out my eyes than dig through those anyway. (Can someone recommend one that isn't totally 'l33t and awful?) 3) and this may be related to "1: can't read the window", I couldn't figure out how to play an Icecast stream at all. xmms has "Play Location" on the menu, BMP does not. Perhaps if I could read the window, the answer would be obvious, but I can't so it's not. 4) "BMP" is a monumentally stupid name (hey, let's name the MP3 player "JPEG"!) and "beep-media-player" is both dumb and too much typing. So then I tried Totem, and it suffers from the canonical Red Hat braindamage of "oh, you haven't installed the mystery secret MP3 plugin, and no, I won't even hint to you where to find it." Frankly, I can't be bothered to go on this snark hunt again, I've done that enough times. So, I'd be thrilled to try out an alternative MP3 player to XMMS, just as soon as someone can point me to one that actually plays MP3s! -- Jamie Zawinski jwz at jwz.org http://www.jwz.org/ jwz at dnalounge.com http://www.dnalounge.com/ http://jwz.livejournal.com/ From laroche at redhat.com Sat Jan 29 13:49:15 2005 From: laroche at redhat.com (Florian La Roche) Date: Sat, 29 Jan 2005 13:49:15 -0000 Subject: binary rpm package checking Message-ID: <20050129142150.GA8208@dudweiler.stuttgart.redhat.com> This is a start to check binary rpm packages for consistency. Right now mostly the rpm header is checked to get a feeling how much "strange" binary rpm packages might be out there. It has two modes of checking, one for the current Fedora Development tree with more strict checks and a more relaxed one that should work for all existing rpm packages, also other distributions. I'd be interested to get feedback on what output is generated for rpm addon expositories and non - Red Hat distributions if the script generates warning messages. At least for Fedora Core only very few rpm tags are actually used in the rpm header. Examples usage: ./pyrpm.py --strict /mirror/fedora/development/i386/Fedora/RPMS/*.rpm Checking all rpms: locate .rpm | xargs ./pyrpm.py find /mirror/linux -name "*.rpm" -type f -print0 2>/dev/null | xargs -0 ./pyrpm.py greetings, Florian La Roche -------------- next part -------------- #!/usr/bin/python #!/usr/bin/python2.2 # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU Library General Public License as published by # the Free Software Foundation; version 2 only # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU Library General Public License for more details. # # You should have received a copy of the GNU Library General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # Copyright 2004 Red Hat, Inc. # # Author: Paul Nasrat, Florian La Roche # import rpmconstants, cpio, os.path import sys, getopt, gzip, cStringIO from types import StringType, IntType, ListType from struct import unpack rpmtag = rpmconstants.rpmtag rpmsigtag = rpmconstants.rpmsigtag RPM_CHAR = rpmconstants.RPM_CHAR RPM_INT8 = rpmconstants.RPM_INT8 RPM_INT16 = rpmconstants.RPM_INT16 RPM_INT32 = rpmconstants.RPM_INT32 RPM_INT64 = rpmconstants.RPM_INT64 RPM_STRING = rpmconstants.RPM_STRING RPM_BIN = rpmconstants.RPM_BIN RPM_STRING_ARRAY = rpmconstants.RPM_STRING_ARRAY RPM_I18NSTRING = rpmconstants.RPM_I18NSTRING RPM_ARGSTRING = rpmconstants.RPM_ARGSTRING # limit: does not support all RHL5.x and earlier rpms if verify is enabled class ReadRpm: def __init__(self, filename, verify=None, fd=None, hdronly=None, legacy=1): self.filename = filename self.issrc = 0 if filename[-8:] == ".src.rpm" or filename[-10:] == ".nosrc.rpm": self.issrc = 1 self.verify = verify # enable/disable more data checking self.fd = fd # filedescriptor self.hdronly = hdronly # if only the header is present from a hdlist # 1 == check if legacy tags are included, 0 allows more old tags # 1 is good for Fedora Core development trees self.legacy = legacy def printErr(self, err): print "%s: %s" % (self.filename, err) def raiseErr(self, err): raise ValueError, "%s: %s" % (self.filename, err) def openFd(self, offset=None): if not self.fd: try: self.fd = open(self.filename, "ro") except: self.printErr("could not open file") return 1 if offset: self.fd.seek(offset, 1) return None def closeFd(self): self.fd = None def __repr__(self): return self.hdr.__repr__() def __getitem__(self, key): try: if isinstance(key, StringType): return self.hdr[rpmtag[key][0]] if isinstance(key, IntType): return self.hdr[key] # trick to also look at the sig header if isinstance(key, ListType): if isinstance(key[0], StringType): return self.sig[rpmsigtag[key[0]][0]] return self.sig[key[0]] self.raiseErr("wrong arg") except: # XXX: try to catch wrong/misspelled keys here? return None def parseLead(self, leaddata): (magic, major, minor, rpmtype, arch, name, osnum, sigtype) = \ unpack("!4scchh66shh16x", leaddata) failed = None if self.verify: if major not in ('\x03', '\x04') or minor != '\x00' or \ sigtype != 5 or rpmtype not in (0, 1): failed = 1 if osnum not in (1, 255, 256): failed = 1 name = name.rstrip('\x00') if self.legacy: if os.path.basename(self.filename)[:len(name)] != name: failed = 1 if failed: print major, minor, rpmtype, arch, name, osnum, sigtype self.raiseErr("wrong data in rpm lead") return (magic, major, minor, rpmtype, arch, name, osnum, sigtype) def verifyTag(self, index, fmt, issig): (tag, ttype, offset, count) = index if issig: if not rpmsigtag.has_key(tag): self.printErr("rpmsigtag has no tag %d" % tag) else: t = rpmsigtag[tag] if t[1] != None and t[1] != ttype: self.printErr("sigtag %d has wrong type %d" % (tag, ttype)) if t[2] != None and t[2] != count: self.printErr("sigtag %d has wrong count %d" % (tag, count)) if (t[3] & 1) and self.legacy: self.printErr("tag %d is marked legacy" % tag) if self.issrc: if (t[3] & 4): self.printErr("tag %d should be for binary rpms" % tag) else: if (t[3] & 2): self.printErr("tag %d should be for src rpms" % tag) else: if not rpmtag.has_key(tag): self.printErr("rpmtag has no tag %d" % tag) else: t = rpmtag[tag] if t[1] != None and t[1] != ttype: if t[1] == RPM_ARGSTRING and (ttype == RPM_STRING or \ ttype == RPM_STRING_ARRAY): pass # special exception case elif t[0] == rpmconstants.RPMTAG_GROUP and \ ttype == RPM_STRING: # XXX hardcoded exception pass else: self.printErr("tag %d has wrong type %d" % (tag, ttype)) if t[2] != None and t[2] != count: self.printErr("tag %d has wrong count %d" % (tag, count)) if (t[3] & 1) and self.legacy: self.printErr("tag %d is marked legacy" % tag) if self.issrc: if (t[3] & 4): self.printErr("tag %d should be for binary rpms" % tag) else: if (t[3] & 2): self.printErr("tag %d should be for src rpms" % tag) if count == 0: self.raiseErr("zero length tag") if ttype < 1 or ttype > 9: self.raiseErr("unknown rpmtype %d" % ttype) if ttype == RPM_INT32: count = count * 4 elif ttype == RPM_STRING_ARRAY or \ ttype == RPM_I18NSTRING: size = 0 for i in xrange(0, count): end = fmt.index('\x00', offset) + 1 size += end - offset offset = end count = size elif ttype == RPM_STRING: if count != 1: self.raiseErr("tag string count wrong") count = fmt.index('\x00', offset) - offset + 1 elif ttype == RPM_CHAR or ttype == RPM_INT8: pass elif ttype == RPM_INT16: count = count * 2 elif ttype == RPM_INT64: count = count * 8 elif ttype == RPM_BIN: pass else: self.raiseErr("unknown tag header") return count def verifyIndex(self, fmt, fmt2, indexNo, storeSize, issig): checkSize = 0 for i in xrange(0, indexNo * 16, 16): index = unpack("!iiii", fmt[i:i + 16]) ttype = index[1] # alignment for some types of data if ttype == RPM_INT16: checkSize += (2 - (checkSize % 2)) % 2 elif ttype == RPM_INT32: checkSize += (4 - (checkSize % 4)) % 4 elif ttype == RPM_INT64: checkSize += (8 - (checkSize % 8)) % 8 checkSize += self.verifyTag(index, fmt2, issig) if checkSize != storeSize: # XXX: add a check for very old rpm versions here, seems this # is triggered for a few RHL5.x rpm packages self.printErr("storeSize/checkSize is %d/%d" % (storeSize, checkSize)) def readIndex(self, pad, issig=None): data = self.fd.read(16) if not len(data): return None (magic, indexNo, storeSize) = unpack("!8sii", data) if magic != "\x8e\xad\xe8\x01\x00\x00\x00\x00" or indexNo < 1: self.raiseErr("bad index magic") fmt = self.fd.read(16 * indexNo) fmt2 = self.fd.read(storeSize) padfmt = "" if pad != 1: padfmt = self.fd.read((pad - (storeSize % pad)) % pad) if self.verify: self.verifyIndex(fmt, fmt2, indexNo, storeSize, issig) return (indexNo, storeSize, data, fmt, fmt2, 16 + len(fmt) + \ len(fmt2) + len(padfmt)) def parseTag(self, index, fmt): (tag, ttype, offset, count) = index if ttype == RPM_INT32: return unpack("!%dI" % count, fmt[offset:offset + count * 4]) elif ttype == RPM_STRING_ARRAY or ttype == RPM_I18NSTRING: data = [] for i in xrange(0, count): end = fmt.index('\x00', offset) data.append(fmt[offset:end]) offset = end + 1 return data elif ttype == RPM_STRING: return fmt[offset:fmt.index('\x00', offset)] elif ttype == RPM_CHAR: return unpack("!%dc" % count, fmt[offset:offset + count]) elif ttype == RPM_INT8: return unpack("!%dB" % count, fmt[offset:offset + count]) elif ttype == RPM_INT16: return unpack("!%dH" % count, fmt[offset:offset + count * 2]) elif ttype == RPM_INT64: return unpack("!%dQ" % count, fmt[offset:offset + count * 8]) elif ttype == RPM_BIN: return fmt[offset:offset + count] self.raiseErr("unknown tag header") return None def parseIndex(self, indexNo, fmt, fmt2, tags=None): # XXX parseIndex() should be implemented as C function for faster speed hdr = {} hdrtype = {} for i in xrange(0, indexNo * 16, 16): index = unpack("!4i", fmt[i:i + 16]) tag = index[0] # support reading only some tags if tags and tag not in tags: continue # ignore duplicate entries as long as they are identical if hdr.has_key(tag): if hdr[tag] != self.parseTag(index, fmt2): self.printErr("tag %d included twice" % tag) else: hdr[tag] = self.parseTag(index, fmt2) hdrtype[tag] = index[1] return (hdr, hdrtype) def verifyHeader(self): if self.hdronly: return #self.cpiosize = self[["payloadsize"]][0] # header + payload size self.payloadsize = self[["size_in_sig"]][0] - self.hdrdata[5] identifysig = self[["header_signatures"]] sha1 = self[["sha1header"]] # header md5sum = self[["md5"]] # header + payload dsa = self[["dsaheader"]] # header gpg = self[["gpg"]] # header + payload def parseHeader(self, tags=None, parsesig=None): if (self.verify or parsesig) and not self.hdronly: (sigindexNo, sigstoreSize, sigdata, sigfmt, sigfmt2, size) = \ self.sigdata (self.sig, self.sigtype) = self.parseIndex(sigindexNo, sigfmt, \ sigfmt2) if self.verify: for i in rpmconstants.rpmsigtagrequired: if not self.sig.has_key(i): self.printErr("sig header is missing: %d" % i) (hdrindexNo, hdrstoreSize, hdrdata, hdrfmt, hdrfmt2, size) = \ self.hdrdata (self.hdr, self.hdrtype) = self.parseIndex(hdrindexNo, hdrfmt, \ hdrfmt2, tags) if self.verify: for i in rpmconstants.rpmtagrequired: if not self.hdr.has_key(i): self.printErr("hdr is missing: %d" % i) self.verifyHeader() def readHeader(self, parse=1, tags=None, keepdata=None): if self.openFd(): return 1 leaddata = self.fd.read(96) if leaddata[:4] != '\xed\xab\xee\xdb': self.printErr("no rpm magic found") return 1 if self.verify: self.parseLead(leaddata) self.sigdata = self.readIndex(8, 1) self.hdrdata = self.readIndex(1) if keepdata: self.leaddata = leaddata if parse: self.parseHeader(tags) return None def readHdlist(self, parse=1, tags=None): self.hdrdata = self.readIndex(1) if not self.hdrdata: return None if parse: self.parseHeader(tags) return 1 def readPayload(self, keepdata=None, verbose=None): self.openFd(96 + self.sigdata[5] + self.hdrdata[5]) if None: #import zlib payload = self.fd.read() if self.verify and self.payloadsize != len(payload): self.raiseErr("payloadsize") if payload[:9] != '\037\213\010\000\000\000\000\000\000': self.raiseErr("not gzipped data") #cpiodata = zlib.decompress(payload) return None else: gz = gzip.GzipFile(fileobj=self.fd) cpiodata = gz.read() #while 1: # buf = gz.read(4096) # if not buf: # break if self.verify and self.cpiosize != len(cpiodata): self.raiseErr("cpiosize") if 1: c = cpio.CPIOFile(cStringIO.StringIO(cpiodata)) try: c.read() except IOError, e: print "Error reading CPIO payload: %s" % e if verbose: print c.namelist() self.closeFd() if keepdata: self.cpiodata = cpiodata if self.verify: return self.verifyPayload(c.namelist()) return None def verifyPayload(self, cpiofiletree=None): hdrfiletree = self.parseFilelist() if cpiofiletree == None: return 0 for filename in cpiofiletree.keys(): cpiostat = cpiofiletree[filename] if filename not in hdrfiletree.keys(): print "Error "+filename+" not in header tags" return 1 hdrstat = hdrfiletree[filename] if cpiostat[1] != hdrstat[1]: print "Error inode is different for file "+filename print cpiostat[1]+" != "+hdrstat[1] return 1 if cpiostat[2] != hdrstat[2]: print "Error mode is different for file "+filename print cpiostat[2]+" != "+hdrstat[2] return 1 # XXX: Need to convert hdr username and groupname to uid and gid # if cpiostat[3] != hdrstat[3]: # print "Error uid is different for file "+filename # print cpiostat[3]+" != "+hdrstat[3] # return 1 # if cpiostat[4] != hdrstat[4]: # print "Error gid is different for file "+filename # print cpiostat[4]+" != "+hdrstat[4] # return 1 # XXX: Leave that alone. Nlink is for hardlinks, not in rpm headers... # if hdrstat[5] != "" and cpiostat[5] != hdrstat[5]: # print "Error nlinks is different for file "+filename # print str(cpiostat[5])+" != "+hdrstat[5] # return 1 if cpiostat[6] != hdrstat[6]: print "Error filesize is different for file "+filename print cpiostat[6]+" != "+hdrstat[6] return 1 # XXX: Starting from entry 7 no entries are usable anymore, so leave them... return 0 def getScript(self, s, p): script = self[s] # prog can be a string or an string_array (with args to the app) prog = self[p] if script == None and prog == None: return (None, None) if self.verify: if script and prog == None: self.raiseErr("no prog") if self.legacy: if prog not in ("/bin/sh", "/sbin/ldconfig", "/usr/bin/fc-cache", "/usr/sbin/glibc_post_upgrade", "/usr/sbin/libgcc_post_upgrade", "/usr/sbin/glibc_post_upgrade.i386", "/usr/sbin/glibc_post_upgrade.i686", "/usr/sbin/build-locale-archive", "/usr/bin/scrollkeeper-update"): self.raiseErr("unknown prog: %s" % prog) return (script, prog) def getNVR(self): return "%s-%s-%s" % (self["name"], self["version"], self["release"]) def getNA(self): return "%s.%s" % (self["name"], self["arch"]) def getFilename(self): return "%s-%s-%s.%s.rpm" % (self["name"], self["version"], self["release"], self["arch"]) def getDeps(self, name, flags, version): n = self[name] if not n: return None f = self[flags] v = self[version] if f == None or v == None or len(n) != len(f) or len(f) != len(v): if f != None or v != None: self.raiseErr("wrong length of deps") deps = [] for i in xrange(0, len(n)): if f != None: deps.append( (n[i], f[i], v[i]) ) else: deps.append( (n[i], None, None) ) return deps def getProvides(self): return self.getDeps("providename", "provideflags", "provideversion") def getRequires(self): return self.getDeps("requirename", "requireflags", "requireversion") def getObsoletes(self): return self.getDeps("obsoletename", "obsoleteflags", "obsoleteversion") def getConflicts(self): return self.getDeps("conflictname", "conflictflags", "conflictversion") def getTriggers(self): return self.getDeps("triggername", "triggerflags", "triggerversion") def buildFileNames(self): """Returns (dir, filename, linksto, flags).""" if self["dirnames"] == None or self["dirindexes"] == None: return [] dirnames = [ self["dirnames"][index] for index in self["dirindexes"] ] return zip (dirnames, self["basenames"], self["fileflags"], self["fileinodes"], self["filemodes"], self["fileusername"], self["filegroupname"], self["filelinktos"], self["filemtimes"], self["filesizes"], self["filedevices"], self["filerdevs"], self["filelangs"], self["filemd5s"] ) def parseFilelist(self): fl = {} for perm in self.buildFileNames(): fl[perm[0] + perm[1]] = perm[2:] return fl class RRpm: def __init__(self, rpm): self.filename = rpm.filename self.name = rpm["name"] self.version = rpm["version"] self.release = rpm["release"] self.epoch = rpm["epoch"] if self.epoch: self.epoch = self.epoch[0] evr = str(self.epoch) + ":" + self.version + "-" + self.release else: evr = self.version + "-" + self.release self.dep = (self.name, rpmconstants.RPMSENSE_EQUAL, evr) self.arch = rpm["arch"] #self.hdrfiletree = rpm.parseFilelist() #self.filetree = rpm.buildFileNames() self.basenames = rpm["basenames"] self.dirnames = rpm["dirnames"] self.provides = rpm.getProvides() self.requires = rpm.getRequires() self.obsoletes = rpm.getObsoletes() self.conflicts = rpm.getConflicts() (self.pre, self.preprog) = rpm.getScript("prein", "preinprog") (self.post, self.postprog) = rpm.getScript("postin", "postinprog") (self.preun, self.preunprog) = rpm.getScript("preun", "preunprog") (self.postun, self.postunprog) = rpm.getScript("postun", "postunprog") (self.verify, self.verifyprog) = rpm.getScript("verifyscript", "verifyscriptprog") self.triggers = rpm.getTriggers() self.triggerindex = rpm["triggerindex"] self.trigger = rpm["triggerscripts"] self.triggerprog = rpm["triggerscriptprog"] # legacy: self.triggerin = rpm["triggerin"] self.triggerun = rpm["triggerun"] self.triggerpostun = rpm["triggerpostun"] if rpm.verify: self.doVerify(rpm) def doVerify(self, rpm): if self.trigger != None: if len(self.trigger) != len(self.triggerprog): raise ValueError, "wrong trigger lengths" if "-" in self.version: self.printErr("version contains wrong char") if rpm["payloadformat"] not in [None, "cpio"]: self.printErr("wrong payload format") if rpm.legacy: if rpm["payloadcompressor"] not in [None, "gzip"]: self.printErr("no gzip compressor: %s" % rpm["payloadcompressor"]) else: if rpm["payloadcompressor"] not in [None, "gzip", "bzip2"]: self.printErr("no gzip/bzip2 compressor: %s" % rpm["payloadcompressor"]) if rpm.legacy: if rpm["payloadflags"] not in ["9"]: self.printErr("no payload flags: %s" % rpm["payloadflags"]) if rpm["os"] not in ["Linux", "linux"]: self.printErr("bad os: %s" % rpm["os"]) if rpm.legacy: if rpm["packager"] not in (None, \ "Red Hat, Inc. "): self.printErr("unknown packager: %s" % rpm["packager"]) if rpm["vendor"] not in (None, "Red Hat, Inc."): self.printErr("unknown vendor: %s" % rpm["vendor"]) if rpm["distribution"] not in (None, "Red Hat Linux", "Red Hat FC-3", "Red Hat (FC-3)", "Red Hat (RHEL-3)", "Red Hat (FC-4)"): self.printErr("unknown distribution: %s" % rpm["distribution"]) if rpm["rhnplatform"] not in (None, self.arch): self.printErr("unknown arch for rhnplatform") if rpm.legacy: if rpm["platform"] not in (None, self.arch + "-redhat-linux-gnu", self.arch + "-redhat-linux", "--target=${target_platform}", self.arch + "-unknown-linux", "--target=${TARGET_PLATFORM}", "--target=$TARGET_PLATFORM", ""): self.printErr("unknown arch %s" % rpm["platform"]) if rpm["exclusiveos"] not in (None, ['Linux'], ['linux']): self.printErr("unknown os %s" % rpm["exclusiveos"]) if rpm.legacy: if rpm["buildarchs"] not in (None, ['noarch']): self.printErr("bad buildarch: %s" % rpm["buildarchs"]) if rpm["excludearch"] != None: for i in rpm["excludearch"]: if i not in rpmconstants.possible_archs: self.printErr("new possible arch %s" % i) if rpm["exclusivearch"] != None: for i in rpm["exclusivearch"]: if i not in rpmconstants.possible_archs: self.printErr("new possible arch %s" % i) def printErr(self, err): print "%s: %s" % (self.filename, err) def verifyRpm(filename, legacy=1, payload=None): """Read in a complete rpm and verify its integrity.""" rpm = ReadRpm(filename, 1, legacy=legacy) if rpm.readHeader(): return None if payload: rpm.readPayload() rpm.closeFd() return rpm def readHdlist(filename, verify=None): fd = open(filename, "ro") rpms = [] while 1: rpm = ReadRpm(filename, verify, fd, 1) if not rpm.readHdlist(): break rpms.append(rpm) return rpms def showHelp(): print "pyrpm [options] /path/to/foo.rpm" print print "options:" print "--help this message" print "--queryformat [queryformat] specifying a format to print the query as" print " see python String Formatting Operations for details" print def queryFormatUnescape(s): import re # Hack to emulate %{name} but not %%{name} and expand escapes rpmre = re.compile(r'([^%])%\{(\w+)\}') s = re.sub(rpmre, r'\1%(\2)s', s) s = s.replace("\\n","\n") s = s.replace("\\t","\t") s = s.replace('\\"', '\"') s = s.replace('\\v','\v') s = s.replace('\\r','\r') return s def main(args): queryformat="%(name)s-%(version)s-%(release)s\n" try: opts, args = getopt.getopt(args, "hq", ["help", "queryformat="]) except getopt.error, e: print "Error parsing command list arguments: %s" % e showHelp() sys.exit(1) for (opt, val) in opts: if opt in ["-h", "--help"]: showHelp() sys.exit(1) if opt in ['-c', "--queryformat"]: queryformat = val if not args: print "Error no packages to query" showHelp() sys.exit(1) queryformat = queryFormatUnescape(queryformat) for a in args: rpm = verifyRpm(a) sys.stdout.write(queryformat % rpm) def verifyAllRpms(): #import time #repo = [] args = sys.argv[1:] legacy = 0 if args[0] == "--strict": legacy = 1 args = args[1:] for a in args: rpm = verifyRpm(a, legacy) if rpm != None: #f = rpm["optflags"] #if f: # print rpm.getFilename() # print f rrpm = RRpm(rpm) #repo.append(rrpm) #print "ready" #time.sleep(30) if __name__ == "__main__": if None: rpms = readHdlist("/home/fedora/i386/Fedora/base/hdlist", 1) for rpm in rpms: print rpm.getFilename() rpms = readHdlist("/home/fedora/i386/Fedora/base/hdlist2", 1) sys.exit(0) if 1: verifyAllRpms() sys.exit(0) main(sys.argv[1:]) # vim:ts=4:sw=4:showmatch:expandtab -------------- next part -------------- #!/usr/bin/python # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU Library General Public License as published by # the Free Software Foundation; version 2 only # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU Library General Public License for more details. # # You should have received a copy of the GNU Library General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # Copyright 2004 Red Hat, Inc. # # Author: Florian La Roche # # RPM Constants - based from rpmlib.h and elsewhere # rpm tag types #RPM_NULL = 0 RPM_CHAR = 1 RPM_INT8 = 2 RPM_INT16 = 3 RPM_INT32 = 4 RPM_INT64 = 5 # currently unused RPM_STRING = 6 RPM_BIN = 7 RPM_STRING_ARRAY = 8 RPM_I18NSTRING = 9 # new type internal to this tool: # STRING_ARRAY for app + params or STRING otherwise RPM_ARGSTRING = 12 # header private tags HEADER_IMAGE = 61 HEADER_SIGNATURES = 62 # starts a header with signatures HEADER_IMMUTABLE = 63 # starts a header with other rpm tags HEADER_REGIONS = 64 HEADER_I18NTABLE = 100 HEADER_SIGBASE = 256 # starting tag for sig information HEADER_TAGBASE = 1000 # starting tag for other rpm tags # RPM header tags RPMTAG_HEADERIMAGE = HEADER_IMAGE RPMTAG_HEADERSIGNATURES = HEADER_SIGNATURES RPMTAG_HEADERIMMUTABLE = HEADER_IMMUTABLE RPMTAG_HEADERREGIONS = HEADER_REGIONS RPMTAG_HEADERI18NTABLE = HEADER_I18NTABLE RPMTAG_SIG_BASE = HEADER_SIGBASE RPMTAG_SIGSIZE = RPMTAG_SIG_BASE+1 RPMTAG_SIGLEMD5_1 = RPMTAG_SIG_BASE+2 RPMTAG_SIGPGP = RPMTAG_SIG_BASE+3 RPMTAG_SIGLEMD5_2 = RPMTAG_SIG_BASE+4 RPMTAG_SIGMD5 = RPMTAG_SIG_BASE+5 RPMTAG_SIGGPG = RPMTAG_SIG_BASE+6 RPMTAG_SIGPGP5 = RPMTAG_SIG_BASE+7 RPMTAG_BADSHA1_1 = RPMTAG_SIG_BASE+8 RPMTAG_BADSHA1_2 = RPMTAG_SIG_BASE+9 RPMTAG_PUBKEYS = RPMTAG_SIG_BASE+10 RPMTAG_DSAHEADER = RPMTAG_SIG_BASE+11 RPMTAG_RSAHEADER = RPMTAG_SIG_BASE+12 RPMTAG_SHA1HEADER = RPMTAG_SIG_BASE+13 RPMSIGTAG_SIZE = 1000 RPMSIGTAG_LEMD5_1 = 1001 RPMSIGTAG_PGP = 1002 RPMSIGTAG_LEMD5_2 = 1002 RPMSIGTAG_MD5 = 1004 RPMSIGTAG_GPG = 1005 RPMSIGTAG_PGP5 = 1006 RPMSIGTAG_PAYLOADSIZE = 1007 RPMTAG_NAME = 1000 RPMTAG_VERSION = 1001 RPMTAG_RELEASE = 1002 RPMTAG_EPOCH = 1003 RPMTAG_SUMMARY = 1004 RPMTAG_DESCRIPTION = 1005 RPMTAG_BUILDTIME = 1006 RPMTAG_BUILDHOST = 1007 RPMTAG_INSTALLTIME = 1008 RPMTAG_SIZE = 1009 RPMTAG_DISTRIBUTION = 1010 RPMTAG_VENDOR = 1011 RPMTAG_GIF = 1012 RPMTAG_XPM = 1013 RPMTAG_LICENSE = 1014 RPMTAG_PACKAGER = 1015 RPMTAG_GROUP = 1016 RPMTAG_CHANGELOG = 1017 RPMTAG_SOURCE = 1018 RPMTAG_PATCH = 1019 RPMTAG_URL = 1020 RPMTAG_OS = 1021 RPMTAG_ARCH = 1022 RPMTAG_PREIN = 1023 RPMTAG_POSTIN = 1024 RPMTAG_PREUN = 1025 RPMTAG_POSTUN = 1026 RPMTAG_OLDFILENAMES = 1027 RPMTAG_FILESIZES = 1028 RPMTAG_FILESTATES = 1029 RPMTAG_FILEMODES = 1030 RPMTAG_FILEUIDS = 1031 RPMTAG_FILEGIDS = 1032 RPMTAG_FILERDEVS = 1033 RPMTAG_FILEMTIMES = 1034 RPMTAG_FILEMD5S = 1035 RPMTAG_FILELINKTOS = 1036 RPMTAG_FILEFLAGS = 1037 RPMTAG_ROOT = 1038 RPMTAG_FILEUSERNAME = 1039 RPMTAG_FILEGROUPNAME = 1040 RPMTAG_EXCLUDE = 1041 RPMTAG_EXCLUSIVE = 1042 RPMTAG_ICON = 1043 RPMTAG_SOURCERPM = 1044 RPMTAG_FILEVERIFYFLAGS = 1045 RPMTAG_ARCHIVESIZE = 1046 RPMTAG_PROVIDENAME = 1047 RPMTAG_REQUIREFLAGS = 1048 RPMTAG_REQUIRENAME = 1049 RPMTAG_REQUIREVERSION = 1050 RPMTAG_NOSOURCE = 1051 RPMTAG_NOPATCH = 1052 RPMTAG_CONFLICTFLAGS = 1053 RPMTAG_CONFLICTNAME = 1054 RPMTAG_CONFLICTVERSION = 1055 RPMTAG_DEFAULTPREFIX = 1056 RPMTAG_BUILDROOT = 1057 RPMTAG_INSTALLPREFIX = 1058 RPMTAG_EXCLUDEARCH = 1059 RPMTAG_EXCLUDEOS = 1060 RPMTAG_EXCLUSIVEARCH = 1061 RPMTAG_EXCLUSIVEOS = 1062 RPMTAG_AUTOREQPROV = 1063 RPMTAG_RPMVERSION = 1064 RPMTAG_TRIGGERSCRIPTS = 1065 RPMTAG_TRIGGERNAME = 1066 RPMTAG_TRIGGERVERSION = 1067 RPMTAG_TRIGGERFLAGS = 1068 RPMTAG_TRIGGERINDEX = 1069 RPMTAG_VERIFYSCRIPT = 1079 RPMTAG_VERIFYSCRIPT2 = 15 RPMTAG_CHANGELOGTIME = 1080 RPMTAG_CHANGELOGNAME = 1081 RPMTAG_CHANGELOGTEXT = 1082 RPMTAG_BROKENMD5 = 1083 RPMTAG_PREREQ = 1084 RPMTAG_PREINPROG = 1085 RPMTAG_POSTINPROG = 1086 RPMTAG_PREUNPROG = 1087 RPMTAG_POSTUNPROG = 1088 RPMTAG_BUILDARCHS = 1089 RPMTAG_OBSOLETENAME = 1090 RPMTAG_VERIFYSCRIPTPROG = 1091 RPMTAG_TRIGGERSCRIPTPROG = 1092 RPMTAG_DOCDIR = 1093 RPMTAG_COOKIE = 1094 RPMTAG_FILEDEVICES = 1095 RPMTAG_FILEINODES = 1096 RPMTAG_FILELANGS = 1097 RPMTAG_PREFIXES = 1098 RPMTAG_INSTPREFIXES = 1099 RPMTAG_TRIGGERIN = 1100 RPMTAG_TRIGGERUN = 1101 RPMTAG_TRIGGERPOSTUN = 1102 RPMTAG_AUTOREQ = 1103 RPMTAG_AUTOPROV = 1104 RPMTAG_CAPABILITY = 1105 RPMTAG_SOURCEPACKAGE = 1106 RPMTAG_OLDORIGFILENAMES = 1107 RPMTAG_BUILDPREREQ = 1108 RPMTAG_BUILDREQUIRES = 1109 RPMTAG_BUILDCONFLICTS = 1110 RPMTAG_BUILDMACROS = 1111 RPMTAG_PROVIDEFLAGS = 1112 RPMTAG_PROVIDEVERSION = 1113 RPMTAG_OBSOLETEFLAGS = 1114 RPMTAG_OBSOLETEVERSION = 1115 RPMTAG_DIRINDEXES = 1116 RPMTAG_BASENAMES = 1117 RPMTAG_DIRNAMES = 1118 RPMTAG_ORIGDIRINDEXES = 1119 RPMTAG_ORIGBASENAMES = 1120 RPMTAG_ORIGDIRNAMES = 1121 RPMTAG_OPTFLAGS = 1122 RPMTAG_DISTURL = 1123 RPMTAG_PAYLOADFORMAT = 1124 RPMTAG_PAYLOADCOMPRESSOR = 1125 RPMTAG_PAYLOADFLAGS = 1126 RPMTAG_INSTALLCOLOR = 1127 RPMTAG_INSTALLTID = 1128 RPMTAG_REMOVETID = 1129 RPMTAG_SHA1RHN = 1130 RPMTAG_RHNPLATFORM = 1131 RPMTAG_PLATFORM = 1132 RPMTAG_PATCHESNAME = 1133 RPMTAG_PATCHESFLAGS = 1134 RPMTAG_PATCHESVERSION = 1135 RPMTAG_CACHECTIME = 1136 RPMTAG_CACHEPKGPATH = 1137 RPMTAG_CACHEPKGSIZE = 1138 RPMTAG_CACHEPKGMTIME = 1139 RPMTAG_FILECOLORS = 1140 RPMTAG_FILECLASS = 1141 RPMTAG_CLASSDICT = 1142 RPMTAG_FILEDEPENDSX = 1143 RPMTAG_FILEDEPENDSN = 1144 RPMTAG_DEPENDSDICT = 1145 RPMTAG_SOURCEPKGID = 1146 RPMTAG_FILECONTEXTS = 1147 RPMSIGTAG_BADSHA1_1 = RPMTAG_BADSHA1_1 RPMSIGTAG_BADSHA1_2 = RPMTAG_BADSHA1_2 RPMSIGTAG_SHA1 = RPMTAG_SHA1HEADER RPMSIGTAG_DSA = RPMTAG_DSAHEADER RPMSIGTAG_RSA = RPMTAG_RSAHEADER RPMTAG_DELTAHOFFSETORDER = 20001 # RPMTAG_NAME array RPMTAG_DELTAVERSION = 20002 # RPM_PROVIDEVERSION array RPMTAG_DELTAORIGSIGS = 20003 # BIN RPMTAG_DELTAHINDEXORDER = 20004 # RPMTAG_NAME array RPMTAG_DELTARAWPAYLOADXDELTA = 20005 # BIN RPMTAG_DELTAORIGPAYLOADFORMAT = 20006 # RPMTAG_PAYLOADFORMAT RPMTAG_DELTAFILEFLAGS = 20007 # INT16 array # XXX: TODO for possible rpm changes: # - arch should not be needed for src.rpms # - deps could be left away from src.rpms # - cookie could go away # - rhnplatform could go away # list of all rpm tags in Fedora Core development # tagname: (tag, type, how-many, flags:legacy=1,src-only=2,bin-only=4) rpmtag = { # basic info "name": (RPMTAG_NAME, RPM_STRING, None, 0), "epoch": (RPMTAG_EPOCH, RPM_INT32, 1, 0), "version": (RPMTAG_VERSION, RPM_STRING, None, 0), "release": (RPMTAG_RELEASE, RPM_STRING, None, 0), "arch": (RPMTAG_ARCH, RPM_STRING, None, 0), # dependencies: provides, requires, obsoletes, conflicts "providename": (RPMTAG_PROVIDENAME, RPM_STRING_ARRAY, None, 0), "provideflags": (RPMTAG_PROVIDEFLAGS, RPM_INT32, None, 0), "provideversion": (RPMTAG_PROVIDEVERSION, RPM_STRING_ARRAY, None, 0), "requirename": (RPMTAG_REQUIRENAME, RPM_STRING_ARRAY, None, 0), "requireflags": (RPMTAG_REQUIREFLAGS, RPM_INT32, None, 0), "requireversion": (RPMTAG_REQUIREVERSION, RPM_STRING_ARRAY, None, 0), "obsoletename": (RPMTAG_OBSOLETENAME, RPM_STRING_ARRAY, None, 4), "obsoleteflags": (RPMTAG_OBSOLETEFLAGS, RPM_INT32, None, 4), "obsoleteversion": (RPMTAG_OBSOLETEVERSION, RPM_STRING_ARRAY, None, 4), "conflictname": (RPMTAG_CONFLICTNAME, RPM_STRING_ARRAY, None, 0), "conflictflags": (RPMTAG_CONFLICTFLAGS, RPM_INT32, None, 0), "conflictversion": (RPMTAG_CONFLICTVERSION, RPM_STRING_ARRAY, None, 0), # triggers "triggername": (RPMTAG_TRIGGERNAME, RPM_STRING_ARRAY, None, 4), "triggerflags": (RPMTAG_TRIGGERFLAGS, RPM_INT32, None, 4), "triggerversion": (RPMTAG_TRIGGERVERSION, RPM_STRING_ARRAY, None, 4), "triggerscripts": (RPMTAG_TRIGGERSCRIPTS, RPM_STRING_ARRAY, None, 4), "triggerscriptprog": (RPMTAG_TRIGGERSCRIPTPROG, RPM_STRING_ARRAY, None, 4), "triggerindex": (RPMTAG_TRIGGERINDEX, RPM_INT32, None, 4), # scripts "prein": (RPMTAG_PREIN, RPM_STRING, None, 4), "preinprog": (RPMTAG_PREINPROG, RPM_ARGSTRING, None, 4), "postin": (RPMTAG_POSTIN, RPM_STRING, None, 4), "postinprog": (RPMTAG_POSTINPROG, RPM_ARGSTRING, None, 4), "preun": (RPMTAG_PREUN, RPM_STRING, None, 4), "preunprog": (RPMTAG_PREUNPROG, RPM_ARGSTRING, None, 4), "postun": (RPMTAG_POSTUN, RPM_STRING, None, 4), "postunprog": (RPMTAG_POSTUNPROG, RPM_ARGSTRING, None, 4), "verifyscript": (RPMTAG_VERIFYSCRIPT, RPM_STRING, None, 4), "verifyscriptprog": (RPMTAG_VERIFYSCRIPTPROG, RPM_ARGSTRING, None, 4), # addon information: # list of available languages "i18ntable": (HEADER_I18NTABLE, RPM_STRING_ARRAY, None, 0), "summary": (RPMTAG_SUMMARY, RPM_I18NSTRING, None, 0), "description": (RPMTAG_DESCRIPTION, RPM_I18NSTRING, None, 0), "url": (RPMTAG_URL, RPM_STRING, None, 0), "license": (RPMTAG_LICENSE, RPM_STRING, None, 0), "rpmversion": (RPMTAG_RPMVERSION, RPM_STRING, None, 0), "sourcerpm": (RPMTAG_SOURCERPM, RPM_STRING, None, 4), "changelogtime": (RPMTAG_CHANGELOGTIME, RPM_INT32, None, 0), "changelogname": (RPMTAG_CHANGELOGNAME, RPM_STRING_ARRAY, None, 0), "changelogtext": (RPMTAG_CHANGELOGTEXT, RPM_STRING_ARRAY, None, 0), # relocatable rpm packages "prefixes": (RPMTAG_PREFIXES, RPM_STRING_ARRAY, None, 4), # optimization flags for gcc "optflags": (RPMTAG_OPTFLAGS, RPM_STRING, None, 4), # %pubkey in .spec files "pubkeys": (RPMTAG_PUBKEYS, RPM_STRING_ARRAY, None, 4), "sourcepkgid": (RPMTAG_SOURCEPKGID, RPM_BIN, 16, 4), # XXX "immutable": (RPMTAG_HEADERIMMUTABLE, RPM_BIN, 16, 0), # XXX # less important information: # time of rpm build "buildtime": (RPMTAG_BUILDTIME, RPM_INT32, 1, 0), # hostname where rpm was built "buildhost": (RPMTAG_BUILDHOST, RPM_STRING, None, 0), "cookie": (RPMTAG_COOKIE, RPM_STRING, None, 0), # build host and time # ignored now, succ is comps.xml # XXX code allows hardcoded exception to also have type RPM_STRING # for RPMTAG_GROUP "group": (RPMTAG_GROUP, RPM_I18NSTRING, None, 0), "size": (RPMTAG_SIZE, RPM_INT32, 1, 0), # sum of all file sizes "distribution": (RPMTAG_DISTRIBUTION, RPM_STRING, None, 0), "vendor": (RPMTAG_VENDOR, RPM_STRING, None, 0), "packager": (RPMTAG_PACKAGER, RPM_STRING, None, 0), "os": (RPMTAG_OS, RPM_STRING, None, 0), # always "linux" "payloadformat": (RPMTAG_PAYLOADFORMAT, RPM_STRING, None, 0), # "cpio" # "gzip" or "bzip2" "payloadcompressor": (RPMTAG_PAYLOADCOMPRESSOR, RPM_STRING, None, 0), "payloadflags": (RPMTAG_PAYLOADFLAGS, RPM_STRING, None, 0), # "9" "rhnplatform": (RPMTAG_RHNPLATFORM, RPM_STRING, None, 4), # == arch "platform": (RPMTAG_PLATFORM, RPM_STRING, None, 0), # source rpm packages: "source": (RPMTAG_SOURCE, RPM_STRING_ARRAY, None, 2), "patch": (RPMTAG_PATCH, RPM_STRING_ARRAY, None, 2), "buildarchs": (RPMTAG_BUILDARCHS, RPM_STRING_ARRAY, None, 2), "excludearch": (RPMTAG_EXCLUDEARCH, RPM_STRING_ARRAY, None, 2), "exclusivearch": (RPMTAG_EXCLUSIVEARCH, RPM_STRING_ARRAY, None, 2), # ['Linux'] or ['linux'] "exclusiveos": (RPMTAG_EXCLUSIVEOS, RPM_STRING_ARRAY, None, 2), # information about files "filesizes": (RPMTAG_FILESIZES, RPM_INT32, None, 0), "filemodes": (RPMTAG_FILEMODES, RPM_INT16, None, 0), "filerdevs": (RPMTAG_FILERDEVS, RPM_INT16, None, 0), "filemtimes": (RPMTAG_FILEMTIMES, RPM_INT32, None, 0), "filemd5s": (RPMTAG_FILEMD5S, RPM_STRING_ARRAY, None, 0), "filelinktos": (RPMTAG_FILELINKTOS, RPM_STRING_ARRAY, None, 0), "fileflags": (RPMTAG_FILEFLAGS, RPM_INT32, None, 0), "fileusername": (RPMTAG_FILEUSERNAME, RPM_STRING_ARRAY, None, 0), "filegroupname": (RPMTAG_FILEGROUPNAME, RPM_STRING_ARRAY, None, 0), "fileverifyflags": (RPMTAG_FILEVERIFYFLAGS, RPM_INT32, None, 0), "filedevices": (RPMTAG_FILEDEVICES, RPM_INT32, None, 0), "fileinodes": (RPMTAG_FILEINODES, RPM_INT32, None, 0), "filelangs": (RPMTAG_FILELANGS, RPM_STRING_ARRAY, None, 0), "dirindexes": (RPMTAG_DIRINDEXES, RPM_INT32, None, 0), "basenames": (RPMTAG_BASENAMES, RPM_STRING_ARRAY, None, 0), "dirnames": (RPMTAG_DIRNAMES, RPM_STRING_ARRAY, None, 0), "filecolors": (RPMTAG_FILECOLORS, RPM_INT32, None, 0), "fileclass": (RPMTAG_FILECLASS, RPM_INT32, None, 0), "classdict": (RPMTAG_CLASSDICT, RPM_STRING_ARRAY, None, 0), "filedependsx": (RPMTAG_FILEDEPENDSX, RPM_INT32, None, 0), "filedependsn": (RPMTAG_FILEDEPENDSN, RPM_INT32, None, 0), "dependsdict": (RPMTAG_DEPENDSDICT, RPM_INT32, None, 0), # legacy additions: # selinux filecontexts "filecontexts": (RPMTAG_FILECONTEXTS, RPM_STRING_ARRAY, None, 1), "archivesize": (RPMTAG_ARCHIVESIZE, RPM_INT32, 1, 1), "capability": (RPMTAG_CAPABILITY, RPM_INT32, None, 1), "xpm": (RPMTAG_XPM, RPM_BIN, None, 1), "gif": (RPMTAG_GIF, RPM_BIN, None, 1), "verifyscript2": (RPMTAG_VERIFYSCRIPT2, RPM_STRING, None, 1), "nosource": (RPMTAG_NOSOURCE, RPM_INT32, None, 1), "nopatch": (RPMTAG_NOPATCH, RPM_INT32, None, 1), "disturl": (RPMTAG_DISTURL, RPM_STRING, None, 1), "oldfilenames": (RPMTAG_OLDFILENAMES, RPM_STRING_ARRAY, None, 1), "triggerin": (RPMTAG_TRIGGERIN, RPM_STRING, None, 5), "triggerun": (RPMTAG_TRIGGERUN, RPM_STRING, None, 5), "triggerpostun": (RPMTAG_TRIGGERPOSTUN, RPM_STRING, None, 5) } rpmtagname = {} # Add a reverse mapping for all tags and a new tag -> name mapping for key in rpmtag.keys(): v = rpmtag[key] rpmtag[v[0]] = v rpmtagname[v[0]] = key # Required tags in a header. rpmtagrequired = [] for key in ["name", "version", "release", "arch"]: rpmtagrequired.append(rpmtag[key][0]) # Info within the sig header. rpmsigtag = { # size of gpg/dsaheader sums differ between 64/65 "dsaheader": (RPMTAG_DSAHEADER, RPM_BIN, None, 0), "gpg": (RPMSIGTAG_GPG, RPM_BIN, None, 0), "header_signatures": (HEADER_SIGNATURES, RPM_BIN, 16, 0), # XXX "payloadsize": (RPMSIGTAG_PAYLOADSIZE, RPM_INT32, 1, 0), "size_in_sig": (RPMSIGTAG_SIZE, RPM_INT32, 1, 0), "sha1header": (RPMTAG_SHA1HEADER, RPM_STRING, None, 0), "md5": (RPMSIGTAG_MD5, RPM_BIN, 16, 0), # legacy entries: "pgp": (RPMSIGTAG_PGP, RPM_BIN, None, 1), "badsha1_1": (RPMTAG_BADSHA1_1, RPM_STRING, None, 1), "badsha1_2": (RPMTAG_BADSHA1_2, RPM_STRING, None, 1) } # Add a reverse mapping for all tags and a new tag -> name mapping for key in rpmsigtag.keys(): v = rpmsigtag[key] rpmsigtag[v[0]] = v rpmtagname[v[0]] = key # Required tags in a signature header. rpmsigtagrequired = [] #for key in ["header_signatures", "payloadsize", "size_in_sig", \ # "sha1header", "md5"]: for key in ["md5"]: rpmsigtagrequired.append(rpmsigtag[key][0]) # check arch names against this list possible_archs = ['noarch', 'i386', 'i486', 'i586', 'i686', 'athlon', 'x86_64', 'ia32e', 'alpha', 'sparc', 'sparc64', 's390', 's390x', 'ia64', 'ppc', 'ppc64', 'ppc64iseries', 'ppc64pseries', 'ppcpseries', 'ppciseries', 'ppcmac', 'ppc8260', 'm68k', 'arm', 'armv4l', 'mips', 'mipseb', 'hppa', 'mipsel', 'sh', 'axp', # these are in old rpms: 'i786', 'i886', 'i986', 's390xc'] RPMSENSE_ANY = 0 RPMSENSE_SERIAL = (1 << 0) # legacy RPMSENSE_LESS = (1 << 1) RPMSENSE_GREATER = (1 << 2) RPMSENSE_EQUAL = (1 << 3) RPMSENSE_PROVIDES = (1 << 4) # only used internally by builds RPMSENSE_CONFLICTS = (1 << 5) # only used internally by builds RPMSENSE_PREREQ = (1 << 6) # legacy RPMSENSE_OBSOLETES = (1 << 7) # only used internally by builds RPMSENSE_INTERP = (1 << 8) # Interpreter used by scriptlet. RPMSENSE_SCRIPT_PRE = ((1 << 9) | RPMSENSE_PREREQ) # %pre dependency RPMSENSE_SCRIPT_POST = ((1 << 10)|RPMSENSE_PREREQ) # %post dependency RPMSENSE_SCRIPT_PREUN = ((1 << 11)|RPMSENSE_PREREQ) # %preun dependency RPMSENSE_SCRIPT_POSTUN = ((1 << 12)|RPMSENSE_PREREQ) # %postun dependency RPMSENSE_SCRIPT_VERIFY = (1 << 13) # %verify dependency RPMSENSE_FIND_REQUIRES = (1 << 14) # find-requires generated dependency RPMSENSE_FIND_PROVIDES = (1 << 15) # find-provides generated dependency RPMSENSE_TRIGGERIN = (1 << 16) # %triggerin dependency RPMSENSE_TRIGGERUN = (1 << 17) # %triggerun dependency RPMSENSE_TRIGGERPOSTUN = (1 << 18) # %triggerpostun dependency RPMSENSE_MISSINGOK = (1 << 19) # suggests/enhances/recommends hint RPMSENSE_SCRIPT_PREP = (1 << 20) # %prep build dependency RPMSENSE_SCRIPT_BUILD = (1 << 21) # %build build dependency RPMSENSE_SCRIPT_INSTALL = (1 << 22) # %install build dependency RPMSENSE_SCRIPT_CLEAN = (1 << 23) # %clean build dependency RPMSENSE_RPMLIB = ((1 << 24) | RPMSENSE_PREREQ) # rpmlib(feature) dependency RPMSENSE_TRIGGERPREIN = (1 << 25) # @todo Implement %triggerprein RPMSENSE_KEYRING = (1 << 26) RPMSENSE_PATCHES = (1 << 27) RPMSENSE_CONFIG = (1 << 28) # vim:ts=4:sw=4:showmatch:expandtab -------------- next part -------------- #!/usr/bin/python # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU Library General Public License as published by # the Free Software Foundation; version 2 only # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU Library General Public License for more details. # # You should have received a copy of the GNU Library General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # Copyright 2004 Red Hat, Inc. # # Author: Phil Knirsch, Paul Nasrat, Florian La Roche # import os, os.path, commands, shutil CP_IFMT = 0170000 CP_IFIFO = 0010000 CP_IFCHR = 0020000 CP_IFDIR = 0040000 CP_IFBLK = 0060000 CP_IFREG = 0100000 CP_IFNWK = 0110000 CP_IFLNK = 0120000 CP_IFSOCK = 0140000 class CPIOFile: """ Read ASCII CPIO files. """ def __init__(self, fd): self.filelist = {} # hash of CPIO headers and stat data self.fd = fd # file descript from which we read self.defered = [] # list of defered files for extract self.filename = None # current filename self.filedata = None # current file stat data self.filerawdata = None # raw data of current file def getNextHeader(self): data = self.fd.read(110) # CPIO ASCII hex, expanded device numbers (070702 with CRC) if data[0:6] not in ["070701", "070702"]: raise IOError, "Bad magic reading CPIO headers %s" % data[0:6] #(magic, inode, mode, uid, gid, nlink, mtime, filesize, devMajor, \ # devMinor, rdevMajor, rdevMinor, namesize, checksum) filedata = [data[0:6], int(data[6:14], 16), \ int(data[14:22], 16), int(data[22:30], 16), \ int(data[30:38], 16), int(data[38:46], 16), \ int(data[46:54], 16), int(data[54:62], 16), \ int(data[62:70], 16), int(data[70:78], 16), \ int(data[78:86], 16), int(data[86:94], 16), \ int(data[94:102], 16), data[102:110]] size = filedata[12] filename = self.fd.read(size) filename = "/"+os.path.normpath("./"+filename.rstrip("\x00")) fsize = 110 + size self.fd.read((4 - (fsize % 4)) % 4) # Detect if we're at the end of the archive if filename == "/TRAILER!!!": return [None, None] # Contents filesize = filedata[7] return [filename, filedata] def _read_cpio_headers(self): while 1: [filename, filedata] = self.getNextHeader() if filename == None: break # Contents filesize = filedata[7] self.fd.read(filesize) self.fd.read((4 - (filesize % 4)) % 4) self.filelist[filename] = filedata def createLink(self, src, dst): try: # First try to unlink the defered file os.unlink(dst) except: pass # Behave exactly like cpio: If the hardlink fails (because of different # partitions), then it has to fail os.link(src, dst) def addToDefered(self, filename): self.defered.append((filename, self.filedata)) def handleCurrentDefered(self, filename): # Check if we have a defered 0 byte file with the same inode, devmajor # and devminor and if yes, create a hardlink to the new file. for i in xrange(len(self.defered)-1, -1, -1): if self.defered[i][1][1] == self.filedata[1] and \ self.defered[i][1][8] == self.filedata[8] and \ self.defered[i][1][9] == self.filedata[9]: self.createLink(filename, self.defered[i][0]) self.defered.pop(i) def postExtract(self): # In the end we need to process the remaining files in the defered # list and see if any of them need to be hardlinked, too. for i in xrange(len(self.defered)-1, -1, -1): # We mark already processed defered hardlinked files by setting # the inode of those files to -1. We have to skip those naturally. if self.defered[i][1][1] < 0: continue # Create empty file fd = open(self.defered[i][0], "w") fd.write("") fd.close() os.chmod(self.defered[i][0], (~CP_IFMT) & self.defered[i][1][2]) os.chown(self.defered[i][0], self.defered[i][1][3], self.defered[i][1][4]) os.utime(self.defered[i][0], (self.defered[i][1][6], self.defered[i][1][6])) for j in xrange(i-1, -1, -1): if self.defered[i][1][1] == self.defered[j][1][1] and \ self.defered[i][1][8] == self.defered[j][1][8] and \ self.defered[i][1][9] == self.defered[j][1][9]: self.createLink(filename, self.defered[i][0]) def makeDirs(self, fullname): dirname = fullname[:fullname.rfind("/")] if not os.path.isdir(dirname): os.makedirs(dirname) def extractCurrentEntry(self, instroot=None): if self.filename == None or self.filedata == None: return 0 if instroot == None: instroot = "/" if not os.path.isdir(instroot): return 0 filetype = self.filedata[2] & CP_IFMT fullname = instroot + self.filename if filetype == CP_IFREG: self.makeDirs(fullname) # CPIO archives are sick: Hardlinks are stored as 0 byte long # regular files. # The last hardlinked file in the archive contains the data, so # we have to defere creating any 0 byte file until either: # - We create a file with data and the inode/devmajor/devminor are # identical # - We have processed all files and can check the defered list for # any more identical files (in which case they are hardlinked # again) # - For the rest in the end create 0 byte files as they were in # fact really 0 byte files, not hardlinks. if self.filedata[7] == 0: self.addToDefered(fullname) return 1 fd = open(fullname, "w") fd.write(self.filerawdata) fd.close() os.chown(fullname, self.filedata[3], self.filedata[4]) os.chmod(fullname, (~CP_IFMT) & self.filedata[2]) os.utime(fullname, (self.filedata[6], self.filedata[6])) self.handleCurrentDefered(fullname) elif filetype == CP_IFDIR: if os.path.isdir(fullname): return 1 os.makedirs(fullname) os.chown(fullname, self.filedata[3], self.filedata[4]) os.chmod(fullname, (~CP_IFMT) & self.filedata[2]) os.utime(fullname, (self.filedata[6], self.filedata[6])) elif filetype == CP_IFLNK: symlinkfile = self.filerawdata.rstrip("\x00") if os.path.islink(fullname) and os.readlink(fullname) == symlinkfile: return 1 self.makeDirs(fullname) os.symlink(symlinkfile, fullname) elif filetype == CP_IFCHR or filetype == CP_IFBLK or filetype == CP_IFSOCK or filetype == CP_IFIFO: if filetype == CP_IFCHR: devtype = "c" elif filetype == CP_IFBLK: devtype = "b" else: return 0 self.makeDirs(fullname) ret = commands.getoutput("/bin/mknod "+fullname+" "+devtype+" "+str(self.filedata[10])+" "+str(self.filedata[11])) if ret != "": print "Error creating device: "+ret else: os.chown(fullname, self.filedata[3], self.filedata[4]) os.chmod(fullname, (~CP_IFMT) & self.filedata[2]) os.utime(fullname, (self.filedata[6], self.filedata[6])) else: raise ValueError, "%s: not a valid CPIO filetype" % (oct(filetype)) def getCurrentEntry(self): return [self.filename, self.filedata, self.filerawdata] def getNextEntry(self): [filename, filedata] = self.getNextHeader() if filename == None: return [None, None, None] # Contents filesize = filedata[7] filerawdata = self.fd.read(filesize) self.fd.read((4 - (filesize % 4)) % 4) self.filename = filename self.filedata = filedata self.filerawdata = filerawdata return self.getCurrentEntry() def resetEntry(self): self.fd.seek(0) self.filename = None self.filedata = None self.filerawdata = None self.defered = [] def namelist(self): """Return a list of file names in the archive.""" return self.filelist def read(self): """Read an parse cpio archive.""" self._read_cpio_headers() if __name__ == "__main__": import sys for f in sys.argv[1:]: if f == "-": c = CPIOFile(sys.stdin) else: c = CPIOFile(f) try: c.read() except IOError, e: print "error reading cpio: %s" % e print c.filelist # vim:ts=4:sw=4:showmatch:expandtab