From mlichvar at redhat.com Fri Dec 1 08:50:04 2006 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Fri, 1 Dec 2006 09:50:04 +0100 Subject: rawhide report: 20061128 changes In-Reply-To: <456F00F5.4030209@develer.com> References: <200611290345.kAT3jTHs000417@hs20-bc2-6.build.redhat.com> <456F00F5.4030209@develer.com> Message-ID: <20061201085004.GB19280@localhost> On Thu, Nov 30, 2006 at 05:04:05PM +0100, Bernardo Innocenti wrote: > buildsys at redhat.com wrote: > > >ncurses-5.5-25.20060715.fc7 > >--------------------------- > >* Mon Nov 27 2006 Miroslav Lichvar 5.5-25.20060715 > >- move libncurses and some terminfo entries out of /usr > >- drop console symlink and sparc terminfo entries > > Package installation fails if you have /usr mounted separately because > /lib/terminfo/v/vt-220 is hardlinked with /lib/terminfo/v/vt220 . This is fixed in ncurses-5.5-26.20060715.fc7. -- Miroslav Lichvar From bernie at develer.com Fri Dec 1 09:13:55 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 01 Dec 2006 10:13:55 +0100 Subject: Switching to ncurses Message-ID: <456FF253.9010503@develer.com> Are we still planning to completely replace termcap with ncurses in Fedora? While I welcome reducing the number of dupe packages, I'm worried by the impact of this change on the size and performance of many core programs. libncurses is much bigger than libtermcap, and also has oddly large .bss and .data sections: bender:/[1/0]# size /lib64/libncurses.so.5 /lib64/libtermcap.so.2 text data bss dec hex filename 319006 56608 3592 379206 5c946 /lib64/libncurses.so.5 10483 788 112 11383 2c77 /lib64/libtermcap.so.2 this is going to impact very negatively on the RSS of several critical programs such as bash and python. I'm also worried that the overall time required spent for a fork may increase considerably. But maybe ncurses can easily be fixed to avoid global data and buffers? -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From fedora at camperquake.de Fri Dec 1 09:22:15 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 1 Dec 2006 10:22:15 +0100 Subject: Switching to ncurses In-Reply-To: <456FF253.9010503@develer.com> References: <456FF253.9010503@develer.com> Message-ID: <20061201102215.217e71e1@banea.int.addix.net> Hi. On Fri, 01 Dec 2006 10:13:55 +0100, Bernardo Innocenti wrote: > I'm also worried that the overall time required spent for a > fork may increase considerably. Why would that be? The library is shared, and Linux has been doing COW for ages. From jakub at redhat.com Fri Dec 1 09:45:18 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 1 Dec 2006 04:45:18 -0500 Subject: Switching to ncurses In-Reply-To: <456FF253.9010503@develer.com> References: <456FF253.9010503@develer.com> Message-ID: <20061201094518.GS6570@devserv.devel.redhat.com> On Fri, Dec 01, 2006 at 10:13:55AM +0100, Bernardo Innocenti wrote: > Are we still planning to completely replace termcap with > ncurses in Fedora? > > While I welcome reducing the number of dupe packages, I'm > worried by the impact of this change on the size and > performance of many core programs. > > libncurses is much bigger than libtermcap, and also has > oddly large .bss and .data sections: > > bender:/[1/0]# size /lib64/libncurses.so.5 /lib64/libtermcap.so.2 > text data bss dec hex filename > 319006 56608 3592 379206 5c946 /lib64/libncurses.so.5 > 10483 788 112 11383 2c77 /lib64/libtermcap.so.2 > > this is going to impact very negatively on the RSS of several > critical programs such as bash and python. The really big writable section (at least in FC6 ncurses; I know many libraries are much bigger, but bash and similar programs are really performance critical, slowing down all configure scripts, libtool etc. by say 50% is not acceptable I guess) is .data.rel.ro: [15] .ctors PROGBITS 000000346904e088 04e088 000010 00 WA 0 0 8 [16] .dtors PROGBITS 000000346904e098 04e098 000010 00 WA 0 0 8 [17] .jcr PROGBITS 000000346904e0a8 04e0a8 000008 00 WA 0 0 8 [18] .data.rel.ro PROGBITS 000000346904e0c0 04e0c0 00c4e8 00 WA 0 0 32 [19] .dynamic DYNAMIC 000000346905a5a8 05a5a8 0001a0 10 WA 3 0 8 [20] .got PROGBITS 000000346905a748 05a748 0001f0 08 WA 0 0 8 [21] .got.plt PROGBITS 000000346905a938 05a938 000940 08 WA 0 0 8 [22] .data PROGBITS 000000346905b280 05b280 000b40 00 WA 0 0 32 [23] .bss NOBITS 000000346905bdc0 05bdc0 000e08 00 WA 0 0 32 There is a bunch of quite big objects: 121: 0000003469050fc0 7960 OBJECT GLOBAL DEFAULT 18 _nc_cap_hash_table 129: 0000003468e244b0 18 FUNC GLOBAL DEFAULT 10 bkgd 176: 000000346904e0e0 360 OBJECT GLOBAL DEFAULT 18 boolcodes 189: 0000003468e2aa50 18 FUNC GLOBAL DEFAULT 10 scrollok 196: 0000003468e24490 18 FUNC GLOBAL DEFAULT 10 bkgdset 244: 0000003468e21c50 18 FUNC GLOBAL DEFAULT 10 clearok 249: 0000003469058160 3320 OBJECT GLOBAL DEFAULT 18 strnames 261: 0000003469057d60 360 OBJECT GLOBAL DEFAULT 18 boolfnames 262: 000000346904e260 320 OBJECT GLOBAL DEFAULT 18 numcodes 294: 0000003469057220 2480 OBJECT GLOBAL DEFAULT 18 _nc_key_names 311: 000000346904f0a0 7960 OBJECT GLOBAL DEFAULT 18 _nc_info_hash_table 341: 0000003469052ee0 1080 OBJECT GLOBAL DEFAULT 18 _nc_capalias_table 344: 0000003468e243a0 18 FUNC GLOBAL DEFAULT 10 echochar 345: 0000003469058020 320 OBJECT GLOBAL DEFAULT 18 numfnames 378: 0000003468e24370 18 FUNC GLOBAL DEFAULT 10 addch 403: 0000003469058e60 3320 OBJECT GLOBAL DEFAULT 18 strfnames 422: 0000003469057be0 360 OBJECT GLOBAL DEFAULT 18 boolnames 440: 0000003468e25af0 18 FUNC GLOBAL DEFAULT 10 leaveok 467: 0000003468e23f50 18 FUNC GLOBAL DEFAULT 10 insch 488: 000000346904e3a0 3320 OBJECT GLOBAL DEFAULT 18 strcodes 515: 0000003468e3ad40 18 FUNC GLOBAL DEFAULT 10 notimeout 525: 0000003469057ee0 320 OBJECT GLOBAL DEFAULT 18 numnames 547: 0000003469053320 168 OBJECT GLOBAL DEFAULT 18 _nc_infoalias_table 551: 0000003468e2d5b0 18 FUNC GLOBAL DEFAULT 10 syncok and 3850 relative relocations. Several of these are used only by code which parses the terminfo sources, does that really have to be in a library that is used by all programs? Is there anything but tic (or a couple of other ncurses utilities) which parses the terminfo sources? I think if it makes sense to remove termcap and replace it only with ncurses (I'm not convinced), then the first step needs to be change ncurses so that it is not a kitchen sink library. Jakub From arjan at fenrus.demon.nl Fri Dec 1 10:00:54 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Fri, 01 Dec 2006 11:00:54 +0100 Subject: Switching to ncurses In-Reply-To: <20061201094518.GS6570@devserv.devel.redhat.com> References: <456FF253.9010503@develer.com> <20061201094518.GS6570@devserv.devel.redhat.com> Message-ID: <1164967254.3233.64.camel@laptopd505.fenrus.org> On Fri, 2006-12-01 at 04:45 -0500, Jakub Jelinek wrote: > On Fri, Dec 01, 2006 at 10:13:55AM +0100, Bernardo Innocenti wrote: > > Are we still planning to completely replace termcap with > > ncurses in Fedora? > > > > While I welcome reducing the number of dupe packages, I'm > > worried by the impact of this change on the size and > > performance of many core programs. > > > > libncurses is much bigger than libtermcap, and also has > > oddly large .bss and .data sections: > > > > bender:/[1/0]# size /lib64/libncurses.so.5 /lib64/libtermcap.so.2 > > text data bss dec hex filename > > 319006 56608 3592 379206 5c946 /lib64/libncurses.so.5 > > 10483 788 112 11383 2c77 /lib64/libtermcap.so.2 > > > > this is going to impact very negatively on the RSS of several > > critical programs such as bash and python. > > The really big writable section how much of that would be missing const ? From mlichvar at redhat.com Fri Dec 1 10:05:29 2006 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Fri, 1 Dec 2006 11:05:29 +0100 Subject: Switching to ncurses In-Reply-To: <456FF253.9010503@develer.com> References: <456FF253.9010503@develer.com> Message-ID: <20061201100529.GD19280@localhost> On Fri, Dec 01, 2006 at 10:13:55AM +0100, Bernardo Innocenti wrote: > While I welcome reducing the number of dupe packages, I'm > worried by the impact of this change on the size and > performance of many core programs. It shouldn't be that bad. > libncurses is much bigger than libtermcap, and also has > oddly large .bss and .data sections: > > bender:/[1/0]# size /lib64/libncurses.so.5 /lib64/libtermcap.so.2 > text data bss dec hex filename > 319006 56608 3592 379206 5c946 /lib64/libncurses.so.5 > 10483 788 112 11383 2c77 /lib64/libtermcap.so.2 > > this is going to impact very negatively on the RSS of several > critical programs such as bash and python. $ ps -o rss,comm RSS COMMAND 1428 bash_termcap 1480 bash_curses Not sure it proves anything. > I'm also worried that the overall time required spent for a > fork may increase considerably. Note that termcap has everything in one big file. A simple program doing just tgetent() and tgetstr() is significantly faster with ncurses. $ time ( a=0;while [ $a -lt 1000 ]; do a=$[$a + 1] && ./testtermcap < /dev/null &> /dev/null; done ) real 0m2.078s user 0m1.137s sys 0m0.936s $ time ( a=0;while [ $a -lt 1000 ]; do a=$[$a + 1] && ./testncurses < /dev/null &> /dev/null; done ) real 0m1.464s user 0m0.496s sys 0m0.962s -- Miroslav Lichvar From bernie at develer.com Fri Dec 1 10:23:21 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 01 Dec 2006 11:23:21 +0100 Subject: Switching to ncurses In-Reply-To: <20061201100529.GD19280@localhost> References: <456FF253.9010503@develer.com> <20061201100529.GD19280@localhost> Message-ID: <45700299.9050800@develer.com> Miroslav Lichvar wrote: >> libncurses is much bigger than libtermcap, and also has >> oddly large .bss and .data sections: >> >> bender:/[1/0]# size /lib64/libncurses.so.5 /lib64/libtermcap.so.2 >> text data bss dec hex filename >> 319006 56608 3592 379206 5c946 /lib64/libncurses.so.5 >> 10483 788 112 11383 2c77 /lib64/libtermcap.so.2 >> >> this is going to impact very negatively on the RSS of several >> critical programs such as bash and python. > > $ ps -o rss,comm > RSS COMMAND > 1428 bash_termcap > 1480 bash_curses > > Not sure it proves anything. We see almost exactly the +50KB size difference reported by "size". The fact that bash also carries an additional 1400KB of bloat does not make the ncurses problem more appealing : - ) > Note that termcap has everything in one big file. A simple program > doing just tgetent() and tgetstr() is significantly faster with > ncurses. I too dislike big binary files, but I would at least hope it's being loaded with mmap() and/or has at least an index to seek to the correct terminal as an O(1) operation. > $ time ( a=0;while [ $a -lt 1000 ]; do a=$[$a + 1] && ./testtermcap < > /dev/null &> /dev/null; done ) > > real 0m2.078s > user 0m1.137s > sys 0m0.936s > > $ time ( a=0;while [ $a -lt 1000 ]; do a=$[$a + 1] && ./testncurses < > /dev/null &> /dev/null; done ) > > real 0m1.464s > user 0m0.496s > sys 0m0.962s Hmmm! So termcap also has algoritmic disadvantages that outweight its smaller size relative to ncurses. This makes me prefer ncurses over termcap, but fixing its abnormal data+bss size is still very desiderable. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Fri Dec 1 10:28:50 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 01 Dec 2006 11:28:50 +0100 Subject: Switching to ncurses In-Reply-To: <20061201102215.217e71e1@banea.int.addix.net> References: <456FF253.9010503@develer.com> <20061201102215.217e71e1@banea.int.addix.net> Message-ID: <457003E2.40700@develer.com> Ralf Ertzinger wrote: > On Fri, 01 Dec 2006 10:13:55 +0100, Bernardo Innocenti wrote: > >> I'm also worried that the overall time required spent for a >> fork may increase considerably. > > Why would that be? The library is shared, and Linux has been doing > COW for ages. COW only saves the memcpy(), you still have to do some per-page book keeping at fork time, I suppose (*). And if those pages are actually being written by the forked process, it's going to cost a page fault and a memcpy(). That's why I wrote "overall time spent for a fork". (*) on second thought, it may actually be a per-vma thing, which would make the nr. of pages irrelevant. I shall study the Linux VM one day... -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From jakub at redhat.com Fri Dec 1 10:32:12 2006 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 1 Dec 2006 05:32:12 -0500 Subject: Switching to ncurses In-Reply-To: <1164967254.3233.64.camel@laptopd505.fenrus.org> References: <456FF253.9010503@develer.com> <20061201094518.GS6570@devserv.devel.redhat.com> <1164967254.3233.64.camel@laptopd505.fenrus.org> Message-ID: <20061201103212.GT6570@devserv.devel.redhat.com> On Fri, Dec 01, 2006 at 11:00:54AM +0100, Arjan van de Ven wrote: > On Fri, 2006-12-01 at 04:45 -0500, Jakub Jelinek wrote: > > On Fri, Dec 01, 2006 at 10:13:55AM +0100, Bernardo Innocenti wrote: > > > Are we still planning to completely replace termcap with > > > ncurses in Fedora? > > > > > > While I welcome reducing the number of dupe packages, I'm > > > worried by the impact of this change on the size and > > > performance of many core programs. > > > > > > libncurses is much bigger than libtermcap, and also has > > > oddly large .bss and .data sections: > > > > > > bender:/[1/0]# size /lib64/libncurses.so.5 /lib64/libtermcap.so.2 > > > text data bss dec hex filename > > > 319006 56608 3592 379206 5c946 /lib64/libncurses.so.5 > > > 10483 788 112 11383 2c77 /lib64/libtermcap.so.2 > > > > > > this is going to impact very negatively on the RSS of several > > > critical programs such as bash and python. > > > > The really big writable section > > how much of that would be missing const ? The 2 biggest objects (8KB each) are const, pregenerated array of: const struct name_table_entry * const _nc_{info,cap}_hash_table[] = { 0, 0, 0, 0, 0, 0, _nc_info_table + 465, 0, 0, 0, 0, 0, _nc_info_table + 261, ... }; I think the easiest would be just nuke the terminfo source parsing routines from libncurses*.so, _nc_read_entry_source nor _nc_parse_entry aren't even prototyped in any installed ncurses headers. It can be IMHO moved to libtic.a which will be linked into ncurses utilities that need it. If that is not possible, there are other options, e.g. switching to a more compact and relocation friendly representation. In those 2 big (sparse) tables all entries are either 0 or _nc_{info,cap}_table + small const offset >= 0 < 512. Representing it as array of short int where -1 would mean the current 0 and 0 .. 511 would mean _nc_info_table + that_value would be trivial, save 2x6KB of memory and save hundreds of relocations. Guess other large .data.rel.ro objects could be treated similarly, again with a < 10 line change in code using the tables and some changes in the generator. Jakub From buildsys at redhat.com Fri Dec 1 10:54:22 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Fri, 1 Dec 2006 05:54:22 -0500 Subject: rawhide report: 20061201 changes Message-ID: <200612011054.kB1AsMBf017076@hs20-bc2-6.build.redhat.com> Updated Packages: anaconda-11.2.0.3-1 ------------------- * Thu Nov 30 2006 Chris Lumens - 11.2.0.3 - Don't look for rhpxl's list of drivers anymore (#217890). - Init wreq structure before use (dcantrel, #215367). - Only compute broadcast and netaddr if IPv4 is enabled (dcantrel, #215451). - Fetch a new release notes file on language change (#217501). - Add support for Iloko language (katzj, #215644). - Fix Sinhala timezone (katzj, #217288). audit-1.3-2.fc7 --------------- * Thu Nov 30 2006 Steve Grubb 1.3-2 - Fix minor parsing problem and add new msg types authconfig-5.3.12-1.fc6 ----------------------- * Wed Nov 29 2006 Tomas Mraz - 5.3.12-1 - when pam_krb5 auth fails with smartcard login don't enforce it in the account stack (#214931) - updated translations (#216570) - winbind should be added only to user tables (#216862) * Fri Oct 20 2006 Tomas Mraz - 5.3.11-1 - fixed --smartcardaction command line option (#211552) compat-db-4.3.29-2.fc7 ---------------------- * Sun Nov 26 2006 Jindrich Novy 4.3.29-2 - include also headers for db4-4.2.52 - sync db4 and compat-db licenses to BSD-style as the result of consultation with legal department - BuildPreReq -> BuildRequires, rpmlint fixes * Fri Nov 10 2006 Jindrich Novy 4.3.29-1 - add 4.3.29 and remove 4.1.25 - spec reduction diet, remove old unapplied patches - apply patches 3-5 with upstream fixes for 4.2.52 - apply first upstream fix patch for 4.3.29 - all patches/sources now point to correct URLs - ship headers for db-4.3.29 coolkey-1.0.1-15.fc7 -------------------- * Wed Nov 01 2006 Bob Relyea - 1.0.1-15 - Don't grab the CUID on cac's. Resting the card causes it to - logout of other applications. * Wed Nov 01 2006 Bob Relyea - 1.0.1-14 - Shared memory directory needs to be writeable by all so - coolkey can create caches for any user. (lack of caches - show up in screen savers reactly slowly). db4-4.5.20-3.fc7 ---------------- * Fri Dec 01 2006 Jindrich Novy 4.5.20-3 - temporarily remove ppc64 from java arches * Sun Nov 26 2006 Jindrich Novy 4.5.20-2 - sync db4 and compat-db licenses to BSD-style as the result of consultation with legal department - fix some rpmlint warnings * Fri Nov 10 2006 Jindrich Novy 4.5.20-1 - update to db-4.5.20 (#198038) - fix BuildRoot - drop .64bit patch - patch/source URLs now point to correct location firstboot-1.4.26-1.fc7 ---------------------- * Thu Nov 30 2006 Chris Lumens 1.4.26-1 - Update translations (#198872). freeradius-1.1.3-2 ------------------ * Thu Nov 30 2006 Thomas Woerner 1.1.3-2 - fixed ldap code to not use internals, added LDAP_DEPRECATED compile time flag (#210912) frysk-0.0.1.2006.11.30.rh1-1.fc7 -------------------------------- * Thu Nov 30 2006 Stepan Kasal - 0.0.1.2006.11.30.rh1-1 - New upstream version. - The stamp file for glade files has been renamed. - Disable ppc64 build. gedit-1:2.16.2-2.fc7 -------------------- * Thu Nov 30 2006 Matthias Clasen - 1:2.16.2-2 - Small accessibility improvements hsqldb-1:1.8.0.4-4jpp.1 ----------------------- * Wed Nov 29 2006 Deepak Bhole 1.8.0.4-4jpp.1 - Added missing entries to the files section libselinux-1.33.2-2.fc7 ----------------------- * Thu Nov 30 2006 Dan Walsh - 1.33.2-2 - Update man page m17n-db-1.3.3-42.fc7 -------------------- * Fri Dec 01 2006 Mayank Jain - Fixed typo in si-wijesekera key summary (in the patch) ncurses-5.5-26.20060715.fc7 --------------------------- * Thu Nov 30 2006 Miroslav Lichvar 5.5-26.20060715 - move also hardlinked entries (#217750) - search /etc/terminfo for local terminfo entries openssh-4.3p2-14.fc7 -------------------- * Thu Nov 30 2006 Tomas Mraz - 4.3p2-14 - fix gssapi with DNS loadbalanced clusters (#216857) openssl-0.9.8b-11.fc7 --------------------- * Thu Nov 30 2006 Tomas Mraz 0.9.8b-11 - the previous change still didn't make X509_NAME_cmp transitive pam-0.99.6.2-5.fc7 ------------------ * Thu Nov 30 2006 Tomas Mraz 0.99.6.2-5 - add select-context option to pam_selinux (#213812) - autoreconf won't work with autoconf-2.61 as configure.in is not yet adjusted for it * Mon Nov 13 2006 Tomas Mraz 0.99.6.2-4 - update internal db4 to 4.5.20 version - move setgid before setuid in pam_keyinit (#212329) - make username check in pam_unix consistent with useradd (#212153) * Tue Oct 24 2006 Tomas Mraz 0.99.6.2-3.3 - don't overflow a buffer in pam_namespace (#211989) pilot-link-2:0.12.1-4.fc7 ------------------------- * Thu Nov 30 2006 Ivana Varekova - 2:0.12.1-4 - fix undefined value problem #156682 * Tue Nov 28 2006 Ivana Varekova - 2:0.12.1-3 - add enable-conduits option * Mon Nov 27 2006 Ivana Varekova - 2:0.12.1-2 - Add epoch - Delete useless patches - Add Buildrequires autoconf, automake and libtool pirut-1.2.9-1.fc7 ----------------- * Thu Nov 30 2006 Jeremy Katz - 1.2.9-1 - rpmlint fixes to packaging (jbowes) - translation fixes (#212877) - Disable linking to bugs and CVEs to avoid launching firefox as root (lmacken, #216552) - translation updates pykickstart-0.40-1.fc7 ---------------------- * Thu Nov 30 2006 Chris Lumens - 0.40-1 - Pull in new translations (#216620). - Add --level argument to logging command writer. pyparted-1.8.1-1.fc7 -------------------- * Thu Nov 30 2006 David Cantrell - 1.8.1-1 - Determine Python version to use in %build so the source RPM is more easily moved between distribution releases. python-virtinst-0.98.0-1 ------------------------ * Thu Nov 30 2006 Jeremy Katz - 0.98.0-1 - add support for creating nonsparse disk images (#217764) - remove xeninst compat bits readline-5.2-2.fc7 ------------------ * Thu Nov 30 2006 Miroslav Lichvar 5.2-2 - require ncurses-devel instead of libtermcap-devel selinux-policy-2.4.6-3.fc7 -------------------------- * Tue Nov 28 2006 Dan Walsh 2.4.6-3 - Allow login programs to polyinstatiate homedirs Resolves: #216184 - Allow quotacheck to create database files Resolves: #212957 setroubleshoot-1.8.3-1.fc7 -------------------------- * Thu Nov 30 2006 John Dennis - 1.8.3-1 * more i18n translations * fix bug 217710, date representation did not respect locale, at the same time remove old date formatting code, now cruft since we can't use it because it was specific to US English. * fix how selections are handled when rows are expunged. * add Copy to Edit menu, for copying selection from detail pane, unfortunately gtkhtml2 widget does not preserve line breaks between table rows. * Tue Nov 28 2006 John Dennis - 1.8.1-1 * fix bug 216936, and bug 215290, add 'Copy Alert' edit menu item * clean up menu items, add tooltips * fix printing so it will work with multiple alerts, force font to monospace 10pt, display error dialog if printing fails. * fix bug 216908, platform and raw audit messages were not wrapped to fit on page. * address bug 216575, update i18n po files * fix bug 216941, set default folder for save operation, also set default filename * add menu items "toggle hide deleted", "select none". Add model filter to control visibility of alerts, final components of bug 216327 fix. * dwalsh adds fix for bug 214218, sealert with no command line arguments induces startup as dbus service, this had been a regression. * fix bug 216327, rework how deletes are performed in browser. Delete now marks each seleted siginfo with a delete flag, expunge permanently deletes siginfo's marked for deletion, also add undelete command, removed delete confirmation dialog. Modify how text attributes in cell renderer are computed to allow for strike-throughs of alerts marked for deletion. * multiple alerts can now be selected, add select all command, setuptool-1.19.1-2 ------------------ * Thu Nov 30 2006 Nalin Dahyabhai 1.19.1-2 - rebuild * Thu Nov 30 2006 Nalin Dahyabhai 1.19.1-1 - update translations (#216494) shadow-utils-2:4.0.18.1-5.fc7 ----------------------------- * Thu Nov 30 2006 Steve Grubb 2:4.0.18.1-5 - Fix SELinux context on home directories created with useradd (#217441) stunnel-4.20-1 -------------- * Thu Nov 30 2006 Miloslav Trmac - 4.20-1 - Update to stunnel-4.20 system-config-kickstart-2.6.19-1.fc7 ------------------------------------ * Thu Nov 30 2006 Chris Lumens 2.6.19-1 - Update translation files (#216593). system-config-securitylevel-1.6.29-1 ------------------------------------ * Thu Nov 30 2006 Chris Lumens 1.6.29-1 - Update translations (#216563). - Remove unnecessary SELinux boolean panel. - GUI package should require same version of TUI package. - Fix IPv6 firewall to allow outbound connections and block incoming connections we don't need (tmraz, #217514). - Other ports expander should grow as the window grows (#217645). tcsh-6.14-13 ------------ * Thu Nov 30 2006 Miloslav Trmac - 6.14-13 - Link to ncurses instead of libtermcap - Fix some rpmlint warnings xorg-x11-drv-s3-0.5.0-1.fc7 --------------------------- * Thu Nov 30 2006 Adam Jackson 0.5.0-1 - Update to 0.5.0 xorg-x11-drv-tdfx-1.3.0-1.fc7 ----------------------------- * Thu Nov 30 2006 Adam Jackson 1.3.0-1.fc7 - Update to 1.3.0. Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From giallu at gmail.com Fri Dec 1 12:27:41 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 1 Dec 2006 13:27:41 +0100 Subject: Logged out from X during yum update Message-ID: I am installing FC-6 onto a brand new server (HP ProLiant ML 350 G5); my usual PXE+HTTP installation went just fine. However, during the first update, I was logged out from X and returned to the gdm screen. The last package I can see in /var/log/yum.log is selinux-policy-targeted.noarch 2.4.5-3.fc6 Now "yum update" fails becuase python-devel confilcts with python < 2.4.4-1.fc6, but I am able to fix this by "yum remove python-2.4.4" before doing the new "yum update". Please also note this happened twice, the former being when I installed the i386 arch while waiting the download of the X86_64 DVD. Does anyone else saw this? From franklinux392 at yahoo.com Fri Dec 1 12:22:23 2006 From: franklinux392 at yahoo.com (Frank S.) Date: Fri, 1 Dec 2006 04:22:23 -0800 (PST) Subject: EASY FEDORA Message-ID: <581965.81337.qm@web54310.mail.yahoo.com> Why don't you create an easy ferdora like (easy ubuntu)or a fedora mint (linux mint) for people new to linux. please do not get me wrong I love Fedora but to make it usable is a lot of work and I would never recomed to a friend because I would slave myself to his dektop. people NEED a dirty Fedora as you would call it. they will call it a usable OS. thank you so very much for your hard work!! --------------------------------- Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at jdub.homelinux.org Fri Dec 1 13:00:39 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 01 Dec 2006 07:00:39 -0600 Subject: EASY FEDORA In-Reply-To: <581965.81337.qm@web54310.mail.yahoo.com> References: <581965.81337.qm@web54310.mail.yahoo.com> Message-ID: <1164978039.13143.1.camel@zod.rchland.ibm.com> On Fri, 2006-12-01 at 04:22 -0800, Frank S. wrote: > Why don't you create an easy ferdora like (easy ubuntu)or a fedora > mint (linux mint) for people new to linux. please do not get me wrong > I love Fedora but to make it usable is a lot of work and I would never > recomed to a friend because I would slave myself to his dektop. > people NEED a dirty Fedora as you would call it. they will call it a > usable OS. If you're talking about a Fedora with things like fglrx or the nvidia drivers, then no. It goes against the entire idea of what Fedora is supposed to be and it doesn't help anyone in the long run. josh From dlara at fls-es.com Fri Dec 1 13:22:34 2006 From: dlara at fls-es.com (David Lara) Date: Fri, 1 Dec 2006 14:22:34 +0100 Subject: EASY FEDORA In-Reply-To: <581965.81337.qm@web54310.mail.yahoo.com> References: <581965.81337.qm@web54310.mail.yahoo.com> Message-ID: <20061201142234.3f88121e@dlara> El Fri, 1 Dec 2006 04:22:23 -0800 (PST) "Frank S." escribi?: > Why don't you create an easy ferdora like (easy ubuntu)or a fedora > mint (linux mint) for people new to linux. please do not get me wrong > I love Fedora but to make it usable is a lot of work and I would > never recomed to a friend because I would slave myself to his dektop. > people NEED a dirty Fedora as you would call it. they will call it a > usable OS. thank you so very much for your hard work!! Fedora is usable for me out-of-the-box. I can listen my music (Vorbis) and watch my videos (Theora) without need to touch anything. Slave to desktop ? Sorry ? Oh, are you talking about people using propietary software like Adobe Flash, slaved to x86 machines and operating systems that are in Adobe whitelist (if you use BSD you are not allowed to use Flash, read the Flash EULA) ? People needs to take care about the problem of closed source programs and formats that make restrictions. Perhaps, some day Adobe will put (for example) x86-32 bits systems on Flash blacklist. Must Fedora ship Flash and support this software ? Or is better to promote (coding, testing, translate) free alternatives like Gnash ? The same with MP3, MOV, etc... Btw, you can install this software without problems. This process is well documented in WWW. Or use other distributions that don't care about this things. Remeber what is Fedora: "It's the best combination of robust and latest software that exists in the free software world". Nothing more, nothing less :) From cmadams at hiwaay.net Fri Dec 1 14:13:19 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 1 Dec 2006 08:13:19 -0600 Subject: Switching to ncurses In-Reply-To: <45700299.9050800@develer.com> References: <456FF253.9010503@develer.com> <20061201100529.GD19280@localhost> <45700299.9050800@develer.com> Message-ID: <20061201141319.GA1246559@hiwaay.net> Once upon a time, Bernardo Innocenti said: > Hmmm! So termcap also has algoritmic disadvantages that outweight > its smaller size relative to ncurses. Remember though that /bin/sh (aka bash) has many uses that are non-interactive and don't ever look up a termcap/terminfo entry (probably many more such uses than interactive). The lookup slowdown probably does not outweigh any dynamic linking slowdown or memory overhead. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From kloczek at zie.pg.gda.pl Fri Dec 1 15:53:42 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Fri, 01 Dec 2006 16:53:42 +0100 Subject: rawhide report: 20061201 changes In-Reply-To: <200612011054.kB1AsMBf017076@hs20-bc2-6.build.redhat.com> References: <200612011054.kB1AsMBf017076@hs20-bc2-6.build.redhat.com> Message-ID: <1164988422.13427.17.camel@kloczek01.pracownicy.zie> Dnia 01-12-2006, pi? o godzinie 05:54 -0500, buildsys at redhat.com napisa?(a): > ncurses-5.5-26.20060715.fc7 > --------------------------- > * Thu Nov 30 2006 Miroslav Lichvar > 5.5-26.20060715 > - move also hardlinked entries (#217750) > - search /etc/terminfo for local terminfo entries On thread about switching from libtermcap to ncurses was about libncurses size vis libtermcap. Why not enable --with-termlib in ncurses. After this only libtermlib[w] can sit in /{_lib} and all other shared libraries can be installed in %{_libdir} because all applications which now uses termcap API can be linked with only libtermlib. Second: now ncurses package contains shared libncurses and libncursesw. Why not all link all against libncursesw ? It will allow drop libncurses (or move to compat-ncurses). It will allow make main package ~two time smaller. If you are interested I can send you all my ncursesw patches (all tested and used more than half year on production; most of changes requires only fixes on autoconf leel). [kloczek at kloczek01 SOURCES]$ ls -1 *ncursesw*.patch bc-ncursesw.patch cscope-ncursesw.patch epic-ncursesw.patch gdb-ncursesw.patch hexedit-ncursesw.patch joe-ncursesw.patch krb5-ncursesw.patch lftp-ncursesw.patch mtr-ncursesw.patch mysql-ncursesw.patch OpenIPMI-ncursesw.patch parted-ncursesw.patch pinfo-ncursesw.patch psmisc-ncursesw.patch readline-use_libncursesw.patch screen-ncursesw.patch statserial-ncursesw.patch tcsh-ncursesw.patch telnet-ncursesw.patch texinfo-ncursesw.patch vte-ncursesw.patch xterm-ncursesw.patch (don't talk me about fill 22 separated entries in Fedora BTS). Most of this patches can be easy extended for use libtermlib[w]. > tcsh-6.14-13 > ------------ > * Thu Nov 30 2006 Miloslav Trmac - 6.14-13 > - Link to ncurses instead of libtermcap > - Fix some rpmlint warnings Current ncurses patch changes: -AC_SEARCH_LIBS(tgetent, termlib termcap curses ncurses) +AC_SEARCH_LIBS(tgetent, ncurses) Why not: -AC_SEARCH_LIBS(tgetent, termlib termcap curses ncurses) +AC_SEARCH_LIBS(tgetent, ncursesw ncurses termlib termcap curses) or even better (after build ncurses with --with-termlib): -AC_SEARCH_LIBS(tgetent, termlib termcap curses ncurses) +AC_SEARCH_LIBS(tgetent, termlibw ncursesw termlib ncurses termcap curses) ?? Probably last form of this fix can be submited to tcsh maintainer for include in dist source tree. Please prepare fixes using mind not hands ;> kloczek From david at fubar.dk Fri Dec 1 17:41:21 2006 From: david at fubar.dk (David Zeuthen) Date: Fri, 01 Dec 2006 12:41:21 -0500 Subject: Zod livecd beta Message-ID: <1164994881.2479.30.camel@zelda.fubar.dk> Hey, General Zod said he wanted to be part of the LiveCD experience ... so I had no other choice than building one for him! More seriously, during the Fedora Summit it was decided that it was time to get more serious with having Live CD's as part of the Fedora release processes. Part of this includes building a Live CD with software from Core 6 and Extras 6. I've created a Wiki page for tracking this work (feel free to contribute) http://fedoraproject.org/wiki/FedoraLiveCD Specifically, I've built a beta livecd for Fedora 6. It's available as a torrent here http://torrent.fedoraproject.org/torrents/Zod-livecd-beta-20061130-i386.torrent Please file bugs against components as usual but make them track the Fedora 6 livecd tracking bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FC6LiveCDTracker The plan is to create another spin of FC6+updates + FE6 in a week or so or when the most serious bugs are resolved. Right now I can only think of two serious bugs https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217919 and the fact that shutdown don't work well. That should probably get filed too. Enjoy! David From pemboa at gmail.com Fri Dec 1 17:56:01 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 1 Dec 2006 11:56:01 -0600 Subject: EASY FEDORA In-Reply-To: <16de708d0612010955u210b895fg5121c78cce0d168@mail.gmail.com> References: <581965.81337.qm@web54310.mail.yahoo.com> <20061201142234.3f88121e@dlara> <16de708d0612010955u210b895fg5121c78cce0d168@mail.gmail.com> Message-ID: <16de708d0612010956j555db692tc6c154eef2df8108@mail.gmail.com> On 12/1/06, Arthur Pemberton wrote: > On 12/1/06, David Lara wrote: > > El Fri, 1 Dec 2006 04:22:23 -0800 (PST) > > "Frank S." escribi?: > > > > > Why don't you create an easy ferdora like (easy ubuntu)or a fedora > > > mint (linux mint) for people new to linux. please do not get me wrong > > > I love Fedora but to make it usable is a lot of work and I would > > > never recomed to a friend because I would slave myself to his dektop. > > > people NEED a dirty Fedora as you would call it. they will call it a > > > usable OS. thank you so very much for your hard work!! > > > > Fedora is usable for me out-of-the-box. I can listen my music (Vorbis) > > and watch my videos (Theora) without need to touch anything. > > > > Slave to desktop ? Sorry ? > > > > Oh, are you talking about people using propietary software like Adobe > > Flash, slaved to x86 machines and operating systems that are in Adobe > > whitelist (if you use BSD you are not allowed to use Flash, read the > > Flash EULA) ? > > > > People needs to take care about the problem of closed source programs > > and formats that make restrictions. Perhaps, some day Adobe will put > > (for example) x86-32 bits systems on Flash blacklist. Must Fedora > > ship Flash and support this software ? Or is better to promote > > (coding, testing, translate) free alternatives like Gnash ? > > > > The same with MP3, MOV, etc... > > > > Btw, you can install this software without problems. This process is > > well documented in WWW. Or use other distributions that don't care > > about this things. Remeber what is Fedora: "It's the best combination > > of robust and latest software that exists in the free software world". > > Nothing more, nothing less :) > > > > All I need now to ban mp3 are inexpensive digital media playing > devices that support .ogg > Oh yah, and a script to do the conversion. -- Fedora Core 6 and proud From pemboa at gmail.com Fri Dec 1 17:55:38 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 1 Dec 2006 11:55:38 -0600 Subject: EASY FEDORA In-Reply-To: <20061201142234.3f88121e@dlara> References: <581965.81337.qm@web54310.mail.yahoo.com> <20061201142234.3f88121e@dlara> Message-ID: <16de708d0612010955u210b895fg5121c78cce0d168@mail.gmail.com> On 12/1/06, David Lara wrote: > El Fri, 1 Dec 2006 04:22:23 -0800 (PST) > "Frank S." escribi?: > > > Why don't you create an easy ferdora like (easy ubuntu)or a fedora > > mint (linux mint) for people new to linux. please do not get me wrong > > I love Fedora but to make it usable is a lot of work and I would > > never recomed to a friend because I would slave myself to his dektop. > > people NEED a dirty Fedora as you would call it. they will call it a > > usable OS. thank you so very much for your hard work!! > > Fedora is usable for me out-of-the-box. I can listen my music (Vorbis) > and watch my videos (Theora) without need to touch anything. > > Slave to desktop ? Sorry ? > > Oh, are you talking about people using propietary software like Adobe > Flash, slaved to x86 machines and operating systems that are in Adobe > whitelist (if you use BSD you are not allowed to use Flash, read the > Flash EULA) ? > > People needs to take care about the problem of closed source programs > and formats that make restrictions. Perhaps, some day Adobe will put > (for example) x86-32 bits systems on Flash blacklist. Must Fedora > ship Flash and support this software ? Or is better to promote > (coding, testing, translate) free alternatives like Gnash ? > > The same with MP3, MOV, etc... > > Btw, you can install this software without problems. This process is > well documented in WWW. Or use other distributions that don't care > about this things. Remeber what is Fedora: "It's the best combination > of robust and latest software that exists in the free software world". > Nothing more, nothing less :) > All I need now to ban mp3 are inexpensive digital media playing devices that support .ogg -- Fedora Core 6 and proud From lists at ralii.com Fri Dec 1 18:43:06 2006 From: lists at ralii.com (Robert Locke) Date: Fri, 01 Dec 2006 13:43:06 -0500 Subject: EASY FEDORA In-Reply-To: <16de708d0612010955u210b895fg5121c78cce0d168@mail.gmail.com> References: <581965.81337.qm@web54310.mail.yahoo.com> <20061201142234.3f88121e@dlara> <16de708d0612010955u210b895fg5121c78cce0d168@mail.gmail.com> Message-ID: <1164998586.12269.2.camel@localhost.localdomain> On Fri, 2006-12-01 at 11:55 -0600, Arthur Pemberton wrote: > On 12/1/06, David Lara wrote: > > El Fri, 1 Dec 2006 04:22:23 -0800 (PST) > > "Frank S." escribi?: > > > > > Why don't you create an easy ferdora like (easy ubuntu)or a fedora > > > mint (linux mint) for people new to linux. please do not get me wrong > > > I love Fedora but to make it usable is a lot of work and I would > > > never recomed to a friend because I would slave myself to his dektop. > > > people NEED a dirty Fedora as you would call it. they will call it a > > > usable OS. thank you so very much for your hard work!! > > > > Fedora is usable for me out-of-the-box. I can listen my music (Vorbis) > > and watch my videos (Theora) without need to touch anything. > > > > Slave to desktop ? Sorry ? > > > > Oh, are you talking about people using propietary software like Adobe > > Flash, slaved to x86 machines and operating systems that are in Adobe > > whitelist (if you use BSD you are not allowed to use Flash, read the > > Flash EULA) ? > > > > People needs to take care about the problem of closed source programs > > and formats that make restrictions. Perhaps, some day Adobe will put > > (for example) x86-32 bits systems on Flash blacklist. Must Fedora > > ship Flash and support this software ? Or is better to promote > > (coding, testing, translate) free alternatives like Gnash ? > > > > The same with MP3, MOV, etc... > > > > Btw, you can install this software without problems. This process is > > well documented in WWW. Or use other distributions that don't care > > about this things. Remeber what is Fedora: "It's the best combination > > of robust and latest software that exists in the free software world". > > Nothing more, nothing less :) > > > > All I need now to ban mp3 are inexpensive digital media playing > devices that support .ogg > I have been encoding my CDs into .ogg files after finding this player a few months ago (I believe there was a "review" of it in Red Hat Magazine), but check out the stuff from iAUDIO.... http://www.cowonamerica.com/products/iaudio/g3/ That is the one I bought so as not to worry about "recharging" and I just carry a spare AA around with me.... --Rob From franklinux392 at yahoo.com Fri Dec 1 20:40:03 2006 From: franklinux392 at yahoo.com (Frank S.) Date: Fri, 1 Dec 2006 12:40:03 -0800 (PST) Subject: Easy Fedora 2 Message-ID: <620278.95751.qm@web54302.mail.yahoo.com> Hi No i'm not talking about a Nvidia or flash. in my case, my only option for internet acces is wi-fi 802.11 how am I suppose to get madwifi or ndiswrap?? and what would you call the "clean Fedora" after installing this drivers to get my wifi 802.11 to work? and the same goes for winmodems. plus everybody installs all this Dirty softwar, what i'm asking is just to make it easyer to get it and install it, like an extra cd with all the warnings. I understand your crusade and applaud your determination that is very nobel from your side, but please have mercy on the user --------------------------------- Everyone is raving about the all-new Yahoo! Mail beta. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkeating at redhat.com Fri Dec 1 20:44:58 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Dec 2006 15:44:58 -0500 Subject: Easy Fedora 2 In-Reply-To: <620278.95751.qm@web54302.mail.yahoo.com> References: <620278.95751.qm@web54302.mail.yahoo.com> Message-ID: <200612011544.59207.jkeating@redhat.com> On Friday 01 December 2006 15:40, Frank S. wrote: > like an extra cd with all the warnings. Because often times that is illegal. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajackson at redhat.com Fri Dec 1 20:57:31 2006 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 01 Dec 2006 15:57:31 -0500 Subject: Easy Fedora 2 In-Reply-To: <620278.95751.qm@web54302.mail.yahoo.com> References: <620278.95751.qm@web54302.mail.yahoo.com> Message-ID: <1165006651.7683.109.camel@localhost.localdomain> On Fri, 2006-12-01 at 12:40 -0800, Frank S. wrote: > Hi > No i'm not talking about a Nvidia or flash. > in my case, my only option for internet acces is wi-fi 802.11 how am > I suppose to get madwifi or ndiswrap?? > and what would you call the "clean Fedora" after installing this > drivers to get > my wifi 802.11 to work? > and the same goes for winmodems. > plus everybody installs all this Dirty softwar, what i'm asking is > just to make it easyer to get it and install it, like an extra cd with > all the warnings. > I understand your crusade and applaud your determination that is very > nobel from your side, but please have mercy on the user Sorry, we're not going to compromise principles for convenience. This is about software that is free, not just software you don't have to pay money for. Even if we were, madwifi and ndiswrapper are fundamentally unsupportable from an engineering perspective. Having large blocks of code you can't fix is not a sustainable approach, and any distro that ships them - let alone claims to support them - is out of its mind, and is merely deferring the user's pain until runtime. - ajax From jam at zoidtechnologies.com Fri Dec 1 21:02:33 2006 From: jam at zoidtechnologies.com (jam at zoidtechnologies.com) Date: Fri, 1 Dec 2006 16:02:33 -0500 Subject: Easy Fedora 2 In-Reply-To: <200612011544.59207.jkeating@redhat.com> References: <620278.95751.qm@web54302.mail.yahoo.com> <200612011544.59207.jkeating@redhat.com> Message-ID: <20061201210233.GD19448@zoidtechnologies.com> On Fri, Dec 01, 2006 at 03:44:58PM -0500, Jesse Keating wrote: > On Friday 01 December 2006 15:40, Frank S. wrote: > > like an extra cd with all the warnings. > > Because often times that is illegal. > a valid point-- however users want these things and if it's "too difficult" to get them installed and operational they will go elsewhere. like the original poster, I applaud the idea of sticking to the guns and not shipping any "grey" content, but that does *not* solve the problem for the vast majority of potential fedora users, and the matter needs to be addressed rather soon if we want to have a serious set of desktop users. regards, J From mitr at volny.cz Fri Dec 1 21:04:11 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Fri, 01 Dec 2006 22:04:11 +0100 Subject: rawhide report: 20061201 changes In-Reply-To: <1164988422.13427.17.camel@kloczek01.pracownicy.zie> References: <200612011054.kB1AsMBf017076@hs20-bc2-6.build.redhat.com> <1164988422.13427.17.camel@kloczek01.pracownicy.zie> Message-ID: <457098CB.8040705@volny.cz> Hello, Tomasz K?oczko napsal(a): >> tcsh-6.14-13 >> ------------ >> * Thu Nov 30 2006 Miloslav Trmac - 6.14-13 >> - Link to ncurses instead of libtermcap >> - Fix some rpmlint warnings > Current ncurses patch changes: > > -AC_SEARCH_LIBS(tgetent, termlib termcap curses ncurses) > +AC_SEARCH_LIBS(tgetent, ncurses) > > Why not: > > -AC_SEARCH_LIBS(tgetent, termlib termcap curses ncurses) > +AC_SEARCH_LIBS(tgetent, ncursesw ncurses termlib termcap curses) Because I want the build to break if something unexpected happens and tcsh would link to termcap instead of ncurses. Checking for a single library is as deterministic as it gets, short of changing LIBS manually. > or even better (after build ncurses with --with-termlib): > > -AC_SEARCH_LIBS(tgetent, termlib termcap curses ncurses) > +AC_SEARCH_LIBS(tgetent, termlibw ncursesw termlib ncurses termcap > curses) > > Probably last form of this fix can be submited to tcsh maintainer for > include in dist source tree. I don't think the upstream would want to prefer ncurses to termcap (which is a potential behavior change) only because Fedora wants to remove one of them. tcsh is still used on a lot of quite old platforms, often by "old-school" system administrators; I wouldn't at all be surprised if some of them have hand-edited /etc/termcap with only the 5 necessary entries. Mirek BTW, > Please prepare fixes using mind not hands ;> Do you think this increases the likelihood of receiving a technical reply to your questions? From sundaram at fedoraproject.org Fri Dec 1 21:10:04 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Dec 2006 02:40:04 +0530 Subject: Easy Fedora 2 In-Reply-To: <20061201210233.GD19448@zoidtechnologies.com> References: <620278.95751.qm@web54302.mail.yahoo.com> <200612011544.59207.jkeating@redhat.com> <20061201210233.GD19448@zoidtechnologies.com> Message-ID: <45709A2C.4030005@fedoraproject.org> jam at zoidtechnologies.com wrote: > On Fri, Dec 01, 2006 at 03:44:58PM -0500, Jesse Keating wrote: >> On Friday 01 December 2006 15:40, Frank S. wrote: >>> like an extra cd with all the warnings. >> Because often times that is illegal. >> > > a valid point-- however users want these things and if it's "too difficult" > to get them installed and operational they will go elsewhere. like the > original poster, I applaud the idea of sticking to the guns and not shipping > any "grey" content, but that does *not* solve the problem for the vast > majority of potential fedora users, and the matter needs to be addressed > rather soon if we want to have a serious set of desktop users. Claiming that we need to address them without providing a good way to solve that while not compromising on our principles is not a solution. If you have a good way to enhance the desktop experience without including or supporting non-free software, feel free to suggest that. Its also important to recognize that non-free software often has practical limitations of not being ported across all the architectures that Fedora supports and we dont have a good way to fix problems that arise out of it. Rahul From jkeating at redhat.com Fri Dec 1 21:14:14 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 1 Dec 2006 16:14:14 -0500 Subject: Easy Fedora 2 In-Reply-To: <20061201210233.GD19448@zoidtechnologies.com> References: <620278.95751.qm@web54302.mail.yahoo.com> <200612011544.59207.jkeating@redhat.com> <20061201210233.GD19448@zoidtechnologies.com> Message-ID: <200612011614.20403.jkeating@redhat.com> On Friday 01 December 2006 16:02, jam at zoidtechnologies.com wrote: > a valid point-- however users want these things and if it's "too difficult" > to get them installed and operational they will go elsewhere. like the > original poster, I applaud the idea of sticking to the guns and not > shipping any "grey" content, but that does *not* solve the problem for the > vast majority of potential fedora users, and the matter needs to be > addressed rather soon if we want to have a serious set of desktop users. Just how do you expect us to "address" the fact that its illegal? I'm sorry, but we're not just going to ignore the law and hope "The Man" doesn't notice. But aside from that, principles are important, and our distribution is based on those principles. We can't be everything for everyone, and trying to be so is a losing battle. There are some legal ways of getting some things onto your system, but we are not in the business of being enablers. There are fundamental reasons we don't include some software, nor make it "easy" to access. Also see ajax's response. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From cmadams at hiwaay.net Fri Dec 1 21:46:28 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 1 Dec 2006 15:46:28 -0600 Subject: Easy Fedora 2 In-Reply-To: <45709A2C.4030005@fedoraproject.org> References: <620278.95751.qm@web54302.mail.yahoo.com> <200612011544.59207.jkeating@redhat.com> <20061201210233.GD19448@zoidtechnologies.com> <45709A2C.4030005@fedoraproject.org> Message-ID: <20061201214628.GF1246559@hiwaay.net> Once upon a time, Rahul Sundaram said: > Claiming that we need to address them without providing a good way to > solve that while not compromising on our principles is not a solution. > If you have a good way to enhance the desktop experience without > including or supporting non-free software, feel free to suggest that. > > Its also important to recognize that non-free software often has > practical limitations of not being ported across all the architectures > that Fedora supports and we dont have a good way to fix problems that > arise out of it. Is there any possibility of shipping the things that are legal and do work across platforms: firmware? For example, I have an Intel wireless card that uses the ipw2200 driver and firmware. I know there was discussion from (IIRC) OpenBSD with various vendors about the licenses for firmware distribution; did any of that go anywhere? What is the Fedora Project's stand on firmware distribution? Could there at least be a pointer included somewhere for where to get firmware? Unlike some other additional software, it is legal to distribute the Intel firmware for example (at least the way I read the license). Maybe there could be a "non-free" that includes software that is legal but under more restrictive licenses (there aren't many things that fall in that category). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From ajackson at redhat.com Fri Dec 1 21:49:00 2006 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 01 Dec 2006 16:49:00 -0500 Subject: Easy Fedora 2 In-Reply-To: <20061201214628.GF1246559@hiwaay.net> References: <620278.95751.qm@web54302.mail.yahoo.com> <200612011544.59207.jkeating@redhat.com> <20061201210233.GD19448@zoidtechnologies.com> <45709A2C.4030005@fedoraproject.org> <20061201214628.GF1246559@hiwaay.net> Message-ID: <1165009740.7683.116.camel@localhost.localdomain> On Fri, 2006-12-01 at 15:46 -0600, Chris Adams wrote: > What is the Fedora Project's stand on firmware distribution? Must be transitively redistributable with no restrictions on deployment (eg, the usual Windows-style EULA where you can download it once to use on a single computer is not okay). We may have other requirements, though none spring to mind. We are working with Intel on the 2200 firmware license though. - ajax From alan at redhat.com Fri Dec 1 21:53:53 2006 From: alan at redhat.com (Alan Cox) Date: Fri, 1 Dec 2006 16:53:53 -0500 Subject: Easy Fedora 2 In-Reply-To: <20061201210233.GD19448@zoidtechnologies.com> References: <620278.95751.qm@web54302.mail.yahoo.com> <200612011544.59207.jkeating@redhat.com> <20061201210233.GD19448@zoidtechnologies.com> Message-ID: <20061201215353.GA14951@devserv.devel.redhat.com> On Fri, Dec 01, 2006 at 04:02:33PM -0500, jam at zoidtechnologies.com wrote: > a valid point-- however users want these things and if it's "too difficult" > to get them installed and operational they will go elsewhere. So heroin should be sold on street corners because if its difficult the users go elsewhere ? > any "grey" content, but that does *not* solve the problem for the vast > majority of potential fedora users, and the matter needs to be addressed > rather soon if we want to have a serious set of desktop users. Agreed. Irritate your congresscritters, continue to lobby for further and stronger patent reform. Alan From sundaram at fedoraproject.org Fri Dec 1 21:57:54 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 02 Dec 2006 03:27:54 +0530 Subject: Easy Fedora 2 In-Reply-To: <20061201214628.GF1246559@hiwaay.net> References: <620278.95751.qm@web54302.mail.yahoo.com> <200612011544.59207.jkeating@redhat.com> <20061201210233.GD19448@zoidtechnologies.com> <45709A2C.4030005@fedoraproject.org> <20061201214628.GF1246559@hiwaay.net> Message-ID: <4570A562.6090501@fedoraproject.org> Chris Adams wrote: > Is there any possibility of shipping the things that are legal and do > work across platforms: firmware? For example, I have an Intel wireless > card that uses the ipw2200 driver and firmware. I know there was > discussion from (IIRC) OpenBSD with various vendors about the licenses > for firmware distribution; did any of that go anywhere? Yes, Some licensing changes are expected. Red Hat is still working with Intel on this last I heard. > > What is the Fedora Project's stand on firmware distribution? The current stand is documented in http://fedoraproject.org/wiki/Packaging/Guidelines#BinaryFirmware. In short we require unrestricted redistribution rights on the minimum. There is also http://fedoraproject.org/wiki/FreeSoftwareAnalysis. > Could there at least be a pointer included somewhere for where to get > firmware? Sure but even better see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217350. In some cases, the licenses are unclear and need to go through a formal legal review too as with other packages. Unlike some other additional software, it is legal to > distribute the Intel firmware for example (at least the way I read the > license). Maybe there could be a "non-free" that includes software that > is legal but under more restrictive licenses (there aren't many things > that fall in that category). We arent planning to introduce any non-free repositories within the distribution. If they are legal but non-free repositories out there we might consider pointing to them with appropriate disclaimers however. Rahul From gilboad at gmail.com Fri Dec 1 22:45:14 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 02 Dec 2006 00:45:14 +0200 Subject: Easy Fedora 2 In-Reply-To: <20061201210233.GD19448@zoidtechnologies.com> References: <620278.95751.qm@web54302.mail.yahoo.com> <200612011544.59207.jkeating@redhat.com> <20061201210233.GD19448@zoidtechnologies.com> Message-ID: <1165013114.13340.10.camel@gilboa-home-dev.localdomain> On Fri, 2006-12-01 at 16:02 -0500, jam at zoidtechnologies.com wrote: > On Fri, Dec 01, 2006 at 03:44:58PM -0500, Jesse Keating wrote: > > On Friday 01 December 2006 15:40, Frank S. wrote: > > > like an extra cd with all the warnings. > > > > Because often times that is illegal. > > > > a valid point-- however users want these things and if it's "too difficult" > to get them installed and operational they will go elsewhere. like the > original poster, I applaud the idea of sticking to the guns and not shipping > any "grey" content, but that does *not* solve the problem for the vast > majority of potential fedora users, and the matter needs to be addressed > rather soon if we want to have a serious set of desktop users. > > regards, > J > Addressed how? IANAL, but AFAIK any attempt to make gray content distribution easier (E.g. Press here to download illegal X) makes you an accomplice in the distribution of illegal content X. - Gilboa From dmalcolm at redhat.com Fri Dec 1 22:51:37 2006 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 01 Dec 2006 17:51:37 -0500 Subject: Easy Fedora 2 In-Reply-To: <1165013114.13340.10.camel@gilboa-home-dev.localdomain> References: <620278.95751.qm@web54302.mail.yahoo.com> <200612011544.59207.jkeating@redhat.com> <20061201210233.GD19448@zoidtechnologies.com> <1165013114.13340.10.camel@gilboa-home-dev.localdomain> Message-ID: <1165013497.21217.27.camel@cassandra.boston.redhat.com> On Sat, 2006-12-02 at 00:45 +0200, Gilboa Davara wrote: > On Fri, 2006-12-01 at 16:02 -0500, jam at zoidtechnologies.com wrote: > > On Fri, Dec 01, 2006 at 03:44:58PM -0500, Jesse Keating wrote: > > > On Friday 01 December 2006 15:40, Frank S. wrote: > > > > like an extra cd with all the warnings. > > > > > > Because often times that is illegal. > > > > > > > a valid point-- however users want these things and if it's "too difficult" > > to get them installed and operational they will go elsewhere. like the > > original poster, I applaud the idea of sticking to the guns and not shipping > > any "grey" content, but that does *not* solve the problem for the vast > > majority of potential fedora users, and the matter needs to be addressed > > rather soon if we want to have a serious set of desktop users. > > > > regards, > > J > > > > Addressed how? > IANAL, but AFAIK any attempt to make gray content distribution easier > (E.g. Press here to download illegal X) makes you an accomplice in the > distribution of illegal content X. > "lobby-buddy" - a helper app similar to "bug-buddy", but tries to detect what country and electoral region you're in, what the legal issue is, and lets you easily generate a letter to the appropriate elected representative? From pemboa at gmail.com Fri Dec 1 22:57:38 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 2 Dec 2006 16:57:38 +1800 Subject: Easy Fedora 2 In-Reply-To: <620278.95751.qm@web54302.mail.yahoo.com> References: <620278.95751.qm@web54302.mail.yahoo.com> Message-ID: <16de708d0612011457k13441db2s3110431cf3352142@mail.gmail.com> On 12/2/06, Frank S. wrote: > Hi > No i'm not talking about a Nvidia or flash. > in my case, my only option for internet acces is wi-fi 802.11 how am I > suppose to get madwifi or ndiswrap?? > and what would you call the "clean Fedora" after installing this drivers to > get > my wifi 802.11 to work? > and the same goes for winmodems. > plus everybody installs all this Dirty softwar, what i'm asking is just to > make it easyer to get it and install it, like an extra cd with all the > warnings. > I understand your crusade and applaud your determination that is very nobel > from your side, but please have mercy on the user 1) Fedora is in it for the pricinple of the matter 2) Fedora is sponsored by an American company, and is based in America where laws apperently forbid a lot of things that would make things easier on the user 3) from 2, if you're an American, right your representative and complain 4) If you're not an american, get some people together and derive a distro from Fedora, should be much work as all you will be chaning is adding the "dirty" stuff 5) remember, Fedora as a community want you as a user, but there are things that the community just isn't prepared to do to keep you (for better or worse) Peace. Oh yah, frankly I think all this legal stuff sucks balls and that all distros should just ignore it all, but that's just not how stuff works for now. -- Fedora Core 6 and proud From gilboad at gmail.com Fri Dec 1 23:13:53 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 02 Dec 2006 01:13:53 +0200 Subject: Easy Fedora 2 In-Reply-To: <1165013497.21217.27.camel@cassandra.boston.redhat.com> References: <620278.95751.qm@web54302.mail.yahoo.com> <200612011544.59207.jkeating@redhat.com> <20061201210233.GD19448@zoidtechnologies.com> <1165013114.13340.10.camel@gilboa-home-dev.localdomain> <1165013497.21217.27.camel@cassandra.boston.redhat.com> Message-ID: <1165014833.13340.23.camel@gilboa-home-dev.localdomain> On Fri, 2006-12-01 at 17:51 -0500, David Malcolm wrote: > On Sat, 2006-12-02 at 00:45 +0200, Gilboa Davara wrote: > > On Fri, 2006-12-01 at 16:02 -0500, jam at zoidtechnologies.com wrote: > > > On Fri, Dec 01, 2006 at 03:44:58PM -0500, Jesse Keating wrote: > > > > On Friday 01 December 2006 15:40, Frank S. wrote: > > > > > like an extra cd with all the warnings. > > > > > > > > Because often times that is illegal. > > > > > > > > > > a valid point-- however users want these things and if it's "too difficult" > > > to get them installed and operational they will go elsewhere. like the > > > original poster, I applaud the idea of sticking to the guns and not shipping > > > any "grey" content, but that does *not* solve the problem for the vast > > > majority of potential fedora users, and the matter needs to be addressed > > > rather soon if we want to have a serious set of desktop users. > > > > > > regards, > > > J > > > > > > > Addressed how? > > IANAL, but AFAIK any attempt to make gray content distribution easier > > (E.g. Press here to download illegal X) makes you an accomplice in the > > distribution of illegal content X. > > > "lobby-buddy" - a helper app similar to "bug-buddy", but tries to detect > what country and electoral region you're in, what the legal issue is, > and lets you easily generate a letter to the appropriate elected > representative? Sound's like a great idea. (Unless you live in say, China (or Cuba)... I'd guess that sending such a letter in there might get into the organ donor list... -fast-) * - Gilboa * Just a joke. Stupid one. Don't know what got over me. Please don't kill me. Thanks. /me start singing the national Chinese anthem. From chris at idlelion.net Fri Dec 1 23:15:08 2006 From: chris at idlelion.net (chris at idlelion.net) Date: Fri, 1 Dec 2006 17:15:08 -0600 (CST) Subject: Easy Fedora 2 In-Reply-To: <20061201225144.07C8D73484@hormel.redhat.com> References: <20061201225144.07C8D73484@hormel.redhat.com> Message-ID: > From: Alan Cox >> any "grey" content, but that does *not* solve the problem for the vast >> majority of potential fedora users, and the matter needs to be >> addressed rather soon if we want to have a serious set of desktop >> users. > Agreed. Irritate your congresscritters, continue to lobby for further > and stronger patent reform. > Alan And buy hardware from manufacturers who support Linux or at least make their specifications available so people can write drivers. A clearer list of those hardware vendors would be welcome (at least by me) as would some advocacy in the line of "Fedora endorses these hardware vendors for their support of Linux." Chris From david at lovesunix.net Fri Dec 1 23:16:33 2006 From: david at lovesunix.net (David Nielsen) Date: Sat, 02 Dec 2006 00:16:33 +0100 Subject: Easy Fedora 2 In-Reply-To: <1165013497.21217.27.camel@cassandra.boston.redhat.com> References: <620278.95751.qm@web54302.mail.yahoo.com> <200612011544.59207.jkeating@redhat.com> <20061201210233.GD19448@zoidtechnologies.com> <1165013114.13340.10.camel@gilboa-home-dev.localdomain> <1165013497.21217.27.camel@cassandra.boston.redhat.com> Message-ID: <4570B7D1.3070308@lovesunix.net> David Malcolm skrev: > On Sat, 2006-12-02 at 00:45 +0200, Gilboa Davara wrote: > >> On Fri, 2006-12-01 at 16:02 -0500, jam at zoidtechnologies.com wrote: >> >>> On Fri, Dec 01, 2006 at 03:44:58PM -0500, Jesse Keating wrote: >>> >>>> On Friday 01 December 2006 15:40, Frank S. wrote: >>>> >>>>> like an extra cd with all the warnings. >>>>> >>>> Because often times that is illegal. >>>> >>>> >>> a valid point-- however users want these things and if it's "too difficult" >>> to get them installed and operational they will go elsewhere. like the >>> original poster, I applaud the idea of sticking to the guns and not shipping >>> any "grey" content, but that does *not* solve the problem for the vast >>> majority of potential fedora users, and the matter needs to be addressed >>> rather soon if we want to have a serious set of desktop users. >>> >>> regards, >>> J >>> >>> >> Addressed how? >> IANAL, but AFAIK any attempt to make gray content distribution easier >> (E.g. Press here to download illegal X) makes you an accomplice in the >> distribution of illegal content X. >> >> > "lobby-buddy" - a helper app similar to "bug-buddy", but tries to detect > what country and electoral region you're in, what the legal issue is, > and lets you easily generate a letter to the appropriate elected > representative I like it.. it's a great educational tool - David From ajackson at redhat.com Fri Dec 1 23:55:33 2006 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 01 Dec 2006 18:55:33 -0500 Subject: Easy Fedora 2 In-Reply-To: References: <20061201225144.07C8D73484@hormel.redhat.com> Message-ID: <1165017333.7683.128.camel@localhost.localdomain> On Fri, 2006-12-01 at 17:15 -0600, chris at idlelion.net wrote: > > From: Alan Cox > > >> any "grey" content, but that does *not* solve the problem for the vast > >> majority of potential fedora users, and the matter needs to be > >> addressed rather soon if we want to have a serious set of desktop > >> users. > > > Agreed. Irritate your congresscritters, continue to lobby for further > > and stronger patent reform. > > > Alan > > And buy hardware from manufacturers who support Linux or at least make > their specifications available so people can write drivers. > > A clearer list of those hardware vendors would be welcome (at least by me) > as would some advocacy in the line of "Fedora endorses these hardware > vendors for their support of Linux." Start with http://www.vendorwatch.org/ - ajax From michel.salim at gmail.com Sat Dec 2 02:38:52 2006 From: michel.salim at gmail.com (Michel Salim) Date: Fri, 1 Dec 2006 21:38:52 -0500 Subject: Logged out from X during yum update In-Reply-To: References: Message-ID: <883cfe6d0612011838o1785297ep2c3f81526a05709@mail.gmail.com> 2006/12/1, Gianluca Sforna : > I am installing FC-6 onto a brand new server (HP ProLiant ML 350 G5); > my usual PXE+HTTP installation went just fine. > > However, during the first update, I was logged out from X and returned > to the gdm screen. > Saw this yesterday. Not exactly logged out, but gnome-panel behaved bizarrely (menus and some applets disappeared, but without dialog boxes asking to reload) - and could not be restarted. I had to log out and back in, and then things work normally. -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From jspaleta at gmail.com Sat Dec 2 03:08:48 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 1 Dec 2006 18:08:48 -0900 Subject: Easy Fedora 2 In-Reply-To: <20061201210233.GD19448@zoidtechnologies.com> References: <620278.95751.qm@web54302.mail.yahoo.com> <200612011544.59207.jkeating@redhat.com> <20061201210233.GD19448@zoidtechnologies.com> Message-ID: <604aa7910612011908g6b03979fn72732f657c37446f@mail.gmail.com> On 12/1/06, jam at zoidtechnologies.com wrote: > a valid point-- however users want these things and if it's "too difficult" i want a pony. It's over there in that field marked no traspassing. All you have to do is open the gate and go get it and bring it to me. Give me that pony. Give it to me now. No, I don't mind if its dead. No, feel free to keep beating it after its dead, I still want it. > to get them installed and operational they will go elsewhere. Having everyone use fedora.. is not the point. It absolutely is not the point. The point is building a future where everyone, everywhere, has equal access to the tools to be self-sufficient digital technology builders and consumers, We are not going to shirk the responsibility for the sake of today's proprietary technological whims. Its a waste of effort and a road to nowhere. The scare resource is not userbase, the scarce resource is competent technical development manpower, especially hardware specific competence. It would be a nearly criminal mismanagement of resources to expend developer time on technology that could not be openly diagnosed and fixed. We shall not offer technology that we can not supoport as a community. We shall not offer technology that we can not legally provide to everyone. > like the original poster, I applaud the idea of sticking to the guns and not shipping > any "grey" content, but that does *not* solve the problem for the vast > majority of potential fedora users, and the matter needs to be addressed > rather soon if we want to have a serious set of desktop users. So what if we don't win a sizable fraction of today's desktops? That has never been the goal. I will state, emphatically, that we have more than enough Fedora desktop users right now, to continue to drive interest in development of desktop components of Fedora forward. No rational person can argue otherwise. The grotesquely productivity-destroying desktop effects in FC6 are but one example of continued progress in desktop development, which sadly works just fine on my intel box with integrated graphics. The future of this project does not need a significant injection of additional desktop users to flourish.. and we have no reason to be greedy about collecting them. Desktop users are not pogs and they are not pokemon.. we do not in fact have a mandate to collect even most of them. If people do not want to use Fedora as their desktop and would prefer another Linux distribution, that is an absolutely acceptable outcome. Choice is good, we do not have to be the best choice for most people right now, or tomorrow, or next year. All we need to do is concentrate on building better choices for everyone in the long run. And I will also, emphatically state, that future users need a complete open source technology stack far far more than most of them currently realize. Fedora is working on that critical long term need, in unsung heroic fashion. -jef"I'm more than happy to see Fedora skip the desktop paradigm completely and focus on what comes next: neural implants, dophin-friendly computing, olpc"spaleta From saikat at cs.cornell.edu Sat Dec 2 06:14:47 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Sat, 02 Dec 2006 01:14:47 -0500 Subject: no portmap, nfs, ypbind after rawhide update Message-ID: <1165040088.18885.13.camel@localhost.localdomain> I just updated rawhide and portmap has started segfaulting on startup. So no nfs, nis etc. (gdb) r -dv Starting program: /sbin/portmap -dv Program received signal SIGSEGV, Segmentation fault. 0x00002aaaaafd0d69 in svc_run () from /lib64/libc.so.6 (gdb) bt #0 0x00002aaaaafd0d69 in svc_run () from /lib64/libc.so.6 #1 0x0000555555557a59 in main (argc=, argv=) at portmap.c:245 Running: glibc-2.5.90-8 Has anyone else encountered this? Or should I start downgrading libc to see where it was introduced. cheers, -- Saikat -------------- 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 saikat at cs.cornell.edu Sat Dec 2 06:21:27 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Sat, 02 Dec 2006 01:21:27 -0500 Subject: no portmap, nfs, ypbind after rawhide update In-Reply-To: <1165040088.18885.13.camel@localhost.localdomain> References: <1165040088.18885.13.camel@localhost.localdomain> Message-ID: <1165040487.18885.16.camel@localhost.localdomain> On Sat, 2006-12-02 at 01:14 -0500, Saikat Guha wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x00002aaaaafd0d69 in svc_run () from /lib64/libc.so.6 Nevermind. Bug #217850: Should be fixed in glibc-2.5.90-10 in rawhide cheers, -- Saikat -------------- 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 arjan at fenrus.demon.nl Sat Dec 2 07:59:51 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sat, 02 Dec 2006 08:59:51 +0100 Subject: Easy Fedora 2 In-Reply-To: <620278.95751.qm@web54302.mail.yahoo.com> References: <620278.95751.qm@web54302.mail.yahoo.com> Message-ID: <1165046391.3233.136.camel@laptopd505.fenrus.org> > in my case, my only option for internet acces is wi-fi 802.11 how am > I suppose to get madwifi or ndiswrap?? madwifi is reverse engineered for a while now, and recently the Software Freedom Law Center lawyers have judged that as being done ok; so expect to see a real free driver for that hardware soon, and once it exists I'm sure it'll be in fedora proper > and the same goes for winmodems. for winmodems there is a legal solution at least; just use the alsa sound driver + the userspace daemon that "whistles" modem noises into the "sound card". but I pitty everyone who still needs to use a modem. It's... painful. From buildsys at redhat.com Sat Dec 2 10:56:53 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 2 Dec 2006 05:56:53 -0500 Subject: rawhide report: 20061202 changes Message-ID: <200612021056.kB2AurHF021516@hs20-bc2-6.build.redhat.com> Updated Packages: apr-util-1.2.7-5 ---------------- * Fri Dec 01 2006 Joe Orton 1.2.7-5 - really rebuild for db45 audit-1.3-3.fc7 --------------- * Thu Nov 30 2006 Steve Grubb 1.3-3 - Fix timestamp for libaudit.conf (#218053) authconfig-5.3.12-1.fc7 ----------------------- binutils-2.17.50.0.7-1 ---------------------- * Fri Dec 01 2006 Jakub Jelinek 2.17.50.0.7-1 - update to 2.17.50.0.7 - .cfi_personality and .cfi_lsda directives, per subsection .cfi_* directives, better .eh_frame CIE merging cadaver-0.22.3-6 ---------------- * Fri Dec 01 2006 Joe Orton 0.22.3-6 - BR ncurses-devel, fix readline support foomatic-3.0.2-42.fc7 --------------------- * Thu Nov 30 2006 Tim Waugh 3.0.2-42 - Updated db to 3.0-20061130. freetype-2.2.1-15.fc6 --------------------- * Mon Nov 27 2006 Behdad Esfahbod 2.2.1-15 - Fix rendering issue with some Asian fonts. - Add freetype-2.2.1-fix-get-orientation.patch - Resolves: #207261 frysk-0.0.1.2006.12.01.rh1-2.fc7 -------------------------------- * Fri Dec 01 2006 Stepan Kasal - 0.0.1.2006.12.01.rh1-2 - Relates: #211775 - The ppc64 build works again. * Fri Dec 01 2006 Stepan Kasal - 0.0.1.2006.12.01.rh1-1 - New upstream version. - Resolves: #211288. gcc-4.1.1-44 ------------ * Fri Dec 01 2006 Jakub Jelinek 4.1.1-44 - fix OpenMP loops with 0 iterations (PR libgomp/29949) * Thu Nov 30 2006 Jakub Jelinek 4.1.1-43 - update from gcc-4_1-branch (-r119167:119343) - PRs c++/29022, fortran/29391, fortran/29489, fortran/29982, libgfortran/29936, target/29319, tree-opt/29964 - fix -fopenmp ICEs on omp constructs where the body never returns (PR middle-end/29965) * Fri Nov 24 2006 Jakub Jelinek 4.1.1-42 - update from gcc-4_1-branch (-r119021:119167) - fix s390{,x} __sync_* builtins - fix ppc64 libffi unwind info glibc-2.5.90-10 --------------- * Fri Dec 01 2006 Jakub Jelinek 2.5.90-10 - fix x86-64 restore_rt unwind info * Thu Nov 30 2006 Jakub Jelinek 2.5.90-9 - fix last svc_run change (#217850) - on ppc64 build __libc_start_main without unwind info, as it breaks MD_FROB_UPDATE_CONTEXT (#217729, #217775; in the future that could be fixable just by providing .cfi_undefined r2 in __libc_start_main instead) - add unwind info for x86-64 restore_rt signal return landing pad (#217087) - add power6x subdir to /lib/ and /lib/rtkaio/, link all libs from ../power6/* into them gnome-netstatus-2.12.0-6.fc7 ---------------------------- * Fri Dec 01 2006 Adam Jackson - 2.12.0-6 - Bump to fix 6 to 7 upgrades. gnome-pilot-2.0.15-3.fc7 ------------------------ * Fri Dec 01 2006 Matthew Barnes - 2.0.15-3.fc7 - Remove patch for GNOME bug #362565 (fixed upstream). gnupg-1.4.5-9 ------------- * Fri Dec 01 2006 Nalin Dahyabhai - 1.4.5-9 - rebuild - give configure a --with-termlib option which can be used to force the selection of libtermcap or libncurses, but don't flip the switch yet * Fri Dec 01 2006 Nalin Dahyabhai - 1.4.5-8 - rebuild * Fri Dec 01 2006 Nalin Dahyabhai - 1.4.5-7 - rebuild gnuplot-4.0.0-13 ---------------- * Fri Dec 01 2006 Ivana Varekova - 4.0.0-13 - rebuild against libncurses gphoto2-2.2.0-4.fc7 ------------------- * Fri Dec 01 2006 Jindrich Novy 2.2.0-4 - nuke useless PreReq and BuildRequires iproute-2.6.18-4.fc7 -------------------- * Fri Dec 01 2006 Radek Vok??l - 2.6.18-4 - spec file cleanup - one more rebuilt against db4 libXfont-1.2.5-1.fc7 -------------------- * Fri Dec 01 2006 Adam Jackson 1.2.5-1 - Update to 1.2.5 from upstream. Drops CID font support. * Sat Nov 25 2006 Adam Jackson 1.2.3-4.fc7 - Revert the namespace whatsit until xfs is sorted out. * Mon Nov 20 2006 Adam Jackson 1.2.3-3.fc7 - libXdmcp-1.0.2-namespace-pollution.patch: One more collision avoider. lvm2-2.02.16-1.fc7 ------------------ * Fri Dec 01 2006 Alasdair Kergon - 2.02.16-1 - Fix VG clustered read locks to use PR not CR. - Adjust some alignments for ia64/sparc. - Fix mirror segment removal to use temporary error segment. - Always compile debug logging into clvmd. - Add startup timeout to clvmd startup script. - Add -T (startup timeout) switch to clvmd. - Improve lvm_dump.sh robustness. man-pages-2.43-1.fc7 -------------------- * Fri Dec 01 2006 Ivana Varekova 2.43-1 - update to 2.43 - fix mount.2 man page (#211608) * Fri Oct 20 2006 Ivana Varekova 2.41-2 - fix mmap(2) man page * Fri Oct 20 2006 Ivana Varekova 2.41-1 - update to 2.41 policycoreutils-1.33.6-2.fc7 ---------------------------- * Fri Dec 01 2006 Dan Walsh 1.33.6-2 - Update po files Resolves: #216920 * Wed Nov 29 2006 Dan Walsh 1.33.6-1 - Update to upstream * Patch from Dan Walsh to add an pam_acct_msg call to run_init * Patch from Dan Walsh to fix error code returns in newrole * Patch from Dan Walsh to remove verbose flag from semanage man page * Patch from Dan Walsh to make audit2allow use refpolicy Makefile in /usr/share/selinux/ ppp-2.4.4-2 ----------- * Fri Dec 01 2006 Thomas Woerner 2.4.4-2 - fixed build requirement for libpcap (#217661) prelink-0.3.10-1 ---------------- * Fri Dec 01 2006 Jakub Jelinek 0.3.10-1 - MIPS support (Richard Sandiford) - don't leave temporary files behind on prelink --verify failures (#199251) pykickstart-0.41-1.fc7 ---------------------- * Fri Dec 01 2006 Chris Lumens - 0.41-1 - Fix traceback when using deprecated commands (#218047, #218059). scim-1.4.5-6.fc7 ---------------- * Fri Dec 01 2006 Jens Petersen - 1.4.5-6 - fix scim-restart quoting for pkill -f - rename scim-turn-off-snooper.patch to scim-gtkimm-default-snooper-off-213796.patch * Fri Dec 01 2006 Jens Petersen - 1.4.5-5 - move dl modules used by im-scim.so back to scim-libs for multilib (#215583) - revert gtkimm-clear-preedit-on-reset-174143.patch for now to be consistent with scim-bridge and upstream behaviour (#174143) - improve scim-restart to also restart xim socket and only kill user's own processes (#205547) * Fri Nov 24 2006 Shawn Huang - 1.4.5-4 - add scim-gtkimm-default-snooper-off-213796.patch to turn off key snooper in im-scim to avoid crashes when clicking during scim gtkimm preedit (#213796) selinux-policy-2.4.6-5.fc7 -------------------------- * Fri Dec 01 2006 Dan Walsh 2.4.6-5 - More fixes for quota Resolves: #212957 * Fri Dec 01 2006 Dan Walsh 2.4.6-4 - ncsd needs to use avahi sockets Resolves: #217640 Resolves: #218014 setroubleshoot-1.8.5-1.fc7 -------------------------- * Fri Dec 01 2006 John Dennis - 1.8.5-1 - fix bug, "could not convert path to a GtkTreePath" when database is initially empty, caused by last_selected_row == None setuptool-1.19.2-2 ------------------ * Fri Dec 01 2006 Nalin Dahyabhai 1.19.2-2 - rebuild * Thu Nov 30 2006 Nalin Dahyabhai 1.19.2-1 - update more translations (#216494) system-config-soundcard-2.0.5-2.fc7 ----------------------------------- * Fri Dec 01 2006 Adam Jackson 2.0.5-2 - Bump to fix 6 to 7 upgrades. xinetd-2:2.3.14-10 ------------------ * Fri Dec 01 2006 James Antill - 2:2.3.14-9 - Fix getpeercon() for LABELED networking MLS environments - Resolves: rhbz#209379 xorg-x11-drv-mga-1.4.5-1.fc7 ---------------------------- * Fri Dec 01 2006 Adam Jackson 1.4.5-1 - Update to 1.4.5. xorg-x11-drv-mouse-1.2.1-1.fc7 ------------------------------ * Fri Dec 01 2006 Adam Jackson 1.2.1-1 - Update to 1.2.1 xorg-x11-drv-nv-1.2.1-1.fc7 --------------------------- * Fri Dec 01 2006 Adam Jackson 1.2.1-1 - Update to 1.2.1 xorg-x11-drv-sis-0.9.3-1.fc7 ---------------------------- * Fri Dec 01 2006 Adam Jackson 0.9.3-1 - Update to 0.9.3 * Sun Oct 01 2006 Jesse Keating - 0.9.1-7 - rebuilt for unwind info generation, broken in gcc-4.1.1-21 * Wed Sep 20 2006 Adam Jackson 0.9.1-6 - sis-0.9.1-assert.patch: Include assert.h so we don't crash. xorg-x11-server-1.1.1-54.fc7 ---------------------------- * Fri Dec 01 2006 Adam Jackson 1.1.1-54.fc7 - xorg-x11-server-1.1.1-xkb-vidmode-switch.patch: Fix string matching on XKB actions to be case-insensitive again. (#216656) * Fri Dec 01 2006 Adam Jackson 1.1.1-53.fc7 - xorg-x11-server-1.1.1-automake-1.10-fixes.patch: Tweak automakefiles to be 1.10-compliant. - Misc spec fixes. * Mon Nov 27 2006 Adam Jackson 1.1.1-52.fc7 - RHEL5 sync: - Deliver SecurityPolicy in Xvfb when !with_hw_servers (s390, s390x) - xorg-x11-server-1.1.1-ia64-int10.patch: Fix int10 on ia64. - xorg-x11-server-1.1.1-ia64-pci-chipsets.patch: ia64 PCI chipset support. - Unify the autoconfig patches. - xorg-x11-server-1.1.1-xf86config-comment-less.patch: Added, makes pyxf86config not grow the config file every time it's run. - Remove with_developer_utils macro. xorg-x11-util-macros-1.1.3-1.fc7 -------------------------------- * Fri Dec 01 2006 Adam Jackson 1.1.3-1 - Update to 1.1.3 ypbind-3:1.19-7.fc7 ------------------- * Fri Dec 01 2006 Steve Dickson - 3:1.19-7 - Fixed leaking ports (bz 217874) - Log all server bindings (bz 217782) - Added better quoting to init script (bz 216739) Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 From zrchrn at gmail.com Sat Dec 2 17:27:26 2006 From: zrchrn at gmail.com (Ahm ed) Date: Sat, 2 Dec 2006 12:27:26 -0500 Subject: on the Easy Fedora 2 issue Message-ID: There are two packges that are planned for Fedora, Im sure you have heard by now, pungi and pilgrim. These two will allow you to re-spin the Fedora install cds into another install cd(s), in the case of pungi or a live cd, in the case of pilgrim. From what I understand if you are simply using packages from the default fedora repos, you CAN keep the fedora logo. IF you are adding non-free packages or even free packages that are NOT from the default Fedora repos, then you must rebrand. I suspect these tools will help you do this re-branding, though I am not sure (it would be a good idea anyways, since it keeps people from have the excuse that they didn't know how to rebrand the distro). In this way you can build your on distro, with minimal fuss. Simply grab the neccessary packages from their appropriate repos(or build them) and then build the cd. you can then give that cd to your "new-to-linux" friends. You can then call in easy linux or something, and brand it really quick with something of your choosing. This way your friend doesn't have to worry about things "not-working", you don't have to be a "slave to his desktop" and nobody can say that fedora violated it's own principals. Alternatively, you can give him the default fedora cds with the fedorafrog script which will add all the non-free stuff he would need. I hope this helps ~Ahmed -------------- next part -------------- An HTML attachment was scrubbed... URL: From benny+usenet at amorsen.dk Sat Dec 2 17:39:05 2006 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 02 Dec 2006 18:39:05 +0100 Subject: removing termcap References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061127163751.GD29814@nostromo.devel.redhat.com> <1164655125.3195.2.camel@rousalka.dyndns.org> <20061130101846.GA31756@petra.dvoda.cz> Message-ID: >>>>> "KZ" == Karel Zak writes: KZ> rescue mode KZ> The root partition has to be useful and consistent in itself. KZ> Karel If /usr was gone and everything was in /, the root partition would be useful and consistent by itself. Obviously. /Benny From fedora at camperquake.de Sat Dec 2 20:01:58 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 2 Dec 2006 21:01:58 +0100 Subject: removing termcap In-Reply-To: References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061127163751.GD29814@nostromo.devel.redhat.com> <1164655125.3195.2.camel@rousalka.dyndns.org> <20061130101846.GA31756@petra.dvoda.cz> Message-ID: <20061202210158.57a49878@nausicaa.camperquake.de> Hi. Benny Amorsen wrote: > If /usr was gone and everything was in /, the root partition would be > useful and consistent by itself. Obviously. That may be. But /usr going away is not going to happen anytime soon, I think. Like, not during the next 10 years or so. -- Sturgeon's Law: 90% of science fiction is junk. But then, 90% of everything is junk. From janina at rednote.net Sat Dec 2 21:33:39 2006 From: janina at rednote.net (Janina Sajka) Date: Sat, 2 Dec 2006 16:33:39 -0500 Subject: Yum Question Message-ID: <20061202213339.GB3781@rednote.net> I want to configure yum to only retrieve kernels from a particular repository--and none other--because I want to insure my installed kernels always provide a certain module not provided by Fedora itself. Reading the yum.conf man page suggests to me that putting: kernelpkgnames=kernel-*spk in the relevant [repo-name].repo file/stanza might accomplish this. However, the man page also says, "This is really only here for the updating of kernel packages and should be removed out in the yum 2.1 series." -- Is this correct? Is there some other way to insure kernels only come from a particular repo? Thanks in advance for all suggestions. Janina Sajka Phone: +1.202.595.7777 Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://ScreenlessPhone.Com to learn more. Chair, Accessibility Workgroup Free Standards Group (FSG) janina at freestandards.org http://a11y.org From skvidal at linux.duke.edu Sat Dec 2 21:42:04 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 02 Dec 2006 16:42:04 -0500 Subject: Yum Question In-Reply-To: <20061202213339.GB3781@rednote.net> References: <20061202213339.GB3781@rednote.net> Message-ID: <1165095724.27584.7.camel@cutter> On Sat, 2006-12-02 at 16:33 -0500, Janina Sajka wrote: > I want to configure yum to only retrieve kernels from a particular > repository--and none other--because I want to insure my installed > kernels always provide a certain module not provided by Fedora itself. > Reading the yum.conf man page suggests to me that putting: > > kernelpkgnames=kernel-*spk > > in the relevant [repo-name].repo file/stanza might accomplish this. > However, the man page also says, "This is really only here for the > updating of kernel packages and should be removed out in the yum 2.1 > series." -- > > Is this correct? Is there some other way to insure kernels only come > from a particular repo? > > Thanks in advance for all suggestions. Easiest ways to make sure certain packages only come from a specific repo is just to exclude those packages from all other repos. -sv From obi at unixkiste.org Sat Dec 2 22:36:20 2006 From: obi at unixkiste.org (Stefan Held) Date: Sat, 02 Dec 2006 23:36:20 +0100 Subject: Eclipse on Linux Distributions eclipse.org project approved In-Reply-To: <20061130222000.GM16792@redhat.com> References: <20061130222000.GM16792@redhat.com> Message-ID: <1165098980.8532.2.camel@develop.unixkiste.local> Am Donnerstag, den 30.11.2006, 17:20 -0500 schrieb Andrew Overholt: > Hi, > > At EclipseCon 2006, Ben Konrath and I met Matt Ryan from Novell. We talked > about the general issues hurting Eclipse adoption in the Linux and FOSS > communities. Matt took the lead out of our conversations and along with > ?Eclipse people? from other major distros, we proposed [1] the ?Eclipse on > Linux Distributions? project at eclipse.org. Hi Andrew. This sound really like a good plan. I use Eclipse now as a daily basis for j2ee development work. What sucks most ist not how Eclipse is included into the major distributions, its the java runtime or development kit. As now Sun has been coming forward with plans to switch java over to the gpl are there any community plans for Fedora to include Suns Java into the Desktop? Why has noone ever asked Sun for a binary distribution License and created two groups for yum which the user is up to decide wether he can live with gcj and classpath or a traditional jdk environment? > Last week, the project had its Creation Review [2] and it was a success! > I?d like to see most, if not all, of the work that our group is doing ? > ChangeLog, autotools, specfile editing, packaging tools, etc. ? get more > visibility as part of this project. We?re also looking forward to > collaborating with developers and packagers from other distributions. > Having this work under the eclipse.org umbrella will give it better > exposure and hopefully help in achieving our goal of bringing Eclipse > technology to Linux distribution users. I am happy to see that this gets adressed now. Keep going! :) > As usual, everyone is invited to join in our work. We hope to see some of > you on IRC (#fedora-java), fedora-devel-java-list at redhat.com, the upstream > mailing lists (linux-distros-dev at eclipse.org ... at least for now - it may > change to be linuxtools-dev at eclipse.org but that's yet to be finalized), > etc. > Subscribing right now. > Thanks, > > Andrew -- Stefan Held VI has only 2 Modes: obi at unixkiste dot org The first one is for beeping all the time, IRCNet: Obi_Wan the second destroys the text. --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1847 bytes Desc: not available URL: From tonynelson at georgeanelson.com Sat Dec 2 22:51:26 2006 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Sat, 2 Dec 2006 17:51:26 -0500 Subject: Easy Fedora 2 In-Reply-To: <200612011614.20403.jkeating@redhat.com> References: <620278.95751.qm@web54302.mail.yahoo.com> <200612011544.59207.jkeating@redhat.com> <20061201210233.GD19448@zoidtechnologies.com> <200612011614.20403.jkeating@redhat.com> Message-ID: At 4:14 PM -0500 12/1/06, Jesse Keating wrote: >Content-Type: multipart/signed; boundary="nextPart2016324.HycaIX8cHJ"; > protocol="application/pgp-signature"; micalg=pgp-sha1 >Content-Transfer-Encoding: 7bit > >On Friday 01 December 2006 16:02, jam at zoidtechnologies.com wrote: >> a valid point-- however users want these things and if it's "too difficult" >> to get them installed and operational they will go elsewhere. like the >> original poster, I applaud the idea of sticking to the guns and not >> shipping any "grey" content, but that does *not* solve the problem for the >> vast majority of potential fedora users, and the matter needs to be >> addressed rather soon if we want to have a serious set of desktop users. > >Just how do you expect us to "address" the fact that its illegal? I'm sorry, >but we're not just going to ignore the law and hope "The Man" doesn't notice. ... Fairly put. I have a modest proposal that supports Fedora's principles. It would help for new users to be shown Fedora's reasoning when they try to play content that requires a missing (non-free) codec. On fedora-list, new users tend to start with questions about how to burn the CDs, then ask about booting (either their video card or grub), and then ask about not being able to play certain content ("Why are these useless players even installed? They won't play /anything/!"). And only a few novice Fedora users even find the fedora-list! I suggest that Fedora-specific patches be added to the standard players, at least the ones in the Gnome menus, so that when something can't be played because it requires a missing (non-free) codec, a useful dialog appears, explaining that there are legal issues that prevent providing the required codec with a link to a fuller explanation of the issue. This should work better than expecting the average user to read and remember the entire Release Notes. I know Fedora prefers to push patches upstream, but this is a special case. (No, I'm not volunteering, as I don't use or maintain any of the players and would therefor be little help, and my only benefit would be seeing fewer plaints on fedora-list.) If there is a common place where a single patch would affect all players, that would be better. I don't think such a place exists, but I'm no expert. Missing (non-free) firmware is another issue that might have a similar solution? -- ____________________________________________________________________ TonyN.:' The Great Writ ' is no more. From sundaram at fedoraproject.org Sat Dec 2 23:41:15 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 03 Dec 2006 05:11:15 +0530 Subject: Eclipse on Linux Distributions eclipse.org project approved In-Reply-To: <1165098980.8532.2.camel@develop.unixkiste.local> References: <20061130222000.GM16792@redhat.com> <1165098980.8532.2.camel@develop.unixkiste.local> Message-ID: <45720F1B.2090907@fedoraproject.org> Stefan Held wrote: > As now Sun has been coming forward with plans to switch java over to the > gpl are there any community plans for Fedora to include Suns Java into > the Desktop? See list archives for the recent discussions. When Sun has a buildable Free software JDK then this can be considered. The tentative timeline for that is March 2007 and even then the JDK might be available for PPC architecture. So alteast for the next release of Fedora we will probably continue to only include GCJ. > > Why has noone ever asked Sun for a binary distribution License and > created two groups for yum which the user is up to decide wether he can > live with gcj and classpath or a traditional jdk environment? Fedora Project wouldnt ship binary only software anyway so there was no incentive to negotiate such a agreement. However the jpackage.org folks already have done the work necessary and Fedora includes the "alternatives" package which allows you to switch between GCJ and Sun JDK. See man alternatives for details. Rahul From sundaram at fedoraproject.org Sat Dec 2 23:42:33 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 03 Dec 2006 05:12:33 +0530 Subject: Easy Fedora 2 In-Reply-To: References: <620278.95751.qm@web54302.mail.yahoo.com> <200612011544.59207.jkeating@redhat.com> <20061201210233.GD19448@zoidtechnologies.com> <200612011614.20403.jkeating@redhat.com> Message-ID: <45720F69.7040008@fedoraproject.org> Tony Nelson wrote: > Fairly put. I have a modest proposal that supports Fedora's principles. > > It would help for new users to be shown Fedora's reasoning when they try to > play content that requires a missing (non-free) codec. On fedora-list, new > users tend to start with questions about how to burn the CDs, then ask > about booting (either their video card or grub), and then ask about not > being able to play certain content ("Why are these useless players even > installed? They won't play /anything/!"). And only a few novice Fedora > users even find the fedora-list! They play the unencumbered codecs very well and that's what we intend to support by default. > > I suggest that Fedora-specific patches be added to the standard players, at > least the ones in the Gnome menus, so that when something can't be played > because it requires a missing (non-free) codec, a useful dialog appears, > explaining that there are legal issues that prevent providing the required > codec with a link to a fuller explanation of the issue. This should work > better than expecting the average user to read and remember the entire > Release Notes. I know Fedora prefers to push patches upstream, but this is > a special case. (No, I'm not volunteering, as I don't use or maintain any > of the players and would therefor be little help, and my only benefit would > be seeing fewer plaints on fedora-list.) > > If there is a common place where a single patch would affect all players, > that would be better. I don't think such a place exists, but I'm no expert. XMMS used to have something like this back in the Red Hat Linux 9 days. With the diverse number of media players this is now more harder. Gstreamer would be the right place add some hooks and enable this now. This was one of the items discussed in Fedora summit. http://fedoraproject.org/wiki/FedoraSummit > Missing (non-free) firmware is another issue that might have a similar > solution? Potentially. We need to sort out the implementation details and someone has to do the actual development. Rahul From obi at unixkiste.org Sun Dec 3 00:03:57 2006 From: obi at unixkiste.org (Stefan Held) Date: Sun, 03 Dec 2006 01:03:57 +0100 Subject: Eclipse on Linux Distributions eclipse.org project approved In-Reply-To: <45720F1B.2090907@fedoraproject.org> References: <20061130222000.GM16792@redhat.com> <1165098980.8532.2.camel@develop.unixkiste.local> <45720F1B.2090907@fedoraproject.org> Message-ID: <1165104237.8532.18.camel@develop.unixkiste.local> Am Sonntag, den 03.12.2006, 05:11 +0530 schrieb Rahul Sundaram: > Fedora Project wouldnt ship binary only software anyway so there was no http://www.sun.com/software/communitysource/j2se/java2/download.xml You only need this aggrement to build your own java version from the source and distribute it. Exactly like you need it for Firefox. This license was nessesary because M$ tried to sell Java as theire own creation (M$ JVM). Please do not cry out FUD. http://www.freebsdfoundation.org/downloads/java.shtml Nice to see that other projects managed this ..... > incentive to negotiate such a agreement. However the jpackage.org folks [sheld at develop ~]$ rpm -qa | grep sun java-1.5.0-sun-plugin-1.5.0.09-1jpp java-1.5.0-sun-1.5.0.09-1jpp > already have done the work necessary and Fedora includes the > "alternatives" package which allows you to switch between GCJ and Sun > JDK. See man alternatives for details. [sheld at develop ~]$ ls -la /etc/alternatives/java lrwxrwxrwx 1 root root 35 30. Nov 01:43 /etc/alternatives/java -> /usr/lib/jvm/jre-1.5.0-sun/bin/java > Rahul I am not exactly sure how such answers help ....... -- Stefan Held VI has only 2 Modes: obi at unixkiste dot org The first one is for beeping all the time, IRCNet: Obi_Wan the second destroys the text. --------------------------------------------------------------------------- perl -e'map{print pack c,($|++?1:13)+ord,select$,,$,,$,,$|}split//,ESEL.$/' --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3413 bytes Desc: not available URL: From sundaram at fedoraproject.org Sun Dec 3 00:29:22 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 03 Dec 2006 05:59:22 +0530 Subject: Eclipse on Linux Distributions eclipse.org project approved In-Reply-To: <1165104237.8532.18.camel@develop.unixkiste.local> References: <20061130222000.GM16792@redhat.com> <1165098980.8532.2.camel@develop.unixkiste.local> <45720F1B.2090907@fedoraproject.org> <1165104237.8532.18.camel@develop.unixkiste.local> Message-ID: <45721A62.50404@fedoraproject.org> Stefan Held wrote: > http://www.sun.com/software/communitysource/j2se/java2/download.xml > > > You only need this aggrement to build your own java version from the > source and distribute it. Exactly like you need it for Firefox. This is not a Free software license which is a requirement for inclusion in Fedora. See http://fedoraproject.org/wiki/Objectives and http://fedoraproject.org/wiki/Packaging/Guidelines#Legal. Just a week or so back I attended a Sun presentation on open source Java where they admitted to not having complete source code under a Free software license since portions of code is licensed by Sun from other vendors. Like I said the tentative timeline to remove that encumbrances is March 2007. > This license was nessesary because M$ tried to sell Java as theire own > creation (M$ JVM). Please do not cry out FUD. You misunderstood. Major portions of Sun Java is under a GPL+classpath exception license currently. See https://openjdk.dev.java.net/ However there are portions of it still not available a Free software license due to it being licensed from other vendors. > http://www.freebsdfoundation.org/downloads/java.shtml > > > Nice to see that other projects managed this ..... Fedora Project is not willing to negotiate agreements to include proprietary software unlike the FreeBSD foundation. > lrwxrwxrwx 1 root root 35 30. Nov 01:43 /etc/alternatives/java > -> /usr/lib/jvm/jre-1.5.0-sun/bin/java > I am not exactly sure how such answers help ....... If you already knew about alternatives, thats the extend of support we can currently provide for other JVM's. Rahul From jdogalt at yahoo.com Sun Dec 3 02:01:14 2006 From: jdogalt at yahoo.com (Jane Dogalt) Date: Sat, 2 Dec 2006 18:01:14 -0800 (PST) Subject: Zod livecd beta In-Reply-To: <1164994881.2479.30.camel@zelda.fubar.dk> Message-ID: <6323.40671.qm@web56906.mail.re3.yahoo.com> Excellent work on the Zod livecd beta David. I'm typing this via firefox, via running it on a p3-600w/378megs and a gforce4, and is very usable. I filed a very minor bug, but otherwise it looks great. I was hoping I'd find a readme, or specific pilgrim commandline, so that I'd know how to recreate the iso precisely. Is there yet a source code controlled tree that I can check out, to build modifications of, and post patches of? Thanks, -dmc/jdog __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jon.nettleton at gmail.com Sun Dec 3 03:03:27 2006 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Sat, 02 Dec 2006 22:03:27 -0500 Subject: CPU Frequency Scaling Message-ID: <1165115008.2314.22.camel@averatec.charles.net> I run an athlon xp-m enabled laptop and have for years now. I have gone through all the iterations of powernowd, cpufreqd, cpuspeed. One of the things that has always bothered me is I have the little cpufreq-applet on my taskbar, but I can't control the cpuspeed with it when running a frequency daemon. Today I was bored on the phone and right clicked on it, went to preferences and what do I see but the option to display and choose a scaling governor. The kernel has had the scaling governor modules for a while now and I am not sure why Fedora is still relying on the cpuspeed daemon by default. If anyone in the know could answer that question I would appreciate it. I put together some quick shell scripts to handle loading the modules and setting a default governer. Before I submitted an RFE, I wanted to get some input from you all. Attached is a tarball of the two files needed to enable the cpu governor modules on boot and set a default governor. 1) cpugov.modules goes in /etc/sysconfig/modules (needs to be executable) 2) cpugov goes in /etc/sysconfig 3) tweak /etc/sysconfig/cpugov to your liking 4) chkconfig cpuspeed off Then make sure and enable scaling governor control in your cpufreq-applet. Can't wait to get some feedback. Jon -------------- next part -------------- A non-text attachment was scrubbed... Name: cpugov.tgz Type: application/x-compressed-tar Size: 443 bytes Desc: not available URL: From giallu at gmail.com Sun Dec 3 10:07:55 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 3 Dec 2006 11:07:55 +0100 Subject: Logged out from X during yum update In-Reply-To: <883cfe6d0612011838o1785297ep2c3f81526a05709@mail.gmail.com> References: <883cfe6d0612011838o1785297ep2c3f81526a05709@mail.gmail.com> Message-ID: On 12/2/06, Michel Salim wrote: > 2006/12/1, Gianluca Sforna : > > I am installing FC-6 onto a brand new server (HP ProLiant ML 350 G5); > > my usual PXE+HTTP installation went just fine. > > > > However, during the first update, I was logged out from X and returned > > to the gdm screen. > > > Saw this yesterday. Not exactly logged out, but gnome-panel behaved > bizarrely (menus and some applets disappeared, but without dialog > boxes asking to reload) - and could not be restarted. I had to log out > and back in, and then things work normally. Just happened again, with a completely different hardware (a Toshiba Satellite U200-168 laptop). Maybe it's time to open a bugzilla ticket... From giallu at gmail.com Sun Dec 3 10:51:18 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 3 Dec 2006 11:51:18 +0100 Subject: Logged out from X during yum update In-Reply-To: References: <883cfe6d0612011838o1785297ep2c3f81526a05709@mail.gmail.com> Message-ID: On 12/3/06, Gianluca Sforna wrote: > > Maybe it's time to open a bugzilla ticket... > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218207 From buildsys at redhat.com Sun Dec 3 11:20:47 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sun, 3 Dec 2006 06:20:47 -0500 Subject: rawhide report: 20061203 changes Message-ID: <200612031120.kB3BKl1B014341@hs20-bc2-6.build.redhat.com> Updated Packages: openoffice.org-1:2.1.0-6.1 -------------------------- * Fri Dec 01 2006 Caolan McNamara - 1:2.1.0-6.1 - next version - Resolves: rhbz#217813 openoffice.org-2.1.0.ooo72129.vcl.fontglyphindex.patch - relocate dictionaries perl-Carp-Clan-5.8-1.fc7 ------------------------ * Sat Dec 02 2006 Robin Norwood - 5.8-1 - New version perl-DBD-MySQL-3.0008-1.fc7 --------------------------- * Sat Dec 02 2006 Robin Norwood - 3.0008-1 - New version from CPAN: 3.0008 perl-DBI-1.53-1.fc7 ------------------- * Sat Dec 02 2006 Robin Norwood - 1.53-1 - Upgrade to latest CPAN version: 1.53 perl-Devel-Symdump-2.0604-1.fc7 ------------------------------- * Sat Dec 02 2006 Robin Norwood - 1.02-1 - Upgrade to latest CPAN version: 1.02 perl-PDL-2.4.3-1.fc7 -------------------- * Sat Dec 02 2006 Robin Norwood - 2.4.3-1 - Latest version from CPAN: 2.4.3 perl-RPM-Specfile-1.51-1.fc7 ---------------------------- * Sat Dec 02 2006 Robin Norwood - 1.51-1 - Build latest version from CPAN: 1.51 perl-XML-Simple-2.16-1..fc7 --------------------------- * Sat Dec 02 2006 Robin Norwood - 2.16-1 - Upgrade to latest CPAN version: 2.16 Broken deps for ppc64 ---------------------------------------------------------- perl-RPM-Specfile - 1.51-1.fc7.noarch requires perl(YAML) Broken deps for i386 ---------------------------------------------------------- perl-RPM-Specfile - 1.51-1.fc7.noarch requires perl(YAML) Broken deps for s390 ---------------------------------------------------------- perl-RPM-Specfile - 1.51-1.fc7.noarch requires perl(YAML) systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- perl-RPM-Specfile - 1.51-1.fc7.noarch requires perl(YAML) Broken deps for x86_64 ---------------------------------------------------------- perl-RPM-Specfile - 1.51-1.fc7.noarch requires perl(YAML) Broken deps for ppc ---------------------------------------------------------- perl-RPM-Specfile - 1.51-1.fc7.noarch requires perl(YAML) Broken deps for s390x ---------------------------------------------------------- perl-RPM-Specfile - 1.51-1.fc7.noarch requires perl(YAML) From hughsient at gmail.com Sun Dec 3 14:14:57 2006 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 03 Dec 2006 14:14:57 +0000 Subject: CPU Frequency Scaling In-Reply-To: <1165115008.2314.22.camel@averatec.charles.net> References: <1165115008.2314.22.camel@averatec.charles.net> Message-ID: <1165155297.3165.9.camel@hughsie-laptop> On Sat, 2006-12-02 at 22:03 -0500, Jon Nettleton wrote: > The kernel has had the scaling governor modules for a while now and I > am > not sure why Fedora is still relying on the cpuspeed daemon by > default. > If anyone in the know could answer that question I would appreciate > it. The latest version of gnome-power-manager allows you to control the cpu frequency on the desktop without poking around in /etc setting stuff setuid or starting services. If you install the latest 2.17.x version, and a fairly new HAL, I would appreciate the feedback on how easy it is to use. Richard. From arjan at fenrus.demon.nl Sun Dec 3 14:58:08 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 03 Dec 2006 15:58:08 +0100 Subject: CPU Frequency Scaling In-Reply-To: <1165115008.2314.22.camel@averatec.charles.net> References: <1165115008.2314.22.camel@averatec.charles.net> Message-ID: <1165157888.3233.225.camel@laptopd505.fenrus.org> > The kernel has had the scaling governor modules for a while now and I am > not sure why Fedora is still relying on the cpuspeed daemon by default. is it? Afaik most cpus actually use the ondemand governer, which lets the kernel do the frequency switches on demand, and quickly ;) Yes the enabling of this happens from the cpuspeed initscript, but the cpuspeed daemon isn't actually involved anymore for just about any modern system. In my experience, ondemand works really well and I've not yet found that I wanted to override it. Maybe if you absolutely want the longest battery life and always want only the lowest frequency (but then again the frequency range is a tunable for ondemand anyway) From jon.nettleton at gmail.com Sun Dec 3 15:06:43 2006 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Sun, 03 Dec 2006 10:06:43 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165155297.3165.9.camel@hughsie-laptop> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> Message-ID: <1165158403.2314.34.camel@averatec.charles.net> On Sun, 2006-12-03 at 14:14 +0000, Richard Hughes wrote: > On Sat, 2006-12-02 at 22:03 -0500, Jon Nettleton wrote: > > The kernel has had the scaling governor modules for a while now and I > > am > > not sure why Fedora is still relying on the cpuspeed daemon by > > default. > > If anyone in the know could answer that question I would appreciate > > it. > > The latest version of gnome-power-manager allows you to control the cpu > frequency on the desktop without poking around in /etc setting stuff > setuid or starting services. If you install the latest 2.17.x version, > and a fairly new HAL, I would appreciate the feedback on how easy it is > to use. > Thanks I will take a look. I still think that we need a /etc interface to enable a governor without a user being logged in. I love the work that is being done to put the control into userspace. However, more and more we are losing the ability to setup these controls automatically on boot, without having a user logged in. Jon From hughsient at gmail.com Sun Dec 3 15:08:37 2006 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 03 Dec 2006 15:08:37 +0000 Subject: CPU Frequency Scaling In-Reply-To: <1165157888.3233.225.camel@laptopd505.fenrus.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165157888.3233.225.camel@laptopd505.fenrus.org> Message-ID: <1165158517.4001.4.camel@hughsie-laptop> On Sun, 2006-12-03 at 15:58 +0100, Arjan van de Ven wrote: > In my experience, ondemand works really well and I've not yet found > that > I wanted to override it. Maybe if you absolutely want the longest > battery life and always want only the lowest frequency > (but then again the frequency range is a tunable for ondemand anyway) Yes, putting this feature in g-p-m allows the user to trivially set different policy on AC and on battery, and we can also do some clever things to try and save battery automatically. Using ondemand rather than performance (when on battery) reduces my power usage by a few watts on my notebook (which translates to about another 20-30 minutes runtime for me). On AC, the default is to run at full speed, as some people don't like the latency of ondemand or conservative. But it's in the preferences to keep most people happy. Richard. From jon.nettleton at gmail.com Sun Dec 3 15:13:09 2006 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Sun, 03 Dec 2006 10:13:09 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165157888.3233.225.camel@laptopd505.fenrus.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165157888.3233.225.camel@laptopd505.fenrus.org> Message-ID: <1165158789.2314.39.camel@averatec.charles.net> On Sun, 2006-12-03 at 15:58 +0100, Arjan van de Ven wrote: > > The kernel has had the scaling governor modules for a while now and I am > > not sure why Fedora is still relying on the cpuspeed daemon by default. > > is it? Afaik most cpus actually use the ondemand governer, which lets > the kernel do the frequency switches on demand, and quickly ;) > Yes the enabling of this happens from the cpuspeed initscript, but the > cpuspeed daemon isn't actually involved anymore for just about any > modern system. > > In my experience, ondemand works really well and I've not yet found that > I wanted to override it. Maybe if you absolutely want the longest > battery life and always want only the lowest frequency > (but then again the frequency range is a tunable for ondemand anyway) Looks like it is only setting up ondemand for centrino|powernow-k8, which explains why my xp-m is left out in the cold. Any reason why it is limited to those two chipsets? It would also be nice to have it read from /etc/sysconfig so more of the governor modules can be loaded. Jon From jkeating at redhat.com Sun Dec 3 16:00:50 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 3 Dec 2006 11:00:50 -0500 Subject: Zod livecd beta In-Reply-To: <6323.40671.qm@web56906.mail.re3.yahoo.com> References: <6323.40671.qm@web56906.mail.re3.yahoo.com> Message-ID: <200612031100.55307.jkeating@redhat.com> On Saturday 02 December 2006 21:01, Jane Dogalt wrote: > I was hoping I'd find a readme, or specific pilgrim commandline, so > that I'd know how to recreate the iso precisely. ?Is there yet a source > code controlled tree that I can check out, to build modifications of, > and post patches of? The code is in git, however David is going to be working on a rewrite (some of us are going to help too!) so that it is easier to reproduce the isos. David had to fiddle with it a bit to produce this iso, its the beta to discover what might need to be fixed during the rewrite. David will probably make more posts regarding progress soon. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arjan at fenrus.demon.nl Sun Dec 3 18:29:12 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 03 Dec 2006 19:29:12 +0100 Subject: CPU Frequency Scaling In-Reply-To: <1165158517.4001.4.camel@hughsie-laptop> References: <1165115008.2314.22.camel@averatec.charles.net> <1165157888.3233.225.camel@laptopd505.fenrus.org> <1165158517.4001.4.camel@hughsie-laptop> Message-ID: <1165170552.3233.234.camel@laptopd505.fenrus.org> > On AC, the default is to run at full speed, I think that's a mistake. Especially for servers, power usage does matter ... > as some people don't like > the latency of ondemand or conservative. But it's in the preferences to > keep most people happy. if there is a problem then lets fix it in ondemand. What is the bugzilla for this? From tmus at tmus.dk Sun Dec 3 21:03:24 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sun, 03 Dec 2006 22:03:24 +0100 Subject: Blowfish encryption for local passwords Message-ID: Hi guys, Is there a reason why fedora does not support blowfish (at least through the various included tools, system-config-authentication etc.) for password encryption? From my understanding, Blowfish provides encryption far superior to even MD5 and there should no license problems. Even though MD5 might seem hard-enough-to-crack, why would we stop there? Also, it seems like supporting blowfish would not be very hard to implement in fedora, so why don't we? (and the unavoidable:) Other linux distros have Blowfish encryption for passwords ;-) Thanks /Thomas From mattdm at mattdm.org Sun Dec 3 22:02:33 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 3 Dec 2006 17:02:33 -0500 Subject: Blowfish encryption for local passwords In-Reply-To: References: Message-ID: <20061203220233.GA28609@jadzia.bu.edu> On Sun, Dec 03, 2006 at 10:03:24PM +0100, Thomas M Steenholdt wrote: > From my understanding, Blowfish provides encryption far superior to > even MD5 and there should no license problems. Isn't this apples and oranges? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From eng at prowip.net.br Mon Dec 4 00:04:54 2006 From: eng at prowip.net.br (HM Eng.Prowip) Date: Sun, 3 Dec 2006 21:04:54 -0300 Subject: CPU Frequency Scaling In-Reply-To: <1165170552.3233.234.camel@laptopd505.fenrus.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> Message-ID: <200612032104.54541.eng@prowip.net.br> On Sunday 03 December 2006 15:29, Arjan van de Ven wrote: > > On AC, the default is to run at full speed, > > I think that's a mistake. Especially for servers, power usage does > matter ... mhhh ... especially for servers power does matter, power usage does not matter at all but that is only a economical question, i got curious here do you run your server really on DC or battery? HM A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From bkonrath at redhat.com Mon Dec 4 03:06:41 2006 From: bkonrath at redhat.com (Ben Konrath) Date: Sun, 03 Dec 2006 22:06:41 -0500 Subject: [fedora-java] Eclipse on Linux Distributions eclipse.org project approved In-Reply-To: <20061130222000.GM16792@redhat.com> References: <20061130222000.GM16792@redhat.com> Message-ID: <1165201601.4988.6.camel@plug> Hi Andrew, On Thu, 2006-11-30 at 17:20 -0500, Andrew Overholt wrote: > Last week, the project had its Creation Review [2] and it was a success! I just wanted to say thanks for all your hard work in bringing this project through the creation review. Cheers, Ben From arjan at fenrus.demon.nl Mon Dec 4 07:01:06 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 04 Dec 2006 08:01:06 +0100 Subject: CPU Frequency Scaling In-Reply-To: <200612032104.54541.eng@prowip.net.br> References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> Message-ID: <1165215666.3233.261.camel@laptopd505.fenrus.org> On Sun, 2006-12-03 at 21:04 -0300, HM Eng.Prowip wrote: > On Sunday 03 December 2006 15:29, Arjan van de Ven wrote: > > > On AC, the default is to run at full speed, > > > > I think that's a mistake. Especially for servers, power usage does > > matter ... > > mhhh ... especially for servers power does matter, power usage does not matter > at all but that is only a economical question, i got curious here do you run > your server really on DC or battery? servers run on main power, which would run at "full speed always" in the proposed g-p-m scheme. Which would be highly unfortunate. From pmr at pajato.com Mon Dec 4 07:13:53 2006 From: pmr at pajato.com (Paul Michael Reilly) Date: Mon, 04 Dec 2006 02:13:53 -0500 Subject: Running with the brakes on ... Message-ID: During the past few weeks, my Rawhide system (A31p Thinkpad Laptop, 1G RAM, 2GHz CPU, running KDE desktop) has been running noticably slower (starts out OK but gets worse over time), particularly with Thunderbird, Firefox and other GUI tools but not so with Emacs, FWIW. I've been scratching my head trying to figure out how to characterize the slowdown in order to say something useful and file a bug report if appropriate but until now about all I could say was "... boy this system seems slower ... maybe if I do an update it will cure whatever ails it ..." only to find out that no magic bullet was available from yum yet. But a few minutes ago, I started playing with multiple X sessions via the "Switch User" facility. I created a root session on Ctrl-Alt-F8 running Gnome. Then I set about to enable sound to run for multiple Users running both KDE and Gnome to run the Soundcard Detection tool and configuring /etc/profile to set the permissions for multiple simultaneous sound car users. I discovered, much to my surprise that the F8 (GNOME) session works perfectly normally while the F7 session (KDE). Which is not to suggest that I think this is a desktop selection issue by any stretch. Now I think I have enough information to solicit suggestions that are more meaningful than the terse "man oprofile" suggestion that I received a few days ago towards getting to the root of the issue. Even better, it would be good to know if anyone else running a remotely similar environment (rawhide, KDE, thunderbird, firefox) is experiencing similar performance slowdowns with the GUI tools. When running top, I see that X is consuming 40% of memory which is not surprising since I am running two X sessions with 3200x1200 (dual head, radeon, open source) along with long running firefox, thunderbird and VNC (also 3200x1200) apps). But when I bring up the Soundcard Detection tool under KDE top shows Xorg is consistently grabbing 93% of the CPU even when all I am doing is typing this message. That would certainly explain a lot of the lag in response to mouse clicks from the app. :-) Switching to Gnome and running top there shows varying, but high (60%ish) CPU use with the Soundcard Detection tool still running in both sessions. But with Gnome, response to mousee clicks is fine, even with the high X CPU use. So I'm still scratching my head but something about the KDE environment is causing a performance problem for my system. -pmr From giallu at gmail.com Mon Dec 4 07:41:13 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 4 Dec 2006 08:41:13 +0100 Subject: Hibernate on FC-6 (partly) fails Message-ID: Sorry for the cross posting (I can't really decide which list was better...) I'm seeing this regression (compared to FC-5, where it used to work fine) on the hibernate function with this laptop, an ASUS M6Ne (Centrino 1.7Ghz, 512Mb RAM, ATI mobility radeon 9700, _not_ using any proprietary kernel modules) Basically, the hibernate procedure go as far as the "shutting down hda" message, then fails to turn off power. I am forced to turn it off manually. Otherwise the operation seems working. Anyone else with similar symptoms? Moreover, I saw from time to time a screen of kernel error messages ( a stack trace ?) on the consule during wake up operation, but I am not sure if this was generated during hibernation. I will try to find a pattern for this and eventually post agina more details. Cheers Gianluca From mike.cohler at gmail.com Mon Dec 4 08:01:43 2006 From: mike.cohler at gmail.com (Mike Cohler) Date: Mon, 4 Dec 2006 08:01:43 +0000 Subject: wpa and fc6/7 Message-ID: <3dd77c60612040001t4f813b5bn2c4e420fb2c59a9a@mail.gmail.com> Can anyone tell me what the status of wpa_supplicant development is? I tried to change over from WEP to WPA in fc6 and hit a brick wall. >From postings all over the net it seems that the vast majority of people who try to get wpa going come across problems and struggle to get anything working properly. The support for different hardware seems erratic and largely undocumented. It appears to me that there is a need for some development as well as some decent documentation to help people with this issue. What do others think? -- mike cohler From giallu at gmail.com Mon Dec 4 08:54:06 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 4 Dec 2006 09:54:06 +0100 Subject: wpa and fc6/7 In-Reply-To: <3dd77c60612040001t4f813b5bn2c4e420fb2c59a9a@mail.gmail.com> References: <3dd77c60612040001t4f813b5bn2c4e420fb2c59a9a@mail.gmail.com> Message-ID: On 12/4/06, Mike Cohler wrote: > > What do others think? I think it should work OOTB... Right now, I have had quite some successes with NetworkManager + WPA + ipwXXXX. I have another working installation at home with madwifi, using straight s-c-n and manual editing of /etc/wpa_supplicant/wpa_supplicat.conf; the provided man pages was enough to get it mostly[1] working. ciao Gianluca [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197319 From fedora at camperquake.de Mon Dec 4 09:06:48 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 4 Dec 2006 10:06:48 +0100 Subject: CPU Frequency Scaling In-Reply-To: <1165157888.3233.225.camel@laptopd505.fenrus.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165157888.3233.225.camel@laptopd505.fenrus.org> Message-ID: <20061204100648.0fd4fb6a@banea.int.addix.net> Hi. On Sun, 03 Dec 2006 15:58:08 +0100, Arjan van de Ven wrote: > is it? Afaik most cpus actually use the ondemand governer, which lets > the kernel do the frequency switches on demand, and quickly ;) Hm. Does not seem to work for P4s, so it's userspace for me. From laroche at redhat.com Mon Dec 4 09:15:41 2006 From: laroche at redhat.com (Florian La Roche) Date: Mon, 4 Dec 2006 10:15:41 +0100 Subject: CPU Frequency Scaling In-Reply-To: <1165215666.3233.261.camel@laptopd505.fenrus.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> <1165215666.3233.261.camel@laptopd505.fenrus.org> Message-ID: <20061204091541.GA4824@dudweiler.stuttgart.redhat.com> On Mon, Dec 04, 2006 at 08:01:06AM +0100, Arjan van de Ven wrote: > On Sun, 2006-12-03 at 21:04 -0300, HM Eng.Prowip wrote: > > On Sunday 03 December 2006 15:29, Arjan van de Ven wrote: > > > > On AC, the default is to run at full speed, > > > > > > I think that's a mistake. Especially for servers, power usage does > > > matter ... > > > > mhhh ... especially for servers power does matter, power usage does not matter > > at all but that is only a economical question, i got curious here do you run > > your server really on DC or battery? > > servers run on main power, which would run at "full speed always" in the > proposed g-p-m scheme. Which would be highly unfortunate. At least for laptops is makes sense to keep them cool even on AC. For servers most probably as well... regards, Florian La Roche From bbbush.yuan at gmail.com Mon Dec 4 09:36:18 2006 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Mon, 4 Dec 2006 17:36:18 +0800 Subject: wpa and fc6/7 In-Reply-To: <3dd77c60612040001t4f813b5bn2c4e420fb2c59a9a@mail.gmail.com> References: <3dd77c60612040001t4f813b5bn2c4e420fb2c59a9a@mail.gmail.com> Message-ID: <76e72f800612040136p1bb846d5nc149c97d59dd8c0e@mail.gmail.com> 2006/12/4, Mike Cohler : > Can anyone tell me what the status of wpa_supplicant development is? > I tried to change over from WEP to WPA in fc6 and hit a brick wall. > > >From postings all over the net it seems that the vast majority of > people who try to get wpa going come across problems and struggle to > get anything working properly. The support for different hardware > seems erratic and largely undocumented. > > It appears to me that there is a need for some development as well as > some decent documentation to help people with this issue. > > What do others think? > Either use wpa_supplicant from atrpms repo and don't use NetworkManager, use iwconfig instead: please search in atrpms bugzilla; or uninstall atrpms' version, use core version instead, together with NM. Running NetworkManager in the foreground will greatly help.. The console output is quite clean and easy to understand.. I was just biten so I found that. -- bbbush ^_^ From tmraz at redhat.com Mon Dec 4 09:36:56 2006 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 04 Dec 2006 10:36:56 +0100 Subject: Blowfish encryption for local passwords In-Reply-To: References: Message-ID: <1165225016.3037.6.camel@perun.kabelta.loc> On Sun, 2006-12-03 at 22:03 +0100, Thomas M Steenholdt wrote: > Hi guys, > > Is there a reason why fedora does not support blowfish (at least through > the various included tools, system-config-authentication etc.) for > password encryption? > From my understanding, Blowfish provides encryption far superior to > even MD5 and there should no license problems. > Even though MD5 might seem hard-enough-to-crack, why would we stop there? > > Also, it seems like supporting blowfish would not be very hard to > implement in fedora, so why don't we? > > (and the unavoidable:) Other linux distros have Blowfish encryption for > passwords ;-) > > Thanks We need support for blowfish directly in glibc or replace libcrypt from glibc with libxcrypt first. Then all other packages can be updated to support Blowfish. See: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173002 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173834 -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From mike.cohler at gmail.com Mon Dec 4 09:45:21 2006 From: mike.cohler at gmail.com (Mike Cohler) Date: Mon, 4 Dec 2006 09:45:21 +0000 (UTC) Subject: wpa and fc6/7 References: <3dd77c60612040001t4f813b5bn2c4e420fb2c59a9a@mail.gmail.com> Message-ID: Gianluca Sforna gmail.com> writes: > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197319 Thanks for the report and ref to the BZ. It seems that this is currently in development and it will be nice to see it work correctly at some point soon. I think I will wait until I see some updates appearing for fc6 which indicate that starting the wpa_supplicant daemon is likely to be successful for my setup. Also it would be really helpful if there was a standard doc which helped the new wpa user get going. Mike From tmus at tmus.dk Mon Dec 4 09:51:15 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 04 Dec 2006 10:51:15 +0100 Subject: Blowfish encryption for local passwords In-Reply-To: <1165225016.3037.6.camel@perun.kabelta.loc> References: <1165225016.3037.6.camel@perun.kabelta.loc> Message-ID: Tomas Mraz wrote: > On Sun, 2006-12-03 at 22:03 +0100, Thomas M Steenholdt wrote: >> Hi guys, >> >> Is there a reason why fedora does not support blowfish (at least through >> the various included tools, system-config-authentication etc.) for >> password encryption? >> From my understanding, Blowfish provides encryption far superior to >> even MD5 and there should no license problems. >> Even though MD5 might seem hard-enough-to-crack, why would we stop there? >> >> Also, it seems like supporting blowfish would not be very hard to >> implement in fedora, so why don't we? >> >> (and the unavoidable:) Other linux distros have Blowfish encryption for >> passwords ;-) >> >> Thanks > > We need support for blowfish directly in glibc or replace libcrypt from > glibc with libxcrypt first. Then all other packages can be updated to > support Blowfish. > > See: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173002 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173834 > Thanks - I've CC'ed myself on those bugs. Doesn't seem like there s much activity on them, though?? Perhaps the actual activity is going on elsewhere (cvs or such)? Latest update for the respective bugs is january and may of this year? /Thomas From tmus at tmus.dk Mon Dec 4 09:54:47 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 04 Dec 2006 10:54:47 +0100 Subject: Blowfish encryption for local passwords In-Reply-To: <20061203220233.GA28609@jadzia.bu.edu> References: <20061203220233.GA28609@jadzia.bu.edu> Message-ID: Matthew Miller wrote: > On Sun, Dec 03, 2006 at 10:03:24PM +0100, Thomas M Steenholdt wrote: >> From my understanding, Blowfish provides encryption far superior to >> even MD5 and there should no license problems. > > Isn't this apples and oranges? > Not really. We want to be able to encrypt our local passwords in a way that is impossible to crack and take the longest to brute force. Blowfish seems to be the winner here (from what I know, at least). Performance table, grabbed from bz#173002, comment#2: --- snip --- http://www.usenix.org/publications/login/2004-06/pdfs/alexander.pdf Particularly noticeable is the below benchmark table, running "John the ripper" on a P4 2.4GHz with 512M of RAM. Slower is better! --------------------------------------------------- | Unix crypt () | 249467 hashes/second | | BSDI DES (x725) | 9618 hashes/second | | FreeBSD MD5 | 4452 hashes/second | | OpenBSD Blowfish | 335 hashes/second | | Kerberos AFS DES (short) | 244907 hashes/second | | Kerberos AFS DES (long) | 435745 hashes/second | | Windows NT LanMan DES | 628234 hashes/second | --------------------------------------------------- --- snip --- /Thomas From mlichvar at redhat.com Mon Dec 4 09:57:09 2006 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Mon, 4 Dec 2006 10:57:09 +0100 Subject: rawhide report: 20061201 changes In-Reply-To: <1164988422.13427.17.camel@kloczek01.pracownicy.zie> References: <200612011054.kB1AsMBf017076@hs20-bc2-6.build.redhat.com> <1164988422.13427.17.camel@kloczek01.pracownicy.zie> Message-ID: <20061204095709.GB28360@localhost> On Fri, Dec 01, 2006 at 04:53:42PM +0100, Tomasz K?oczko wrote: > Dnia 01-12-2006, pi? o godzinie 05:54 -0500, buildsys at redhat.com > napisa?(a): > > ncurses-5.5-26.20060715.fc7 > > --------------------------- > > * Thu Nov 30 2006 Miroslav Lichvar > > 5.5-26.20060715 > > - move also hardlinked entries (#217750) > > - search /etc/terminfo for local terminfo entries > > On thread about switching from libtermcap to ncurses was about > libncurses size vis libtermcap. Why not enable --with-termlib in > ncurses. After this only libtermlib[w] can sit in /{_lib} and all other > shared libraries can be installed in %{_libdir} because all applications > which now uses termcap API can be linked with only libtermlib. The termlib is the part of ncurses that has big .data section, so it wouldn't help much. > Second: now ncurses package contains shared libncurses and libncursesw. > Why not all link all against libncursesw ? It will allow drop libncurses > (or move to compat-ncurses). It will allow make main package ~two time > smaller. Some packages don't need the wide-character ncurses, in fact there are only 20 packages in FC+FE that depend on the library. But number of packages requiring libncurses is about 200. -- Miroslav Lichvar From fedora at camperquake.de Mon Dec 4 10:01:47 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 4 Dec 2006 11:01:47 +0100 Subject: Blowfish encryption for local passwords In-Reply-To: References: <20061203220233.GA28609@jadzia.bu.edu> Message-ID: <20061204110147.396e8cb6@banea.int.addix.net> Hi. On Mon, 04 Dec 2006 10:54:47 +0100, Thomas M Steenholdt wrote: > We want to be able to encrypt our local passwords in a way that is > impossible to crack and take the longest to brute force. Blowfish > seems to be the winner here (from what I know, at least). The point was that MD5 is a hash algorithm, while Blowfish is an encryption algorithm. Both types are certainly related, but are different things. From tmus at tmus.dk Mon Dec 4 10:18:26 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 04 Dec 2006 11:18:26 +0100 Subject: Blowfish encryption for local passwords In-Reply-To: <20061204110147.396e8cb6@banea.int.addix.net> References: <20061203220233.GA28609@jadzia.bu.edu> <20061204110147.396e8cb6@banea.int.addix.net> Message-ID: Ralf Ertzinger wrote: > > The point was that MD5 is a hash algorithm, while Blowfish is an > encryption algorithm. Both types are certainly related, but are > different things. > I realize this - But both are viable options for storing passwords securely, and that's what my question is about. So in this context I think it's a fair apples to apples comparison :) /Thomas From tmus at tmus.dk Mon Dec 4 10:38:57 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 04 Dec 2006 11:38:57 +0100 Subject: CPU Frequency Scaling In-Reply-To: <200612032104.54541.eng@prowip.net.br> References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> Message-ID: HM Eng.Prowip wrote: > On Sunday 03 December 2006 15:29, Arjan van de Ven wrote: >>> On AC, the default is to run at full speed, >> I think that's a mistake. Especially for servers, power usage does >> matter ... > > mhhh ... especially for servers power does matter, power usage does not matter > at all but that is only a economical question, i got curious here do you run > your server really on DC or battery? > > HM > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. > Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br > If the scaling governor is quick enough to detect the need and perform the transition, most workloads should not see an actual performance hit by having this enabled. And saving power during idle periods is the right thing to do for a number of reasons, even on servers. However, I've not conducted any benchmarks of the transition speeds etc, so I don't know how well this theory holds in the real world. /Thomas From buildsys at redhat.com Mon Dec 4 10:43:02 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 4 Dec 2006 05:43:02 -0500 Subject: rawhide report: 20061204 changes Message-ID: <200612041043.kB4Ah2Ym018732@hs20-bc2-6.build.redhat.com> Updated Packages: binutils-2.17.50.0.8-1 ---------------------- * Sun Dec 03 2006 Jakub Jelinek 2.17.50.0.8-1 - update to 2.17.50.0.8 - initialize frch_cfi_data (BZ#3607) db4-4.5.20-4.fc7 ---------------- * Mon Dec 04 2006 Jindrich Novy 4.5.20-4 - apply upstream patches for 4.5.20 (Java API <-> core API related fixes) Broken deps for i386 ---------------------------------------------------------- perl-RPM-Specfile - 1.51-1.fc7.noarch requires perl(YAML) Broken deps for ppc64 ---------------------------------------------------------- perl-RPM-Specfile - 1.51-1.fc7.noarch requires perl(YAML) Broken deps for x86_64 ---------------------------------------------------------- perl-RPM-Specfile - 1.51-1.fc7.noarch requires perl(YAML) Broken deps for s390 ---------------------------------------------------------- perl-RPM-Specfile - 1.51-1.fc7.noarch requires perl(YAML) systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ppc ---------------------------------------------------------- perl-RPM-Specfile - 1.51-1.fc7.noarch requires perl(YAML) Broken deps for ia64 ---------------------------------------------------------- perl-RPM-Specfile - 1.51-1.fc7.noarch requires perl(YAML) Broken deps for s390x ---------------------------------------------------------- perl-RPM-Specfile - 1.51-1.fc7.noarch requires perl(YAML) From seg at haxxed.com Mon Dec 4 11:40:02 2006 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 04 Dec 2006 05:40:02 -0600 Subject: CPU Frequency Scaling In-Reply-To: <1165115008.2314.22.camel@averatec.charles.net> References: <1165115008.2314.22.camel@averatec.charles.net> Message-ID: <1165232402.6017.53.camel@max.booze> On Sat, 2006-12-02 at 22:03 -0500, Jon Nettleton wrote: > The kernel has had the scaling governor modules for a while now and I am > not sure why Fedora is still relying on the cpuspeed daemon by default. > If anyone in the know could answer that question I would appreciate it. On my wife's eMachines m6805, running FC6 x86_64, it boots up with ondemand enabled automagically. It seems to be built into the kernel? Its not listed as a module. On my Athlon 64 3000+ desktop, it doesn't work out of the box. Being a desktop, the native PowerNow driver doesn't seem to work but ACPI does. It only has two speeds, 2ghz and 1ghz. I found the cpuspeed demon will flap up and down by default, as its doesn't tune itself to the actual speed difference. I shouldn't have to tune *anything*. I dumped it in favor of loading and enabling ondemand in rc.local, it doesn't seem to have such flapping problems. Another point against userspace is the recent crusade against context switching. A bit ironically, all the userspace polling sends context switching through the roof. In theory, I don't know how its actually implemented, but the kernel governor could run alongside and interact with the kernel scheduler directly, without adding additional context switching and without icky polling. -------------- 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 hughsient at gmail.com Mon Dec 4 11:43:06 2006 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 04 Dec 2006 11:43:06 +0000 Subject: CPU Frequency Scaling In-Reply-To: References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> Message-ID: <1165232586.3147.3.camel@hughsie-laptop> On Mon, 2006-12-04 at 11:38 +0100, Thomas M Steenholdt wrote: > If the scaling governor is quick enough to detect the need and perform > the transition, most workloads.... I've had complaint, (and noticed myself) that conservative and ondemand often take a few hundred ms to "ramp up" to a suitable frequency. Ordinarily this isn't a problem, but with my dual 1.6Ghz laptop idling down to 1Ghz, clicking 'Applications' doesn't feel as "snappy" as it should. I guess it's a difficult balance between latency and smoothing to avoid changing the frequency too often. Richard. From mattdm at mattdm.org Mon Dec 4 13:21:16 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 4 Dec 2006 08:21:16 -0500 Subject: Blowfish encryption for local passwords In-Reply-To: <20061204110147.396e8cb6@banea.int.addix.net> References: <20061203220233.GA28609@jadzia.bu.edu> <20061204110147.396e8cb6@banea.int.addix.net> Message-ID: <20061204132115.GA29472@jadzia.bu.edu> On Mon, Dec 04, 2006 at 11:01:47AM +0100, Ralf Ertzinger wrote: > > We want to be able to encrypt our local passwords in a way that is > > impossible to crack and take the longest to brute force. Blowfish > > seems to be the winner here (from what I know, at least). > The point was that MD5 is a hash algorithm, while Blowfish is an > encryption algorithm. Both types are certainly related, but are > different things. I'm not a crypto geek, but a little research shows that there's a blowfish-derived hash function which can be used with crypt. It's not blowfish itself (or encryption). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Mon Dec 4 13:21:37 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 4 Dec 2006 08:21:37 -0500 Subject: Blowfish encryption for local passwords In-Reply-To: References: <20061203220233.GA28609@jadzia.bu.edu> <20061204110147.396e8cb6@banea.int.addix.net> Message-ID: <20061204132137.GB29472@jadzia.bu.edu> On Mon, Dec 04, 2006 at 11:18:26AM +0100, Thomas M Steenholdt wrote: > I realize this - But both are viable options for storing passwords > securely, and that's what my question is about. So in this context I > think it's a fair apples to apples comparison :) We don't actually want to store passwords. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From kloczek at zie.pg.gda.pl Mon Dec 4 14:25:54 2006 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Mon, 04 Dec 2006 15:25:54 +0100 Subject: rawhide report: 20061201 changes In-Reply-To: <20061204095709.GB28360@localhost> References: <200612011054.kB1AsMBf017076@hs20-bc2-6.build.redhat.com> <1164988422.13427.17.camel@kloczek01.pracownicy.zie> <20061204095709.GB28360@localhost> Message-ID: <1165242354.2924.46.camel@kloczek01.pracownicy.zie> Dnia 04-12-2006, pon o godzinie 10:57 +0100, Miroslav Lichvar napisa?(a): [..] > > Second: now ncurses package contains shared libncurses and libncursesw. > > Why not all link all against libncursesw ? It will allow drop libncurses > > (or move to compat-ncurses). It will allow make main package ~two time > > smaller. > > Some packages don't need the wide-character ncurses, in fact there are > only 20 packages in FC+FE that depend on the library. But number of > packages requiring libncurses is about 200. Seems you dont' know some fact. Using libncursesw ABI don't mean "program uses wchar". libncursesw API in most cases can be used as normal libncurses but have loaded in the same time libncursesw and libncurses and libtermcap means you are preffer waste more memory then using for all program single term toolkit library (nevermind which). Let me explain some other fact: using by RH and Fedora ncurses and libtermcap in current way it is not some think over result. It is result of random order procedures of detecting termcap and ncurses which comes with *dist source* tar balls. Proofs 1: in current Fedora source resources there is no patches which switches using ncurses<>termcap ABI (don't count in this class fixes for detecting termcap/ncurses ABI in case when package like gnupg does not uses term toolkit ABI but it is linked with readline which is now used with weak term toolkit symbols). Proof 2: if ncurses in you opinion is worse than libtermcap why ncurses now is used more offen then libtermcap ? If it is matter of size why there is not in Fedora patches which switches from ncurses to libtermacap API ? kloczek From cmadams at hiwaay.net Mon Dec 4 14:33:57 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 4 Dec 2006 08:33:57 -0600 Subject: Blowfish encryption for local passwords In-Reply-To: <20061204110147.396e8cb6@banea.int.addix.net> References: <20061203220233.GA28609@jadzia.bu.edu> <20061204110147.396e8cb6@banea.int.addix.net> Message-ID: <20061204143357.GA1336277@hiwaay.net> Once upon a time, Ralf Ertzinger said: > The point was that MD5 is a hash algorithm, while Blowfish is an > encryption algorithm. Both types are certainly related, but are > different things. Wasn't the original Unix crypt DES, which is an encryption algorithm? IIRC it worked by using the password as the key to encrypt an empty string (repeatedly?). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From arjan at fenrus.demon.nl Mon Dec 4 15:32:06 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 04 Dec 2006 16:32:06 +0100 Subject: CPU Frequency Scaling In-Reply-To: <1165232586.3147.3.camel@hughsie-laptop> References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> <1165232586.3147.3.camel@hughsie-laptop> Message-ID: <1165246326.3233.288.camel@laptopd505.fenrus.org> On Mon, 2006-12-04 at 11:43 +0000, Richard Hughes wrote: > On Mon, 2006-12-04 at 11:38 +0100, Thomas M Steenholdt wrote: > > If the scaling governor is quick enough to detect the need and perform > > the transition, most workloads.... > > I've had complaint, (and noticed myself) that conservative and ondemand > often take a few hundred ms to "ramp up" to a suitable frequency. again... what is the bugzilla nr? > Ordinarily this isn't a problem, but with my dual 1.6Ghz laptop idling > down to 1Ghz, clicking 'Applications' doesn't feel as "snappy" as it > should. you as human don't notice the difference between 1000 and 1600 Mhz. This has nothing to do with how snappy it feels.... This very very likely is some other effect like pagefault misses etc. > I guess it's a difficult balance between latency and smoothing to avoid > changing the frequency too often no it's not, it's most likely a case of nobody filing a bug or doing a problem report.... in principle ondemand on Intel cpus can switch in like 10 usec. The rest is software tuning. From fedora at camperquake.de Mon Dec 4 16:00:31 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 4 Dec 2006 17:00:31 +0100 Subject: Xen under vmware Message-ID: <20061204170031.357d7e9a@banea.int.addix.net> Hi. Is there a general problem with running a xen enabled system in a vmware virtual machine? I'm losing all network connection from dom0 as soon as network-bridge does it's weird magic, and I can not figure out why. From dragoran at feuerpokemon.de Mon Dec 4 16:06:57 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 04 Dec 2006 17:06:57 +0100 Subject: CPU Frequency Scaling In-Reply-To: <1165246326.3233.288.camel@laptopd505.fenrus.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> <1165232586.3147.3.camel@hughsie-laptop> <1165246326.3233.288.camel@laptopd505.fenrus.org> Message-ID: <457447A1.1050404@feuerpokemon.de> The only reason I need to change the clock by hand on my core 2 duo is because some apps (windows games started using wine) behave weird when they are started with 1 GHZ and the cpu runs @ 2.17GHZ. If I switch to perfomace before starting they work fine. (could be some tsc issue; no idea games are closed source) From arjan at fenrus.demon.nl Mon Dec 4 16:27:52 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 04 Dec 2006 17:27:52 +0100 Subject: CPU Frequency Scaling In-Reply-To: <457447A1.1050404@feuerpokemon.de> References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> <1165232586.3147.3.camel@hughsie-laptop> <1165246326.3233.288.camel@laptopd505.fenrus.org> <457447A1.1050404@feuerpokemon.de> Message-ID: <1165249672.3233.291.camel@laptopd505.fenrus.org> On Mon, 2006-12-04 at 17:06 +0100, dragoran wrote: > The only reason I need to change the clock by hand on my core 2 duo is > because some apps (windows games started using wine) behave weird when > they are started with 1 GHZ and the cpu runs @ 2.17GHZ. If I switch to > perfomace before starting they work fine. (could be some tsc issue; no > idea games are closed source) someone should check the wine sourcecode for rdtsc use though.. in general on linux, using rdtsc in userspace just a bug..... From david at fubar.dk Mon Dec 4 16:41:17 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 04 Dec 2006 11:41:17 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165158403.2314.34.camel@averatec.charles.net> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> Message-ID: <1165250477.2484.18.camel@zelda.fubar.dk> On Sun, 2006-12-03 at 10:06 -0500, Jon Nettleton wrote: > Thanks I will take a look. I still think that we need a /etc interface > to enable a governor without a user being logged in. I love the work > that is being done to put the control into userspace. However, more and > more we are losing the ability to setup these controls automatically on > boot, without having a user logged in. My position is that rather than fiddling with an /etc interface.. what needs to happen is that we reuse the policy daemons [1] we already have working well in the desktop and just run them headless in run level 3 and integrate them with gdm for run level 5. Then the user gets a pretty [Make settings system-wide] button in e.g. the gnome-power-manager UI and that's what system administrators wants to use for their servers (user will have to put in root password / own password to make this happen though). Moreover, with the policy daemons reading settings from gconf, who knows, maybe the system administrator can just tweak a few settings in the Fedora Directory Server and the changes gets propagated out to his servers. I really think that's the user experience we want; not some set of human-editable configuration files in /etc. Anyway, if we don't do this we'll end up with two separate code bases, feature parity plus confusion why you can't use the shiny UI's we have for the policy daemons in your desktop. Sorta like the terrible situation we still have with NetworkManager vs. /etc/init.d/network / s-c-network. I'm sure most people want to avoid that. For the record, here's some detail http://bugzilla.gnome.org/show_bug.cgi?id=356174 but I'm not sure anyone knows exactly to do this just yet. I think it's pretty dependent on other stuff we want to do for this task http://fedoraproject.org/wiki/Desktop/FastUserSwitching and once we got these pieces (ConsoleKit, PolicyKit) in place, I think it'll naturally fall out. Now, if only we had more time / hackers working on this... I really hope I've not started a flamewar by posting this; just wanted to clarify what upstream is considering (myself, Richard Hughes, Jon McCann, Dan Williams, others). Hope it's useful. Thanks. David [1] : includes - gnome-screensaver - gnome-power-manager - gnome-volume-manager - NetworkManager-gnome From mattdm at mattdm.org Mon Dec 4 16:45:36 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 4 Dec 2006 11:45:36 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165250477.2484.18.camel@zelda.fubar.dk> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> Message-ID: <20061204164536.GA8329@jadzia.bu.edu> On Mon, Dec 04, 2006 at 11:41:17AM -0500, David Zeuthen wrote: > knows, maybe the system administrator can just tweak a few settings in > the Fedora Directory Server and the changes gets propagated out to his > servers. I really think that's the user experience we want; not some set > of human-editable configuration files in /etc. Who is "we" here, though? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ajackson at redhat.com Mon Dec 4 16:44:50 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 04 Dec 2006 11:44:50 -0500 Subject: Running with the brakes on ... In-Reply-To: References: Message-ID: <1165250690.7683.136.camel@localhost.localdomain> On Mon, 2006-12-04 at 02:13 -0500, Paul Michael Reilly wrote: > When running top, I see that X is consuming 40% of memory which is not > surprising since I am running two X sessions with 3200x1200 (dual > head, radeon, open source) along with long running firefox, > thunderbird and VNC (also 3200x1200) apps). But when I bring up the > Soundcard Detection tool under KDE top shows Xorg is consistently > grabbing 93% of the CPU even when all I am doing is typing this > message. That would certainly explain a lot of the lag in response to > mouse clicks from the app. :-) Switching to Gnome and running top > there shows varying, but high (60%ish) CPU use with the Soundcard > Detection tool still running in both sessions. But with Gnome, > response to mousee clicks is fine, even with the high X CPU use. So you've found that some use profile makes X use all the CPU. Now you need to find out _what_ in X is taking all the time. You need to either use a tool like oprofile or sysprof to extract that information, or you need to instrument the X server to report on what requests and clients are using most of its time. The latter requires code changes to a project that many people find intimidating and/or unpleasant to work with, which is why I suggested using oprofile in the first place. - ajax From david at fubar.dk Mon Dec 4 16:59:06 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 04 Dec 2006 11:59:06 -0500 Subject: CPU Frequency Scaling In-Reply-To: <20061204164536.GA8329@jadzia.bu.edu> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> Message-ID: <1165251546.2484.28.camel@zelda.fubar.dk> On Mon, 2006-12-04 at 11:45 -0500, Matthew Miller wrote: > On Mon, Dec 04, 2006 at 11:41:17AM -0500, David Zeuthen wrote: > > knows, maybe the system administrator can just tweak a few settings in > > the Fedora Directory Server and the changes gets propagated out to his > > servers. I really think that's the user experience we want; not some set > > of human-editable configuration files in /etc. > > Who is "we" here, though? Should be evident: only speaking for myself, of course, hoping to influence the Fedora Project otherwise I wouldn't be posting this to the development list of the Fedora Project, would I? It's a meritocracy after all isn't it? (Hoping this thread won't turn into yet-another-thread about (the important topic of) how the Fedora project is governed. I'm so not getting into that because I'm busy enough doing software.) Now, just because I'm curious, do you disagree this is not the user experience we want? (Or did you just want to discuss matters raised in the previous paragraph? If so, please take it to the fedora-advisory-board at redhat.com instead. Thanks.) David From twoerner at redhat.com Mon Dec 4 17:05:50 2006 From: twoerner at redhat.com (Thomas Woerner) Date: Mon, 04 Dec 2006 18:05:50 +0100 Subject: tcp_wrappers Message-ID: <4574556E.4040008@redhat.com> Hello, tcp_wrappers has two new sub packages: tcp_wrappers-devel and tcp_wrappers-libs. All build requirements for tcp_wrappers have to get changed to tcp_wrappers-devel. Thanks, Thomas -- Thomas Woerner Software Engineer Phone: +49-711-96437-310 Red Hat GmbH Fax : +49-711-96437-111 Hauptstaetterstr. 58 Email: Thomas Woerner D-70178 Stuttgart Web : http://www.redhat.de/ From mattdm at mattdm.org Mon Dec 4 17:09:07 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 4 Dec 2006 12:09:07 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165251546.2484.28.camel@zelda.fubar.dk> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> Message-ID: <20061204170907.GA10166@jadzia.bu.edu> On Mon, Dec 04, 2006 at 11:59:06AM -0500, David Zeuthen wrote: > > > knows, maybe the system administrator can just tweak a few settings in > > > the Fedora Directory Server and the changes gets propagated out to his > > > servers. I really think that's the user experience we want; not some > > > set of human-editable configuration files in /etc. > > Who is "we" here, though? > Should be evident: only speaking for myself, of course, hoping to > influence the Fedora Project otherwise I wouldn't be posting this to the > development list of the Fedora Project, would I? It's a meritocracy > after all isn't it? No, I didn't mean that, sorry, and I definitely don't want to take the conversation in *that* direction. I'm just not convinced that not being able to ssh in to a server and edit some config files but rather have to figure out how to tweak the policy-daemon-of-the-month is the user experience a large segment of "we" wants at all. Human-editable config files are a huge strength. Using a policy daemon may be part of the answer, but it should be able to get its configuration from something that can be fixed with vi. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jon.nettleton at gmail.com Mon Dec 4 17:14:33 2006 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Mon, 04 Dec 2006 12:14:33 -0500 Subject: CPU Frequency Scaling In-Reply-To: <20061204170907.GA10166@jadzia.bu.edu> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> Message-ID: <1165252474.17010.13.camel@averatec.charles.net> On Mon, 2006-12-04 at 12:09 -0500, Matthew Miller wrote: > On Mon, Dec 04, 2006 at 11:59:06AM -0500, David Zeuthen wrote: > > > > knows, maybe the system administrator can just tweak a few settings in > > > > the Fedora Directory Server and the changes gets propagated out to his > > > > servers. I really think that's the user experience we want; not some > > > > set of human-editable configuration files in /etc. > > > Who is "we" here, though? > > Should be evident: only speaking for myself, of course, hoping to > > influence the Fedora Project otherwise I wouldn't be posting this to the > > development list of the Fedora Project, would I? It's a meritocracy > > after all isn't it? > > No, I didn't mean that, sorry, and I definitely don't want to take the > conversation in *that* direction. > > I'm just not convinced that not being able to ssh in to a server and edit > some config files but rather have to figure out how to tweak the > policy-daemon-of-the-month is the user experience a large segment of "we" > wants at all. Human-editable config files are a huge strength. Using a > policy daemon may be part of the answer, but it should be able to get its > configuration from something that can be fixed with vi. > I definitely agree with this point of view. Jon From db-fedora at 3di.it Mon Dec 4 17:16:15 2006 From: db-fedora at 3di.it (Davide Bolcioni) Date: Mon, 04 Dec 2006 18:16:15 +0100 Subject: CPU Frequency Scaling In-Reply-To: <1165250477.2484.18.camel@zelda.fubar.dk> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> Message-ID: <457457DF.6020709@3di.it> David Zeuthen wrote: > Moreover, with the policy daemons reading settings from gconf, who > knows, maybe the system administrator can just tweak a few settings in > the Fedora Directory Server and the changes gets propagated out to his > servers. I really think that's the user experience we want; not some set > of human-editable configuration files in /etc. Experience tells us that a set of human-editable configuration files is very reliable. Maybe said set could be read by each client after asking the policy daemon; this way, we can both (a) let the local administrator take the matter in his hands, and (b) have a fallback if the policy daemon is not running, which leads to (c) the local administrator can do away with the policy daemon entirely and remove (rpm -e) it on locked-down hosts (hoping nothing is shipped which *requires* the policy daemons, of course). Just my $0.02, Davide Bolcioni -- Paranoia is a survival asset. From david at fubar.dk Mon Dec 4 17:31:19 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 04 Dec 2006 12:31:19 -0500 Subject: CPU Frequency Scaling In-Reply-To: <20061204170907.GA10166@jadzia.bu.edu> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> Message-ID: <1165253479.2484.44.camel@zelda.fubar.dk> On Mon, 2006-12-04 at 12:09 -0500, Matthew Miller wrote: > I'm just not convinced that not being able to ssh in to a server and edit > some config files but rather have to figure out how to tweak the > policy-daemon-of-the-month is the user experience a large segment of "we" > wants at all. Human-editable config files are a huge strength. Using a > policy daemon may be part of the answer, but it should be able to get its > configuration from something that can be fixed with vi. No-one says you can't have command line tools to set g-p-m preferences and that you can't use them while logging in via ssh. Heck, since gconftool-2 already exists you can do this already; just write a small shell script, gpm-set-governor or whatever, and it'll already work. I can't speak for Richard but if we do this thing of making g-p-m run in the unusual cases when no-one is logged in, I'm pretty damn sure he would take patches providing such functionality. You or others would probably have to do the work however. We're not taking functionality away from you and no-one prevents you or others from writing and using software that utilizes configuration files if that's what you want. I just don't think this is what Fedora needs in a default install. And if I have it my way you'll have a much more powerful way of controlling policy on servers; one that provides UI for system administrators and one that, down the road, scales to getting the policy from the network via some futuristic networked LDAP backend for gconf or whatever. The price you pay? Maybe you'll have to use dedicated command line tools instead of editing a file in /etc. Understand that we, the developers of these bits, are actually trying to reach out and make it easier for system administrators like yourself. Both sides gotta give a little. David From davej at redhat.com Mon Dec 4 17:58:05 2006 From: davej at redhat.com (Dave Jones) Date: Mon, 4 Dec 2006 12:58:05 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165232586.3147.3.camel@hughsie-laptop> References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> <1165232586.3147.3.camel@hughsie-laptop> Message-ID: <20061204175805.GA26115@redhat.com> On Mon, Dec 04, 2006 at 11:43:06AM +0000, Richard Hughes wrote: > On Mon, 2006-12-04 at 11:38 +0100, Thomas M Steenholdt wrote: > > If the scaling governor is quick enough to detect the need and perform > > the transition, most workloads.... > > I've had complaint, (and noticed myself) that conservative and ondemand > often take a few hundred ms to "ramp up" to a suitable frequency. > Ordinarily this isn't a problem, but with my dual 1.6Ghz laptop idling > down to 1Ghz, clicking 'Applications' doesn't feel as "snappy" as it > should. It doesn't strike you that something might be amiss that a 1GHz CPU can't display a menu quick enough ? Shuffling the problem under the rug isn't the way to fix this. Find out why it's taking so long, and fix that. Dave From galibert at pobox.com Mon Dec 4 18:12:17 2006 From: galibert at pobox.com (Olivier Galibert) Date: Mon, 4 Dec 2006 19:12:17 +0100 Subject: CPU Frequency Scaling In-Reply-To: <1165253479.2484.44.camel@zelda.fubar.dk> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> Message-ID: <20061204181217.GA33394@dspnet.fr.eu.org> On Mon, Dec 04, 2006 at 12:31:19PM -0500, David Zeuthen wrote: > On Mon, 2006-12-04 at 12:09 -0500, Matthew Miller wrote: > > I'm just not convinced that not being able to ssh in to a server and edit > > some config files but rather have to figure out how to tweak the > > policy-daemon-of-the-month is the user experience a large segment of "we" > > wants at all. Human-editable config files are a huge strength. Using a > > policy daemon may be part of the answer, but it should be able to get its > > configuration from something that can be fixed with vi. > > No-one says you can't have command line tools to set g-p-m preferences > and that you can't use them while logging in via ssh. He did not say "command line tools", he said "vi". That's a hell of a difference. Text file processing comes with a nice set of tools for diffing, patching, synchronizing, etc. Gconf doesn't. Xml is piss-poor to run sed or grep on. > Heck, since > gconftool-2 already exists you can do this already; just write a small > shell script, gpm-set-governor or whatever, and it'll already work. I > can't speak for Richard but if we do this thing of making g-p-m run in > the unusual cases when no-one is logged in, I'm pretty damn sure he > would take patches providing such functionality. You or others would > probably have to do the work however. In the 200 or so fedora installations I have around, around 30 see someone logged on. Remote administration capabilities and network transparency are some of the points that allowed Unix is survive against Windows. Please do stop thinking that the "openoffice gnome desktop" user is the only worthwhile one. Especially since he often isn't the one doing the linux installation in the first place. OG. From david at lovesunix.net Mon Dec 4 19:14:00 2006 From: david at lovesunix.net (David Nielsen) Date: Mon, 04 Dec 2006 20:14:00 +0100 Subject: CPU Frequency Scaling In-Reply-To: <20061204170907.GA10166@jadzia.bu.edu> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> Message-ID: <1165259640.3582.29.camel@dawkins> man, 04 12 2006 kl. 12:09 -0500, skrev Matthew Miller: > On Mon, Dec 04, 2006 at 11:59:06AM -0500, David Zeuthen wrote: > > > > knows, maybe the system administrator can just tweak a few settings in > > > > the Fedora Directory Server and the changes gets propagated out to his > > > > servers. I really think that's the user experience we want; not some > > > > set of human-editable configuration files in /etc. > > > Who is "we" here, though? > > Should be evident: only speaking for myself, of course, hoping to > > influence the Fedora Project otherwise I wouldn't be posting this to the > > development list of the Fedora Project, would I? It's a meritocracy > > after all isn't it? > > No, I didn't mean that, sorry, and I definitely don't want to take the > conversation in *that* direction. > > I'm just not convinced that not being able to ssh in to a server and edit > some config files but rather have to figure out how to tweak the > policy-daemon-of-the-month is the user experience a large segment of "we" > wants at all. Human-editable config files are a huge strength. Using a > policy daemon may be part of the answer, but it should be able to get its > configuration from something that can be fixed with vi. I disagree, first up, once we get an implementation we are happy with there should be no reason to change the policy-daemon so that argument is weak at best. As for human-editable config files, that has worked so poorly for us in the past, it makes Linux painful to use, just notice how much easier Linux got to use after we got HAL integrated. Back then we had basically the same argument and now I don't know a single person who would live without HAL. In addition, no two programs have ever been able to agree on a config file format so you need to learn every location and format regardless of how readable they are. Given that we could either do policy based configuration or at least unify the configuration files in one interface (akin to Elektra - generally agreed upon as not being the best solution). We will never get upstream to universally adopt something like Elektra so it would mean carrying a massive delta with all that entails of additional work and potential bugs. A policy daemon is a fine solution to this problem and we get extra functionality to boot. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From david at fubar.dk Mon Dec 4 18:34:36 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 04 Dec 2006 13:34:36 -0500 Subject: CPU Frequency Scaling In-Reply-To: <20061204181217.GA33394@dspnet.fr.eu.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> Message-ID: <1165257276.2484.61.camel@zelda.fubar.dk> On Mon, 2006-12-04 at 19:12 +0100, Olivier Galibert wrote: > He did not say "command line tools", he said "vi". I did read that. > In the 200 or so fedora installations I have around, around 30 see > someone logged on. Remote administration capabilities and network > transparency are some of the points that allowed Unix is survive > against Windows. Please do stop thinking that the "openoffice gnome > desktop" user is the only worthwhile one. Especially since he often > isn't the one doing the linux installation in the first place. I was, in fact, arguing for remote admin capabilities. Did you read my mail at all? David From notting at redhat.com Mon Dec 4 18:42:15 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 4 Dec 2006 13:42:15 -0500 Subject: CPU Frequency Scaling In-Reply-To: <20061204175805.GA26115@redhat.com> References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> <1165232586.3147.3.camel@hughsie-laptop> <20061204175805.GA26115@redhat.com> Message-ID: <20061204184215.GB31682@nostromo.devel.redhat.com> Dave Jones (davej at redhat.com) said: > It doesn't strike you that something might be amiss that a 1GHz CPU > can't display a menu quick enough ? Shuffling the problem under the rug > isn't the way to fix this. Find out why it's taking so long, and fix that. It's scanning the desktop files, almost certainly. What bugs *me* about it is that there's a stuck grab in there somewhere: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202874 Bill From mattdm at mattdm.org Mon Dec 4 18:52:16 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 4 Dec 2006 13:52:16 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165253479.2484.44.camel@zelda.fubar.dk> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> Message-ID: <20061204185216.GA15568@jadzia.bu.edu> On Mon, Dec 04, 2006 at 12:31:19PM -0500, David Zeuthen wrote: > gconftool-2 already exists you can do this already; just write a small > shell script, gpm-set-governor or whatever, and it'll already work. I > can't speak for Richard but if we do this thing of making g-p-m run in > the unusual cases when no-one is logged in, I'm pretty damn sure he I think calling this an "unusual case" is the root cause of the difference in viewpoints here. > gconf or whatever. The price you pay? Maybe you'll have to use dedicated > command line tools instead of editing a file in /etc. Understand that > we, the developers of these bits, are actually trying to reach out and > make it easier for system administrators like yourself. Both sides gotta > give a little. I *do* appreciate your development work on this. I just want to help you understand an important segment of the "we" you mentioned before. This way of doing things isn't merely old-fashioned -- it's got concrete advantages which continue to be important to Linux as it moves forward. I don't mind using dedicated command line tools to accomplish tasks -- I'm fine with using chkconfig to manipulate runlevels, for example -- but the problem with adding a bunch more of these sorts of thing is that each one has its own new interface to learn (and relearn if you only do it infrequently). A key=value config file, on the other hand, can be understood immediately (particularly with decent comments). And, you can fix it with any old rescue environment -- no need for fancy tools. In the real world, that's *huge*. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dimi at lattica.com Mon Dec 4 18:56:06 2006 From: dimi at lattica.com (Dimi Paun) Date: Mon, 4 Dec 2006 13:56:06 -0500 (EST) Subject: CPU Frequency Scaling In-Reply-To: <1165250477.2484.18.camel@zelda.fubar.dk> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> Message-ID: <4266.207.245.37.34.1165258566.squirrel@lattica.com> On Mon, December 4, 2006 11:41 am, David Zeuthen wrote: > Moreover, with the policy daemons reading settings from gconf, who > knows, maybe the system administrator can just tweak a few settings in > the Fedora Directory Server and the changes gets propagated out to his > servers. I really think that's the user experience we want; not some set > of human-editable configuration files in /etc. I'm not sure why LDAP is seen as a better alternative to /etc. Every time I've tried using LDAP, it's been a horrific experience: it's complex, complicated, and obscure. Why would we want _that_ to be the user experience? Now, I'm all for centralized management, ease of use, etc. But LDAP is just a mechanism to achieve that, and it's not at all clear that's the best one for the job, and it's certainly not the only one. There's not such a great incomaptibility between having easily modifiable files in /etc and a good user experience. Why do they have to be mutually exclusive? -- Dimi Paun Lattica, Inc. From mattdm at mattdm.org Mon Dec 4 18:56:28 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 4 Dec 2006 13:56:28 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165257276.2484.61.camel@zelda.fubar.dk> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> Message-ID: <20061204185628.GB15568@jadzia.bu.edu> On Mon, Dec 04, 2006 at 01:34:36PM -0500, David Zeuthen wrote: > I was, in fact, arguing for remote admin capabilities. Did you read my > mail at all? The "futuristic networked LDAP backend" you mention presumes that you've got the luxury of setting up said backend in your environment and making all your systems work with it. In the ideal world, where the system analyst/admin gets dropped into a problem with a clean slate and a huge budget, that'd sounds great. Making it work in an existing heterogeneous enviroment where you've got working systems already deployed is different. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tmus at tmus.dk Mon Dec 4 18:55:54 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 04 Dec 2006 19:55:54 +0100 Subject: Blowfish encryption for local passwords In-Reply-To: <20061204132137.GB29472@jadzia.bu.edu> References: <20061203220233.GA28609@jadzia.bu.edu> <20061204110147.396e8cb6@banea.int.addix.net> <20061204132137.GB29472@jadzia.bu.edu> Message-ID: Matthew Miller wrote: > On Mon, Dec 04, 2006 at 11:18:26AM +0100, Thomas M Steenholdt wrote: >> I realize this - But both are viable options for storing passwords >> securely, and that's what my question is about. So in this context I >> think it's a fair apples to apples comparison :) > > We don't actually want to store passwords. > Right, but i think you get the point. /Thomas From david at fubar.dk Mon Dec 4 19:17:05 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 04 Dec 2006 14:17:05 -0500 Subject: CPU Frequency Scaling In-Reply-To: <20061204185628.GB15568@jadzia.bu.edu> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> Message-ID: <1165259825.2484.93.camel@zelda.fubar.dk> On Mon, 2006-12-04 at 13:56 -0500, Matthew Miller wrote: > On Mon, Dec 04, 2006 at 01:34:36PM -0500, David Zeuthen wrote: > > I was, in fact, arguing for remote admin capabilities. Did you read my > > mail at all? > > The "futuristic networked LDAP backend" you mention presumes that you've got > the luxury of setting up said backend in your environment and making all > your systems work with it. In the ideal world, where the system > analyst/admin gets dropped into a problem with a clean slate and a huge > budget, that'd sounds great. We've got all the essential bits as free software already (Fedora Directory Server, Sabayon [1], gconf, g-p-m bits). Someone just needs to start wiring these components together. (Of course it's going to be hard and it will surely involve fixing many of the interdependent components. The wins are, potentially, huge for system administrators administering lots of desktops.. and.. with reusing GNOME policy daemons system-wide as I'm proposing, also servers. Certainly a worth-while effort I think.) > Making it work in an existing heterogeneous > enviroment where you've got working systems already deployed is different. I think that point is well-understood but the Fedora Project (as I see it at least) is also about moving our OS forward. David [1] : http://www.gnome.org/projects/sabayon/ From mattdm at mattdm.org Mon Dec 4 19:23:36 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 4 Dec 2006 14:23:36 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165259825.2484.93.camel@zelda.fubar.dk> References: <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> Message-ID: <20061204192336.GA17780@jadzia.bu.edu> On Mon, Dec 04, 2006 at 02:17:05PM -0500, David Zeuthen wrote: > > Making it work in an existing heterogeneous enviroment where you've got > > working systems already deployed is different. > I think that point is well-understood but the Fedora Project (as I see > it at least) is also about moving our OS forward. Sure, but move forward into a niche corner? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From david at fubar.dk Mon Dec 4 19:30:45 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 04 Dec 2006 14:30:45 -0500 Subject: CPU Frequency Scaling In-Reply-To: <20061204192336.GA17780@jadzia.bu.edu> References: <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> Message-ID: <1165260645.2484.108.camel@zelda.fubar.dk> On Mon, 2006-12-04 at 14:23 -0500, Matthew Miller wrote: > On Mon, Dec 04, 2006 at 02:17:05PM -0500, David Zeuthen wrote: > > > Making it work in an existing heterogeneous enviroment where you've got > > > working systems already deployed is different. > > I think that point is well-understood but the Fedora Project (as I see > > it at least) is also about moving our OS forward. > > Sure, but move forward into a niche corner? I'm having problems responding to that. Sorry. David From david at fubar.dk Mon Dec 4 19:32:05 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 04 Dec 2006 14:32:05 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165260645.2484.108.camel@zelda.fubar.dk> References: <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> Message-ID: <1165260725.2484.110.camel@zelda.fubar.dk> On Mon, 2006-12-04 at 14:30 -0500, David Zeuthen wrote: > On Mon, 2006-12-04 at 14:23 -0500, Matthew Miller wrote: > > On Mon, Dec 04, 2006 at 02:17:05PM -0500, David Zeuthen wrote: > > > > Making it work in an existing heterogeneous enviroment where you've got > > > > working systems already deployed is different. > > > I think that point is well-understood but the Fedora Project (as I see > > > it at least) is also about moving our OS forward. > > > > Sure, but move forward into a niche corner? > > I'm having problems responding to that. Sorry. (I obviously meant s/that/that kind of language/) David From mattdm at mattdm.org Mon Dec 4 19:38:58 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 4 Dec 2006 14:38:58 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165260725.2484.110.camel@zelda.fubar.dk> References: <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> <1165260725.2484.110.camel@zelda.fubar.dk> Message-ID: <20061204193858.GA18344@jadzia.bu.edu> On Mon, Dec 04, 2006 at 02:32:05PM -0500, David Zeuthen wrote: > > > > > Making it work in an existing heterogeneous enviroment where > > > > > you've got working systems already deployed is different. > > > > I think that point is well-understood but the Fedora Project (as I see > > > > it at least) is also about moving our OS forward. > > > Sure, but move forward into a niche corner? > > I'm having problems responding to that. Sorry. > (I obviously meant s/that/that kind of language/) Okay, let me phrase it differently. Moving our OS forward is great, but there's no reason to _encourage_ this forward movement to be in directions that fit in less well in existing production environments. The situation where it's a great step forward for remote administration if and only if you set up a whole new special infrastructure is counterproductive. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From wcohen at redhat.com Mon Dec 4 19:41:33 2006 From: wcohen at redhat.com (William Cohen) Date: Mon, 04 Dec 2006 14:41:33 -0500 Subject: Running with the brakes on ... In-Reply-To: <1165250690.7683.136.camel@localhost.localdomain> References: <1165250690.7683.136.camel@localhost.localdomain> Message-ID: <457479ED.2020701@redhat.com> Adam Jackson wrote: > On Mon, 2006-12-04 at 02:13 -0500, Paul Michael Reilly wrote: > > >>When running top, I see that X is consuming 40% of memory which is not >>surprising since I am running two X sessions with 3200x1200 (dual >>head, radeon, open source) along with long running firefox, >>thunderbird and VNC (also 3200x1200) apps). But when I bring up the >>Soundcard Detection tool under KDE top shows Xorg is consistently >>grabbing 93% of the CPU even when all I am doing is typing this >>message. That would certainly explain a lot of the lag in response to >>mouse clicks from the app. :-) Switching to Gnome and running top >>there shows varying, but high (60%ish) CPU use with the Soundcard >>Detection tool still running in both sessions. But with Gnome, >>response to mousee clicks is fine, even with the high X CPU use. > > > So you've found that some use profile makes X use all the CPU. Now you > need to find out _what_ in X is taking all the time. You need to either > use a tool like oprofile or sysprof to extract that information, or you > need to instrument the X server to report on what requests and clients > are using most of its time. The latter requires code changes to a > project that many people find intimidating and/or unpleasant to work > with, which is why I suggested using oprofile in the first place. > > - ajax > Yes, certainly use OProfile to narrow down what code/package is using the CPU. If you are not familar with OProfile, there are some writeup on how to use OProfile to track down this kind of problem at: http://people.redhat.com/wcohen/ In particular the following articles would be a good place to start: http://people.redhat.com/wcohen/FedoraCore2OProfileTutorial.txt http://www.redhat.com/magazine/012oct05/features/oprofile/ You will probably need to install some debuginfo RPMs when doing the analysis of the collected data to see exactly which functions are using up the time. These can be install via yum. -Will From arjan at fenrus.demon.nl Mon Dec 4 19:45:54 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 04 Dec 2006 20:45:54 +0100 Subject: CPU Frequency Scaling In-Reply-To: <20061204184215.GB31682@nostromo.devel.redhat.com> References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> <1165232586.3147.3.camel@hughsie-laptop> <20061204175805.GA26115@redhat.com> <20061204184215.GB31682@nostromo.devel.redhat.com> Message-ID: <1165261554.3233.319.camel@laptopd505.fenrus.org> On Mon, 2006-12-04 at 13:42 -0500, Bill Nottingham wrote: > Dave Jones (davej at redhat.com) said: > > It doesn't strike you that something might be amiss that a 1GHz CPU > > can't display a menu quick enough ? Shuffling the problem under the rug > > isn't the way to fix this. Find out why it's taking so long, and fix that. > > It's scanning the desktop files, almost certainly. and how does that depend on a cpu going from 1.6Ghz to 1Ghz? Other than "NOT" From david at fubar.dk Mon Dec 4 20:01:59 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 04 Dec 2006 15:01:59 -0500 Subject: CPU Frequency Scaling In-Reply-To: <20061204193858.GA18344@jadzia.bu.edu> References: <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> <1165260725.2484.110.camel@zelda.fubar.dk> <20061204193858.GA18344@jadzia.bu.edu> Message-ID: <1165262519.2484.133.camel@zelda.fubar.dk> On Mon, 2006-12-04 at 14:38 -0500, Matthew Miller wrote: > Okay, let me phrase it differently. Moving our OS forward is great, but > there's no reason to _encourage_ this forward movement to be in directions > that fit in less well in existing production environments. The situation > where it's a great step forward for remote administration if and only if you > set up a whole new special infrastructure is counterproductive. No, doing things right (e.g. in a way so you can plug-in networked config backends) to start with is far better than having to deal with with retrofitting things later. Plus, people will never start to build networked config backends unless we actually start deploying software that will use it. Making e.g. g-p-m run when no-one is logged in solves a *bunch* of other problems; sorry if granting you these capabilities (that you didn't have earlier btw) as a system administrator causes you so much pain, e.g. that you can't hand-edit a bloody file in /etc using vi or emacs (but you will be able to run command tools as I mentioned in the other mail to tweak things). The whole proposal was put on the table to make life sweeter for system administrators like yourself. To gain feature parity for power management on the server and the desktop. To provide the same unique and powerful interface for configuring it. To attract admins not as trained as yourself. To enable remote administration in the future. And, frankly, this feature has not landed yet, I was just sharing some ideas from upstream. Sorry if it's too visionary for you. David From smooge at gmail.com Mon Dec 4 20:08:42 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 4 Dec 2006 13:08:42 -0700 Subject: Xen under vmware In-Reply-To: <20061204170031.357d7e9a@banea.int.addix.net> References: <20061204170031.357d7e9a@banea.int.addix.net> Message-ID: <80d7e4090612041208q21e3a388wfa741f4ee7390827@mail.gmail.com> On 12/4/06, Ralf Ertzinger wrote: > Hi. > > Is there a general problem with running a xen enabled system in a > vmware virtual machine? I'm losing all network connection from dom0 > as soon as network-bridge does it's weird magic, and I can not figure > out why. > I would expect so. I don't think they it is on purpose, but they are pretty much orthoganal in what they expect the kernel does for networking and such. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From mattdm at mattdm.org Mon Dec 4 20:09:27 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 4 Dec 2006 15:09:27 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165262519.2484.133.camel@zelda.fubar.dk> References: <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> <1165260725.2484.110.camel@zelda.fubar.dk> <20061204193858.GA18344@jadzia.bu.edu> <1165262519.2484.133.camel@zelda.fubar.dk> Message-ID: <20061204200927.GA20997@jadzia.bu.edu> On Mon, Dec 04, 2006 at 03:01:59PM -0500, David Zeuthen wrote: > that you can't hand-edit a bloody file in /etc using vi or emacs (but [...] > from upstream. Sorry if it's too visionary for you. Wow, got a chip on your shoulder much? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mitr at volny.cz Mon Dec 4 20:10:41 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Mon, 04 Dec 2006 21:10:41 +0100 Subject: CPU Frequency Scaling In-Reply-To: <1165262519.2484.133.camel@zelda.fubar.dk> References: <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> <1165260725.2484.110.camel@zelda.fubar.dk> <20061204193858.GA18344@jadzia.bu.edu> <1165262519.2484.133.camel@zelda.fubar.dk> Message-ID: <457480C1.7080104@volny.cz> David Zeuthen napsal(a): > On Mon, 2006-12-04 at 14:38 -0500, Matthew Miller wrote: >> Okay, let me phrase it differently. Moving our OS forward is great, but >> there's no reason to _encourage_ this forward movement to be in directions >> that fit in less well in existing production environments. The situation >> where it's a great step forward for remote administration if and only if you >> set up a whole new special infrastructure is counterproductive. > The whole proposal was put on the table to make life sweeter for system > administrators like yourself. If the system administrators have the choice between 1) writing a shell script that echo(1)s settings to files in sysfs, 2) writing a shell script that writes them to gconf (which is more complicated and not as easy to test as cat()ing sysfs files), running g-p-m and gconfd, why would they choose option 2) ? Regardless of the rosy possible future, you need sysadmin buy-in to the proposed solution _now_. If you don't get the buy-in in the first, say, two Fedora releases after the code is introducted, getting it later will be much harder. Mirek From david at fubar.dk Mon Dec 4 20:18:04 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 04 Dec 2006 15:18:04 -0500 Subject: CPU Frequency Scaling In-Reply-To: <20061204200927.GA20997@jadzia.bu.edu> References: <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> <1165260725.2484.110.camel@zelda.fubar.dk> <20061204193858.GA18344@jadzia.bu.edu> <1165262519.2484.133.camel@zelda.fubar.dk> <20061204200927.GA20997@jadzia.bu.edu> Message-ID: <1165263484.2484.135.camel@zelda.fubar.dk> On Mon, 2006-12-04 at 15:09 -0500, Matthew Miller wrote: > On Mon, Dec 04, 2006 at 03:01:59PM -0500, David Zeuthen wrote: > > that you can't hand-edit a bloody file in /etc using vi or emacs (but > [...] > > from upstream. Sorry if it's too visionary for you. > > Wow, got a chip on your shoulder much? And.. how's that constructive Matt? David From david at fubar.dk Mon Dec 4 20:19:35 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 04 Dec 2006 15:19:35 -0500 Subject: CPU Frequency Scaling In-Reply-To: <457480C1.7080104@volny.cz> References: <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> <1165260725.2484.110.camel@zelda.fubar.dk> <20061204193858.GA18344@jadzia.bu.edu> <1165262519.2484.133.camel@zelda.fubar.dk> <457480C1.7080104@volny.cz> Message-ID: <1165263575.2484.138.camel@zelda.fubar.dk> On Mon, 2006-12-04 at 21:10 +0100, Miloslav Trmac wrote: > If the system administrators have the choice between > 1) writing a shell script that echo(1)s settings to files in sysfs, > 2) writing a shell script that writes them to gconf (which is more > complicated and not as easy to test as cat()ing sysfs files), running > g-p-m and gconfd, The proposal was that g-p-m would ship with a set of commands that would do the heavy lifting, e.g. # gpm-set-cpuscaling ondemand etc. David From pjones at redhat.com Mon Dec 4 20:23:07 2006 From: pjones at redhat.com (Peter Jones) Date: Mon, 04 Dec 2006 15:23:07 -0500 Subject: Suggestion: Static libs policy, a draft In-Reply-To: <456BE0C3.7010308@redhat.com> References: <20061122100800.GQ6570@devserv.devel.redhat.com> <456AFE8D.8050205@odu.neva.ru> <20061127182234.GB32187@nostromo.devel.redhat.com> <456BE0C3.7010308@redhat.com> Message-ID: <1165263787.2795.12.camel@localhost.localdomain> On Mon, 2006-11-27 at 23:09 -0800, Ulrich Drepper wrote: > Bill Nottingham wrote: > >> In other words, for all statically linked executables in Core > >> (recovering, init/boot time etc.), all the libraries which take place in > >> the correspond static linkage must be present. > > > > Obviously. This is sort of prerequisite for self-hosting. > > Well, not so fast. There is no reason for booting to require static > linking. It might even be that the static linking meanwhile increases > the ramdisk size (2.7M for both binaries). In any case, we're not > booting from floppy disks anymore so this is not an issue. The static > linking should be removed where it is currently used for booting. And as of mkinitrd-6.0.1-1 , it mostly is. Some of the utilities mkinitrd pulls in are still statically linked (basically just lvm really). I'll release an update to use a dynamic lvm just as soon as there's an lvm2 package that provides dynamic executables. Until then, the initrd is actually significantly _bigger_ with dynamic linking. mkinitrd-6.0.1-1 should hit rawhide tomorrow. Testing will be much appreciated. -- Peter From jon.nettleton at gmail.com Mon Dec 4 20:35:50 2006 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Mon, 04 Dec 2006 15:35:50 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165263575.2484.138.camel@zelda.fubar.dk> References: <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> <1165260725.2484.110.camel@zelda.fubar.dk> <20061204193858.GA18344@jadzia.bu.edu> <1165262519.2484.133.camel@zelda.fubar.dk> <457480C1.7080104@volny.cz> <1165263575.2484.138.camel@zelda.fubar.dk> Message-ID: <1165264550.17010.25.camel@averatec.charles.net> On Mon, 2006-12-04 at 15:19 -0500, David Zeuthen wrote: > On Mon, 2006-12-04 at 21:10 +0100, Miloslav Trmac wrote: > > If the system administrators have the choice between > > 1) writing a shell script that echo(1)s settings to files in sysfs, > > 2) writing a shell script that writes them to gconf (which is more > > complicated and not as easy to test as cat()ing sysfs files), running > > g-p-m and gconfd, > > The proposal was that g-p-m would ship with a set of commands that would > do the heavy lifting, e.g. > > # gpm-set-cpuscaling ondemand Is that a temporary setting, or does it stick over restarts? Can a user that logs in override it? What is that command? Before I say anything about it I would love to see what is planned. Are there any use cases posted to a wiki somewhere? I think we could have a much more productive conversation about where Fedora is going if we all had a little more information. We are a community driven distribution right? Jon From list at pceet030.cern.ch Mon Dec 4 20:41:08 2006 From: list at pceet030.cern.ch (Alfredo Ferrari) Date: Mon, 4 Dec 2006 21:41:08 +0100 (CET) Subject: CPU Frequency Scaling In-Reply-To: <20061204170907.GA10166@jadzia.bu.edu> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> Message-ID: +1 for Matthew position On Mon, 4 Dec 2006, Matthew Miller wrote: > On Mon, Dec 04, 2006 at 11:59:06AM -0500, David Zeuthen wrote: >>>> knows, maybe the system administrator can just tweak a few settings in >>>> the Fedora Directory Server and the changes gets propagated out to his >>>> servers. I really think that's the user experience we want; not some >>>> set of human-editable configuration files in /etc. >>> Who is "we" here, though? >> Should be evident: only speaking for myself, of course, hoping to >> influence the Fedora Project otherwise I wouldn't be posting this to the >> development list of the Fedora Project, would I? It's a meritocracy >> after all isn't it? > > No, I didn't mean that, sorry, and I definitely don't want to take the > conversation in *that* direction. > > I'm just not convinced that not being able to ssh in to a server and edit > some config files but rather have to figure out how to tweak the > policy-daemon-of-the-month is the user experience a large segment of "we" > wants at all. Human-editable config files are a huge strength. Using a > policy daemon may be part of the answer, but it should be able to get its > configuration from something that can be fixed with vi. > > -- +----------------------------------------------------------------------------+ | Alfredo Ferrari || Tel.: +41.22.767.6119 | | C.E.R.N. || Fax.: +41.22.767.7555 | | European Laboratory for Particle Physics|| | | AB Division / ATB Group || e-mail: | | 1211 Geneva 23 || Alfredo.Ferrari at cern.ch | | Switzerland || Alfredo.Ferrari at mi.infn.it | +----------------------------------------------------------------------------+ From pmr at pajato.com Mon Dec 4 20:44:22 2006 From: pmr at pajato.com (Paul Reilly) Date: Mon, 04 Dec 2006 15:44:22 -0500 Subject: Running with the brakes on ... In-Reply-To: <457479ED.2020701@redhat.com> References: <1165250690.7683.136.camel@localhost.localdomain> <457479ED.2020701@redhat.com> Message-ID: <457488A6.3070308@pajato.com> William Cohen wrote: > Adam Jackson wrote: >> On Mon, 2006-12-04 at 02:13 -0500, Paul Michael Reilly wrote: >> >> >>> When running top, I see that X is consuming 40% of memory which is not >>> surprising since I am running two X sessions with 3200x1200 (dual >>> head, radeon, open source) along with long running firefox, >>> thunderbird and VNC (also 3200x1200) apps). But when I bring up the >>> Soundcard Detection tool under KDE top shows Xorg is consistently >>> grabbing 93% of the CPU even when all I am doing is typing this >>> message. That would certainly explain a lot of the lag in response to >>> mouse clicks from the app. :-) Switching to Gnome and running top >>> there shows varying, but high (60%ish) CPU use with the Soundcard >>> Detection tool still running in both sessions. But with Gnome, >>> response to mousee clicks is fine, even with the high X CPU use. >> >> >> So you've found that some use profile makes X use all the CPU. Now you >> need to find out _what_ in X is taking all the time. You need to either >> use a tool like oprofile or sysprof to extract that information, or you >> need to instrument the X server to report on what requests and clients >> are using most of its time. The latter requires code changes to a >> project that many people find intimidating and/or unpleasant to work >> with, which is why I suggested using oprofile in the first place. >> >> - ajax >> > > Yes, certainly use OProfile to narrow down what code/package is using > the CPU. If you are not familar with OProfile, there are some writeup > on how to use OProfile to track down this kind of problem at: > > http://people.redhat.com/wcohen/ > > In particular the following articles would be a good place to start: > > http://people.redhat.com/wcohen/FedoraCore2OProfileTutorial.txt > http://www.redhat.com/magazine/012oct05/features/oprofile/ > > You will probably need to install some debuginfo RPMs when doing the > analysis of the collected data to see exactly which functions are > using up the time. These can be install via yum. > > -Will Thanks Will. This is exactly what I was hoping to hear. Forgive me a small moment but this is just so much more productive and effective in motivating me to help Fedora than the terse, "use oprofile" message that I received twice. -pmr From notting at redhat.com Mon Dec 4 20:43:40 2006 From: notting at redhat.com (Bill Nottingham) Date: Mon, 4 Dec 2006 15:43:40 -0500 Subject: CPU Frequency Scaling In-Reply-To: <20061204170907.GA10166@jadzia.bu.edu> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> Message-ID: <20061204204340.GB2427@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > I'm just not convinced that not being able to ssh in to a server and edit > some config files but rather have to figure out how to tweak the > policy-daemon-of-the-month is the user experience a large segment of "we" > wants at all. Human-editable config files are a huge strength. Using a > policy daemon may be part of the answer, but it should be able to get its > configuration from something that can be fixed with vi. So, the entire thing boils down to "I don't like the g-conf storage format?" (I'm honestly asking here.) Bill From wtogami at redhat.com Mon Dec 4 20:50:45 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 04 Dec 2006 15:50:45 -0500 Subject: wpa and fc6/7 In-Reply-To: <3dd77c60612040001t4f813b5bn2c4e420fb2c59a9a@mail.gmail.com> References: <3dd77c60612040001t4f813b5bn2c4e420fb2c59a9a@mail.gmail.com> Message-ID: <45748A25.2010908@redhat.com> Mike Cohler wrote: > Can anyone tell me what the status of wpa_supplicant development is? > I tried to change over from WEP to WPA in fc6 and hit a brick wall. > >> From postings all over the net it seems that the vast majority of > people who try to get wpa going come across problems and struggle to > get anything working properly. The support for different hardware > seems erratic and largely undocumented. > > It appears to me that there is a need for some development as well as > some decent documentation to help people with this issue. > > What do others think? > I've personally been using WPA with NetworkManager with ipw2945 for the past several months with FC6 devel. It has been very stable for me. Warren Togami wtogami at redhat.com From david at fubar.dk Mon Dec 4 20:50:09 2006 From: david at fubar.dk (David Zeuthen) Date: Mon, 04 Dec 2006 15:50:09 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165264550.17010.25.camel@averatec.charles.net> References: <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> <1165260725.2484.110.camel@zelda.fubar.dk> <20061204193858.GA18344@jadzia.bu.edu> <1165262519.2484.133.camel@zelda.fubar.dk> <457480C1.7080104@volny.cz> <1165263575.2484.138.camel@zelda.fubar.dk> <1165264550.17010.25.camel@averatec.charles.net> Message-ID: <1165265409.2484.152.camel@zelda.fubar.dk> On Mon, 2006-12-04 at 15:35 -0500, Jon Nettleton wrote: > On Mon, 2006-12-04 at 15:19 -0500, David Zeuthen wrote: > > On Mon, 2006-12-04 at 21:10 +0100, Miloslav Trmac wrote: > > > If the system administrators have the choice between > > > 1) writing a shell script that echo(1)s settings to files in sysfs, > > > 2) writing a shell script that writes them to gconf (which is more > > > complicated and not as easy to test as cat()ing sysfs files), running > > > g-p-m and gconfd, > > > > The proposal was that g-p-m would ship with a set of commands that would > > do the heavy lifting, e.g. > > > > # gpm-set-cpuscaling ondemand > > Is that a temporary setting, or does it stick over restarts? It would stick over restarts; it would just be modifying the system-wide defaults gconf setting that all instances of g-p-m would read. > Can a user > that logs in override it? Yes. It's just gconf, an user can override settings unless they are the setting is set in the mandatory layer. Resolving settings currently involves three layers 1. System-wide mandatory settings 2. Per-user settings 3. System-wide defaults in that order. E.g. if a setting is in the mandatory layer, we don't consult the user, system defaults layers. (for doing this we'd probably stick a fourth layer in called "Factory defaults" e.g. the settings we ship with and currently install as system-wide defaults. This is easy and to avoid .rpmnew/.rpmold problems when a user modifies system-wide defaults. I believe Debian does this already.). For more information on gconf see http://developer.gnome.org/feature/archive/gconf/gconf.html > What is that command? It's not written, it was an example. I'd expect initial incarnations of it to just be a 10-line (and that's probably too high) shell script that invokes gconftool-2. > Before I say anything > about it I would love to see what is planned. Are there any use cases > posted to a wiki somewhere? I think we could have a much more > productive conversation about where Fedora is going if we all had a > little more information. We are a community driven distribution right? Everything written down is pretty much still in the GNOME bug I posted a link to. I'm busy with other things (RHEL-5, LiveCD, fast-user-switching, new hal+ PolicyKit+ConsoleKit releases, Christmas, LCA, emergency bug fixing) until February but feel free to create a Wiki page about it and post it to the list. Certainly, if anyone is to do such a thing one would be posting the proposal to f-d-l just like I did for fast-user-switching and, recently, live cd work. I just mentioned this thing to shed some light on some of the plans we have upstream and avoid duplication by introducing more confusing ways to configure power management. Whether Fedora wants to use that or not is another matter. David From mattdm at mattdm.org Mon Dec 4 21:15:44 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 4 Dec 2006 16:15:44 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165263484.2484.135.camel@zelda.fubar.dk> References: <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> <1165260725.2484.110.camel@zelda.fubar.dk> <20061204193858.GA18344@jadzia.bu.edu> <1165262519.2484.133.camel@zelda.fubar.dk> <20061204200927.GA20997@jadzia.bu.edu> <1165263484.2484.135.camel@zelda.fubar.dk> Message-ID: <20061204211544.GA24270@jadzia.bu.edu> On Mon, Dec 04, 2006 at 03:18:04PM -0500, David Zeuthen wrote: > On Mon, 2006-12-04 at 15:09 -0500, Matthew Miller wrote: > > On Mon, Dec 04, 2006 at 03:01:59PM -0500, David Zeuthen wrote: > > > that you can't hand-edit a bloody file in /etc using vi or emacs (but > > [...] > > > from upstream. Sorry if it's too visionary for you. > > Wow, got a chip on your shoulder much? > And.. how's that constructive Matt? Err, yeah, it didn't seem constructive at all. Whether I'm "visionary" or "bloody" isn't the issue. I'm trying to provide feedback, and you can listen or not. If you're too visionary to listen, well, so be it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From smooge at gmail.com Mon Dec 4 21:31:42 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 4 Dec 2006 14:31:42 -0700 Subject: wpa and fc6/7 In-Reply-To: <45748A25.2010908@redhat.com> References: <3dd77c60612040001t4f813b5bn2c4e420fb2c59a9a@mail.gmail.com> <45748A25.2010908@redhat.com> Message-ID: <80d7e4090612041331y219cf398mc17bc5d00b57d1a9@mail.gmail.com> On 12/4/06, Warren Togami wrote: > Mike Cohler wrote: > > Can anyone tell me what the status of wpa_supplicant development is? > > I tried to change over from WEP to WPA in fc6 and hit a brick wall. > > > >> From postings all over the net it seems that the vast majority of > > people who try to get wpa going come across problems and struggle to > > get anything working properly. The support for different hardware > > seems erratic and largely undocumented. > > > > It appears to me that there is a need for some development as well as > > some decent documentation to help people with this issue. > > > > What do others think? > > > > I've personally been using WPA with NetworkManager with ipw2945 for the > past several months with FC6 devel. It has been very stable for me. > I had problems with it for the first 2 weeks after the release (WPA would not work with my ipw3945 etc) . but what is currently on my system is working great. [It was kind of interesting.. it started working the day before Thanksgiving and has worked since then.] -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From tiagomatos at gmail.com Mon Dec 4 21:45:03 2006 From: tiagomatos at gmail.com (Rui Tiago =?ISO-8859-1?Q?Ca=E7=E3o?= Matos) Date: Mon, 04 Dec 2006 21:45:03 +0000 Subject: CPU Frequency Scaling In-Reply-To: <457480C1.7080104@volny.cz> References: <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> <1165260725.2484.110.camel@zelda.fubar.dk> <20061204193858.GA18344@jadzia.bu.edu> <1165262519.2484.133.camel@zelda.fubar.dk> <457480C1.7080104@volny.cz> Message-ID: <1165268703.3392.14.camel@hive> On Seg, 2006-12-04 at 21:10 +0100, Miloslav Trmac wrote: > If the system administrators have the choice between > 1) writing a shell script that echo(1)s settings to files in sysfs, > 2) writing a shell script that writes them to gconf (which is more > complicated and not as easy to test as cat()ing sysfs files), running > g-p-m and gconfd, Actually someone could even write a fuse filesystem to allow tweaking all this with your usual UNIX commands and thus grant you some sort of legacy compatibility. I understand that people are generally afraid of changes to working habits etc, but we can't stop at Linux is a good UNIX clone. We must evolve and search new possibilities, not being afraid to change 30 year old paradigms if needed. IMHO we (free software comunity) do need more integrated host and network level configurability at various levels: networking, power management, users, etc. I think the work being done by David Zeuthen and others is well headed it that direction and badly needed. Oh and don't come waving the windows_style_registry_is_evil flag because of a simple reason: this is free software, anyone with the required skills can participate in the design and the source is out there in the open. Oh and there's no need to copy other systems. We can and should IMO build on the concepts these other systems use that are proven to be robust, scalable and integrated though. Rui -------------- 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 Mon Dec 4 21:48:41 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 4 Dec 2006 15:48:41 -0600 Subject: CPU Frequency Scaling In-Reply-To: <1165262519.2484.133.camel@zelda.fubar.dk> References: <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> <1165260725.2484.110.camel@zelda.fubar.dk> <20061204193858.GA18344@jadzia.bu.edu> <1165262519.2484.133.camel@zelda.fubar.dk> Message-ID: <20061204214841.GC1083395@hiwaay.net> Once upon a time, David Zeuthen said: > Making e.g. g-p-m run when no-one is logged in solves a *bunch* of other > problems; sorry if granting you these capabilities (that you didn't have > earlier btw) as a system administrator causes you so much pain, e.g. > that you can't hand-edit a bloody file in /etc using vi or emacs (but > you will be able to run command tools as I mentioned in the other mail > to tweak things). Plain text config files are nice for system administration. They can be versioned with CVS (and others), they can be self documenting with comments, and they can even be edited on another system if necessary. Tools like sed and perl can make mass changes, grep can find arbitrary things, etc. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mattdm at mattdm.org Mon Dec 4 21:57:17 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 4 Dec 2006 16:57:17 -0500 Subject: CPU Frequency Scaling In-Reply-To: <20061204204340.GB2427@nostromo.devel.redhat.com> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> Message-ID: <20061204215717.GB24270@jadzia.bu.edu> On Mon, Dec 04, 2006 at 03:43:40PM -0500, Bill Nottingham wrote: > So, the entire thing boils down to "I don't like the g-conf storage > format?" (I'm honestly asking here.) It gets some *serious* dings for transparency, yeah -- and lack of transparency is one of the main enemies of the working sysadmin. It's kinda telling that gconf's own /etc/gconf/2/path is just a flat file. :) My initial comment was in response to the statement that the user experience "we" want is to be able to tweak settings in a directory server and have changes propagated out, specifically as opposed to human-editable configuration files in /etc. I don't think that's what we want at all. Ideally, we'd have *both* those things and not have them opposed at all. However, if we can't have both, it'd more useful to a large subset of "we" to have human-editable configuration files in /etc *rather* than the heavy-infrastructure machine-useful-human-difficult solution. Call me as non-visionary as you like, but I've already got a mile-long list of improvements that could be made to the infrastructure here, and I'm sure that's the case at every other large organization as well. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From g at socallinuxexpo.org Mon Dec 4 22:10:29 2006 From: g at socallinuxexpo.org (Gareth J. Greenaway) Date: Mon, 4 Dec 2006 14:10:29 -0800 Subject: Southern California Linux Expo 5x Opens Registration Message-ID: <200612041410.29493.g@socallinuxexpo.org> Effective immediately, registration for SCALE 5X is available at http://www.socallinuxexpo.org/order. The Early bird ticket price is $60 for full admission with a $30 admission for students with valid ID. Fedora developers can use the FDORA promotional code for a 40% discount on the full access pass. Prices go up Jan 24th, so don't dawdle; get registered now! If you're interested in seeing who's participating in SCALE, the exhibitor list is at http://socallinuxexpo.com/scale5x/exhibitions.php Fedora will be exhibiting at the show, come out and support your fellow developers! A partial list of speakers can be viewed at http://socallinuxexpo.com/scale5x/speakers.php SCALE will be February 10-11, 2007, at The Westin Los Angeles Airport. For those staying over, The Westin is offering special hotel room rates for the Expo. Hotel information is available here: http://socallinuxexpo.com/scale5x/location.php Thank You. -- Gareth J. Greenaway | g at socallinuxexpo.org Voice - 877-831-2569 x130 Southern California Linux Expo http://www.socallinuxexpo.org From florin at andrei.myip.org Mon Dec 4 22:21:10 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Mon, 04 Dec 2006 14:21:10 -0800 Subject: yum update can commit suicide Message-ID: <45749F56.8000705@andrei.myip.org> Yesterday I was trying to update my FC6 laptop. Quite a few updates, because this system was not used that much recently. I did not use the updates applet, because I was on a restrictive network: first establish a VPN connection, then you can use a proxy through VPN to browse the Internet. Since this is not my typical location, the proxy was not set in the desktop configuration. So I had to run yum manually in a terminal window. First do an "export http_proxy=..." then run yum. Halfway through the update, X was killed by some script in one of the update packages. Of course, that also killed yum, mid-transaction. :-( Init restarted X, of course, but now I was staring at the gdm login screen. This is pretty rude, not to mention that killing yum in the middle of a transaction can leave the system in a messy state. I'm not sure what needs to be fixed (don't kill X, or make yum or rpm smarter and don't kill X if the session is being run from within X, or something like that), I don't even know which package caused that, but my take is that this is something that needs to be fixed. -- Florin Andrei http://florin.myip.org/ From rstrode at redhat.com Mon Dec 4 22:59:30 2006 From: rstrode at redhat.com (Ray Strode) Date: Mon, 04 Dec 2006 17:59:30 -0500 Subject: yum update can commit suicide In-Reply-To: <45749F56.8000705@andrei.myip.org> References: <45749F56.8000705@andrei.myip.org> Message-ID: <1165273170.2643.5.camel@halflap.boston.devel.redhat.com> Hi, On Mon, 2006-12-04 at 14:21 -0800, Florin Andrei wrote: > Yesterday I was trying to update my FC6 laptop. Quite a few updates, > because this system was not used that much recently. ... > > Halfway through the update, X was killed by some script in one of the > update packages. Of course, that also killed yum, mid-transaction. :-( > Init restarted X, of course, but now I was staring at the gdm login screen. > Yea, it's a really nasty bug. You can track its progress here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218207 --Ray From jspaleta at gmail.com Mon Dec 4 23:47:56 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 4 Dec 2006 14:47:56 -0900 Subject: Running with the brakes on ... In-Reply-To: <1165250690.7683.136.camel@localhost.localdomain> References: <1165250690.7683.136.camel@localhost.localdomain> Message-ID: <604aa7910612041547r3daa0916n64f6e87e1085bdbd@mail.gmail.com> On 12/4/06, Adam Jackson wrote: > So you've found that some use profile makes X use all the CPU. Now you > need to find out _what_ in X is taking all the time. You need to either > use a tool like oprofile or sysprof to extract that information, or you > need to instrument the X server to report on what requests and clients > are using most of its time. The latter requires code changes to a > project that many people find intimidating and/or unpleasant to work > with, which is why I suggested using oprofile in the first place. is xrestop at all useful in this situation? -jef From ajackson at redhat.com Tue Dec 5 01:11:20 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 04 Dec 2006 20:11:20 -0500 Subject: Running with the brakes on ... In-Reply-To: <604aa7910612041547r3daa0916n64f6e87e1085bdbd@mail.gmail.com> References: <1165250690.7683.136.camel@localhost.localdomain> <604aa7910612041547r3daa0916n64f6e87e1085bdbd@mail.gmail.com> Message-ID: <1165281080.7683.152.camel@localhost.localdomain> On Mon, 2006-12-04 at 14:47 -0900, Jeff Spaleta wrote: > On 12/4/06, Adam Jackson wrote: > > So you've found that some use profile makes X use all the CPU. Now you > > need to find out _what_ in X is taking all the time. You need to either > > use a tool like oprofile or sysprof to extract that information, or you > > need to instrument the X server to report on what requests and clients > > are using most of its time. The latter requires code changes to a > > project that many people find intimidating and/or unpleasant to work > > with, which is why I suggested using oprofile in the first place. > > is xrestop at all useful in this situation? Not at the moment. xrestop right now is only useful for showing you client memory allocations (see /usr/include/X11/extensions/XRes*.h for the gory details). It would be pretty straightforward to hook up some basic per-client accounting in the scheduler, although it's slightly tricky to do that while not blowing away your dispatch performance, gettimeofday() is equivalent to about 10 (no-op) client requests. There's different metrics you want to measure there - number of requests, number of scheduler punishes, number of sleeps, total request time - and it's not immediately clear to me which ones would be worth doing and which would just be overhead. Would definitely be a pleasant thing to have though. - ajax From florin at andrei.myip.org Tue Dec 5 01:00:42 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Mon, 04 Dec 2006 17:00:42 -0800 Subject: CPU Frequency Scaling In-Reply-To: <200612032104.54541.eng@prowip.net.br> References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> Message-ID: <4574C4BA.1000908@andrei.myip.org> HM Eng.Prowip wrote: > mhhh ... especially for servers power does matter, power usage does not matter > at all but that is only a economical question, i got curious here do you run > your server really on DC or battery? In a datacenter with more than a few thousands of servers, energy consumption starts to matter quite a bit. And it's not just straight energy costs - it's also energy required to keep the temperature low and prevent the whole datacenter to boil over. Arjan is right - it's surprising to realize that people are not thinking about this issue a lot more. P.S.: Heck, my own webserver is an AMD64 2600 under the table in my living room, running 24/7. Come to think of it, I'd like to reduce the power consumption on that system a little bit, given that it's almost idle most of the time. -- Florin Andrei http://florin.myip.org/ From otaylor at redhat.com Mon Dec 4 22:56:17 2006 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 04 Dec 2006 17:56:17 -0500 Subject: Running with the brakes on ... In-Reply-To: <1165281080.7683.152.camel@localhost.localdomain> References: <1165250690.7683.136.camel@localhost.localdomain> <604aa7910612041547r3daa0916n64f6e87e1085bdbd@mail.gmail.com> <1165281080.7683.152.camel@localhost.localdomain> Message-ID: <1165272977.2507.7.camel@localhost.localdomain> On Mon, 2006-12-04 at 20:11 -0500, Adam Jackson wrote: > On Mon, 2006-12-04 at 14:47 -0900, Jeff Spaleta wrote: > > On 12/4/06, Adam Jackson wrote: > > > So you've found that some use profile makes X use all the CPU. Now you > > > need to find out _what_ in X is taking all the time. You need to either > > > use a tool like oprofile or sysprof to extract that information, or you > > > need to instrument the X server to report on what requests and clients > > > are using most of its time. The latter requires code changes to a > > > project that many people find intimidating and/or unpleasant to work > > > with, which is why I suggested using oprofile in the first place. > > > > is xrestop at all useful in this situation? > > Not at the moment. xrestop right now is only useful for showing you > client memory allocations (see /usr/include/X11/extensions/XRes*.h for > the gory details). It would be pretty straightforward to hook up some > basic per-client accounting in the scheduler, although it's slightly > tricky to do that while not blowing away your dispatch performance, > gettimeofday() is equivalent to about 10 (no-op) client requests. > > There's different metrics you want to measure there - number of > requests, number of scheduler punishes, number of sleeps, total request > time - and it's not immediately clear to me which ones would be worth > doing and which would just be overhead. Would definitely be a pleasant > thing to have though. What someone might want to think about is whether the X server can "leave about" the information about what client is working for that is accessible to sysprof and oprofile when they are taking a stack trace? Now there are some limitations there: - If the server is bottlenecked by the accelerator (acceleration code is better than than the accelerator) then the X server is going to spend most of its time waiting for some previous request to finish. Luckily that's seldom the case when X is a performance problem... - Even if you can associate the X call with the caller, it's much harder to associate it with a particular stack trace in the caller because of the asynchronous nature of X ... that stack trace is a distant memory. But it still could be useful. - Owen From opensource at till.name Tue Dec 5 02:42:31 2006 From: opensource at till.name (Till Maas) Date: Tue, 05 Dec 2006 03:42:31 +0100 Subject: Maintainance of hwdata Message-ID: <200612050342.40196.opensource@till.name> Hiyas, new bugs about hwdata are assigned to Karsten Hopp in bugzilla, but according to the changelog of hwdata he never made any change to it, ever. So is this normal for fedora core packages? Or is there maybe some false information about the maintainer of hwdata in Bugzilla because the open bugs seem to get not much attention. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From n0dalus+redhat at gmail.com Tue Dec 5 03:38:39 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Tue, 5 Dec 2006 14:08:39 +1030 Subject: CPU Frequency Scaling In-Reply-To: <1165158517.4001.4.camel@hughsie-laptop> References: <1165115008.2314.22.camel@averatec.charles.net> <1165157888.3233.225.camel@laptopd505.fenrus.org> <1165158517.4001.4.camel@hughsie-laptop> Message-ID: <6280325c0612041938i30cdc987p3f97208bf092e925@mail.gmail.com> On 12/4/06, Richard Hughes wrote: > > Yes, putting this feature in g-p-m allows the user to trivially set > different policy on AC and on battery, and we can also do some clever > things to try and save battery automatically. > I'm slightly concerned over the whole idea of per-user CPU scaling policies. Should users be able to have this kind of control over the hardware? If so, how should things work if more than one user is logged in at once and both are running different scaling policies? Personally I think the policy should be set globally by root, and there should be some control over which users, if any, are allowed to manually change the CPU speed. n0dalus. From peter at thecodergeek.com Tue Dec 5 05:28:49 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 04 Dec 2006 21:28:49 -0800 Subject: yum update can commit suicide In-Reply-To: <1165273170.2643.5.camel@halflap.boston.devel.redhat.com> References: <45749F56.8000705@andrei.myip.org> <1165273170.2643.5.camel@halflap.boston.devel.redhat.com> Message-ID: <1165296529.4233.1.camel@localhost> On Mon, 2006-12-04 at 17:59 -0500, Ray Strode wrote: > Yea, it's a really nasty bug. You can track its progress here: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=218207 > Apparently I'm the only one who has yet to be hit by this nasty bug; and I've been updating almost exclusively through Pup/Pirut since I first installed this FC6 system about two weeks after it's release. Geek's Luck, I guess... :| -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- 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 Tue Dec 5 08:25:05 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 5 Dec 2006 09:25:05 +0100 (CET) Subject: CPU Frequency Scaling In-Reply-To: <1165257276.2484.61.camel@zelda.fubar.dk> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> Message-ID: <56143.192.54.193.51.1165307105.squirrel@rousalka.dyndns.org> Le Lun 4 d?cembre 2006 19:34, David Zeuthen a ?crit : > On Mon, 2006-12-04 at 19:12 +0100, Olivier Galibert wrote: > Please do stop thinking that the "openoffice gnome >> desktop" user is the only worthwhile one. Especially since he often >> isn't the one doing the linux installation in the first place. > > I was, in fact, arguing for remote admin capabilities. Did you read my > mail at all? People want/need access to the configuration backend with simple robust CLI tools such as vi. Which shoudln't forbid XML or gconf use (we do require packagers to edit raw comps.xml.in for example) except the gconf guys forgot long ago they were supposed to produce human-editable XML and specialize in machine-oriented/obfuscated XML serialization. Which is a pity, because xslt is way more powerful and safe than diff/patch for admin scripting, but that requires discoverable file structure in the first place. Regards, -- Nicolas Mailhot From nicolas.mailhot at laposte.net Tue Dec 5 08:43:23 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 5 Dec 2006 09:43:23 +0100 (CET) Subject: CPU Frequency Scaling In-Reply-To: <20061204185628.GB15568@jadzia.bu.edu> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> Message-ID: <58944.192.54.193.51.1165308203.squirrel@rousalka.dyndns.org> Le Lun 4 d?cembre 2006 19:56, Matthew Miller a ?crit : > On Mon, Dec 04, 2006 at 01:34:36PM -0500, David Zeuthen wrote: >> I was, in fact, arguing for remote admin capabilities. Did you read my >> mail at all? > > The "futuristic networked LDAP backend" you mention presumes that you've > got the luxury of setting up said backend in your environment and making > all your systems work with it. In the ideal world, where the system > analyst/admin gets dropped into a problem with a clean slate and a huge > budget, that'd sounds great. Making it work in an existing heterogeneous > enviroment where you've got working systems already deployed is different. Well, MS proved generalized directory use was no problem for basic admins/devs as long as the directory server deployment itself was hassle-free. You have to take a longer view that what exists today, or no infrastructure change would ever be possible. However the LDAP stack in Fedora is not ready for such use today, and won't be till the Fedora Directory Server guys actually get their stuff in Rawhide and make it as easy to setup as Fedora Apache is. (The same argument could be written about JBoss & Java-on-Linux BTW. The fact SUN is lifting licensing restrictions won't magically push adoption by itself, unless there are serious packaging and streamlining follow-ups) -- Nicolas Mailhot From nicolas.mailhot at laposte.net Tue Dec 5 08:43:15 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 5 Dec 2006 09:43:15 +0100 (CET) Subject: CPU Frequency Scaling In-Reply-To: <20061204185628.GB15568@jadzia.bu.edu> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> Message-ID: <58466.192.54.193.51.1165308195.squirrel@rousalka.dyndns.org> Le Lun 4 d?cembre 2006 19:56, Matthew Miller a ?crit : > On Mon, Dec 04, 2006 at 01:34:36PM -0500, David Zeuthen wrote: >> I was, in fact, arguing for remote admin capabilities. Did you read my >> mail at all? > > The "futuristic networked LDAP backend" you mention presumes that you've > got the luxury of setting up said backend in your environment and making > all your systems work with it. In the ideal world, where the system > analyst/admin gets dropped into a problem with a clean slate and a huge > budget, that'd sounds great. Making it work in an existing heterogeneous > enviroment where you've got working systems already deployed is different. Well, MS proved generalized directory use was no problem for basic admins/devs as long as the directory server deployment itself was hassle-free. You have to take a longer view that what exists today, or no infrastructure change would ever be possible. However the LDAP stack in Fedora is not ready for such use today, and won't be till the Fedora Directory Server guys actually get their stuff in Rawhide and make it as easy to setup as Fedora Apache is. (The same argument could be written about JBoss & Java-on-Linux BTW. The fact SUN is lifting licensing restrictions won't magically push adoption by itself, unless there is serious packaging and streamlining follow-ups) -- Nicolas Mailhot From arjan at fenrus.demon.nl Tue Dec 5 08:54:44 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 05 Dec 2006 09:54:44 +0100 Subject: Running with the brakes on ... In-Reply-To: <1165250690.7683.136.camel@localhost.localdomain> References: <1165250690.7683.136.camel@localhost.localdomain> Message-ID: <1165308884.3233.353.camel@laptopd505.fenrus.org> On Mon, 2006-12-04 at 11:44 -0500, Adam Jackson wrote: > On Mon, 2006-12-04 at 02:13 -0500, Paul Michael Reilly wrote: > > > When running top, I see that X is consuming 40% of memory which is not > > surprising since I am running two X sessions with 3200x1200 (dual > > head, radeon, open source) along with long running firefox, > > thunderbird and VNC (also 3200x1200) apps). But when I bring up the > > Soundcard Detection tool under KDE top shows Xorg is consistently > > grabbing 93% of the CPU even when all I am doing is typing this > > message. That would certainly explain a lot of the lag in response to > > mouse clicks from the app. :-) Switching to Gnome and running top > > there shows varying, but high (60%ish) CPU use with the Soundcard > > Detection tool still running in both sessions. But with Gnome, > > response to mousee clicks is fine, even with the high X CPU use. > > So you've found that some use profile makes X use all the CPU. Now you > need to find out _what_ in X is taking all the time. You need to either > use a tool like oprofile or sysprof to extract that information, one easy way that might give a good clue is cstop (for context-switch top); it's a system tap script that reports the top context switchers http://www.fenrus.org/cstop.stp run this as stap -v cstop.stp (you need the kernel-debuginfo rpm installed for this to work) X will probably be way high up there, but so will the culprit which makes X do a lot of work, at least that's my experience.... From nicolas.mailhot at laposte.net Tue Dec 5 09:21:48 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 5 Dec 2006 10:21:48 +0100 (CET) Subject: CPU Frequency Scaling In-Reply-To: <20061204204340.GB2427@nostromo.devel.redhat.com> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> Message-ID: <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> Le Lun 4 d?cembre 2006 21:43, Bill Nottingham a ?crit : > Matthew Miller (mattdm at mattdm.org) said: >> I'm just not convinced that not being able to ssh in to a server and >> edit >> some config files but rather have to figure out how to tweak the >> policy-daemon-of-the-month is the user experience a large segment of >> "we" >> wants at all. Human-editable config files are a huge strength. Using a >> policy daemon may be part of the answer, but it should be able to get >> its >> configuration from something that can be fixed with vi. > > So, the entire thing boils down to "I don't like the g-conf storage > format?" (I'm honestly asking here.) What admin likes the g-conf storage format ? What admin likes the fact that unless you're careful gconfd will happily overwrite manual modifications because you've done them in vim and not (insert name of neutered GUI gconf tool there) I like XML but I'll take an old GNOME .ini conf file over a gconf one any day. Instead of being admin-friendly the gconf storage backend is over-optimized for developpers. Admins want/need stable schemas, sane file organization, stable formatting, pretty indenting, XML schemas registered in places vim and emacs can find them, safety of editing with whatever tool the admin likes best, no magic binary cookies use, explicit documentation Developpers want a system that can re-read conf files at blazing speed (so their app can read 20 times the same setting without impacting performance), with low change impedance (so they can stuff last-minute settings there or even change the format from version to version), and no hard documentation requirements (yay for burying configuration access in gconf-editor). They don't care if settings are not accessible without writing dedicated tools/scripts because writing code is what they do for a living. I wonder that anyone is surprised by the admin anguish over making a core infrastructure element depend on gconf. -- Nicolas Mailhot From tmus at tmus.dk Tue Dec 5 10:08:35 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 05 Dec 2006 11:08:35 +0100 Subject: CPU Frequency Scaling In-Reply-To: <1165262519.2484.133.camel@zelda.fubar.dk> References: <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> <1165260725.2484.110.camel@zelda.fubar.dk> <20061204193858.GA18344@jadzia.bu.edu> <1165262519.2484.133.camel@zelda.fubar.dk> Message-ID: David Zeuthen wrote: > Making e.g. g-p-m run when no-one is logged in solves a *bunch* of other > problems; sorry if granting you these capabilities (that you didn't have > earlier btw) as a system administrator causes you so much pain, e.g. > that you can't hand-edit a bloody file in /etc using vi or emacs (but > you will be able to run command tools as I mentioned in the other mail > to tweak things). One of the real strengths of *nixes is that we're immediately able to make use of *every* feature of a daemon for example. I'd really hate to see us going where windows is today, where all configurations are done via a specially designed tool, specialized to do only that job. 1) The feature you want to use HAS to be available through the config-tool, which is bad. A lot of daemons etc has so many options that it would be impossible to add the all to a user-friendly config tool. 2) If you want/need to take advantage of a new feature, you'll have to wait for development of the feature you need in the daemon AND in the config-tool. Development of the config tools can be ignored or postponed if the config files are human editable files. I've never really been a big fan of the gconf/win-registry thing. I really think we should avoid pushing it beyond the desktop. We need to remember what makes *nix so powerful and work hard to avoid losing those strengths. I'm not saying that config tools or GUIs are all bad, but I really don't think we should tie things up so tightly. just my .5 cents. /Thomas From tmus at tmus.dk Tue Dec 5 10:14:00 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 05 Dec 2006 11:14:00 +0100 Subject: CPU Frequency Scaling In-Reply-To: <1165268703.3392.14.camel@hive> References: <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> <1165260725.2484.110.camel@zelda.fubar.dk> <20061204193858.GA18344@jadzia.bu.edu> <1165262519.2484.133.camel@zelda.fubar.dk> <457480C1.7080104@volny.cz> <1165268703.3392.14.camel@hive> Message-ID: Rui Tiago Ca??o Matos wrote: > I understand that people are generally afraid of changes to working > habits etc, but we can't stop at Linux is a good UNIX clone. We must > evolve and search new possibilities, not being afraid to change 30 year > old paradigms if needed. IMHO we (free software comunity) do need more > integrated host and network level configurability at various levels: > networking, power management, users, etc. I think the work being done by > David Zeuthen and others is well headed it that direction and badly > needed. The old way of "Keeping It Simple" is powerful. Hand-editable configuration files have worked great in the past and continues to do so. Why would we want a new way of doing the same thing in a much more complex way? We should probably try to extend the old ways, rather than replacing them altogether. /Thomas From tmus at tmus.dk Tue Dec 5 10:23:47 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 05 Dec 2006 11:23:47 +0100 Subject: CPU Frequency Scaling In-Reply-To: <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > > What admin likes the g-conf storage format ? > What admin likes the fact that unless you're careful gconfd will happily > overwrite manual modifications because you've done them in vim and not > (insert name of neutered GUI gconf tool there) > > I like XML but I'll take an old GNOME .ini conf file over a gconf one any > day. > > Instead of being admin-friendly the gconf storage backend is > over-optimized for developpers. > > Admins want/need stable schemas, sane file organization, stable > formatting, pretty indenting, XML schemas registered in places vim and > emacs can find them, safety of editing with whatever tool the admin likes > best, no magic binary cookies use, explicit documentation > > Developpers want a system that can re-read conf files at blazing speed (so > their app can read 20 times the same setting without impacting > performance), with low change impedance (so they can stuff last-minute > settings there or even change the format from version to version), and no > hard documentation requirements (yay for burying configuration access in > gconf-editor). They don't care if settings are not accessible without > writing dedicated tools/scripts because writing code is what they do for a > living. > > I wonder that anyone is surprised by the admin anguish over making a core > infrastructure element depend on gconf. > Agreed!!! /Thomas From karsten at redhat.com Tue Dec 5 10:24:00 2006 From: karsten at redhat.com (Karsten Hopp) Date: Tue, 05 Dec 2006 11:24:00 +0100 Subject: Maintainance of hwdata In-Reply-To: <200612050342.40196.opensource@till.name> References: <200612050342.40196.opensource@till.name> Message-ID: <457548C0.5060401@redhat.com> Till Maas schrieb: > Hiyas, > > new bugs about hwdata are assigned to Karsten Hopp in bugzilla, but according > to the changelog of hwdata he never made any change to it, ever. So is this > normal for fedora core packages? Or is there maybe some false information > about the maintainer of hwdata in Bugzilla because the open bugs seem to get > not much attention. > > Regards, > Till > No, the bugzilla information is correct. I just recently got this package from Phil, that's why you won't find any changelogs from me yet. Karsten -- Karsten Hopp | Mail: karsten at redhat.de Red Hat Deutschland | Tel: +49-711-96437-0 Hauptstaetterstr.58 | Fax: +49-711-613590 D-70178 Stuttgart | http://www.redhat.de From david at lovesunix.net Tue Dec 5 11:44:19 2006 From: david at lovesunix.net (David Nielsen) Date: Tue, 05 Dec 2006 12:44:19 +0100 Subject: CPU Frequency Scaling In-Reply-To: References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> Message-ID: <1165319059.3089.12.camel@dawkins> tir, 05 12 2006 kl. 11:23 +0100, skrev Thomas M Steenholdt: > Nicolas Mailhot wrote: > > > > What admin likes the g-conf storage format ? > > What admin likes the fact that unless you're careful gconfd will happily > > overwrite manual modifications because you've done them in vim and not > > (insert name of neutered GUI gconf tool there) > > > > I like XML but I'll take an old GNOME .ini conf file over a gconf one any > > day. > > > > Instead of being admin-friendly the gconf storage backend is > > over-optimized for developpers. > > > > Admins want/need stable schemas, sane file organization, stable > > formatting, pretty indenting, XML schemas registered in places vim and > > emacs can find them, safety of editing with whatever tool the admin likes > > best, no magic binary cookies use, explicit documentation > > > > Developpers want a system that can re-read conf files at blazing speed (so > > their app can read 20 times the same setting without impacting > > performance), with low change impedance (so they can stuff last-minute > > settings there or even change the format from version to version), and no > > hard documentation requirements (yay for burying configuration access in > > gconf-editor). They don't care if settings are not accessible without > > writing dedicated tools/scripts because writing code is what they do for a > > living. > > > > I wonder that anyone is surprised by the admin anguish over making a core > > infrastructure element depend on gconf. > > > > Agreed!!! Solution, fix gconf rather than complain over davidz and friends at least suggesting a forward minded solution to the horror that is "human readable" configuration files. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From arjan at fenrus.demon.nl Tue Dec 5 10:52:59 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 05 Dec 2006 11:52:59 +0100 Subject: Maintainance of hwdata In-Reply-To: <457548C0.5060401@redhat.com> References: <200612050342.40196.opensource@till.name> <457548C0.5060401@redhat.com> Message-ID: <1165315979.3233.364.camel@laptopd505.fenrus.org> On Tue, 2006-12-05 at 11:24 +0100, Karsten Hopp wrote: > Till Maas schrieb: > > Hiyas, > > > > new bugs about hwdata are assigned to Karsten Hopp in bugzilla, but according > > to the changelog of hwdata he never made any change to it, ever. So is this > > normal for fedora core packages? Or is there maybe some false information > > about the maintainer of hwdata in Bugzilla because the open bugs seem to get > > not much attention. > > > > Regards, > > Till > > > > No, the bugzilla information is correct. I just recently got this package from > Phil, that's why you won't find any changelogs from me yet. one thing that would be nice is if the cpu microcode data would actually move from microcode_ctl to hwdata; the program almost never gets updated but the microcode file gets updated every few months (and soon the userspace isn't even needed anymore once Intel starts publishing it in the new format that 2.6.19 understands natively via firmware loader interface and the userspace app can go away) From skvidal at linux.duke.edu Tue Dec 5 11:09:37 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 05 Dec 2006 06:09:37 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165319059.3089.12.camel@dawkins> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> Message-ID: <1165316977.17513.37.camel@cutter> On Tue, 2006-12-05 at 12:44 +0100, David Nielsen wrote: > Solution, fix gconf rather than complain over davidz and friends at > least suggesting a forward minded solution to the horror that is "human > readable" configuration files. I've been reading this whole thread and I'm tired of a couple of semantics being used: 1. the assumption that all new development is 'progressive' or 'visionary'. Forward motion isn't always positive. So let's cut the spin and just call it what it is - a new interface. 2. That anyone promoting sticking with the status-quo is somehow backward. cut it out. -sv From buildsys at redhat.com Tue Dec 5 11:27:09 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 5 Dec 2006 06:27:09 -0500 Subject: rawhide report: 20061205 changes Message-ID: <200612051127.kB5BR9kC025254@hs20-bc2-6.build.redhat.com> Updated Packages: anacron-2.3-45.fc7 ------------------ * Mon Dec 04 2006 Marcela Maslanova 2.3-45 - rebuilt with pie insted pic bug-buddy-1:2.17.2-1.fc7 ------------------------ * Tue Dec 05 2006 Matthias Clasen - 1:2.17.2-1 - Update to 2.17.2 - Drop upstreamed patch evolution-connector-2.9.3-1.fc7 ------------------------------- * Mon Dec 04 2006 Matthew Barnes - 2.9.3-1.fc7 - Update to 2.9.3 - Require evolution-data-server-1.9.3. - Add %post section to install new schemas file. - Remove evolution-exchange-2.8.1-bump-requirements.patch (fixed upstream). evolution-data-server-1.9.3-1.fc7 --------------------------------- * Mon Dec 04 2006 Matthew Barnes - 1.9.3-1.fc7 - Update to 1.9.3 - Remove patch for GNOME bug #353924 (fixed upstream). file-roller-2.17.3-1.fc7 ------------------------ * Tue Dec 05 2006 Matthias Clasen - 2.17.3-1 - Update to 2.17.3 fonts-arabic-2.0-3.fc7 ---------------------- * Tue Dec 05 2006 Parag Nemade - 2.0-3 - Fixed bug 218411 PakTypeNaqsh.ttf contains a space in PS name freetype-2.2.1-16.fc6 --------------------- * Mon Dec 04 2006 Behdad Esfahbod 2.2.1-16 - Backport binary-search fixes from HEAD - Add freetype-2.2.1-ttcmap.patch - Resolves: #208734 gcalctool-5.9.8-1.fc7 --------------------- * Tue Dec 05 2006 Matthias Clasen - 5.9.8-1 - Update to 5.9.8 gedit-1:2.17.1-1.fc7 -------------------- * Tue Dec 05 2006 Matthias Clasen - 1:2.17.1-1 - Update to 2.17.1 * Mon Dec 04 2006 Matthias Clasen - 1:2.16.2-3 - Add BuildRequires for libattr-devel gnome-power-manager-2.17.3-1.fc7 -------------------------------- * Tue Dec 05 2006 Matthias Clasen - 2.17.3-1 - Update to 2.17.3 - Remove obsolete patch gnome-system-monitor-2.17.3-1.fc7 --------------------------------- * Tue Dec 05 2006 Matthias Clasen - 2.17.3-1 - Update to 2.17.3 gnome-themes-2.17.3-1.fc7 ------------------------- * Tue Dec 05 2006 Matthias Clasen - 2.17.3-1 - Update to 2.17.3 gtkhtml3-3.13.3-1.fc7 --------------------- * Mon Dec 04 2006 Matthew Barnes - 3.13.3-1.fc7 - Update to 3.13.3 - Remove patch for GNOME bug #353424 (fixed upstream). kernel-2.6.19-1.2844.fc7 ------------------------ * Mon Dec 04 2006 Dave Jones - 2.6.19-git5 * Wed Nov 29 2006 Dave Jones - 2.6.19 * Mon Nov 27 2006 Dave Jones - 2.6.19-rc6-git10 libgdiplus-1.2.2-1.fc7 ---------------------- * Mon Dec 04 2006 Alexander Larsson - 1.2.2-1 - Update to 1.2.2 - add ldconfig post/postun - Added doc files libgtop2-2.14.5-1.fc7 --------------------- * Tue Dec 05 2006 Matthias Clasen - 2.14.5-1 - Update to 2.14.5 - Require pkgconfig in the -devel package libpfm-3.2-0.061205.1.fc7 ------------------------- * Mon Dec 04 2006 Will Cohen - 3.2-0.061205.1 - Update to libpfm-3.2-061205. mc-1:4.6.1a-37.fc7 ------------------ * Mon Dec 04 2006 Jindrich Novy 4.6.1a-37 - update bindings - attempt to fcntl() descriptors appropriatelly so that subshell doesn't leave them open while execve()ing commands (#217027) - more general fix for #215909 * Mon Nov 27 2006 Jindrich Novy 4.6.1a-36 - don't crash when temporary directory cannot be created (#217342) mcstrans-0.1.10-1.fc7 --------------------- * Mon Dec 04 2006 Dan Walsh 0.1.10-1 - Fix Memory Leak Resolves: #218173 * Thu Sep 21 2006 Dan Walsh 0.1.9-1 - Add -pie - Fix compiler warnings - Fix Memory Leak Resolves: #218173 mesa-6.5.2-2.fc7 ---------------- * Mon Dec 04 2006 Adam Jackson 6.5.2-2.fc6 - Fix OSMesa file listing to use %version for DSO number. Note that this will still break on Mesa 7; oh well. - Deleted file: directfbgl.h * Sun Dec 03 2006 Kristian H??gsberg 6.5.2-1.fc6 - Update to 6.5.2. mkinitrd-6.0.1-1 ---------------- * Mon Dec 04 2006 Peter Jones - 6.0.1-1 - Fix library soname and link error. * Mon Dec 04 2006 Peter Jones - 6.0-1 - Merge in close() fix in bdevid probe code from rhel5 branch - Try to load raid456 module as well as individual level-based modules - more sophisticated modalias probing, so we get new storage drivers better (patch from notting) - Handle dynamic executables and libraries - Don't clobber the kernel command line when handling resume (#215084). - Fix test for "withusb" (#215314). - Link dynamically * Thu Oct 26 2006 Peter Jones - Don't reference "netdev" in addnetdev() - Only use one IP address for "remoteip" in handlenfs() - Abort much earlier if not invoked as UID 0 mono-1.2.2-1.fc7 ---------------- * Mon Dec 04 2006 Alexander Larsson - 1.2.2-1 - update to 1.2.2 - Mark config files as noreplace - Require pkgconfig in mono-devel - Run ldconfig in post/postun net-snmp-1:5.4-2.fc7 -------------------- * Mon Dec 04 2006 Radek Vok??l - 5.4-2 - rebuilt against tcp_wrappers-devel openldap-2.3.30-1.1.fc7 ----------------------- * Mon Dec 04 2006 Thomas Woerner 2.3.30-1.1.fc7 - tcp_wrappers has a new devel and libs sub package, therefore changing build requirement for tcp_wrappers to tcp_wrappers-devel openoffice.org-1:2.1.0-6.2 -------------------------- * Sun Dec 03 2006 Caolan McNamara - 1:2.1.0-6.2 - hazard some educated guesses as to dictionaries might be acceptable to speakers of the same language in neighbouring countries - Resolves: rhbz#218253 openoffice.org-2.1.0.oooXXXXX.vcl.filterzwatrender.patch orca-2.17.3-1.fc7 ----------------- * Tue Dec 05 2006 Matthias Clasen - 2.17.3-1 - Update to orca 2.17.3 paps-0.6.6-17.fc7 ----------------- * Mon Dec 04 2006 Akira TAGOH - 0.6.6-17 - Fix a segfault on non-printable character. (#216296) parted-1.8.1-1.fc7 ------------------ * Mon Dec 04 2006 David Cantrell - 1.8.1-1 - Upgrade to GNU parted-1.8.1 perl-RPM-Specfile-1.51-2.fc7 ---------------------------- * Sun Dec 03 2006 Robin Norwood - 1.51-2 - Add Requires: perl(YAML) pfmon-3.2-0.061205.1.fc7 ------------------------ * Mon Dec 04 2006 Will Cohen - 3.2-0.061205.1 - Update to pfmon-3.2-061205. portmap-4.0-65.3 ---------------- * Mon Dec 04 2006 Thomas Woerner - 4.0-65.3 - tcp_wrappers has a new devel and libs sub package, therefore changing build requirement for tcp_wrappers to tcp_wrappers-devel postgresql-8.2.0-1.fc7 ---------------------- * Mon Dec 04 2006 Tom Lane 8.2.0-1 - Update to PostgreSQL 8.2.0 - Update to PyGreSQL 3.8.1 - Fix chcon arguments in test/regress/Makefile Related: #201035 - Adjust init script to not fool /etc/rc.d/rc Resolves: #161470 - Change init script to not do initdb automatically, but require manual "service postgresql initdb" for safety. Per upstream discussions. quota-1:3.13-1.3.fc7 -------------------- * Mon Dec 04 2006 Thomas Woerner 1:3.13-1.3 - tcp_wrappers has a new devel and libs sub package, therefore changing build requirement for tcp_wrappers to tcp_wrappers-devel sendmail-8.13.8-3.1 ------------------- * Mon Dec 04 2006 Thomas Woerner 8.13.8-3.1 - tcp_wrappers has a new devel and libs sub package, therefore changing build requirement for tcp_wrappers to tcp_wrappers-devel stunnel-4.20-2 -------------- * Mon Dec 04 2006 Miloslav Trmac - 4.20-2 - Update BuildRequires for the separate tcp_wrappers-devel package tcp_wrappers-7.6-41 ------------------- * Mon Dec 04 2006 Thomas Woerner 7.6-41 - moved devel libraries, headers and man pages into devel sub package (#193188) - new libs sub package for libraries - using BuildRequires instead of BuildPreReq texinfo-4.8-15 -------------- * Mon Dec 04 2006 Miloslav Trmac - 4.8-15 - Don't replace 0xA0 by a space in makeinfo Related: #208511 - Fix some rpmlint warnings vnc-4.1.2-7.1.fc7 ----------------- * Mon Dec 04 2006 Thomas Woerner 4.1.2-7.1.fc7 - tcp_wrappers has a new devel and libs sub package, therefore changing build requirement for tcp_wrappers to tcp_wrappers-devel xinetd-2:2.3.14-11 ------------------ * Mon Dec 04 2006 Thomas Woerner - 2:2.3.14-11 - tcp_wrappers has a new devel and libs sub package, therefore changing build requirement for tcp_wrappers to tcp_wrappers-devel xorg-x11-drv-mga-1.4.5-2.fc7 ---------------------------- * Mon Dec 04 2006 Adam Jackson 1.4.5-2 - mga-1.4.5-no-hal-advertising.patch: Don't link to the HAL module as it's non-free. xorg-x11-drv-vesa-1.3.0-1.fc7 ----------------------------- * Mon Dec 04 2006 Adam Jackson 1.3.0-1 - Update to 1.3.0 - vesa-1.2.1-validmode.patch: Implement a ValidMode driver hook, which rejects modes not present in the BIOS or outside the capability of the monitor. zenity-2.17.1-1.fc7 ------------------- * Tue Dec 05 2006 Matthias Clasen - 2.17.1-1 - Update to 2.17.1 * Mon Dec 04 2006 Matthias Clasen - 2.16.1-2 - Add a BuildRequires for libnotify-devel Broken deps for ia64 ---------------------------------------------------------- apr-util - 1.2.7-5.ia64 requires libpq.so.4()(64bit) bind-sdb - 30:9.3.3-6.fc7.ia64 requires libpq.so.4()(64bit) cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.ia64 requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.ia64 requires libpq.so.4()(64bit) gnome-volume-manager - 2.17.0-2.fc7.ia64 requires kernel >= 0:2.6 libdbi-dbd-pgsql - 0.8.1a-1.2.2.ia64 requires libpq.so.4()(64bit) mod_auth_pgsql - 2.0.3-2.3.1.ia64 requires libpq.so.4()(64bit) pcmciautils - 014-5.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 perl-DBD-Pg - 1.49-1.fc6.ia64 requires libpq.so.4()(64bit) perl-RPM-Specfile - 1.51-2.fc7.noarch requires perl(YAML) php-pgsql - 5.2.0-7.ia64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ia64 requires libpq.so.4()(64bit) qt-PostgreSQL - 1:3.3.7-1.fc7.ia64 requires libpq.so.4()(64bit) systemtap - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 Broken deps for i386 ---------------------------------------------------------- apr-util - 1.2.7-5.i386 requires libpq.so.4 bind-sdb - 30:9.3.3-6.fc7.i386 requires libpq.so.4 cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.i386 requires libpq.so.4 freeradius-postgresql - 1.1.3-2.i386 requires libpq.so.4 libdbi-dbd-pgsql - 0.8.1a-1.2.2.i386 requires libpq.so.4 mod_auth_pgsql - 2.0.3-2.3.1.i386 requires libpq.so.4 perl-DBD-Pg - 1.49-1.fc6.i386 requires libpq.so.4 perl-RPM-Specfile - 1.51-2.fc7.noarch requires perl(YAML) php-pgsql - 5.2.0-7.i386 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.i386 requires libpq.so.4 qt-PostgreSQL - 1:3.3.7-1.fc7.i386 requires libpq.so.4 Broken deps for ppc64 ---------------------------------------------------------- apr-util - 1.2.7-5.ppc64 requires libpq.so.4()(64bit) bind-sdb - 30:9.3.3-6.fc7.ppc64 requires libpq.so.4()(64bit) cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.ppc64 requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.ppc64 requires libpq.so.4()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc64 requires libpq.so.4()(64bit) mod_auth_pgsql - 2.0.3-2.3.1.ppc64 requires libpq.so.4()(64bit) perl-DBD-Pg - 1.49-1.fc6.ppc64 requires libpq.so.4()(64bit) perl-RPM-Specfile - 1.51-2.fc7.noarch requires perl(YAML) php-pgsql - 5.2.0-7.ppc64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ppc64 requires libpq.so.4()(64bit) qt-PostgreSQL - 1:3.3.7-1.fc7.ppc64 requires libpq.so.4()(64bit) Broken deps for s390 ---------------------------------------------------------- apr-util - 1.2.7-5.s390 requires libpq.so.4 bind-sdb - 30:9.3.3-6.fc7.s390 requires libpq.so.4 cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.s390 requires libpq.so.4 freeradius-postgresql - 1.1.3-2.s390 requires libpq.so.4 libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390 requires libpq.so.4 mod_auth_pgsql - 2.0.3-2.3.1.s390 requires libpq.so.4 perl-DBD-Pg - 1.49-1.fc6.s390 requires libpq.so.4 perl-RPM-Specfile - 1.51-2.fc7.noarch requires perl(YAML) php-pgsql - 5.2.0-7.s390 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.s390 requires libpq.so.4 qt-PostgreSQL - 1:3.3.7-1.fc7.s390 requires libpq.so.4 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for x86_64 ---------------------------------------------------------- apr-util - 1.2.7-5.x86_64 requires libpq.so.4()(64bit) apr-util - 1.2.7-5.i386 requires libpq.so.4 bind-sdb - 30:9.3.3-6.fc7.x86_64 requires libpq.so.4()(64bit) cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.x86_64 requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.x86_64 requires libpq.so.4()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.x86_64 requires libpq.so.4()(64bit) mod_auth_pgsql - 2.0.3-2.3.1.x86_64 requires libpq.so.4()(64bit) perl-DBD-Pg - 1.49-1.fc6.x86_64 requires libpq.so.4()(64bit) perl-RPM-Specfile - 1.51-2.fc7.noarch requires perl(YAML) php-pgsql - 5.2.0-7.x86_64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.x86_64 requires libpq.so.4()(64bit) qt-PostgreSQL - 1:3.3.7-1.fc7.x86_64 requires libpq.so.4()(64bit) Broken deps for ppc ---------------------------------------------------------- apr-util - 1.2.7-5.ppc requires libpq.so.4 bind-sdb - 30:9.3.3-6.fc7.ppc requires libpq.so.4 cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.ppc requires libpq.so.4 freeradius-postgresql - 1.1.3-2.ppc requires libpq.so.4 libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc requires libpq.so.4 mod_auth_pgsql - 2.0.3-2.3.1.ppc requires libpq.so.4 perl-DBD-Pg - 1.49-1.fc6.ppc requires libpq.so.4 perl-RPM-Specfile - 1.51-2.fc7.noarch requires perl(YAML) php-pgsql - 5.2.0-7.ppc requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.ppc requires libpq.so.4 qt-PostgreSQL - 1:3.3.7-1.fc7.ppc requires libpq.so.4 Broken deps for s390x ---------------------------------------------------------- apr-util - 1.2.7-5.s390x requires libpq.so.4()(64bit) apr-util - 1.2.7-5.s390 requires libpq.so.4 bind-sdb - 30:9.3.3-6.fc7.s390x requires libpq.so.4()(64bit) cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.s390x requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.s390x requires libpq.so.4()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390x requires libpq.so.4()(64bit) mod_auth_pgsql - 2.0.3-2.3.1.s390x requires libpq.so.4()(64bit) perl-DBD-Pg - 1.49-1.fc6.s390x requires libpq.so.4()(64bit) perl-RPM-Specfile - 1.51-2.fc7.noarch requires perl(YAML) php-pgsql - 5.2.0-7.s390x requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.s390x requires libpq.so.4()(64bit) qt-PostgreSQL - 1:3.3.7-1.fc7.s390x requires libpq.so.4()(64bit) From david at lovesunix.net Tue Dec 5 12:27:28 2006 From: david at lovesunix.net (David Nielsen) Date: Tue, 05 Dec 2006 13:27:28 +0100 Subject: CPU Frequency Scaling In-Reply-To: <1165316977.17513.37.camel@cutter> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <1165316977.17513.37.camel@cutter> Message-ID: <1165321648.3116.15.camel@dawkins> tir, 05 12 2006 kl. 06:09 -0500, skrev seth vidal: > On Tue, 2006-12-05 at 12:44 +0100, David Nielsen wrote: > > > Solution, fix gconf rather than complain over davidz and friends at > > least suggesting a forward minded solution to the horror that is "human > > readable" configuration files. > > I've been reading this whole thread and I'm tired of a couple of > semantics being used: > > 1. the assumption that all new development is 'progressive' or > 'visionary'. Forward motion isn't always positive. So let's cut the spin > and just call it what it is - a new interface. > > 2. That anyone promoting sticking with the status-quo is somehow > backward. This also assumes that there are no problems with the current scheme though. By moving to a configuration storage scheme like gconf we get the option of having all key explanations be translated and having one common format and syntax, I think those two factors alone make it worth considering seriously. It seems to me that people are not looking at the full picture here, there are people in the world for whom this would be godsend, not just desktop users but admins - that is aside all the nice things that this will enable us to do according to davidz. It will enable us to give the users greater understanding of settings and a greater ease in tinkering with them, largely thanks to having one uniform interface, with comprehensive comments and explanations in their language. - David Nielsen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From mitr at volny.cz Tue Dec 5 11:34:33 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Tue, 05 Dec 2006 12:34:33 +0100 Subject: CPU Frequency Scaling In-Reply-To: <1165321648.3116.15.camel@dawkins> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <1165316977.17513.37.camel@cutter> <1165321648.3116.15.camel@dawkins> Message-ID: <45755949.9080505@volny.cz> David Nielsen napsal(a): > This also assumes that there are no problems with the current scheme > though. By moving to a configuration storage scheme like gconf we get > the option of having all key explanations be translated and having one > common format and syntax, I think those two factors alone make it worth > considering seriously. OTOH the key explanations are moved away from the options they describe, making them, again, harder to use without a specialized tool. It would be possible to write a tool that dumps a GConf subtree along with the comments to an ini-like file and accepts a modified file as a source of data to store back to GConf, but try storing that in a versioning system. Mirek From k.georgiou at imperial.ac.uk Tue Dec 5 11:43:10 2006 From: k.georgiou at imperial.ac.uk (Kostas Georgiou) Date: Tue, 5 Dec 2006 11:43:10 +0000 Subject: CPU Frequency Scaling In-Reply-To: <20061204204340.GB2427@nostromo.devel.redhat.com> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> Message-ID: <20061205114310.GA21691@imperial.ac.uk> On Mon, Dec 04, 2006 at 03:43:40PM -0500, Bill Nottingham wrote: > Matthew Miller (mattdm at mattdm.org) said: > > I'm just not convinced that not being able to ssh in to a server and edit > > some config files but rather have to figure out how to tweak the > > policy-daemon-of-the-month is the user experience a large segment of "we" > > wants at all. Human-editable config files are a huge strength. Using a > > policy daemon may be part of the answer, but it should be able to get its > > configuration from something that can be fixed with vi. > > So, the entire thing boils down to "I don't like the g-conf storage > format?" (I'm honestly asking here.) It is also that some of the sysadmins (including me) are scared with the direction that the distribution seems to be taking. Some new tools seem to focus mainly on user functionality (which isn't a bad thing) and ignore the sysadmin side (which is bad). To us adding adding new tools that are less easy to script or manage with something like cfengine/puppet/etc is a huge step backwards, we don't care if users can now have a desktop applet so they can supend/hibernate the machine, we don't want them to be able to do that anyway. Kostas From nicolas.mailhot at laposte.net Tue Dec 5 11:45:11 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 5 Dec 2006 12:45:11 +0100 (CET) Subject: CPU Frequency Scaling In-Reply-To: <45755949.9080505@volny.cz> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <1165316977.17513.37.camel@cutter> <1165321648.3116.15.camel@dawkins> <45755949.9080505@volny.cz> Message-ID: <22443.192.54.193.51.1165319111.squirrel@rousalka.dyndns.org> Le Mar 5 d?cembre 2006 12:34, Miloslav Trmac a ?crit : > OTOH the key explanations are moved away from the options they describe, > making them, again, harder to use without a specialized tool. It would > be possible to write a tool ... You replace one admin indirection hassle with another -- looks zero-win to me. What could be done is to have gconf tools put the explanations as comments next to the corresponding XML elements when then write the XML files (in the system language, fallbacking on english if it's not known) -- Nicolas Mailhot From nicolas.mailhot at laposte.net Tue Dec 5 11:50:40 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 5 Dec 2006 12:50:40 +0100 (CET) Subject: CPU Frequency Scaling In-Reply-To: <1165319059.3089.12.camel@dawkins> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> Message-ID: <44130.192.54.193.51.1165319440.squirrel@rousalka.dyndns.org> Le Mar 5 d?cembre 2006 12:44, David Nielsen a ?crit : > Solution, fix gconf gconf does not need to be "fixed" (well it does but that's not the major problem). What need to be "fixed" are developper assumptions and the way they routinely abuse gconf in admin-unfriendly ways. > rather than complain over davidz and friends app writers are the ones that dump garbage in gconf with little though over how admins will manage it. As long as their app can read it back they consider their job done. That's the same kind of problem as the HIG revolution : 20% tooling, 80% developper evangelization. -- Nicolas Mailhot From dcbw at redhat.com Tue Dec 5 12:28:47 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 05 Dec 2006 07:28:47 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165321648.3116.15.camel@dawkins> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <1165316977.17513.37.camel@cutter> <1165321648.3116.15.camel@dawkins> Message-ID: <1165321728.2751.22.camel@localhost.localdomain> On Tue, 2006-12-05 at 13:27 +0100, David Nielsen wrote: > tir, 05 12 2006 kl. 06:09 -0500, skrev seth vidal: > > On Tue, 2006-12-05 at 12:44 +0100, David Nielsen wrote: > > > > > Solution, fix gconf rather than complain over davidz and friends at > > > least suggesting a forward minded solution to the horror that is "human > > > readable" configuration files. > > > > I've been reading this whole thread and I'm tired of a couple of > > semantics being used: > > > > 1. the assumption that all new development is 'progressive' or > > 'visionary'. Forward motion isn't always positive. So let's cut the spin > > and just call it what it is - a new interface. > > > > 2. That anyone promoting sticking with the status-quo is somehow > > backward. > > This also assumes that there are no problems with the current scheme > though. By moving to a configuration storage scheme like gconf we get > the option of having all key explanations be translated and having one > common format and syntax, I think those two factors alone make it worth > considering seriously. It's also easier to auto-update GConf with new settings. The horror that is autoupdating, say, /etc/pam.conf or httpd.conf. _Every_ distributor gets killed by trying to issue updates that might have to automatically change httpd.conf, even if it's just a few lines, (even Apple!). Human manipulatable != machine maniuplatable Many cases are optimum for human manipulation. I don't think anyone wants /etc/resolv.conf to be in XML somewhere. That said, /etc/resolv.conf will never get split DNS resolution because the config file format _cannot_ change. Hence you need a local caching DNS resolver. But for complex configurations, often-times human-manipulatable config files are _not_ the best solution, especially when you want to auto-update configuration from an RPM, or some other mechanism that may have to take user/site-specific changes into account. It's simply a non-starter to attempt to automatically merge configuration updates into existing config files that that may be different than expected even in a few places. Which leads me to the next point. Most config file formats these days are pretty dumb. They don't have all the information that's needed to (a) verify conf format, (b) change narrowly scoped pieces of configuration, or (c) be editable in something other than English. XML can do all of this, but is much less human-readable in complex form. Red Hat tried to do a grand unified configuration project years ago, with GUI config tools that edited things like /etc/passwd, httpd.conf, /etc/fstab, and many more. I think everyone would agree that having GUI config tools makes Linux more accessible to some portion of the system administration audience, but the horrors uncovered by that project mean that what we've got today really doesn't work for GUI config in most cases. So it's a tradeoff. Do you want to keep all the configuration human manipulatable, and therefore inaccessible to those sysadmins who _don't_ want to edit 10 different config files to get something done, each with their own config file format? Or do you add _some_ measure of machine manipulation ability to the configuration format, at the expense of a slightly harder to understand configuration format for humans? After all, machines are our tools no matter whether we SSH into them to edit the files directly, or whether we deploy updates via RPM or whatever automatically. So perhaps GConf isn't the best solution. But then what? What provides better experience for GUI-based config tools and people who don't want to get that far down and dirty with hand editing files? How _do_ you provide a better way to update little pieces of configuration without the almost-all-or-nothing approach of automatically updating config files today? How many .rpmsave or .rpmnew files do you have lying around? Dan > It seems to me that people are not looking at the full picture here, > there are people in the world for whom this would be godsend, not just > desktop users but admins - that is aside all the nice things that this > will enable us to do according to davidz. It will enable us to give the > users greater understanding of settings and a greater ease in tinkering > with them, largely thanks to having one uniform interface, with > comprehensive comments and explanations in their language. > > - David Nielsen > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From skvidal at linux.duke.edu Tue Dec 5 12:33:24 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 05 Dec 2006 07:33:24 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165321728.2751.22.camel@localhost.localdomain> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <1165316977.17513.37.camel@cutter> <1165321648.3116.15.camel@dawkins> <1165321728.2751.22.camel@localhost.localdomain> Message-ID: <1165322004.17513.41.camel@cutter> On Tue, 2006-12-05 at 07:28 -0500, Dan Williams wrote: > On Tue, 2006-12-05 at 13:27 +0100, David Nielsen wrote: > > tir, 05 12 2006 kl. 06:09 -0500, skrev seth vidal: > > > On Tue, 2006-12-05 at 12:44 +0100, David Nielsen wrote: > > > > > > > Solution, fix gconf rather than complain over davidz and friends at > > > > least suggesting a forward minded solution to the horror that is "human > > > > readable" configuration files. > > > > > > I've been reading this whole thread and I'm tired of a couple of > > > semantics being used: > > > > > > 1. the assumption that all new development is 'progressive' or > > > 'visionary'. Forward motion isn't always positive. So let's cut the spin > > > and just call it what it is - a new interface. > > > > > > 2. That anyone promoting sticking with the status-quo is somehow > > > backward. > > > > This also assumes that there are no problems with the current scheme > > though. By moving to a configuration storage scheme like gconf we get > > the option of having all key explanations be translated and having one > > common format and syntax, I think those two factors alone make it worth > > considering seriously. > > It's also easier to auto-update GConf with new settings. The horror > that is autoupdating, say, /etc/pam.conf or httpd.conf. _Every_ > distributor gets killed by trying to issue updates that might have to > automatically change httpd.conf, even if it's just a few lines, (even > Apple!). > > Human manipulatable != machine maniuplatable > > Many cases are optimum for human manipulation. I don't think anyone > wants /etc/resolv.conf to be in XML somewhere. That > said, /etc/resolv.conf will never get split DNS resolution because the > config file format _cannot_ change. Hence you need a local caching DNS > resolver. But for complex configurations, often-times > human-manipulatable config files are _not_ the best solution, especially > when you want to auto-update configuration from an RPM, or some other > mechanism that may have to take user/site-specific changes into account. > It's simply a non-starter to attempt to automatically merge > configuration updates into existing config files that that may be > different than expected even in a few places. > > Which leads me to the next point. Most config file formats these days > are pretty dumb. They don't have all the information that's needed to > (a) verify conf format, (b) change narrowly scoped pieces of > configuration, or (c) be editable in something other than English. XML > can do all of this, but is much less human-readable in complex form. > > Red Hat tried to do a grand unified configuration project years ago, > with GUI config tools that edited things like /etc/passwd, > httpd.conf, /etc/fstab, and many more. I think everyone would agree > that having GUI config tools makes Linux more accessible to some portion > of the system administration audience, but the horrors uncovered by that > project mean that what we've got today really doesn't work for GUI > config in most cases. > > So it's a tradeoff. Do you want to keep all the configuration human > manipulatable, and therefore inaccessible to those sysadmins who _don't_ > want to edit 10 different config files to get something done, each with > their own config file format? Or do you add _some_ measure of machine > manipulation ability to the configuration format, at the expense of a > slightly harder to understand configuration format for humans? After > all, machines are our tools no matter whether we SSH into them to edit > the files directly, or whether we deploy updates via RPM or whatever > automatically. > > So perhaps GConf isn't the best solution. But then what? What provides > better experience for GUI-based config tools and people who don't want > to get that far down and dirty with hand editing files? How _do_ you > provide a better way to update little pieces of configuration without > the almost-all-or-nothing approach of automatically updating config > files today? How many .rpmsave or .rpmnew files do you have lying > around? > You don't. You work around that problem and, fortunately, we already know how to do that. As opposed to the gconf-mechanism where we will have to learn a whole new way to do it, unless of course, there is no option to learn b/c it just isn't possible to automatically correct it. Try fixing evolution settings that used to be in gconf using gconftool. Not a fun option. That's the point - we keep trotting out new mechanisms that claim to make sysadmin life easier/better/something but seem to have few ACTUAL sysadmins who would back up that claim. Seriously, who are you deriving these claims about sysadmins from? Clearly not actual linux sysadmins. -sv From davej at redhat.com Tue Dec 5 12:38:01 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 5 Dec 2006 07:38:01 -0500 Subject: rawhide report: 20061205 changes In-Reply-To: <200612051127.kB5BR9kC025254@hs20-bc2-6.build.redhat.com> References: <200612051127.kB5BR9kC025254@hs20-bc2-6.build.redhat.com> Message-ID: <20061205123801.GB20160@redhat.com> On Tue, Dec 05, 2006 at 06:27:09AM -0500, buildsys at redhat.com wrote: > kernel-2.6.19-1.2844.fc7 > ------------------------ > * Mon Dec 04 2006 Dave Jones > - 2.6.19-git5 > > * Wed Nov 29 2006 Dave Jones > - 2.6.19 > > * Mon Nov 27 2006 Dave Jones > - 2.6.19-rc6-git10 This is totally busted, and will create initrd's with missing modules due to broken dependancies. Avoid. Dave From fedora at camperquake.de Tue Dec 5 13:24:26 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 5 Dec 2006 14:24:26 +0100 Subject: Xen under vmware In-Reply-To: <80d7e4090612041208q21e3a388wfa741f4ee7390827@mail.gmail.com> References: <20061204170031.357d7e9a@banea.int.addix.net> <80d7e4090612041208q21e3a388wfa741f4ee7390827@mail.gmail.com> Message-ID: <20061205142426.75b044f3@banea.int.addix.net> Hi. On Mon, 4 Dec 2006 13:08:42 -0700, Stephen John Smoogen wrote: > I would expect so. I don't think they it is on purpose, but they are > pretty much orthoganal in what they expect the kernel does for > networking and such. I am not sure how a Xen-enabled kernel in a vmware guest cares what the kernel on the vmware host does with it's network, but somewhere packets get dropped. The "naked" xen kernel in the guest (without xend started) can network just fine. With xend started (network-bridge) I see ARP requests leaving the guest, arriving on the host and ARP replies leaving the host. But those never make it to the guest. Strange world. Well, I'll have to conduct my xen testing somewhere else, it seems. From andy at warmcat.com Tue Dec 5 13:27:22 2006 From: andy at warmcat.com (Andy Green) Date: Tue, 05 Dec 2006 13:27:22 +0000 Subject: Xen under vmware In-Reply-To: <20061205142426.75b044f3@banea.int.addix.net> References: <20061204170031.357d7e9a@banea.int.addix.net> <80d7e4090612041208q21e3a388wfa741f4ee7390827@mail.gmail.com> <20061205142426.75b044f3@banea.int.addix.net> Message-ID: <457573BA.1000107@warmcat.com> Ralf Ertzinger wrote: > I am not sure how a Xen-enabled kernel in a vmware guest cares what > the kernel on the vmware host does with it's network, but somewhere > packets get dropped. > > The "naked" xen kernel in the guest (without xend started) can network > just fine. With xend started (network-bridge) I see ARP requests leaving > the guest, arriving on the host and ARP replies leaving the host. > But those never make it to the guest. vmware behaves the same if you merely have a wireless network on the host, it's not a Xen thing. On my box with XP in vmware on top of FC6 I see this in dmesg (on recent vmware versions, there used to be no sign of why ARPs didn't get forwarded) vmnet: You are trying to use wireless bridged networking together with vmnet: vmware-any-any-update. This is not supported configuration, and vmnet: your wireless bridge will probably not work. -Andy From nicolas.mailhot at laposte.net Tue Dec 5 13:29:04 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 5 Dec 2006 14:29:04 +0100 (CET) Subject: CPU Frequency Scaling In-Reply-To: <1165321728.2751.22.camel@localhost.localdomain> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <1165316977.17513.37.camel@cutter> <1165321648.3116.15.camel@dawkins> <1165321728.2751.22.camel@localhost.localdomain> Message-ID: <15946.192.54.193.51.1165325344.squirrel@rousalka.dyndns.org> Le Mar 5 d?cembre 2006 13:28, Dan Williams a ?crit : > Human manipulatable != machine maniuplatable It seems to me the great failure of gconf users was to make this asumption, and consider that since the settings were available through gconf-editor there was no reason to clean-up/prettify the XML representation. Just as sysadmins need to accept some structure in config files is required to ease machine manipulation, developpers need to accept indentation, comments, careful design are required to ease human manipulation. There is no inherent reason elements in XML files can not be properly indented, commented and ordered so diff/patch and manual editing works (even if xslt + xsltproc should eventually superceded diff/patch for XML files). It will cost design time, it will cost processing time, but it's doable. All the recent profiling ops show massive over-reading and polling of conf files by GNOME apps. Did we really mess up the config storage layer only to help applications writers abuse it in every possible way? > Red Hat tried to do a grand unified configuration project years ago, > with GUI config tools that edited things like /etc/passwd, > httpd.conf, /etc/fstab, and many more. I think everyone would agree > that having GUI config tools makes Linux more accessible to some portion > of the system administration audience, but the horrors uncovered by that > project mean that what we've got today really doesn't work for GUI > config in most cases. The main mistake of this project IMHO was to separate machine-manipulable and human-manipulable versions of the same data, with the two versions fighting each other constantly. Ironically what is being proposed today is similar. The only difference being the authoritative version is the machine-manipulable one this time. It will fail the same way for the same reasons. To avoid sysadmin and application disconnect both apps and sysadmins need direct raw access to the same config data (ie no layer of templating indirection for conf apps like in the old RedHat projet, and no layer of gconf tools/scripts indirection for sysadmins like in the current one). That means the low-level format of config files must be adequate for apps and sysadmins, not one or the other like has been done so far. -- Nicolas Mailhot From mclasen at redhat.com Tue Dec 5 13:34:31 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 05 Dec 2006 08:34:31 -0500 Subject: CPU Frequency Scaling In-Reply-To: <15946.192.54.193.51.1165325344.squirrel@rousalka.dyndns.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <1165316977.17513.37.camel@cutter> <1165321648.3116.15.camel@dawkins> <1165321728.2751.22.camel@localhost.localdomain> <15946.192.54.193.51.1165325344.squirrel@rousalka.dyndns.org> Message-ID: <1165325671.9398.4.camel@golem.boston.devel.redhat.com> On Tue, 2006-12-05 at 14:29 +0100, Nicolas Mailhot wrote: > Le Mar 5 d?cembre 2006 13:28, Dan Williams a ?crit : > > > Human manipulatable != machine maniuplatable > > It seems to me the great failure of gconf users was to make this > asumption, and consider that since the settings were available through > gconf-editor there was no reason to clean-up/prettify the XML > representation. > > Just as sysadmins need to accept some structure in config files is > required to ease machine manipulation, developpers need to accept > indentation, comments, careful design are required to ease human > manipulation. > > There is no inherent reason elements in XML files can not be properly > indented, commented and ordered so diff/patch and manual editing works > (even if xslt + xsltproc should eventually superceded diff/patch for XML > files). It will cost design time, it will cost processing time, but it's > doable. > > All the recent profiling ops show massive over-reading and polling of conf > files by GNOME apps. Did we really mess up the config storage layer only > to help applications writers abuse it in every possible way? ARe you just making belligerent comments, or do you have any proof for this "recent profiling" ? From markmc at redhat.com Tue Dec 5 13:39:42 2006 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 05 Dec 2006 13:39:42 +0000 Subject: CPU Frequency Scaling In-Reply-To: <1165325671.9398.4.camel@golem.boston.devel.redhat.com> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <1165316977.17513.37.camel@cutter> <1165321648.3116.15.camel@dawkins> <1165321728.2751.22.camel@localhost.localdomain> <15946.192.54.193.51.1165325344.squirrel@rousalka.dyndns.org> <1165325671.9398.4.camel@golem.boston.devel.redhat.com> Message-ID: <1165325982.3096.34.camel@blaa> On Tue, 2006-12-05 at 08:34 -0500, Matthias Clasen wrote: > On Tue, 2006-12-05 at 14:29 +0100, Nicolas Mailhot wrote: > > Just as sysadmins need to accept some structure in config files is > > required to ease machine manipulation, developpers need to accept > > indentation, comments, careful design are required to ease human > > manipulation. > > > > There is no inherent reason elements in XML files can not be properly > > indented, commented and ordered so diff/patch and manual editing works Take a look at the how the XML files are saved these days (they're indented) and also take a look at gconftool-2 --load and --dump for "patching". Cheers, Mark. From mclasen at redhat.com Tue Dec 5 13:48:11 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 05 Dec 2006 08:48:11 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165325982.3096.34.camel@blaa> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <1165316977.17513.37.camel@cutter> <1165321648.3116.15.camel@dawkins> <1165321728.2751.22.camel@localhost.localdomain> <15946.192.54.193.51.1165325344.squirrel@rousalka.dyndns.org> <1165325671.9398.4.camel@golem.boston.devel.redhat.com> <1165325982.3096.34.camel@blaa> Message-ID: <1165326491.9398.10.camel@golem.boston.devel.redhat.com> Careful with your quoting. I didn't write that. > On Tue, 2006-12-05 at 08:34 -0500, Matthias Clasen wrote: > > On Tue, 2006-12-05 at 14:29 +0100, Nicolas Mailhot wrote: > > > > Just as sysadmins need to accept some structure in config files is > > > required to ease machine manipulation, developpers need to accept > > > indentation, comments, careful design are required to ease human > > > manipulation. > > > > > > There is no inherent reason elements in XML files can not be properly > > > indented, commented and ordered so diff/patch and manual editing works > > Take a look at the how the XML files are saved these days (they're > indented) and also take a look at gconftool-2 --load and --dump for > "patching". > > Cheers, > Mark. > From mattdm at mattdm.org Tue Dec 5 14:12:09 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 5 Dec 2006 09:12:09 -0500 Subject: CPU Frequency Scaling In-Reply-To: <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> Message-ID: <20061205141209.GA32538@jadzia.bu.edu> On Tue, Dec 05, 2006 at 10:21:48AM +0100, Nicolas Mailhot wrote: > Developpers want a system that can re-read conf files at blazing speed (so > their app can read 20 times the same setting without impacting > performance), with low change impedance (so they can stuff last-minute > settings there or even change the format from version to version), and no > hard documentation requirements (yay for burying configuration access in > gconf-editor). They don't care if settings are not accessible without > writing dedicated tools/scripts because writing code is what they do for a > living. In other words, the old cliche about developers making poor designers. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nicolas.mailhot at laposte.net Tue Dec 5 15:29:50 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 5 Dec 2006 16:29:50 +0100 (CET) Subject: CPU Frequency Scaling In-Reply-To: <1165325982.3096.34.camel@blaa> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <1165316977.17513.37.camel@cutter> <1165321648.3116.15.camel@dawkins> <1165321728.2751.22.camel@localhost.localdomain> <15946.192.54.193.51.1165325344.squirrel@rousalka.dyndns.org> <1165325671.9398.4.camel@golem.boston.devel.redhat.com> <1165325982.3096.34.camel@blaa> Message-ID: <8724.192.54.193.51.1165332590.squirrel@rousalka.dyndns.org> Le Mar 5 d?cembre 2006 14:39, Mark McLoughlin a ?crit : > Take a look at the how the XML files are saved these days (they're > indented) Good, the situation is slowly improving then. Can the gconf files acquire comments too now pretty please? (just write the stuff gconf-editor shows as XML comments next to the relevant XML elements on file writing) Now I think I've looked at the rawhide gconf evo files in the last two months, and they were the mess I remembered, so the situation is not quite fixed yet (and evolution crashes often enough I suspect many people have looked there and used it as their standard to evaluate gconf. Unfair I know) Regards, -- Nicolas Mailhot From selinux at gmail.com Tue Dec 5 15:33:12 2006 From: selinux at gmail.com (Tom London) Date: Tue, 5 Dec 2006 07:33:12 -0800 Subject: rawhide report: 20061205 changes In-Reply-To: <200612051127.kB5BR9kC025254@hs20-bc2-6.build.redhat.com> References: <200612051127.kB5BR9kC025254@hs20-bc2-6.build.redhat.com> Message-ID: <4c4ba1530612050733k7dc24adct7599fbf211fe1b88@mail.gmail.com> With these updates, running compiz w/i810, I get thick black lines around each of my windows, and slowly vanishing panel, etc. Turning off desktop effects restores windows and panel. Any thoughts? From nicolas.mailhot at laposte.net Tue Dec 5 15:33:44 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 5 Dec 2006 16:33:44 +0100 (CET) Subject: CPU Frequency Scaling In-Reply-To: <20061205141209.GA32538@jadzia.bu.edu> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <20061205141209.GA32538@jadzia.bu.edu> Message-ID: <24064.192.54.193.51.1165332824.squirrel@rousalka.dyndns.org> Le Mar 5 d?cembre 2006 15:12, Matthew Miller a ?crit : > In other words, the old cliche about developers making poor designers. I wasn't the one who just wrote sysadmins could just use dedicated tools/scripts to access configuration files :) I may have repeated clich?s, but so did most posters in this thread, even if they were not aware of it. -- Nicolas Mailhot From ajackson at redhat.com Tue Dec 5 15:31:26 2006 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 05 Dec 2006 10:31:26 -0500 Subject: rawhide report: 20061205 changes In-Reply-To: <4c4ba1530612050733k7dc24adct7599fbf211fe1b88@mail.gmail.com> References: <200612051127.kB5BR9kC025254@hs20-bc2-6.build.redhat.com> <4c4ba1530612050733k7dc24adct7599fbf211fe1b88@mail.gmail.com> Message-ID: <1165332686.7683.163.camel@localhost.localdomain> On Tue, 2006-12-05 at 07:33 -0800, Tom London wrote: > With these updates, running compiz w/i810, I get thick black lines > around each of my windows, and slowly vanishing panel, etc. > > Turning off desktop effects restores windows and panel. > > Any thoughts? I blame Mesa. Does the previous Mesa package still work for you? - ajax From selinux at gmail.com Tue Dec 5 15:45:26 2006 From: selinux at gmail.com (Tom London) Date: Tue, 5 Dec 2006 07:45:26 -0800 Subject: rawhide report: 20061205 changes In-Reply-To: <1165332686.7683.163.camel@localhost.localdomain> References: <200612051127.kB5BR9kC025254@hs20-bc2-6.build.redhat.com> <4c4ba1530612050733k7dc24adct7599fbf211fe1b88@mail.gmail.com> <1165332686.7683.163.camel@localhost.localdomain> Message-ID: <4c4ba1530612050745k2c0b1a15hd7aa89294c7d6d35@mail.gmail.com> On 12/5/06, Adam Jackson wrote: > On Tue, 2006-12-05 at 07:33 -0800, Tom London wrote: > > With these updates, running compiz w/i810, I get thick black lines > > around each of my windows, and slowly vanishing panel, etc. > > > > Turning off desktop effects restores windows and panel. > > > > Any thoughts? > > I blame Mesa. Does the previous Mesa package still work for you? > > - ajax > Yeah. Thanks. Reverting to previous mesa packages fixes: mesa-libGL-6.5.1-8.fc6 mesa-libGLU-devel-6.5.1-8.fc6 mesa-libGL-devel-6.5.1-8.fc6 mesa-libGLU-6.5.1-8.fc6 tom -- Tom London From mattdm at mattdm.org Tue Dec 5 15:46:42 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 5 Dec 2006 10:46:42 -0500 Subject: CPU Frequency Scaling In-Reply-To: <24064.192.54.193.51.1165332824.squirrel@rousalka.dyndns.org> References: <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <20061205141209.GA32538@jadzia.bu.edu> <24064.192.54.193.51.1165332824.squirrel@rousalka.dyndns.org> Message-ID: <20061205154642.GA4179@jadzia.bu.edu> On Tue, Dec 05, 2006 at 04:33:44PM +0100, Nicolas Mailhot wrote: > > In other words, the old cliche about developers making poor designers. > I wasn't the one who just wrote sysadmins could just use dedicated > tools/scripts to access configuration files :) I may have repeated > clich?s, but so did most posters in this thread, even if they were not > aware of it. Oh, that doesn't make it untrue by a long shot. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ajackson at redhat.com Tue Dec 5 16:11:40 2006 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 05 Dec 2006 11:11:40 -0500 Subject: rawhide report: 20061205 changes In-Reply-To: <4c4ba1530612050745k2c0b1a15hd7aa89294c7d6d35@mail.gmail.com> References: <200612051127.kB5BR9kC025254@hs20-bc2-6.build.redhat.com> <4c4ba1530612050733k7dc24adct7599fbf211fe1b88@mail.gmail.com> <1165332686.7683.163.camel@localhost.localdomain> <4c4ba1530612050745k2c0b1a15hd7aa89294c7d6d35@mail.gmail.com> Message-ID: <1165335100.7683.169.camel@localhost.localdomain> On Tue, 2006-12-05 at 07:45 -0800, Tom London wrote: > On 12/5/06, Adam Jackson wrote: > > On Tue, 2006-12-05 at 07:33 -0800, Tom London wrote: > > > With these updates, running compiz w/i810, I get thick black lines > > > around each of my windows, and slowly vanishing panel, etc. > > > > > > Turning off desktop effects restores windows and panel. > > > > > > Any thoughts? > > > > I blame Mesa. Does the previous Mesa package still work for you? > > > > - ajax > > > Yeah. Thanks. > > Reverting to previous mesa packages fixes: > > mesa-libGL-6.5.1-8.fc6 > mesa-libGLU-devel-6.5.1-8.fc6 > mesa-libGL-devel-6.5.1-8.fc6 > mesa-libGLU-6.5.1-8.fc6 Fascinating. Might need a 2D driver update too, to enable the new memory manager. What hardware is this with? - ajax From selinux at gmail.com Tue Dec 5 16:19:54 2006 From: selinux at gmail.com (Tom London) Date: Tue, 5 Dec 2006 08:19:54 -0800 Subject: rawhide report: 20061205 changes In-Reply-To: <1165335100.7683.169.camel@localhost.localdomain> References: <200612051127.kB5BR9kC025254@hs20-bc2-6.build.redhat.com> <4c4ba1530612050733k7dc24adct7599fbf211fe1b88@mail.gmail.com> <1165332686.7683.163.camel@localhost.localdomain> <4c4ba1530612050745k2c0b1a15hd7aa89294c7d6d35@mail.gmail.com> <1165335100.7683.169.camel@localhost.localdomain> Message-ID: <4c4ba1530612050819ideddbb5jbc63702f5caf2300@mail.gmail.com> On 12/5/06, Adam Jackson wrote: > On Tue, 2006-12-05 at 07:45 -0800, Tom London wrote: > > On 12/5/06, Adam Jackson wrote: > > > On Tue, 2006-12-05 at 07:33 -0800, Tom London wrote: > > > > With these updates, running compiz w/i810, I get thick black lines > > > > around each of my windows, and slowly vanishing panel, etc. > > > > > > > > Turning off desktop effects restores windows and panel. > > > > > > > > Any thoughts? > > > > > > I blame Mesa. Does the previous Mesa package still work for you? > > > > > > - ajax > > > > > Yeah. Thanks. > > > > Reverting to previous mesa packages fixes: > > > > mesa-libGL-6.5.1-8.fc6 > > mesa-libGLU-devel-6.5.1-8.fc6 > > mesa-libGL-devel-6.5.1-8.fc6 > > mesa-libGLU-6.5.1-8.fc6 > > Fascinating. Might need a 2D driver update too, to enable the new > memory manager. What hardware is this with? > > - ajax > Thinkpad X60. Here is output of 'lspci': 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller AHCI (rev 02) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02) 02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) 15:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b4) 15:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 09) 15:00.2 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 18) tom -- Tom London From davej at redhat.com Tue Dec 5 17:04:04 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 5 Dec 2006 12:04:04 -0500 Subject: CPU Frequency Scaling In-Reply-To: <20061204184215.GB31682@nostromo.devel.redhat.com> References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> <1165232586.3147.3.camel@hughsie-laptop> <20061204175805.GA26115@redhat.com> <20061204184215.GB31682@nostromo.devel.redhat.com> Message-ID: <20061205170404.GA4802@redhat.com> On Mon, Dec 04, 2006 at 01:42:15PM -0500, Bill Nottingham wrote: > Dave Jones (davej at redhat.com) said: > > It doesn't strike you that something might be amiss that a 1GHz CPU > > can't display a menu quick enough ? Shuffling the problem under the rug > > isn't the way to fix this. Find out why it's taking so long, and fix that. > > It's scanning the desktop files, almost certainly. If that's the case, it has no excuse for doing so now that we have inotify. It amazes me how much fuss the gnome people made about that feature and how it really absolutely must get into the kernel. It'd be great if stuff actually used it. Dave From mlichvar at redhat.com Tue Dec 5 17:18:18 2006 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Tue, 5 Dec 2006 18:18:18 +0100 Subject: rawhide report: 20061201 changes In-Reply-To: <1165242354.2924.46.camel@kloczek01.pracownicy.zie> References: <200612011054.kB1AsMBf017076@hs20-bc2-6.build.redhat.com> <1164988422.13427.17.camel@kloczek01.pracownicy.zie> <20061204095709.GB28360@localhost> <1165242354.2924.46.camel@kloczek01.pracownicy.zie> Message-ID: <20061205171818.GD2582@localhost> On Mon, Dec 04, 2006 at 03:25:54PM +0100, Tomasz K?oczko wrote: > Dnia 04-12-2006, pon o godzinie 10:57 +0100, Miroslav Lichvar > napisa?(a): > [..] > > > Second: now ncurses package contains shared libncurses and libncursesw. > > > Why not all link all against libncursesw ? It will allow drop libncurses > > > (or move to compat-ncurses). It will allow make main package ~two time > > > smaller. > > > > Some packages don't need the wide-character ncurses, in fact there are > > only 20 packages in FC+FE that depend on the library. But number of > > packages requiring libncurses is about 200. > > Seems you dont' know some fact. Using libncursesw ABI don't mean > "program uses wchar". Ok, then what does it mean? > libncursesw API in most cases can be used as > normal libncurses but have loaded in the same time libncursesw and > libncurses and libtermcap means you are preffer waste more memory then > using for all program single term toolkit library (nevermind which). If you switch everything to libncursesw and start few of these applications, it will waste even more memory as libncursesw uses internally much larger structures. So don't link an application with ncursesw unless it needs it. -- Miroslav Lichvar From mclasen at redhat.com Tue Dec 5 17:43:59 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 05 Dec 2006 12:43:59 -0500 Subject: CPU Frequency Scaling In-Reply-To: <20061205170404.GA4802@redhat.com> References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> <1165232586.3147.3.camel@hughsie-laptop> <20061204175805.GA26115@redhat.com> <20061204184215.GB31682@nostromo.devel.redhat.com> <20061205170404.GA4802@redhat.com> Message-ID: <1165340639.10890.5.camel@golem.boston.devel.redhat.com> On Tue, 2006-12-05 at 12:04 -0500, Dave Jones wrote: > On Mon, Dec 04, 2006 at 01:42:15PM -0500, Bill Nottingham wrote: > > Dave Jones (davej at redhat.com) said: > > > It doesn't strike you that something might be amiss that a 1GHz CPU > > > can't display a menu quick enough ? Shuffling the problem under the rug > > > isn't the way to fix this. Find out why it's taking so long, and fix that. > > > > It's scanning the desktop files, almost certainly. > > If that's the case, it has no excuse for doing so now that we have > inotify. It amazes me how much fuss the gnome people made about that > feature and how it really absolutely must get into the kernel. > > It'd be great if stuff actually used it. gnome-menus uses gamin for notification, which uses inotify. The problem is that inotify sucks when it comes to nonexisting files, and relevant people refuse to fix it, so gamin still needs to poll sometimes. From bdwheele at indiana.edu Tue Dec 5 17:58:03 2006 From: bdwheele at indiana.edu (Brian Wheeler) Date: Tue, 05 Dec 2006 12:58:03 -0500 Subject: bug in makewhatis? Message-ID: <1165341483.2685.18.camel@wombat.dlib.indiana.edu> I've been trying to figure out where apropos/whatis is finding this. -------- [bdwheele at wombat etc]$ whatis fuse Fuse (3pm) - write filesystems in Perl using FUSE fuse (rpm) - File System in Userspace (FUSE) utilities fuse-devel (rpm) - File System in Userspace (FUSE) devel files fuse-libs (rpm) - File System in Userspace (FUSE) libraries fuse-smb (rpm) - FUSE-Filesystem to fast and easy access remote resources via SMB [bdwheele at wombat etc]$ man fuse No manual entry for fuse -------- Where are these 'rpm' section man pages coming from in the makewhatis index? It'd be nice if there was some actual output (like installation time, version, etc) when one did a man on an RPM page... Thanks Brian Wheeler bdwheele at indiana.edu From davej at redhat.com Tue Dec 5 17:59:21 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 5 Dec 2006 12:59:21 -0500 Subject: Maintainance of hwdata In-Reply-To: <1165315979.3233.364.camel@laptopd505.fenrus.org> References: <200612050342.40196.opensource@till.name> <457548C0.5060401@redhat.com> <1165315979.3233.364.camel@laptopd505.fenrus.org> Message-ID: <20061205175921.GB6796@redhat.com> On Tue, Dec 05, 2006 at 11:52:59AM +0100, Arjan van de Ven wrote: > On Tue, 2006-12-05 at 11:24 +0100, Karsten Hopp wrote: > > Till Maas schrieb: > > > Hiyas, > > > > > > new bugs about hwdata are assigned to Karsten Hopp in bugzilla, but according > > > to the changelog of hwdata he never made any change to it, ever. So is this > > > normal for fedora core packages? Or is there maybe some false information > > > about the maintainer of hwdata in Bugzilla because the open bugs seem to get > > > not much attention. > > > > > > Regards, > > > Till > > > > > > > No, the bugzilla information is correct. I just recently got this package from > > Phil, that's why you won't find any changelogs from me yet. > > one thing that would be nice is if the cpu microcode data would actually > move from microcode_ctl to hwdata; the program almost never gets updated > but the microcode file gets updated every few months hwdata is noarch though. Including x86 microcode data on all arches would be a bit crap. Dave From mclasen at redhat.com Tue Dec 5 18:19:55 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 05 Dec 2006 13:19:55 -0500 Subject: bug in makewhatis? In-Reply-To: <1165341483.2685.18.camel@wombat.dlib.indiana.edu> References: <1165341483.2685.18.camel@wombat.dlib.indiana.edu> Message-ID: <1165342796.16839.1.camel@golem.boston.devel.redhat.com> On Tue, 2006-12-05 at 12:58 -0500, Brian Wheeler wrote: > I've been trying to figure out where apropos/whatis is finding this. > > -------- > [bdwheele at wombat etc]$ whatis fuse > Fuse (3pm) - write filesystems in Perl using FUSE > fuse (rpm) - File System in Userspace (FUSE) utilities > fuse-devel (rpm) - File System in Userspace (FUSE) devel files > fuse-libs (rpm) - File System in Userspace (FUSE) libraries > fuse-smb (rpm) - FUSE-Filesystem to fast and easy access > remote resources via SMB > [bdwheele at wombat etc]$ man fuse > No manual entry for fuse > -------- > > Where are these 'rpm' section man pages coming from in the makewhatis > index? It'd be nice if there was some actual output (like installation > time, version, etc) when one did a man on an RPM page... This is a (somewhat silly) patch in our makewhatis that adds the names of all installed rpms to the database... From cmadams at hiwaay.net Tue Dec 5 18:18:24 2006 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 5 Dec 2006 12:18:24 -0600 Subject: bug in makewhatis? In-Reply-To: <1165342796.16839.1.camel@golem.boston.devel.redhat.com> References: <1165341483.2685.18.camel@wombat.dlib.indiana.edu> <1165342796.16839.1.camel@golem.boston.devel.redhat.com> Message-ID: <20061205181823.GA1028220@hiwaay.net> Once upon a time, Matthias Clasen said: > This is a (somewhat silly) patch in our makewhatis that adds the names > of all installed rpms to the database... How about a corresponding patch to man to maybe do the equivalent of "rpm -i"? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From bdwheele at indiana.edu Tue Dec 5 18:20:05 2006 From: bdwheele at indiana.edu (Brian Wheeler) Date: Tue, 05 Dec 2006 13:20:05 -0500 Subject: bug in makewhatis? In-Reply-To: <1165342796.16839.1.camel@golem.boston.devel.redhat.com> References: <1165341483.2685.18.camel@wombat.dlib.indiana.edu> <1165342796.16839.1.camel@golem.boston.devel.redhat.com> Message-ID: <1165342805.2685.26.camel@wombat.dlib.indiana.edu> On Tue, 2006-12-05 at 13:19 -0500, Matthias Clasen wrote: > On Tue, 2006-12-05 at 12:58 -0500, Brian Wheeler wrote: > > I've been trying to figure out where apropos/whatis is finding this. > > > > -------- > > [bdwheele at wombat etc]$ whatis fuse > > Fuse (3pm) - write filesystems in Perl using FUSE > > fuse (rpm) - File System in Userspace (FUSE) utilities > > fuse-devel (rpm) - File System in Userspace (FUSE) devel files > > fuse-libs (rpm) - File System in Userspace (FUSE) libraries > > fuse-smb (rpm) - FUSE-Filesystem to fast and easy access > > remote resources via SMB > > [bdwheele at wombat etc]$ man fuse > > No manual entry for fuse > > -------- > > > > Where are these 'rpm' section man pages coming from in the makewhatis > > index? It'd be nice if there was some actual output (like installation > > time, version, etc) when one did a man on an RPM page... > > This is a (somewhat silly) patch in our makewhatis that adds the names > of all installed rpms to the database... > Its actually helpful -- I've used it to discover packages I didn't know about, but it is a bit confusing, since the man page comes up empty. Brian From florin at andrei.myip.org Tue Dec 5 17:41:54 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 05 Dec 2006 09:41:54 -0800 Subject: CPU Frequency Scaling In-Reply-To: References: <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <1165253479.2484.44.camel@zelda.fubar.dk> <20061204181217.GA33394@dspnet.fr.eu.org> <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> <1165260725.2484.110.camel@zelda.fubar.dk> <20061204193858.GA18344@jadzia.bu.edu> <1165262519.2484.133.camel@zelda.fubar.dk> Message-ID: <4575AF62.8070201@andrei.myip.org> Thomas M Steenholdt wrote: > 2) If you want/need to take advantage of a new feature, you'll have to > wait for development of the feature you need in the daemon AND in the > config-tool. Development of the config tools can be ignored or postponed > if the config files are human editable files. Theoretically speaking, if the daemons could advertise their features to the config tool via an agreed upon protocol, then this would not be a problem. -- Florin Andrei http://florin.myip.org/ From nutello at sweetness.com Tue Dec 5 18:35:19 2006 From: nutello at sweetness.com (Rudi Chiarito) Date: Tue, 5 Dec 2006 19:35:19 +0100 Subject: CPU Frequency Scaling In-Reply-To: <4575AF62.8070201@andrei.myip.org> References: <1165257276.2484.61.camel@zelda.fubar.dk> <20061204185628.GB15568@jadzia.bu.edu> <1165259825.2484.93.camel@zelda.fubar.dk> <20061204192336.GA17780@jadzia.bu.edu> <1165260645.2484.108.camel@zelda.fubar.dk> <1165260725.2484.110.camel@zelda.fubar.dk> <20061204193858.GA18344@jadzia.bu.edu> <1165262519.2484.133.camel@zelda.fubar.dk> <4575AF62.8070201@andrei.myip.org> Message-ID: <20061205183519.GB24970@plain.rackshack.net> On Tue, Dec 05, 2006 at 09:41:54AM -0800, Florin Andrei wrote: > Theoretically speaking, if the daemons could advertise their features to > the config tool via an agreed upon protocol, then this would not be a > problem. The problem with that is that automatically generated user interfaces tend to suck. A lot. -- Rudi From florin at andrei.myip.org Tue Dec 5 17:47:41 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 05 Dec 2006 09:47:41 -0800 Subject: CPU Frequency Scaling In-Reply-To: <1165321728.2751.22.camel@localhost.localdomain> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <1165316977.17513.37.camel@cutter> <1165321648.3116.15.camel@dawkins> <1165321728.2751.22.camel@localhost.localdomain> Message-ID: <4575B0BD.4030900@andrei.myip.org> Dan Williams wrote: > It's also easier to auto-update GConf with new settings. The horror > that is autoupdating, say, /etc/pam.conf or httpd.conf. _Every_ > distributor gets killed by trying to issue updates that might have to > automatically change httpd.conf, even if it's just a few lines, (even > Apple!). This is a very strong argument and it shows one of the biggest weaknesses of the classic "edit by vi" model. disclaimer: I'm a sysadmin ;-) -- Florin Andrei http://florin.myip.org/ From davej at redhat.com Tue Dec 5 19:02:45 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 5 Dec 2006 14:02:45 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165340639.10890.5.camel@golem.boston.devel.redhat.com> References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> <1165232586.3147.3.camel@hughsie-laptop> <20061204175805.GA26115@redhat.com> <20061204184215.GB31682@nostromo.devel.redhat.com> <20061205170404.GA4802@redhat.com> <1165340639.10890.5.camel@golem.boston.devel.redhat.com> Message-ID: <20061205190245.GG6796@redhat.com> On Tue, Dec 05, 2006 at 12:43:59PM -0500, Matthias Clasen wrote: > On Tue, 2006-12-05 at 12:04 -0500, Dave Jones wrote: > > On Mon, Dec 04, 2006 at 01:42:15PM -0500, Bill Nottingham wrote: > > > Dave Jones (davej at redhat.com) said: > > > > It doesn't strike you that something might be amiss that a 1GHz CPU > > > > can't display a menu quick enough ? Shuffling the problem under the rug > > > > isn't the way to fix this. Find out why it's taking so long, and fix that. > > > > > > It's scanning the desktop files, almost certainly. > > > > If that's the case, it has no excuse for doing so now that we have > > inotify. It amazes me how much fuss the gnome people made about that > > feature and how it really absolutely must get into the kernel. > > > > It'd be great if stuff actually used it. > > gnome-menus uses gamin for notification, which uses inotify. The problem > is that inotify sucks when it comes to nonexisting files Can't you add a watch on the directory, and get notification when a file gets added that way? Dave From mitr at volny.cz Tue Dec 5 19:03:37 2006 From: mitr at volny.cz (Miloslav Trmac) Date: Tue, 05 Dec 2006 20:03:37 +0100 Subject: CPU Frequency Scaling In-Reply-To: <4575B0BD.4030900@andrei.myip.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <1165316977.17513.37.camel@cutter> <1165321648.3116.15.camel@dawkins> <1165321728.2751.22.camel@localhost.localdomain> <4575B0BD.4030900@andrei.myip.org> Message-ID: <4575C289.7010209@volny.cz> Florin Andrei napsal(a): > Dan Williams wrote: >> It's also easier to auto-update GConf with new settings. The horror >> that is autoupdating, say, /etc/pam.conf or httpd.conf. _Every_ >> distributor gets killed by trying to issue updates that might have to >> automatically change httpd.conf, even if it's just a few lines, (even >> Apple!). > This is a very strong argument and it shows one of the biggest > weaknesses of the classic "edit by vi" model. Not really. It is not that much harder to write the equivalent code without GConf. To support upgrades, the application must 1) be able to read the settings in the original format 2) convert them to the new format 3) write them back in the new format. 2) doesn't depend on GConf availability. GConf helps with 1) and 3). Applications not GConf obviously already have 1). So the only difference is writing code that can write the current configuration as a configuration file (losing all comments in the process, exactly like GConf-using applications would). Writing this code should really not be _that_ difficult. When httpd changed the config format incompatibly and the httpd developers didn't write a config format converter, and when GNOME applications changed the used GConf schema and their developers did write a config format converter, the difference is mainly caused by the developer's decision, not by usage of GConf. Mirek From mclasen at redhat.com Tue Dec 5 19:08:22 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 05 Dec 2006 14:08:22 -0500 Subject: CPU Frequency Scaling In-Reply-To: <20061205190245.GG6796@redhat.com> References: <1165115008.2314.22.camel@averatec.charles.net> <1165158517.4001.4.camel@hughsie-laptop> <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> <1165232586.3147.3.camel@hughsie-laptop> <20061204175805.GA26115@redhat.com> <20061204184215.GB31682@nostromo.devel.redhat.com> <20061205170404.GA4802@redhat.com> <1165340639.10890.5.camel@golem.boston.devel.redhat.com> <20061205190245.GG6796@redhat.com> Message-ID: <1165345702.16839.3.camel@golem.boston.devel.redhat.com> On Tue, 2006-12-05 at 14:02 -0500, Dave Jones wrote: > On Tue, Dec 05, 2006 at 12:43:59PM -0500, Matthias Clasen wrote: > > On Tue, 2006-12-05 at 12:04 -0500, Dave Jones wrote: > > > On Mon, Dec 04, 2006 at 01:42:15PM -0500, Bill Nottingham wrote: > > > > Dave Jones (davej at redhat.com) said: > > > > > It doesn't strike you that something might be amiss that a 1GHz CPU > > > > > can't display a menu quick enough ? Shuffling the problem under the rug > > > > > isn't the way to fix this. Find out why it's taking so long, and fix that. > > > > > > > > It's scanning the desktop files, almost certainly. > > > > > > If that's the case, it has no excuse for doing so now that we have > > > inotify. It amazes me how much fuss the gnome people made about that > > > feature and how it really absolutely must get into the kernel. > > > > > > It'd be great if stuff actually used it. > > > > gnome-menus uses gamin for notification, which uses inotify. The problem > > is that inotify sucks when it comes to nonexisting files > > Can't you add a watch on the directory, and get notification when > a file gets added that way? > Sure. But if that directory is a busy one like, say, $HOME, then you get a lot of unnecessary wakeups. From mattdm at mattdm.org Tue Dec 5 19:10:40 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 5 Dec 2006 14:10:40 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165345702.16839.3.camel@golem.boston.devel.redhat.com> References: <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> <1165232586.3147.3.camel@hughsie-laptop> <20061204175805.GA26115@redhat.com> <20061204184215.GB31682@nostromo.devel.redhat.com> <20061205170404.GA4802@redhat.com> <1165340639.10890.5.camel@golem.boston.devel.redhat.com> <20061205190245.GG6796@redhat.com> <1165345702.16839.3.camel@golem.boston.devel.redhat.com> Message-ID: <20061205191040.GA21315@jadzia.bu.edu> On Tue, Dec 05, 2006 at 02:08:22PM -0500, Matthias Clasen wrote: > > > gnome-menus uses gamin for notification, which uses inotify. The problem > > > is that inotify sucks when it comes to nonexisting files > > Can't you add a watch on the directory, and get notification when > > a file gets added that way? > Sure. But if that directory is a busy one like, say, $HOME, then you get > a lot of unnecessary wakeups. Is "menu entries right in $HOME" a typical case? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From davej at redhat.com Tue Dec 5 19:17:13 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 5 Dec 2006 14:17:13 -0500 Subject: CPU Frequency Scaling In-Reply-To: <1165345702.16839.3.camel@golem.boston.devel.redhat.com> References: <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> <1165232586.3147.3.camel@hughsie-laptop> <20061204175805.GA26115@redhat.com> <20061204184215.GB31682@nostromo.devel.redhat.com> <20061205170404.GA4802@redhat.com> <1165340639.10890.5.camel@golem.boston.devel.redhat.com> <20061205190245.GG6796@redhat.com> <1165345702.16839.3.camel@golem.boston.devel.redhat.com> Message-ID: <20061205191713.GH6796@redhat.com> On Tue, Dec 05, 2006 at 02:08:22PM -0500, Matthias Clasen wrote: > > > gnome-menus uses gamin for notification, which uses inotify. The problem > > > is that inotify sucks when it comes to nonexisting files > > > > Can't you add a watch on the directory, and get notification when > > a file gets added that way? > > > > Sure. But if that directory is a busy one like, say, $HOME, then you get > a lot of unnecessary wakeups. That's still got to be more efficient than polling. Dave From nicolas.mailhot at laposte.net Tue Dec 5 19:46:15 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 05 Dec 2006 20:46:15 +0100 Subject: CPU Frequency Scaling In-Reply-To: <8724.192.54.193.51.1165332601.squirrel@rousalka.dyndns.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <1165316977.17513.37.camel@cutter> <1165321648.3116.15.camel@dawkins> <1165321728.2751.22.camel@localhost.localdomain> <15946.192.54.193.51.1165325344.squirrel@rousalka.dyndns.org> <1165325671.9398.4.camel@golem.boston.devel.redhat.com> <1165325982.3096.34.camel@blaa> <8724.192.54.193.51.1165332601.squirrel@rousalka.dyndns.org> Message-ID: <1165347976.20474.60.camel@rousalka.dyndns.org> Le mardi 05 d?cembre 2006 ? 16:30 +0100, Nicolas Mailhot a ?crit : > Le Mar 5 d?cembre 2006 14:39, Mark McLoughlin a ?crit : > > > Take a look at the how the XML files are saved these days (they're > > indented) > > Good, the situation is slowly improving then. ? > Now I think I've looked at the rawhide gconf evo files in the last two > months, and they were the mess I remembered, Since I've sinned by talking from memory, and from memory of a known gconf abuser, here is a quick sysadmin-oriented review of the latest gconf files I have access to (rawhide system) 1. the file hierarchy is weird. The default file is named "%gconf.xml", which seems to protect against inexistent collision risks (gconf seems to only allow those files or directories, so anything ended in .xml would have fit the bill) 2. I can understand the choice to only allow foo/%gconf.xml instead of foo.xml files (leaf vs parent node safety), but only because of my background. Most humans will find this choice weird, unintuitive and heavy-handed on directories 3. all the conf files I've skimmed only use XML nesting for technical not functional reasons, they don't even have the first level of grouping of .ini files, so one wonders if the XML potential is really used there (esp. WRT the deep filesystem directory nesting used at the same time)? 4. OTOH the format is needlessly nesting and verbose for technical reasons. A sample (composition of gconf extracts): /usr/share/backgrounds/images/default-wide.jpg
  • systray
  • trash_applet
    • a. what the hell is mtime doing there? If the gconf users are not live, why should they care when an entry was modified ? If one or several users are live and you need to track concurrent modifications, surely this can happen in a memory cache without ever hitting the file system ? This bit alone prevents safe manual editing b. why is the typing in the conf file itself and not in a separate file? (that could be written using a standard syntax like Relax NG generic tools like vim or xsltproc have a chance to understand) c. the boolean entry needlessly uses two lines d. for the following entry: now we've written the entry is a string (which tells us nothing, string basically means untyped) instead of filling it with an xml string directly, someone though it was smart to stuff the xml string in a element. Why the heck for ? I could understand it if you could have several stringvalue children, but multivalued elements 1. have another type? 2. wrap their stringvalues in li elements anyway. Put all those remarks together and you could have : /usr/share/backgrounds/images/default-wide.jpg
  • systray
  • trash_applet
    •      typing-schema-id being the id of a schema properly declared in /etc/xml for vim, libxslt and friends I don't think this variant would be any more difficult for apps. For humans it would definitively be nicer. ? ignoring the schema part for ? IMHO it could safely be moved to /usr/share as it's not were configuration takes place. ? I won't expand on the type + ltype + type-in-li thing -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From david at fubar.dk Tue Dec 5 19:49:53 2006 From: david at fubar.dk (David Zeuthen) Date: Tue, 05 Dec 2006 14:49:53 -0500 Subject: CPU Frequency Scaling In-Reply-To: <44130.192.54.193.51.1165319440.squirrel@rousalka.dyndns.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <44130.192.54.193.51.1165319440.squirrel@rousalka.dyndns.org> Message-ID: <1165348193.2460.64.camel@zelda.fubar.dk> On Tue, 2006-12-05 at 12:50 +0100, Nicolas Mailhot wrote: > gconf does not need to be "fixed" (well it does but that's not the major > problem). What need to be "fixed" are developper assumptions and the way > they routinely abuse gconf in admin-unfriendly ways. Bah, blanket statement, anyone can write crap with even the finest tools. So, care to make specific complaints about g-p-m's scheme http://cvs.gnome.org/viewcvs/gnome-power-manager/data/gnome-power-manager.schemas.in?rev=1.52&view=markup and how that is "difficult" for admins to grasp? My only complaint is that perhaps g-p-m suffers from too many options. David From nicolas.mailhot at laposte.net Tue Dec 5 20:01:39 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 05 Dec 2006 21:01:39 +0100 Subject: CPU Frequency Scaling In-Reply-To: <1165348193.2460.64.camel@zelda.fubar.dk> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <44130.192.54.193.51.1165319440.squirrel@rousalka.dyndns.org> <1165348193.2460.64.camel@zelda.fubar.dk> Message-ID: <1165348900.20474.67.camel@rousalka.dyndns.org> Le mardi 05 d?cembre 2006 ? 14:49 -0500, David Zeuthen a ?crit : > On Tue, 2006-12-05 at 12:50 +0100, Nicolas Mailhot wrote: > > gconf does not need to be "fixed" (well it does but that's not the major > > problem). What need to be "fixed" are developper assumptions and the way > > they routinely abuse gconf in admin-unfriendly ways. > > Bah, blanket statement, anyone can write crap with even the finest > tools. So, care to make specific complaints about g-p-m's scheme > > http://cvs.gnome.org/viewcvs/gnome-power-manager/data/gnome-power-manager.schemas.in?rev=1.52&view=markup > > and how that is "difficult" for admins to grasp? My only complaint is > that perhaps g-p-m suffers from too many options. Care to post an actual conf file sample ? That's what sysadmins will see. gnome-power-manager.schemas.in is about as interesting to them as a corba IDL declaration. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From arjan at fenrus.demon.nl Tue Dec 5 20:21:44 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 05 Dec 2006 21:21:44 +0100 Subject: CPU Frequency Scaling In-Reply-To: <20061205191713.GH6796@redhat.com> References: <1165170552.3233.234.camel@laptopd505.fenrus.org> <200612032104.54541.eng@prowip.net.br> <1165232586.3147.3.camel@hughsie-laptop> <20061204175805.GA26115@redhat.com> <20061204184215.GB31682@nostromo.devel.redhat.com> <20061205170404.GA4802@redhat.com> <1165340639.10890.5.camel@golem.boston.devel.redhat.com> <20061205190245.GG6796@redhat.com> <1165345702.16839.3.camel@golem.boston.devel.redhat.com> <20061205191713.GH6796@redhat.com> Message-ID: <1165350104.3233.404.camel@laptopd505.fenrus.org> On Tue, 2006-12-05 at 14:17 -0500, Dave Jones wrote: > On Tue, Dec 05, 2006 at 02:08:22PM -0500, Matthias Clasen wrote: > > > > > gnome-menus uses gamin for notification, which uses inotify. The problem > > > > is that inotify sucks when it comes to nonexisting files > > > > > > Can't you add a watch on the directory, and get notification when > > > a file gets added that way? > > > > > > > Sure. But if that directory is a busy one like, say, $HOME, then you get > > a lot of unnecessary wakeups. > > That's still got to be more efficient than polling. surely you can rate limit this and just on busy dirs at most scan every 4 seconds... (which is the current poll interval) From florin at andrei.myip.org Tue Dec 5 19:37:01 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 05 Dec 2006 11:37:01 -0800 Subject: CPU Frequency Scaling In-Reply-To: <4575C289.7010209@volny.cz> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <1165316977.17513.37.camel@cutter> <1165321648.3116.15.camel@dawkins> <1165321728.2751.22.camel@localhost.localdomain> <4575B0BD.4030900@andrei.myip.org> <4575C289.7010209@volny.cz> Message-ID: <4575CA5D.8000609@andrei.myip.org> Miloslav Trmac wrote: > Not really. It is not that much harder to write the equivalent code > without GConf. To support upgrades, the application must > 1) be able to read the settings in the original format > 2) convert them to the new format > 3) write them back in the new format. Reinventing the wheel is always a bad idea. Why force this ordeal upon each and every application, when a clear configuration management interface could be used instead by all of them? > 2) doesn't depend on GConf availability. But gconf (or any other equivalent) avoids the reinvention of the wheel by each and every application. > GConf helps with 1) and 3). > Applications not GConf obviously already have 1). So the only > difference is writing code that can write the current configuration as a > configuration file (losing all comments in the process, exactly like > GConf-using applications would). Why lose the comments? A configuration management app can be purposefully created in such a way as to preserve even the comments. > Writing this code should really not be > _that_ difficult. Agreed, provided that it's written _once_. > When httpd changed the config format incompatibly and the httpd > developers didn't write a config format converter, and when GNOME > applications changed the used GConf schema and their developers did > write a config format converter, the difference is mainly caused by the > developer's decision, not by usage of GConf. The developer's decisions will be greatly simplified if they had an external tool to handle all the configuration management issues. One less nuisance to bother with. I wrote initially a longer message, but it's been edited a bit and I will post the rest in a separate message in this thread. -- Florin Andrei http://florin.myip.org/ From florin at andrei.myip.org Tue Dec 5 19:41:40 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 05 Dec 2006 11:41:40 -0800 Subject: ideal config management framework [was: CPU Frequency Scaling] In-Reply-To: <20061204170907.GA10166@jadzia.bu.edu> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> Message-ID: <4575CB74.6030200@andrei.myip.org> Matthew Miller wrote: > I'm just not convinced that not being able to ssh in to a server and edit > some config files but rather have to figure out how to tweak the > policy-daemon-of-the-month is the user experience a large segment of "we" > wants at all. Human-editable config files are a huge strength. Using a > policy daemon may be part of the answer, but it should be able to get its > configuration from something that can be fixed with vi. Long-term, it's actually best for the sysadmin to only have to deal with _one_ interface for all configuration tasks. Automating config changes will be made consistent and trivial. Just think of it, you could run (fictional example) something like... config-tool change ...and presto! you just reconfigured the app. E.g.: config-tool change apache ServerRoot "/foo/bar" Or something like... config-tool dump | less ...and, well, it's self-explanatory. Certain values in the space could be reserved for system settings. E.g.: config-tool change system-eth0 ip-address 192.168.2.7 How about this? config-tool -remote some.other.server.com change \ I would _love_ to be able to do that (if everything's correctly implemented, with security in mind, let's not be clueless morons, yadda-yadda). I hate the freakin' text files with passion. It would be great if all config files had the same format, ideally either something along the lines of daemontools or djbdns (specially designed so automation is super-trivial), or heck I would even take XML - but only if it was universally used by all apps and system components. Several different user-level tools could be implemented, offering different views into the same data, and different mechanisms to change the same settings: - a command-line tool as exemplified above - a text-based pseudo-GUI (think Midnight Commander) - a true GUI, based on GTK or Qt or what have you - APIs for PHP, Perl, Python, C, Java, etc. for Web interfaces or for direct access from within other apps If push comes to shove, the configuration daemon could be stopped and the XML backend (or whatever) could be edited manually by those who really need to do that. I am dreaming about this since... I don't know, maybe 1999 or so. P.S.: Please note that I'm not necessarily speaking of gconf in particular. I'm merely discussing the advantages of a well-written configuration management framework - which gconf may or may not be yet, I'm not familiar enough with it. -- Florin Andrei http://florin.myip.org/ From nicolas.mailhot at laposte.net Tue Dec 5 20:22:23 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 05 Dec 2006 21:22:23 +0100 Subject: CPU Frequency Scaling In-Reply-To: <1165347976.20474.60.camel@rousalka.dyndns.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <16781.192.54.193.51.1165310508.squirrel@rousalka.dyndns.org> <1165319059.3089.12.camel@dawkins> <1165316977.17513.37.camel@cutter> <1165321648.3116.15.camel@dawkins> <1165321728.2751.22.camel@localhost.localdomain> <15946.192.54.193.51.1165325344.squirrel@rousalka.dyndns.org> <1165325671.9398.4.camel@golem.boston.devel.redhat.com> <1165325982.3096.34.camel@blaa> <8724.192.54.193.51.1165332601.squirrel@rousalka.dyndns.org> <1165347976.20474.60.camel@rousalka.dyndns.org> Message-ID: <1165350146.20474.80.camel@rousalka.dyndns.org> Le mardi 05 d?cembre 2006 ? 20:46 +0100, Nicolas Mailhot a ?crit : > Put all those remarks together and you could have : > > > > > > > /usr/share/backgrounds/images/default-wide.jpg > > >
  • systray
    • >
  • trash_applet
    • >     >     > > typing-schema-id being the id of a schema properly declared in /etc/xml > for vim, libxslt and friends another variant (easier to write typing schema for) : /usr/share/backgrounds/images/default-wide.jpg systray trash_applet -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From mattdm at mattdm.org Tue Dec 5 20:54:30 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 5 Dec 2006 15:54:30 -0500 Subject: ideal config management framework [was: CPU Frequency Scaling] In-Reply-To: <4575CB74.6030200@andrei.myip.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <4575CB74.6030200@andrei.myip.org> Message-ID: <20061205205430.GA26719@jadzia.bu.edu> On Tue, Dec 05, 2006 at 11:41:40AM -0800, Florin Andrei wrote: > Long-term, it's actually best for the sysadmin to only have to deal with > _one_ interface for all configuration tasks. Automating config changes > will be made consistent and trivial. Just think of it, you could run > (fictional example) something like... Long term isn't here yet. It's fine to design for long term, but to get from here to there, please don't throw out "now". [...] > I hate the freakin' text files with passion. It would be great if all This is a fine viewpoint. It is, however, not universal, and it's better for Fedora if it's not treated as the gospel. The system you're proposing seems okay enough, especially if you can get it to work across platforms. It's a lot more useful for me (or anyone in a large heterogeneous environment) to know how to edit Sendmail and Apache configs on any platform than it is for me to have a tool that edits any arbitrary config on one specific platform. Even if the config file is as frustrating as sendmail's. In fact, the tool is merely annoying, because it becomes a special case. Being a special case is not how we win. I realize this specific thread started by talking about a specific case for which there is no existing functionality, but the basic principle still applies. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sonal.santan at xilinx.com Tue Dec 5 20:56:26 2006 From: sonal.santan at xilinx.com (Sonal Santan) Date: Tue, 5 Dec 2006 12:56:26 -0800 Subject: ideal config management framework [was: CPU Frequency Scaling] Message-ID: Elektra Project at http://elektra.sf.net seems to provide some of these features. Sonal -----Original Message----- From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of Florin Andrei Sent: Tuesday, December 05, 2006 11:42 AM To: Development discussions related to Fedora Core Subject: ideal config management framework [was: CPU Frequency Scaling] Matthew Miller wrote: > I'm just not convinced that not being able to ssh in to a server and edit > some config files but rather have to figure out how to tweak the > policy-daemon-of-the-month is the user experience a large segment of "we" > wants at all. Human-editable config files are a huge strength. Using a > policy daemon may be part of the answer, but it should be able to get its > configuration from something that can be fixed with vi. Long-term, it's actually best for the sysadmin to only have to deal with _one_ interface for all configuration tasks. Automating config changes will be made consistent and trivial. Just think of it, you could run (fictional example) something like... config-tool change ...and presto! you just reconfigured the app. E.g.: config-tool change apache ServerRoot "/foo/bar" Or something like... config-tool dump | less ...and, well, it's self-explanatory. Certain values in the space could be reserved for system settings. E.g.: config-tool change system-eth0 ip-address 192.168.2.7 How about this? config-tool -remote some.other.server.com change \ I would _love_ to be able to do that (if everything's correctly implemented, with security in mind, let's not be clueless morons, yadda-yadda). I hate the freakin' text files with passion. It would be great if all config files had the same format, ideally either something along the lines of daemontools or djbdns (specially designed so automation is super-trivial), or heck I would even take XML - but only if it was universally used by all apps and system components. Several different user-level tools could be implemented, offering different views into the same data, and different mechanisms to change the same settings: - a command-line tool as exemplified above - a text-based pseudo-GUI (think Midnight Commander) - a true GUI, based on GTK or Qt or what have you - APIs for PHP, Perl, Python, C, Java, etc. for Web interfaces or for direct access from within other apps If push comes to shove, the configuration daemon could be stopped and the XML backend (or whatever) could be edited manually by those who really need to do that. I am dreaming about this since... I don't know, maybe 1999 or so. P.S.: Please note that I'm not necessarily speaking of gconf in particular. I'm merely discussing the advantages of a well-written configuration management framework - which gconf may or may not be yet, I'm not familiar enough with it. -- Florin Andrei http://florin.myip.org/ -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list From jcm at redhat.com Tue Dec 5 21:06:08 2006 From: jcm at redhat.com (Jon Masters) Date: Tue, 05 Dec 2006 16:06:08 -0500 Subject: Maintainance of hwdata In-Reply-To: <20061205175921.GB6796@redhat.com> References: <200612050342.40196.opensource@till.name> <457548C0.5060401@redhat.com> <1165315979.3233.364.camel@laptopd505.fenrus.org> <20061205175921.GB6796@redhat.com> Message-ID: <4575DF40.30608@redhat.com> Dave Jones wrote: > On Tue, Dec 05, 2006 at 11:52:59AM +0100, Arjan van de Ven wrote: > > one thing that would be nice is if the cpu microcode data would actually > > move from microcode_ctl to hwdata; the program almost never gets updated > > but the microcode file gets updated every few months Indeed. I've been doing some work on microcode_ctl lately, having taken it over recently - I'm ok with the idea of splitting the microcode itself out into another package, but that package is not hwdata. > hwdata is noarch though. Including x86 microcode data on all arches would be > a bit crap. Yep. Though if people (and Intel?) think it's a good idea, I can split it out into another package for ease of updating...any word on whether greater microcode changelog data is forthcoming? :-) Jon. From hamzy at us.ibm.com Tue Dec 5 21:04:51 2006 From: hamzy at us.ibm.com (Mark Hamzy) Date: Tue, 5 Dec 2006 15:04:51 -0600 Subject: Fw: Build Error (Job 22980): sblim-cmpi-base-1_5_4-7_fc7 on fedora-development-extras Message-ID: Does anyone know what I am doing wrong here? I am trying to rebuild sblim-cmpi-base and I am getting this error message. I think that when it tries to install tog-pegasus in the build root, it is installing exim and exim wants libpq.so.4 which is in postgres? I don't want exim or postgres. Thanks, Mark Common Information Model/Web-Based Enterprise Management at http://www.openpegasus.org/ Take a look at the Linux Omni Printer Driver Framework at http://omniprint.sourceforge.net/ ----- Forwarded by Mark Hamzy/Austin/IBM on 12/05/2006 03:00 PM ----- buildsys at fedorapr oject.org To 12/05/2006 11:37 Mark Hamzy/Austin/IBM at IBMUS AM cc Subject Build Error (Job 22980): sblim-cmpi-base-1_5_4-7_fc7 on fedora-development-extras Job failed on arch i386 Build logs may be found at http://buildsys.fedoraproject.org/logs/fedora-development-extras/22980-sblim-cmpi-base-1.5.4-7.fc7/ ------------------------------------------------- sblim-cmpi-base ################################################## Executing /usr/sbin/mock-helper chroot /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root /sbin/runuser - root -c "/sbin/runuser -c 'rpmbuild -bs --target i386 --nodeps /builddir/build/SPECS/sblim-cmpi-base.spec' mockbuild" warning: Could not canonicalize hostname: hammer2.fedora.redhat.com Building target platforms: i386 Building for target i386 Wrote: /builddir/build/SRPMS/sblim-cmpi-base-1.5.4-7.fc7.src.rpm ensuring dir /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/proc Executing /usr/sbin/mock-helper mount -t proc proc /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/proc mount: proc already mounted or /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/proc busy mount: according to mtab, proc is already mounted on /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/dev/pts Executing /usr/sbin/mock-helper mount -t devpts devpts /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/dev/pts mount: devpts already mounted or /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/dev/pts busy mount: according to mtab, devpts is already mounted on /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/dev/pts Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root resolvedep 'tog-pegasus-devel >= 2.5' 2:tog-pegasus-devel-2.5.2-2.fc6.i386 ensuring dir /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/proc Executing /usr/sbin/mock-helper mount -t proc proc /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/proc mount: proc already mounted or /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/proc busy mount: according to mtab, proc is already mounted on /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/proc ensuring dir /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/dev/pts Executing /usr/sbin/mock-helper mount -t devpts devpts /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/dev/pts mount: devpts already mounted or /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/dev/pts busy mount: according to mtab, devpts is already mounted on /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/dev/pts Executing /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root install 'tog-pegasus-devel >= 2.5' Error: Missing Dependency: libpq.so.4 is needed by package exim Cleaning up... Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/proc Executing /usr/sbin/mock-helper umount /var/lib/mock/fedora-development-i386-core-c639c2676fff01b51b937295fc17e9329ffd6485/root/dev/pts Done. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pic27656.gif Type: image/gif Size: 1255 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ecblank.gif Type: image/gif Size: 45 bytes Desc: not available URL: From tiagomatos at gmail.com Tue Dec 5 21:24:31 2006 From: tiagomatos at gmail.com (Rui Tiago =?ISO-8859-1?Q?Ca=E7=E3o?= Matos) Date: Tue, 05 Dec 2006 21:24:31 +0000 Subject: ideal config management framework [was: CPU Frequency Scaling] In-Reply-To: <4575CB74.6030200@andrei.myip.org> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <4575CB74.6030200@andrei.myip.org> Message-ID: <1165353871.24893.21.camel@hive> On Ter, 2006-12-05 at 11:41 -0800, Florin Andrei wrote: > config-tool change > > ...and presto! you just reconfigured the app. E.g.: > > config-tool change apache ServerRoot "/foo/bar" > > Or something like... > > config-tool dump | less > > ...and, well, it's self-explanatory. > > Certain values in the space could be reserved for system > settings. E.g.: > > config-tool change system-eth0 ip-address 192.168.2.7 > > How about this? > > config-tool -remote some.other.server.com change \ > Very nice, I think Mac OS X has something like this [1]. > Several different user-level tools could be implemented, offering > different views into the same data, and different mechanisms to change > the same settings: > - a command-line tool as exemplified above > - a text-based pseudo-GUI (think Midnight Commander) > - a true GUI, based on GTK or Qt or what have you > - APIs for PHP, Perl, Python, C, Java, etc. for Web interfaces or for > direct access from within other apps > If push comes to shove, the configuration daemon could be stopped and > the XML backend (or whatever) could be edited manually by those who > really need to do that. And let's not forget that these APIs could and should provide mainloop integration like gconf does so that preferences can be automatically applied without manual daemon restarts or polling hacks. Yes even the sys V init system should completely go away and be something more like upstart[2]... I digress. Rui [1] http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFPreferences/Concepts/PreferenceDomains.html#//apple_ref/doc/uid/20001168 [2] http://upstart.ubuntu.com/ -------------- 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 Tue Dec 5 21:53:04 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 5 Dec 2006 16:53:04 -0500 Subject: gconf2 deps [was Re: CPU Frequency Scaling] In-Reply-To: <20061204204340.GB2427@nostromo.devel.redhat.com> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> Message-ID: <20061205215304.GA29307@jadzia.bu.edu> On Mon, Dec 04, 2006 at 03:43:40PM -0500, Bill Nottingham wrote: > So, the entire thing boils down to "I don't like the g-conf storage > format?" (I'm honestly asking here.) Here's another one. On my FTP server box, where it would be nice to have convenient power management settings, I currently have no reason whatsoever to have installed ORBit2, atk, fontconfig, freetype, gtk2, libIDL, libjpeg, libpng, libtiff, pango, xorg-x11-Mesa-libGL, or xorg-xll-libs. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From a.badger at gmail.com Tue Dec 5 22:44:54 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 05 Dec 2006 14:44:54 -0800 Subject: gconf2 deps [was Re: CPU Frequency Scaling] In-Reply-To: <20061205215304.GA29307@jadzia.bu.edu> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <20061205215304.GA29307@jadzia.bu.edu> Message-ID: <1165358694.21163.131.camel@localhost.localdomain> On Tue, 2006-12-05 at 16:53 -0500, Matthew Miller wrote: > On Mon, Dec 04, 2006 at 03:43:40PM -0500, Bill Nottingham wrote: > > So, the entire thing boils down to "I don't like the g-conf storage > > format?" (I'm honestly asking here.) > > Here's another one. On my FTP server box, where it would be nice to have > convenient power management settings, I currently have no reason whatsoever > to have installed The GConf2 package needs to be split up. Near as I can tell these: > ORBit2, > libIDL, are actual requirements of the GConf2 system. These: > atk, fontconfig, freetype, gtk2, > libjpeg, > libpng, libtiff, pango, xorg-x11-Mesa-libGL, or xorg-xll-libs. are all requirements of what appears to be a diagnostic tool. If /usr/libexec/gconf-sanity-check-2 was in a subpackage we wouldn't have any of these dependencies. -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 hhoffman at ip-solutions.net Wed Dec 6 02:30:53 2006 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 05 Dec 2006 21:30:53 -0500 Subject: adding scripts to hibernate/suspend Message-ID: <45762B5D.6060502@ip-solutions.net> Hi All, wondering if anyone has some pointers as to go about adding scripts to be executed when suspend/hibernate occur in FC6. i recall these used to be in /etc/acpi but this seems to have changed. I googled and found some items about gnome-hal but the examples used programs that don't seem to be within the fedora install. Any pointers? I'd like to be able to shut down my atheros card, as I'm not sure it's suspending. Thanks, Harry From mattdm at mattdm.org Wed Dec 6 02:45:22 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 5 Dec 2006 21:45:22 -0500 Subject: gconf2 deps [was Re: CPU Frequency Scaling] In-Reply-To: <1165358694.21163.131.camel@localhost.localdomain> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <20061205215304.GA29307@jadzia.bu.edu> <1165358694.21163.131.camel@localhost.localdomain> Message-ID: <20061206024522.GA9417@jadzia.bu.edu> On Tue, Dec 05, 2006 at 02:44:54PM -0800, Toshio Kuratomi wrote: > The GConf2 package needs to be split up. Near as I can tell these: > > ORBit2, > > libIDL, > are actual requirements of the GConf2 system. > These: > > atk, fontconfig, freetype, gtk2, > > libjpeg, > > libpng, libtiff, pango, xorg-x11-Mesa-libGL, or xorg-xll-libs. > are all requirements of what appears to be a diagnostic tool. > If /usr/libexec/gconf-sanity-check-2 was in a subpackage we wouldn't > have any of these dependencies. Thanks for taking the next logical step to my complaining. I'll file a bug for this in the morning if there isn't one already. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mclasen at redhat.com Wed Dec 6 02:56:28 2006 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 05 Dec 2006 21:56:28 -0500 Subject: gconf2 deps [was Re: CPU Frequency Scaling] In-Reply-To: <20061206024522.GA9417@jadzia.bu.edu> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <20061205215304.GA29307@jadzia.bu.edu> <1165358694.21163.131.camel@localhost.localdomain> <20061206024522.GA9417@jadzia.bu.edu> Message-ID: <1165373788.3640.4.camel@localhost.localdomain> On Tue, 2006-12-05 at 21:45 -0500, Matthew Miller wrote: > On Tue, Dec 05, 2006 at 02:44:54PM -0800, Toshio Kuratomi wrote: > > The GConf2 package needs to be split up. Near as I can tell these: > > > ORBit2, > > > libIDL, > > are actual requirements of the GConf2 system. > > These: > > > atk, fontconfig, freetype, gtk2, > > > libjpeg, > > > libpng, libtiff, pango, xorg-x11-Mesa-libGL, or xorg-xll-libs. > > are all requirements of what appears to be a diagnostic tool. > > If /usr/libexec/gconf-sanity-check-2 was in a subpackage we wouldn't > > have any of these dependencies. > > Thanks for taking the next logical step to my complaining. I'll file a bug > for this in the morning if there isn't one already. > Right, thats a simple packaging mishap thats easily fixable. From peter at thecodergeek.com Wed Dec 6 03:04:32 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 05 Dec 2006 19:04:32 -0800 Subject: adding scripts to hibernate/suspend In-Reply-To: <45762B5D.6060502@ip-solutions.net> References: <45762B5D.6060502@ip-solutions.net> Message-ID: <1165374272.4233.3.camel@localhost> On Tue, 2006-12-05 at 21:30 -0500, Harry Hoffman wrote: > i recall these used to be in /etc/acpi but this seems to have changed. I > googled and found some items about gnome-hal but the examples used > programs that don't seem to be within the fedora install. There are a bunch of helper scripts in /etc/pm/hooks which you can use as examples to generate your own that runs rmmod or modprobe as needed, et al. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- 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 Wed Dec 6 03:05:37 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 5 Dec 2006 22:05:37 -0500 Subject: gconf2 deps [was Re: CPU Frequency Scaling] In-Reply-To: <1165373788.3640.4.camel@localhost.localdomain> References: <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <20061204204340.GB2427@nostromo.devel.redhat.com> <20061205215304.GA29307@jadzia.bu.edu> <1165358694.21163.131.camel@localhost.localdomain> <20061206024522.GA9417@jadzia.bu.edu> <1165373788.3640.4.camel@localhost.localdomain> Message-ID: <20061206030537.GA10688@jadzia.bu.edu> On Tue, Dec 05, 2006 at 09:56:28PM -0500, Matthias Clasen wrote: > Right, thats a simple packaging mishap thats easily fixable. It's not even really a mishap in the current case where gconf is only used for GUI desktop stuff where you'll always have that stuff anyway. It's just one of the things that needs to be considered. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From hhoffman at ip-solutions.net Wed Dec 6 03:15:40 2006 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Tue, 05 Dec 2006 22:15:40 -0500 Subject: adding scripts to hibernate/suspend In-Reply-To: <1165374272.4233.3.camel@localhost> References: <45762B5D.6060502@ip-solutions.net> <1165374272.4233.3.camel@localhost> Message-ID: <457635DC.5040306@ip-solutions.net> Peter, that's just what I needed! thanks much :-) Cheers, Harry Peter Gordon wrote: > On Tue, 2006-12-05 at 21:30 -0500, Harry Hoffman wrote: >> i recall these used to be in /etc/acpi but this seems to have changed. I >> googled and found some items about gnome-hal but the examples used >> programs that don't seem to be within the fedora install. > > There are a bunch of helper scripts in /etc/pm/hooks which you can use > as examples to generate your own that runs rmmod or modprobe as needed, > et al. > From florin at andrei.myip.org Wed Dec 6 03:39:04 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 05 Dec 2006 19:39:04 -0800 Subject: ideal config management framework [was: CPU Frequency Scaling] In-Reply-To: References: Message-ID: <45763B58.3020301@andrei.myip.org> Sonal Santan wrote: > Elektra Project at http://elektra.sf.net seems to provide some of these > features. Not bad. Seems like they need a bit more user-level tools and it would be pretty close to what I was describing above. -- Florin Andrei http://florin.myip.org/ From pertusus at free.fr Wed Dec 6 08:49:33 2006 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 6 Dec 2006 09:49:33 +0100 Subject: ideal config management framework [was: CPU Frequency Scaling] In-Reply-To: <45763B58.3020301@andrei.myip.org> References: <45763B58.3020301@andrei.myip.org> Message-ID: <20061206084932.GA2491@free.fr> On Tue, Dec 05, 2006 at 07:39:04PM -0800, Florin Andrei wrote: > Sonal Santan wrote: > >Elektra Project at http://elektra.sf.net seems to provide some of these > >features. > > Not bad. Seems like they need a bit more user-level tools and it would > be pretty close to what I was describing above. I submitted it for Fedora Extras: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209906 Ralf Corsepius begun reviewing it, but don't want to approve it because of some names which may conflict, but maybe somebody else could be less demanding. -- Pat From mihamina.rakotomandimby at etu.univ-orleans.fr Wed Dec 6 09:16:56 2006 From: mihamina.rakotomandimby at etu.univ-orleans.fr (Mihamina Rakotomandimby) Date: Wed, 06 Dec 2006 10:16:56 +0100 Subject: 2.6.18-1.2239 soft lockup on CPU#0 Message-ID: <1165396616.5042.7.camel@r4000> Hi, I use FC5 on an MSI KT4A-V [1] and an AMD Athlon 2800+ CPU. Kernel is kernel-2.6.18-1.2239. When booting, I got a "soft lockup detected on CPU#0". 2.6.15 kernel (the one instaled at install time) works fine. Would you know an existing bug I could confirm or should I open one? I already searched, and there are many similar problems. What to do then? From rc040203 at freenet.de Wed Dec 6 09:38:09 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 06 Dec 2006 10:38:09 +0100 Subject: ideal config management framework [was: CPU Frequency Scaling] In-Reply-To: <20061206084932.GA2491@free.fr> References: <45763B58.3020301@andrei.myip.org> <20061206084932.GA2491@free.fr> Message-ID: <1165397889.23106.93.camel@mccallum.corsepiu.local> On Wed, 2006-12-06 at 09:49 +0100, Patrice Dumas wrote: > On Tue, Dec 05, 2006 at 07:39:04PM -0800, Florin Andrei wrote: > > Sonal Santan wrote: > > >Elektra Project at http://elektra.sf.net seems to provide some of these > > >features. > > > > Not bad. Seems like they need a bit more user-level tools and it would > > be pretty close to what I was describing above. > > I submitted it for Fedora Extras: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209906 > > Ralf Corsepius begun reviewing it, Well, to be precise, I have never reviewed it, I only commented on it. Apart from apparent packaging issues (headers, static libs), which have not been addressed so far, I am sensing a pretty large gap between elektra's claims (I perceived their proponents to be very aggressively marketing their package) and reality (Otherwise it probably already would be in Fedora as requirement of another package ;) ). Ralf From tmus at tmus.dk Wed Dec 6 11:48:12 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 06 Dec 2006 12:48:12 +0100 Subject: ideal config management framework [was: CPU Frequency Scaling] In-Reply-To: <20061205205430.GA26719@jadzia.bu.edu> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <4575CB74.6030200@andrei.myip.org> <20061205205430.GA26719@jadzia.bu.edu> Message-ID: Matthew Miller wrote: > > The system you're proposing seems okay enough, especially if you can get it > to work across platforms. > Still, if a new config system should make configging things easier, it would have to work all over the place. No apps should use other config-methods and *swoosh*, we're windows (in the worst possible sense). Not that I'm totally against adopting things that work fine on other OS's, but the windows registry is a notorious mess. Also - Think of the additional error scenarios when init is gconf'ed. The same complexity is added for everything else that adopts a registry based configuration engine (since that engine has to be operational for it to work in the first place) but may not be quite as aparrent. /Thomas From buildsys at redhat.com Wed Dec 6 11:57:16 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 6 Dec 2006 06:57:16 -0500 Subject: rawhide report: 20061206 changes Message-ID: <200612061157.kB6BvGGF031947@hs20-bc2-6.build.redhat.com> Updated Packages: apr-util-1.2.8-2 ---------------- * Tue Dec 05 2006 Joe Orton 1.2.8-2 - update to 1.2.8, pick up new libpq soname autofs-1:5.0.1-0.rc2.29 ----------------------- * Wed Dec 06 2006 Ian Kent - 5.0.1-0.rc2.29 - alter nfs4 host probing to not use portmap lookup and add options check for "port=" parameter (bz 208757. - correct semantics of "-null" map handling (bzs 214800, 208091). control-center-1:2.17.3-1.fc7 ----------------------------- * Tue Dec 05 2006 Matthias Clasen - 2.17.3-1 - Update to 2.17.3 cpio-2.6-21.fc7 --------------- * Tue Dec 05 2006 Peter Vrabec 2.6-21 - fix setlocale (#200478) dasher-4.3.2-1.fc7 ------------------ * Tue Dec 05 2006 Matthias Clasen - 4.3.2-1 - Update to 4.3.2 * Tue Nov 07 2006 Matthias Clasen - 4.3.1-1 - Update to 4.3.1 eog-2.17.2-1.fc7 ---------------- * Tue Dec 05 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 epiphany-2.17.3-1.fc7 --------------------- * Tue Dec 05 2006 Matthias Clasen - 2.17.3-1 - Update to 2.17.3 fontconfig-2.4.2-1.fc7 ---------------------- * Tue Dec 05 2006 Matthias Clasen - 2.4.2-1 - Update to 2.4.2 * Wed Oct 04 2006 Matthias Clasen - 2.4.1-4 - Fix a multilib upgrade problem (#208151) fonts-indic-2.0.10-1.fc7 ------------------------ * Wed Dec 06 2006 Parag Nemade - 2.0.10-1.fc7 - Resolved Bugs from Parag Nemade - Resolves: bug 207269,bug 217482,bug 216628,bug 218588,bug 206599 - Resolved Bugs from LingNing Zhang - Resolves: Bug 218586,bug 218587 * Tue Nov 21 2006 Parag Nemade - 2.0.9-1 - Fixed Bugs from Parag Nemade - Bug 216060: [pa_IN]Lohit Punjabi: (U+0A03) Gurmukhi Sign Visarga right margin is too wide. * Tue Nov 21 2006 Parag Nemade - 2.0.8-1 - Fixed Bugs from Parag Nemade - Bug 216629 : [te_IN] GPOS position should be at middle instead of left hand side - Priority B - Bug 216631 : [or_IN] one GSUB Rule is wrongly defined - Priority A - Bug 216628 : [ml] characters are not shown bold during selecting BOLD font - Bug 216624 : [pa_IN] 0a01/0a03/0964/0965 is missing from font - Bug 216634 : Glyphs for two combinations are wrong in Gujarati (gu_IN) - Bug 197216 : [bn_IN]Incorrect glyph for conjunct - Bug 215894 : Relative height of 0x0901 (and 0x0902) on 0x0915 is different than other devnagari characters (hi_IN, mr_IN) - Fixed Bugs from LingNing Zhang - Bug 216626 : [as_IN] Pango - A particular char when Conjuncts, creates Cursor Nevigation Problem - Bug 216627 : [ml_IN] The glyph of 0x25CC is not existing in lohit_ml.ttf - Bug 216639 : [kn_IN] OTF rules to be fixed - Priority A gaim-2:2.0.0-0.26.beta5.fc7 --------------------------- * Tue Dec 05 2006 Warren Togami - 2:2.0.0-0.26.beta6 - Jabber SASL Authentication Crash (#217335) ghostscript-8.15.3-3.fc7 ------------------------ * Tue Dec 05 2006 Tim Waugh 8.15.3-3 - Added split-cidfnmap patch (bug #194592). * Thu Nov 16 2006 Tim Waugh 8.15.3-2 - 8.15.3. No longer need gtk2, ps2epsi, badc, pagesize, use-external-freetype, split-font-configuration or cjkv patches. - Renumbered patches. * Tue Oct 03 2006 Tim Waugh 8.15.2-9 - Apply CJKV patch from svn164:165 plus the fix from svn173:174 (bug #194592, bug #203712, possibly bug #167596). gnome-applets-1:2.16.2-2.fc7 ---------------------------- * Tue Dec 05 2006 Matthias Clasen - 1:2.16.2-2 - Fix the trashapplet opening a window on the wrong screen (#218447) * Tue Dec 05 2006 Matthias Clasen - 1:2.16.2-1 - Update to 2.16.2 - Drop obsolete patches gnome-games-1:2.17.3-1.fc7 -------------------------- * Tue Dec 05 2006 Matthias Clasen - 1:2.17.3-1 - Update to 2.17.3 gnome-icon-theme-2.17.3-1.fc7 ----------------------------- * Tue Dec 05 2006 Matthias Clasen - 2.17.3-1 - Update to 2.17.3 gnome-panel-2.16.2-1.fc7 ------------------------ * Tue Dec 05 2006 Matthias Clasen - 2.16.2-1 - Update to 2.16.2 - Drop upstreamed patches gnome-screensaver-2.17.3-1.fc7 ------------------------------ * Tue Dec 05 2006 Matthias Clasen - 2.17.3-1 - Update to 2.17.3 - Drop upstreamed patch gnome-vfs2-2.16.3-1.fc7 ----------------------- * Tue Dec 05 2006 Matthias Clasen - 2.16.3-1 - Update to 2.16.3 - Don't ship static libraries gtk2-engines-2.9.0-1.fc7 ------------------------ * Tue Dec 05 2006 Matthias Clasen - 2.9.0-1 - Update to 2.9.0 httpd-2.2.3-7 ------------- * Tue Dec 05 2006 Joe Orton 2.2.3-7 - rebuild for libpq soname bump libgnome-2.17.1-1.fc7 --------------------- * Tue Dec 05 2006 Matthias Clasen - 2.17.1-1 - Update to 2.17.1 * Wed Nov 08 2006 Matthias Clasen - 2.17.0-1 - Update to 2.17.0 * Fri Oct 27 2006 David Zeuthen - 2.16.0-7 - Make Echo the default icon theme and require echo-icon-theme for now libgnomeui-2.17.0-1.fc7 ----------------------- * Tue Dec 05 2006 Matthias Clasen - 2.17.0-1 - Update to 2.17.0 libwnck-2.16.2-1.fc7 -------------------- * Tue Dec 05 2006 Matthias Clasen - 2.16.2-1 - Update to 2.16.2 mkinitrd-6.0.2-1 ---------------- * Tue Dec 05 2006 Peter Jones - 6.0.2-1 - Fix typo introduced in merge (patch from notting) mod_auth_pgsql-2.0.3-3 ---------------------- * Tue Dec 05 2006 Joe Orton 2.0.3-3 - rebuild for new libpq * Wed Jul 12 2006 Jesse Keating - 2.0.3-2.3.1 - rebuild * Fri Feb 10 2006 Jesse Keating - 2.0.3-2.3 - bump again for double-long bug on ppc(64) mod_perl-2.0.3-3 ---------------- * Tue Dec 05 2006 Joe Orton 2.0.3-3 - trim modules even more aggressively (#197841) * Mon Dec 04 2006 Joe Orton 2.0.3-2 - update to 2.0.3 - remove droplet in buildroot from multilib patch - drop build-related ModPerl:: modules and Apache::Test (#197841) - spec file cleanups nautilus-cd-burner-2.17.3-1.fc7 ------------------------------- * Tue Dec 05 2006 Matthias Clasen - 2.17.3-1 - Update to 2.17.3 pango-1.15.1-1.fc7 ------------------ * Tue Dec 05 2006 Matthias Clasen - 1.15.1-1 - Update to 1.15.1 perl-DBD-Pg-1.49-3.fc7 ---------------------- * Wed Dec 06 2006 Robin Norwood - 1.49-3 - rebuild for new version of postgres. perl-RPM-Specfile-1.19-2.1.1 ---------------------------- * Wed Jul 12 2006 Jesse Keating - sh: line 0: fg: no job control - rebuild * Fri Feb 03 2006 Jason Vas Dias - 1.19-2.1 - rebuild for new perl-5.8.8 * Fri Jan 06 2006 Ville Skytt?? - 1.19-1 - 1.19 (#176721). - Rewrite specfile using fedora-rpmdevtools' spec template, fixes #176888. perl-XML-Simple-2.16-2.fc7 -------------------------- * Tue Dec 05 2006 Robin Norwood - 2.16-2 - Fix incorrect 'Release' tag - removed extra dot. pykickstart-0.42-1.fc7 ---------------------- * Tue Dec 05 2006 Chris Lumens - 0.42-1 - Fix traceback when writing out repo command (#218274). pyparted-1.8.1-2.fc7 -------------------- * Tue Dec 05 2006 David Cantrell - 1.8.1-2 - Rebuild for GNU parted-1.8.1 pyxf86config-0.3.31-3.fc7 ------------------------- * Tue Dec 05 2006 Adam Jackson 0.3.31-3 - Update libxf86config-devel BR to a sufficiently new version to not print the "Comment all HorizSync and VertSync values to use DDC" message, and rebuild. (#216288) redhat-lsb-3.1-12.2 ------------------- * Wed Nov 29 2006 Lawrence Lim - 3.1-12 - replaced aliases with functions in /lib/lsb/init-functions; Bug 217566 * Sun Oct 01 2006 Jesse Keating - 3.1-11 - rebuilt for unwind info generation, broken in gcc-4.1.1-21 * Thu Sep 21 2006 Lawrence Lim - 3.1-10.3 - Fix upgrade issue; Bug 202548 selinux-policy-2.4.6-6.fc7 -------------------------- * Mon Dec 04 2006 Dan Walsh 2.4.6-6 - Fix polyinstatiation - Fix pcscd handling of terminal Resolves: #218149 Resolves: #218350 sound-juicer-2.16.2-1.fc7 ------------------------- * Tue Dec 05 2006 Matthias Clasen - 2.16.2-1 - Update to 2.16.2 vte-0.15.0-1.fc7 ---------------- * Tue Dec 05 2006 Matthias Clasen 0.15.0-1 - Update to 2.15.0 yelp-2.16.2-1.fc7 ----------------- * Tue Dec 05 2006 Matthias Clasen - 2.16.2-1 - Update to 2.16.2 - Drop obsolete patch Broken deps for ia64 ---------------------------------------------------------- bind-sdb - 30:9.3.3-6.fc7.ia64 requires libpq.so.4()(64bit) cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.ia64 requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.ia64 requires libpq.so.4()(64bit) gnome-volume-manager - 2.17.0-2.fc7.ia64 requires kernel >= 0:2.6 libdbi-dbd-pgsql - 0.8.1a-1.2.2.ia64 requires libpq.so.4()(64bit) pcmciautils - 014-5.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 php-pgsql - 5.2.0-7.ia64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ia64 requires libpq.so.4()(64bit) qt-PostgreSQL - 1:3.3.7-1.fc7.ia64 requires libpq.so.4()(64bit) systemtap - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 Broken deps for s390 ---------------------------------------------------------- bind-sdb - 30:9.3.3-6.fc7.s390 requires libpq.so.4 cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.s390 requires libpq.so.4 freeradius-postgresql - 1.1.3-2.s390 requires libpq.so.4 libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390 requires libpq.so.4 php-pgsql - 5.2.0-7.s390 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.s390 requires libpq.so.4 qt-PostgreSQL - 1:3.3.7-1.fc7.s390 requires libpq.so.4 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for i386 ---------------------------------------------------------- bind-sdb - 30:9.3.3-6.fc7.i386 requires libpq.so.4 cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.i386 requires libpq.so.4 freeradius-postgresql - 1.1.3-2.i386 requires libpq.so.4 libdbi-dbd-pgsql - 0.8.1a-1.2.2.i386 requires libpq.so.4 php-pgsql - 5.2.0-7.i386 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.i386 requires libpq.so.4 qt-PostgreSQL - 1:3.3.7-1.fc7.i386 requires libpq.so.4 Broken deps for x86_64 ---------------------------------------------------------- bind-sdb - 30:9.3.3-6.fc7.x86_64 requires libpq.so.4()(64bit) cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.x86_64 requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.x86_64 requires libpq.so.4()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.x86_64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.x86_64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.x86_64 requires libpq.so.4()(64bit) qt-PostgreSQL - 1:3.3.7-1.fc7.x86_64 requires libpq.so.4()(64bit) Broken deps for s390x ---------------------------------------------------------- bind-sdb - 30:9.3.3-6.fc7.s390x requires libpq.so.4()(64bit) cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.s390x requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.s390x requires libpq.so.4()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390x requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.s390x requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.s390x requires libpq.so.4()(64bit) qt-PostgreSQL - 1:3.3.7-1.fc7.s390x requires libpq.so.4()(64bit) Broken deps for ppc ---------------------------------------------------------- bind-sdb - 30:9.3.3-6.fc7.ppc requires libpq.so.4 cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.ppc requires libpq.so.4 freeradius-postgresql - 1.1.3-2.ppc requires libpq.so.4 libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc requires libpq.so.4 php-pgsql - 5.2.0-7.ppc requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.ppc requires libpq.so.4 qt-PostgreSQL - 1:3.3.7-1.fc7.ppc requires libpq.so.4 Broken deps for ppc64 ---------------------------------------------------------- bind-sdb - 30:9.3.3-6.fc7.ppc64 requires libpq.so.4()(64bit) cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.ppc64 requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.ppc64 requires libpq.so.4()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ppc64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ppc64 requires libpq.so.4()(64bit) qt-PostgreSQL - 1:3.3.7-1.fc7.ppc64 requires libpq.so.4()(64bit) From db-fedora at 3di.it Wed Dec 6 12:11:04 2006 From: db-fedora at 3di.it (Davide Bolcioni) Date: Wed, 06 Dec 2006 13:11:04 +0100 Subject: ideal config management framework [was: CPU Frequency Scaling] In-Reply-To: References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <4575CB74.6030200@andrei.myip.org> <20061205205430.GA26719@jadzia.bu.edu> Message-ID: <4576B358.3000106@3di.it> Thomas M Steenholdt wrote: > Also - Think of the additional error scenarios when init is gconf'ed. > The same complexity is added for everything else that adopts a registry > based configuration engine (since that engine has to be operational for > it to work in the first place) but may not be quite as aparrent. As I suggested in another message in the original thread, if this is changed, i.e. everything adopts a registry-based configuration *if one is found* but happily reads plain old configuration files from /etc if not, this problem can be made less aggravating. Personally, a scheme where (a) if the registry or policy daemon is not operational it is supplemented by the configuration in /etc, and (b) said configuration *overrides* unconditionally whatever the registry or policy daemon spits out, would offer the right mix of safety and functionality to give it a try on a non-production host, which seems the sweet spot for Fedora. The scheme might get fancy and differentiate between /etc/foo.conf which overrides unconditionally and /etc/fallback/foo.conf which is read if the registry or policy daemon is not available (and possibly overridden shortly thereafter). For production use, however, the registry or policy daemon *must* preserve comments and be manageable using whatever version control is in use at a site (not everybody uses CVS or SVN); very often, there is a reason behind setting something in a configuration and having to record it separately is just one of the many shortcomings of registry-based approaches. Just my $0.02, Davide Bolcioni -- There is no place like /home. From tmus at tmus.dk Wed Dec 6 13:42:16 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 06 Dec 2006 14:42:16 +0100 Subject: ideal config management framework [was: CPU Frequency Scaling] In-Reply-To: <4576B358.3000106@3di.it> References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <4575CB74.6030200@andrei.myip.org> <20061205205430.GA26719@jadzia.bu.edu> <4576B358.3000106@3di.it> Message-ID: Davide Bolcioni wrote: > Personally, a scheme where (a) if the registry or policy daemon is not > operational it is supplemented by the configuration in /etc, and (b) > said configuration *overrides* unconditionally whatever the registry or > policy daemon spits out, would offer the right mix of safety and > functionality to give it a try on a non-production host, which seems the > sweet spot for Fedora. The scheme might get fancy and differentiate > between /etc/foo.conf which overrides unconditionally and > /etc/fallback/foo.conf which is read if the registry or policy daemon is > not available (and possibly overridden shortly thereafter). If we must have a globally-universal configuration scheme, I'd prefer a libconfu (or such) library that can be used to reliably read, write and modify text based configuration files, keeping comments etc. within the files. Hand-configurations would be easy and well-supported and Apps/daemons could use the reading capabilities of the lib to read their config options. If somebody chose to create a frontend for app FOO, the read/write/modify capabilities of the lib could used to effectively and reliably implement that. /Thomas From mattdm at mattdm.org Wed Dec 6 13:47:18 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 6 Dec 2006 08:47:18 -0500 Subject: ideal config management framework [was: CPU Frequency Scaling] In-Reply-To: References: <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <4575CB74.6030200@andrei.myip.org> <20061205205430.GA26719@jadzia.bu.edu> <4576B358.3000106@3di.it> Message-ID: <20061206134718.GA32620@jadzia.bu.edu> On Wed, Dec 06, 2006 at 02:42:16PM +0100, Thomas M Steenholdt wrote: > If we must have a globally-universal configuration scheme, I'd prefer a > libconfu (or such) library that can be used to reliably read, write and > modify text based configuration files, keeping comments etc. within the > files. Hand-configurations would be easy and well-supported and Theoretically, I think gconf could actually support this if someone were interested in writing the backend. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tmus at tmus.dk Wed Dec 6 14:28:23 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 06 Dec 2006 15:28:23 +0100 Subject: ideal config management framework [was: CPU Frequency Scaling] In-Reply-To: <20061206134718.GA32620@jadzia.bu.edu> References: <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <4575CB74.6030200@andrei.myip.org> <20061205205430.GA26719@jadzia.bu.edu> <4576B358.3000106@3di.it> <20061206134718.GA32620@jadzia.bu.edu> Message-ID: Matthew Miller wrote: > Theoretically, I think gconf could actually support this if someone were > interested in writing the backend. > Of course that would still require a policy daemon to be running, which is one of the aspects I particularly do not like about the global registry based approach. However - A framework that looks and works similar to gconf could be written based on this idea. Perhaps this was what you meant? The difference would be that such a framework would not require a policy daemon to be running. /Thomas From mattdm at mattdm.org Wed Dec 6 14:29:26 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 6 Dec 2006 09:29:26 -0500 Subject: rawhide report: 20061205 changes In-Reply-To: <20061205123801.GB20160@redhat.com> References: <200612051127.kB5BR9kC025254@hs20-bc2-6.build.redhat.com> <20061205123801.GB20160@redhat.com> Message-ID: <20061206142926.GA2238@jadzia.bu.edu> On Tue, Dec 05, 2006 at 07:38:01AM -0500, Dave Jones wrote: > > kernel-2.6.19-1.2844.fc7 > This is totally busted, and will create initrd's with missing > modules due to broken dependancies. Avoid. So is it now okay with the updated mkinitrd, or is it still to be avoided? Thanks! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tibbs at math.uh.edu Wed Dec 6 16:29:20 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Dec 2006 10:29:20 -0600 Subject: Fw: Build Error (Job 22980): sblim-cmpi-base-1_5_4-7_fc7 on fedora-development-extras In-Reply-To: References: Message-ID: >>>>> "MH" == Mark Hamzy writes: MH> I think that when it tries to install tog-pegasus in the build MH> root, it is installing exim and exim wants libpq.so.4 which is in MH> postgres? More likely, something in the dependency chain requires either smtpdaemon or /usr/sbin/sendmail, and in the absence of any other information to go on yum's dependency resolver picks the package with the shortest name, that being "exim". Exim has busted dependencies at the moment owing to the unannounced bumping of Postgres which has broken various bits. It will be fixed relatively soon, as one of us will rebuild the package in a few days if the maintainer does not. MH> I don't want exim or postgres. But something does. You can temporarily add BuildRequires: postfix or something to force some other SMTP server. (Assuming that the other ones don't have similar dependency problems.) Welcome to rawhide. - J< From markmc at redhat.com Wed Dec 6 18:04:21 2006 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 06 Dec 2006 18:04:21 +0000 Subject: Package dependency analysis Message-ID: <1165428261.8880.19.camel@blaa> Hey, Some of us were talking previously about how to make it easier to keep down the general problem of dependency bloat - e.g. to spot when the "core" group is pulling in packages which it shouldn't. What kind of a tool would help? The workflow we thought would be best was: 1) Pull out the list of packages and their dependencies which you're interested (e.g. the "core" group, the kernel and its deps, the "desktop" group etc.) 2) Browse through the list of packages and identify anything that looks strange 3) For any package which looks strange, look through which packages pull it in and see if it makes sense So, I've hacked up a first-cut at a tool like this: http://people.redhat.com/markmc/depsgraph/ To build do e.g.: $> wget http://people.redhat.com/markmc/depsgraph/depsgraph-0.30.tar.bz2 $> rpmbuild -ta depsgraph-0.30.tar.bz2 $> rpm -Uhv /usr/src/redhat/RPMS/i386/depsgraph-0.30-1.i386.rpm To use, first set up a repo with what you want to look at: $> mkdir test-repo && cd test-repo $> repotrack -r core kernel && createrepo -p . Then look out for anything that you wouldn't expect in the repo and do: $> depsgraph file:///home/markmc/trash/trepo1 python See the attached screenshot showing this bug: https://bugzilla.redhat.com/203327 Any comments? Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: depsgraph.png Type: image/png Size: 60781 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Wed Dec 6 18:12:35 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 06 Dec 2006 19:12:35 +0100 Subject: Package dependency analysis In-Reply-To: <1165428261.8880.19.camel@blaa> References: <1165428261.8880.19.camel@blaa> Message-ID: <1165428756.30013.2.camel@rousalka.dyndns.org> Le mercredi 06 d?cembre 2006 ? 18:04 +0000, Mark McLoughlin a ?crit : > Any comments? The java group did something similar in 2005 http://article.gmane.org/gmane.linux.redhat.fedora.java/561 http://gnu.wildebeest.org/diary/index.php?p=97 Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From notting at redhat.com Wed Dec 6 18:16:16 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 6 Dec 2006 13:16:16 -0500 Subject: Package dependency analysis In-Reply-To: <1165428261.8880.19.camel@blaa> References: <1165428261.8880.19.camel@blaa> Message-ID: <20061206181616.GI30810@nostromo.devel.redhat.com> Mark McLoughlin (markmc at redhat.com) said: > https://bugzilla.redhat.com/203327 > > Any comments? It makes the X server a tad unhappy if you point it at glibc. :) Bill From markmc at redhat.com Wed Dec 6 18:29:31 2006 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 06 Dec 2006 18:29:31 +0000 Subject: Package dependency analysis In-Reply-To: <20061206181616.GI30810@nostromo.devel.redhat.com> References: <1165428261.8880.19.camel@blaa> <20061206181616.GI30810@nostromo.devel.redhat.com> Message-ID: <1165429771.8880.25.camel@blaa> On Wed, 2006-12-06 at 13:16 -0500, Bill Nottingham wrote: > Mark McLoughlin (markmc at redhat.com) said: > > https://bugzilla.redhat.com/203327 > > > > Any comments? > > It makes the X server a tad unhappy if you point it at glibc. :) It does indeed :-) Easy to just do a hacky fix to limit the number of packages to display ... it's not useful to look at what packages require glibc anyway. Patches welcome :) Cheers, Mark. From notting at redhat.com Wed Dec 6 18:30:28 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 6 Dec 2006 13:30:28 -0500 Subject: Package dependency analysis In-Reply-To: <1165429771.8880.25.camel@blaa> References: <1165428261.8880.19.camel@blaa> <20061206181616.GI30810@nostromo.devel.redhat.com> <1165429771.8880.25.camel@blaa> Message-ID: <20061206183028.GJ30810@nostromo.devel.redhat.com> Mark McLoughlin (markmc at redhat.com) said: > > It makes the X server a tad unhappy if you point it at glibc. :) > > It does indeed :-) Carl was suggesting trying to distill it down into a cairo testcase. Bill From markmc at redhat.com Wed Dec 6 18:35:10 2006 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 06 Dec 2006 18:35:10 +0000 Subject: Package dependency analysis In-Reply-To: <1165428756.30013.2.camel@rousalka.dyndns.org> References: <1165428261.8880.19.camel@blaa> <1165428756.30013.2.camel@rousalka.dyndns.org> Message-ID: <1165430110.8880.32.camel@blaa> On Wed, 2006-12-06 at 19:12 +0100, Nicolas Mailhot wrote: > Le mercredi 06 d?cembre 2006 ? 18:04 +0000, Mark McLoughlin a ?crit : > > Any comments? > > The java group did something similar in 2005 > http://article.gmane.org/gmane.linux.redhat.fedora.java/561 > http://gnu.wildebeest.org/diary/index.php?p=97 The idea isn't to create a big graph showing lots of dependencies ... that's been done before e.g.: http://adrian.gimp.org/rpm-graph/p0002338.jpg We want to make this stuff easier to digest. In this case, you identify likely suspect packages and then pull browse through sub-graphs that helps you figure out what caused that package to be pulled in. Cheers, Mark. From florin at andrei.myip.org Wed Dec 6 18:23:57 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 06 Dec 2006 10:23:57 -0800 Subject: ideal config management framework [was: CPU Frequency Scaling] In-Reply-To: References: <1165115008.2314.22.camel@averatec.charles.net> <1165155297.3165.9.camel@hughsie-laptop> <1165158403.2314.34.camel@averatec.charles.net> <1165250477.2484.18.camel@zelda.fubar.dk> <20061204164536.GA8329@jadzia.bu.edu> <1165251546.2484.28.camel@zelda.fubar.dk> <20061204170907.GA10166@jadzia.bu.edu> <4575CB74.6030200@andrei.myip.org> <20061205205430.GA26719@jadzia.bu.edu> Message-ID: <45770ABD.106@andrei.myip.org> Thomas M Steenholdt wrote: > Still, if a new config system should make configging things easier, it > would have to work all over the place. No apps should use other > config-methods and *swoosh*, we're windows (in the worst possible > sense). Not that I'm totally against adopting things that work fine on > other OS's, but the windows registry is a notorious mess. I think it's a mess for two reasons: 1. the information is structured in a highly non-intuitive way 2. the tools one can use to access and modify the registry are very primitive Both are easy to avoid. E.g., Elektra does a reasonable job at avoiding reason #1. http://elektra.sf.net/ > Also - Think of the additional error scenarios when init is gconf'ed. > The same complexity is added for everything else that adopts a registry > based configuration engine (since that engine has to be operational for > it to work in the first place) but may not be quite as aparrent. A very small part of the system might make sense to stay out of the registry. init seems to me a likely candidate. -- Florin Andrei http://florin.myip.org/ From florin at andrei.myip.org Wed Dec 6 18:30:48 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 06 Dec 2006 10:30:48 -0800 Subject: ideal config management framework [was: CPU Frequency Scaling] In-Reply-To: <1165397889.23106.93.camel@mccallum.corsepiu.local> References: <45763B58.3020301@andrei.myip.org> <20061206084932.GA2491@free.fr> <1165397889.23106.93.camel@mccallum.corsepiu.local> Message-ID: <45770C58.2040705@andrei.myip.org> Ralf Corsepius wrote: > Apart from apparent packaging issues (headers, static libs), which have > not been addressed so far, I am sensing a pretty large gap between > elektra's claims (I perceived their proponents to be very aggressively > marketing their package) and reality (Otherwise it probably already > would be in Fedora as requirement of another package ;) ). Part of that perception might be the fact that Elektra represents a fairly big change in The Way Things Are Done on a Linux system, so any way you look at it, it seems to be a very aggressive change. I agree that this is not something to be treated lightly. -- Florin Andrei http://florin.myip.org/ From linux_4ever at yahoo.com Wed Dec 6 20:15:28 2006 From: linux_4ever at yahoo.com (Steve G) Date: Wed, 6 Dec 2006 12:15:28 -0800 (PST) Subject: Package dependency analysis In-Reply-To: <1165430110.8880.32.camel@blaa> Message-ID: <520242.67069.qm@web51501.mail.yahoo.com> >We want to make this stuff easier to digest. I wrote one of these about 3 years ago, too. What I did to make it easier to use is create 3 views, show a package's dependencies, show what depends on that package, and both. For example, this is the dependencies required to make mkinitrd: http://www.web-insights.net/rookery/mkinitrd.dep.gz I'd also note that rpmgraph is shipped with FC for quite a while. -Steve ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com From dlutter at redhat.com Wed Dec 6 20:16:55 2006 From: dlutter at redhat.com (David Lutterkort) Date: Wed, 06 Dec 2006 12:16:55 -0800 Subject: Package dependency analysis In-Reply-To: <1165428261.8880.19.camel@blaa> References: <1165428261.8880.19.camel@blaa> Message-ID: <1165436216.6541.0.camel@localhost.localdomain> On Wed, 2006-12-06 at 18:04 +0000, Mark McLoughlin wrote: > Any comments? I am not sure that graphical repesentations of dependencies are all that useful. I'd rather have a (GUI based) tool that is focused on answering specific questions; for example, * given a set of packages/groups, what is the package set that anaconda will install with that input (i.e. closure under dep solving) * given a set of packages/groups I, and its closure C, why is package X in C ? This might actually benefit from showing the full dependency path from the initial packages to the resolved set, though just highlighting the member(s) of I that cause X to end up in C might be enough * given the sets I and C and a specific package X in I, which packages in C are pulled in by X ? Which ones are pulled in just by X and which ones by X and other packages in I ? A really simple UI might just consist of two lists, one for I and one for C with behavior like * point tool at arbitrary number of repos and comps files * add/remove packages and groups to/from I and have C updated * selecting a package in I will highlight the packages in C that it causes to be pulled in (with some sort of distinction between pulled in exclusively by that package and pulled in by that package and others) * selecting a package in C will highlight the packages in I that cause that package to be pulled in. Add some sort of option to look at the full dependency chain between them. Having said all that, the graph looks very cool ;) David From buildsys at redhat.com Thu Dec 7 11:33:37 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 7 Dec 2006 06:33:37 -0500 Subject: rawhide report: 20061207 changes Message-ID: <200612071133.kB7BXbxw007284@hs20-bc2-6.build.redhat.com> Updated Packages: MySQL-python-1.2.1_p2-1 ----------------------- * Wed Dec 06 2006 Tom Lane 1.2.1_p2-1 - Update to 1.2.1_p2 autofs-1:5.0.1-0.rc2.32 ----------------------- * Thu Dec 07 2006 Ian Kent - 5.0.1-0.rc2.32 - remove ability to use multiple indirect mount entries in master map (bz 218616). bind-31:9.3.3-0.1.rc3.fc7 ------------------------- * Wed Dec 06 2006 Martin Stransky - 31:9.3.3-0.1.rc3 - added back an interval to restart - renamed package, it should meet the N-V-R criteria - fix for #216185: bind-chroot-admin able to change root mode 750 - added fix from #215997: incorrect permissions on dnszone.schema - added a notice to init script when /etc/named.conf doesn't exist (#216075) cairo-1.3.6-1.fc7 ----------------- * Wed Dec 06 2006 Matthias Clasen 1.3.6-1 - Update to 1.3.6 dev86-0.16.17-3.fc7 ------------------- * Tue Dec 05 2006 Jindrich Novy - 0.16.17-3 - make the dev86 spec less tragic -> use macros, don't conflict on multiarches, add URL, fix BuildRoot, fix rpmlint warnings eclipse-1:3.2.1-23.fc7 ---------------------- * Tue Nov 28 2006 Andrew Overholt 3.2.1-23 - Move back to ~/.eclipse for update site pending upstream comments. - Add patch to add platform to ~/.eclipse's platform.xml. This maintains user-installed plugins but allows us to remove the pre-configured platform.xml in the OSGi configuration area. gaim-2:2.0.0-0.27.beta5.fc7 --------------------------- * Wed Dec 06 2006 Warren Togami - 2:2.0.0-0.27.beta5 - Debian patch 12_gstreamer-cleanup, hopefully fixes #218070 * Tue Dec 05 2006 Warren Togami - 2:2.0.0-0.26.beta5 - Jabber SASL Authentication Crash (#217335) * Wed Nov 29 2006 Warren Togami - 2:2.0.0-0.25.beta5 - GTK File dialog blanked fix (#217768) glibc-2.5.90-11 --------------- * Tue Dec 05 2006 Jakub Jelinek 2.5.90-11 - allow suid apps to setenv NIS_PATH and incluence through that nis_list and nis_lookup (#209155) - fix ttyname and ttyname_r with invalid file descriptor (#218276) - cs_CZ LC_TIME fixes (#218438) - fix build with 2.6.19+ headers (#217723) gnupg-1.4.6-3 ------------- * Wed Dec 06 2006 Nalin Dahyabhai - 1.4.6-3 - rebuild * Wed Dec 06 2006 Nalin Dahyabhai - 1.4.6-2 - rebuild * Wed Dec 06 2006 Nalin Dahyabhai - 1.4.6-1 - update to 1.4.6, incorporating fixes for CVE-2006-6169 and CVE-2006-6235 hwdata-0.192-1 -------------- * Wed Dec 06 2006 Karsten Hopp 0.192-1 - update pci.ids - update usb.ids - add some Samsung monitors (Till Maas, #204459) libselinux-1.33.2-3.fc7 ----------------------- * Wed Dec 06 2006 Dan Walsh - 1.33.2-3 - Fix matchpathcon to lstat files m17n-db-1.3.3-43.fc7 -------------------- * Thu Dec 07 2006 Mayank Jain - Resolves: bug 218255 - Fixed ta-typewriter keymap. mrtg-2.15.0-1 ------------- * Wed Dec 06 2006 Miloslav Trmac - 2.15.0-1 - Update to mrtg-2.15.0 - Don't use Prereq: for /sbin/service - Use (sed -i) instead of perl to make the regexps more readable mutt-5:1.4.2.2-5.fc7 -------------------- * Wed Dec 06 2006 Miroslav Lichvar 5:1.4.2.2-5 - use correct fcc folder with IMAP (#217469) - don't require smtpdaemon, gettext openoffice.org-1:2.1.0-6.3 -------------------------- * Tue Dec 05 2006 Caolan McNamara - 1:2.1.0-6.3 - Resolves: rhbz#218412 crash on cancel from search view of file chooser policycoreutils-1.33.6-3.fc7 ---------------------------- * Wed Dec 06 2006 Dan Walsh 1.33.6-3 - Update po files Resolves: #216920 python-urlgrabber-2.9.9-4.fc7 ----------------------------- * Wed Dec 06 2006 Jeremy Katz - 2.9.9-4 - fix keepalive (#218268) selinux-policy-2.4.6-8.fc7 -------------------------- * Wed Dec 06 2006 Dan Walsh 2.4.6-8 - More Fixes polyinstatiation Resolves: #216184 * Wed Dec 06 2006 Dan Walsh 2.4.6-7 - More Fixes polyinstatiation - Fix handling of keyrings Resolves: #216184 shadow-utils-2:4.0.18.1-6.fc7 ----------------------------- * Wed Dec 06 2006 Peter Vrabec 2:4.0.18.1-6 - use MD5 encryption by default (#218629). udev-103-3 ---------- * Wed Dec 06 2006 Harald Hoyer - 103-3 - changed DRIVER to DRIVERS - Resolves: rhbz#218160 unixODBC-2.2.12-1.fc7 --------------------- * Wed Dec 06 2006 Tom Lane 2.2.12-1 - Update to unixODBC 2.2.12. - Add missing BuildPrereq for bison. Resolves: #190427 Broken deps for ia64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.ia64 requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.ia64 requires libpq.so.4()(64bit) gnome-volume-manager - 2.17.0-2.fc7.ia64 requires kernel >= 0:2.6 libdbi-dbd-pgsql - 0.8.1a-1.2.2.ia64 requires libpq.so.4()(64bit) pcmciautils - 014-5.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 php-pgsql - 5.2.0-7.ia64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ia64 requires libpq.so.4()(64bit) qt-PostgreSQL - 1:3.3.7-1.fc7.ia64 requires libpq.so.4()(64bit) systemtap - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ia64 requires kernel >= 0:2.6.9-11 Broken deps for i386 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.i386 requires libpq.so.4 freeradius-postgresql - 1.1.3-2.i386 requires libpq.so.4 libdbi-dbd-pgsql - 0.8.1a-1.2.2.i386 requires libpq.so.4 php-pgsql - 5.2.0-7.i386 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.i386 requires libpq.so.4 qt-PostgreSQL - 1:3.3.7-1.fc7.i386 requires libpq.so.4 Broken deps for s390 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.s390 requires libpq.so.4 freeradius-postgresql - 1.1.3-2.s390 requires libpq.so.4 libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390 requires libpq.so.4 php-pgsql - 5.2.0-7.s390 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.s390 requires libpq.so.4 qt-PostgreSQL - 1:3.3.7-1.fc7.s390 requires libpq.so.4 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ppc64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.ppc64 requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.ppc64 requires libpq.so.4()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ppc64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ppc64 requires libpq.so.4()(64bit) qt-PostgreSQL - 1:3.3.7-1.fc7.ppc64 requires libpq.so.4()(64bit) Broken deps for x86_64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.x86_64 requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.x86_64 requires libpq.so.4()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.x86_64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.x86_64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.x86_64 requires libpq.so.4()(64bit) qt-PostgreSQL - 1:3.3.7-1.fc7.x86_64 requires libpq.so.4()(64bit) Broken deps for ppc ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.ppc requires libpq.so.4 freeradius-postgresql - 1.1.3-2.ppc requires libpq.so.4 libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc requires libpq.so.4 php-pgsql - 5.2.0-7.ppc requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.ppc requires libpq.so.4 qt-PostgreSQL - 1:3.3.7-1.fc7.ppc requires libpq.so.4 Broken deps for s390x ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.s390x requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.s390x requires libpq.so.4()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390x requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.s390x requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.s390x requires libpq.so.4()(64bit) qt-PostgreSQL - 1:3.3.7-1.fc7.s390x requires libpq.so.4()(64bit) From seandarcy2 at gmail.com Thu Dec 7 15:01:34 2006 From: seandarcy2 at gmail.com (sean) Date: Thu, 07 Dec 2006 10:01:34 -0500 Subject: rawhide report: 20061205 changes In-Reply-To: <20061206142926.GA2238@jadzia.bu.edu> References: <200612051127.kB5BR9kC025254@hs20-bc2-6.build.redhat.com> <20061205123801.GB20160@redhat.com> <20061206142926.GA2238@jadzia.bu.edu> Message-ID: Matthew Miller wrote: > On Tue, Dec 05, 2006 at 07:38:01AM -0500, Dave Jones wrote: >> > kernel-2.6.19-1.2844.fc7 >> This is totally busted, and will create initrd's with missing >> modules due to broken dependancies. Avoid. > > So is it now okay with the updated mkinitrd, or is it still to be avoided? > Thanks! > ping If it is totally busted, shouldn't it be taken off the server? sean From dhollis at davehollis.com Thu Dec 7 18:59:52 2006 From: dhollis at davehollis.com (David Hollis) Date: Thu, 07 Dec 2006 18:59:52 +0000 Subject: wpa and fc6/7 In-Reply-To: <80d7e4090612041331y219cf398mc17bc5d00b57d1a9@mail.gmail.com> References: <3dd77c60612040001t4f813b5bn2c4e420fb2c59a9a@mail.gmail.com> <45748A25.2010908@redhat.com> <80d7e4090612041331y219cf398mc17bc5d00b57d1a9@mail.gmail.com> Message-ID: <1165517992.3195.19.camel@dhollis-lnx.sunera.com> On Mon, 2006-12-04 at 14:31 -0700, Stephen John Smoogen wrote: > > I had problems with it for the first 2 weeks after the release (WPA > would not work with my ipw3945 etc) . but what is currently on my > system is working great. [It was kind of interesting.. it started > working the day before Thanksgiving and has worked since then.] What I've found with ipw3945 is that even though you can build it against the in-kernel IEEE80211 stack (1.1.13), WPA doesn't work worth a darn. If you build it against the latest stack (1.2.15), everything works quite well. It would be real nice if Intel would get rid of the ipw3945d daemon - which apparently they are in the process of doing - just to make it so I don't have to have any hack-arounds for it. -- David Hollis From yanmin_zhang at linux.intel.com Fri Dec 8 04:46:22 2006 From: yanmin_zhang at linux.intel.com (Zhang, Yanmin) Date: Fri, 08 Dec 2006 12:46:22 +0800 Subject: unaligned access on ia64 Message-ID: <1165553182.15989.99.camel@ymzhang> There are many unaligned access reported by FedoraCore 6 on ia64. See the report at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202096. Because relocation entries might point to unaligned addresses, ld.so might cause unaligned access when accessing such addresses. Besides dmraid, other applications, including anaconda (python), also cause unaligned access, so it's better to fix it in glibc. I worked out a patch to fix it. The patch was also posted to the bug report. Could anybody provide comments? Thanks, Yanmin --- --- glibc-2.5-20061008T1257/sysdeps/ia64/dl-machine.h 2006-12-08 01:26:54.000000000 +0800 +++ glibc-2.5-20061008T1257_bak/sysdeps/ia64/dl-machine.h 2006-12-08 02:33:02.000000000 +0800 @@ -477,16 +477,25 @@ elf_machine_rela (struct link_map *map, can be skipped. */ #define ELF_MACHINE_REL_RELATIVE 1 +union ia64_unaligned_data { + Elf64_Addr l_addr; +} __attribute__ ((packed)); + auto inline void __attribute ((always_inline)) elf_machine_rela_relative (Elf64_Addr l_addr, const Elf64_Rela *reloc, void *const reloc_addr_arg) { - Elf64_Addr *const reloc_addr = reloc_addr_arg; /* ??? Ignore MSB and Instruction format for now. */ assert (ELF64_R_TYPE (reloc->r_info) == R_IA64_REL64LSB); - *reloc_addr += l_addr; + if (((long)reloc_addr_arg) & 0x7) { + union ia64_unaligned_data *const lpdata = reloc_addr_arg; + lpdata->l_addr += l_addr; + } else { + Elf64_Addr *const reloc_addr = reloc_addr_arg; + *reloc_addr += l_addr; + } } /* Perform a RELATIVE reloc on the .got entry that transfers to the .plt. */ From jspaleta at gmail.com Fri Dec 8 04:56:20 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 8 Dec 2006 04:56:20 +0000 Subject: Package dependency analysis In-Reply-To: <1165436216.6541.0.camel@localhost.localdomain> References: <1165428261.8880.19.camel@blaa> <1165436216.6541.0.camel@localhost.localdomain> Message-ID: <604aa7910612072056o1694db40m7fd5381d329dd633@mail.gmail.com> On 12/6/06, David Lutterkort wrote: > * given a set of packages/groups I, and its closure C, why is > package X in C ? This might actually benefit from showing the > full dependency path from the initial packages to the resolved > set, though just highlighting the member(s) of I that cause X to > end up in C might be enough I think you want a representation of the connectedness of all the members leading to X. You don't want to waste time hunting down how to remove a member M from the set C in an effort to prevent X from getting pulled into C, if that member M needed by a lot more than X. > * given the sets I and C and a specific package X in I, which > packages in C are pulled in by X ? Which ones are pulled in just > by X and which ones by X and other packages in I ? Again measures of the the associate subtrees around a vertex would be useful. Don't need a visual graph for that, just an associated weight on the member indicating the size, interconnectedness of its sub-tree. -jef"Still looking for a way to justify that semester studying Graph Theory in Budapest.. did i say study.. i meant drinking heavily."spaleta From buildsys at redhat.com Fri Dec 8 11:35:13 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Fri, 8 Dec 2006 06:35:13 -0500 Subject: rawhide report: 20061208 changes Message-ID: <200612081135.kB8BZDYx013668@hs20-bc2-6.build.redhat.com> Updated Packages: MySQL-python-1.2.1_p2-2 ----------------------- * Thu Dec 07 2006 Jeremy Katz - 1.2.1_p2-2 - rebuild for python 2.5 OpenIPMI-2.0.6-7.fc7 -------------------- * Thu Dec 07 2006 Jeremy Katz - 2.0.6-7 - rebuild for python 2.5 PyQt-3.17-2 ----------- * Thu Dec 07 2006 Jeremy Katz - 3.17-2 - rebuild for python 2.5 PyXML-0.8.4-5 ------------- * Thu Dec 07 2006 Jeremy Katz - 0.8.4-5 - rebuild against python 2.5 Pyrex-0:0.9.4-3.fc7 ------------------- * Thu Dec 07 2006 Jeremy Katz - 0:0.9.4-2 - rebuild against python 2.5 aqbanking-2.1.0-10 ------------------ * Thu Dec 07 2006 Jeremy Katz - 2.1.0-10 - rebuild for python 2.5 audit-1.3-4.fc7 --------------- * Wed Dec 06 2006 Jeremy Katz - 1.3-4 - rebuild against python 2.5 authconfig-5.3.12-2.fc7 ----------------------- * Wed Dec 06 2006 Jeremy Katz - 5.3.12-2 - rebuild against python 2.5 avahi-0.6.15-4.fc7 ------------------ * Wed Dec 06 2006 Jeremy Katz - 0.6.15-4 - rebuild against python 2.5 beagle-0.2.13-3.fc7 ------------------- * Wed Dec 06 2006 Jeremy Katz - 0.2.13-3 - rebuild for python 2.5 beecrypt-4.1.2-12 ----------------- * Wed Dec 06 2006 Jeremy Katz - 4.1.2-12 - rebuild against python 2.5 - follow python packaging guidelines cracklib-2.8.9-6 ---------------- * Thu Dec 07 2006 Jeremy Katz - 2.8.9-6 - rebuild against python 2.5 cups-1:1.2.7-6.fc7 ------------------ * Thu Dec 07 2006 Tim Waugh 1:1.2.7-6 - Fixed If-Modified-Since: handling in libcups (bug #217556, STR #2133). - Fixed extra EOF in pstops output (bug #216154, STR #2111). - Use upstream patch for STR #2121. dbus-python-0.70-8.fc7 ---------------------- * Wed Dec 06 2006 Jeremy Katz - 0.70-8 - rebuild against python 2.5 dogtail-0.6.0-2.fc7 ------------------- * Thu Dec 07 2006 Jeremy Katz - 0.6.0-2 - build for python 2.5 - BR python-devel * Wed Sep 13 2006 Zack Cerza - 0.6.0-1 - New upstream release. - Add Requires for xorg-x11-xinit. - Add Requires for gnome-python2-gconf. - Bump pyspi Requires. - Remove upstreamed patches. * Fri Aug 18 2006 Zack Cerza - 0.5.2-3 - Add Requires for xorg-x11-xinit. Closes: #203189. epiphany-2.17.3-3.fc7 --------------------- * Thu Dec 07 2006 Matthias Clasen - 2.17.3-3 - Fix Requires in -devel (#218863) * Thu Dec 07 2006 Jeremy Katz - 2.17.3-2 - rebuild for python 2.5 gamin-0.1.8-3.fc7 ----------------- * Thu Dec 07 2006 Jeremy Katz - 0.1.8-3 - rebuild for python 2.5 gedit-1:2.17.1-2.fc7 -------------------- * Thu Dec 07 2006 Jeremy Katz - 1:2.17.1-2 - rebuild for python 2.5 gnome-applets-1:2.16.2-3.fc7 ---------------------------- * Thu Dec 07 2006 Jeremy Katz - 1:2.16.2-3 - rebuild for python 2.5 gnome-bluetooth-0.8.0-2.fc7 --------------------------- * Thu Dec 07 2006 Jeremy Katz - 0.8.0-2 - rebuild for python 2.5 * Mon Nov 13 2006 Harald Hoyer - 0.8.0-1 - version 0.8.0 * Wed Jul 12 2006 Jesse Keating - 0.7.0-10.1 - rebuild gnome-games-1:2.17.3-2.fc7 -------------------------- * Thu Dec 07 2006 Jeremy Katz - 1:2.17.3-2 - rebuild for python 2.5 gnome-menus-2.17.2-2.fc7 ------------------------ * Thu Dec 07 2006 Jeremy Katz - 2.17.2-2 - rebuild for python 2.5 gnome-python2-2.16.2-4.fc7 -------------------------- * Thu Dec 07 2006 Jeremy Katz - 2.16.2-4 - rebuild for python 2.5 gnome-python2-desktop-2.17.1-2.fc7 ---------------------------------- * Thu Dec 07 2006 Jeremy Katz - 2.17.1-2 - rebuild for python 2.5 - BR gnome-python2-devel gnome-python2-extras-2.14.2-7.fc7 --------------------------------- * Thu Dec 07 2006 Jeremy Katz - 2.14.2-7 - rebuild for python 2.5 hplip-1.6.10-7.fc7 ------------------ * Thu Dec 07 2006 Jeremy Katz - 1.6.10-7 - rebuild against python 2.5 * Wed Dec 06 2006 Tim Waugh - Minor state fixes for out-of-paper patch. httpd-2.2.3-8 ------------- * Thu Dec 07 2006 Joe Orton 2.2.3-8 - fix path to instdso.sh in special.mk (#217677) - fix detection of links in "apachectl fullstatus" java-1.4.2-gcj-compat-0:1.4.2.0-40jpp.111 ----------------------------------------- * Thu Dec 07 2006 Jeremy Katz - 0:1.4.2.0-40jpp.111 - rebuild for python 2.5 * Tue Oct 10 2006 Thomas Fitzsimmons - Require gij binary explicitly. (208913) * Wed Sep 13 2006 Thomas Fitzsimmons - 0:1.4.2.0-40jpp.109 - Require gcj-dbtool for post and postun. (205103) kbd-1.12-20 ----------- * Thu Dec 07 2006 Miloslav Trmac - 1.12-20 - Document that setkeycodes doesn't affect USB keyboards and that the kernel doesn't provide the raw scan codes by default Resolves: #211803 kernel-2.6.18-1.2849.fc6 ------------------------ * Fri Nov 10 2006 Dave Jones - Xen grant table operations security fix. - Add sleep wakeup profiling patch. - Disable W1 (#195825) * Thu Nov 09 2006 Dave Jones - Change HZ to 1000 for increased accuracy. (Except in Xen, where it stays at 250 for now). - TTY locking fixes. - splice : Must fully check for FIFO - Fix potential NULL dereference in sys_move_pages - ISO9660 __find_get_block_slow() denial of service CVE-2006-5757 - Fix up oops in cramfs when encountering corrupt images. - E1000 suspend/resume fixes. - Set CIFS preferred IO size. (#214607) * Mon Nov 06 2006 Roland McGrath - New utrace patch: fix locking snafu crash on second engine attach. kudzu-1.2.64-2 -------------- * Thu Dec 07 2006 Jeremy Katz - 1.2.64-2 - rebuild for python 2.5 lcms-1.15-2 ----------- * Thu Dec 07 2006 Jeremy Katz - 1.15-2 - rebuild against python 2.5 * Wed Jul 12 2006 Jesse Keating - rebuild * Mon Feb 13 2006 Jesse Keating - 1.15-1.2.1 - rebump for build order issues during double-long bump libbtctl-0.8.2-2.fc7 -------------------- * Thu Dec 07 2006 Jeremy Katz - 0.8.2-2 - rebuild for python 2.5 libglade2-2.6.0-3.fc7 --------------------- * Fri Dec 08 2006 Matthias Clasen - 2.6.0-3 - Small spec file cleanups libgnomecanvas-2.14.0-5.fc7 --------------------------- * Thu Dec 07 2006 Matthias Clasen - 2.14.0-5 - Small spec file cleanups libgsf-1.14.3-2 --------------- * Thu Dec 07 2006 Jeremy Katz - 1.14.3-2 - rebuild for python 2.5 libieee1284-0.2.9-4 ------------------- * Thu Dec 07 2006 Jeremy Katz - 0.2.9-4 - rebuild against python 2.5 libselinux-1.33.2-4.fc7 ----------------------- * Thu Dec 07 2006 Jeremy Katz - 1.33.2-4 - rebuild against python 2.5 libsemanage-1.9.1-2 ------------------- * Thu Dec 07 2006 Jeremy Katz - 1.9.1-2 - rebuild against python 2.5 libuser-0.54.8-2 ---------------- * Thu Dec 07 2006 Jeremy Katz - 0.54.8-2 - rebuild against python2.5 - follow python packaging guidelines libvirt-0.1.9-2.fc7 ------------------- * Thu Dec 07 2006 Jeremy Katz - 0.1.9-2 - rebuild against python 2.5 libxml2-2.6.27-2 ---------------- * Thu Dec 07 2006 Jeremy Katz - 2.6.27-2 - rebuild against python 2.5 libxslt-1.1.19-2 ---------------- * Thu Dec 07 2006 Jeremy Katz - 1.1.19-2 - rebuild against python 2.5 m2crypto-0.16-7.fc7 ------------------- * Thu Dec 07 2006 Jeremy Katz - 0.16-7 - rebuild against python 2.5 mkinitrd-6.0.3-1 ---------------- * Thu Dec 07 2006 Jeremy Katz - 6.0.3-1 - build against arbitrary pythons and rebuild for python 2.5 mod_python-3.2.10-4 ------------------- * Thu Dec 07 2006 Jeremy Katz - 3.2.10-4 - rebuild against python 2.5 mx-2.0.6-3 ---------- * Thu Dec 07 2006 Jeremy Katz - 2.0.6-3 - rebuild against python 2.5 net-snmp-1:5.4-4.fc7 -------------------- * Thu Dec 07 2006 Radek Vok??l - 5.4-4 - fix rtnetlink.h/if_addr.h * Thu Dec 07 2006 Joe Orton - 5.4-3 - add Requires for tcp_wrappers-devel for -devel newt-0.52.4-2.fc7 ----------------- * Thu Dec 07 2006 Jeremy Katz - 0.52.4-2 - rebuild for python 2.5 notify-python-0.1.0-4.fc7 ------------------------- * Thu Dec 07 2006 Jeremy Katz - 0.1.0-4 - rebuild for python 2.5 openoffice.org-1:2.1.0-6.5 -------------------------- * Thu Dec 07 2006 Jeremy Katz - 1:2.1.0-6.5 - rebuild for python2.5 * Thu Dec 07 2006 Caolan McNamara - 1:2.1.0-6.4 - Resolves: rhbz#216094 openoffice.org-2.1.0.ooo72349.svx.scriptrange.patch - Resolves: rhbz#216094 openoffice.org-2.1.0.ooo72350.svx.showsizes.patch orca-2.17.3-2.fc7 ----------------- * Thu Dec 07 2006 Jeremy Katz - 2.17.3-2 - rebuild for python 2.5 perl-XML-LibXML-1.62001-2.fc7 ----------------------------- * Thu Dec 07 2006 Robin Norwood - 1.62001-2 - Rebuild * Sat Dec 02 2006 Robin Norwood - 1.62001 - Build latest version from CPAN: 1.62001 * Wed Jul 12 2006 Jesse Keating - 1.58-2.2.2.1 - rebuild pirut-1.2.9-2.fc7 ----------------- * Thu Dec 07 2006 Jeremy Katz - 1.2.9-2 - rebuild for python 2.5 pkgconfig-1:0.21-2.fc7 ---------------------- * Thu Dec 07 2006 Matthias Clasen - 1:0.21-2 - Small spec file cleanups planner-0.14.2-2.fc7 -------------------- * Thu Dec 07 2006 Jeremy Katz - 0.14.2-2 - rebuild for python 2.5 policycoreutils-1.33.6-4.fc7 ---------------------------- * Thu Dec 07 2006 Jeremy Katz - 1.33.6-4 - rebuild for python 2.5 postgresql-8.2.0-2.fc7 ---------------------- * Thu Dec 07 2006 Jeremy Katz - 8.2.0-2 - rebuild for python 2.5 pycairo-1.2.6-2.fc7 ------------------- * Thu Dec 07 2006 Jeremy Katz - 1.2.6-2 - rebuild against python 2.5 pychecker-0.8.17-2 ------------------ * Thu Dec 07 2006 Jeremy Katz - 0.8.17-2 - rebuild against python 2.5 pygobject2-2.12.3-2.fc7 ----------------------- * Thu Dec 07 2006 Jeremy Katz - 2.12.3-2 - rebuild against python 2.5 pygtk2-2.10.3-6.fc7 ------------------- * Thu Dec 07 2006 Jeremy Katz - 2.10.3-6 - rebuild for python 2.5 pykickstart-0.42-2.fc7 ---------------------- * Thu Dec 07 2006 Jeremy Katz - 0.42-2 - rebuild against python 2.5 pyorbit-2.14.1-2 ---------------- * Thu Dec 07 2006 Jeremy Katz - 2.14.1-2 - rebuild for python 2.5 pyparted-1.8.1-3.fc7 -------------------- * Thu Dec 07 2006 Jeremy Katz - 1.8.1-3 - rebuild for python 2.5 pyspi-0.6.1-2.fc7 ----------------- * Thu Dec 07 2006 Jeremy Katz - 0.6.1-2 - rebuild for python 2.5 python-2.5-2.fc7 ---------------- * Wed Dec 06 2006 Jeremy Katz - 2.5.3-2 - disable installation of .egg-info files for now * Tue Dec 05 2006 Jeremy Katz - support db 4.5 - obsolete python-elementtree; since it requires some code tweaks, don't provide it - obsolete old python-sqlite; provide the version that's actually included * Mon Oct 30 2006 Jeremy Katz - fix _md5 and _sha modules (Robert Sheck) - no longer provide optik compat; it's been a couple of years now - no longer provide the old shm module; if this is still needed, let's build it separately - no longer provide japanese codecs; should be a separate package python-ldap-0:2.2.0-3 --------------------- * Thu Dec 07 2006 Jeremy Katz - 0:2.2.0-3 - rebuild against python 2.5 * Wed Jul 12 2006 Jesse Keating - rebuild * Wed May 17 2006 Matthew Barnes - 2.2.0-2 - Put back the epoch line... happy beehive? python-numeric-24.2-3 --------------------- * Thu Dec 07 2006 Jeremy Katz - 24.2-3 - rebuild against python 2.5 python-pyblock-0.27-1 --------------------- * Thu Dec 07 2006 Jeremy Katz - 0.27-1 - fix build for other python versions, build against python 2.5 - fix for Py_ssize_t changes in python 2.5 * Fri Oct 20 2006 Peter Jones - 0.25-1 - fix refcounting of map names and partition building for new maps (#210412) - fix naming so device names on a single controller are in LUN order * Fri Sep 29 2006 Peter Jones - 0.24-1 - add block.load() to load specific bdevid probes instead of always doing loadAll() (#208423) - make block.getMPaths() return a sorted list (#208337, #208431) python-urlgrabber-2.9.9-5.fc7 ----------------------------- * Wed Dec 06 2006 Jeremy Katz - 2.9.9-5 - rebuild for python 2.5 python-virtinst-0.98.0-2 ------------------------ * Thu Dec 07 2006 Jeremy Katz - 0.98.0-2 - rebuild for python 2.5 pyxf86config-0.3.31-4.fc7 ------------------------- * Thu Dec 07 2006 Jeremy Katz - 0.3.31-4 - rebuild against python 2.5 qt-1:3.3.7-2.fc7 ---------------- * Wed Dec 06 2006 Than Ngo - 1:3.3.7-2.fc7 - Resolves: bz#214371, bn_IN font rendering - Resolves: bz#217657, ml_IN issue with cursor position - Resolves: bz#217638, regression bug in qt - Resolves: bz#209974, Vowel position set properly - Resolves: bz#214570, Rendering is not fine for 'RA' 09B0 rhpl-0.196-1 ------------ * Thu Dec 07 2006 Jeremy Katz - 0.196-1 - fix build with new gettext - simplify russian keyboard choices (clumens, #218264) - build against python 2.5 * Thu Nov 30 2006 Paul Nasrat - 0.195-1 - Add Maple support (#217145) rhpxl-0.41-2.fc7 ---------------- * Thu Dec 07 2006 Jeremy Katz - 0.41-2 - rebuild against python 2.5 rhythmbox-0.9.6-4.fc7 --------------------- * Thu Dec 07 2006 Jeremy Katz - 0.9.6-4 - rebuild for python 2.5 rpm-4.4.2-37.fc7 ---------------- * Wed Dec 06 2006 Jeremy Katz - 4.4.2-37 - rebuild for python 2.5 setroubleshoot-1.8.5-2.fc7 -------------------------- * Thu Dec 07 2006 Jeremy Katz - 1.8.5-2 - rebuild for python 2.5 - doesn't actually use python-elementtree anymore sip-4.5-2 --------- * Thu Dec 07 2006 Jeremy Katz - 4.5-2 - rebuild against python 2.5 - cleanups for python packaging guidelines system-config-printer-0.7.41-2.fc7 ---------------------------------- * Thu Dec 07 2006 Jeremy Katz - 0.7.41-2 - build against python 2.5 * Thu Dec 07 2006 Tim Waugh 0.7.41-1 - Updated pycups to 1.9.16. - 0.7.41: - Reconnect smoothly after uploading new configuration. - Update lpoptions when setting default printer if it conflicts with the new setting (bug #217395). - Fixed typo in show_HTTP_Error (bug #217537). - Don't pre-select make and model when not discoverable for chosen device (bug #217518). - Set Forward button sensitive on Device screen in new-printer dialog (bug #217515). - Keep Server Settings selected after applying changes if it was selected before. - Set Connecting dialog transient for main window. - Center Connecting dialog on parent. - Optional 'reason' argument for cupshelpers.Printer.setEnabled. - Describe devices that have no optional parameters. * Thu Nov 30 2006 Tim Waugh - Provide pycups feature. system-config-soundcard-2.0.5-3.fc7 ----------------------------------- * Thu Dec 07 2006 Martin Stransky 2.0.5-3 - removed unused code (#218389) - hide tabs if only one sound device is detected (#208411) vim-2:7.0.168-2 --------------- * Thu Dec 07 2006 Jeremy Katz - rebuild for python 2.5 virt-manager-0.2.6-2.fc7 ------------------------ * Thu Dec 07 2006 Jeremy Katz - 0.2.6-%{extra_release}}} - rebuild for python 2.5 vte-0.15.0-2.fc7 ---------------- * Thu Dec 07 2006 Jeremy Katz - 0.15.0-2 - rebuild for python 2.5 wget-1.10.2-9.fc7 ----------------- * Thu Dec 07 2006 Karsten Hopp 1.10.2-9 - add distflag, rebuild * Thu Dec 07 2006 Karsten Hopp 1.10.2-8 - Resolves: #218211 fix double free corruption wireshark-0.99.4-5.fc7 ---------------------- * Thu Dec 07 2006 Jeremy Katz - 0.99.4-5 - rebuild for python 2.5 xterm-223-1.fc7 --------------- * Thu Dec 07 2006 Miroslav Lichvar 223-1 - update to 223 yum-3.0.1-3.fc7 --------------- * Wed Dec 06 2006 Jeremy Katz - 3.0.1-3 - fixes to work with python 2.5 yum-metadata-parser-1.0-9.fc7 ----------------------------- * Wed Dec 06 2006 Jeremy Katz - 1.0-9 - rebuild for python 2.5, support new sqlite Broken deps for i386 ---------------------------------------------------------- alacarte - 0.10.1-1.fc7.noarch requires python(abi) = 0:2.4 alacarte - 0.10.1-1.fc7.noarch requires /usr/bin/python2.4 alchemist - 1.0.36-1.2.2.i386 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.i386 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.i386 requires libpq.so.4 freeradius-postgresql - 1.1.3-2.i386 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.i386 requires libpython2.4.so.1.0 libdbi-dbd-pgsql - 0.8.1a-1.2.2.i386 requires libpq.so.4 php-pgsql - 5.2.0-7.i386 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.i386 requires libpq.so.4 pyOpenSSL - 0.6-1.p24.7.2.2.i386 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.i386 requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.i386 requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.i386 requires python(abi) = 0:2.4 subversion - 1.4.2-3.i386 requires python(abi) = 0:2.4 xen - 3.0.3-1.i386 requires python(abi) = 0:2.4 Broken deps for s390 ---------------------------------------------------------- alacarte - 0.10.1-1.fc7.noarch requires python(abi) = 0:2.4 alacarte - 0.10.1-1.fc7.noarch requires /usr/bin/python2.4 alchemist - 1.0.36-1.2.2.s390 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.s390 requires libpq.so.4 freeradius-postgresql - 1.1.3-2.s390 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.s390 requires libpython2.4.so.1.0 libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390 requires libpq.so.4 php-pgsql - 5.2.0-7.s390 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.s390 requires libpq.so.4 pyOpenSSL - 0.6-1.p24.7.2.2.s390 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.s390 requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.s390 requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.s390 requires python(abi) = 0:2.4 subversion - 1.4.2-3.s390 requires python(abi) = 0:2.4 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- alacarte - 0.10.1-1.fc7.noarch requires python(abi) = 0:2.4 alacarte - 0.10.1-1.fc7.noarch requires /usr/bin/python2.4 alchemist - 1.0.36-1.2.2.ia64 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ia64 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.ia64 requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.ia64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ia64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ia64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ia64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ia64 requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.ia64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ia64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ia64 requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.ia64 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.ia64 requires python(abi) = 0:2.4 python-elementtree - 1.2.6-5.ia64 requires python-abi = 0:2.4 python-sqlite - 1.1.7-1.2.1.ia64 requires python(abi) = 0:2.4 subversion - 1.4.2-3.ia64 requires python(abi) = 0:2.4 xen - 3.0.3-1.ia64 requires python(abi) = 0:2.4 Broken deps for x86_64 ---------------------------------------------------------- alacarte - 0.10.1-1.fc7.noarch requires /usr/bin/python2.4 alacarte - 0.10.1-1.fc7.noarch requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.x86_64 requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.x86_64 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.i386 requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.i386 requires python-abi = 0:2.4 cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.x86_64 requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.x86_64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.x86_64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.x86_64 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.x86_64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.x86_64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.x86_64 requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.x86_64 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.x86_64 requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.x86_64 requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.x86_64 requires python(abi) = 0:2.4 subversion - 1.4.2-3.i386 requires python(abi) = 0:2.4 subversion - 1.4.2-3.x86_64 requires python(abi) = 0:2.4 xen - 3.0.3-1.x86_64 requires python(abi) = 0:2.4 Broken deps for ppc64 ---------------------------------------------------------- alacarte - 0.10.1-1.fc7.noarch requires python(abi) = 0:2.4 alacarte - 0.10.1-1.fc7.noarch requires /usr/bin/python2.4 alchemist - 1.0.36-1.2.2.ppc64 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ppc64 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.ppc64 requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.ppc64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ppc64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ppc64 requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ppc64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ppc64 requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.ppc64 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.ppc64 requires python(abi) = 0:2.4 python-elementtree - 1.2.6-5.ppc64 requires python-abi = 0:2.4 python-sqlite - 1.1.7-1.2.1.ppc64 requires python(abi) = 0:2.4 subversion - 1.4.2-3.ppc64 requires python(abi) = 0:2.4 Broken deps for ppc ---------------------------------------------------------- alacarte - 0.10.1-1.fc7.noarch requires python(abi) = 0:2.4 alacarte - 0.10.1-1.fc7.noarch requires /usr/bin/python2.4 alchemist - 1.0.36-1.2.2.ppc requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ppc requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.ppc requires libpq.so.4 freeradius-postgresql - 1.1.3-2.ppc requires libpq.so.4 kdebindings - 3.5.5-1.fc7.ppc requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.ppc requires libpython2.4.so.1.0 libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc requires libpq.so.4 php-pgsql - 5.2.0-7.ppc requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.ppc requires libpq.so.4 pyOpenSSL - 0.6-1.p24.7.2.2.ppc requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.ppc requires python(abi) = 0:2.4 python-elementtree - 1.2.6-5.ppc requires python-abi = 0:2.4 python-sqlite - 1.1.7-1.2.1.ppc requires python(abi) = 0:2.4 subversion - 1.4.2-3.ppc requires python(abi) = 0:2.4 Broken deps for s390x ---------------------------------------------------------- alacarte - 0.10.1-1.fc7.noarch requires python(abi) = 0:2.4 alacarte - 0.10.1-1.fc7.noarch requires /usr/bin/python2.4 alchemist - 1.0.36-1.2.2.s390x requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390x requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.s390x requires libpq.so.4()(64bit) freeradius-postgresql - 1.1.3-2.s390x requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.s390x requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390x requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeedu - 3.5.5-0.1.fc6.s390x requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.s390x requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390x requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.s390x requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.s390x requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.s390x requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.s390x requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.s390x requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.s390x requires python(abi) = 0:2.4 subversion - 1.4.2-3.s390x requires python(abi) = 0:2.4 subversion - 1.4.2-3.s390 requires python(abi) = 0:2.4 From sdl.web at gmail.com Fri Dec 8 13:25:52 2006 From: sdl.web at gmail.com (Leo) Date: Fri, 08 Dec 2006 13:25:52 +0000 Subject: rawhide report: 20061208 changes References: <200612081135.kB8BZDYx013668@hs20-bc2-6.build.redhat.com> Message-ID: On FRI, 8 DEC 2006, buildsys wrote: > python-numeric-24.2-3 > --------------------- > * Thu Dec 07 2006 Jeremy Katz - 24.2-3 > - rebuild against python 2.5 > >From http://numpy.scipy.org/: "Maintenance has ceased for Numeric, and users should transisition to NumPy as quickly as possible." Shouldn't we move to python-numpy which is already in extras? -- Leo From fedora at camperquake.de Fri Dec 8 15:06:51 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 8 Dec 2006 16:06:51 +0100 Subject: Xen under vmware In-Reply-To: <20061204170031.357d7e9a@banea.int.addix.net> References: <20061204170031.357d7e9a@banea.int.addix.net> Message-ID: <20061208160651.7fdd63c5@banea.int.addix.net> Hi. On Mon, 4 Dec 2006 17:00:31 +0100, Ralf Ertzinger wrote: > Is there a general problem with running a xen enabled system in a > vmware virtual machine? I'm losing all network connection from dom0 > as soon as network-bridge does it's weird magic, and I can not figure > out why. For some obscure reason the solution for this is to make the vmnet* device nodes writable to the user running the virtual machine. Strange but true. From michel.salim at gmail.com Fri Dec 8 21:50:06 2006 From: michel.salim at gmail.com (Michel Salim) Date: Fri, 8 Dec 2006 16:50:06 -0500 Subject: wpa and fc6/7 In-Reply-To: <1165517992.3195.19.camel@dhollis-lnx.sunera.com> References: <3dd77c60612040001t4f813b5bn2c4e420fb2c59a9a@mail.gmail.com> <45748A25.2010908@redhat.com> <80d7e4090612041331y219cf398mc17bc5d00b57d1a9@mail.gmail.com> <1165517992.3195.19.camel@dhollis-lnx.sunera.com> Message-ID: <883cfe6d0612081350i66aa7f4dqe040ccf500509ba6@mail.gmail.com> 2006/12/7, David Hollis : > On Mon, 2006-12-04 at 14:31 -0700, Stephen John Smoogen wrote: > > > > > I had problems with it for the first 2 weeks after the release (WPA > > would not work with my ipw3945 etc) . but what is currently on my > > system is working great. [It was kind of interesting.. it started > > working the day before Thanksgiving and has worked since then.] > > What I've found with ipw3945 is that even though you can build it > against the in-kernel IEEE80211 stack (1.1.13), WPA doesn't work worth a > darn. If you build it against the latest stack (1.2.15), everything > works quite well. It would be real nice if Intel would get rid of the > ipw3945d daemon - which apparently they are in the process of doing - > just to make it so I don't have to have any hack-arounds for it. > How much difference did it make? I ended up turning off WPA on my wireless router because the router would freeze every few hours. The only problem I noticed on the laptop side is that it takes a long time to acquire a network address using DHCP, and sometimes I have to tell NetworkManager to reconnect several times. This is using freshrpms' ipw3945, which has a small patch that (as I understand it) sets the API version to 1.1.13 instead of 1.1.14 Regards, -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From bernie at develer.com Sat Dec 9 05:45:05 2006 From: bernie at develer.com (Bernardo Innocenti) Date: Sat, 09 Dec 2006 06:45:05 +0100 Subject: removing termcap In-Reply-To: References: <20061121174945.GC7982@localhost> <1164244207.32083.19.camel@localhost.localdomain> <20061127163751.GD29814@nostromo.devel.redhat.com> <1164655125.3195.2.camel@rousalka.dyndns.org> Message-ID: <457A4D61.7070105@develer.com> Benny Amorsen wrote: > Does anyone still mount /usr later? If so, why? Because my /usr is on RAID5 and I need to keep a small root filesystem (with /boot in it) on a RAID1 mirror in a small partition so grub can read from it. I prefer to keep the whole / on RAID1 because it makes it much easier to do recovery on the RAID5 partition without using the rescue mode of the installation CD. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From ghisha at email.it Sat Dec 9 09:25:47 2006 From: ghisha at email.it (Giandomenico De Tullio) Date: Sat, 09 Dec 2006 10:25:47 +0100 Subject: Eclipse on Linux Distributions eclipse.org project approved In-Reply-To: <1165104237.8532.18.camel@develop.unixkiste.local> References: <20061130222000.GM16792@redhat.com> <1165098980.8532.2.camel@develop.unixkiste.local> <45720F1B.2090907@fedoraproject.org> <1165104237.8532.18.camel@develop.unixkiste.local> Message-ID: <457A811B.3000700@email.it> Stefan Held ha scritto: >> incentive to negotiate such a agreement. However the jpackage.org folks > > [sheld at develop ~]$ rpm -qa | grep sun > java-1.5.0-sun-plugin-1.5.0.09-1jpp > java-1.5.0-sun-1.5.0.09-1jpp and java-1.5.0-sun-compat package: Description : This package provides JPackage compatibility symlinks and directories for the vendor's JDK rpm. From buildsys at redhat.com Sat Dec 9 10:21:20 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 9 Dec 2006 05:21:20 -0500 Subject: rawhide report: 20061209 changes Message-ID: <200612091021.kB9ALK6k019319@hs20-bc2-6.build.redhat.com> Updated Packages: ORBit2-2.14.3-4.fc7 ------------------- * Fri Dec 08 2006 Matthias Clasen - 2.14.3-4 - Handle ref leaks in the a11y stack more gracefully (#214795) alacarte-0.10.1-4.fc7 --------------------- * Sat Dec 09 2006 Matthias Clasen - 0.10.1-4 - try again * Wed Dec 06 2006 Jeremy Katz - 0.10.1-2 - build against python 2.5 at-spi-1.7.13-2.fc7 ------------------- * Sat Dec 09 2006 Matthias Clasen - 1.7.13-2 - Small spec file cleanups desktop-printing-0.19-19.fc7 ---------------------------- * Fri Dec 08 2006 Matthias Clasen - 0.19-19 - Fix remote job cancellation (#218945) freeradius-1.1.3-2.1 -------------------- * Fri Dec 08 2006 Thomas Woerner 1.1.3-2.1 - rebuild for new postgresql library version gnome-applets-1:2.16.2-4.fc7 ---------------------------- * Sat Dec 09 2006 Matthias Clasen - 1:2.16.2-4 - Small spec file cleanups gphoto2-2.3.0-1.fc7 ------------------- * Tue Dec 05 2006 Jindrich Novy 2.3.0-1 - update to 2.3.0 - enable lockdev - spec cleanup man-pages-2.43-2.fc7 -------------------- * Fri Dec 08 2006 Ivana Varekova 2.43-2 - remove old/wrong patches - fix tgkill/tkill man pages inconsistency * Fri Dec 01 2006 Ivana Varekova 2.43-1 - update to 2.43 - fix mount.2 man page (#211608) * Fri Oct 20 2006 Ivana Varekova 2.41-2 - fix mmap(2) man page policycoreutils-1.33.6-5.fc7 ---------------------------- * Fri Dec 08 2006 Dan Walsh 1.33.6-5 - Update po files - Fix newrole to open stdout and stderr rdrw so more will work on MLS machines Resolves: #216920 poppler-0.5.4-3.fc7 ------------------- * Fri Dec 08 2006 Rex Dieter - 0.5.4-3 - drop hard-wired: Req: gtk2 - --disable-static - enable qt wrapper - -devel: Requires: pkgconfig sed-4.1.5-6.fc7 --------------- * Fri Dec 08 2006 Petr Machata - 4.1.5-6 - Split confused patches "copy+symlink" and "relsymlink" into discrete "copy" and "symlink". setroubleshoot-1.8.7-1.fc7 -------------------------- * Fri Dec 08 2006 Dan Walsh - 1.8.7-1 - Additional Translations - Change avc_audit.py to allow it to analyze /var/log/messages * Mon Dec 04 2006 John Dennis - 1.8.6-1 - Resolves: bug# 218150, "If view is set to "hide delete" you cannot filter new entries" Actually, the bug was toggle cell renderer was connected to the base model instead of the model attached to the view, the sort model, this meant the toggle was occuring on the wrong row if the view was sorted differently than the base model. * Fri Dec 01 2006 John Dennis - 1.8.5-1 - fix bug, "could not convert path to a GtkTreePath" when database is initially empty, caused by last_selected_row == None subversion-1.4.2-5 ------------------ * Fri Dec 08 2006 Joe Orton 1.4.2-5 - fix use of python_sitearch * Thu Dec 07 2006 Jeremy Katz - 1.4.2-4 - rebuild against python 2.5 - follow python packaging guidelines wget-1.10.2-10.fc7 ------------------ * Fri Dec 08 2006 Karsten Hopp 1.10.2-10 - fix repeated downloads (Tomas Heinrich, #186195) xorg-x11-fonts-7.1-3.fc7 ------------------------ * Fri Dec 08 2006 Adam Jackson 7.1-3 - Create encodings.dir containing entries for both /usr/share/X11/fonts/encodings and /usr/share/X11/fonts/encodings/large (#209102). Broken deps for ia64 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.ia64 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ia64 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.ia64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ia64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ia64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ia64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ia64 requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.ia64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ia64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ia64 requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.ia64 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.ia64 requires python(abi) = 0:2.4 python-elementtree - 1.2.6-5.ia64 requires python-abi = 0:2.4 python-sqlite - 1.1.7-1.2.1.ia64 requires python(abi) = 0:2.4 xen - 3.0.3-1.ia64 requires python(abi) = 0:2.4 Broken deps for s390 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.s390 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.s390 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.s390 requires libpython2.4.so.1.0 libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390 requires libpq.so.4 php-pgsql - 5.2.0-7.s390 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.s390 requires libpq.so.4 pyOpenSSL - 0.6-1.p24.7.2.2.s390 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.s390 requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.s390 requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.s390 requires python(abi) = 0:2.4 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for i386 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.i386 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.i386 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.i386 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.i386 requires libpython2.4.so.1.0 libdbi-dbd-pgsql - 0.8.1a-1.2.2.i386 requires libpq.so.4 php-pgsql - 5.2.0-7.i386 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.i386 requires libpq.so.4 pyOpenSSL - 0.6-1.p24.7.2.2.i386 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.i386 requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.i386 requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.i386 requires python(abi) = 0:2.4 xen - 3.0.3-1.i386 requires python(abi) = 0:2.4 Broken deps for s390x ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.s390x requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390x requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.s390x requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.s390x requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390x requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeedu - 3.5.5-0.1.fc6.s390x requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.s390x requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390x requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.s390x requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.s390x requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.s390x requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.s390x requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.s390x requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.s390x requires python(abi) = 0:2.4 Broken deps for x86_64 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.x86_64 requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.x86_64 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.i386 requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.i386 requires python-abi = 0:2.4 cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.x86_64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.x86_64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.x86_64 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.x86_64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.x86_64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.x86_64 requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.x86_64 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.x86_64 requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.x86_64 requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.x86_64 requires python(abi) = 0:2.4 xen - 3.0.3-1.x86_64 requires python(abi) = 0:2.4 Broken deps for ppc64 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.ppc64 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ppc64 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.ppc64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ppc64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ppc64 requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ppc64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ppc64 requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.ppc64 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.ppc64 requires python(abi) = 0:2.4 python-elementtree - 1.2.6-5.ppc64 requires python-abi = 0:2.4 python-sqlite - 1.1.7-1.2.1.ppc64 requires python(abi) = 0:2.4 Broken deps for ppc ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.ppc requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ppc requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.ppc requires libpq.so.4 kdebindings - 3.5.5-1.fc7.ppc requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.ppc requires libpython2.4.so.1.0 libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc requires libpq.so.4 php-pgsql - 5.2.0-7.ppc requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.ppc requires libpq.so.4 pyOpenSSL - 0.6-1.p24.7.2.2.ppc requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.ppc requires python(abi) = 0:2.4 python-elementtree - 1.2.6-5.ppc requires python-abi = 0:2.4 python-sqlite - 1.1.7-1.2.1.ppc requires python(abi) = 0:2.4 From zrchrn at gmail.com Sat Dec 9 21:19:37 2006 From: zrchrn at gmail.com (Ahm ed) Date: Sat, 9 Dec 2006 16:19:37 -0500 Subject: yum Message-ID: I'm sure we have all heard about yum's "speed" issues, and yes it is annyoing, but fc6 went a long way to try to improve this speed. FC6 also saw yum become even more integrated into fedora (anaconda etc.). And all this development is good, and don't get me wrong I think yum is a fantastic tool with many wonderful features. However it's currently still lacking in some areas. 1. The GUI pup and pirut are pretty good programs but they are in some ways, a bit restricting. (for lack of a better word). I think that they should have more then just a progress bar. They should also output more information about say, the size of the files. How much (exactly) has been downloaded, and perhaps at what speed the downloads are going. 2. yum CLI Yum's CLI is much better than the gui tools at this point, and though it has gotten better there are some ways that it still needs to improve. The two areas I find most...upsetting involved the headers and dependency resolution. The headers are quite large....ok so maybe the biggest they get is around 400k (if I recall correctly) but when your on a slower connection, and your upgrading a lot of packages this can be quite annoying. Perhaps they header files could be placed in a different, smaller, format. Or an option to download all the header files could be included, and the headers can be updated then along with the metadata. The other, and in my opinion more important, area the yum cli should improve is in the resolution of dependencies, it should be faster. Currently yum seems just as good as apt-get or smart-pm or packman (arch linux's tool) at resolving dependecies. Yet all the other package manager do it much faster, almost instantly. I'm not sure why that is. It seems that it does each package one by one slowly. I think this may relate to the way the headers are stored. What makes these improvements to the cli so important is that if they are done they will benifit puplet and pirut, as well as anaconda's installation tool. And thus I view the ClI improvments to be very important. Please don't misunderstand, I'm not complaining. I'm stating areas that I (based solely on what I have gathered from my usage of fedora an yum) feel that yum can improve. A friend of mine along with myself plan to start looking at the yum code to try to see what we can do to improve yum, with our basic programming skills. However I decided it would be best to work directly with the devs on this one. My goal is to start a discussion on the issue to see what the fedora devs, especially those involved directly with yum, had to say about this. And perhaps we can help in this area. Thank you for your time. Ahmed G. p.s. This was the best place I could find to post this, if there is a better place to do this (a yum-devel list) please notify me and I will take this there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From icon at fedoraproject.org Sat Dec 9 22:04:55 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Sat, 9 Dec 2006 17:04:55 -0500 Subject: yum In-Reply-To: References: Message-ID: On 12/9/06, Ahm ed wrote: > Perhaps > they header files could be placed in a different, smaller, format. Or an > option to download all the header files could be included, and the headers > can be updated then along with the metadata. That's a neat idea -- we could place all headers into something like .hdr files inside the repodata directory, named something like name-epoch-version-release-arch.hdr. Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From vonbrand at inf.utfsm.cl Sat Dec 9 23:45:23 2006 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sat, 09 Dec 2006 20:45:23 -0300 Subject: rawhide report: 20061209 changes In-Reply-To: Your message of "Sat, 09 Dec 2006 05:21:20 CDT." <200612091021.kB9ALK6k019319@hs20-bc2-6.build.redhat.com> Message-ID: <200612092345.kB9NjNeV027149@laptop13.inf.utfsm.cl> buildsys at redhat.com wrote: [...] > Broken deps for ia64 > ---------------------------------------------------------- > alchemist - 1.0.36-1.2.2.ia64 requires python-abi = 0:2.4 > alchemist - 1.0.36-1.2.2.ia64 requires python(abi) = 0:2.4 Duplicate dependency? There are more similar ones... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 From jbowes at redhat.com Sun Dec 10 00:25:25 2006 From: jbowes at redhat.com (James Bowes) Date: Sat, 09 Dec 2006 19:25:25 -0500 Subject: yum In-Reply-To: References: Message-ID: <457B53F5.9020100@redhat.com> Hi: Ahm ed wrote: > p.s. This was the best place I could find to post this, if there is a > better place to do this (a yum-devel list) please notify me and I will > take this there. There is yum-devel at linux.duke.edu. See: https://lists.linux.duke.edu/mailman/listinfo/yum-devel -James From jbowes at redhat.com Sun Dec 10 00:26:36 2006 From: jbowes at redhat.com (James Bowes) Date: Sat, 09 Dec 2006 19:26:36 -0500 Subject: yum In-Reply-To: References: Message-ID: <457B543C.90703@redhat.com> Konstantin Ryabitsev wrote: > That's a neat idea -- we could place all headers into something like > .hdr files inside the repodata directory, named something like > name-epoch-version-release-arch.hdr. Isn't this how yum used to work, before using the repository metadata files? -James From jkeating at redhat.com Sun Dec 10 01:28:06 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 9 Dec 2006 20:28:06 -0500 Subject: rawhide report: 20061209 changes In-Reply-To: <200612092345.kB9NjNeV027149@laptop13.inf.utfsm.cl> References: <200612092345.kB9NjNeV027149@laptop13.inf.utfsm.cl> Message-ID: <200612092028.12212.jkeating@redhat.com> On Saturday 09 December 2006 18:45, Horst H. von Brand wrote: > > ??????alchemist - 1.0.36-1.2.2.ia64 requires python-abi = 0:2.4 > > ??????alchemist - 1.0.36-1.2.2.ia64 requires python(abi) = 0:2.4 > > Duplicate dependency? There are more similar ones... One is probably manual in the spec file, while the other one is generated automatically during the rpm build process. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedorauser101 at yahoo.com Sun Dec 10 03:04:46 2006 From: fedorauser101 at yahoo.com (fedora user 101) Date: Sat, 9 Dec 2006 19:04:46 -0800 (PST) Subject: openssh 4.5 Message-ID: <628074.77404.qm@web59007.mail.re1.yahoo.com> Why isn't rawhide using openssh 4.5? I realize that the patches for the sshd privilege separation issue are in the 4.3 rpm, but shouldn't rawhide be using the latest greatest? Thanks, --------------------------------- Have a burning question? Go to Yahoo! Answers and get answers from real people who know. -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at redhat.com Sun Dec 10 10:25:58 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sun, 10 Dec 2006 05:25:58 -0500 Subject: rawhide report: 20061210 changes Message-ID: <200612101025.kBAAPwwx013266@hs20-bc2-6.build.redhat.com> Updated Packages: autofs-1:5.0.1-0.rc2.33 ----------------------- * Sun Dec 10 2006 Ian Kent - 5.0.1-0.rc2.33 - expand export access checks to include missing syntax options. - make "-hosts" module try to be sensitive to exports list changes. evolution-2.9.3-1.fc7 --------------------- * Sat Dec 09 2006 Matthew Barnes - 2.9.3-1.fc7 - Update to 2.9.3 - Configure with scrollkeeper disabled. - Disable automake portability checking. - Ship our own icons from gnome-icon-theme. - BuildRequires: gnome-doc-utils >= 0.8.0 - Add patch for RH bug #215478 (Maildir and MH accounts). - Add patch for RH bug #215695 (crashes w/o mail accounts). - Add patch for RH bug #216537 (viewing attachments). - Add patch for RH bug #218801 (count unread messages first). - Add patch for GNOME bug #350253 (ship our own icons). - Add patch for GNOME bug #382431 (implicit function declaration). - Revise patch for GNOME bug #360946 (improved "about" dialog). - Remove patch for GNOME bug #357970 (fixed upstream). * Tue Nov 28 2006 Matthew Barnes - 2.9.2-3.fc7 - Add patch to port evolution conduits to pilot-link 0.12. - Add patch for RH bug #215466 (optional meeting participants). - Add patch for GNOME bug #373837 (use GtkFontButton). - Remove patch for GNOME bug #343331 (fixed upstream). * Tue Nov 07 2006 Matthew Barnes - 2.9.2-2.fc7 - Revise patch for RH bug #202751 and re-enable it. gnome-doc-utils-0.8.0-3.fc7 --------------------------- * Sat Dec 09 2006 Matthew Barnes - 0.8.0-3 - Add patch for GNOME bug #355521 (look for local m4 files). gtk2-2.10.6-7.fc7 ----------------- * Sat Dec 09 2006 Matthias Clasen - 2.10.6-7 - Fix error handling in pixbuf loaders (#218755) - Fix clipping of mnemonic underlines (#218615) - Give accessible names to message dialogs (#215472) - Fix a crash in the handling of invalid icon themes (#218247) - Make the print dialog work when the 'BrowseShortNames Off' cups option is used (#217220) * Sat Nov 25 2006 Matthias Clasen - 2.10.6-6 - Fix a recent-files related crash * Tue Nov 21 2006 Matthias Clasen - 2.10.6-5 - Change the search patch to check for beagle first libnotify-0.4.3-2.fc7 --------------------- * Sat Dec 09 2006 Matthias Clasen - 0.4.3-2 - Another typo (#214275) Broken deps for s390 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.s390 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.s390 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.s390 requires libpython2.4.so.1.0 libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390 requires libpq.so.4 php-pgsql - 5.2.0-7.s390 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.s390 requires libpq.so.4 pyOpenSSL - 0.6-1.p24.7.2.2.s390 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.s390 requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.s390 requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.s390 requires python(abi) = 0:2.4 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for s390x ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.s390x requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390x requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.s390x requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.s390x requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390x requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeedu - 3.5.5-0.1.fc6.s390x requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.s390x requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390x requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.s390x requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.s390x requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.s390x requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.s390x requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.s390x requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.s390x requires python(abi) = 0:2.4 Broken deps for i386 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.i386 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.i386 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.i386 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.i386 requires libpython2.4.so.1.0 libdbi-dbd-pgsql - 0.8.1a-1.2.2.i386 requires libpq.so.4 php-pgsql - 5.2.0-7.i386 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.i386 requires libpq.so.4 pyOpenSSL - 0.6-1.p24.7.2.2.i386 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.i386 requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.i386 requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.i386 requires python(abi) = 0:2.4 xen - 3.0.3-1.i386 requires python(abi) = 0:2.4 Broken deps for x86_64 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.x86_64 requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.x86_64 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.i386 requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.i386 requires python-abi = 0:2.4 cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.x86_64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.x86_64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.x86_64 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.x86_64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.x86_64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.x86_64 requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.x86_64 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.x86_64 requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.x86_64 requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.x86_64 requires python(abi) = 0:2.4 xen - 3.0.3-1.x86_64 requires python(abi) = 0:2.4 Broken deps for ppc64 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.ppc64 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ppc64 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.ppc64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ppc64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ppc64 requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ppc64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ppc64 requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.ppc64 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.ppc64 requires python(abi) = 0:2.4 python-elementtree - 1.2.6-5.ppc64 requires python-abi = 0:2.4 python-sqlite - 1.1.7-1.2.1.ppc64 requires python(abi) = 0:2.4 Broken deps for ppc ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.ppc requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ppc requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.ppc requires libpq.so.4 kdebindings - 3.5.5-1.fc7.ppc requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.ppc requires libpython2.4.so.1.0 libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc requires libpq.so.4 php-pgsql - 5.2.0-7.ppc requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.ppc requires libpq.so.4 pyOpenSSL - 0.6-1.p24.7.2.2.ppc requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.ppc requires python(abi) = 0:2.4 python-elementtree - 1.2.6-5.ppc requires python-abi = 0:2.4 python-sqlite - 1.1.7-1.2.1.ppc requires python(abi) = 0:2.4 Broken deps for ia64 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.ia64 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ia64 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.ia64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ia64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ia64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ia64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ia64 requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.ia64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ia64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ia64 requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.ia64 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.ia64 requires python(abi) = 0:2.4 python-elementtree - 1.2.6-5.ia64 requires python-abi = 0:2.4 python-sqlite - 1.1.7-1.2.1.ia64 requires python(abi) = 0:2.4 xen - 3.0.3-1.ia64 requires python(abi) = 0:2.4 From gauret at free.fr Sun Dec 10 17:14:56 2006 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 10 Dec 2006 18:14:56 +0100 Subject: Fedora planet RSS feed is broken Message-ID: Hey there, I'm not sure who to contact this about this issue : The Fedora Planet RSS feed seem to be broken : http://fedoraproject.org/people/rss20.xml It seems to be broken by a link in David Lutterkort's entry about "Kickstarting into puppet". Who should I contact to report this bug ? Thanks, Aur?lien. -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Backups are for wimps. Real men upload their work to an ftp server and have everybody mirror it." -- Linus Torvalds From michel.salim at gmail.com Sun Dec 10 19:51:37 2006 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 10 Dec 2006 14:51:37 -0500 Subject: Fedora planet RSS feed is broken In-Reply-To: References: Message-ID: <883cfe6d0612101151o164bf74dsea9265e690250e40@mail.gmail.com> 2006/12/10, Aurelien Bompard : > It seems to be broken by a link in David Lutterkort's entry > about "Kickstarting into puppet". > This has happened before, IIRC. It would be nice if each entry could be validated first before being added to the Planet page. -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From skvidal at linux.duke.edu Sun Dec 10 20:34:36 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 10 Dec 2006 15:34:36 -0500 Subject: Fedora planet RSS feed is broken In-Reply-To: References: Message-ID: <1165782876.15738.0.camel@cutter> On Sun, 2006-12-10 at 18:14 +0100, Aurelien Bompard wrote: > Hey there, > > I'm not sure who to contact this about this issue : The Fedora Planet RSS > feed seem to be broken : http://fedoraproject.org/people/rss20.xml > > It seems to be broken by a link in David Lutterkort's entry > about "Kickstarting into puppet". I don't see the brokenness. > > Who should I contact to report this bug ? fedora-admin ticketing system - it's in the wiki under the infrastructure pages. -sv From skvidal at linux.duke.edu Sun Dec 10 20:44:24 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 10 Dec 2006 15:44:24 -0500 Subject: Fedora planet RSS feed is broken In-Reply-To: <883cfe6d0612101151o164bf74dsea9265e690250e40@mail.gmail.com> References: <883cfe6d0612101151o164bf74dsea9265e690250e40@mail.gmail.com> Message-ID: <1165783464.15738.3.camel@cutter> On Sun, 2006-12-10 at 14:51 -0500, Michel Salim wrote: > 2006/12/10, Aurelien Bompard : > > > It seems to be broken by a link in David Lutterkort's entry > > about "Kickstarting into puppet". > > > This has happened before, IIRC. It would be nice if each entry could > be validated first before being added to the Planet page. It's using the planet code. If you would like to contribute the above as a mechanism I'm sure it would be looked at. -sv From pmr at pajato.com Sun Dec 10 21:04:56 2006 From: pmr at pajato.com (Paul Michael Reilly) Date: Sun, 10 Dec 2006 16:04:56 -0500 Subject: yum In-Reply-To: References: Message-ID: <457C7678.60304@pajato.com> Ahm ed wrote: > I'm sure we have all heard about yum's "speed" issues, and yes it is > annyoing, but fc6 went a long way to try to improve this speed. FC6 also > saw yum become even more integrated into fedora (anaconda etc.). And all > this development is good, and don't get me wrong I think yum is a > fantastic tool with many wonderful features. However it's currently > still lacking in some areas. Indisputable and I'm very glad that you raised the issue. > 1. The GUI > pup and pirut are pretty good programs but they are in some ways, a bit > restricting. (for lack of a better word). I think that they should have > more then just a progress bar. They should also output more information > about say, the size of the files. How much (exactly) has been > downloaded, and perhaps at what speed the downloads are going. I used these GUI tools for the first time this weekend and was very surprised to see how weak they are. They offer a tremendous opportunity for good hackers with some extra time to make some substantial improvements in the RPM experience. And before the author(s), their family, friends or secret admirers take offense, I applaud the fact that these tools were created. The creators of these tools did good. You creators have my thanks. Most definitely. > 2. yum CLI > Yum's CLI is much better than the gui tools at this point, and though it ... > 3. Shared access: I would like to see multiple processes allowed simultaneous access to repositories and the local RPM DB and only complain when the second process actually wants to modify the local RPM DB. For example, a User should be allowed to search repos for packages while an update is in progress (possibly using a shared library and/or cache to increase thoughput). Or query the local DB while updates are in progress. I could be convinced that a warning should be issued by readers when a writer process (one that has begun an install/update/erase transaction) is running so take what you get with a grain of salt. And as soon as I have some extra time I'll plunge right in. Which is exactly why I so appreciate those Saints who have made the effort to improve the Yum experience for the rest of us. :-) -pmr From lsof at nodata.co.uk Sun Dec 10 22:29:31 2006 From: lsof at nodata.co.uk (nodata) Date: Sun, 10 Dec 2006 23:29:31 +0100 Subject: yum In-Reply-To: <457C7678.60304@pajato.com> References: <457C7678.60304@pajato.com> Message-ID: <1165789771.13985.8.camel@sb-home.lan> [snip] > > Indisputable and I'm very glad that you raised the issue. > > > 1. The GUI > > pup and pirut are pretty good programs but they are in some ways, a bit > > restricting. (for lack of a better word). I think that they should have [snip] > > I used these GUI tools for the first time this weekend and was very > surprised to see how weak they are. [snip] I couldn't disagree more. Surely these GUI tools are aimed at people who don't care how big something is, or what dependencies something has, or any of that. Aren't they aimed at people who just "want to install a piece of software"? Don't lets turn a simple tool for adding software into something for people who already know about dependencies - those people can use the ever powerful command-line for that, or another tool. On a side note, I think even pup is overblown: A popup appears telling a user they have new updates? Why do they need to know? They click "Show updates". The list refreshes and they are shown the list of updates. Why do they need to know? They click apply updates, and a progress bar stays on screen showing the download. Why? The downloads finish and install, the user is notified again. Why? From ottohaliburton at tx.rr.com Sun Dec 10 22:44:06 2006 From: ottohaliburton at tx.rr.com (Otto Haliburton) Date: Sun, 10 Dec 2006 16:44:06 -0600 Subject: yum In-Reply-To: <1165789771.13985.8.camel@sb-home.lan> Message-ID: <00ab01c71cac$b3949400$0201a8c0@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of nodata > Sent: Sunday, December 10, 2006 4:30 PM > To: Development discussions related to Fedora Core > Subject: Re: yum > > [snip] > > > > Indisputable and I'm very glad that you raised the issue. > > > > > 1. The GUI > > > pup and pirut are pretty good programs but they are in some ways, a > bit > > > restricting. (for lack of a better word). I think that they should > have > > [snip] > > > > > I used these GUI tools for the first time this weekend and was very > > surprised to see how weak they are. > > [snip] > > I couldn't disagree more. Surely these GUI tools are aimed at people who > don't care how big something is, or what dependencies something has, or > any of that. Aren't they aimed at people who just "want to install a > piece of software"? Don't lets turn a simple tool for adding software > into something for people who already know about dependencies - those > people can use the ever powerful command-line for that, or another tool. > > On a side note, I think even pup is overblown: > > A popup appears telling a user they have new updates? Why do they need > to know? They click "Show updates". The list refreshes and they are > shown the list of updates. Why do they need to know? They click apply > updates, and a progress bar stays on screen showing the download. Why? > The downloads finish and install, the user is notified again. Why? Not all updates are acceptable for everyone system, and why shouldn't you be able to accept updates or refuse them?? Common courtesy if you ask me. > From chitlesh at fedoraproject.org Sun Dec 10 23:28:15 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Mon, 11 Dec 2006 00:28:15 +0100 Subject: Fedora planet RSS feed is broken In-Reply-To: References: Message-ID: <13dbfe4f0612101528s39e42544od52a77ef1dae9805@mail.gmail.com> On 12/10/06, Aurelien Bompard wrote: > Hey there, > > I'm not sure who to contact this about this issue : The Fedora Planet RSS > feed seem to be broken : http://fedoraproject.org/people/rss20.xml I confirm, it's broken: http://www.flickr.com/photo_zoom.gne?id=319002439&size=o chitlesh -- http://clunixchit.blogspot.com From emmanuel.seyman at club-internet.fr Sun Dec 10 23:40:46 2006 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Mon, 11 Dec 2006 00:40:46 +0100 Subject: Fedora planet RSS feed is broken In-Reply-To: <1165782876.15738.0.camel@cutter> References: <1165782876.15738.0.camel@cutter> Message-ID: <20061210234046.GB15045@orient.maison.lan> On Sun, Dec 10, 2006 at 03:34:36PM -0500, seth vidal wrote: > > I don't see the brokenness. I'm seeing errors using xmllint: [manu at orient ~]$ xmllint rss20.xml rss20.xml:647: parser error : EntityRef: expecting ';' http://watzmann.net/blog/index.php?title=kickstarting_into_puppet&more=1& ^ rss20.xml:647: parser error : EntityRef: expecting ';' http://watzmann.net/blog/index.php?title=kickstarting_into_puppet&more=1&c ^ rss20.xml:647: parser error : EntityRef: expecting ';' >http://watzmann.net/blog/index.php?title=kickstarting_into_puppet&more=1&c=1&tb ^ rss20.xml:647: parser error : EntityRef: expecting ';' ://watzmann.net/blog/index.php?title=kickstarting_into_puppet&more=1&c=1&tb=1&pb ^ Emmanuel From pemboa at gmail.com Mon Dec 11 00:08:53 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 10 Dec 2006 18:08:53 -0600 Subject: yum In-Reply-To: <1165789771.13985.8.camel@sb-home.lan> References: <457C7678.60304@pajato.com> <1165789771.13985.8.camel@sb-home.lan> Message-ID: <16de708d0612101608g11ab83es40f8c7dce79fd703@mail.gmail.com> On 12/10/06, nodata wrote: > [snip] > > > > Indisputable and I'm very glad that you raised the issue. > > > > > 1. The GUI > > > pup and pirut are pretty good programs but they are in some ways, a bit > > > restricting. (for lack of a better word). I think that they should have > > [snip] > > > > > I used these GUI tools for the first time this weekend and was very > > surprised to see how weak they are. > > [snip] > > I couldn't disagree more. Surely these GUI tools are aimed at people who > don't care how big something is, or what dependencies something has, or > any of that. Aren't they aimed at people who just "want to install a > piece of software"? Don't lets turn a simple tool for adding software > into something for people who already know about dependencies - those > people can use the ever powerful command-line for that, or another tool. I have to say, I agree with you. I've never used pirut except in Anaconda myself, and it seems to me that the GUI is for exactly the purpose you stated. I would hope these tools are even easier to use than _anything_ that exists on Windows - Maybe I should give them a try. Besides, there is already Yumex, and KYum, right? > On a side note, I think even pup is overblown: On that note, when do we KDE peeps get KYum? > A popup appears telling a user they have new updates? Why do they need > to know? If it didn't it would be malware. > They click "Show updates". The list refreshes and they are > shown the list of updates. Why do they need to know? Again, yes...if not it would be malware. > They click apply > updates, and a progress bar stays on screen showing the download. Why? Can the screen be hidden till completion? > The downloads finish and install, the user is notified again. Why? > They might have been waiting for the download to complete so that they could shutdown the machine. -- Fedora Core 6 and proud From kevin.kofler at chello.at Mon Dec 11 00:22:51 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 11 Dec 2006 00:22:51 +0000 (UTC) Subject: yum References: <457C7678.60304@pajato.com> <1165789771.13985.8.camel@sb-home.lan> <16de708d0612101608g11ab83es40f8c7dce79fd703@mail.gmail.com> Message-ID: Arthur Pemberton gmail.com> writes: > Besides, there is already Yumex, and KYum, right? Right, and Synaptic (apt-based) and the Smart GUI. Kevin Kofler From peter at thecodergeek.com Mon Dec 11 02:31:47 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 10 Dec 2006 18:31:47 -0800 Subject: yum In-Reply-To: <16de708d0612101608g11ab83es40f8c7dce79fd703@mail.gmail.com> References: <457C7678.60304@pajato.com> <1165789771.13985.8.camel@sb-home.lan> <16de708d0612101608g11ab83es40f8c7dce79fd703@mail.gmail.com> Message-ID: <1165804307.26647.3.camel@localhost> On Sun, 2006-12-10 at 18:08 -0600, Arthur Pemberton wrote: > Can the screen be hidden till completion? Ok, so what about the user's wanting to know what his system is doing? Without a simple "Downloading..." or "Installing/Updating..." message and its subsequent progress bar, the user will definitely end up wondering what on earth is consuming their downstream bandwidth and/or why their system has become somewhat unresponsive (CPU usage due to RPM installation). Also, with no feedback to the user, how does one know that clicking "Apply" actually did something? How does he know that the downloading/installing is completed and he can therefore safely shutdown or hibernate (etc.) his or her machine? -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- 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 pemboa at gmail.com Mon Dec 11 04:09:52 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 11 Dec 2006 22:09:52 +1800 Subject: yum In-Reply-To: <1165804307.26647.3.camel@localhost> References: <457C7678.60304@pajato.com> <1165789771.13985.8.camel@sb-home.lan> <16de708d0612101608g11ab83es40f8c7dce79fd703@mail.gmail.com> <1165804307.26647.3.camel@localhost> Message-ID: <16de708d0612102009k7547ad90yaefd0cf1adc6a116@mail.gmail.com> On 12/11/06, Peter Gordon wrote: > On Sun, 2006-12-10 at 18:08 -0600, Arthur Pemberton wrote: > > Can the screen be hidden till completion? > > Ok, so what about the user's wanting to know what his system is doing? > Without a simple "Downloading..." or "Installing/Updating..." message > and its subsequent progress bar, the user will definitely end up > wondering what on earth is consuming their downstream bandwidth and/or > why their system has become somewhat unresponsive (CPU usage due to RPM > installation). > > Also, with no feedback to the user, how does one know that clicking > "Apply" actually did something? How does he know that the > downloading/installing is completed and he can therefore safely shutdown > or hibernate (etc.) his or her machine? I agree with you - but why did you quote that statement? -- Fedora Core 6 and proud From buildsys at redhat.com Mon Dec 11 10:23:17 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 11 Dec 2006 05:23:17 -0500 Subject: rawhide report: 20061211 changes Message-ID: <200612111023.kBBANH4G018848@hs20-bc2-6.build.redhat.com> Updated Packages: audit-1.3.1-1.fc7 ----------------- * Sun Dec 10 2006 Steve Grubb 1.3.1-1 - Fix a couple parsing problems (#217952) - Add tgkill to S390* syscall tables (#218484) - Fix error messages in ausearch/aureport autofs-1:5.0.1-0.rc2.34 ----------------------- * Mon Dec 11 2006 Ian Kent - 5.0.1-0.rc2.34 - change mount "device" from "automount" to the map name. - check for buffer overflow in mount_afs.c. - replace tempnam with mkdtemp. bind-31:9.3.3-1.fc7 ------------------- * Sun Dec 10 2006 Martin Stransky - 31:9.3.3-1 - update to 9.3.3 final - fix for #219069: file included twice in src.rpm cpio-2.6-22.fc7 --------------- * Sun Dec 10 2006 Peter Vrabec 2.6-22 - fix rpmlint issue in spec file evince-0.6.1-2.fc7 ------------------ * Sun Dec 10 2006 Matthias Clasen - 0.6.1-2 - Fix an overflow in the PostScript backend (#217674, CVE-2006-5864) gcc-4.1.1-45 ------------ * Fri Dec 08 2006 Jakub Jelinek 4.1.1-45 - update from gcc-4_1-branch (-r119343:119654) - PRs c++/14329, c++/28284, c++/29632, c++/29728, c++/29729, c++/29730, c++/29733, c++/30022, libfortran/29810 - add protoize.1 and unprotoize.1 man pages (#188914) - fix RTL sharing problem in combine (#218603, PR rtl-optimization/27761) - additions to libgcj-src (Ben Konrath, PR libgcj/30110) glibc-2.5.90-12 --------------- * Sun Dec 10 2006 Jakub Jelinek 2.5.90-12 - fix hasmntopt (#218802) - fix setusershell and getusershell (#218782) - strtod fixes (BZ#3664, BZ#3673, BZ#3674) - fix memusage with realloc (x, 0) libuser-0.55-1 -------------- * Sun Dec 10 2006 Miloslav Trmac - 0.55-1 - Update to support the 64-bit API of Python 2.5 - Drop the quota library and Python module redhat-menus-7.8.9-1.fc7 ------------------------ * Sun Dec 10 2006 Ray Strode - 7.8.9-1 - Update to 7.8.9 ruby-1.8.5.2-1.fc7 ------------------ * Mon Dec 11 2006 Akira TAGOH - 1.8.5.2-1 - security fix release. sysklogd-1.4.1-42.fc7 --------------------- * Tue Dec 12 2006 Peter Vrabec 1.4.1-42 - fix IPv6 patch tar-2:1.15.1-22.fc7 ------------------- * Sun Dec 10 2006 Peter Vrabec 2:1.15.1-22 - fix some rpmlint spec file issues Broken deps for s390 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.s390 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.s390 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.s390 requires libpython2.4.so.1.0 libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390 requires libpq.so.4 php-pgsql - 5.2.0-7.s390 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.s390 requires libpq.so.4 pyOpenSSL - 0.6-1.p24.7.2.2.s390 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.s390 requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.s390 requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.s390 requires python(abi) = 0:2.4 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for i386 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.i386 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.i386 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.i386 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.i386 requires libpython2.4.so.1.0 libdbi-dbd-pgsql - 0.8.1a-1.2.2.i386 requires libpq.so.4 php-pgsql - 5.2.0-7.i386 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.i386 requires libpq.so.4 pyOpenSSL - 0.6-1.p24.7.2.2.i386 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.i386 requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.i386 requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.i386 requires python(abi) = 0:2.4 xen - 3.0.3-1.i386 requires python(abi) = 0:2.4 Broken deps for x86_64 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.i386 requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.i386 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.x86_64 requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.x86_64 requires python-abi = 0:2.4 cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.x86_64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.x86_64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.x86_64 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeedu - 3.5.5-0.1.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.x86_64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.x86_64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.x86_64 requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.x86_64 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.x86_64 requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.x86_64 requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.x86_64 requires python(abi) = 0:2.4 xen - 3.0.3-1.x86_64 requires python(abi) = 0:2.4 Broken deps for ppc ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.ppc requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ppc requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 dovecot - 1.0-0.1.rc7.fc6.ppc requires libpq.so.4 kdebindings - 3.5.5-1.fc7.ppc requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.ppc requires libpython2.4.so.1.0 libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc requires libpq.so.4 php-pgsql - 5.2.0-7.ppc requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.ppc requires libpq.so.4 pyOpenSSL - 0.6-1.p24.7.2.2.ppc requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.ppc requires python(abi) = 0:2.4 python-elementtree - 1.2.6-5.ppc requires python-abi = 0:2.4 python-sqlite - 1.1.7-1.2.1.ppc requires python(abi) = 0:2.4 Broken deps for ppc64 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.ppc64 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ppc64 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.ppc64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ppc64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ppc64 requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ppc64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ppc64 requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.ppc64 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.ppc64 requires python(abi) = 0:2.4 python-elementtree - 1.2.6-5.ppc64 requires python-abi = 0:2.4 python-sqlite - 1.1.7-1.2.1.ppc64 requires python(abi) = 0:2.4 Broken deps for ia64 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.ia64 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ia64 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.ia64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ia64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ia64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ia64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ia64 requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.ia64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ia64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ia64 requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.ia64 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.ia64 requires python(abi) = 0:2.4 python-elementtree - 1.2.6-5.ia64 requires python-abi = 0:2.4 python-sqlite - 1.1.7-1.2.1.ia64 requires python(abi) = 0:2.4 xen - 3.0.3-1.ia64 requires python(abi) = 0:2.4 Broken deps for s390x ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.s390x requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390x requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) dovecot - 1.0-0.1.rc7.fc6.s390x requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.s390x requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390x requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390x requires libpython2.4.so.1.0()(64bit) kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.s390x requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390x requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.s390x requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.s390x requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.s390x requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 python-elementtree - 1.2.6-5.s390x requires python-abi = 0:2.4 python-elementtree - 1.2.6-5.s390x requires python(abi) = 0:2.4 python-sqlite - 1.1.7-1.2.1.s390x requires python(abi) = 0:2.4 From buildsys at redhat.com Mon Dec 11 20:17:04 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 11 Dec 2006 15:17:04 -0500 Subject: rawhide report: 20061211 changes Message-ID: <200612112017.kBBKH44C022286@hs20-bc2-6.build.redhat.com> Removed package python-sqlite Removed package python-elementtree Updated Packages: audit-1.3.1-1.fc7 ----------------- * Sun Dec 10 2006 Steve Grubb 1.3.1-1 - Fix a couple parsing problems (#217952) - Add tgkill to S390* syscall tables (#218484) - Fix error messages in ausearch/aureport autofs-1:5.0.1-0.rc2.34 ----------------------- * Mon Dec 11 2006 Ian Kent - 5.0.1-0.rc2.34 - change mount "device" from "automount" to the map name. - check for buffer overflow in mount_afs.c. - replace tempnam with mkdtemp. bind-31:9.3.3-1.fc7 ------------------- * Sun Dec 10 2006 Martin Stransky - 31:9.3.3-1 - update to 9.3.3 final - fix for #219069: file included twice in src.rpm busybox-1:1.2.2-2.fc7 --------------------- * Sun Dec 10 2006 Ivana Varekova - 1:1.2.2-2 - enable ash cpio-2.6-22.fc7 --------------- * Sun Dec 10 2006 Peter Vrabec 2.6-22 - fix rpmlint issue in spec file dovecot-1.0-1.rc15.fc7 ---------------------- * Tue Dec 05 2006 Tomas Janousek - 1.0-1.rc15 - update to latest upstream, fixes a few bugs, plus a security vulnerability (#216508, CVE-2006-5973) * Tue Oct 10 2006 Petr Rockai - 1.0-0.3.rc7 - fix few inconsistencies in specfile, fixes #198940 * Wed Oct 04 2006 Petr Rockai - 1.0-0.2.rc7 - fix default paths in the example mkcert.sh to match configuration defaults (fixes #183151) evince-0.6.1-2.fc7 ------------------ * Sun Dec 10 2006 Matthias Clasen - 0.6.1-2 - Fix an overflow in the PostScript backend (#217674, CVE-2006-5864) gcc-4.1.1-45 ------------ * Fri Dec 08 2006 Jakub Jelinek 4.1.1-45 - update from gcc-4_1-branch (-r119343:119654) - PRs c++/14329, c++/28284, c++/29632, c++/29728, c++/29729, c++/29730, c++/29733, c++/30022, libfortran/29810 - add protoize.1 and unprotoize.1 man pages (#188914) - fix RTL sharing problem in combine (#218603, PR rtl-optimization/27761) - additions to libgcj-src (Ben Konrath, PR libgcj/30110) glibc-2.5.90-12 --------------- * Sun Dec 10 2006 Jakub Jelinek 2.5.90-12 - fix hasmntopt (#218802) - fix setusershell and getusershell (#218782) - strtod fixes (BZ#3664, BZ#3673, BZ#3674) - fix memusage with realloc (x, 0) gphoto2-2.3.0-2.fc7 ------------------- * Mon Dec 11 2006 Jindrich Novy 2.3.0-2 - don't ship docs in separate tarball, use the internal one iproute-2.6.18-5.fc7 -------------------- * Mon Dec 11 2006 Radek Vok??l - 2.6.18-5 - fix snapshot version iptraf-3.0.0-5.fc7 ------------------ * Mon Dec 11 2006 Marcela Maslanova - 3.0.0-5 - input traffic libuser-0.55-1 -------------- * Sun Dec 10 2006 Miloslav Trmac - 0.55-1 - Update to support the 64-bit API of Python 2.5 - Drop the quota library and Python module man-1.6e-1.fc7 -------------- * Mon Dec 11 2006 Ivana Varekova - 1.6e-1 - update to 1.6e * Thu Oct 26 2006 Ivana Varekova - 1.6d-3 - add MAKEWHATISDBUPDATES option (bug 210501) * Tue Oct 24 2006 Ivana Varekova - 1.6d-2 - makewhatis overlooks man pages with two dashes in SH line (bug 208216) ncurses-5.5-27.20061209.fc7 --------------------------- * Mon Dec 11 2006 Miroslav Lichvar 5.5-27.20061209 - update to patch 20061209 - strip large tables from shared libraries, reduce number of relocations - package utils linked with libncurses instead of libncursesw - package only wide-character headers python-2.5-3.fc7 ---------------- * Mon Dec 11 2006 Jeremy Katz - 2.5.3-3 - fix atexit traceback with failed syslog logger (#218214) - split libpython into python-libs subpackage for multilib apps embedding python interpreters * Wed Dec 06 2006 Jeremy Katz - 2.5.3-2 - disable installation of .egg-info files for now * Tue Dec 05 2006 Jeremy Katz - support db 4.5 - obsolete python-elementtree; since it requires some code tweaks, don't provide it - obsolete old python-sqlite; provide the version that's actually included redhat-menus-7.8.9-1.fc7 ------------------------ * Sun Dec 10 2006 Ray Strode - 7.8.9-1 - Update to 7.8.9 ruby-1.8.5.2-1.fc7 ------------------ * Mon Dec 11 2006 Akira TAGOH - 1.8.5.2-1 - security fix release. selinux-policy-2.4.6-9.fc7 -------------------------- * Fri Dec 08 2006 Dan Walsh 2.4.6-9 - More fixes for MLS sysklogd-1.4.1-42.fc7 --------------------- * Tue Dec 12 2006 Peter Vrabec 1.4.1-42 - fix IPv6 patch tar-2:1.15.1-22.fc7 ------------------- * Sun Dec 10 2006 Peter Vrabec 2:1.15.1-22 - fix some rpmlint spec file issues yum-3.0.1-4.fc7 --------------- * Mon Dec 11 2006 Jeremy Katz - 3.0.1-4 - fix typo in python2.5 patch (#219029) Broken deps for i386 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.i386 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.i386 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.i386 requires libpython2.4.so.1.0 libdbi-dbd-pgsql - 0.8.1a-1.2.2.i386 requires libpq.so.4 php-pgsql - 5.2.0-7.i386 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.i386 requires libpq.so.4 pyOpenSSL - 0.6-1.p24.7.2.2.i386 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 setroubleshoot - 1.8.7-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.i386 requires python(abi) = 0:2.4 Broken deps for ppc64 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.ppc64 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ppc64 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ppc64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ppc64 requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ppc64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ppc64 requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.ppc64 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 setroubleshoot - 1.8.7-1.fc7.noarch requires python-elementtree Broken deps for x86_64 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.i386 requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.i386 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.x86_64 requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.x86_64 requires python-abi = 0:2.4 cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.x86_64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.x86_64 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.x86_64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.x86_64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.x86_64 requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.x86_64 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 setroubleshoot - 1.8.7-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.x86_64 requires python(abi) = 0:2.4 Broken deps for ia64 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.ia64 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ia64 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ia64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ia64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ia64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ia64 requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.ia64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ia64 requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.ia64 requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.ia64 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 setroubleshoot - 1.8.7-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.ia64 requires python(abi) = 0:2.4 Broken deps for ppc ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.ppc requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ppc requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 kdebindings - 3.5.5-1.fc7.ppc requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.ppc requires libpython2.4.so.1.0 libdbi-dbd-pgsql - 0.8.1a-1.2.2.ppc requires libpq.so.4 php-pgsql - 5.2.0-7.ppc requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.ppc requires libpq.so.4 pyOpenSSL - 0.6-1.p24.7.2.2.ppc requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 setroubleshoot - 1.8.7-1.fc7.noarch requires python-elementtree Broken deps for s390 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.s390 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.s390 requires libpython2.4.so.1.0 libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390 requires libpq.so.4 php-pgsql - 5.2.0-7.s390 requires libpq.so.4 postgresql-odbc - 08.01.0200-3.1.s390 requires libpq.so.4 pyOpenSSL - 0.6-1.p24.7.2.2.s390 requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 setroubleshoot - 1.8.7-1.fc7.noarch requires python-elementtree systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for s390x ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.s390x requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390x requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.s390x requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390x requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeedu - 3.5.5-0.1.fc6.s390x requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.s390x requires libpython2.4.so.1.0()(64bit) libdbi-dbd-pgsql - 0.8.1a-1.2.2.s390x requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.s390x requires libpq.so.4()(64bit) postgresql-odbc - 08.01.0200-3.1.s390x requires libpq.so.4()(64bit) pyOpenSSL - 0.6-1.p24.7.2.2.s390x requires python(abi) = 0:2.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 setroubleshoot - 1.8.7-1.fc7.noarch requires python-elementtree From mlichvar at redhat.com Tue Dec 12 09:54:44 2006 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Tue, 12 Dec 2006 10:54:44 +0100 Subject: Switching to ncurses In-Reply-To: <20061201103212.GT6570@devserv.devel.redhat.com> References: <456FF253.9010503@develer.com> <20061201094518.GS6570@devserv.devel.redhat.com> <1164967254.3233.64.camel@laptopd505.fenrus.org> <20061201103212.GT6570@devserv.devel.redhat.com> Message-ID: <20061212095444.GA23264@localhost> On Fri, Dec 01, 2006 at 05:32:12AM -0500, Jakub Jelinek wrote: > > > > libncurses is much bigger than libtermcap, and also has > > > > oddly large .bss and .data sections: > > > > > > > > bender:/[1/0]# size /lib64/libncurses.so.5 /lib64/libtermcap.so.2 > > > > text data bss dec hex filename > > > > 319006 56608 3592 379206 5c946 /lib64/libncurses.so.5 > > > > 10483 788 112 11383 2c77 /lib64/libtermcap.so.2 [...] > > I think the easiest would be just nuke the terminfo source > parsing routines from libncurses*.so, _nc_read_entry_source nor > _nc_parse_entry aren't even prototyped in any installed ncurses > headers. It can be IMHO moved to libtic.a which will be linked > into ncurses utilities that need it. > > If that is not possible, there are other options, e.g. switching > to a more compact and relocation friendly representation. [...] Thanks for the suggestions. ncurses-5.5-27.20061209.fc7 should be much better. $ size /lib64/libncurses.so.5 text data bss dec hex filename 261273 20504 3144 284921 458f9 /lib64/libncurses.so.5 Linker statistics show that total startup time in dynamic loader for bash with libncurses is about 10% longer than with libtermcap. Is it good enough to replace libtermcap? -- Miroslav Lichvar From tla-ml at rasmil.dk Tue Dec 12 10:13:07 2006 From: tla-ml at rasmil.dk (Tim Lauridsen) Date: Tue, 12 Dec 2006 11:13:07 +0100 Subject: yum In-Reply-To: References: Message-ID: <457E80B3.80405@rasmil.dk> Ahm ed wrote: > I'm sure we have all heard about yum's "speed" issues, and yes it is > annyoing, but fc6 went a long way to try to improve this speed. FC6 > also saw yum become even more integrated into fedora (anaconda etc.). > And all this development is good, and don't get me wrong I think yum > is a fantastic tool with many wonderful features. However it's > currently still lacking in some areas. > 1. The GUI > pup and pirut are pretty good programs but they are in some ways, a > bit restricting. (for lack of a better word). I think that they should > have more then just a progress bar. They should also output more > information about say, the size of the files. How much (exactly) has > been downloaded, and perhaps at what speed the downloads are going. pup and pirut is created to be simple, if you want more options and output the try out yumex. You can get the the latest development 1.9.x prerelease here: http://www.yum-extender.org/dnl/yumex/devel/ or you can use the 1.2.x one currently in Extras. > > 2. yum CLI > Yum's CLI is much better than the gui tools at this point, and though > it has gotten better there are some ways that it still needs to > improve. The two areas I find most...upsetting involved the headers > and dependency resolution. The headers are quite large....ok so maybe > the biggest they get is around 400k (if I recall correctly) but when > your on a slower connection, and your upgrading a lot of packages this > can be quite annoying. Perhaps they header files could be placed in a > different, smaller, format. Or an option to download all the header > files could be included, and the headers can be updated then along > with the metadata. Yum only download the header part of the rpm files from the mirror to feed it into rpm api, which does part of the depsolving. I dont speed up thing to split out the header data into seperate files, like earlier versions of yum did, the same number of bytes have to be download any way. Depsolving is a complex task an it takes time to do, i prefere good depsolving, more than fast depsolving. Tim From buildsys at redhat.com Tue Dec 12 10:54:02 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 12 Dec 2006 05:54:02 -0500 Subject: rawhide report: 20061212 changes Message-ID: <200612121054.kBCAs2RM027851@hs20-bc2-6.build.redhat.com> Updated Packages: alsa-lib-1.0.14-0.1.rc1.fc7 --------------------------- * Mon Dec 11 2006 Martin Stransky 1.0.14-0.1.rc1 - new upstream autofs-1:5.0.1-0.rc2.35 ----------------------- * Mon Dec 11 2006 Ian Kent - 5.0.1-0.rc2.35 - update "replace-tempnam" patch to create temp files in sane location. gaim-2:2.0.0-0.28.beta5.fc7 --------------------------- * Mon Dec 11 2006 Warren Togami - 2:2.0.0-0.28.beta5 - Debian patch 13_yahoo_webauth_disable temporarily disable the broken yahoo web auth fallback irqbalance-2:0.54-1.fc7 ----------------------- * Mon Dec 11 2006 Neil Horman - 0.54-1 - Update irqbalance to new version released at www.irqbalance.org jpackage-utils-0:1.7.3-1jpp.1.fc7 --------------------------------- * Mon Dec 11 2006 Thomas Fitzsimmons - 0:1.7.3-1jpp.1.fc7 - Import version 0:1.7.3-1jpp from jpackage.org. - Change release numbering format to Xjpp.Y.fc7. - Resolves: rhbz#218936 * Sat Nov 11 2006 Ville Skytt?? - 0:1.7.3-1jpp - Add Java 1.6.0 dirs. * Mon Oct 23 2006 Deepak Bhole 1.7.2-1jpp - Added maven2 depmap related macros. libdbi-drivers-0.8.1a-2.fc7 --------------------------- * Mon Dec 11 2006 Tom Lane 0.8.1a-2 - Enable building of sqlite driver Resolves: #184568 - Rebuild needed anyway for Postgres library update openssl-0.9.8b-12.fc7 --------------------- * Mon Dec 11 2006 Tomas Mraz 0.9.8b-12 - detect duplicates in add_dir properly (#206346) postgresql-odbc-08.01.0200-4.fc7 -------------------------------- * Mon Dec 11 2006 Tom Lane 08.01.0200-4 - Rebuild for new Postgres libraries pyOpenSSL-0.6-1.p24.9 --------------------- * Mon Dec 11 2006 Paul Howarth - 0.6-1.p24.9 - add missing buildreq latex2html, needed to build HTML docs - rewrite to be more in line with Fedora python spec template and use %{python_sitearch} rather than a script-generated %files list - package is not relocatable - drop Prefix: tag - buildreq perl not necessary - fix permissions for files going into debuginfo package * Thu Dec 07 2006 Jeremy Katz - 0.6-1.p24.8 - rebuild for python 2.5 rpm-4.4.2-38.fc7 ---------------- * Mon Dec 11 2006 Jeremy Katz - 4.4.2-38 - python: dbmatch keys can be unicode objects also (#219008) system-config-printer-0.7.42-1.fc7 ---------------------------------- * Mon Dec 11 2006 Tim Waugh 0.7.42-1 - 0.7.42: - Fixed typo in command set matching code. - Case-insensitive matching when Device ID not known to database. Broken deps for i386 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.i386 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.i386 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.i386 requires libpython2.4.so.1.0 php-pgsql - 5.2.0-7.i386 requires libpq.so.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 setroubleshoot - 1.8.7-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.i386 requires python(abi) = 0:2.4 Broken deps for ppc64 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.ppc64 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ppc64 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ppc64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ppc64 requires libpython2.4.so.1.0()(64bit) php-pgsql - 5.2.0-7.ppc64 requires libpq.so.4()(64bit) python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 setroubleshoot - 1.8.7-1.fc7.noarch requires python-elementtree Broken deps for x86_64 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.i386 requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.i386 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.x86_64 requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.x86_64 requires python-abi = 0:2.4 cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.x86_64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.x86_64 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) php-pgsql - 5.2.0-7.x86_64 requires libpq.so.4()(64bit) python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 setroubleshoot - 1.8.7-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.x86_64 requires python(abi) = 0:2.4 Broken deps for ppc ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.ppc requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ppc requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 kdebindings - 3.5.5-1.fc7.ppc requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.ppc requires libpython2.4.so.1.0 php-pgsql - 5.2.0-7.ppc requires libpq.so.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 setroubleshoot - 1.8.7-1.fc7.noarch requires python-elementtree Broken deps for s390 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.s390 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.s390 requires libpython2.4.so.1.0 php-pgsql - 5.2.0-7.s390 requires libpq.so.4 python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 setroubleshoot - 1.8.7-1.fc7.noarch requires python-elementtree systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.ia64 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.ia64 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ia64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ia64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ia64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ia64 requires libpython2.4.so.1.0()(64bit) php-pgsql - 5.2.0-7.ia64 requires libpq.so.4()(64bit) python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 setroubleshoot - 1.8.7-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.ia64 requires python(abi) = 0:2.4 Broken deps for s390x ---------------------------------------------------------- alchemist - 1.0.36-1.2.2.s390x requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390x requires python(abi) = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python-abi = 0:2.4 alchemist - 1.0.36-1.2.2.s390 requires python(abi) = 0:2.4 cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.s390x requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390x requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeedu - 3.5.5-0.1.fc6.s390x requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.s390x requires libpython2.4.so.1.0()(64bit) php-pgsql - 5.2.0-7.s390x requires libpq.so.4()(64bit) python-docs - 2.4.4-1.fc7.noarch requires python = 0:2.4.4 setroubleshoot - 1.8.7-1.fc7.noarch requires python-elementtree From dominik at greysector.net Tue Dec 12 11:36:45 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 12 Dec 2006 12:36:45 +0100 Subject: wpa and fc6/7 In-Reply-To: <883cfe6d0612081350i66aa7f4dqe040ccf500509ba6@mail.gmail.com> References: <3dd77c60612040001t4f813b5bn2c4e420fb2c59a9a@mail.gmail.com> <45748A25.2010908@redhat.com> <80d7e4090612041331y219cf398mc17bc5d00b57d1a9@mail.gmail.com> <1165517992.3195.19.camel@dhollis-lnx.sunera.com> <883cfe6d0612081350i66aa7f4dqe040ccf500509ba6@mail.gmail.com> Message-ID: <20061212113645.GA17932@ryvius.pekin.waw.pl> On Friday, 08 December 2006 at 22:50, Michel Salim wrote: > 2006/12/7, David Hollis : > >On Mon, 2006-12-04 at 14:31 -0700, Stephen John Smoogen wrote: > > > >> > >> I had problems with it for the first 2 weeks after the release (WPA > >> would not work with my ipw3945 etc) . but what is currently on my > >> system is working great. [It was kind of interesting.. it started > >> working the day before Thanksgiving and has worked since then.] > > > >What I've found with ipw3945 is that even though you can build it > >against the in-kernel IEEE80211 stack (1.1.13), WPA doesn't work worth a > >darn. If you build it against the latest stack (1.2.15), everything > >works quite well. It would be real nice if Intel would get rid of the > >ipw3945d daemon - which apparently they are in the process of doing - > >just to make it so I don't have to have any hack-arounds for it. > > > How much difference did it make? I ended up turning off WPA on my > wireless router because the router would freeze every few hours. The > only problem I noticed on the laptop side is that it takes a long time > to acquire a network address using DHCP, and sometimes I have to tell > NetworkManager to reconnect several times. > > This is using freshrpms' ipw3945, which has a small patch that (as I > understand it) sets the API version to 1.1.13 instead of 1.1.14 Works for me using unpatched ipw3945-1.1.2 with small patches to make it build on current FC6 kernel, taken from ipw3945 bugzilla: http://www.bughost.org/bugzilla/show_bug.cgi?id=1155 http://www.bughost.org/bugzilla/show_bug.cgi?id=1151 Package is on its way into Livna. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski MPlayer developer http://rpm.greysector.net/mplayer/ "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From markmc at redhat.com Tue Dec 12 12:01:47 2006 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 12 Dec 2006 12:01:47 +0000 Subject: Package dependency analysis In-Reply-To: <1165436216.6541.0.camel@localhost.localdomain> References: <1165428261.8880.19.camel@blaa> <1165436216.6541.0.camel@localhost.localdomain> Message-ID: <1165924907.14906.10.camel@blaa> Hi David, On Wed, 2006-12-06 at 12:16 -0800, David Lutterkort wrote: > > I am not sure that graphical repesentations of dependencies are all that > useful. I'd rather have a (GUI based) tool that is focused on answering > specific questions; for example, > > * given a set of packages/groups, what is the package set that > anaconda will install with that input (i.e. closure under dep > solving) > * given a set of packages/groups I, and its closure C, why is > package X in C ? This might actually benefit from showing the > full dependency path from the initial packages to the resolved > set, though just highlighting the member(s) of I that cause X to > end up in C might be enough > * given the sets I and C and a specific package X in I, which > packages in C are pulled in by X ? Which ones are pulled in just > by X and which ones by X and other packages in I ? That's more or less what I'm getting at :-) I've done a little hacking to make it more obvious what it is I'm trying to do. Give it a whirl ... $> wget http://people.redhat.com/markmc/depsgraph/depsgraph-0.31.tar.bz2 $> rpmbuild -ta ./depsgraph-0.31.tar.bz2 $> rpm -Uhv /usr/src/redhat/RPMS/i386/depsgraph-0.31-1.i386.rpm Assume you're looking at kernel deps in FC6: $> depsgraph http://download.fedora.redhat.com/pub/fedora/linux/core/6/i386/os/ kernel Scroll down through the list looking for anything unusual. Notice python, double-click on it. [1] "Ah, something called cracklib requires it" ... click on cracklib. [2] "Ah, pam needs that ... hmm, cracklib probably shouldn't require python then" [3] Cheers, Mark. [1] - http://people.redhat.com/markmc/depsgraph/screenshots/depsgraph1.png [2] - http://people.redhat.com/markmc/depsgraph/screenshots/depsgraph2.png [3] - http://people.redhat.com/markmc/depsgraph/screenshots/depsgraph3.png From zrchrn at gmail.com Wed Dec 13 04:54:45 2006 From: zrchrn at gmail.com (Ahm ed) Date: Tue, 12 Dec 2006 23:54:45 -0500 Subject: yum Message-ID: Tim Wrote: Yum only download the header part of the rpm files from the mirror to feed it into rpm api, which does part of the depsolving. I dont speed up thing to split out the header data into seperate files, like earlier versions of yum did, the same number of bytes have to be download any way. Depsolving is a complex task an it takes time to do, i prefere good depsolving, more than fast depsolving. Tim Ah, I see. About the speed. I agree good depsolving IS better than fast depsolving. BUT the choice is not necessarily between good and fast. as I have stated Arch Linux's pacman pkg management tool and smart-pm (available in fedora) as well as debian's tools all process dependencies MUCH faster than yum. And they do it with comparable effectiveness to yum. I feel we can make this process faster, not necessarily as "fast" but faster then what it is. It does not seem to be a problem directly with rpm itself since smart does work fairly fast even in fedora. So I am assuming it has to do with something yum does. It could be due to python. In that case I recommend we move more parts of yum to c. especially the "heavy" processes involved with depchecks. What I want is for yum to be as fast as possible, without it's quality taking a hit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From che666 at gmail.com Wed Dec 13 08:13:06 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 13 Dec 2006 09:13:06 +0100 Subject: Call for help with packagaging games for fedora-extras Message-ID: Hello to you! First of all i want you to know the following facts: 1. there are people dedicated to games packaging but those people maintain a really huge number of packages. 2. there are lots of very interesting games, even 3d games that are not part of extras yet So this is why I write this email. We need more people dedicated to package games. Especially initial packaging of games takes alot work usually for various reasons. If anyone is interested to maintain some of the next generation games in extras you can either: a) look at the games sig on the fedora wiki b) contact me as i have various things initially packaged but not ready for extras inclusion also a lack of time to really maintain the packages in extras because i am too often on the road... but still sometimes spare time to invest into building initial packages b) look around for a yet unknown/unpackaged open source game What i have ready e.g. would be warzone2100, vdrift (vdrift.net) and a few others, so if youd like to take those i can send you a halfway finished spec file. regards, Rudolf Kastl From che666 at gmail.com Wed Dec 13 08:14:43 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 13 Dec 2006 09:14:43 +0100 Subject: Call for help with packagaging games for fedora-extras In-Reply-To: References: Message-ID: 2006/12/13, Rudolf Kastl : > Hello to you! > > First of all i want you to know the following facts: > > 1. there are people dedicated to games packaging but those people > maintain a really huge number of packages. > > 2. there are lots of very interesting games, even 3d games that are > not part of extras yet > > So this is why I write this email. We need more people dedicated to > package games. Especially initial packaging of games takes alot work > usually for various reasons. > > If anyone is interested to maintain some of the next generation games > in extras you can either: > > a) look at the games sig on the fedora wiki > b) contact me as i have various things initially packaged but not > ready for extras inclusion also a lack of time to really maintain the > packages in extras because i am too often on the road... but still > sometimes spare time to invest into building initial packages > b) look around for a yet unknown/unpackaged open source game > > What i have ready e.g. would be warzone2100, vdrift (vdrift.net) and a > few others, so if youd like to take those i can send you a halfway > finished spec file. > > regards, > Rudolf Kastl > replying to my own email because i forgot to mention the #fedora-games irc channel on irc.freenode.net regards, Rudolf Kastl From rc040203 at freenet.de Wed Dec 13 08:29:42 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 13 Dec 2006 09:29:42 +0100 Subject: Call for help with packagaging games for fedora-extras In-Reply-To: References: Message-ID: <1165998583.24534.158.camel@mccallum.corsepiu.local> On Wed, 2006-12-13 at 09:14 +0100, Rudolf Kastl wrote: > 2006/12/13, Rudolf Kastl : > > > > What i have ready e.g. would be warzone2100, vdrift (vdrift.net) and a > > few others, so if youd like to take those i can send you a halfway > > finished spec file. Sorry, but what prevents you from submitting them for review? Ralf From sundaram at fedoraproject.org Wed Dec 13 08:41:01 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 Dec 2006 14:11:01 +0530 Subject: Call for help with packagaging games for fedora-extras In-Reply-To: <1165998583.24534.158.camel@mccallum.corsepiu.local> References: <1165998583.24534.158.camel@mccallum.corsepiu.local> Message-ID: <457FBC9D.6020307@fedoraproject.org> Ralf Corsepius wrote: > On Wed, 2006-12-13 at 09:14 +0100, Rudolf Kastl wrote: >> 2006/12/13, Rudolf Kastl : > >>> What i have ready e.g. would be warzone2100, vdrift (vdrift.net) and a >>> few others, so if youd like to take those i can send you a halfway >>> finished spec file. > > Sorry, but what prevents you from submitting them for review? > Submitting them for review would imply that the person is ready to maintain the packages. If the person has some spec files but is not willing or does have not the time to commit to continuing maintenance, then submitting them for review would be inappropriate. Rahul From che666 at gmail.com Wed Dec 13 09:08:52 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 13 Dec 2006 10:08:52 +0100 Subject: Call for help with packagaging games for fedora-extras In-Reply-To: <457FBC9D.6020307@fedoraproject.org> References: <1165998583.24534.158.camel@mccallum.corsepiu.local> <457FBC9D.6020307@fedoraproject.org> Message-ID: 2006/12/13, Rahul Sundaram : > Ralf Corsepius wrote: > > On Wed, 2006-12-13 at 09:14 +0100, Rudolf Kastl wrote: > >> 2006/12/13, Rudolf Kastl : > > > >>> What i have ready e.g. would be warzone2100, vdrift (vdrift.net) and a > >>> few others, so if youd like to take those i can send you a halfway > >>> finished spec file. > > > > Sorry, but what prevents you from submitting them for review? > > > > Submitting them for review would imply that the person is ready to > maintain the packages. If the person has some spec files but is not > willing or does have not the time to commit to continuing maintenance, > then submitting them for review would be inappropriate. Thats exactly my problem. Sometimes i have chunks of time to invest into work and i usually invest it with upstream work so the stuff is working on fedora and is packageable. For maintaining those packages in my eyes id have to have frequent time so i can make sure its possible to upgrade it as soon as there is a new version. Id be willing to help and/or comaintain the packages for sure but what i cant garantud is that i wont be on the road and i will have inet at all. regards, Rudolf Kastl > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From sundaram at fedoraproject.org Wed Dec 13 09:09:51 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 Dec 2006 14:39:51 +0530 Subject: Call for help with packagaging games for fedora-extras In-Reply-To: References: <1165998583.24534.158.camel@mccallum.corsepiu.local> <457FBC9D.6020307@fedoraproject.org> Message-ID: <457FC35F.6020200@fedoraproject.org> Rudolf Kastl wrote: > Thats exactly my problem. Sometimes i have chunks of time to invest > into work and i usually invest it with upstream work so the stuff is > working on fedora and is packageable. > For maintaining those packages in my eyes id have to have frequent > time so i can make sure its possible to upgrade it as soon as there is > a new version. > Id be willing to help and/or comaintain the packages for sure but what > i cant garantud is that i wont be on the road and i will have inet at > all. What you can do here is copy the spec files and refer to them from the extras wish list and games pages so they are publicly accessible for anyone who wants to get started with packaging those games. I am sure you are not the only one sitting on some spec files for various reasons. Rahul From che666 at gmail.com Wed Dec 13 09:16:32 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 13 Dec 2006 10:16:32 +0100 Subject: Call for help with packagaging games for fedora-extras In-Reply-To: <457FC35F.6020200@fedoraproject.org> References: <1165998583.24534.158.camel@mccallum.corsepiu.local> <457FBC9D.6020307@fedoraproject.org> <457FC35F.6020200@fedoraproject.org> Message-ID: 2006/12/13, Rahul Sundaram : > Rudolf Kastl wrote: > > > Thats exactly my problem. Sometimes i have chunks of time to invest > > into work and i usually invest it with upstream work so the stuff is > > working on fedora and is packageable. > > For maintaining those packages in my eyes id have to have frequent > > time so i can make sure its possible to upgrade it as soon as there is > > a new version. > > Id be willing to help and/or comaintain the packages for sure but what > > i cant garantud is that i wont be on the road and i will have inet at > > all. > > What you can do here is copy the spec files and refer to them from the > extras wish list and games pages so they are publicly accessible for > anyone who wants to get started with packaging those games. I am sure > you are not the only one sitting on some spec files for various reasons. maybe it would be discussable to have a kinda "upload possibility" for spec files one has hanging around locally. this way it would be easier to collect those. what do you think? regards, Rudolf Kastl > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From pemboa at gmail.com Wed Dec 13 09:20:01 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 14 Dec 2006 03:20:01 +1800 Subject: yum In-Reply-To: References: Message-ID: <16de708d0612130120t16434fabrec0ebbe66f3c4f2e@mail.gmail.com> On 12/13/06, Ahm ed wrote: > Tim Wrote: > Yum only download the header part of the rpm files from the mirror to > feed it into rpm api, which does part of the depsolving. > I dont speed up thing to split out the header data into seperate files, > like earlier versions of yum did, the same number of bytes have to > be download any way. Depsolving is a complex task an it takes time to > do, i prefere good depsolving, more than fast depsolving. > > Tim > > Ah, I see. About the speed. I agree good depsolving IS better than fast > depsolving. BUT the choice is not necessarily between good and fast. as I > have stated Arch Linux's pacman pkg management tool and smart-pm (available > in fedora) as well as debian's tools all process dependencies MUCH faster > than yum. And they do it with comparable effectiveness to yum. I feel we can > make this process faster, not necessarily as "fast" but faster then what it > is. It does not seem to be a problem directly with rpm itself since smart > does work fairly fast even in fedora. So I am assuming it has to do with > something yum does. It could be due to python. In that case I recommend we > move more parts of yum to c. especially the "heavy" processes involved with > depchecks. What I want is for yum to be as fast as possible, without it's > quality taking a hit. > You may just want to write a module in C to do this. -- Fedora Core 6 and proud From sundaram at fedoraproject.org Wed Dec 13 09:21:40 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 13 Dec 2006 14:51:40 +0530 Subject: Call for help with packagaging games for fedora-extras In-Reply-To: References: <1165998583.24534.158.camel@mccallum.corsepiu.local> <457FBC9D.6020307@fedoraproject.org> <457FC35F.6020200@fedoraproject.org> Message-ID: <457FC624.5010402@fedoraproject.org> Rudolf Kastl wrote: > 2006/12/13, Rahul Sundaram : >> Rudolf Kastl wrote: >> >> > Thats exactly my problem. Sometimes i have chunks of time to invest >> > into work and i usually invest it with upstream work so the stuff is >> > working on fedora and is packageable. >> > For maintaining those packages in my eyes id have to have frequent >> > time so i can make sure its possible to upgrade it as soon as there is >> > a new version. >> > Id be willing to help and/or comaintain the packages for sure but what >> > i cant garantud is that i wont be on the road and i will have inet at >> > all. >> >> What you can do here is copy the spec files and refer to them from the >> extras wish list and games pages so they are publicly accessible for >> anyone who wants to get started with packaging those games. I am sure >> you are not the only one sitting on some spec files for various reasons. > > maybe it would be discussable to have a kinda "upload possibility" for > spec files one has hanging around locally. this way it would be easier > to collect those. > > what do you think? Sure. See http://fedoraproject.org/wiki/Extras/WishList. The wiki has the ability to upload files. We already link submitted reviews in the wishlist for reference. You can do something similar for spec files or create e dedicated section. Link all the uploaded spec files there and anyone interested can use those. Rahul From che666 at gmail.com Wed Dec 13 09:36:53 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 13 Dec 2006 10:36:53 +0100 Subject: Call for help with packagaging games for fedora-extras In-Reply-To: <457FC624.5010402@fedoraproject.org> References: <1165998583.24534.158.camel@mccallum.corsepiu.local> <457FBC9D.6020307@fedoraproject.org> <457FC35F.6020200@fedoraproject.org> <457FC624.5010402@fedoraproject.org> Message-ID: 2006/12/13, Rahul Sundaram : > Rudolf Kastl wrote: > > 2006/12/13, Rahul Sundaram : > >> Rudolf Kastl wrote: > >> > >> > Thats exactly my problem. Sometimes i have chunks of time to invest > >> > into work and i usually invest it with upstream work so the stuff is > >> > working on fedora and is packageable. > >> > For maintaining those packages in my eyes id have to have frequent > >> > time so i can make sure its possible to upgrade it as soon as there is > >> > a new version. > >> > Id be willing to help and/or comaintain the packages for sure but what > >> > i cant garantud is that i wont be on the road and i will have inet at > >> > all. > >> > >> What you can do here is copy the spec files and refer to them from the > >> extras wish list and games pages so they are publicly accessible for > >> anyone who wants to get started with packaging those games. I am sure > >> you are not the only one sitting on some spec files for various reasons. > > > > maybe it would be discussable to have a kinda "upload possibility" for > > spec files one has hanging around locally. this way it would be easier > > to collect those. > > > > what do you think? > > Sure. See http://fedoraproject.org/wiki/Extras/WishList. The wiki has > the ability to upload files. We already link submitted reviews in the > wishlist for reference. You can do something similar for spec files or > create e dedicated section. Link all the uploaded spec files there and > anyone interested can use those. > > Rahul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > going to work on a dedicated page for uploading spec files that can be used by future maintainers. what it doesent solve yet though is the missing manpower that is required to help out the currently active game packagers. regards, Rudolf Kastl From rc040203 at freenet.de Wed Dec 13 09:43:15 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 13 Dec 2006 10:43:15 +0100 Subject: Call for help with packagaging games for fedora-extras In-Reply-To: References: <1165998583.24534.158.camel@mccallum.corsepiu.local> <457FBC9D.6020307@fedoraproject.org> <457FC35F.6020200@fedoraproject.org> <457FC624.5010402@fedoraproject.org> Message-ID: <1166002996.24534.203.camel@mccallum.corsepiu.local> On Wed, 2006-12-13 at 10:36 +0100, Rudolf Kastl wrote: > 2006/12/13, Rahul Sundaram : > > Rudolf Kastl wrote: > > > 2006/12/13, Rahul Sundaram : > > >> Rudolf Kastl wrote: > > >> > > >> > Thats exactly my problem. Sometimes i have chunks of time to invest > > >> > into work and i usually invest it with upstream work so the stuff is > > >> > working on fedora and is packageable. > > >> > For maintaining those packages in my eyes id have to have frequent > > >> > time so i can make sure its possible to upgrade it as soon as there is > > >> > a new version. > > >> > Id be willing to help and/or comaintain the packages for sure but what > > >> > i cant garantud is that i wont be on the road and i will have inet at > > >> > all. > > >> > > >> What you can do here is copy the spec files and refer to them from the > > >> extras wish list and games pages so they are publicly accessible for > > >> anyone who wants to get started with packaging those games. I am sure > > >> you are not the only one sitting on some spec files for various reasons. > > > > > > maybe it would be discussable to have a kinda "upload possibility" for > > > spec files one has hanging around locally. this way it would be easier > > > to collect those. > > > > > > what do you think? > > > > Sure. See http://fedoraproject.org/wiki/Extras/WishList. The wiki has > > the ability to upload files. We already link submitted reviews in the > > wishlist for reference. You can do something similar for spec files or > > create e dedicated section. Link all the uploaded spec files there and > > anyone interested can use those. > > > > Rahul > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > going to work on a dedicated page for uploading spec files that can be > used by future maintainers. > > what it doesent solve yet though is the missing manpower that is > required to help out the currently active game packagers. IMO, the only way that works is somebody seriously interested in a package to submit it and guide it through a review. Anything else is "hot air" and more or less irrelevant. Or to put it differently: I guess you (Rudolf) are aware how your request sounds to active packagers? Ralf From che666 at gmail.com Wed Dec 13 09:54:35 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 13 Dec 2006 10:54:35 +0100 Subject: Call for help with packagaging games for fedora-extras In-Reply-To: <1166002996.24534.203.camel@mccallum.corsepiu.local> References: <1165998583.24534.158.camel@mccallum.corsepiu.local> <457FBC9D.6020307@fedoraproject.org> <457FC35F.6020200@fedoraproject.org> <457FC624.5010402@fedoraproject.org> <1166002996.24534.203.camel@mccallum.corsepiu.local> Message-ID: 2006/12/13, Ralf Corsepius : > On Wed, 2006-12-13 at 10:36 +0100, Rudolf Kastl wrote: > > 2006/12/13, Rahul Sundaram : > > > Rudolf Kastl wrote: > > > > 2006/12/13, Rahul Sundaram : > > > >> Rudolf Kastl wrote: > > > >> > > > >> > Thats exactly my problem. Sometimes i have chunks of time to invest > > > >> > into work and i usually invest it with upstream work so the stuff is > > > >> > working on fedora and is packageable. > > > >> > For maintaining those packages in my eyes id have to have frequent > > > >> > time so i can make sure its possible to upgrade it as soon as there is > > > >> > a new version. > > > >> > Id be willing to help and/or comaintain the packages for sure but what > > > >> > i cant garantud is that i wont be on the road and i will have inet at > > > >> > all. > > > >> > > > >> What you can do here is copy the spec files and refer to them from the > > > >> extras wish list and games pages so they are publicly accessible for > > > >> anyone who wants to get started with packaging those games. I am sure > > > >> you are not the only one sitting on some spec files for various reasons. > > > > > > > > maybe it would be discussable to have a kinda "upload possibility" for > > > > spec files one has hanging around locally. this way it would be easier > > > > to collect those. > > > > > > > > what do you think? > > > > > > Sure. See http://fedoraproject.org/wiki/Extras/WishList. The wiki has > > > the ability to upload files. We already link submitted reviews in the > > > wishlist for reference. You can do something similar for spec files or > > > create e dedicated section. Link all the uploaded spec files there and > > > anyone interested can use those. > > > > > > Rahul > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > going to work on a dedicated page for uploading spec files that can be > > used by future maintainers. > > > > what it doesent solve yet though is the missing manpower that is > > required to help out the currently active game packagers. > > IMO, the only way that works is somebody seriously interested in a > package to submit it and guide it through a review. Anything else is > "hot air" and more or less irrelevant. > > Or to put it differently: I guess you (Rudolf) are aware how your > request sounds to active packagers? > > Ralf Well if you take it as offensive or whining etc alright. Actually its not me that has a huge burden of packages to actively maintain and also its not me that has a problem with getting things packaged and deployed on my box. Everyone who knows me is aware that i did over 100 packages for a few years on newrpms. theres just a point where you dont have 16 hours a day to dedicate to packaging and/or see other more important things like doing upstream work etc. regards, Rudolf Kastl > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From nscheibl at gmail.com Wed Dec 13 10:21:24 2006 From: nscheibl at gmail.com (Nico Bdav) Date: Wed, 13 Dec 2006 11:21:24 +0100 Subject: yum In-Reply-To: <16de708d0612130120t16434fabrec0ebbe66f3c4f2e@mail.gmail.com> References: <16de708d0612130120t16434fabrec0ebbe66f3c4f2e@mail.gmail.com> Message-ID: Hi all, Just to say "About the speed" of yum, here is my story: Last week i just installed FC6 on a P3 550Mhz with 256MB of ram, for a "minimal home made" install it takes about 1 hour to solve dependecy before starting installing packages. The real install process take less than 30min. I don't think this is a normal behaviour. Lot's of people don't have the latest hardware with ultra high cpu frequency. I won't tell you how yum is unusable on a Pentium 233Mhz whereas apt-rpm works (within some seconds) like a charm. If you don't have a powerfull internet connection, you can simply forget about yum, whereas apt works like a charm from a bad internet connection (GSM/GPRS/PSTN). My configuration is largely sufficient for a basic desktop, or a tiny webserver, but not for fedora install/update tool. I think yum, which is the basic packet management system under fedora, must work on any configuration including older hardware (starting from pentium class systems). For so i think yum must be improved, to be faster and lighter or Fedora will become an elitist distribution for latest Top level hardware with hudge network connection. From che666 at gmail.com Wed Dec 13 10:49:56 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 13 Dec 2006 11:49:56 +0100 Subject: Call for help with packagaging games for fedora-extras In-Reply-To: <1166002996.24534.203.camel@mccallum.corsepiu.local> References: <1165998583.24534.158.camel@mccallum.corsepiu.local> <457FBC9D.6020307@fedoraproject.org> <457FC35F.6020200@fedoraproject.org> <457FC624.5010402@fedoraproject.org> <1166002996.24534.203.camel@mccallum.corsepiu.local> Message-ID: 2006/12/13, Ralf Corsepius : > On Wed, 2006-12-13 at 10:36 +0100, Rudolf Kastl wrote: > > 2006/12/13, Rahul Sundaram : > > > Rudolf Kastl wrote: > > > > 2006/12/13, Rahul Sundaram : > > > >> Rudolf Kastl wrote: > > > >> > > > >> > Thats exactly my problem. Sometimes i have chunks of time to invest > > > >> > into work and i usually invest it with upstream work so the stuff is > > > >> > working on fedora and is packageable. > > > >> > For maintaining those packages in my eyes id have to have frequent > > > >> > time so i can make sure its possible to upgrade it as soon as there is > > > >> > a new version. > > > >> > Id be willing to help and/or comaintain the packages for sure but what > > > >> > i cant garantud is that i wont be on the road and i will have inet at > > > >> > all. > > > >> > > > >> What you can do here is copy the spec files and refer to them from the > > > >> extras wish list and games pages so they are publicly accessible for > > > >> anyone who wants to get started with packaging those games. I am sure > > > >> you are not the only one sitting on some spec files for various reasons. > > > > > > > > maybe it would be discussable to have a kinda "upload possibility" for > > > > spec files one has hanging around locally. this way it would be easier > > > > to collect those. > > > > > > > > what do you think? > > > > > > Sure. See http://fedoraproject.org/wiki/Extras/WishList. The wiki has > > > the ability to upload files. We already link submitted reviews in the > > > wishlist for reference. You can do something similar for spec files or > > > create e dedicated section. Link all the uploaded spec files there and > > > anyone interested can use those. > > > > > > Rahul > > > > > > -- > > > fedora-devel-list mailing list > > > fedora-devel-list at redhat.com > > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > > > going to work on a dedicated page for uploading spec files that can be > > used by future maintainers. > > > > what it doesent solve yet though is the missing manpower that is > > required to help out the currently active game packagers. > > IMO, the only way that works is somebody seriously interested in a > package to submit it and guide it through a review. Anything else is > "hot air" and more or less irrelevant. i disagree. its about saving time with the reinventing the wheel syndrom. > > Or to put it differently: I guess you (Rudolf) are aware how your > request sounds to active packagers? already answered. i guess you know how that sounds to someone doing lots of upstream work. > > Ralf > > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From arjan at fenrus.demon.nl Wed Dec 13 10:56:33 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Wed, 13 Dec 2006 11:56:33 +0100 Subject: putting fedora on a (memory) diet... some suggestions for the kernel config Message-ID: <1166007393.27217.764.camel@laptopd505.fenrus.org> Looking at kernel memory use (based on 2.6.19 with a fedora config), there's some not that hard ways to gain quite a bit of memory back. Most important is CONFIG_NR_CPUS, right now that is set to 255 for everyone; this value is used for scaling a LOT of things in the kernel, and the sad thing is it's not even possible today to get a 255 core/processor machine (you run out of apic ids well before you get that far). Setting CONFIG_NR_CPUS to 64 (which is still huge, even 16 would be more than 99.99999% of the people who use fedora will ever use) will save user 255 64 saving ---------------------------------------------- irq_desc 2154496 294912 1859584 irq_domain 269312 18432 250880 irq_lists 134656 36864 97792 irq_2_pin 100992 27648 73344 irq_timer_state 67328 18432 48896 msi_desc 67328 18432 48896 per_cpu__kstat 33728 9280 24448 ----------------------------------------------- total 2403839 this alone saves 2.4Mb of memory in *static* buffers! Add a bunch more in smaller buffers and all dynamic kernel allocations and it'll be closer to 3Mb.. Easy gain right there. Another one is __log_buf; this is currently 128Kb. Arguably it's important for debugging to get 128Kb of dmesg info, but I wonder if 64Kb would be enough as well, it's another easy save by setting CONFIG_LOG_BUF_SHIFT to 16. A third one is disabling CPU hotplug. CPU hotplug keeps quite a bit of code in the kernel, that otherwise is boot-time only and gets evicted right after boot..... You could argue the same for PCI hotplug but cardbus is sort of the party spoiler there I suppose. I don't know what Dave will pick for CONFIG_STACK_PROTECTOR_ALL; I would suggest to turn this off (while enabling the normal CONFIG_STACK_PROTECTOR); _ALL doesn't add much if any security while it creates bigger and slower code everywhere. (The difference is that _ALL forces the canary on every function, while the normal setting only forces it for functions with buffers on the stack) From buildsys at redhat.com Wed Dec 13 11:16:46 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 13 Dec 2006 06:16:46 -0500 Subject: rawhide report: 20061213 changes Message-ID: <200612131116.kBDBGklY002471@hs20-bc2-6.build.redhat.com> Updated Packages: alchemist-1.0.37-1 ------------------ * Tue Dec 12 2006 Tim Waugh 1.0.37-1 - 1.0.37: - Build against Python 2.5. * Wed Dec 06 2006 Jeremy Katz - 1.0.36-2 - rebuild against python 2.5 alsa-utils-1.0.14-0.1.rc1.fc7 ----------------------------- * Mon Dec 11 2006 Martin Stransky 1.0.14-0.1.rc1 - new upstream authconfig-5.3.13-1.fc7 ----------------------- * Tue Dec 12 2006 Tomas Mraz - 5.3.13-1 - another traceback in --probe and other fixes (#218874) - make smbRealm a default realm when appropriate (#219300) - added missing languages in LINGUAS * Wed Nov 29 2006 Tomas Mraz - 5.3.12-1 - when pam_krb5 auth fails with smartcard login don't enforce it in the account stack (#214931) - updated translations (#216570) - winbind should be added only to user tables (#216862) * Fri Oct 20 2006 Tomas Mraz - 5.3.11-1 - fixed --smartcardaction command line option (#211552) bouncycastle-1.34-2.fc7 ----------------------- * Tue Dec 12 2006 Thomas Fitzsimmons - 1.34-2.fc7 - Install bcprov jar and unversioned symlink in /usr/share/java. - Install bcprov symlink in /usr/share/java/gcj-endorsed. - Change release numbering format to X.fc7. - Include new bcprov files in files list. - Import Bouncy Castle 1.34. - Related: rhbz#218794 desktop-printing-0.19-22.fc7 ---------------------------- * Tue Dec 12 2006 Matthias Clasen 0.19-22 - Fix parsing of foomatic XML (#219283) * Tue Dec 12 2006 Tim Waugh 0.19-21 - Fixed broken API name patch (bug #214619). * Tue Dec 12 2006 Tim Waugh 0.19-20 - Removed broken perl scripting line (bug #214619). evolution-2.9.3-3.fc7 --------------------- * Tue Dec 12 2006 Matthew Barnes - 2.9.3-3.fc7 - Revise patch for RH bug #215466 to also fix RH bug #218589. * Mon Dec 11 2006 Matthew Barnes - 2.9.3-2.fc7 - Add patch for RH bug #215467 (missing meeting participants). * Sat Dec 09 2006 Matthew Barnes - 2.9.3-1.fc7 - Update to 2.9.3 - Configure with scrollkeeper disabled. - Disable automake portability checking. - Ship our own icons from gnome-icon-theme. - BuildRequires: gnome-doc-utils >= 0.8.0 - Add patch for RH bug #215478 (Maildir and MH accounts). - Add patch for RH bug #215695 (crashes w/o mail accounts). - Add patch for RH bug #216537 (viewing attachments). - Add patch for RH bug #218801 (count unread messages first). - Add patch for GNOME bug #350253 (ship our own icons). - Add patch for GNOME bug #382431 (implicit function declaration). - Revise patch for GNOME bug #360946 (improved "about" dialog). - Remove patch for GNOME bug #357970 (fixed upstream). gdb-6.5-19.fc7 -------------- * Tue Dec 12 2006 Jan Kratochvil - 6.5-19 - Fix attachment also to a threaded stopped process (BZ 219118). - Cleanup any leftover testsuite processes as it may stuck mock(1) builds. * Sat Nov 25 2006 Jan Kratochvil - 6.5-18 - Fix readline history for input mode commands like `command' (BZ 215816). * Thu Nov 16 2006 Jan Kratochvil - 6.5-17 - Bugfix testcase typo of gdb-6.5-16. gnome-applets-1:2.16.2-5.fc7 ---------------------------- * Tue Dec 12 2006 Ray Strode - 1:2.16.2-5 - fix mixer applet error on login for new users (bug 217919) gstreamer-0.10.11-1.fc7 ----------------------- * Tue Dec 12 2006 Matthias Clasen - 0.10.11-1 - Update to 0.10.11 * Fri Oct 27 2006 Matthias Clasen - 0.10.10-2 - Cleanups - Attempt to fix multilib conflicts gstreamer-plugins-base-0.10.11-1.fc7 ------------------------------------ * Tue Dec 12 2006 Matthias Clasen - 0.10.11-1 - Update to 0.10.11 irqbalance-2:0.55-2.fc7 ----------------------- * Tue Dec 12 2006 Neil Horman - 0.55-2 - Fixing typos in spec file (bz 219301) * Tue Dec 12 2006 Neil Horman - 0.55-1 - Updating to version 0.55 libsepol-1.15.3-1.fc7 --------------------- * Tue Dec 12 2006 Adam Jackson 1.15.3-1 - Add dist tag and rebuild, fixes 6 to 7 upgrades. libusb-0.1.12-6.fc7 ------------------- * Tue Dec 12 2006 Jindrich Novy 0.1.12-6 - fix BuildRoot, add dist tag, rpmlint warnfixes mesa-6.5.2-3.fc7 ---------------- * Tue Dec 12 2006 Adam Jackson 6.5.2-3 - mesa-6.5.2-xserver-1.1-source-compat.patch: Add some source-compatibility defines to dispatch.h so the X server will continue to build. mtx-1.2.18-9.fc7 ---------------- * Tue Dec 12 2006 Jindrich Novy 1.2.18-9 - spec cleanup net-snmp-1:5.4-5.fc7 -------------------- * Tue Dec 12 2006 Radek Vok??l - 5.4-5 - fix memleaks in ip-addr and tcpConn passwd-0.74-1 ------------- * Tue Dec 12 2006 Tomas Mraz 0.74-1 - minor fixes in error reporting - localize messages (#204022) python-2.5-4.fc7 ---------------- * Tue Dec 12 2006 Jeremy Katz - 2.5.3-4 - obsolete/provide python-ctypes (#219256) * Mon Dec 11 2006 Jeremy Katz - 2.5.3-3 - fix atexit traceback with failed syslog logger (#218214) - split libpython into python-libs subpackage for multilib apps embedding python interpreters * Wed Dec 06 2006 Jeremy Katz - 2.5.3-2 - disable installation of .egg-info files for now python-docs-2.5-1.fc7 --------------------- * Tue Dec 12 2006 Jeremy Katz - 2.5-1 - update to 2.5 selinux-policy-2.4.6-10.fc7 --------------------------- * Tue Dec 12 2006 Dan Walsh 2.4.6-10 - Allow initrc to create files in /var directories Resolves: #219227 setroubleshoot-1.8.8-1.fc7 -------------------------- * Tue Dec 12 2006 Dan Walsh - 1.8.8-1 - Additional Translations - Change sealert to be able to run without X-Windows Resolves: #216575 setup-2.6.2-1.fc7 ----------------- * Tue Dec 12 2006 Phil Knirsch 2.6.2-1.fc7 - Updated uidgid for split of pcap into arpwatcher and tcpdump. * Tue Nov 28 2006 Phil Knirsch 2.6.1-1.fc7 - Update version and rebuilt * Tue Nov 28 2006 Phil Knirsch 2.5.57-1 - Revert change for umask in /etc/bashrc (#217523) squid-7:2.6.STABLE6-1.fc7 ------------------------- * Tue Dec 12 2006 Martin Stransky - 7:2.6.STABLE6-1 - update to the latest upstream system-config-nfs-1.3.23-1.fc7 ------------------------------ * Tue Dec 12 2006 Nils Philippsen 1.3.23 - pick up updated translations (#198604, #216608) * Fri Nov 24 2006 Nils Philippsen 1.3.22 - pick up updated translations (#216608) system-config-samba-1.2.37-1.fc7 -------------------------------- * Tue Dec 12 2006 Nils Philippsen - 1.2.37 - pick up updated translations (#216611) * Fri Nov 24 2006 Nils Philippsen - 1.2.36 - pick up updated translations (#216611) - add dist tag * Wed Mar 29 2006 Nils Philippsen - 1.2.35 - don't require gnome module (#187200) - don't wrap text in About dialog tar-2:1.15.1-23.fc7 ------------------- * Tue Dec 12 2006 Florian La Roche 2:1.15.1-23 - fix CVE-2006-6097 GNU tar directory traversal (#216937) tcpdump-14:3.9.5-2.fc7 ---------------------- * Tue Dec 12 2006 Miroslav Lichvar - 14:3.9.5-2 - use tcpdump user, fix scriptlet (#219268) vim-2:7.0.178-1 --------------- * Tue Dec 12 2006 Karsten Hopp 7.0.178-1 - patchlevel 178 - use macros - Resolves: #219154 add directory /usr/share/vim/vimfiles for plugins wireshark-0.99.5-0.pre1.fc7 --------------------------- * Tue Dec 12 2006 Radek Vokal 0.99.5-0.pre1 - update to 0.99.5 prerelease xorg-x11-drv-tdfx-1.3.0-2.fc7 ----------------------------- * Thu Nov 30 2006 Adam Jackson 1.3.0-2.fc7 - Update to 1.3.0. * Wed Jul 12 2006 Jesse Keating - sh: line 0: fg: no job control - rebuild * Fri May 26 2006 Mike A. Harris 1.2,1-3 - Added "BuildRequires: libdrm-devel >= 2.0-1" for (#192358) xorg-x11-server-1.1.1-55.fc7 ---------------------------- * Mon Dec 11 2006 Adam Jackson 1.1.1-55 - xorg-x11-server-1.1.1-lid-close-crash.patch: Added, backport from head. (#197921) * Mon Dec 11 2006 Adam Tkac 1.1.1-54.1.fc7 - fixed building against mesa-6.5.2 yum-3.0.1-5.fc7 --------------- * Tue Dec 12 2006 Jeremy Katz - 3.0.1-5 - further python 2.5 fix (Deji Akingunola, #219244) - fix silent failures (#219030) Broken deps for ppc64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ppc64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ppc64 requires libpython2.4.so.1.0()(64bit) php-pgsql - 5.2.0-7.ppc64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.8-1.fc7.noarch requires python-elementtree Broken deps for i386 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.i386 requires libpython2.4.so.1.0 php-pgsql - 5.2.0-7.i386 requires libpq.so.4 setroubleshoot - 1.8.8-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.i386 requires python(abi) = 0:2.4 Broken deps for x86_64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.x86_64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.x86_64 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) php-pgsql - 5.2.0-7.x86_64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.8-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.x86_64 requires python(abi) = 0:2.4 Broken deps for s390 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.s390 requires libpython2.4.so.1.0 php-pgsql - 5.2.0-7.s390 requires libpq.so.4 setroubleshoot - 1.8.8-1.fc7.noarch requires python-elementtree systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ia64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ia64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ia64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ia64 requires libpython2.4.so.1.0()(64bit) php-pgsql - 5.2.0-7.ia64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.8-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.ia64 requires python(abi) = 0:2.4 Broken deps for ppc ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 kdebindings - 3.5.5-1.fc7.ppc requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.ppc requires libpython2.4.so.1.0 php-pgsql - 5.2.0-7.ppc requires libpq.so.4 setroubleshoot - 1.8.8-1.fc7.noarch requires python-elementtree Broken deps for s390x ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.s390x requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390x requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390x requires libpython2.4.so.1.0()(64bit) kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.s390x requires libpython2.4.so.1.0()(64bit) php-pgsql - 5.2.0-7.s390x requires libpq.so.4()(64bit) setroubleshoot - 1.8.8-1.fc7.noarch requires python-elementtree From rc040203 at freenet.de Wed Dec 13 11:40:35 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 13 Dec 2006 12:40:35 +0100 Subject: Call for help with packagaging games for fedora-extras In-Reply-To: References: <1165998583.24534.158.camel@mccallum.corsepiu.local> <457FBC9D.6020307@fedoraproject.org> <457FC35F.6020200@fedoraproject.org> <457FC624.5010402@fedoraproject.org> <1166002996.24534.203.camel@mccallum.corsepiu.local> Message-ID: <1166010036.24534.220.camel@mccallum.corsepiu.local> On Wed, 2006-12-13 at 11:49 +0100, Rudolf Kastl wrote: > 2006/12/13, Ralf Corsepius : > > Or to put it differently: I guess you (Rudolf) are aware how your > > request sounds to active packagers? > > already answered. i guess you know how that sounds to someone doing > lots of upstream work. Well, then I once again can't avoid being very direct: You are looking for packaging-monkeys to package up and clean up your "semi-functional" pieces. Though taking such role might be interesting to some people, it isn't for me - and you (!), otherwise you've already done it. Also, why would you walking your "semi-functional" packages through a formal review, be a waste of time? It isn't, it is a formalized way to bring this "semi-functional" specs into shape - it's a kind of development process - In the end, all ends, Fedora, you (nrpms) and upstream would profit from it - The only difference to you would be having to collaborate with others. Ralf From che666 at gmail.com Wed Dec 13 12:51:13 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 13 Dec 2006 13:51:13 +0100 Subject: Call for help with packagaging games for fedora-extras In-Reply-To: <1166010036.24534.220.camel@mccallum.corsepiu.local> References: <457FBC9D.6020307@fedoraproject.org> <457FC35F.6020200@fedoraproject.org> <457FC624.5010402@fedoraproject.org> <1166002996.24534.203.camel@mccallum.corsepiu.local> <1166010036.24534.220.camel@mccallum.corsepiu.local> Message-ID: 2006/12/13, Ralf Corsepius : > On Wed, 2006-12-13 at 11:49 +0100, Rudolf Kastl wrote: > > 2006/12/13, Ralf Corsepius : > > > > > Or to put it differently: I guess you (Rudolf) are aware how your > > > request sounds to active packagers? > > > > already answered. i guess you know how that sounds to someone doing > > lots of upstream work. > Well, then I once again can't avoid being very direct: You are looking > for packaging-monkeys to package up and clean up your "semi-functional" > pieces. > > Though taking such role might be interesting to some people, it isn't > for me - and you (!), otherwise you've already done it. if i had frequently time to maintain it sure i would have done it. if its not interesting for you i guess you should probably just ignore my call for help because then you are obviously not a member of the intended audience. > > Also, why would you walking your "semi-functional" packages through a > formal review, be a waste of time? It isn't, it is a formalized way to > bring this "semi-functional" specs into shape - it's a kind of > development process - i believe in collaborative development. well i can for sure submit the specs for review but then youd throw the "its not a dump" argument against me, because of the lack of time to maintain the stuff in the end. i am currently busy with doing software qa and fixing stuff upstream to make things packageable at all. software qa is not part of the review process as per definition so it probably should be done before submission and before throwing the software at end users. If other people want to do the upstream work i have time for packaging but then i cant garantue that i have inet and time within a certain time period to update the packages e.g. incase of a security problem etc... thats why i offered co maintainership and help for anyone that is interested in taking those packages into fe. (somehow i get the feeling i already mentioned that in a previous email to the list) In the end, all ends, Fedora, you (nrpms) and > upstream would profit from it - The only difference to you would be > having to collaborate with others. i am not doing nrpms (nrpms is not newrpms) and i dont have time anymore to maintain a repo with all the qa i personally think is necassery to drive it. and collaboration is the reason i wrote this mail to the list at all in the hope to get constructive feedback or help people interested. Collecting the specs would especially enable people to do collaborative work and prevent wheel reinvention which would result in less time and effort for the individual maintainer of the package. regards, Rudolf Kastl > > Ralf > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From j.w.r.degoede at hhs.nl Wed Dec 13 13:07:37 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 13 Dec 2006 14:07:37 +0100 Subject: Call for help with packagaging games for fedora-extras In-Reply-To: References: Message-ID: <457FFB19.50803@hhs.nl> Rudolf Kastl wrote: > Hello to you! > > First of all i want you to know the following facts: > > 1. there are people dedicated to games packaging but those people > maintain a really huge number of packages. > > 2. there are lots of very interesting games, even 3d games that are > not part of extras yet > > So this is why I write this email. We need more people dedicated to > package games. Especially initial packaging of games takes alot work > usually for various reasons. > > If anyone is interested to maintain some of the next generation games > in extras you can either: > > a) look at the games sig on the fedora wiki > b) contact me as i have various things initially packaged but not > ready for extras inclusion also a lack of time to really maintain the > packages in extras because i am too often on the road... but still > sometimes spare time to invest into building initial packages > b) look around for a yet unknown/unpackaged open source game > > What i have ready e.g. would be warzone2100, vdrift (vdrift.net) and a > few others, so if youd like to take those i can send you a halfway > finished spec file. > +1 As one of the primary Game SIG pullers I would like to give this a +1 if not a +10, we could really use a hand, there still is a wealth of good Free games out there which I would like to see packaged, so that I never have to hear the "I don't use Linux as there are no good games" argument ever again. I'm more then willing to help out (coach, fix nasty bugs requireing more C-knowledge then you own, sponsor, in general help) anyone who wishes to join the Games SIG, also if you need a list of games to package I can help there too. BTW artists / level designers are welcome too, it would for example be great if we as Fedora Games SIG could give openquartz the small last boost it needs to offer a fully playable Free quake1. Etc. So to make a long story short, come on and join the FUN! Regards, Hans From che666 at gmail.com Wed Dec 13 13:16:38 2006 From: che666 at gmail.com (Rudolf Kastl) Date: Wed, 13 Dec 2006 14:16:38 +0100 Subject: Call for help with packagaging games for fedora-extras In-Reply-To: <457FFB19.50803@hhs.nl> References: <457FFB19.50803@hhs.nl> Message-ID: 2006/12/13, Hans de Goede : > Rudolf Kastl wrote: > > Hello to you! > > > > First of all i want you to know the following facts: > > > > 1. there are people dedicated to games packaging but those people > > maintain a really huge number of packages. > > > > 2. there are lots of very interesting games, even 3d games that are > > not part of extras yet > > > > So this is why I write this email. We need more people dedicated to > > package games. Especially initial packaging of games takes alot work > > usually for various reasons. > > > > If anyone is interested to maintain some of the next generation games > > in extras you can either: > > > > a) look at the games sig on the fedora wiki > > b) contact me as i have various things initially packaged but not > > ready for extras inclusion also a lack of time to really maintain the > > packages in extras because i am too often on the road... but still > > sometimes spare time to invest into building initial packages > > b) look around for a yet unknown/unpackaged open source game > > > > What i have ready e.g. would be warzone2100, vdrift (vdrift.net) and a > > few others, so if youd like to take those i can send you a halfway > > finished spec file. > > > > +1 > > As one of the primary Game SIG pullers I would like to give this a +1 if > not a +10, we could really use a hand, there still is a wealth of good > Free games out there which I would like to see packaged, so that I never > have to hear the "I don't use Linux as there are no good games" argument > ever again. i know how big the burden is you already carry hans and all i can say is "Thank you!". Theres so much to do in the games area... from evalution testing qa initial packaging to maintainership... between those steps always the "fix bug" and "submit patch" loop. > > I'm more then willing to help out (coach, fix nasty bugs requireing more > C-knowledge then you own, sponsor, in general help) anyone who wishes to > join the Games SIG, also if you need a list of games to package I can > help there too. BTW artists / level designers are welcome too, it would > for example be great if we as Fedora Games SIG could give openquartz the > small last boost it needs to offer a fully playable Free quake1. Etc. +1 for artists / level designers / story writers and all the other non technical tasks that are required. Especially also required for the worldforge project so we have at some point a really free 3d mmorpg. > > So to make a long story short, come on and join the FUN! I couldnt say it in a better way. > > Regards, > > Hans > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From katzj at redhat.com Wed Dec 13 15:43:35 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 13 Dec 2006 10:43:35 -0500 Subject: putting fedora on a (memory) diet... some suggestions for the kernel config In-Reply-To: <1166007393.27217.764.camel@laptopd505.fenrus.org> References: <1166007393.27217.764.camel@laptopd505.fenrus.org> Message-ID: <1166024615.2505.17.camel@aglarond.local> On Wed, 2006-12-13 at 11:56 +0100, Arjan van de Ven wrote: > Another one is __log_buf; this is currently 128Kb. Arguably it's > important for debugging to get 128Kb of dmesg info, but I wonder if 64Kb > would be enough as well, it's another easy save by setting > CONFIG_LOG_BUF_SHIFT to 16. I don't know that this is really a big enough win to be worthwhile... especially as the 128kb of dmesg has been handy to me in the past given the amount of verbosity from some of the kernel these days. > A third one is disabling CPU hotplug. CPU hotplug keeps quite a bit of > code in the kernel, that otherwise is boot-time only and gets evicted > right after boot..... You could argue the same for PCI hotplug but > cardbus is sort of the party spoiler there I suppose. Isn't cpu hotplug needed for sleep/swsusp on multicore laptops? Jeremy From jcm at redhat.com Wed Dec 13 15:59:12 2006 From: jcm at redhat.com (Jon Masters) Date: Wed, 13 Dec 2006 10:59:12 -0500 Subject: putting fedora on a (memory) diet... some suggestions for the kernel config In-Reply-To: <1166024615.2505.17.camel@aglarond.local> References: <1166007393.27217.764.camel@laptopd505.fenrus.org> <1166024615.2505.17.camel@aglarond.local> Message-ID: <1166025552.26949.54.camel@jcm.boston.redhat.com> On Wed, 2006-12-13 at 10:43 -0500, Jeremy Katz wrote: > On Wed, 2006-12-13 at 11:56 +0100, Arjan van de Ven wrote: > > Another one is __log_buf; this is currently 128Kb. Arguably it's > > important for debugging to get 128Kb of dmesg info, but I wonder if 64Kb > > would be enough as well, it's another easy save by setting > > CONFIG_LOG_BUF_SHIFT to 16. > > I don't know that this is really a big enough win to be worthwhile... > especially as the 128kb of dmesg has been handy to me in the past given > the amount of verbosity from some of the kernel these days. Seconded. It's not enough of a saving /and/ reduces the value of having the ringbuffer in the first place if data you want is never there. There's a lot of noise to deal with - arguably that could be reduced, but that's not something to be solved in Fedora directly. Personally, I think kernel config is one of the last places to cleanup after regular apps are taken care of. Jon. From fedora at camperquake.de Wed Dec 13 15:58:55 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 13 Dec 2006 16:58:55 +0100 Subject: putting fedora on a (memory) diet... some suggestions for the kernel config In-Reply-To: <1166024615.2505.17.camel@aglarond.local> References: <1166007393.27217.764.camel@laptopd505.fenrus.org> <1166024615.2505.17.camel@aglarond.local> Message-ID: <20061213165855.63f0e635@banea.int.addix.net> Hi. On Wed, 13 Dec 2006 10:43:35 -0500, Jeremy Katz wrote: > Isn't cpu hotplug needed for sleep/swsusp on multicore laptops? And don't xen guests need this in order to receive more/less VCPUs from the host? From ddutile at redhat.com Wed Dec 13 16:07:01 2006 From: ddutile at redhat.com (Don Dutile) Date: Wed, 13 Dec 2006 11:07:01 -0500 Subject: putting fedora on a (memory) diet... some suggestions for the kernel config In-Reply-To: <1166007393.27217.764.camel@laptopd505.fenrus.org> References: <1166007393.27217.764.camel@laptopd505.fenrus.org> Message-ID: <45802525.4070401@redhat.com> Arjan van de Ven wrote: > Looking at kernel memory use (based on 2.6.19 with a fedora config), > there's some not that hard ways to gain quite a bit of memory back. > > Most important is CONFIG_NR_CPUS, right now that is set to 255 for > everyone; this value is used for scaling a LOT of things in the kernel, > and the sad thing is it's not even possible today to get a 255 > core/processor machine (you run out of apic ids well before you get that > far). > > Setting CONFIG_NR_CPUS to 64 (which is still huge, even 16 would be more > than 99.99999% of the people who use fedora will ever use) will save > The proper solution: kmalloc-based, per-cpu structs; wire to gs(or is it cs) reg like pda is, if performance is an issue. then you only get what you need. > > user 255 64 saving > ---------------------------------------------- > irq_desc 2154496 294912 1859584 > irq_domain 269312 18432 250880 > irq_lists 134656 36864 97792 > irq_2_pin 100992 27648 73344 > irq_timer_state 67328 18432 48896 > msi_desc 67328 18432 48896 > per_cpu__kstat 33728 9280 24448 > ----------------------------------------------- > total 2403839 > > this alone saves 2.4Mb of memory in *static* buffers! Add a bunch more > in smaller buffers and all dynamic kernel allocations and it'll be > closer to 3Mb.. Easy gain right there. > > Another one is __log_buf; this is currently 128Kb. Arguably it's > important for debugging to get 128Kb of dmesg info, but I wonder if 64Kb > would be enough as well, it's another easy save by setting > CONFIG_LOG_BUF_SHIFT to 16. Pls! Size it based on memory: on small mem footprints (256MB), make it 32K; large memory footprints (1G and above) make it 512KB! (a la "I like to make it big for debugging" Jeremy). > > A third one is disabling CPU hotplug. CPU hotplug keeps quite a bit of > code in the kernel, that otherwise is boot-time only and gets evicted > right after boot..... You could argue the same for PCI hotplug but > cardbus is sort of the party spoiler there I suppose. > ditto Jeremy's reply wrt multicore/multi-socket systems (they will be std PC within a year). > > I don't know what Dave will pick for CONFIG_STACK_PROTECTOR_ALL; I would > suggest to turn this off (while enabling the normal > CONFIG_STACK_PROTECTOR); _ALL doesn't add much if any security while it > creates bigger and slower code everywhere. (The difference is that _ALL > forces the canary on every function, while the normal setting only > forces it for functions with buffers on the stack) Another good project: stack utilization reduction. better yet: put tools in place that warn when a function uses X-amt of stack, and analyze those functions/modules for lower stack utilization. > > > > From ddutile at redhat.com Wed Dec 13 16:08:41 2006 From: ddutile at redhat.com (Don Dutile) Date: Wed, 13 Dec 2006 11:08:41 -0500 Subject: putting fedora on a (memory) diet... some suggestions for the kernel config In-Reply-To: <20061213165855.63f0e635@banea.int.addix.net> References: <1166007393.27217.764.camel@laptopd505.fenrus.org> <1166024615.2505.17.camel@aglarond.local> <20061213165855.63f0e635@banea.int.addix.net> Message-ID: <45802589.6050603@redhat.com> Ralf Ertzinger wrote: > Hi. > > On Wed, 13 Dec 2006 10:43:35 -0500, Jeremy Katz wrote: > >> Isn't cpu hotplug needed for sleep/swsusp on multicore laptops? > > And don't xen guests need this in order to receive more/less VCPUs from > the host? > Yes! (as we just turned it on for 4.5-paravirt xenU kernels) From katzj at redhat.com Wed Dec 13 16:12:22 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 13 Dec 2006 11:12:22 -0500 Subject: putting fedora on a (memory) diet... some suggestions for the kernel config In-Reply-To: <20061213165855.63f0e635@banea.int.addix.net> References: <1166007393.27217.764.camel@laptopd505.fenrus.org> <1166024615.2505.17.camel@aglarond.local> <20061213165855.63f0e635@banea.int.addix.net> Message-ID: <1166026342.2505.31.camel@aglarond.local> On Wed, 2006-12-13 at 16:58 +0100, Ralf Ertzinger wrote: > On Wed, 13 Dec 2006 10:43:35 -0500, Jeremy Katz wrote: > > Isn't cpu hotplug needed for sleep/swsusp on multicore laptops? > > And don't xen guests need this in order to receive more/less VCPUs from > the host? Yes, but I wasn't going to use that as my argument as the Xen kernel could be built with different options Jeremy From arjan at fenrus.demon.nl Wed Dec 13 16:49:02 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Wed, 13 Dec 2006 17:49:02 +0100 Subject: putting fedora on a (memory) diet... some suggestions for the kernel config In-Reply-To: <45802525.4070401@redhat.com> References: <1166007393.27217.764.camel@laptopd505.fenrus.org> <45802525.4070401@redhat.com> Message-ID: <1166028542.27217.834.camel@laptopd505.fenrus.org> On Wed, 2006-12-13 at 11:07 -0500, Don Dutile wrote: > Arjan van de Ven wrote: > > Looking at kernel memory use (based on 2.6.19 with a fedora config), > > there's some not that hard ways to gain quite a bit of memory back. > > > > Most important is CONFIG_NR_CPUS, right now that is set to 255 for > > everyone; this value is used for scaling a LOT of things in the kernel, > > and the sad thing is it's not even possible today to get a 255 > > core/processor machine (you run out of apic ids well before you get that > > far). > > > > Setting CONFIG_NR_CPUS to 64 (which is still huge, even 16 would be more > > than 99.99999% of the people who use fedora will ever use) will save > > > The proper solution: kmalloc-based, per-cpu structs; wire to gs(or is it cs) reg > like pda is, if performance is an issue. then you only get what you need. except if you still do it for each cpu. And not all of these are per cpu things at all; they just SCALE with the number of cpus. That's not the same. ANd the IRQ stuff needs to be there long before kmalloc works.. it's not that easy. > Pls! Size it based on memory: on small mem footprints (256MB), make it 32K; > large memory footprints (1G and above) make it 512KB! (a la "I like to make > it big for debugging" Jeremy). logbuf needs to work REAL early, before dynamic allocators work. > better yet: put tools in place that warn when a function uses X-amt of stack, > and analyze those functions/modules for lower stack utilization. like make checkstack ? been there done that 3 years ago ;) From arjan at fenrus.demon.nl Wed Dec 13 16:50:29 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Wed, 13 Dec 2006 17:50:29 +0100 Subject: putting fedora on a (memory) diet... some suggestions for the kernel config In-Reply-To: <45802589.6050603@redhat.com> References: <1166007393.27217.764.camel@laptopd505.fenrus.org> <1166024615.2505.17.camel@aglarond.local> <20061213165855.63f0e635@banea.int.addix.net> <45802589.6050603@redhat.com> Message-ID: <1166028629.27217.836.camel@laptopd505.fenrus.org> On Wed, 2006-12-13 at 11:08 -0500, Don Dutile wrote: > Ralf Ertzinger wrote: > > Hi. > > > > On Wed, 13 Dec 2006 10:43:35 -0500, Jeremy Katz wrote: > > > >> Isn't cpu hotplug needed for sleep/swsusp on multicore laptops? > > > > And don't xen guests need this in order to receive more/less VCPUs from > > the host? > > > > Yes! (as we just turned it on for 4.5-paravirt xenU kernels) good luck if you meant RHEL4.5 ;) HOTPLUG isn't working all that well in 2.6.9 iirc ;) From notting at redhat.com Wed Dec 13 17:22:26 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 13 Dec 2006 12:22:26 -0500 Subject: putting fedora on a (memory) diet... some suggestions for the kernel config In-Reply-To: <1166007393.27217.764.camel@laptopd505.fenrus.org> References: <1166007393.27217.764.camel@laptopd505.fenrus.org> Message-ID: <20061213172226.GC1729@nostromo.devel.redhat.com> Arjan van de Ven (arjan at fenrus.demon.nl) said: > Another one is __log_buf; this is currently 128Kb. Arguably it's > important for debugging to get 128Kb of dmesg info, but I wonder if 64Kb > would be enough as well, it's another easy save by setting > CONFIG_LOG_BUF_SHIFT to 16. 64k of savings I'm not sure is enough - you can get more by whacking userspace. The 2+MB from NR_CPUS looks worthwhile. > A third one is disabling CPU hotplug. CPU hotplug keeps quite a bit of > code in the kernel, that otherwise is boot-time only and gets evicted > right after boot..... You could argue the same for PCI hotplug but > cardbus is sort of the party spoiler there I suppose. Xen and other virt stuff trips you up here. Bill From dwmw2 at infradead.org Wed Dec 13 17:25:11 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 13 Dec 2006 17:25:11 +0000 Subject: putting fedora on a (memory) diet... some suggestions for the kernel config In-Reply-To: <1166007393.27217.764.camel@laptopd505.fenrus.org> References: <1166007393.27217.764.camel@laptopd505.fenrus.org> Message-ID: <1166030711.5253.742.camel@pmac.infradead.org> On Wed, 2006-12-13 at 11:56 +0100, Arjan van de Ven wrote: > Looking at kernel memory use (based on 2.6.19 with a fedora config), > there's some not that hard ways to gain quite a bit of memory back. The kernel is far from the worst offender though: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5253 dwmw2 15 0 1291m 772m 41m S 17 31.3 887:51.74 evolution 3104 root 15 0 325m 133m 16m S 6 5.4 3492:19 Xorg 13295 dwmw2 16 0 257m 133m 21m S 2 5.4 57:30.49 gnome-terminal 30028 dwmw2 15 0 242m 118m 12m S 2 4.8 757:49.44 gnome-terminal 23011 dwmw2 15 0 281m 93m 38m S 2 3.8 7:24.88 firefox-bin -- dwmw2 From jreiser at BitWagon.com Wed Dec 13 17:29:01 2006 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 13 Dec 2006 09:29:01 -0800 Subject: putting fedora on a (memory) diet... some suggestions for the kernel config In-Reply-To: <1166025552.26949.54.camel@jcm.boston.redhat.com> References: <1166007393.27217.764.camel@laptopd505.fenrus.org> <1166024615.2505.17.camel@aglarond.local> <1166025552.26949.54.camel@jcm.boston.redhat.com> Message-ID: <4580385D.1030809@BitWagon.com> Jon Masters wrote: > [snipped discussion about __log_buf specifically, but this seems general:] > Personally, I think kernel config is one of the last places to cleanup > after regular apps are taken care of. Kernel config is the first place to pick low-hanging fruit. Inflating CONFIG_NR_CPUS from 64 to 255 steals 3MB of physical RAM from the entire workload. There are many servers (both in numbers and percentage) with <=4 CPUs and <=1GB RAM where that 3MB could be used much more productively than by sparse static irq_* tables. -- From ddutile at redhat.com Wed Dec 13 17:36:49 2006 From: ddutile at redhat.com (Don Dutile) Date: Wed, 13 Dec 2006 12:36:49 -0500 Subject: putting fedora on a (memory) diet... some suggestions for the kernel config In-Reply-To: <1166028542.27217.834.camel@laptopd505.fenrus.org> References: <1166007393.27217.764.camel@laptopd505.fenrus.org> <45802525.4070401@redhat.com> <1166028542.27217.834.camel@laptopd505.fenrus.org> Message-ID: <45803A31.1020505@redhat.com> Arjan van de Ven wrote: > On Wed, 2006-12-13 at 11:07 -0500, Don Dutile wrote: >> Arjan van de Ven wrote: >>> Looking at kernel memory use (based on 2.6.19 with a fedora config), >>> there's some not that hard ways to gain quite a bit of memory back. >>> >>> Most important is CONFIG_NR_CPUS, right now that is set to 255 for >>> everyone; this value is used for scaling a LOT of things in the kernel, >>> and the sad thing is it's not even possible today to get a 255 >>> core/processor machine (you run out of apic ids well before you get that >>> far). >>> >>> Setting CONFIG_NR_CPUS to 64 (which is still huge, even 16 would be more >>> than 99.99999% of the people who use fedora will ever use) will save >>> >> The proper solution: kmalloc-based, per-cpu structs; wire to gs(or is it cs) reg >> like pda is, if performance is an issue. then you only get what you need. > > except if you still do it for each cpu. > And not all of these are per cpu things at all; they just SCALE with the > number of cpus. That's not the same. > ANd the IRQ stuff needs to be there long before kmalloc works.. it's not > that easy. Yeah, I'll agree this area needs a re-design for scaling as well! ;-) > > >> Pls! Size it based on memory: on small mem footprints (256MB), make it 32K; >> large memory footprints (1G and above) make it 512KB! (a la "I like to make >> it big for debugging" Jeremy). > > logbuf needs to work REAL early, before dynamic allocators work. did this in Tru64-UNIX -- steal memory during early boot, when you know size of memory, before kmalloc in place; it wasn't that tough to do (8 years ago). >> better yet: put tools in place that warn when a function uses X-amt of stack, >> and analyze those functions/modules for lower stack utilization. > > like make checkstack ? been there done that 3 years ago ;) > sounds like we need a time machine... From arjan at fenrus.demon.nl Wed Dec 13 18:03:51 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Wed, 13 Dec 2006 19:03:51 +0100 Subject: putting fedora on a (memory) diet... some suggestions for the kernel config In-Reply-To: <1166030711.5253.742.camel@pmac.infradead.org> References: <1166007393.27217.764.camel@laptopd505.fenrus.org> <1166030711.5253.742.camel@pmac.infradead.org> Message-ID: <1166033031.27217.855.camel@laptopd505.fenrus.org> On Wed, 2006-12-13 at 17:25 +0000, David Woodhouse wrote: > On Wed, 2006-12-13 at 11:56 +0100, Arjan van de Ven wrote: > > Looking at kernel memory use (based on 2.6.19 with a fedora config), > > there's some not that hard ways to gain quite a bit of memory back. > > The kernel is far from the worst offender though: no argument there.. but it's an easy one to get a few megs back From davej at redhat.com Wed Dec 13 18:46:20 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 13 Dec 2006 13:46:20 -0500 Subject: putting fedora on a (memory) diet... some suggestions for the kernel config In-Reply-To: <1166007393.27217.764.camel@laptopd505.fenrus.org> References: <1166007393.27217.764.camel@laptopd505.fenrus.org> Message-ID: <20061213184620.GC969@redhat.com> On Wed, Dec 13, 2006 at 11:56:33AM +0100, Arjan van de Ven wrote: > Setting CONFIG_NR_CPUS to 64 (which is still huge, even 16 would be more > than 99.99999% of the people who use fedora will ever use) will save > ... > total 2403839 > > this alone saves 2.4Mb of memory in *static* buffers! Add a bunch more > in smaller buffers and all dynamic kernel allocations and it'll be > closer to 3Mb.. Easy gain right there. That's definitly worthwhile. I'll make that change for the next FC5/FC6 updates as well as devel. In part this ended up so high because we wanted to see if there were any problems that needed to be fixed. Fixing this stuff now is a lot easier than fixing it post-RHEL5. It's entirely feasible that 256-way CPUs may be around before RHEL5 reaches EOL, (even if they do need apic.c changes etc). > Another one is __log_buf; this is currently 128Kb. Arguably it's > important for debugging to get 128Kb of dmesg info, but I wonder if 64Kb > would be enough as well, it's another easy save by setting > CONFIG_LOG_BUF_SHIFT to 16. As others mentioned, this is a bit of a downside, especially on kernels with lockdep enabled for eg, where the ring buffer gets spent really quickly ;) > A third one is disabling CPU hotplug. CPU hotplug keeps quite a bit of > code in the kernel, that otherwise is boot-time only and gets evicted > right after boot..... Needed for software suspend on SMP. > I don't know what Dave will pick for CONFIG_STACK_PROTECTOR_ALL; I would > suggest to turn this off (while enabling the normal > CONFIG_STACK_PROTECTOR); _ALL doesn't add much if any security while it > creates bigger and slower code everywhere. (The difference is that _ALL > forces the canary on every function, while the normal setting only > forces it for functions with buffers on the stack) Hrmm.. $ grep CONFIG_STACK_PROTECTOR kernel-2.6.19/linux-2.6.19.noarch/configs/* $ Dave -- http://www.codemonkey.org.uk From fs111 at web.de Wed Dec 13 22:49:26 2006 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9_Kelpe?=) Date: Wed, 13 Dec 2006 23:49:26 +0100 Subject: yum In-Reply-To: <16de708d0612130120t16434fabrec0ebbe66f3c4f2e@mail.gmail.com> References: <16de708d0612130120t16434fabrec0ebbe66f3c4f2e@mail.gmail.com> Message-ID: <45808376.1010902@web.de> Arthur Pemberton schrieb: > You may just want to write a module in C to do this. > Before someone does this it might be useful to profile yum and see where the bottlenecks are. Writing slow code is possible in any language and if python can run youtube it should be fast enough for a tool like yum... I heard that the new cProfile in python 2.5 is pretty good, so maybe this is a good starting point. Andr? From pemboa at gmail.com Thu Dec 14 01:36:41 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 14 Dec 2006 19:36:41 +1800 Subject: yum In-Reply-To: <45808376.1010902@web.de> References: <16de708d0612130120t16434fabrec0ebbe66f3c4f2e@mail.gmail.com> <45808376.1010902@web.de> Message-ID: <16de708d0612131736u18c70958h937bf0517ab00301@mail.gmail.com> On 12/14/06, Andr? Kelpe wrote: > Arthur Pemberton schrieb: > > You may just want to write a module in C to do this. > > > Before someone does this it might be useful to profile yum and see where > the bottlenecks are. Writing slow code is possible in any language and > if python can run youtube it should be fast enough for a tool like > yum... I heard that the new cProfile in python 2.5 is pretty good, so > maybe this is a good starting point. > > Andr? > Yah...i've been wondering what's the hold up between Fedora and Python 2.5. Cost me some headaches not having the currently documented version. -- Fedora Core 6 and proud From mattdm at mattdm.org Thu Dec 14 01:43:02 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 13 Dec 2006 20:43:02 -0500 Subject: yum In-Reply-To: <16de708d0612131736u18c70958h937bf0517ab00301@mail.gmail.com> References: <16de708d0612130120t16434fabrec0ebbe66f3c4f2e@mail.gmail.com> <45808376.1010902@web.de> <16de708d0612131736u18c70958h937bf0517ab00301@mail.gmail.com> Message-ID: <20061214014302.GA14423@jadzia.bu.edu> On Thu, Dec 14, 2006 at 07:36:41PM +1800, Arthur Pemberton wrote: > Yah...i've been wondering what's the hold up between Fedora and Python > 2.5. Cost me some headaches not having the currently documented > version. Try rawhide. It's got Python 2.5 as of a few days ago, and various things are in various states of broken while they catch up. Python is one of several things I don't think *should* jump mid-release. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Thu Dec 14 01:49:18 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 20:49:18 -0500 Subject: yum In-Reply-To: <20061214014302.GA14423@jadzia.bu.edu> References: <16de708d0612131736u18c70958h937bf0517ab00301@mail.gmail.com> <20061214014302.GA14423@jadzia.bu.edu> Message-ID: <200612132049.22187.jkeating@redhat.com> On Wednesday 13 December 2006 20:43, Matthew Miller wrote: > Try rawhide. It's got Python 2.5 as of a few days ago, and various things > are in various states of broken while they catch up. Python is one of > several things I don't think *should* jump mid-release. No way in hell. An abi/api change of python would wreak havoc across our software stack. Massive amounts of rebuilds. Not bloody useful in a shipped release. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pemboa at gmail.com Thu Dec 14 01:56:49 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 14 Dec 2006 19:56:49 +1800 Subject: yum In-Reply-To: <20061214014302.GA14423@jadzia.bu.edu> References: <16de708d0612130120t16434fabrec0ebbe66f3c4f2e@mail.gmail.com> <45808376.1010902@web.de> <16de708d0612131736u18c70958h937bf0517ab00301@mail.gmail.com> <20061214014302.GA14423@jadzia.bu.edu> Message-ID: <16de708d0612131756h20e895dl99deb9e617d068ab@mail.gmail.com> On 12/14/06, Matthew Miller wrote: > On Thu, Dec 14, 2006 at 07:36:41PM +1800, Arthur Pemberton wrote: > > Yah...i've been wondering what's the hold up between Fedora and Python > > 2.5. Cost me some headaches not having the currently documented > > version. > > Try rawhide. It's got Python 2.5 as of a few days ago, and various things > are in various states of broken while they catch up. Python is one of > several things I don't think *should* jump mid-release. > Well technically it got updated just about freeze time......so it is not really a mid release update. Oh well. -- Fedora Core 6 and proud From jkeating at redhat.com Thu Dec 14 02:02:41 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 21:02:41 -0500 Subject: yum In-Reply-To: <16de708d0612131756h20e895dl99deb9e617d068ab@mail.gmail.com> References: <20061214014302.GA14423@jadzia.bu.edu> <16de708d0612131756h20e895dl99deb9e617d068ab@mail.gmail.com> Message-ID: <200612132102.41859.jkeating@redhat.com> On Wednesday 13 December 2006 20:56, Arthur Pemberton wrote: > Well technically it got updated just about freeze time......so it is > not really a mid release update. Oh well. A freeze means we think we're done and we're going to shake out any bugs, not we're going to abi bump a critical part of our distribution causing massive rebuilds. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Thu Dec 14 02:52:33 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 13 Dec 2006 21:52:33 -0500 Subject: yum In-Reply-To: <200612132049.22187.jkeating@redhat.com> References: <16de708d0612131736u18c70958h937bf0517ab00301@mail.gmail.com> <20061214014302.GA14423@jadzia.bu.edu> <200612132049.22187.jkeating@redhat.com> Message-ID: <20061214025233.GA16751@jadzia.bu.edu> On Wed, Dec 13, 2006 at 08:49:18PM -0500, Jesse Keating wrote: > > several things I don't think *should* jump mid-release. > No way in hell. An abi/api change of python would wreak havoc across our > software stack. Massive amounts of rebuilds. Not bloody useful in a > shipped release. Just to be clear, you're agreeing with me. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Thu Dec 14 02:53:37 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 13 Dec 2006 21:53:37 -0500 Subject: yum In-Reply-To: <20061214025233.GA16751@jadzia.bu.edu> References: <200612132049.22187.jkeating@redhat.com> <20061214025233.GA16751@jadzia.bu.edu> Message-ID: <200612132153.37680.jkeating@redhat.com> On Wednesday 13 December 2006 21:52, Matthew Miller wrote: > On Wed, Dec 13, 2006 at 08:49:18PM -0500, Jesse Keating wrote: > > > several things I don't think *should* jump mid-release. > > > > No way in hell. ?An abi/api change of python would wreak havoc across our > > software stack. Massive amounts of rebuilds. Not bloody useful in a > > shipped release. > > Just to be clear, you're agreeing with me Heh, yeah, a very emphatic +1 (: -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Thu Dec 14 02:59:12 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 13 Dec 2006 21:59:12 -0500 Subject: yum In-Reply-To: <16de708d0612131736u18c70958h937bf0517ab00301@mail.gmail.com> References: <16de708d0612130120t16434fabrec0ebbe66f3c4f2e@mail.gmail.com> <45808376.1010902@web.de> <16de708d0612131736u18c70958h937bf0517ab00301@mail.gmail.com> Message-ID: <1166065152.2508.9.camel@aglarond.local> On Thu, 2006-12-14 at 19:36 +0000, Arthur Pemberton wrote: > Yah...i've been wondering what's the hold up between Fedora and Python > 2.5. Cost me some headaches not having the currently documented > version. We looked at the possibility of doing python 2.5 for FC6, but with the original schedule of FC6 overlaid with the python 2.5 schedule, it just didn't look like python 2.5 would be out in time. Always a matter of trade-offs for deciding the right time to rev a major system component Jeremy From pemboa at gmail.com Thu Dec 14 07:55:13 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 14 Dec 2006 01:55:13 -0600 Subject: Removable of manual display configuration on first boot (FC6) Message-ID: <16de708d0612132355l5669108dl550eb17f2d9bfe53@mail.gmail.com> I would like to inquire as to why configuration of display settings was removed from first boot. As it is, xorg often ignores resolutions set by system-config-display, but now I'm not evening being given the chance to be ignored, and frankly Fedora is terrible at guessing display settings (from the past 4 FC6 install I've done). In the latest install, FC6 correctly detected the VGA and monitor, but botched the autoconfig enough that LCD blanked out (display out of range) - fixing this was troublesome enough - and I've yet to get xorg to accept the resolution as I set t exactly from system-config-display. I was thinking of filing a bug report, but I figured that I should better ask questions here first. Thanks Arthur Pemberton -- Fedora Core 6 and proud From sundaram at fedoraproject.org Thu Dec 14 09:03:32 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 14 Dec 2006 14:33:32 +0530 Subject: Removable of manual display configuration on first boot (FC6) In-Reply-To: <16de708d0612132355l5669108dl550eb17f2d9bfe53@mail.gmail.com> References: <16de708d0612132355l5669108dl550eb17f2d9bfe53@mail.gmail.com> Message-ID: <45811364.8020705@fedoraproject.org> Arthur Pemberton wrote: > I would like to inquire as to why configuration of display settings > was removed from first boot. As it is, xorg often ignores resolutions > set by system-config-display, but now I'm not evening being given the > chance to be ignored, and frankly Fedora is terrible at guessing > display settings (from the past 4 FC6 install I've done). In the > latest install, FC6 correctly detected the VGA and monitor, but > botched the autoconfig enough that LCD blanked out (display out of > range) - fixing this was troublesome enough - and I've yet to get xorg > to accept the resolution as I set t exactly from > system-config-display. > > I was thinking of filing a bug report, but I figured that I should > better ask questions here first. I think the answer is that Xorg is moving into the direction of getting things working properly by default by instead of having the user fiddle with settings. The Xorg auto configuration mechanism in FC6 works better and usually gets things right. If there are problems file bug reports and help fix the issue rather than workaround it with configuration tools and files manually. For Xorg 7.3, the plan is to use HAL and DBus to enhance this further. Also see http://fedoraproject.org/wiki/XInFC7 Rahul From pekkas at netcore.fi Thu Dec 14 09:16:58 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 14 Dec 2006 11:16:58 +0200 (EET) Subject: Updates dependency/conflict checking Message-ID: Hi, With FC6 and updates-testing, I've gotten the following error for almost a week now: Transaction Check Error: file /usr/bin/pdftoppm from install of poppler-utils-0.5.4-3.fc6 conflicts with file from package xpdf-utils-3.01-26.fc6 file /usr/share/man/man1/pdftoppm.1.gz from install of poppler-utils-0.5.4-3.fc6 conflicts with file from package xpdf-utils-3.01-26.fc6 Looking at CVS, this appears to have been fixed 5 hours ago [1], but the more generic question remains: This isn't the first time this has happened. Shouldn't there be a tool (or automatic check) with updates system that would check for conflicts across all the packages in "official" Fedora repositories? [1] http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219033 -- 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 buildsys at redhat.com Thu Dec 14 11:15:00 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 14 Dec 2006 06:15:00 -0500 Subject: rawhide report: 20061214 changes Message-ID: <200612141115.kBEBF0r2009859@hs20-bc2-6.build.redhat.com> Updated Packages: autofs-1:5.0.1-0.rc2.38 ----------------------- * Thu Dec 14 2006 Ian Kent - 5.0.1-0.rc2.38 - update master map tokenizer to admit "slasify-colons" option. - update location validation to accept "_" (bz 219445). - set close-on-exec flag on open sockets (bz 215757). dvd+rw-tools-7.0-0.fc7.3 ------------------------ * Wed Dec 13 2006 Harald Hoyer - 7.0-0.fc7.3 - use _SC_PHYS_PAGES instead of _SC_AVPHYS_PAGES to determine available memory - Resolves: rhbz#216794 * Fri Nov 03 2006 Harald Hoyer - 7.0-0.fc7.2 - define RLIMIT_MEMLOCK, which should resolve the memlock problems firstboot-1.4.27-1.fc7 ---------------------- * Wed Dec 13 2006 Chris Lumens 1.4.27-1 - More translation updates (#212958, #198872). openoffice.org-1:2.1.0-6.7 -------------------------- * Wed Dec 13 2006 Caolan McNamara - 1:2.1.0-6.7 - split out english dictionaries into hunspell-en * Tue Dec 12 2006 Caolan McNamara - 1:2.1.0-6.6 - Resolves: rhbz#219161 openoffice.org-2.1.0.ooo72505.vcl.wrongrole.patch pirut-1.2.10-1.fc7 ------------------ * Wed Dec 13 2006 James Bowes - 1.2.10-1 - Don't show 'No updates available' on mouse scroll (David Timms, #219075) - Fix traceback in progress.py (katzj, #218417) - Add man pages (#218731) * Thu Nov 30 2006 Jeremy Katz - 1.2.9-1 - rpmlint fixes to packaging (jbowes) - translation fixes (#212877) - Disable linking to bugs and CVEs to avoid launching firefox as root (lmacken, #216552) - translation updates * Fri Nov 10 2006 Jeremy Katz - 1.2.8-1 - Clear deps on transaction cancel (#213421) - Make puplet text be "View Updates..." (#214627) - More verbose error for yum-updatesd not being available (#213520) - Stick information about a package requiring a reboot in the details (#214794) poppler-0.5.4-4.fc7 ------------------- * Wed Dec 13 2006 Matthias Clasen - 0.5.4-4 - Add Provides/Obsoletes for xpdf-utils (#219033) python-2.5-5.fc7 ---------------- * Wed Dec 13 2006 Jarod Wilson - 2.5.3-5 - fix invalid assert in debug mode (upstream changeset 52622) rsh-0.17-38.fc7 --------------- * Tue Dec 05 2006 Adam Tkac 0.17-38.fc7 - rsh now load pan_env module correctly selinux-policy-2.4.6-11.fc7 --------------------------- * Tue Dec 12 2006 Dan Walsh 2.4.6-11 Resolves: #218978 setools-3.0-2.fc7 ----------------- * Wed Dec 13 2006 Adam Jackson 3.0-2 - Rebuild with dist tag, fixes 6 to 7 upgrades. setroubleshoot-1.8.9-1.fc7 -------------------------- * Sat Dec 09 2006 Dan Walsh - 1.8.9-1 - Additional Translations Resolves: #216575 * Fri Dec 08 2006 Dan Walsh - 1.8.8-1 - Additional Translations - Change sealert to be able to run without X-Windows Resolves: #216575 * Fri Dec 08 2006 Dan Walsh - 1.8.7-1 - Additional Translations - Change avc_audit.py to allow it to analyze /var/log/messages sysklogd-1.4.1-43.fc7 --------------------- * Wed Dec 13 2006 Peter Vrabec 1.4.1-43 - fix some rpmlint issues * Sat Dec 09 2006 Peter Vrabec 1.4.1-42 - fix IPv6 patch * Thu Nov 23 2006 Peter Vrabec 1.4.1-41 - improve IPv6 patch system-config-date-1.8.10-1.fc7 ------------------------------- * Wed Dec 13 2006 Nils Philippsen 1.8.10 - pick up updated translations (#216073) * Fri Nov 24 2006 Nils Philippsen 1.8.9 - pick up updated translations (#216073) * Tue Nov 21 2006 Nils Philippsen - revamp timezone potfile generation a bit - pick up new timezones for translation (#216073) system-config-users-1.2.50-1.fc7 -------------------------------- * Wed Dec 13 2006 Nils Philippsen - 1.2.50 - pick up updated translations (#216396) * Fri Nov 24 2006 Nils Philippsen - 1.2.49 - pick up updated translations (#216396) vnc-4.1.2-8.1.fc7 ----------------- * Wed Dec 13 2006 Adam Tkac 4.1.2-8.1.fc7 - changed __ppc64__ to __ppc__ in vnc-render.patch all powerpc has render enabled by default, other archs no * Mon Dec 11 2006 Adam Tkac 4.1.2-8.fc7 - fixed building against mesa-6.5.2 * Tue Dec 05 2006 Adam Tkac 4.1.2-7.2.fc7 - fixed vnc-102434.patch - potential buffer overflow error - only ppc64 architecture has enabled render extensions default (conflict between glx&render) Broken deps for i386 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.i386 requires libpython2.4.so.1.0 openoffice.org-core - 1:2.1.0-6.7.i386 requires hunspell-en php-pgsql - 5.2.0-7.i386 requires libpq.so.4 setroubleshoot - 1.8.9-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.i386 requires python(abi) = 0:2.4 Broken deps for ppc64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ppc64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ppc64 requires libpython2.4.so.1.0()(64bit) php-pgsql - 5.2.0-7.ppc64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.9-1.fc7.noarch requires python-elementtree Broken deps for x86_64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.x86_64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.x86_64 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.i386 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) kdeedu - 3.5.5-0.1.fc6.i386 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) openoffice.org-core - 1:2.1.0-6.7.x86_64 requires hunspell-en php-pgsql - 5.2.0-7.x86_64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.9-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.x86_64 requires python(abi) = 0:2.4 Broken deps for ppc ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 kdebindings - 3.5.5-1.fc7.ppc requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.ppc requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ppc requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.ppc requires libpython2.4.so.1.0 openoffice.org-core - 1:2.1.0-6.7.ppc requires hunspell-en php-pgsql - 5.2.0-7.ppc requires libpq.so.4 setroubleshoot - 1.8.9-1.fc7.noarch requires python-elementtree Broken deps for s390 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeutils - 6:3.5.5-1.fc7.s390 requires libpython2.4.so.1.0 php-pgsql - 5.2.0-7.s390 requires libpq.so.4 setroubleshoot - 1.8.9-1.fc7.noarch requires python-elementtree systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.ia64 requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.ia64 requires python-abi = 0:2.4 kdeedu - 3.5.5-0.1.fc6.ia64 requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.ia64 requires libpython2.4.so.1.0()(64bit) php-pgsql - 5.2.0-7.ia64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.9-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.ia64 requires python(abi) = 0:2.4 Broken deps for s390x ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) kdebindings - 3.5.5-1.fc7.s390x requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390x requires python(abi) = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python-abi = 0:2.4 kdebindings - 3.5.5-1.fc7.s390 requires python(abi) = 0:2.4 kdeedu - 3.5.5-0.1.fc6.s390 requires libpython2.4.so.1.0 kdeedu - 3.5.5-0.1.fc6.s390x requires libpython2.4.so.1.0()(64bit) kdeutils - 6:3.5.5-1.fc7.s390x requires libpython2.4.so.1.0()(64bit) php-pgsql - 5.2.0-7.s390x requires libpq.so.4()(64bit) setroubleshoot - 1.8.9-1.fc7.noarch requires python-elementtree From tmus at tmus.dk Thu Dec 14 11:17:16 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 14 Dec 2006 12:17:16 +0100 Subject: Updates dependency/conflict checking In-Reply-To: References: Message-ID: Pekka Savola wrote: > Hi, > > With FC6 and updates-testing, I've gotten the following error for almost > a week now: > > Transaction Check Error: file /usr/bin/pdftoppm from install of > poppler-utils-0.5.4-3.fc6 conflicts with file from package > xpdf-utils-3.01-26.fc6 > file /usr/share/man/man1/pdftoppm.1.gz from install of > poppler-utils-0.5.4-3.fc6 conflicts with file from package > xpdf-utils-3.01-26.fc6 > > Looking at CVS, this appears to have been fixed 5 hours ago [1], but the > more generic question remains: > > This isn't the first time this has happened. Shouldn't there be a tool > (or automatic check) with updates system that would check for conflicts > across all the packages in "official" Fedora repositories? > > [1] > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219033 > Yet another real-life example, why it would be extremely useful to have a yum feature to simply ignore problematic packages during an update. Although it really *should* not happen too often with the production repos, we've seen it time and time again. Often due to incomplete mirroring and such. But regardless of the reason, the problem remains. I've seen and tried the --ignore-broken (yum plugin) option which, while it's intentions are good, has never actually made a difference, when I've had dependency problems during an update. /Thomas From clumens at redhat.com Thu Dec 14 15:29:23 2006 From: clumens at redhat.com (Chris Lumens) Date: Thu, 14 Dec 2006 10:29:23 -0500 Subject: Removable of manual display configuration on first boot (FC6) In-Reply-To: <45811364.8020705@fedoraproject.org> References: <16de708d0612132355l5669108dl550eb17f2d9bfe53@mail.gmail.com> <45811364.8020705@fedoraproject.org> Message-ID: <20061214152923.GD1043@exeter.boston.redhat.com> > I think the answer is that Xorg is moving into the direction of getting > things working properly by default by instead of having the user fiddle > with settings. The Xorg auto configuration mechanism in FC6 works better > and usually gets things right. If there are problems file bug reports > and help fix the issue rather than workaround it with configuration > tools and files manually. For Xorg 7.3, the plan is to use HAL and DBus > to enhance this further. Also see http://fedoraproject.org/wiki/XInFC7 Yes, this is exactly right. We need to be improving autoconfiguration instead of relying on that display module more. If anyone is having problems with the autoconfig results, please file bugs about it. This stuff is still a little rough around the edges, particularly in the kickstart case (yet another thing on my todo list...) - Chris From cra at WPI.EDU Thu Dec 14 16:08:25 2006 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 14 Dec 2006 11:08:25 -0500 Subject: Updates dependency/conflict checking In-Reply-To: References: Message-ID: <20061214160825.GC4408@angus.ind.WPI.EDU> On Thu, Dec 14, 2006 at 11:16:58AM +0200, Pekka Savola wrote: > This isn't the first time this has happened. Shouldn't there be a > tool (or automatic check) with updates system that would check for > conflicts across all the packages in "official" Fedora repositories? I'm thinking of implementing a double-buffer system that checks for repo closure before pushing updates to the local repo that my clients point to. From jreiser at BitWagon.com Thu Dec 14 17:28:23 2006 From: jreiser at BitWagon.com (John Reiser) Date: Thu, 14 Dec 2006 09:28:23 -0800 Subject: Removable of manual display configuration on first boot (FC6) In-Reply-To: <20061214152923.GD1043@exeter.boston.redhat.com> References: <16de708d0612132355l5669108dl550eb17f2d9bfe53@mail.gmail.com> <45811364.8020705@fedoraproject.org> <20061214152923.GD1043@exeter.boston.redhat.com> Message-ID: <458189B7.7010407@BitWagon.com> > ... If anyone is having > problems with the autoconfig results, please file bugs about it. Such as: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208712 video out of range on graphical install from rescue CD on PowerPC which has been there for two months with no action. FC6 final release still has the problem. -- From mmcgrath at fedoraproject.org Thu Dec 14 20:35:37 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Thu, 14 Dec 2006 14:35:37 -0600 Subject: SCM Sig Message-ID: <3237e4410612141235o3e7a432ay7693184a01c455f1@mail.gmail.com> We need a one time SIG to discuss the future of our version control systems (CVS, SVN, mercurial, git?) Interested parties please add approperate information to the SIG page: http://fedoraproject.org/wiki/Infrastructure/SCMSig (GIT and mercurial users especially requested) We will be sending out the initial meeting notes in 1 week. -Mike From chris at tylers.info Thu Dec 14 21:23:51 2006 From: chris at tylers.info (Chris Tyler) Date: Thu, 14 Dec 2006 16:23:51 -0500 Subject: Removable of manual display configuration on first boot (FC6) In-Reply-To: <20061214170004.2953373614@hormel.redhat.com> References: <20061214170004.2953373614@hormel.redhat.com> Message-ID: <1166131431.14116.25.camel@concord2.proximity.on.ca> Chris Lumens wrote: > Rahul Sundaram wrote: > > I think the answer is that Xorg is moving into the direction of getting > > things working properly by default by instead of having the user fiddle > > with settings. The Xorg auto configuration mechanism in FC6 works better > > and usually gets things right. If there are problems file bug reports > > and help fix the issue rather than workaround it with configuration > > tools and files manually. For Xorg 7.3, the plan is to use HAL and DBus > > to enhance this further. Also see http://fedoraproject.org/wiki/XInFC7 > > Yes, this is exactly right. We need to be improving autoconfiguration > instead of relying on that display module more. If anyone is having > problems with the autoconfig results, please file bugs about it. This > stuff is still a little rough around the edges, particularly in the > kickstart case (yet another thing on my todo list...) > > - Chris This is a right direction to go -- but what about situations where it just can't work? For example, in the electronic classroom configuration where I teach, the video output from the podium PC goes to a video splitter which drives an LCD panel and an LCD projector. Each of those devices has an optimal/native resolution, but the splitter prevents the use of DDC to get the monitor specs (and rightly so, because the devices may have different specs). The XInFC7 wiki page just says that we need to be able to remember/bind EDIDs, but there are many cases like this where we won't *get* an EDID at all, ever, and defaulting to the lowest common denominator is "decidedly suboptimal". We can't switch entirely to autoconfiguration. -Chris From pemboa at gmail.com Thu Dec 14 21:32:26 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 14 Dec 2006 15:32:26 -0600 Subject: Removable of manual display configuration on first boot (FC6) In-Reply-To: <45811364.8020705@fedoraproject.org> References: <16de708d0612132355l5669108dl550eb17f2d9bfe53@mail.gmail.com> <45811364.8020705@fedoraproject.org> Message-ID: <16de708d0612141332g4f6402f8mb513e1d9b0637ba9@mail.gmail.com> On 12/14/06, Rahul Sundaram wrote: > Arthur Pemberton wrote: > > I would like to inquire as to why configuration of display settings > > was removed from first boot. As it is, xorg often ignores resolutions > > set by system-config-display, but now I'm not evening being given the > > chance to be ignored, and frankly Fedora is terrible at guessing > > display settings (from the past 4 FC6 install I've done). In the > > latest install, FC6 correctly detected the VGA and monitor, but > > botched the autoconfig enough that LCD blanked out (display out of > > range) - fixing this was troublesome enough - and I've yet to get xorg > > to accept the resolution as I set t exactly from > > system-config-display. > > > > I was thinking of filing a bug report, but I figured that I should > > better ask questions here first. > > I think the answer is that Xorg is moving into the direction of getting > things working properly by default by instead of having the user fiddle > with settings. The Xorg auto configuration mechanism in FC6 works better > and usually gets things right. If there are problems file bug reports > and help fix the issue rather than workaround it with configuration > tools and files manually. For Xorg 7.3, the plan is to use HAL and DBus > to enhance this further. Also see http://fedoraproject.org/wiki/XInFC7 > > Rahul > Until the process gets better, it would be nice if the config tool was still available on firstboot. As it is, if I didn't know what to do (because this happens to me so often) I would be stuck. I had to power down the machine, reboot, go to run level 3 , login , and then run the display config tool. As opposed to before, I would just have my display config settings ignored, and I'd be stuck on a poor but viewable display. I will try to file a report on the latest one - what data should I include? and what should I file against? And just to put this out there, some of you may have noticed that some dude strongly believes that FC killed some of his LCD's functionality - i don't really believe his case, but up on till yesterday, i had never had fedora completely blank out my display either. All this also explains why my desktop boots into a different resolution when my monitor is off than when it is on - was baffled by this until now. Restarting X normally fixes this issue, so I didn't bother with it. But I dare say this can be very worrying behavior. -- Fedora Core 6 and proud From ajackson at redhat.com Thu Dec 14 21:46:51 2006 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 14 Dec 2006 16:46:51 -0500 Subject: Removable of manual display configuration on first boot (FC6) In-Reply-To: <1166131431.14116.25.camel@concord2.proximity.on.ca> References: <20061214170004.2953373614@hormel.redhat.com> <1166131431.14116.25.camel@concord2.proximity.on.ca> Message-ID: <1166132811.7683.353.camel@localhost.localdomain> On Thu, 2006-12-14 at 16:23 -0500, Chris Tyler wrote: > This is a right direction to go -- but what about situations where it > just can't work? > > For example, in the electronic classroom configuration where I teach, > the video output from the podium PC goes to a video splitter which > drives an LCD panel and an LCD projector. Each of those devices has an > optimal/native resolution, but the splitter prevents the use of DDC to > get the monitor specs (and rightly so, because the devices may have > different specs). In the RANDR 1.2 world you can DDC at runtime too and reconfigure on the fly, and we can set pipes to arbitrary resolutions when we don't get DDC (or even when we do). This dynamicism simply is not present in the RANDR in Xorg 7.2, and there really is no satisfactory way to fake it with s-c-d. In the example you mention, X would come up at a safe mode, and you'd force it higher with the resolution applet, and X would serialize that setting to disk somewhere (probably _not_ in the config file) so that it comes up right the next time. _That_ is the model you want. > The XInFC7 wiki page just says that we need to be able to remember/bind > EDIDs, but there are many cases like this where we won't *get* an EDID > at all, ever, and defaulting to the lowest common denominator is > "decidedly suboptimal". We can't switch entirely to autoconfiguration. Oh yes we can. Just not in FC6. Sorry, everyone sucks this bad right now. One can either paper up s-c-d as pretty as possible for RANDR 1.1, or on make RANDR 1.2 work across all drivers. They'll take comparable amounts of time, so 1.2 _really_ is better. If someone has a more pressing need for s-c-d to work better nownownow, well, I do take patches. But I straight-up suck at GUI programming, and it's a worse return on investment compared to fixing RANDR, so my natural preference is to let s-c-d languish. By the time 1.2 is deployable, s-c-d will need a big enough facelift anyway that it's nearly wasted effort to work on it now. - ajax From rodd at clarkson.id.au Fri Dec 15 02:29:15 2006 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Fri, 15 Dec 2006 13:29:15 +1100 Subject: With GL based desktops, how relevant in screen resolution? Message-ID: <1166149755.3537.47.camel@localhost.localdomain> (These aren't completely new thoughts, I've heard them discussed before, but I thought that with the advent of a GL based desktop for Fedora it might be interesting to have this discussion.) How relevant is screen resolution now that my desktop is now GL based. For example, while screen resolutions used to be important regarding the number of pixels on the screen, I can't help but wonder why resizing a screen should be based on pixels anymore. For example, rather than having to pick a new resolution to make my desktop (fonts, titlebars, etc.) look bigger or smaller, couldn't we now just have a slider that makes the desktop appear bigger or smaller? Another example. (This is what got me thinking about this). If I've got an application that works at a particular size (say 800x600 in the old measure) and I want it a different size, what's stopping us from being able to proportionally re-size a window to make it smaller or larger? This might be useful for games, or if you want to resize a mozilla window to make the fonts larger, but keep the layout proportional including images. What do people think? Is this just madness, or are we very close to being able to do this sort of thing. R. -- "It's a fine line between denial and faith. It's much better on my side" From tmus at tmus.dk Fri Dec 15 08:23:09 2006 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 15 Dec 2006 09:23:09 +0100 Subject: Updates dependency/conflict checking In-Reply-To: <20061214160825.GC4408@angus.ind.WPI.EDU> References: <20061214160825.GC4408@angus.ind.WPI.EDU> Message-ID: Chuck Anderson wrote: > On Thu, Dec 14, 2006 at 11:16:58AM +0200, Pekka Savola wrote: >> This isn't the first time this has happened. Shouldn't there be a >> tool (or automatic check) with updates system that would check for >> conflicts across all the packages in "official" Fedora repositories? > > I'm thinking of implementing a double-buffer system that checks for > repo closure before pushing updates to the local repo that my clients > point to. > Yeah, that kind of workaround could solve the problem for larger installations. My point with this is, that yum (and other software updating tools) should always try to do the best they can, with what they've got. If it's missing parts of a header, clearly that package cannot be updated. But that's no reason to skip other updates that do not have a problem. Same thing for deps. If a package is missing a dep, we cannot update that package, period. But all the other updates that have no problems should still not be ignored. /Thomas From nicolas.mailhot at laposte.net Fri Dec 15 08:30:50 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 15 Dec 2006 09:30:50 +0100 (CET) Subject: With GL based desktops, how relevant in screen resolution? In-Reply-To: <1166149755.3537.47.camel@localhost.localdomain> References: <1166149755.3537.47.camel@localhost.localdomain> Message-ID: <41574.192.54.193.51.1166171450.squirrel@rousalka.dyndns.org> Le Ven 15 d?cembre 2006 03:29, Rodd Clarkson a ?crit : > How relevant is screen resolution now that my desktop is now GL based. > For example, rather than having to pick a new resolution to make my > desktop (fonts, titlebars, etc.) look bigger or smaller, Screen resolution should be orthogonal to font scaling, you don't get text twice as big when switching from 600 to 1200 dpi printers. That it has been used in the past to control font scaling is the abuse of broken implementation unfortunate side-effects > couldn't we now > just have a slider that makes the desktop appear bigger or smaller? There is still the slight problem of all the bitmap artwork, though it could certainly be scaled by discrete levels (and apps just have to expect it, just like they had to learn i18n means variable-length text strings) Also given the poor resolution of current screens you certainly want the highest possible resolution regardless of the user-selected scale, if only to have sharp fonts and avoid the mess freetype autohinting is[1]. Just moving from 100 to 125 dpi improves the font rendering tremendously (and I'm not even talking about OLPC-like resolutions) [1] That's not to say the freetype hackers are bad, but if autohinting was easy no one would have specified manual hinting in the first place Regards, -- Nicolas Mailhot From buildsys at redhat.com Fri Dec 15 11:06:33 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Fri, 15 Dec 2006 06:06:33 -0500 Subject: rawhide report: 20061215 changes Message-ID: <200612151106.kBFB6XkN014471@hs20-bc2-6.build.redhat.com> Updated Packages: cairo-1.3.8-1.fc7 ----------------- * Thu Dec 14 2006 Carl Worth 1.3.8-1 - Update to 1.3.8 * Sat Dec 09 2006 Matthias Clasen 1.3.6-2 - Small spec file cleanups * Wed Dec 06 2006 Matthias Clasen 1.3.6-1 - Update to 1.3.6 cpuspeed-1:1.2.1-1.46.fc7 ------------------------- * Thu Dec 14 2006 Jarod Wilson - Set lock file for centrino/powernow-k8 so status indicates we do have scaling working - Fix up centrino/powernow-k8 stop function (#213999) dvd+rw-tools-7.0-2.fc7 ---------------------- * Thu Dec 14 2006 Harald Hoyer - 7.0-0.fc7.4 - set pthread stack size according to limit (#215818) ethtool-5-1.fc7 --------------- * Thu Dec 14 2006 Jay Fenlason 5-1 - Upgrade to ethtool version 5 to close bz#184985: RFE: 10gigE support bz#204840: "buffer overflow detected" when devname's length >=16 of ethtool Resolves: #184985, #204840 glibc-2.5.90-13 --------------- * Thu Dec 14 2006 Jakub Jelinek 2.5.90-13 - fix setcontext on ppc32 (#219107) - fix wide stdio after setvbuf (#217064, BZ#2337) - handle realtime mount option in statvfs - revert i?86/x86_64 clone CFI temporarily kdebindings-3.5.5-4.fc7 ----------------------- * Thu Dec 14 2006 Karsten Hopp 3.5.5-4 - use correct types * Tue Dec 12 2006 Karsten Hopp 3.5.5-3 - fix automake check * Thu Dec 07 2006 Jeremy Katz - 3.5.5-2 - rebuild for python 2.5 kdeedu-3.5.4-2.fc7 ------------------ * Thu Dec 14 2006 Karsten Hopp 3.5.4-2 - fix automake version check * Thu Aug 10 2006 Than Ngo 3.5.4-1 - rebuild * Mon Jul 24 2006 Than Ngo 3.5.4-0.pre1 - prerelease of 3.5.4 (from the first-cut tag) kdeutils-6:3.5.5-3.fc7 ---------------------- * Thu Dec 14 2006 Karsten Hopp 3.5.5-3 - ExcludeArch: ppc64 (#219629) * Thu Dec 14 2006 Karsten Hopp 3.5.5-2 - rebuild with python-2.5 kernel-2.6.19-1.2877.fc7 ------------------------ * Thu Dec 14 2006 Dave Jones - 2.6.20rc1 - libata: don't initialize sg in ata_exec_internal() if DMA_NONE * Wed Dec 13 2006 Dave Jones - Kill off -kdump for 686. * Wed Dec 13 2006 David Woodhouse - Fix and re-enable ppc, ppc64, ppciseries builds - Fix hdrcheck.sh invocation - %_target_cpu in BuildRoot to allow parallel builds lvm2-2.02.17-1.fc7 ------------------ * Thu Dec 14 2006 Alasdair Kergon - 2.02.17-1 - Add missing pvremove error message when device doesn't exist. - When lvconvert allocates a mirror log, respect parallel area constraints. - Check for failure to allocate just the mirror log. - Support mirror log allocation when there is only one PV: area_count now 0. - Fix detection of smallest area in _alloc_parallel_area() for cling policy. - Add manpage entry for clvmd -T - Fix hang in clvmd if a pre-command failed. mkinitrd-6.0.5-1 ---------------- * Thu Dec 14 2006 Jeremy Katz - 6.0.5-1 - use "stabilized" with ahci and sata_* as well * Thu Dec 14 2006 Peter Jones - 6.0.4-1 - use "stabilized" with the new pata drivers so we don't race. newt-perl-1.08-11 ----------------- * Thu Dec 14 2006 Joe Orton 1.08-11 - fix directory ownership (#216610) scim-1.4.5-7.fc7 ---------------- * Fri Dec 15 2006 Jens Petersen - 1.4.5-7 - improve scim_panel-observe-workarea-xprop-204442.patch to autosnap within desktop workarea (#204442) - add scim_panel_gtk-settle-toolbar-after-drag.patch to autosnap toolbar after dragging - improve initial-locale-hotkey-186861.patch not to set next/previous factory and show menu hotkeys by default (#219247) - remove show factory menu hotkey and add super and hyper as valid modifiers in scim-system-default-config.patch - improve scim-1.4.5-panel-menu-fixes.patch to correctly name recently used factories for same language (#217324) * Fri Dec 01 2006 Jens Petersen - 1.4.5-6 - fix scim-restart quoting for pkill -f - rename scim-turn-off-snooper.patch to scim-gtkimm-default-snooper-off-213796.patch * Fri Dec 01 2006 Jens Petersen - 1.4.5-5 - move dl modules used by im-scim.so back to scim-libs for multilib (#215583) - revert gtkimm-clear-preedit-on-reset-174143.patch for now to be consistent with scim-bridge and upstream behaviour (#174143) - improve scim-restart to also restart xim socket and only kill user's own processes (#205547) selinux-policy-2.4.6-12.fc7 --------------------------- * Wed Dec 13 2006 Dan Walsh 2.4.6-12 * Wed Dec 13 2006 Dan Walsh 2.4.6-11 Resolves: #218978 * Tue Dec 12 2006 Dan Walsh 2.4.6-10 - Allow initrc to create files in /var directories Resolves: #219227 * Fri Dec 08 2006 Dan Walsh 2.4.6-9 - More fixes for MLS Resolves: #181566 setroubleshoot-1.8.10-1.fc7 --------------------------- * Sat Dec 09 2006 Dan Walsh - 1.8.10-1 - Improve quality of plugins - Make matching easier Resolves: #216575 shadow-utils-2:4.0.18.1-7.fc7 ----------------------------- * Thu Dec 14 2006 Peter Vrabec 2:4.0.18.1-7 - fix rpmlint issues spamassassin-3.1.7-2.fc7 ------------------------ * Thu Dec 14 2006 Warren Togami - 3.1.7-2 - own directory /var/lib/spamassassin util-linux-2.13-0.46.fc7 ------------------------ * Thu Dec 14 2006 Karel Zak 2.13-0.46 - fix leaking file descriptor in the more command (patch by Steve Grubb) * Wed Dec 13 2006 Karel Zak 2.13-0.45 - use ncurses only - fix #218915 - fdisk -b 4K - upgrade to -pre7 release - fix building problem with raw0 patch - fix #217186 - /bin/sh: @MKINSTALLDIRS@: No such file or directory (port po/Makefile.in.in from gettext-0.16) - sync with FC6 and RHEL5: - fix #216489 - SCHED_BATCH option missing in chrt - fix #216712 - issues with raw device support ("raw0" is wrong device name) - fix #216760 - mount with context or fscontext option fails (temporarily disabled the support for additional contexts -- not supported by kernel yet) - fix #211827 - Can't mount with additional contexts - fix #213127 - mount --make-unbindable does not work - fix #211749 - add -r option to losetup to create a read-only loop * Thu Oct 12 2006 Karel Zak 2.13-0.44 - fix #209911 - losetup.8 updated (use dm-crypt rather than deprecated cryptoloop) - fix #210338 - spurious error from '/bin/login -h $PHONENUMBER' (bug in IPv6 patch) - fix #208634 - mkswap "works" without warning on a mounted device vim-2:7.0.178-2 --------------- * Thu Dec 14 2006 Karsten Hopp 7.0.178-2 - build vim-minimal with features=small instead of tiny (#219605) Broken deps for i386 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 openoffice.org-core - 1:2.1.0-6.7.i386 requires hunspell-en php-pgsql - 5.2.0-7.i386 requires libpq.so.4 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.i386 requires python(abi) = 0:2.4 Broken deps for ppc64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ppc64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree Broken deps for x86_64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) openoffice.org-core - 1:2.1.0-6.7.x86_64 requires hunspell-en php-pgsql - 5.2.0-7.x86_64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.x86_64 requires python(abi) = 0:2.4 Broken deps for ppc ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 gnome-volume-manager - 2.17.0-2.fc7.ppc requires kernel >= 0:2.6 openoffice.org-core - 1:2.1.0-6.7.ppc requires hunspell-en pcmciautils - 014-5.ppc requires kernel >= 0:2.6.12-1.1411_FC5 php-pgsql - 5.2.0-7.ppc requires libpq.so.4 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree systemtap - 0.5.10-1.fc7.ppc requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ppc requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ia64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.ia64 requires python(abi) = 0:2.4 Broken deps for s390 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 php-pgsql - 5.2.0-7.s390 requires libpq.so.4 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for s390x ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.s390x requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree From mattdm at mattdm.org Fri Dec 15 12:32:23 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 15 Dec 2006 07:32:23 -0500 Subject: With GL based desktops, how relevant in screen resolution? In-Reply-To: <1166149755.3537.47.camel@localhost.localdomain> References: <1166149755.3537.47.camel@localhost.localdomain> Message-ID: <20061215123223.GA21519@jadzia.bu.edu> On Fri, Dec 15, 2006 at 01:29:15PM +1100, Rodd Clarkson wrote: > For example, rather than having to pick a new resolution to make my > desktop (fonts, titlebars, etc.) look bigger or smaller, couldn't we now > just have a slider that makes the desktop appear bigger or smaller? This has *always* been the case for scalable elements. Right now, though, I don't think displays have enough intrinsic resolution to pull this off acceptably with jpeg/png images on web sites, or with a lot of games. When displays get to be 300dpi or higher, then it'll be different (although for precision bitmap graphics work, you'll still want to be able to set scaling to 1:1). -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From overholt at redhat.com Fri Dec 15 14:36:40 2006 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 15 Dec 2006 09:36:40 -0500 Subject: That much dependences ? (rssowl hell) In-Reply-To: <1164232214.10975.1.camel@localhost.localdomain> References: <1164232214.10975.1.camel@localhost.localdomain> Message-ID: <1166193400.7921.3.camel@localhost.localdomain> On Wed, 2006-22-11 at 22:50 +0100, Thomas Canniot wrote: > [root at localhost ~]# yum install rssowl > > > [snip] > Install 57 Package(s) > > [...] > > I guess there are some kind of abusive dependences there ? > > Running up 2 date FC6 i386. Can you try again today and see what you get? It should be less since the RSSOwl dependency on eclipse-platform is gone. Thanks, Andrew -------------- 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 lmacken at redhat.com Fri Dec 15 19:06:37 2006 From: lmacken at redhat.com (Luke Macken) Date: Fri, 15 Dec 2006 14:06:37 -0500 Subject: Updates dependency/conflict checking In-Reply-To: References: Message-ID: <4582F23D.50702@redhat.com> Pekka Savola wrote: > Hi, > > With FC6 and updates-testing, I've gotten the following error for almost > a week now: > > Transaction Check Error: file /usr/bin/pdftoppm from install of > poppler-utils-0.5.4-3.fc6 conflicts with file from package > xpdf-utils-3.01-26.fc6 > file /usr/share/man/man1/pdftoppm.1.gz from install of > poppler-utils-0.5.4-3.fc6 conflicts with file from package > xpdf-utils-3.01-26.fc6 > > Looking at CVS, this appears to have been fixed 5 hours ago [1], but the > more generic question remains: > > This isn't the first time this has happened. Shouldn't there be a tool > (or automatic check) with updates system that would check for conflicts > across all the packages in "official" Fedora repositories? The current updates system has the ability to check dependency closure, but it isn't integrated nicely with the process (it requires human intervention). The new updates system that I am working on will check closure (among other things) automatically before anything is pushed out. http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem luke From jkeating at redhat.com Fri Dec 15 19:11:11 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 15 Dec 2006 14:11:11 -0500 Subject: Updates dependency/conflict checking In-Reply-To: <4582F23D.50702@redhat.com> References: <4582F23D.50702@redhat.com> Message-ID: <200612151411.14791.jkeating@redhat.com> On Friday 15 December 2006 14:06, Luke Macken wrote: > The current updates system has the ability to check dependency closure, > but it isn't integrated nicely with the process (it requires human > intervention). More to the point, the update tool looks at core packages for repoclosure, this breakage happens to be because of an Extras package. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jreiser at BitWagon.com Fri Dec 15 21:00:48 2006 From: jreiser at BitWagon.com (John Reiser) Date: Fri, 15 Dec 2006 13:00:48 -0800 Subject: With GL based desktops, how relevant in screen resolution? In-Reply-To: <1166149755.3537.47.camel@localhost.localdomain> References: <1166149755.3537.47.camel@localhost.localdomain> Message-ID: <45830D00.5000601@BitWagon.com> Rodd Clarkson wrote: > How relevant is screen resolution now that my desktop is now GL based. There are synthetic, quantitative images that rely on false-color pixels, and whose usefulness can be degraded substantially by arbitrary scaling. The typical resolution of about 100 pixels per inch is fairly coarse; for such images anti-aliasing amounts to destruction of data. For an example that could be relevant to a programmer's desktop, see http://bitwagon.com/duv/duv.html . Such images can be read by eye to a resolution of 1 part in 1000. The program scales the display by using a DDA (digital difference analyzer). -- From buildsys at redhat.com Sat Dec 16 11:05:45 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 16 Dec 2006 06:05:45 -0500 Subject: rawhide report: 20061216 changes Message-ID: <200612161105.kBGB5jGi020977@hs20-bc2-6.build.redhat.com> New package hunspell-en English hunspell dictionaries Updated Packages: dbus-1.0.1-3.fc7 ---------------- * Fri Dec 15 2006 David Zeuthen - 1.0.1-3.fc7 - CVE-2006-6107: D-Bus denial of service * Sun Nov 26 2006 Matthias Clasen - 1.0.1-2 - Include docs, and make them show up in devhelp * Mon Nov 20 2006 Ray Strode - 1.0.1-1 - Update to 1.0.1 - Apply patch from Thiago Macieira to fix failed assertion in threading implementation - Drop some crazy looking build time speed optimization evolution-2.9.3-4.fc7 --------------------- * Fri Dec 15 2006 Matthew Barnes - 2.9.3-4.fc7 - Disable patch for RH bug #216537, which caused RH bug #219228. * Tue Dec 12 2006 Matthew Barnes - 2.9.3-3.fc7 - Revise patch for RH bug #215466 to also fix RH bug #218589. * Mon Dec 11 2006 Matthew Barnes - 2.9.3-2.fc7 - Add patch for RH bug #215467 (missing meeting participants). gcc-4.1.1-47 ------------ * Thu Dec 14 2006 Jakub Jelinek 4.1.1-47 - fix ia64 prologue generation (Andreas Schwab, #219594, PR target/29166) - fix ppc64 divdi3 (PR target/30185) * Wed Dec 13 2006 Jakub Jelinek 4.1.1-46 - update from gcc-4_1-branch (-r119654:119833) - PRs c++/27316, c++/28740, c++/29732, fortran/29820, fortran/29821, fortran/29912, fortran/29916, fortran/30003, libstdc++/26497, libstdc++/28125, libstdc++/28265, target/30039 - fix loop unswitching (Zdenek Dvorak, #219138, PR rtl-optimization/30113) gdm-1:2.17.4-1.fc7 ------------------ * Fri Dec 15 2006 Matthias Clasen - 1:2.17.4-1 - Update to 2.17.4, which fixes CVE-2006-6105 * Tue Dec 05 2006 Matthias Clasen - 1:2.17.3-1 - Update to 2.17.3 - Update some patches ghostscript-fonts-5.50-14.fc7 ----------------------------- * Fri Dec 15 2006 Tim Waugh 5.50-14 - Copied post/postun scriptlets from urw-fonts (bug #203369). hunspell-1.1.4-3.fc7 -------------------- iproute-2.6.19-1.fc7 -------------------- * Fri Dec 15 2006 Radek Vok??l - 2.6.19-1 - upgrade to 2.6.19 parted-1.8.1-2.fc7 ------------------ * Fri Dec 15 2006 David Cantrell - 1.8.1-2 - Fix a segfault when initializing new volumes (pjones) poppler-0.5.4-5.fc7 ------------------- * Fri Dec 15 2006 Matthias Clasen - 0.5.4-5 - Include epoch in the Provides/Obsoletes for xpdf-utils postgresql-jdbc-0:8.2.504-1jpp.fc7 ---------------------------------- * Fri Dec 15 2006 Tom Lane 8.2.504-1jpp - Update to build 8.2-504 pykickstart-0.43-1.fc7 ---------------------- * Fri Dec 15 2006 Chris Lumens - 0.43-1 - Pull in new translations (#216620). python-2.5-6.fc7 ---------------- * Fri Dec 15 2006 Jeremy Katz - 2.5.3-6 - don't link against compat-db (Robert Scheck) * Wed Dec 13 2006 Jarod Wilson - 2.5.3-5 - fix invalid assert in debug mode (upstream changeset 52622) * Tue Dec 12 2006 Jeremy Katz - 2.5.3-4 - obsolete/provide python-ctypes (#219256) selinux-policy-2.4.6-14.fc7 --------------------------- * Thu Dec 14 2006 Dan Walsh 2.4.6-14 - Allow cron to polyinstatiate - Fix creation of boot flags Resolves: #207433 * Thu Dec 14 2006 Dan Walsh 2.4.6-13 - Fixes for irqbalance Resolves: #219606 * Thu Dec 14 2006 Dan Walsh 2.4.6-12 - Fix vixie-cron to work on mls Resolves: #207433 system-config-date-1.8.11-1.fc7 ------------------------------- * Fri Dec 15 2006 Nils Philippsen 1.8.11 - provide more info when encountering bad timezone translations (i.e. not split into Region,Continent/Location) (#219773) - pick up updated translations (#216073) * Wed Dec 13 2006 Nils Philippsen - fix keyboard shortcuts in Czech translation (#190355) tree-1.5.0-5.fc7 ---------------- * Fri Dec 15 2006 Tim Waugh 1.5.0-5 - Fixed '--charset' option (bug #188884). util-linux-2.13-0.47.fc7 ------------------------ * Fri Dec 15 2006 Karel Zak 2.13-0.47 - fix #217240 - namei ignores non-directory components instead of saying "Not a directory" - fix #217241 - namei enforces symlink limits inconsistently yum-3.0.1-6.fc7 --------------- * Fri Dec 15 2006 Jeremy Katz - 3.0.1-6 - fix yum provides (#219716) Broken deps for i386 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 php-pgsql - 5.2.0-7.i386 requires libpq.so.4 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.i386 requires python(abi) = 0:2.4 Broken deps for ppc64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ppc64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree Broken deps for x86_64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.x86_64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.x86_64 requires python(abi) = 0:2.4 Broken deps for s390 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 php-pgsql - 5.2.0-7.s390 requires libpq.so.4 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ppc ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 gnome-volume-manager - 2.17.0-2.fc7.ppc requires kernel >= 0:2.6 pcmciautils - 014-5.ppc requires kernel >= 0:2.6.12-1.1411_FC5 php-pgsql - 5.2.0-7.ppc requires libpq.so.4 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree systemtap - 0.5.10-1.fc7.ppc requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ppc requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ia64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.ia64 requires python(abi) = 0:2.4 Broken deps for s390x ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.s390x requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree From emeric.maschino at gmail.com Sat Dec 16 13:08:51 2006 From: emeric.maschino at gmail.com (=?ISO-8859-1?Q?=C9meric_Maschino?=) Date: Sat, 16 Dec 2006 14:08:51 +0100 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) Message-ID: Hi, Just to inform Itanium users that kernel-2.6.19-1.2877.fc7 is unbootable on my hp workstation zx6000. VolGroup00 can't be found (I've used the default partitionning scheme during the installation). No problem with previous kernel-2.6.18-1.2849.fc6. Cheers, ?meric -------------- next part -------------- An HTML attachment was scrubbed... URL: From caolanm at redhat.com Sat Dec 16 13:22:05 2006 From: caolanm at redhat.com (Caolan McNamara) Date: Sat, 16 Dec 2006 13:22:05 +0000 Subject: hunspell-en and OOo In-Reply-To: <1166264369.21598.3.camel@T7.Linux> References: <1166264369.21598.3.camel@T7.Linux> Message-ID: <1166275326.3350.22.camel@soulcrusher.caolan.org> On Sat, 2006-12-16 at 10:19 +0000, Paul wrote: > Hi, > > hunspell is in rawhide. I can see that. OOo requires hunspell-en though. > Is this just a mistake on packaging hunspell or is it a problem with OOo > and more over, when is a fix going to appear in rawhide for it? Should all be good today, I jumped the gun on requiring hunspell-en before it was actually available. hunspell is the package which provides the spell checking library used by OOo and the hunspell command line tool hunspell-en is the package which provides the english dictionaries which the OOo core requires, just as the core bundles the english resources as the effective "C" final fallback locale. All the noise is to kick off the master plan to reduce our dictionary madness a bit for fc7 (rhbz#207571) or at least to enable this. So hunspell has been moved out of OOo (rhbz#214764) and now the english dictionaries have been moved out as well (rhbz#218769). Which will enable firefox/thunderbird to reuse the same dictionaries if tweaked to use hunspell instead of myspell and the firefox/thunderbird dictionary dir is linked to /usr/share/myspell (rhbz#218762). Current firefox/thunderbird use myspell, hunspell's predecessor and also include copies of these english dictionaries, so that's a relatively small step. Also vim has a rather baroque spellchecker which backs on to converted copies of these same hunspell/myspell dictionaries. rhbz#219777 is a semi-plausible route to avoiding the need for the converted copies (which would come to approx 40megs in total I think) So http://people.redhat.com/caolanm/hunspell/ are the src.rpms for the rest of the dictionaries that are currently included as part of our OOo langpacks. I'll take care of those myself (I guess) I'd encourage anyone who wants to package dictionaries for other languages for OOo (et.al) that are not listed at the above url, or especially for anyone who might already have packaged in extras stuff like "openoffice.org-dict.some_language" to repackage their dictionaries along the lines of the like the above examples. i.e. take the dicts from http://wiki.services.openoffice.org/wiki/Dictionaries set the correct licence for the dict, and take the datestamp of the language there as the pre-release version unless the dictionary otherwise notes a canonical version. Unlike the previous situation there's no need for the baroque "DICT name foo whatever" line to be added to dictionary.lst, just name the dictionary as the xx_YY language_region it supplies and it'll just work out of the box in OOo. C. From davej at redhat.com Sat Dec 16 14:43:34 2006 From: davej at redhat.com (Dave Jones) Date: Sat, 16 Dec 2006 09:43:34 -0500 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: References: Message-ID: <20061216144334.GE23368@redhat.com> On Sat, Dec 16, 2006 at 02:08:51PM +0100, ?meric Maschino wrote: > Hi, > > Just to inform Itanium users that kernel-2.6.19-1.2877.fc7 is unbootable on > my hp workstation zx6000. VolGroup00 can't be found (I've used the default > partitionning scheme during the installation). No problem with previous > kernel-2.6.18-1.2849.fc6. Probably the changes to use libata PATA drivers instead of the old crusty IDE drivers at a guess. The most obvious change being the move from /dev/hd* to /dev/sd*. If you're using mount-by-label, that should 'just work' though, so perhaps either the driver is broken, or it needs a workaround in mkinitrd like the other PATA drivers to wait for the disk nodes to appear in /dev before we go looking for volume groups. Do you know which IDE chipset this uses? (If you know the module that ended up in the initrd, even better). Dave -- http://www.codemonkey.org.uk From rob at choralone.org Sat Dec 16 14:51:26 2006 From: rob at choralone.org (Rob Andrews) Date: Sat, 16 Dec 2006 14:51:26 +0000 Subject: No PPC (32-bit) kernel in rawhide? Message-ID: <20061216145126.GA11483@aphasia.badger.choralone.org> fedora/linux/core/development/ppc/os/Fedora/RPMS/ doesn't seem to have a 32-bit PPC kernel - it does have a 64-bit kernel, however. -- rob andrews :: pgp 0x01e00563 :: rob at choralone.org From rob at choralone.org Sat Dec 16 14:54:25 2006 From: rob at choralone.org (Rob Andrews) Date: Sat, 16 Dec 2006 14:54:25 +0000 Subject: No PPC (32-bit) kernel in rawhide? In-Reply-To: <20061216145126.GA11483@aphasia.badger.choralone.org> References: <20061216145126.GA11483@aphasia.badger.choralone.org> Message-ID: <20061216145425.GB11483@aphasia.badger.choralone.org> On 16-Dec-2006 14:51.26 (GMT), Rob Andrews wrote: > fedora/linux/core/development/ppc/os/Fedora/RPMS/ doesn't seem to have a > 32-bit PPC kernel - it does have a 64-bit kernel, however. Never mind: > yeah, ppc32 busted due to a missing 64bit divide implementation. -- rob andrews :: pgp 0x01e00563 :: rob at choralone.org From seandarcy2 at gmail.com Sat Dec 16 17:30:08 2006 From: seandarcy2 at gmail.com (sean) Date: Sat, 16 Dec 2006 12:30:08 -0500 Subject: with python-2.5, where to put site-packages on x86-64. Message-ID: No i386 python: python-2.5-6.fc7.x86_64 python-devel-2.5-6.fc7.x86_64 python-docs-2.5-1.fc7.noarch python-libs-2.5-6.fc7.x86_64 python-tools-2.5-6.fc7.x86_64 But all the related packages are populating /usr/lib/python2.5/site-packages. And: python Python 2.5 (r25:51908, Dec 15 2006, 11:08:48) [GCC 4.1.1 20061213 (Red Hat 4.1.1-47)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from distutils import sysconfig >>> print sysconfig.get_python_lib() /usr/lib/python2.5/site-packages Is this the desired packaging? For my own stuff does it even matter? sean From a.badger at gmail.com Sat Dec 16 17:30:40 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 16 Dec 2006 09:30:40 -0800 Subject: with python-2.5, where to put site-packages on x86-64. In-Reply-To: References: Message-ID: On 12/16/06, sean wrote: > No i386 python: > > python-2.5-6.fc7.x86_64 > python-devel-2.5-6.fc7.x86_64 > python-docs-2.5-1.fc7.noarch > python-libs-2.5-6.fc7.x86_64 > python-tools-2.5-6.fc7.x86_64 > > But all the related packages are populating > /usr/lib/python2.5/site-packages. > > And: > > python > Python 2.5 (r25:51908, Dec 15 2006, 11:08:48) > [GCC 4.1.1 20061213 (Red Hat 4.1.1-47)] on linux2 > Type "help", "copyright", "credits" or "license" for more > information. > >>> from distutils import sysconfig > >>> print sysconfig.get_python_lib() > /usr/lib/python2.5/site-packages > What does sysconfig.get_python_lib(1) return? It should be: /usr/lib64/python2.5/site-packages > Is this the desired packaging? For my own stuff does it even > matter? > arch specific python packages should go to /usr/lib64/python2.5/site-packages and arch independent python packages should go to /usr/lib/python2.5/site-packages Is this not what's happening for you? Are there .so files being saved into /usr/lib/python2.5? -Toshio From tbrinkman at sbcglobal.net Sat Dec 16 17:52:30 2006 From: tbrinkman at sbcglobal.net (Tom Brinkman) Date: Sat, 16 Dec 2006 11:52:30 -0600 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <20061216144334.GE23368@redhat.com> References: <20061216144334.GE23368@redhat.com> Message-ID: <200612161152.30703.tbrinkman@sbcglobal.net> On Saturday 16 December 2006 8:43 am, Dave Jones wrote: > On Sat, Dec 16, 2006 at 02:08:51PM +0100, ?meric Maschino wrote: > > Hi, > > > > Just to inform Itanium users that kernel-2.6.19-1.2877.fc7 is > > unbootable on my hp workstation zx6000. VolGroup00 can't be > > found (I've used the default partitionning scheme during the > > installation). No problem with previous > > kernel-2.6.18-1.2849.fc6. > > Probably the changes to use libata PATA drivers instead of the > old crusty IDE drivers at a guess. The most obvious change being > the move from /dev/hd* to /dev/sd*. If you're using > mount-by-label, that should 'just work' though, so perhaps either > the driver is broken, or it needs a workaround in mkinitrd like > the other PATA drivers to wait for the disk nodes to appear in > /dev before we go looking for volume groups. > > Do you know which IDE chipset this uses? (If you know the module > that ended up in the initrd, even better). > > Dave It panics, unable to mount on i386 without any LVM too. Asus A7V600, kt600 chipset, both pata an sata drives. My / is on hd0,0 an IDE pata drive. The sata (all storage) appears to be found before the kernel panics on IDE. All drives (2 pata, 1 sata) are ext3. (from my other dual boot side, fc6-test, lspci -v) 00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: ASUSTeK Computer Inc. A7V600/K8V-X/A8V Deluxe motherboard Flags: bus master, medium devsel, latency 32, IRQ 169 I/O ports at a400 [size=16] Capabilities: [c0] Power Management version 2 Before I saw any of these posts, I had already remade an initrd for 2877. I was ignorant of "the changes to use libata PATA drivers" I am usin mount by label, title FC7 (2.6.19-1.2877.fc7) root (hd0,0) kernel /vmlinuz-2.6.19-1.2877.fc7 ro root=LABEL=/ initrd /initrd-2.6.19-1.2877.fc7.img According to rawhide report that's 2.6.20rc1 Since I share /boot between fc6-test an rawhide, I could see what 2877 initrd contains (both the original an my remake)... but I don't know how -- Tom Brinkman Corpus Christi, Texas From kmaraas at broadpark.no Sat Dec 16 19:44:17 2006 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Sat, 16 Dec 2006 20:44:17 +0100 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <200612161152.30703.tbrinkman@sbcglobal.net> References: <20061216144334.GE23368@redhat.com> <200612161152.30703.tbrinkman@sbcglobal.net> Message-ID: <1166298257.2721.7.camel@rivendell> l?r, 16.12.2006 kl. 11.52 -0600, skrev Tom Brinkman: > On Saturday 16 December 2006 8:43 am, Dave Jones wrote: > > On Sat, Dec 16, 2006 at 02:08:51PM +0100, ?meric Maschino wrote: > > > Hi, > > > > > > Just to inform Itanium users that kernel-2.6.19-1.2877.fc7 is > > > unbootable on my hp workstation zx6000. VolGroup00 can't be > > > found (I've used the default partitionning scheme during the > > > installation). No problem with previous > > > kernel-2.6.18-1.2849.fc6. > > > > Probably the changes to use libata PATA drivers instead of the > > old crusty IDE drivers at a guess. The most obvious change being > > the move from /dev/hd* to /dev/sd*. If you're using > > mount-by-label, that should 'just work' though, so perhaps either > > the driver is broken, or it needs a workaround in mkinitrd like > > the other PATA drivers to wait for the disk nodes to appear in > > /dev before we go looking for volume groups. > > > > Do you know which IDE chipset this uses? (If you know the module > > that ended up in the initrd, even better). > > > > Dave > > It panics, unable to mount on i386 without any LVM too. Asus > A7V600, kt600 chipset, both pata an sata drives. My / is on hd0,0 > an IDE pata drive. The sata (all storage) appears to be found > before the kernel panics on IDE. All drives (2 pata, 1 sata) are > ext3. > Same thing here with a plain Pentium M laptop (HP Compaq nc4010) 00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4) (prog-if ea) Subsystem: Compaq Computer Corporation Unknown device 005a Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at 3800 [size=16] Capabilities: [root at rivendell gnome]# hdparm -I /dev/hda /dev/hda: ATA device, with non-removable media Model Number: HTS541080G9AT00 Serial Number: MPB4LAX6K4MZKM Firmware Revision: MB4OA60A Standards: Used: ATA/ATAPI-6 T13 1410D revision 3a Supported: 6 5 4 Configuration: Logical max current cylinders 16383 65535 heads 16 1 sectors/track 63 63 -- CHS current addressable sectors: 4128705 LBA user addressable sectors: 156301488 LBA48 user addressable sectors: 156301488 device size with M = 1024*1024: 76319 MBytes device size with M = 1000*1000: 80026 MBytes (80 GB) It failed to mount /dev IIRC. Cheers Kjartan > (from my other dual boot side, fc6-test, lspci -v) > > 00:0f.1 IDE interface: VIA Technologies, Inc. > VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) > (prog-if 8a [Master SecP PriP]) > Subsystem: ASUSTeK Computer Inc. A7V600/K8V-X/A8V Deluxe > motherboard > Flags: bus master, medium devsel, latency 32, IRQ 169 > I/O ports at a400 [size=16] > Capabilities: [c0] Power Management version 2 > > Before I saw any of these posts, I had already remade an initrd > for 2877. I was ignorant of "the changes to use libata PATA > drivers" I am usin mount by label, > > title FC7 (2.6.19-1.2877.fc7) > root (hd0,0) > kernel /vmlinuz-2.6.19-1.2877.fc7 ro root=LABEL=/ > initrd /initrd-2.6.19-1.2877.fc7.img > > According to rawhide report that's 2.6.20rc1 > > Since I share /boot between fc6-test an rawhide, I could see what > 2877 initrd contains (both the original an my remake)... but I > don't know how > -- > Tom Brinkman Corpus Christi, Texas > From dorin.lazar.liste at gmail.com Sat Dec 16 19:49:41 2006 From: dorin.lazar.liste at gmail.com (Dorin Lazar) Date: Sat, 16 Dec 2006 21:49:41 +0200 Subject: poppler-utils requires an older version of poppler Message-ID: <200612162149.41308.dorin.lazar.liste@gmail.com> Hello, It seems that the dependency for poppler-utils is broken, as it requires poppler = 0.5.4-4.fc7, yet 0.5.4-5.fc7 is available: ----------------------- --> Processing Dependency: poppler = 0.5.4-4.fc7 for package: poppler-utils --> Finished Dependency Resolution Error: Missing Dependency: poppler = 0.5.4-4.fc7 is needed by package poppler-utils [root at spooky ~]# rpm -qi poppler Name : poppler Relocations: (not relocatable) Version : 0.5.4 Vendor: Red Hat, Inc. Release : 5.fc7 Build Date: Fri 15 Dec 2006 04:29:17 PM EET Install Date: Sat 16 Dec 2006 05:35:10 PM EET Build Host: ls20-bc1-13.build.redhat.com [...] ---------------- Best regards, Dorin From pea510 at aol.de Sat Dec 16 20:03:34 2006 From: pea510 at aol.de (pea510 at aol.de) Date: Sat, 16 Dec 2006 15:03:34 -0500 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <200612161152.30703.tbrinkman@sbcglobal.net> References: <20061216144334.GE23368@redhat.com> <200612161152.30703.tbrinkman@sbcglobal.net> Message-ID: <8C8EF6466A0AD87-8E0-D0B6@FWM-D17.sysops.aol.com> Check the size of your "inird" file. I you hadn't updated "mkinitrd" to the current version before installing the new "2.1.19" kernel, chances are high that it is corrupted. It's size then is much smaller than of that created for the older kernel. You might try to boot with the old kernel, update "mkinitrd" and reinstall the new kernel package. In my case this procedure was successful. ________________________________________________________________________ Testen Sie das neue, kostenlose AOL eMail: 2 GB Speicherplatz mit marktf?hrendem Spam- und eMail-Virenschutz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at camperquake.de Sat Dec 16 20:52:24 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 16 Dec 2006 21:52:24 +0100 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <200612161152.30703.tbrinkman@sbcglobal.net> References: <20061216144334.GE23368@redhat.com> <200612161152.30703.tbrinkman@sbcglobal.net> Message-ID: <20061216215224.3b5f33a9@nausicaa.camperquake.de> Hi. Tom Brinkman wrote: > It panics, unable to mount on i386 without any LVM too. Asus > A7V600, kt600 chipset, both pata an sata drives. My / is on hd0,0 > an IDE pata drive. The sata (all storage) appears to be found > before the kernel panics on IDE. All drives (2 pata, 1 sata) are > ext3. My (SATA only) laptop boots fine. -- Cat's urine glows under a blacklight. From davej at redhat.com Sat Dec 16 23:23:22 2006 From: davej at redhat.com (Dave Jones) Date: Sat, 16 Dec 2006 18:23:22 -0500 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <8C8EF6466A0AD87-8E0-D0B6@FWM-D17.sysops.aol.com> References: <20061216144334.GE23368@redhat.com> <200612161152.30703.tbrinkman@sbcglobal.net> <8C8EF6466A0AD87-8E0-D0B6@FWM-D17.sysops.aol.com> Message-ID: <20061216232322.GB30713@redhat.com> On Sat, Dec 16, 2006 at 03:03:34PM -0500, pea510 at aol.de wrote: > Check the size of your "inird" file. I you hadn't updated "mkinitrd" to the > current version before installing the new "2.1.19" kernel, chances are high > that it is corrupted. Unless you're installing the kernel with rpm --nodeps, that shouldn't be possible. The current kernel depends on the new mkinitrd. (Well, 1 rev back, but that's good enough). Dave -- http://www.codemonkey.org.uk From j.rink at freenet.de Sat Dec 16 23:51:04 2006 From: j.rink at freenet.de (=?UTF-8?B?SsO2cm4=?= Rink) Date: Sun, 17 Dec 2006 00:51:04 +0100 Subject: how can i add a patch to kernel-2.6.spec Message-ID: <20061217005104.cb84f145.j.rink@freenet.de> Hi, i want to add a patch for me to the kernel-2.6.spec file and recompile the kernel. I have downloaded the kernel source, install it and i put the patch to the $RPMBUILD/SOURCE directory. In the spec file there are Patch number with patches behind. When i add a new number and my patch, it is ignored by rpmbuild -bp. But there is also no error msg. I found no hint where the Patch Numbers are defined, but when i comment out, eg Patch4, i get an error msg. So, how can i add a patch, or where are the numbers defined? I want to add the linux phc patch (undervolting my thinkpad t43) patching, configuring and compiling works, but i have to patch it manually in the $RPMBUILD/BUILD directory. Thanks From tbrinkman at sbcglobal.net Sun Dec 17 00:42:12 2006 From: tbrinkman at sbcglobal.net (Tom Brinkman) Date: Sat, 16 Dec 2006 18:42:12 -0600 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <8C8EF6466A0AD87-8E0-D0B6@FWM-D17.sysops.aol.com> References: <200612161152.30703.tbrinkman@sbcglobal.net> <8C8EF6466A0AD87-8E0-D0B6@FWM-D17.sysops.aol.com> Message-ID: <200612161842.12361.tbrinkman@sbcglobal.net> On Saturday 16 December 2006 2:03 pm, pea510 at aol.de wrote: > Check the size of your "inird" file. I you hadn't updated > "mkinitrd" to the current version before installing the new > "2.1.19" kernel, chances are high that it is corrupted. It's size > then is much smaller than of that created for the older kernel. > You might try to boot with the old kernel, update "mkinitrd" and > reinstall the new kernel package. In my case this procedure was > successful. Probly not respondin to me, but... I had updated initrd (heck all of rawhide kept current daily). An makin a new initrd resulted in the same panic. But I did check, an the 2877 kernel initrd is damn near twice the size. / # du -k /boot/initrd-2.6.1* 1045 /boot/initrd-2.6.16-1.2255_FC6.img 1045 /boot/initrd-2.6.16-1.2258_FC6.img 1356 /boot/initrd-2.6.17-1.2445.fc6.img 1484 /boot/initrd-2.6.18-1.2784.fc6.img 1483 /boot/initrd-2.6.18-1.2798.fc6.img 1483 /boot/initrd-2.6.18-1.2835.fc6.img 1491 /boot/initrd-2.6.18-1.2849.fc6.img 1489 /boot/initrd-2.6.18-1.2860.fc6.img 2877 /boot/initrd-2.6.19-1.2877.fc7.img / # du -k /boot/sav-initrd-2.6.19-1.2877.fc7.img 2872 /boot/sav-initrd-2.6.19-1.2877.fc7.img sav- is the original initrd. I forgot to mention before that yum did install 2877 an update my grub.conf OTOH, my tokeep=4 was ignored and an older rawhide kernel removed. Not what I wanted, but at least I'm aware (again) of it now. It's happened before. -- Tom Brinkman Corpus Christi, Texas From emmanuel.seyman at club-internet.fr Sun Dec 17 00:46:31 2006 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Sun, 17 Dec 2006 01:46:31 +0100 Subject: how can i add a patch to kernel-2.6.spec In-Reply-To: <20061217005104.cb84f145.j.rink@freenet.de> References: <20061217005104.cb84f145.j.rink@freenet.de> Message-ID: <20061217004631.GA6915@orient.maison.lan> On Sun, Dec 17, 2006 at 12:51:04AM +0100, J?rn Rink wrote: > > When i add a new number and my patch, it is ignored by rpmbuild -bp. There are two things to do : - define a new patch (this is what you've done, apparently). - tell rpm to apply that patch with the line : %patchN -p0 where N is the number you've given to your patch and -p0 the arguements you want to give to patch. Emmanuel From pea510 at aol.de Sun Dec 17 09:12:24 2006 From: pea510 at aol.de (pea510 at aol.de) Date: Sun, 17 Dec 2006 04:12:24 -0500 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <20061216232322.GB30713@redhat.com> References: <20061216144334.GE23368@redhat.com> <200612161152.30703.tbrinkman@sbcglobal.net> <8C8EF6466A0AD87-8E0-D0B6@FWM-D17.sysops.aol.com> <20061216232322.GB30713@redhat.com> Message-ID: <8C8EFD2996EA708-104C-EA3B@mblk-r35.sysops.aol.com> >Unless you're installing the kernel with rpm --nodeps, that shouldn't be >possible. >The current kernel depends on the new mkinitrd. (Well, 1 rev back, but that's >good enough). > > Dave Not quite: I had installed "FC" from scratch from the "rawhide" tree using the "FC6" install DVD because network is broken in the current "rescue" image. The install completed successfully, but then I encountered this kernel panic, checked the "initrd" size which was 50 bytes only and reinstalled "kernel-2.6.19-1.2877.fc7". Because now, the "rawhide" version of "mkinitrd" was used, the created "initrd" was correct, and I could boot the new kernel on my "IBM ThinkPad T23" (only ATA devices) without a glitch and without modifying "grub.conf". Joachim Frieben ________________________________________________________________________ Testen Sie das neue, kostenlose AOL eMail: 2 GB Speicherplatz mit marktf?hrendem Spam- und eMail-Virenschutz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.kratochvil at redhat.com Sun Dec 17 09:46:12 2006 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Sun, 17 Dec 2006 10:46:12 +0100 Subject: how can i add a patch to kernel-2.6.spec In-Reply-To: <20061217004631.GA6915@orient.maison.lan> References: <20061217005104.cb84f145.j.rink@freenet.de> <20061217004631.GA6915@orient.maison.lan> Message-ID: <20061217094612.GA31294@host0.dyn.jankratochvil.net> On Sun, 17 Dec 2006 01:46:31 +0100, Emmanuel Seyman wrote: > On Sun, Dec 17, 2006 at 12:51:04AM +0100, J?rn Rink wrote: > > > > When i add a new number and my patch, it is ignored by rpmbuild -bp. > > There are two things to do : > > - define a new patch (this is what you've done, apparently). > - tell rpm to apply that patch with the line : > %patchN -p0 This second step I found to be a common mistake (and probably not only of myself?). I wrote a small script I am using automatically for this check: http://cvs.jankratochvil.net/viewcvs/nethome/bin/checkspecpatch?rev=HEAD Would be a similiar C patch accepted for rpmbuild(8)? OK, it shoule be BZ RFEd. It would be still backward compatible and for unapplied patches one would have to at least write an explicit comment line like: #%patch42 -p1 Regards, Jan From bart.vanbrabant at zoeloelip.be Sun Dec 17 10:47:39 2006 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Sun, 17 Dec 2006 11:47:39 +0100 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <8C8EF6466A0AD87-8E0-D0B6@FWM-D17.sysops.aol.com> References: <20061216144334.GE23368@redhat.com> <200612161152.30703.tbrinkman@sbcglobal.net> <8C8EF6466A0AD87-8E0-D0B6@FWM-D17.sysops.aol.com> Message-ID: <4585204B.6020506@zoeloelip.be> pea510 at aol.de wrote: > Check the size of your "inird" file. I you hadn't updated "mkinitrd" to > the current version before installing the new "2.1.19" kernel, chances > are high that it is corrupted. It's size then is much smaller than of > that created for the older kernel. > You might try to boot with the old kernel, update "mkinitrd" and > reinstall the new kernel package. In my case this procedure was successful. Hi, I had the same problem. When I first booted the 2.6.19-1.2877.fc7 kernel I got a kernel panic it couldn't start init. I booted back to the previous kernel and my initrd was only 336k, I updated it and now it's 3.6M. I checked my logs to see how yum updated my kernel and mkinitrd: Dec 12 17:01:00 localhost Updated: mkinitrd.i386 6.0.3-1 Dec 16 11:45:43 localhost Updated: mkinitrd.i386 6.0.5-1 Dec 16 11:48:03 localhost Installed: kernel.i686 2.6.19-1.2877.fc7 So I had the new mkinitrd before my kernel was updated. If necessary I can upload the initrd created at the updated and the one I created. What will happen the next time grub needs to be installed? Will the grup device map be updated to the new device naming? gr, Bart -- Bart Vanbrabant PGP fingerprint: 093C BB84 17F6 3AA6 6D5E FC4F 84E1 FED1 E426 64D1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From buildsys at redhat.com Sun Dec 17 11:13:48 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sun, 17 Dec 2006 06:13:48 -0500 Subject: rawhide report: 20061217 changes Message-ID: <200612171113.kBHBDmme015640@hs20-bc2-6.build.redhat.com> Updated Packages: bash-3.2-1.fc7 -------------- * Fri Dec 15 2006 Tim Waugh 3.2-1 - Build requires autoconf and gettext. - 3.2. No longer need aq, login, ulimit, sighandler or read-memleak patches. * Wed Jul 12 2006 Tim Waugh 3.1-17 - Fixed 'tags out of date' problem with 'info bash' (bug #150118). util-linux-2.13-0.48.fc7 ------------------------ * Sun Dec 17 2006 Karel Zak 2.13-0.48 - fix paths in po/Makefile.in.in Broken deps for ppc64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ppc64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree Broken deps for s390 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 php-pgsql - 5.2.0-7.s390 requires libpq.so.4 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for i386 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 php-pgsql - 5.2.0-7.i386 requires libpq.so.4 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.i386 requires python(abi) = 0:2.4 Broken deps for ia64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ia64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.ia64 requires python(abi) = 0:2.4 Broken deps for x86_64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.x86_64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.x86_64 requires python(abi) = 0:2.4 Broken deps for ppc ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 gnome-volume-manager - 2.17.0-2.fc7.ppc requires kernel >= 0:2.6 pcmciautils - 014-5.ppc requires kernel >= 0:2.6.12-1.1411_FC5 php-pgsql - 5.2.0-7.ppc requires libpq.so.4 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree systemtap - 0.5.10-1.fc7.ppc requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.ppc requires kernel >= 0:2.6.9-11 Broken deps for s390x ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.s390x requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree From dwmw2 at infradead.org Sun Dec 17 12:24:39 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 17 Dec 2006 12:24:39 +0000 Subject: No PPC (32-bit) kernel in rawhide? In-Reply-To: <20061216145126.GA11483@aphasia.badger.choralone.org> References: <20061216145126.GA11483@aphasia.badger.choralone.org> Message-ID: <1166358279.6714.46.camel@pmac.infradead.org> On Sat, 2006-12-16 at 14:51 +0000, Rob Andrews wrote: > fedora/linux/core/development/ppc/os/Fedora/RPMS/ doesn't seem to have a > 32-bit PPC kernel - it does have a 64-bit kernel, however. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25724 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21237 Jakub, should I file a bug in our bugzilla for that, or just wait for the fix to migrate? -- dwmw2 From gilboad at gmail.com Sun Dec 17 18:15:53 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 17 Dec 2006 20:15:53 +0200 Subject: Enabled mach64_dri in kernel, mesa? (fc7,rawhide) Message-ID: <1166379353.12924.15.camel@gilboa-work-dev.localdomain> Hello all, According to [1] and [2], the latest mach64 mesa (6.5.x) driver is considered secure. Could it be possible to implant the mach64.* code into the kernel source (from drm) and enable mach64_dri in the mesa spec? (I can live with the missing mach64.ko kernel module; However, having to rebuild mesa on a PII366 every time a new mesa package is released to fc6-updates is a -huge- pain in the backside) Thanks, - Gilboa [1] http://dri.freedesktop.org/wiki/ATIMach64 [2] https://bugs.freedesktop.org/show_bug.cgi?id=6242 From icon at fedoraproject.org Sun Dec 17 18:42:48 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Sun, 17 Dec 2006 13:42:48 -0500 Subject: python-kid 0.9.4 warning Message-ID: A small warning for those who use kidc to pre-compile kid templates. Python-kid 0.9.4 is about to hit extras, and here's a warning from changelog: Due to optimizations in kid.template_util, Kid 0.9.3 templates need to be re-compiled in order to run with Kid 0.9.4. Caveat coder. Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From david at fubar.dk Sun Dec 17 23:10:59 2006 From: david at fubar.dk (David Zeuthen) Date: Sun, 17 Dec 2006 18:10:59 -0500 Subject: rawhide report: 20061215 changes In-Reply-To: <200612151106.kBFB6XkN014471@hs20-bc2-6.build.redhat.com> References: <200612151106.kBFB6XkN014471@hs20-bc2-6.build.redhat.com> Message-ID: <4585CE83.5010502@fubar.dk> buildsys at redhat.com wrote: > mkinitrd-6.0.5-1 > ---------------- > * Thu Dec 14 2006 Jeremy Katz - 6.0.5-1 > - use "stabilized" with ahci and sata_* as well > > * Thu Dec 14 2006 Peter Jones - 6.0.4-1 > - use "stabilized" with the new pata drivers so we don't race. This one breaks my Macbook Pro https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219966 David From ndbecker2 at gmail.com Sun Dec 17 23:55:08 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 17 Dec 2006 18:55:08 -0500 Subject: with python-2.5, where to put site-packages on x86-64. References: Message-ID: Toshio Kuratomi wrote: > On 12/16/06, sean wrote: >> No i386 python: >> >> python-2.5-6.fc7.x86_64 >> python-devel-2.5-6.fc7.x86_64 >> python-docs-2.5-1.fc7.noarch >> python-libs-2.5-6.fc7.x86_64 >> python-tools-2.5-6.fc7.x86_64 >> >> But all the related packages are populating >> /usr/lib/python2.5/site-packages. >> >> And: >> >> python >> Python 2.5 (r25:51908, Dec 15 2006, 11:08:48) >> [GCC 4.1.1 20061213 (Red Hat 4.1.1-47)] on linux2 >> Type "help", "copyright", "credits" or "license" for more >> information. >> >>> from distutils import sysconfig >> >>> print sysconfig.get_python_lib() >> /usr/lib/python2.5/site-packages >> > What does sysconfig.get_python_lib(1) return? It should be: > /usr/lib64/python2.5/site-packages > >> Is this the desired packaging? For my own stuff does it even >> matter? >> > arch specific python packages should go to > /usr/lib64/python2.5/site-packages and arch independent python > packages should go to /usr/lib/python2.5/site-packages > > Is this not what's happening for you? Are there .so files being saved > into /usr/lib/python2.5? > > -Toshio > IIUC this setup is actually broken. Packages that have both arch-indep and arch-dep will not be found correctly with this scheme. AFAIK this has not been fixed in python, and python authors said that this scheme is wrong. From davej at redhat.com Mon Dec 18 02:15:08 2006 From: davej at redhat.com (Dave Jones) Date: Sun, 17 Dec 2006 21:15:08 -0500 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <200612161152.30703.tbrinkman@sbcglobal.net> References: <20061216144334.GE23368@redhat.com> <200612161152.30703.tbrinkman@sbcglobal.net> Message-ID: <20061218021508.GC8353@redhat.com> On Sat, Dec 16, 2006 at 11:52:30AM -0600, Tom Brinkman wrote: > > Probably the changes to use libata PATA drivers instead of the > > old crusty IDE drivers at a guess. The most obvious change being > > the move from /dev/hd* to /dev/sd*. If you're using > > mount-by-label, that should 'just work' though, so perhaps either > > the driver is broken, or it needs a workaround in mkinitrd like > > the other PATA drivers to wait for the disk nodes to appear in > > /dev before we go looking for volume groups. > > > It panics, unable to mount on i386 without any LVM too. Asus > A7V600, kt600 chipset, both pata an sata drives. My / is on hd0,0 > an IDE pata drive. The sata (all storage) appears to be found > before the kernel panics on IDE. All drives (2 pata, 1 sata) are > ext3. Hmm, I just managed to reproduce this on a similar box. Rerunning mkinitrd wasn't the answer though. The problem was that there were a ton of SELinux denials. Can you try.. setenforce 0 mkinitrd /boot/initrd-2.6.19-1.2877.fc7.img 2.6.19-1.2877.fc7 Dave -- http://www.codemonkey.org.uk From a.badger at gmail.com Mon Dec 18 02:28:06 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 17 Dec 2006 18:28:06 -0800 Subject: with python-2.5, where to put site-packages on x86-64. In-Reply-To: References: Message-ID: <1166408886.21769.6.camel@localhost.localdomain> On Sun, 2006-12-17 at 18:55 -0500, Neal Becker wrote: > Toshio Kuratomi wrote: > > > On 12/16/06, sean wrote: > >> No i386 python: > >> > >> python-2.5-6.fc7.x86_64 > >> python-devel-2.5-6.fc7.x86_64 > >> python-docs-2.5-1.fc7.noarch > >> python-libs-2.5-6.fc7.x86_64 > >> python-tools-2.5-6.fc7.x86_64 > >> > >> But all the related packages are populating > >> /usr/lib/python2.5/site-packages. > >> > >> And: > >> > >> python > >> Python 2.5 (r25:51908, Dec 15 2006, 11:08:48) > >> [GCC 4.1.1 20061213 (Red Hat 4.1.1-47)] on linux2 > >> Type "help", "copyright", "credits" or "license" for more > >> information. > >> >>> from distutils import sysconfig > >> >>> print sysconfig.get_python_lib() > >> /usr/lib/python2.5/site-packages > >> > > What does sysconfig.get_python_lib(1) return? It should be: > > /usr/lib64/python2.5/site-packages > > > >> Is this the desired packaging? For my own stuff does it even > >> matter? > >> > > arch specific python packages should go to > > /usr/lib64/python2.5/site-packages and arch independent python > > packages should go to /usr/lib/python2.5/site-packages > > > > Is this not what's happening for you? Are there .so files being saved > > into /usr/lib/python2.5? > > > > -Toshio > > > > IIUC this setup is actually broken. Packages that have both arch-indep and > arch-dep will not be found correctly with this scheme. AFAIK this has not > been fixed in python, and python authors said that this scheme is wrong. > The problem you are describing occurs when the arch specific portion of a package is installed in /usr/lib64/ and the arch independent portion is installed in /usr/lib/. This is not the case in the scenario I describe: the whole of an arch specific package is installed into /usr/lib64/ and the whole of an arch independent package is installed into /usr/lib/. I still don't know what exactly the OP is seeing, though. -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 mattdm at mattdm.org Mon Dec 18 02:37:42 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 17 Dec 2006 21:37:42 -0500 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <20061218021508.GC8353@redhat.com> References: <20061216144334.GE23368@redhat.com> <200612161152.30703.tbrinkman@sbcglobal.net> <20061218021508.GC8353@redhat.com> Message-ID: <20061218023742.GA25334@jadzia.bu.edu> On Sun, Dec 17, 2006 at 09:15:08PM -0500, Dave Jones wrote: > Hmm, I just managed to reproduce this on a similar box. > Rerunning mkinitrd wasn't the answer though. The problem was that > there were a ton of SELinux denials. > Can you try.. > setenforce 0 > mkinitrd /boot/initrd-2.6.19-1.2877.fc7.img 2.6.19-1.2877.fc7 FWIW, I ran into this the other day and complained about it on the selinux list.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tbrinkman at sbcglobal.net Mon Dec 18 03:48:10 2006 From: tbrinkman at sbcglobal.net (Tom Brinkman) Date: Sun, 17 Dec 2006 21:48:10 -0600 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <20061218021508.GC8353@redhat.com> References: <200612161152.30703.tbrinkman@sbcglobal.net> <20061218021508.GC8353@redhat.com> Message-ID: <200612172148.10336.tbrinkman@sbcglobal.net> On Sunday 17 December 2006 8:15 pm, Dave Jones wrote: > On Sat, Dec 16, 2006 at 11:52:30AM -0600, Tom Brinkman wrote: > > > Probably the changes to use libata PATA drivers instead of > > > the old crusty IDE drivers at a guess. The most obvious > > > change being the move from /dev/hd* to /dev/sd*. If you're > > > using mount-by-label, that should 'just work' though, so > > > perhaps either the driver is broken, or it needs a > > > workaround in mkinitrd like the other PATA drivers to wait > > > for the disk nodes to appear in /dev before we go looking > > > for volume groups. > > > > It panics, unable to mount on i386 without any LVM too. > > Asus A7V600, kt600 chipset, both pata an sata drives. My / is > > on hd0,0 an IDE pata drive. The sata (all storage) appears to > > be found before the kernel panics on IDE. All drives (2 pata, > > 1 sata) are ext3. > > Hmm, I just managed to reproduce this on a similar box. > Rerunning mkinitrd wasn't the answer though. The problem was that > there were a ton of SELinux denials. > > Can you try.. > > setenforce 0 > mkinitrd /boot/initrd-2.6.19-1.2877.fc7.img 2.6.19-1.2877.fc7 > > Dave Thanks for your interest, but no go While I've always disabled SELinux, I did run setenforce 0 an then mkinitrd /boot/initrd-2.6.19-1.2877.fc7.img 2.6.19-1.2877.fc7 (again) ;) I did this after bootin to rawhide (2849) an the result was, boot # du -k *initrd-2.6.19* 2877 initrd-2.6.19-1.2877.fc7.img 2877 sav2-initrd-2.6.19-1.2877.fc7.img 2872 sav-initrd-2.6.19-1.2877.fc7.img sav- is the original from a rawhide yum update, sav2- is my earlier attempt, an the results of re-doin it after setenforce 0 produced no change. It still panics on mount. I did make an error in my earlier post tho, which I suspect you picked up. / is not hd0,0 .. that is my /boot ... shared by FC6-test an FC7-rawhide (as is /swap, hda5) df for rawhide is, Filesystem Size Used Avail Use% Mounted on /dev/hdb1 9.9G 4.4G 5.1G 47% / /dev/hda1 92M 50M 37M 58% /boot tmpfs 506M 0 506M 0% /dev/shm /dev/hdb2 27G 5.7G 20G 23% /home /dev/hda8 41G 25G 14G 64% /stor2 /dev/sda1 151G 119G 25G 84% /stor4 df for fc6-test is, Filesystem Size Used Avail Use% Mounted on /dev/hda6 9.7G 4.7G 4.6G 51% / /dev/hda1 92M 50M 37M 58% /boot tmpfs 506M 0 506M 0% /dev/shm /dev/hda7 24G 9.7G 13G 44% /home /dev/hda8 41G 25G 14G 64% /stor2 /dev/sda1 151G 119G 25G 84% /stor4 -- Tom Brinkman Corpus Christi, Texas From pea510 at aol.de Mon Dec 18 09:16:26 2006 From: pea510 at aol.de (pea510 at aol.de) Date: Mon, 18 Dec 2006 04:16:26 -0500 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <20061218021508.GC8353@redhat.com> References: <20061216144334.GE23368@redhat.com> <200612161152.30703.tbrinkman@sbcglobal.net> <20061218021508.GC8353@redhat.com> Message-ID: <8C8F09C5484642F-161C-4DD4@mblk-r30.sysops.aol.com> >Hmm, I just managed to reproduce this on a similar box. >Rerunning mkinitrd wasn't the answer though. The problem was that >there were a ton of SELinux denials. > >Can you try.. > >setenforce 0 >mkinitrd /boot/initrd-2.6.19-1.2877.fc7.img 2.6.19-1.2877.fc7 > > Dave After a succsessful upgrade to kernel "2.6.19-1.2877.fc7.i686" on my "IBM ThinkPad T23", I have now run into problems when doing the same on my desktop system which is equipped with an onboard "SCSI" chip driven by "aix7xxx.ko". The latest "rescue" disk couldn't load the driver module and when selecting it manually, the above module was not even on the list. However, it is present in the kernel package. After updating "mkinitrd" to the latest "rawhide" version, I installed kernel "2.6.19-1.2877.fc7.i686" on the system ["SCSI" hard disk] and encountered the well known kernel panic after the kernel was unable to mount the root volume [/dev/mapper/VolGroup00-LogVol00]. The "initrd" file looks ok, in particular its size. The system is "FC6" plus updates instead of "rawhide" on my notebook but that's probably not the reason. "SELinux" is in permissive mode on both systems. Joachim Frieben ________________________________________________________________________ Testen Sie das neue, kostenlose AOL eMail: 2 GB Speicherplatz mit marktf?hrendem Spam- und eMail-Virenschutz. From buildsys at redhat.com Mon Dec 18 10:56:46 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 18 Dec 2006 05:56:46 -0500 Subject: rawhide report: 20061218 changes Message-ID: <200612181056.kBIAukgj021914@hs20-bc2-6.build.redhat.com> Updated Packages: kernel-2.6.19-1.2881.fc7 ------------------------ * Sun Dec 17 2006 David Woodhouse - Enable Efika platform support - Temporarily provide __ucmpdi2 on ppc32 to work around GCC PR #25724 Broken deps for i386 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 php-pgsql - 5.2.0-7.i386 requires libpq.so.4 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.i386 requires python(abi) = 0:2.4 Broken deps for ppc64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ppc64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree Broken deps for x86_64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.x86_64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.x86_64 requires python(abi) = 0:2.4 Broken deps for s390 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 php-pgsql - 5.2.0-7.s390 requires libpq.so.4 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ppc ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 php-pgsql - 5.2.0-7.ppc requires libpq.so.4 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree Broken deps for ia64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.ia64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.ia64 requires python(abi) = 0:2.4 Broken deps for s390x ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) php-pgsql - 5.2.0-7.s390x requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree From ottohaliburton at tx.rr.com Mon Dec 18 13:11:44 2006 From: ottohaliburton at tx.rr.com (Otto Haliburton) Date: Mon, 18 Dec 2006 07:11:44 -0600 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems(IA-64 architecture) In-Reply-To: <20061218021508.GC8353@redhat.com> Message-ID: <011e01c722a6$11828370$0201a8c0@C515816A> > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Dave Jones > Sent: Sunday, December 17, 2006 8:15 PM > To: Development discussions related to Fedora Core > Subject: Re: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium > systems(IA-64 architecture) > > On Sat, Dec 16, 2006 at 11:52:30AM -0600, Tom Brinkman wrote: > > > > Probably the changes to use libata PATA drivers instead of the > > > old crusty IDE drivers at a guess. The most obvious change being > > > the move from /dev/hd* to /dev/sd*. If you're using > > > mount-by-label, that should 'just work' though, so perhaps either > > > the driver is broken, or it needs a workaround in mkinitrd like > > > the other PATA drivers to wait for the disk nodes to appear in > > > /dev before we go looking for volume groups. > > > > > It panics, unable to mount on i386 without any LVM too. Asus > > A7V600, kt600 chipset, both pata an sata drives. My / is on hd0,0 > > an IDE pata drive. The sata (all storage) appears to be found > > before the kernel panics on IDE. All drives (2 pata, 1 sata) are > > ext3. > > Hmm, I just managed to reproduce this on a similar box. > Rerunning mkinitrd wasn't the answer though. The problem was that > there were a ton of SELinux denials. > > Can you try.. > > setenforce 0 > mkinitrd /boot/initrd-2.6.19-1.2877.fc7.img 2.6.19-1.2877.fc7 > > Dave > > -- > http://www.codemonkey.org.u I'm curious if anyone has checked /boot/device.map to see if the proper devices are mapped. From pbruna at it-linux.cl Mon Dec 18 14:21:38 2006 From: pbruna at it-linux.cl (Patricio A. Bruna) Date: Mon, 18 Dec 2006 11:21:38 -0300 (CLST) Subject: Customize Rescue CD Message-ID: <20892470.291166451698881.JavaMail.root@lisa.it-linux.cl> hi, how can i customize de rescue enviroment of Fedora, i need to add a couple of software to it. regards. PS: Anyone knows how can i build a live cd with more that one distro? for example, fedora 2 rescue and fedora 3 rescue, they have diferents kernels, so the mkfs.ext3 has diferent formats. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clydekunkel7734 at cox.net Mon Dec 18 15:34:02 2006 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Mon, 18 Dec 2006 10:34:02 -0500 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <20061218021508.GC8353@redhat.com> References: <20061216144334.GE23368@redhat.com> <200612161152.30703.tbrinkman@sbcglobal.net> <20061218021508.GC8353@redhat.com> Message-ID: <4586B4EA.9000006@cox.net> Dave Jones wrote: > On Sat, Dec 16, 2006 at 11:52:30AM -0600, Tom Brinkman wrote: > > > > > > It panics, unable to mount on i386 without any LVM too. Asus > > A7V600, kt600 chipset, both pata an sata drives. My / is on hd0,0 > > an IDE pata drive. The sata (all storage) appears to be found > > before the kernel panics on IDE. All drives (2 pata, 1 sata) are > > ext3. > > Hmm, I just managed to reproduce this on a similar box. > Rerunning mkinitrd wasn't the answer though. The problem was that > there were a ton of SELinux denials. > > Can you try.. > > setenforce 0 > mkinitrd /boot/initrd-2.6.19-1.2877.fc7.img 2.6.19-1.2877.fc7 > > Dave > Doesn't work for me on a system with mixed SATA and traditional IDE. Root is on a software raid device. Using LABEL references vice actual /dev names. Same panic as others are reporting. Booted older working kernel and reran mkinitrd forcing use of raid modules; however, even tho raid devices seen, same panic. Looked for a BZ but don't see one. Wouldn't one be filed under mkinitrd? -- Regards, Old Fart (my reply-to address is "munged" to defeat spambots) From davej at redhat.com Mon Dec 18 16:12:42 2006 From: davej at redhat.com (Dave Jones) Date: Mon, 18 Dec 2006 11:12:42 -0500 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <4586B4EA.9000006@cox.net> References: <20061216144334.GE23368@redhat.com> <200612161152.30703.tbrinkman@sbcglobal.net> <20061218021508.GC8353@redhat.com> <4586B4EA.9000006@cox.net> Message-ID: <20061218161242.GF14286@redhat.com> On Mon, Dec 18, 2006 at 10:34:02AM -0500, Clyde E. Kunkel wrote: > Doesn't work for me on a system with mixed SATA and traditional IDE. > Root is on a software raid device. Software raid is currently busted. (it won't get autostarted, and the mkinitrd magic to start it isn't there yet). > /dev names. Same panic as others are reporting. Booted older working > kernel and reran mkinitrd forcing use of raid modules; however, even tho > raid devices seen, same panic. > > Looked for a BZ but don't see one. Wouldn't one be filed under mkinitrd? Its already on Peters 'todo' list, don't know if there's a bug for it. Dave -- http://www.codemonkey.org.uk From ajackson at redhat.com Mon Dec 18 16:14:13 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 18 Dec 2006 11:14:13 -0500 Subject: With GL based desktops, how relevant in screen resolution? In-Reply-To: <1166149755.3537.47.camel@localhost.localdomain> References: <1166149755.3537.47.camel@localhost.localdomain> Message-ID: <1166458453.7683.414.camel@localhost.localdomain> On Fri, 2006-12-15 at 13:29 +1100, Rodd Clarkson wrote: > (These aren't completely new thoughts, I've heard them discussed before, > but I thought that with the advent of a GL based desktop for Fedora it > might be interesting to have this discussion.) > > How relevant is screen resolution now that my desktop is now GL based. Let's not go wild here. Your desktop is _not_ a vector UI yet. You're rendering to textures, which do have finite numbers of pixels; they are not vector maps. If you scale them up (by a non-integer factor), they will look fuzzy. > For example, rather than having to pick a new resolution to make my > desktop (fonts, titlebars, etc.) look bigger or smaller, couldn't we now > just have a slider that makes the desktop appear bigger or smaller? This has always been possible. Just remember that all intermediate rendering results within the X server are collections of pixels; if you're going to rasterize a vector representation (like say, a font), you can get measurably better results by knowing how large your output pixels are going to be. Until your screen starts scanning out something other than pixels, this will continue to be true. Therefore: you want as many pixels as possible, and you want them all to be _tiny_. The better your pixels approximate Platonic points, the better your rasterization will look. Just because we're using GL to compose the scene doesn't mean we're not rasterizing. The problem of then making GTK and Gnome into something resembling a vector API is... well, let's just say "harder". > Another example. (This is what got me thinking about this). If I've > got an application that works at a particular size (say 800x600 in the > old measure) and I want it a different size, what's stopping us from > being able to proportionally re-size a window to make it smaller or > larger? This might be useful for games, or if you want to resize a > mozilla window to make the fonts larger, but keep the layout > proportional including images. Technically there's nothing hard about this. The UI seems difficult though, you really don't want to overload the resize handles on the window frame. Maybe a decoration button of a magnifying glass (two, one + and one - maybe), that triggers the compositor to do an integer scale? Shrug. I'm not a good UI designer. Hopefully someone else is. Basically, in the rest state where your compositor isn't animating a transition, you generally want all your windows to have one texel of their output correspond to exactly one pixel on the screen, because that looks best. The challenge is getting all your apps to scale their UI elements to be a consistent size. GTK is not using GL internally to render widgets, so there's no direct scaling available there; you'll still need to scale up inside GTK in terms of pixels. Also insert something handwavey here about GL font rendering not being good enough yet to switch. So we're still dealing with rasterized temporaries for a while to come. The full other end of the spectrum would be representing all UI elements as a vector-format scene graph. In this model, none of your apps render in terms of pixels at all. If they really need to (say, to draw an icon that only exists in pixmap format), they specify a box to draw it in and the renderer takes care of scaling it. Heavy lifting required. Plus, the old raster API would still need to work, since ABI compatibility is a harsh mistress. In the middle you've got something like a global zoom factor slider with appropriate scaling done at all levels of GTK. Gets good results fast, and relatively straightforward to implement, once you find someone to implement it. In fact we _almost_ have this, in the bogglingly inaccurately named "Resolution" setting in the Fonts preferences, and it would work pretty well if the rest of the stack would scale its UI to match. The tricky parts are things like picking icon size, scaling the panels, etc. So to answer your question: resolution is still very relevant. And will always _be_ relevant to the app doing the final rasterization, unless screens start rendering things other than pixels. But we can make the rest of the pipeline more pixel-agnostic, and it's generally a good thing to do. - ajax From clydekunkel7734 at cox.net Mon Dec 18 16:24:32 2006 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Mon, 18 Dec 2006 11:24:32 -0500 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <20061218161242.GF14286@redhat.com> References: <20061216144334.GE23368@redhat.com> <200612161152.30703.tbrinkman@sbcglobal.net> <20061218021508.GC8353@redhat.com> <4586B4EA.9000006@cox.net> <20061218161242.GF14286@redhat.com> Message-ID: <4586C0C0.9090703@cox.net> Dave Jones wrote: > On Mon, Dec 18, 2006 at 10:34:02AM -0500, Clyde E. Kunkel wrote: > > > Doesn't work for me on a system with mixed SATA and traditional IDE. > > Root is on a software raid device. > > Software raid is currently busted. > Dave > Ouch!!! -- Regards, Old Fart (my reply-to address is "munged" to defeat spambots) From ajackson at redhat.com Mon Dec 18 16:29:17 2006 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 18 Dec 2006 11:29:17 -0500 Subject: Enabled mach64_dri in kernel, mesa? (fc7,rawhide) In-Reply-To: <1166379353.12924.15.camel@gilboa-work-dev.localdomain> References: <1166379353.12924.15.camel@gilboa-work-dev.localdomain> Message-ID: <1166459358.7683.417.camel@localhost.localdomain> On Sun, 2006-12-17 at 20:15 +0200, Gilboa Davara wrote: > Hello all, > > According to [1] and [2], the latest mach64 mesa (6.5.x) driver is > considered secure. > Could it be possible to implant the mach64.* code into the kernel source > (from drm) and enable mach64_dri in the mesa spec? > (I can live with the missing mach64.ko kernel module; However, having to > rebuild mesa on a PII366 every time a new mesa package is released to > fc6-updates is a -huge- pain in the backside) I'll look into this. Adding the DRI driver is no problem, but the DRM isn't upstream yet last I checked. - ajax From jreiser at BitWagon.com Mon Dec 18 17:47:49 2006 From: jreiser at BitWagon.com (John Reiser) Date: Mon, 18 Dec 2006 09:47:49 -0800 Subject: Customize Rescue CD In-Reply-To: <20892470.291166451698881.JavaMail.root@lisa.it-linux.cl> References: <20892470.291166451698881.JavaMail.root@lisa.it-linux.cl> Message-ID: <4586D445.3000107@BitWagon.com> > how can i customize de rescue enviroment of Fedora, i need to add a couple of software to it. Find the recipe for building the rescue disk, and change it. :-) Or, reverse engineer it: # mount -o ro,loop FC-6-i386-rescuecd.iso /mnt/tmp1 $ cd /mnt/tmp1; ls images isolinux TRANS.TBL $ (cd images; ls; file state2.img) stage2.img TRANS.TBL stage2.img: Squashfs filesystem ... $ (cd isolinux; ls; file initrd.img) ... initrd.img ... initrd.img: gzip compressed ... $ gzip -d -c isolinux/initrd.img >/tmp/initrd $ file /tmp/initrd /tmp/initrd: ASCII cpio archive $ cpio --list --verbose PS: Anyone knows how can i build a live cd with more that one distro? Have more than one stage2.img file; choose and mount the one you want. -- From pbruna at it-linux.cl Mon Dec 18 20:43:03 2006 From: pbruna at it-linux.cl (Patricio A. Bruna) Date: Mon, 18 Dec 2006 17:43:03 -0300 (CLST) Subject: Customize Rescue CD In-Reply-To: <4586D445.3000107@BitWagon.com> Message-ID: <24720983.631166474583126.JavaMail.root@lisa.it-linux.cl> John, Thx for the reply, do you have any web link where i can find more info about build this thing? im a little short of "Build a booteable cd" ----- Mensaje Original ----- De: John Reiser Para: Development discussions related to Fedora Core Enviados: lunes 18 de diciembre de 2006 14H47 GMT-0400 America/Santiago Asunto: Re: Customize Rescue CD > how can i customize de rescue enviroment of Fedora, i need to add a couple of software to it. Find the recipe for building the rescue disk, and change it. :-) Or, reverse engineer it: # mount -o ro,loop FC-6-i386-rescuecd.iso /mnt/tmp1 $ cd /mnt/tmp1; ls images isolinux TRANS.TBL $ (cd images; ls; file state2.img) stage2.img TRANS.TBL stage2.img: Squashfs filesystem ... $ (cd isolinux; ls; file initrd.img) ... initrd.img ... initrd.img: gzip compressed ... $ gzip -d -c isolinux/initrd.img >/tmp/initrd $ file /tmp/initrd /tmp/initrd: ASCII cpio archive $ cpio --list --verbose PS: Anyone knows how can i build a live cd with more that one distro? Have more than one stage2.img file; choose and mount the one you want. -- -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreiser at BitWagon.com Mon Dec 18 20:53:25 2006 From: jreiser at BitWagon.com (John Reiser) Date: Mon, 18 Dec 2006 12:53:25 -0800 Subject: Customize Rescue CD In-Reply-To: <24720983.631166474583126.JavaMail.root@lisa.it-linux.cl> References: <24720983.631166474583126.JavaMail.root@lisa.it-linux.cl> Message-ID: <4586FFC5.4010305@BitWagon.com> > I'm a little short of "Build a bootable cd" Use Google. Or, search the Red Hat mailing list archives for my posts: 2006-08-06 nahant-list Re: DVD ISO creation script? 2005-11-23 fedora-test-list Re: FC5 Test1 DVD 2005-02-23 nahant-list Re: RHEL 4 DVD ? [A DVD cannot be distinguished from a CD except for storage capacity.] -- From buildsys at redhat.com Tue Dec 19 11:02:30 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 19 Dec 2006 06:02:30 -0500 Subject: rawhide report: 20061219 changes Message-ID: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> Updated Packages: ORBit2-2.14.4-1.fc7 ------------------- * Tue Dec 19 2006 Matthias Clasen - 2.14.4-1 - Update to 2.14.4 am-utils-5:6.1.5-5 ------------------ * Mon Dec 18 2006 Karel Zak 5:6.1.5-5 - fix #219437 - amd: stopping service will pop up an error dialog in system-config-services app. - fix build (m4 stuff) of the package (UTS_RELEASE macro has been removed from the latest kernel-headers) anaconda-11.2.0.7-1 ------------------- * Sun Dec 17 2006 Jeremy Katz - 11.2.0.7-1 - Clean up execConsole to work better (clumens, #210481, #16155) - Fixes due to earlier changes (dcantrell, #219789) - Build fix for new kernel headers * Thu Dec 14 2006 Jeremy Katz - 11.2.0.6-1 - fix build for no more md START_ARRAY; note that this leaves swraid broken * Thu Dec 14 2006 Jeremy Katz - 11.2.0.5-1 - Fix adding zfcp devices (dcantrell, #210635) - Fix rescue mode (clumens) - Do dasdfmt based on initlabel (dcantrell, #218861) - Adjust for official xvc0 major/minor - Abstract required media for different backends (Elliot Peele) - Fix overflow of source CDs (Dawei Pang) - EDD should work on x86_64 (#218123) - Better ipv6 config for second stage (dcantrell, #213110, #213112) - Fix iscsi typo, don't traceback when iscsi isn't present (#218513) - Unmount CD after install when using local stage2 with http install (clumens) - Don't set LIBUSER_CONF in %post scripts (#218213) - Some python 2.5 updates curl-7.16.0-4.fc7 ----------------- * Mon Dec 18 2006 Jindrich Novy 7.16.0-4 - convert spec to UTF-8 - don't delete BuildRoot in %prep phase - rpmlint fixes eel2-2.17.1-1.fc7 ----------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.1-1 - Update to 2.17.1 file-roller-2.17.4-1.fc7 ------------------------ * Tue Dec 19 2006 Matthias Clasen - 2.17.4-1 - Update to 2.17.4 firstboot-1.4.28-1.fc7 ---------------------- * Mon Dec 18 2006 Chris Lumens 1.4.28-1 - Remove unused graphics (#218118). - Allow running on s390 and ppc64 under reconfig mode (#217921). - Don't leave a bunch of defunct processes around. - Correctly shut down if not running under rhgb. frysk-0.0.1.2006.12.18.rh1-1.fc7 -------------------------------- * Mon Dec 18 2006 Stepan Kasal - 0.0.1.2006.12.18.rh1-1 - New upstream version. - Do not install the .desktop file. - Resolves: #211200 - Split to frysk, frysk-devel, and frysk-gnome; move the requires for gui java-gnome libraries to frysk-gnome. - Resolves: #218835 - Remove frysk-arch32-disable.patch, use --disable-arch32-tests instead. - Disable ppc64 build. gcalctool-5.9.9-1.fc7 --------------------- * Tue Dec 19 2006 Matthias Clasen - 5.9.9-1 - Update to 5.9.9 gconf-editor-2.17.0-1.fc7 ------------------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.0-1 - Update to 2.17.0 glib2-2.12.5-1.fc7 ------------------ * Mon Dec 18 2006 Matthias Clasen - 2.12.5-1 - Update to 2.12.5 gnome-keyring-0.7.2-1.fc7 ------------------------- * Tue Dec 19 2006 Matthias Clasen - 0.7.2-1 - Update to 0.7.2 gnome-keyring-manager-2.17.0-1.fc7 ---------------------------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.0-1 - Update to 2.17.0 gnome-mag-0.14.0-1.fc7 ---------------------- * Mon Dec 18 2006 Matthias Clasen - 0.14.0-1 - Update to 0.14.0 gnome-system-monitor-2.17.4-1.fc7 --------------------------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.4-1 - Update to 2.17.4 gnome-vfs2-2.17.1-1.fc7 ----------------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.1-1 - Update to 2.17.1 gtksourceview-1.8.2-1.fc7 ------------------------- * Mon Dec 18 2006 Matthias Clasen - 1.8.2-1 - Update to 1.8.2 htdig-3:3.2.0b6-7.fc7 --------------------- * Mon Dec 18 2006 Adam Tkac 3:3.2.0b6-7.fc7 - really fixed #130528 - started using dist macro kernel-2.6.19-1.2885.fc7 ------------------------ * Mon Dec 18 2006 David Woodhouse - Enable CONFIG_IDE on PowerPC, for PMAC. Need pata_pmac driver... - Fix the deleteme handling - Fix build on platforms without writel_be() - Fix connector build failure * Sun Dec 17 2006 Dave Jones - 2.6.20rc1-git5 mesa-6.5.2-4.fc7 ---------------- * Mon Dec 18 2006 Adam Jackson 6.5.2-4 - Add i915tex and mach64 to the install set. nautilus-2.17.1-1.fc7 --------------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.1-1 - Update to 2.17.1 nautilus-cd-burner-2.17.4-1.fc7 ------------------------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.4-1 - Update to 2.17.4 php-5.2.0-8 ----------- * Tue Dec 05 2006 Joe Orton 5.2.0-8 - fix filter.h installation path - fix php-zend-abi version (Remi Collet, #212804) policycoreutils-1.33.6-6.fc7 ---------------------------- * Fri Dec 08 2006 Dan Walsh 1.33.6-6 - Fix audit2allow generating reference policy selinux-policy-2.4.6-15.fc7 --------------------------- * Mon Dec 18 2006 Dan Walsh 2.4.6-15 - allow automount to setgid Resolves: #219999 sysstat-7.0.3-1.fc7 ------------------- * Mon Dec 18 2006 Ivana Varekova -7.0.3-1 - update to 7.0.3 xorg-x11-server-1.1.1-56.fc7 ---------------------------- * Mon Dec 18 2006 Adam Jackson 1.1.1-56 - RHEL5 sync: - xorg-x11-server-1.1.1-maxpixclock-option.patch: Allow the maximum pixel clock of a monitor to be specified in the config file. - xorg-x11-server-1.1.1-glcore-visual-matching.patch: Fix a client crash when creating software indirect GLX contexts. - xorg-x11-server-1.1.1-vt-activate-is-a-terrible-api.patch: During server init, abort if either VT activation ioctl fails. During shutdown, be sure to wait for the VT switch to finish before exiting. Broken deps for ppc64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) firstboot - 1.4.28-1.fc7.noarch requires system-config-keyboard firstboot - 1.4.28-1.fc7.noarch requires system-config-display setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree Broken deps for i386 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.i386 requires python(abi) = 0:2.4 Broken deps for x86_64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.x86_64 requires python(abi) = 0:2.4 Broken deps for ia64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.ia64 requires python(abi) = 0:2.4 Broken deps for ppc ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree Broken deps for s390 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 firstboot - 1.4.28-1.fc7.noarch requires system-config-keyboard firstboot - 1.4.28-1.fc7.noarch requires system-config-soundcard firstboot - 1.4.28-1.fc7.noarch requires rhpxl >= 0:0.19 firstboot - 1.4.28-1.fc7.noarch requires system-config-display setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for s390x ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) firstboot - 1.4.28-1.fc7.noarch requires rhpxl >= 0:0.19 firstboot - 1.4.28-1.fc7.noarch requires system-config-display firstboot - 1.4.28-1.fc7.noarch requires system-config-keyboard firstboot - 1.4.28-1.fc7.noarch requires system-config-soundcard setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree From gilboad at gmail.com Tue Dec 19 11:45:02 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 19 Dec 2006 13:45:02 +0200 Subject: Enabled mach64_dri in kernel, mesa? (fc7,rawhide) In-Reply-To: <1166459358.7683.417.camel@localhost.localdomain> References: <1166379353.12924.15.camel@gilboa-work-dev.localdomain> <1166459358.7683.417.camel@localhost.localdomain> Message-ID: <1166528702.6886.83.camel@gilboa-work-dev.localdomain> On Mon, 2006-12-18 at 11:29 -0500, Adam Jackson wrote: > On Sun, 2006-12-17 at 20:15 +0200, Gilboa Davara wrote: > > Hello all, > > > > According to [1] and [2], the latest mach64 mesa (6.5.x) driver is > > considered secure. > > Could it be possible to implant the mach64.* code into the kernel source > > (from drm) and enable mach64_dri in the mesa spec? > > (I can live with the missing mach64.ko kernel module; However, having to > > rebuild mesa on a PII366 every time a new mesa package is released to > > fc6-updates is a -huge- pain in the backside) > > I'll look into this. Adding the DRI driver is no problem, but the DRM > isn't upstream yet last I checked. > > - ajax > AFAIK the updated DRM has yet to be integrated into the main trunk. I may be wrong, though. Either way, if you can enable the mach_64.drv (Patch attached) I'll be -very- grateful. - Gilboa -------------- next part -------------- A non-text attachment was scrubbed... Name: mesa.patch Type: text/x-patch Size: 459 bytes Desc: not available URL: From gilboad at gmail.com Tue Dec 19 12:44:10 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 19 Dec 2006 14:44:10 +0200 Subject: rawhide report: 20061219 changes In-Reply-To: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> References: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> Message-ID: <1166532250.6886.95.camel@gilboa-work-dev.localdomain> On Tue, 2006-12-19 at 06:02 -0500, buildsys at redhat.com wrote: > > mesa-6.5.2-4.fc7 > ---------------- > * Mon Dec 18 2006 Adam Jackson 6.5.2-4 > - Add i915tex and mach64 to the install set. Thanks! Can you down-stream this package to FC6-updates? - Gilboa From ajackson at redhat.com Tue Dec 19 13:13:21 2006 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 19 Dec 2006 08:13:21 -0500 Subject: Enabled mach64_dri in kernel, mesa? (fc7,rawhide) In-Reply-To: <1166528702.6886.83.camel@gilboa-work-dev.localdomain> References: <1166379353.12924.15.camel@gilboa-work-dev.localdomain> <1166459358.7683.417.camel@localhost.localdomain> <1166528702.6886.83.camel@gilboa-work-dev.localdomain> Message-ID: <1166534001.7683.447.camel@localhost.localdomain> On Tue, 2006-12-19 at 13:45 +0200, Gilboa Davara wrote: > AFAIK the updated DRM has yet to be integrated into the main trunk. > I may be wrong, though. Yeah, I poked Dave Airlie about it yesterday. He took a quick look and had some slight reservations about the security claim, so between that and the rawhide kernel not building (thanks Xen!) I haven't finished that part yet. I'll try to work in a review of the DRM soonish. > Either way, if you can enable the mach_64.drv (Patch attached) I'll be > -very- grateful. Done, thanks! - ajax From davej at redhat.com Tue Dec 19 15:06:53 2006 From: davej at redhat.com (Dave Jones) Date: Tue, 19 Dec 2006 10:06:53 -0500 Subject: Enabled mach64_dri in kernel, mesa? (fc7,rawhide) In-Reply-To: <1166534001.7683.447.camel@localhost.localdomain> References: <1166379353.12924.15.camel@gilboa-work-dev.localdomain> <1166459358.7683.417.camel@localhost.localdomain> <1166528702.6886.83.camel@gilboa-work-dev.localdomain> <1166534001.7683.447.camel@localhost.localdomain> Message-ID: <20061219150653.GF25461@redhat.com> On Tue, Dec 19, 2006 at 08:13:21AM -0500, Adam Jackson wrote: > On Tue, 2006-12-19 at 13:45 +0200, Gilboa Davara wrote: > > > AFAIK the updated DRM has yet to be integrated into the main trunk. > > I may be wrong, though. > > Yeah, I poked Dave Airlie about it yesterday. He took a quick look and > had some slight reservations about the security claim, so between that > and the rawhide kernel not building (thanks Xen!) I haven't finished > that part yet. Xen in rawhide is a lost cause right now. Just disable it. Dave -- http://www.codemonkey.org.uk From cra at WPI.EDU Tue Dec 19 16:11:15 2006 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 19 Dec 2006 11:11:15 -0500 Subject: rawhide report: 20061219 changes In-Reply-To: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> References: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> Message-ID: <20061219161115.GG12152@angus.ind.WPI.EDU> On Tue, Dec 19, 2006 at 06:02:30AM -0500, buildsys at redhat.com wrote: > - Better ipv6 config for second stage (dcantrell, #213110, #213112) Is it possible to make these bugs accessible to the public? Thanks. From pgraner at redhat.com Tue Dec 19 16:24:04 2006 From: pgraner at redhat.com (Pete Graner) Date: Tue, 19 Dec 2006 17:24:04 +0100 Subject: rawhide report: 20061219 changes In-Reply-To: <20061219161115.GG12152@angus.ind.WPI.EDU> References: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> <20061219161115.GG12152@angus.ind.WPI.EDU> Message-ID: <45881224.8010707@redhat.com> Chuck Anderson wrote: > On Tue, Dec 19, 2006 at 06:02:30AM -0500, buildsys at redhat.com wrote: >> - Better ipv6 config for second stage (dcantrell, #213110, #213112) > > Is it possible to make these bugs accessible to the public? > > Thanks. > Done. Pete -- Pete Graner email: Senior Engineering Manager Office: 978.392.2476 Base Operating Systems Mobile: 978.987.3125 Red Hat Inc. http://www.redhat.com From darrellpf at gmail.com Tue Dec 19 17:08:16 2006 From: darrellpf at gmail.com (darrell pfeifer) Date: Tue, 19 Dec 2006 09:08:16 -0800 Subject: rawhide report: 20061219 changes In-Reply-To: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> References: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> Message-ID: >xorg-x11-server-1.1.1-56.fc7 >---------------------------- >* Mon Dec 18 2006 Adam Jackson 1.1.1-56 >- RHEL5 sync: > snip >- xorg-x11-server-1.1.1-vt-activate-is-a-terrible-api.patch: During server > init, abort if either VT activation ioctl fails. During shutdown, be > sure to wait for the VT switch to finish before exiting. X server hangs at boot when starting up, sometimes with the gray screen, sometimes with the start of the gdm blue screen. Booting runlevel 3, logging in as root and then telinit 5 is successful. darrell From vismor.td at gmail.com Tue Dec 19 17:24:45 2006 From: vismor.td at gmail.com (Timothy Vismor) Date: Tue, 19 Dec 2006 12:24:45 -0500 Subject: rawhide report: 20061219 changes In-Reply-To: References: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> Message-ID: <7946769f0612190924q26c2839ck4534e49df2c41c03@mail.gmail.com> On 12/19/06, darrell pfeifer wrote: > >xorg-x11-server-1.1.1-56.fc7 > >---------------------------- > >* Mon Dec 18 2006 Adam Jackson 1.1.1-56 > >- RHEL5 sync: > > snip > >- xorg-x11-server-1.1.1-vt-activate-is-a-terrible-api.patch: During server > > init, abort if either VT activation ioctl fails. During shutdown, be > > sure to wait for the VT switch to finish before exiting. > > X server hangs at boot when starting up, sometimes with the > gray screen, sometimes with the start of the gdm blue screen. > > Booting runlevel 3, logging in as root and then telinit 5 is successful. > > darrell > Same problem here. I turned of rhgb and booted successfully. From dragoran at feuerpokemon.de Tue Dec 19 18:36:32 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 19 Dec 2006 19:36:32 +0100 Subject: rawhide report: 20061219 changes In-Reply-To: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> References: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> Message-ID: <45883130.7090203@feuerpokemon.de> > anaconda-11.2.0.7-1 > ------------------- > * Sun Dec 17 2006 Jeremy Katz - 11.2.0.7-1 > - Clean up execConsole to work better (clumens, #210481, #16155) > - Fixes due to earlier changes (dcantrell, #219789) > - Build fix for new kernel headers > > * Thu Dec 14 2006 Jeremy Katz - 11.2.0.6-1 > - fix build for no more md START_ARRAY; note that this leaves swraid broken > does this mean that this anaconda does not support software raid? From ajackson at redhat.com Tue Dec 19 18:44:47 2006 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 19 Dec 2006 13:44:47 -0500 Subject: rawhide report: 20061219 changes In-Reply-To: References: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> Message-ID: <1166553887.7683.452.camel@localhost.localdomain> On Tue, 2006-12-19 at 09:08 -0800, darrell pfeifer wrote: > >xorg-x11-server-1.1.1-56.fc7 > >---------------------------- > >* Mon Dec 18 2006 Adam Jackson 1.1.1-56 > >- RHEL5 sync: > > snip > >- xorg-x11-server-1.1.1-vt-activate-is-a-terrible-api.patch: During server > > init, abort if either VT activation ioctl fails. During shutdown, be > > sure to wait for the VT switch to finish before exiting. > > X server hangs at boot when starting up, sometimes with the > gray screen, sometimes with the start of the gdm blue screen. Gah! Apparently the rhgb patch that goes with this never made it to rawhide. Built now, should be in rawhide tomorrow. - ajax From Liste at FamilleCollet.com Tue Dec 19 18:50:49 2006 From: Liste at FamilleCollet.com (Remi Collet) Date: Tue, 19 Dec 2006 19:50:49 +0100 Subject: rawhide report: 20061219 changes In-Reply-To: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> References: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> Message-ID: <45883489.4040603@FamilleCollet.com> buildsys at redhat.com a ?crit : > php-5.2.0-8 > ----------- > * Tue Dec 05 2006 Joe Orton 5.2.0-8 > - fix filter.h installation path > - fix php-zend-abi version (Remi Collet, #212804) I think this new virtual provides give us the opportunity to modify the "Guidelines for packaging PHP addon modules" for all pecl packages to require this (fc6 and fc7) From katzj at redhat.com Tue Dec 19 19:04:33 2006 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 19 Dec 2006 14:04:33 -0500 Subject: rawhide report: 20061219 changes In-Reply-To: <45883130.7090203@feuerpokemon.de> References: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> <45883130.7090203@feuerpokemon.de> Message-ID: <1166555073.4024.5.camel@aglarond.local> On Tue, 2006-12-19 at 19:36 +0100, dragoran wrote: > > anaconda-11.2.0.7-1 > > ------------------- > > * Sun Dec 17 2006 Jeremy Katz - 11.2.0.7-1 > > - Clean up execConsole to work better (clumens, #210481, #16155) > > - Fixes due to earlier changes (dcantrell, #219789) > > - Build fix for new kernel headers > > > > * Thu Dec 14 2006 Jeremy Katz - 11.2.0.6-1 > > - fix build for no more md START_ARRAY; note that this leaves swraid broken > > > does this mean that this anaconda does not support software raid? For the moment, yes. Definitely something that will have to be resolved prior to F7; patches cheerfully accepted if anyone wants to take a look :-) Jeremy From tibbs at math.uh.edu Tue Dec 19 19:56:09 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 19 Dec 2006 13:56:09 -0600 Subject: rawhide report: 20061219 changes In-Reply-To: <45883489.4040603@FamilleCollet.com> References: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> <45883489.4040603@FamilleCollet.com> Message-ID: >>>>> "RC" == Remi Collet writes: > php-5.2.0-8 > ----------- > * Tue Dec 05 2006 Joe Orton 5.2.0-8 > - fix filter.h installation path > - fix php-zend-abi version (Remi Collet, #212804) RC> I think this new virtual provides give us the opportunity to RC> modify the "Guidelines for packaging PHP addon modules" for all RC> pecl packages to require this (fc6 and fc7) Could you elaborate on that a bit? We currently have mandate Requires: php-abi = version; how would we use php-zend-abi? - J< From kmacmill at redhat.com Tue Dec 19 22:14:41 2006 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 19 Dec 2006 17:14:41 -0500 Subject: Fast User Switching and security / SELinux Message-ID: <45886451.8070601@redhat.com> Reading through http://fedoraproject.org/wiki/Desktop/FastUserSwitching, I had two questions. 1) Any work ongoing to look at the security of this solution. For example, the proposed fix for device ownership allows multiple users to use devices simultaneously. This could have serious security implications (e.g., monitoring VIOP calls made by another user). 2) Some work will likely be needed for this to work well with SELinux, particularly as we are looking at locking down user apps as an option in the future (evolution, firefox, etc.). This may also include XACE (http://blogs.sun.com/alanc/entry/xace_merged_into_xorg_for - just ignore the trusted extensions notes). Any current plans on tackling this? Thanks - Karl From david at fubar.dk Tue Dec 19 23:04:29 2006 From: david at fubar.dk (David Zeuthen) Date: Tue, 19 Dec 2006 18:04:29 -0500 Subject: Fast User Switching and security / SELinux In-Reply-To: <45886451.8070601@redhat.com> References: <45886451.8070601@redhat.com> Message-ID: <1166569469.2597.22.camel@zelda.fubar.dk> On Tue, 2006-12-19 at 17:14 -0500, Karl MacMillan wrote: > Reading through http://fedoraproject.org/wiki/Desktop/FastUserSwitching, > I had two questions. > > 1) Any work ongoing to look at the security of this solution. For > example, the proposed fix for device ownership allows multiple users to > use devices simultaneously. This could have serious security > implications (e.g., monitoring VIOP calls made by another user). No code yet, plans include using ACL's on device nodes and have *some* way of specifying whether a device of a given class can have multiple owners or not. Preferably specifying this so it can be locked down. Whether the driver in question support multiple openers (it varies, even within the same class e.g. ALSA) is another question. All this will probably mean replacing pam-console with *something*, not a bad idea anyway since pam-console is one reason that e.g. udev takes a long time to start. It just does a lot of work on every uevent that it doesn't need to do. Again, no code is written yet. For discussion please follow up on the Wiki page, not on this mailing list (as such, Karl, please add notes to the Wiki page). Thanks. David From sdl.web at gmail.com Wed Dec 20 01:11:36 2006 From: sdl.web at gmail.com (Leo) Date: Wed, 20 Dec 2006 01:11:36 +0000 Subject: What's going on with `yum install tracker' Message-ID: Hi all, I suspect there is a bug? Could you look at the output of 'yum install track'? ,---- | [root at leo ~]# yum install tracker | Loading "installonlyn" plugin | Setting up Install Process | Setting up repositories | Reading repository metadata in from local files | Parsing package install arguments | Resolving Dependencies | --> Populating transaction set with selected packages. Please wait. | ---> Package mikmod.i386 0:3.1.6-38.1 set to be updated | --> Running transaction check | | Dependencies Resolved | | ============================================================================= | Package Arch Version Repository Size | ============================================================================= | Installing: | mikmod i386 3.1.6-38.1 core 200 k | | Transaction Summary | ============================================================================= | Install 1 Package(s) | Update 0 Package(s) | Remove 0 Package(s) | | Total download size: 200 k | Is this ok [y/N]: `---- -- Leo (GPG Key: 9283AA3F) From jspaleta at gmail.com Wed Dec 20 05:09:01 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 19 Dec 2006 20:09:01 -0900 Subject: What's going on with `yum install tracker' In-Reply-To: References: Message-ID: <604aa7910612192109n6e3d9fbajfc00a64e18c4a41f@mail.gmail.com> On 12/19/06, Leo wrote: > Hi all, > > I suspect there is a bug? Could you look at the output of 'yum install > track'? The mikmod that shipped with FC6 had an explicit obsolete statement for tracker. rpm -q --obsoletes -p mikmod-3.1.6-38.1.i386.rpm tracker The mikmod released as an update no longer carries the obsolete rpm -q --changelog mikmod * Thu Nov 09 2006 Martin Stransky - 3.1.6-39 - removed obsoletes on tracker (#214112) The workaround is to use: yum --disablerepo=core install tracker or set obsoletes=0 in the yum.conf Technically... the bug has been fixed, the latest mikmod packages no longer obsolete 'tracker'. But because of the way obsoletes work it still causes problems. There is no automatic way to override a specific obsolete, you have to disable the calculation of obseletes in some fashion. -jef"time to trim a tree"spaleta From skvidal at linux.duke.edu Wed Dec 20 06:42:40 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 20 Dec 2006 01:42:40 -0500 Subject: What's going on with `yum install tracker' In-Reply-To: <604aa7910612192109n6e3d9fbajfc00a64e18c4a41f@mail.gmail.com> References: <604aa7910612192109n6e3d9fbajfc00a64e18c4a41f@mail.gmail.com> Message-ID: <1166596960.25450.0.camel@cutter> On Tue, 2006-12-19 at 20:09 -0900, Jeff Spaleta wrote: > On 12/19/06, Leo wrote: > > Hi all, > > > > I suspect there is a bug? Could you look at the output of 'yum install > > track'? > > > The mikmod that shipped with FC6 had an explicit obsolete statement for tracker. > rpm -q --obsoletes -p mikmod-3.1.6-38.1.i386.rpm > tracker > > The mikmod released as an update no longer carries the obsolete > rpm -q --changelog mikmod > * Thu Nov 09 2006 Martin Stransky - 3.1.6-39 > - removed obsoletes on tracker (#214112) > > The workaround is to use: > yum --disablerepo=core install tracker > > or set obsoletes=0 in the yum.conf > > Technically... the bug has been fixed, the latest mikmod packages no > longer obsolete 'tracker'. But because of the way obsoletes work it > still causes problems. There is no automatic way to override a > specific obsolete, you have to disable the calculation of obseletes in > some fashion. > The above is fixed in yum 3.0.2 or above. 3.0.2 isn't out yet, but it will be. -sv From sdl.web at gmail.com Wed Dec 20 09:43:45 2006 From: sdl.web at gmail.com (Leo) Date: Wed, 20 Dec 2006 09:43:45 +0000 Subject: What's going on with `yum install tracker' References: <604aa7910612192109n6e3d9fbajfc00a64e18c4a41f@mail.gmail.com> Message-ID: * Jeff Spaleta (2006-12-19 20:09 -0900) said: ^^^^^^^^^^^^ > On 12/19/06, Leo wrote: >> Hi all, >> >> I suspect there is a bug? Could you look at the output of 'yum install >> track'? > > > The mikmod that shipped with FC6 had an explicit obsolete statement > for tracker. rpm -q --obsoletes -p mikmod-3.1.6-38.1.i386.rpm > tracker My first response is my system is infected with virus. > The mikmod released as an update no longer carries the obsolete > rpm -q --changelog mikmod > * Thu Nov 09 2006 Martin Stransky - 3.1.6-39 > - removed obsoletes on tracker (#214112) > > The workaround is to use: > yum --disablerepo=core install tracker > > or set obsoletes=0 in the yum.conf Or set exclude=mikmod in /etc/yum.repos.d/fedora-core.repo. Thank you for the wonderful explanation. -- Leo (GPG Key: 9283AA3F) From buildsys at redhat.com Wed Dec 20 11:21:25 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 20 Dec 2006 06:21:25 -0500 Subject: rawhide report: 20061220 changes Message-ID: <200612201121.kBKBLPpG000576@hs20-bc2-6.build.redhat.com> Updated Packages: alacarte-0.10.2-2.fc7 --------------------- * Wed Dec 20 2006 Matthias Clasen - 0.10.2-2 - Update to 0.10.2 at-spi-1.7.14-1.fc7 ------------------- * Tue Dec 19 2006 Matthias Clasen - 1.7.14-1 - Update to 1.7.14 atk-1.12.4-1.fc7 ---------------- * Tue Dec 19 2006 Matthias Clasen - 1.12.4-1 - Update to 1.12.4 bug-buddy-1:2.17.3-1.fc7 ------------------------ * Tue Dec 19 2006 Matthias Clasen - 1:2.17.3-1 - Update to 2.17.3 dasher-4.3.3-1.fc7 ------------------ * Wed Dec 20 2006 Matthias Clasen - 4.3.3-1 - Update to 4.3.3 dbus-glib-0.71-4.fc7 -------------------- * Tue Dec 19 2006 John (J5) Palmieri - 0.71-4 - Add dbus-glib-0.70-use-default-threads.patch - Partial fix to #219257 desktop-printing-0.20-1.fc7 --------------------------- * Tue Dec 19 2006 Matthias Clasen 0.20-1 - Update to 0.20 - Drop upstreamed patches e2fsprogs-1.39-7.fc6 -------------------- * Mon Dec 18 2006 Thomas Woerner - 1.39-7.fc6 - make uuid_generate_time generate unique uuids (#218606) enscript-1.6.4-5.fc7 -------------------- * Tue Dec 19 2006 Adam Tkac 1.6.4-5 - fixed long-header patch (#202082) eog-2.17.3-1.fc7 ---------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.3-1 - Update to 2.17.3 epiphany-2.17.4-1.fc7 --------------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.4-1 - Update to 2.17.4 evince-0.7.0-1.fc7 ------------------ * Tue Dec 19 2006 Matthias Clasen - 0.7.0-1 - Update to 0.7.0 evolution-2.9.4-1.fc7 --------------------- * Tue Dec 19 2006 Matthew Barnes - 2.9.4-1.fc7 - Update to 2.9.4 - Bump eds_version to 1.9.4 due to soname changes. - Remove patch for GNOME bug #382431 (fixed upstream). * Fri Dec 15 2006 Matthew Barnes - 2.9.3-5.fc7 - Add patch for GNOME bug #373116 (use GtkColorButton). * Fri Dec 15 2006 Matthew Barnes - 2.9.3-4.fc7 - Disable patch for RH bug #216537, which caused RH bug #219228. evolution-connector-2.9.4-1.fc7 ------------------------------- * Tue Dec 19 2006 Matthew Barnes - 2.9.4-1.fc7 - Update to 2.9.4 - Require evolution-data-server-1.9.4. evolution-data-server-1.9.4-1.fc7 --------------------------------- * Tue Dec 19 2006 Matthew Barnes - 1.9.4-1.fc7 - Update to 1.9.4 - Add patch for GNOME bug #373117 (storing color settings). - Add patch for GNOME bug #387638 (implicit function declaration). gail-1.9.4-1.fc7 ---------------- * Tue Dec 19 2006 Matthias Clasen - 1.9.4-1 - Update to 1.9.4 gdb-6.5-20.fc7 -------------- * Tue Dec 19 2006 Jan Kratochvil - 6.5-20 - Fix bogus 0x0 unwind of the thread's topmost function clone(3) (BZ 216711). - Testcase for readline segfault on excessively long hand-typed lines. * Tue Dec 12 2006 Jan Kratochvil - 6.5-19 - Fix attachment also to a threaded stopped process (BZ 219118). - Cleanup any leftover testsuite processes as it may stuck mock(1) builds. * Sat Nov 25 2006 Jan Kratochvil - 6.5-18 - Fix readline history for input mode commands like `command' (BZ 215816). gedit-1:2.17.2-1.fc7 -------------------- * Wed Dec 20 2006 Matthias Clasen - 1:2.17.2-1 - Update to 2.17.2 glib2-2.12.5-2.fc7 ------------------ * Mon Dec 18 2006 Matthias Clasen - 2.12.5-2 - Fix the configure check for broken poll glibc-2.5.90-14 --------------- * Tue Dec 19 2006 Jakub Jelinek 2.5.90-14 - fix {j,m}rand48{,_r} on 64-bit arches (BZ#3747) - handle power6x AT_PLATFORM (#216970) - fix a race condition in getXXbyYY_r (#219145) - fix tst-pselect testcase gnome-games-1:2.17.4.1-2.fc7 ---------------------------- * Wed Dec 20 2006 Matthias Clasen - 1:2.17.4.1-1 - Update to 2.17.4.1 gnome-icon-theme-2.17.4-1.fc7 ----------------------------- * Wed Dec 20 2006 Matthias Clasen - 2.17.4-1 - Update to 2.17.4 gnome-media-2.17.1-1.fc7 ------------------------ * Wed Dec 20 2006 Matthias Clasen - 2.17.1-1 - Update to 2.17.1 gnome-nettool-2.17.4-1.fc7 -------------------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.4-1 - Update to 2.17.4 gnome-power-manager-2.17.4-1.fc7 -------------------------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.4-1 - Update to 2.17.4 gnome-screensaver-2.17.4-1.fc7 ------------------------------ * Wed Dec 20 2006 Matthias Clasen - 2.17.4-1 - Update to 2.17.4 gnome-speech-0.4.7-1.fc7 ------------------------ * Wed Dec 20 2006 Matthias Clasen - 0.4.7-1 - Update to 0.4.7 - Require pkgconfig in the -devel package gnome-system-monitor-2.17.4.2-1.fc7 ----------------------------------- * Wed Dec 20 2006 Matthias Clasen - 2.17.4.2-1 - Update to 2.17.4.2 gnome-themes-2.17.4-1.fc7 ------------------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.4-1 - Update to 2.17.4 gnome-vfs2-2.17.2-1.fc7 ----------------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 gtkhtml3-3.13.4-1.fc7 --------------------- * Tue Dec 19 2006 Matthew Barnes - 3.13.4-1.fc7 - Update to 3.13.4 kernel-2.6.19-1.2889.fc7 ------------------------ * Tue Dec 19 2006 David Woodhouse - Fix ebus oops - Actually make it possible to include iSeries in the generic PPC64 kernel * Tue Dec 19 2006 David Woodhouse - Include iSeries in the generic PPC64 kernel now that's possible - Fix squashfs - Fix softmac fallout from work_struct changes - Update OF uevent handler patch kexec-tools-1.101-55.fc7 ------------------------ * Fri Dec 15 2006 Neil Horman - 1.101-5.fc7 - Wholesale update of RHEL5 revisions 55-147 * Tue Aug 29 2006 Neil Horman - 1.101-54.fc7 - integrate default elf format patch * Tue Aug 29 2006 Neil Horman - 1.101-53.fc7 - Taking Viveks x86_64 crashdump patch (rcv. via email) mkinitrd-6.0.6-1 ---------------- * Tue Dec 19 2006 Peter Jones - 6.0.6-1 - Fix LABEL handling orca-2.17.4-1.fc7 ----------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.4-1 - Update to orca 2.17.4 policycoreutils-1.33.6-7.fc7 ---------------------------- * Tue Dec 19 2006 Dan Walsh 1.33.6-7 - add exists switch to semanage to tell it not to check for existance of Linux user Resolves: #219421 * Mon Dec 18 2006 Dan Walsh 1.33.6-6 - Fix audit2allow generating reference policy - Fix semanage to manage user roles properly Resolves: #220071 * Fri Dec 08 2006 Dan Walsh 1.33.6-5 - Update po files - Fix newrole to open stdout and stderr rdrw so more will work on MLS machines Resolves: #216920 rhgb-0.16.4-4.fc7 ----------------- * Tue Dec 19 2006 Adam Jackson - 0.16.4-4 - rhgb-0.16.4-wait-for-server-to-exit.patch: Added, wait for the X server to shut down before exiting. rhythmbox-0.9.7-4.fc7 --------------------- * Tue Dec 19 2006 Matthias Clasen - 0.9.7-5 - Update to 0.9.7 vino-2.17.4-1.fc7 ----------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.4-1 - Update to 2.17.4 virt-manager-0.2.6-3.fc7 ------------------------ * Tue Dec 19 2006 Daniel P. Berrange - 0.2.6-3.fc7 - Imported latest translations from Fedora i18n repository (bz 203783) - Use 127.0.0.1 address for connecting to VNC console instead of localhost to avoid some issue with messed up /etc/hosts. - Add selector for sparse or non-sparse file, defaulting to non-sparse. Add appropriate warnings and progress-bar text. (bz 218996) - Disable memory ballooning & CPU hotplug for HVM guests (bz 214432) - Updated memory-setting UI to include a hard upper limit for physical host RAM - Added documentation on the page warning that setting virtual host RAM too high can exhaust the memory of the machine - Handle errors when hostname resolution fails to avoid app exiting (bz 216975) * Thu Dec 07 2006 Jeremy Katz - 0.2.6-2.fc7 - rebuild for python 2.5 * Thu Nov 09 2006 Daniel P. Berrange - 0.2.6-1.fc7 - Imported translations from Fedora i18n repository - Make (most) scrollbar policies automatic - Set busy cursor while creating new VMs - Preference for controlling keygrab policy - Preference for when to automatically open console (bz 211385) - Re-try VNC connection attempt periodically in case VNC daemon hasn't finished starting up - Added activation of URLs for about dialog (bz 210782) - Improved error reporting when connecting to HV (bz 211229) - Add command line args to open specific windows - Don't skip para/full virt wizard step - instead gray out full virt option & tell user why - Change 'physical' to 'logical' when refering to host CPUs - Include hostname in titlebar - Disable wizard sensitivity while creating VM zenity-2.17.2-1.fc7 ------------------- * Tue Dec 19 2006 Matthias Clasen - 2.17.2-1 - Update to 2.17.2 Broken deps for i386 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 planner-eds - 0.14.2-2.fc7.i386 requires libcamel-1.2.so.0 planner-eds - 0.14.2-2.fc7.i386 requires libcamel-provider-1.2.so.8 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.i386 requires python(abi) = 0:2.4 Broken deps for ppc64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) firstboot - 1.4.28-1.fc7.noarch requires system-config-keyboard firstboot - 1.4.28-1.fc7.noarch requires system-config-display planner-eds - 0.14.2-2.fc7.ppc64 requires libcamel-1.2.so.0()(64bit) planner-eds - 0.14.2-2.fc7.ppc64 requires libcamel-provider-1.2.so.8()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree Broken deps for x86_64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) planner-eds - 0.14.2-2.fc7.x86_64 requires libcamel-1.2.so.0()(64bit) planner-eds - 0.14.2-2.fc7.x86_64 requires libcamel-provider-1.2.so.8()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.x86_64 requires python(abi) = 0:2.4 Broken deps for ppc ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 planner-eds - 0.14.2-2.fc7.ppc requires libcamel-1.2.so.0 planner-eds - 0.14.2-2.fc7.ppc requires libcamel-provider-1.2.so.8 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree Broken deps for s390 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 firstboot - 1.4.28-1.fc7.noarch requires system-config-keyboard firstboot - 1.4.28-1.fc7.noarch requires system-config-soundcard firstboot - 1.4.28-1.fc7.noarch requires rhpxl >= 0:0.19 firstboot - 1.4.28-1.fc7.noarch requires system-config-display planner-eds - 0.14.2-2.fc7.s390 requires libcamel-provider-1.2.so.8 planner-eds - 0.14.2-2.fc7.s390 requires libcamel-1.2.so.0 setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) planner-eds - 0.14.2-2.fc7.ia64 requires libcamel-1.2.so.0()(64bit) planner-eds - 0.14.2-2.fc7.ia64 requires libcamel-provider-1.2.so.8()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree xen - 3.0.3-1.ia64 requires python(abi) = 0:2.4 Broken deps for s390x ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) firstboot - 1.4.28-1.fc7.noarch requires rhpxl >= 0:0.19 firstboot - 1.4.28-1.fc7.noarch requires system-config-display firstboot - 1.4.28-1.fc7.noarch requires system-config-keyboard firstboot - 1.4.28-1.fc7.noarch requires system-config-soundcard planner-eds - 0.14.2-2.fc7.s390x requires libcamel-1.2.so.0()(64bit) planner-eds - 0.14.2-2.fc7.s390x requires libcamel-provider-1.2.so.8()(64bit) setroubleshoot - 1.8.10-1.fc7.noarch requires python-elementtree From jeroen.janssen at gmail.com Wed Dec 20 14:55:33 2006 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Wed, 20 Dec 2006 15:55:33 +0100 Subject: firstboot development? Message-ID: Hello, I am looking for information om the firstboot development, but I can not seem to find any specific information. I'm looking for: * the mailinglist where development discussions take place. * the CVS? repository of the latest software. According to "rpm -qi firstboot", the url is http://fedora.redhat.com/projects/config-tools/ , but according to the redhat mailman software, the fedora-config-list mailinglist does not exist (anymore?). Can someone point me in the right direction? Best regards, Jeroen Janssen From clumens at redhat.com Wed Dec 20 14:59:56 2006 From: clumens at redhat.com (Chris Lumens) Date: Wed, 20 Dec 2006 09:59:56 -0500 Subject: firstboot development? In-Reply-To: References: Message-ID: <20061220145956.GK1043@exeter.boston.redhat.com> > I'm looking for: > * the mailinglist where development discussions take place. There's not a firstboot-specific mailing list. It doesn't see a ton of development. This list would be fine for anything you want to say about it. > * the CVS? repository of the latest software. cvs -d :pserver:anonymous at rhlinux.redhat.com:/usr/local/CVS co firstboot > Can someone point me in the right direction? I'm pretty much it. What's up? - Chris From mmcgrath at fedoraproject.org Wed Dec 20 17:20:47 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 20 Dec 2006 11:20:47 -0600 Subject: Unique Identifier Message-ID: <3237e4410612200920o57130c30sfe59a45783862933@mail.gmail.com> Whats the most accepted way to create a unique identifier (key) for a host? Collisions are fine if they are rare. -Mike From skvidal at linux.duke.edu Wed Dec 20 17:26:16 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 20 Dec 2006 12:26:16 -0500 Subject: Unique Identifier In-Reply-To: <3237e4410612200920o57130c30sfe59a45783862933@mail.gmail.com> References: <3237e4410612200920o57130c30sfe59a45783862933@mail.gmail.com> Message-ID: <1166635576.28129.12.camel@cutter> On Wed, 2006-12-20 at 11:20 -0600, Mike McGrath wrote: > Whats the most accepted way to create a unique identifier (key) for a > host? Collisions are fine if they are rare. > What's the UUID that rhn uses to recognize the host? I'm pretty sure that code is open. -sv From nutello at sweetness.com Wed Dec 20 17:20:47 2006 From: nutello at sweetness.com (Rudi Chiarito) Date: Wed, 20 Dec 2006 18:20:47 +0100 Subject: Unique Identifier In-Reply-To: <3237e4410612200920o57130c30sfe59a45783862933@mail.gmail.com> References: <3237e4410612200920o57130c30sfe59a45783862933@mail.gmail.com> Message-ID: <20061220172047.GA14729@plain.rackshack.net> On Wed, Dec 20, 2006 at 11:20:47AM -0600, Mike McGrath wrote: > Whats the most accepted way to create a unique identifier (key) for a > host? Collisions are fine if they are rare. I use a combination of MAC address and the serial number of the first ATA device. It would be cool to have something like this provided by Anaconda. -- Rudi From jeff at ocjtech.us Wed Dec 20 17:57:46 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Wed, 20 Dec 2006 11:57:46 -0600 Subject: Unique Identifier In-Reply-To: <3237e4410612200920o57130c30sfe59a45783862933@mail.gmail.com> References: <3237e4410612200920o57130c30sfe59a45783862933@mail.gmail.com> Message-ID: <1166637467.3531.2.camel@lt21223.campus.dmacc.edu> On Wed, 2006-12-20 at 11:20 -0600, Mike McGrath wrote: > Whats the most accepted way to create a unique identifier (key) for a > host? Collisions are fine if they are rare. What about the uuid package in extras? $ uuid 7c098fe8-9053-11db-a2c8-001560c53ca8 Jeff -------------- 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 katzj at redhat.com Wed Dec 20 18:04:20 2006 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 20 Dec 2006 13:04:20 -0500 Subject: Unique Identifier In-Reply-To: <1166637467.3531.2.camel@lt21223.campus.dmacc.edu> References: <3237e4410612200920o57130c30sfe59a45783862933@mail.gmail.com> <1166637467.3531.2.camel@lt21223.campus.dmacc.edu> Message-ID: <1166637860.10717.27.camel@aglarond.local> On Wed, 2006-12-20 at 11:57 -0600, Jeffrey C. Ollie wrote: > On Wed, 2006-12-20 at 11:20 -0600, Mike McGrath wrote: > > Whats the most accepted way to create a unique identifier (key) for a > > host? Collisions are fine if they are rare. > > What about the uuid package in extras? > > $ uuid > 7c098fe8-9053-11db-a2c8-001560c53ca8 Why not /usr/bin/uuidgen from e2fsprogs? :-) Jeremy From Matt_Domsch at dell.com Wed Dec 20 18:10:03 2006 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 20 Dec 2006 12:10:03 -0600 Subject: Unique Identifier In-Reply-To: <1166637860.10717.27.camel@aglarond.local> References: <3237e4410612200920o57130c30sfe59a45783862933@mail.gmail.com> <1166637467.3531.2.camel@lt21223.campus.dmacc.edu> <1166637860.10717.27.camel@aglarond.local> Message-ID: <20061220181003.GA8511@lists.us.dell.com> On Wed, Dec 20, 2006 at 01:04:20PM -0500, Jeremy Katz wrote: > On Wed, 2006-12-20 at 11:57 -0600, Jeffrey C. Ollie wrote: > > On Wed, 2006-12-20 at 11:20 -0600, Mike McGrath wrote: > > > Whats the most accepted way to create a unique identifier (key) for a > > > host? Collisions are fine if they are rare. > > > > What about the uuid package in extras? > > > > $ uuid > > 7c098fe8-9053-11db-a2c8-001560c53ca8 > > Why not /usr/bin/uuidgen from e2fsprogs? :-) +1 -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com From seg at haxxed.com Wed Dec 20 18:17:43 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 20 Dec 2006 12:17:43 -0600 Subject: Unique Identifier In-Reply-To: <1166637860.10717.27.camel@aglarond.local> References: <3237e4410612200920o57130c30sfe59a45783862933@mail.gmail.com> <1166637467.3531.2.camel@lt21223.campus.dmacc.edu> <1166637860.10717.27.camel@aglarond.local> Message-ID: <1166638663.5608.65.camel@max.booze> On Wed, 2006-12-20 at 13:04 -0500, Jeremy Katz wrote: > On Wed, 2006-12-20 at 11:57 -0600, Jeffrey C. Ollie wrote: > > On Wed, 2006-12-20 at 11:20 -0600, Mike McGrath wrote: > > > Whats the most accepted way to create a unique identifier (key) for a > > > host? Collisions are fine if they are rare. > > > > What about the uuid package in extras? > > > > $ uuid > > 7c098fe8-9053-11db-a2c8-001560c53ca8 > > Why not /usr/bin/uuidgen from e2fsprogs? :-) $ head -c 33 /dev/random |base64 lOmmWgyYE+EBZpsxP+Ayxt/JLL2JgdghfOiTWUEVBaDK 264 bits of random. -------------- 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 mmcgrath at fedoraproject.org Wed Dec 20 18:26:51 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 20 Dec 2006 12:26:51 -0600 Subject: Unique Identifier In-Reply-To: <1166637860.10717.27.camel@aglarond.local> References: <3237e4410612200920o57130c30sfe59a45783862933@mail.gmail.com> <1166637467.3531.2.camel@lt21223.campus.dmacc.edu> <1166637860.10717.27.camel@aglarond.local> Message-ID: <3237e4410612201026x1d34048cgffab7c5ebdb948d9@mail.gmail.com> On 12/20/06, Jeremy Katz wrote: > On Wed, 2006-12-20 at 11:57 -0600, Jeffrey C. Ollie wrote: > > On Wed, 2006-12-20 at 11:20 -0600, Mike McGrath wrote: > > > Whats the most accepted way to create a unique identifier (key) for a > > > host? Collisions are fine if they are rare. > > > > What about the uuid package in extras? > > > > $ uuid > > 7c098fe8-9053-11db-a2c8-001560c53ca8 > > Why not /usr/bin/uuidgen from e2fsprogs? :-) > > Jeremy > Holy moly, thats amazing :-D I'll have to get into the workings and make sure its not basing anything off of hostname or ip or something sensitive that could be reverse engineered. -Mike From al at authentidate.de Wed Dec 20 18:36:00 2006 From: al at authentidate.de (Andreas Laumann) Date: Wed, 20 Dec 2006 19:36:00 +0100 Subject: Unique Identifier In-Reply-To: <3237e4410612201026x1d34048cgffab7c5ebdb948d9@mail.gmail.com> References: <3237e4410612200920o57130c30sfe59a45783862933@mail.gmail.com> <1166637467.3531.2.camel@lt21223.campus.dmacc.edu> <1166637860.10717.27.camel@aglarond.local> <3237e4410612201026x1d34048cgffab7c5ebdb948d9@mail.gmail.com> Message-ID: <1166639761.5302.88.camel@justine.inexnet.de> Am Mittwoch, den 20.12.2006, 12:26 -0600 schrieb Mike McGrath: > On 12/20/06, Jeremy Katz wrote: > > On Wed, 2006-12-20 at 11:57 -0600, Jeffrey C. Ollie wrote: > > > On Wed, 2006-12-20 at 11:20 -0600, Mike McGrath wrote: > > > > Whats the most accepted way to create a unique identifier (key) for a > > > > host? Collisions are fine if they are rare. > > > > > > What about the uuid package in extras? > > > > > > $ uuid > > > 7c098fe8-9053-11db-a2c8-001560c53ca8 > > > > Why not /usr/bin/uuidgen from e2fsprogs? :-) > > > > Jeremy > > > > Holy moly, thats amazing :-D I'll have to get into the workings and > make sure its not basing anything off of hostname or ip or something > sensitive that could be reverse engineered. Why not using the kernel random proc interface for that ? cat /proc/sys/kernel/random/uuid Andreas > > -Mike -- "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 tbrinkman at sbcglobal.net Wed Dec 20 18:15:43 2006 From: tbrinkman at sbcglobal.net (Tom Brinkman) Date: Wed, 20 Dec 2006 12:15:43 -0600 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <200612172148.10336.tbrinkman@sbcglobal.net> References: <20061218021508.GC8353@redhat.com> <200612172148.10336.tbrinkman@sbcglobal.net> Message-ID: <200612201215.44049.tbrinkman@sbcglobal.net> On Sunday 17 December 2006 9:48 pm, Tom Brinkman wrote: > On Sunday 17 December 2006 8:15 pm, Dave Jones wrote: > > On Sat, Dec 16, 2006 at 11:52:30AM -0600, Tom Brinkman wrote: > > > > Probably the changes to use libata PATA drivers instead of > > > > the old crusty IDE drivers at a guess. The most obvious > > > > change being the move from /dev/hd* to /dev/sd*. If > > > > you're using mount-by-label, that should 'just work' > > > > though, so perhaps either the driver is broken, or it > > > > needs a workaround in mkinitrd like the other PATA drivers > > > > to wait for the disk nodes to appear in /dev before we go > > > > looking for volume groups. > > > > > > It panics, unable to mount on i386 without any LVM too. > > > Asus A7V600, kt600 chipset, both pata an sata drives. My / > > > is on hd0,0 an IDE pata drive. The sata (all storage) > > > appears to be found before the kernel panics on IDE. All > > > drives (2 pata, 1 sata) are ext3. > > > > Hmm, I just managed to reproduce this on a similar box. > > Rerunning mkinitrd wasn't the answer though. The problem was > > that there were a ton of SELinux denials. > > > > Can you try.. > > > > setenforce 0 > > mkinitrd /boot/initrd-2.6.19-1.2877.fc7.img 2.6.19-1.2877.fc7 > > > > Dave > > Thanks for your interest, but no go > df for rawhide is, > Filesystem Size Used Avail Use% Mounted on > /dev/hdb1 9.9G 4.4G 5.1G 47% / > /dev/hda1 92M 50M 37M 58% /boot > tmpfs 506M 0 506M 0% /dev/shm > /dev/hdb2 27G 5.7G 20G 23% /home > /dev/hda8 41G 25G 14G 64% /stor2 > /dev/sda1 151G 119G 25G 84% /stor4 2889 Boots! after todays (12/20) updates, includin mkinitrd. Thanks Dave et al. $ uname -r 2.6.19-1.2889.fc7 $ df Filesystem Size Used Avail Use% Mounted on /dev/sdb1 9.9G 4.5G 5.0G 48% / /dev/sda1 92M 56M 32M 65% /boot tmpfs 502M 0 502M 0% /dev/shm /dev/sdb2 27G 5.7G 20G 23% /home /dev/sda8 41G 25G 14G 65% /stor2 /dev/sdc1 151G 119G 25G 84% /stor4 BTW, FC6 (2860) also still boots. ~ $ df Filesystem Size Used Avail Use% Mounted on /dev/hda6 9.7G 4.7G 4.6G 51% / /dev/hda1 92M 56M 32M 65% /boot tmpfs 506M 0 506M 0% /dev/shm /dev/hda7 24G 8.3G 14G 38% /home /dev/hda8 41G 25G 14G 65% /stor2 /dev/sda1 151G 119G 25G 84% /stor4 -- Tom Brinkman Corpus Christi, Texas From fedora at camperquake.de Wed Dec 20 20:48:12 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 20 Dec 2006 21:48:12 +0100 Subject: Unique Identifier In-Reply-To: <3237e4410612200920o57130c30sfe59a45783862933@mail.gmail.com> References: <3237e4410612200920o57130c30sfe59a45783862933@mail.gmail.com> Message-ID: <20061220214812.03fb38ad@nausicaa.camperquake.de> Hi. "Mike McGrath" wrote: > Whats the most accepted way to create a unique identifier (key) for a > host? Collisions are fine if they are rare. Do you need unique or unique and reproducable? -- Don't anthropomorphize computers. They don't like it. From mmcgrath at fedoraproject.org Wed Dec 20 20:52:20 2006 From: mmcgrath at fedoraproject.org (Mike McGrath) Date: Wed, 20 Dec 2006 14:52:20 -0600 Subject: Unique Identifier In-Reply-To: <20061220214812.03fb38ad@nausicaa.camperquake.de> References: <3237e4410612200920o57130c30sfe59a45783862933@mail.gmail.com> <20061220214812.03fb38ad@nausicaa.camperquake.de> Message-ID: <3237e4410612201252l55ea45ebn2123a408a7355d6d@mail.gmail.com> On 12/20/06, Ralf Ertzinger wrote: > Hi. > > "Mike McGrath" wrote: > > > Whats the most accepted way to create a unique identifier (key) for a > > host? Collisions are fine if they are rare. > > Do you need unique or unique and reproducable? > For now I think unique and storable will do ( > /etc/sysconfig/somekey) would work fine. -Mike From clydekunkel7734 at cox.net Thu Dec 21 03:26:52 2006 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Wed, 20 Dec 2006 22:26:52 -0500 Subject: Warning: kernel-2.6.19-1.2877.fc7 unbootable on Itanium systems (IA-64 architecture) In-Reply-To: <200612201215.44049.tbrinkman@sbcglobal.net> References: <20061218021508.GC8353@redhat.com> <200612172148.10336.tbrinkman@sbcglobal.net> <200612201215.44049.tbrinkman@sbcglobal.net> Message-ID: <4589FEFC.7070204@cox.net> Tom Brinkman wrote: > > 2889 Boots! after todays (12/20) updates, includin mkinitrd. > Thanks Dave et al. > Whoa, Nellie....not so fast. Software raid still broken, so fc7 kernels still not booting for us software raid fans. Still having to boot the older fc6 kernels. -- Regards, Old Fart (my reply-to address is "munged" to defeat spambots) From seandarcy2 at gmail.com Thu Dec 21 03:47:25 2006 From: seandarcy2 at gmail.com (sean) Date: Wed, 20 Dec 2006 22:47:25 -0500 Subject: why do new kernels insist on uninstalling old? Message-ID: Using yum I have kernels install only: installonlypkgs=kernel yet with the new 2.6.19 kernels, yum insist on uninstalling the old kernels. Removing: kernel x86_64 2.6.19-1.2885.fc7 installed 60 M Why? Can I fix this? I'd really like to keep my old kernels, until I'm satisfied the new ones work. sean From skvidal at linux.duke.edu Thu Dec 21 03:50:19 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 20 Dec 2006 22:50:19 -0500 Subject: why do new kernels insist on uninstalling old? In-Reply-To: References: Message-ID: <1166673019.32180.2.camel@cutter> On Wed, 2006-12-20 at 22:47 -0500, sean wrote: > Using yum I have kernels install only: > > installonlypkgs=kernel > > yet with the new 2.6.19 kernels, yum insist on uninstalling > the old kernels. > > Removing: > kernel x86_64 2.6.19-1.2885.fc7 > installed 60 M > > Why? > > Can I fix this? > > I'd really like to keep my old kernels, until I'm satisfied > the new ones work. > Do you see 'installonlyn' plugin loading when you start up yum? That is the plugin which removes kernels of a certain age. You can disable the plugin if you'd like. Take a look at /etc/yum/pluginconf.d/ -sv From buildsys at redhat.com Thu Dec 21 11:36:06 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 21 Dec 2006 06:36:06 -0500 Subject: rawhide report: 20061221 changes Message-ID: <200612211136.kBLBa6tM007013@hs20-bc2-6.build.redhat.com> Updated Packages: evolution-2.9.4-2.fc7 --------------------- * Wed Dec 20 2006 Matthew Barnes - 2.9.4-2.fc7 - Revise patch for RH bug #202751 (printing of indic languages). * Tue Dec 19 2006 Matthew Barnes - 2.9.4-1.fc7 - Update to 2.9.4 - Bump eds_version to 1.9.4 due to soname changes. - Remove patch for GNOME bug #382431 (fixed upstream). * Fri Dec 15 2006 Matthew Barnes - 2.9.3-5.fc7 - Add patch for GNOME bug #373116 (use GtkColorButton). filesystem-2.4.1-1 ------------------ * Wed Dec 20 2006 Phil Knirsch - 2.4.1-1 - Dropped the obsolete directories /usr/lib{,64}/gcc-lib (#220235) firstboot-1.4.28-2.fc7 ---------------------- * Wed Dec 20 2006 Chris Lumens 1.4.28-2 - Revert spec file changes for s390, s390x, and ppc64 for now. gcc-4.1.1-48 ------------ * Wed Dec 20 2006 Jakub Jelinek 4.1.1-48 - update from gcc-4_1-branch (-r119833:120062) - PRs libstdc++/11953, target/24036 - fix ia64 EH region boundaries where last br.call in the region is not at the end of a bundle (#219596, PR target/30230) - fix DI resp. TImode __sync_*_compare_and_swap on i?86 resp. x86_64 (Kazu Hirata, #220258, PR target/27266) - fix asm vs. nested functions or OpenMP (#220250, PRs middle-end/30262, middle-end/30263) - fix handling of complex shared OpenMP vars (Andrew Pinski, PR middle-end/30143) glib2-2.12.6-1.fc7 ------------------ * Wed Dec 20 2006 Matthias Clasen - 2.12.6-1 - Update to 2.12.6 gtk-doc-1.7-2.fc7 ----------------- * Wed Dec 20 2006 Matthias Clasen - 1.7-2 - Own the /usr/share/gtk-doc/html directory (#220230) htdig-3:3.2.0b6-8.fc7 --------------------- * Wed Dec 20 2006 Adam Tkac 3:3.2.0b6-8.fc7 - fixed htfuzzy's sigfaults (#130528) kernel-2.6.19-1.2890.fc7 ------------------------ * Wed Dec 20 2006 David Woodhouse - Fix BE OHCI support -- write only BE not BE and _then_ LE. Doh. libvirt-0.1.10-1.fc7 -------------------- * Wed Dec 20 2006 Daniel Veillard 0.1.10-1.fc7 - support for inactive Xen domains - improved support for Xen display and vnc - a few bug fixes - localization updates logwatch-7.3.1-9.fc7 -------------------- * Wed Dec 20 2006 Ivana Varekova 7.3.1-9 - add cron, pam_unix, audit, init service patches * Wed Dec 20 2006 Ivana Varekova 7.3.1-8 - add dovecot, amavis and init patch - cleanup spec file opal-2.2.3-4.fc7 ---------------- * Wed Dec 20 2006 Daniel Veillard - 2.2.3-4 - applied patch from upstream to fix RFC2833 DTMF duration problem - Resolves: rhbz#220333 planner-0.14.2-3.fc7 -------------------- * Wed Dec 20 2006 Caolan McNamara - 0.14.2-3.fc7 - rebuild for new evolution-data-server policycoreutils-1.33.6-8.fc7 ---------------------------- * Wed Dec 20 2006 Dan Walsh 1.33.6-8 - Remove hard coding of python2.4 from Makefiles setroubleshoot-1.8.12-1.fc7 --------------------------- * Wed Dec 20 2006 John Dennis - 1.8.12-1 - remove obsolte requires for python element tree * Mon Dec 18 2006 John Dennis - 1.8.11-1 - Resolves: #216575, more translations - Replace delete and expunge menu labels with something more intuitive - add ability for browser to be restarted with identical window position and state - add pkg version and protocol version to logon handshake, test for compatibility between clint and server, prompt for restart - add non-modal restart dialog - add dialog to display traceback if sealert faults with an uncaught exception, try to limit invisible errors - fix return args on rpc method - add instance id to server tetex-3.0-34.fc7 ---------------- * Wed Dec 20 2006 Jindrich Novy 3.0-34 - don't inherit incorrect permissions for ls-R from parent directory while doing texhash (#220239) * Sun Oct 08 2006 Jindrich Novy 3.0-33 - rebuild Broken deps for i386 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 xen - 3.0.3-1.i386 requires python(abi) = 0:2.4 Broken deps for ppc64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) Broken deps for x86_64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) xen - 3.0.3-1.x86_64 requires python(abi) = 0:2.4 Broken deps for s390 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ppc ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 Broken deps for ia64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) xen - 3.0.3-1.ia64 requires python(abi) = 0:2.4 Broken deps for s390x ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) From skadz1 at gmail.com Thu Dec 21 14:56:58 2006 From: skadz1 at gmail.com (Ryan Skadberg) Date: Thu, 21 Dec 2006 09:56:58 -0500 Subject: why do new kernels insist on uninstalling old? In-Reply-To: References: Message-ID: <8719b8230612210656t1f49cb6ay894a6b532b2bd2e6@mail.gmail.com> Just edit: /etc/yum/pluginconf.d/installonlyn.conf And change the tokeep number to the number of kernels you want to keep. Skadz On 12/20/06, sean wrote: > Using yum I have kernels install only: > > installonlypkgs=kernel > > yet with the new 2.6.19 kernels, yum insist on uninstalling > the old kernels. > > Removing: > kernel x86_64 2.6.19-1.2885.fc7 > installed 60 M > > Why? > > Can I fix this? > > I'd really like to keep my old kernels, until I'm satisfied > the new ones work. > > sean > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From conke.hu at gmail.com Thu Dec 21 15:34:10 2006 From: conke.hu at gmail.com (Conke Hu) Date: Thu, 21 Dec 2006 23:34:10 +0800 Subject: [BUG] FC5/FC6 does not support ATI SB600 SATA Message-ID: <5767b9100612210734udfb2b21ua7da35f2628810a8@mail.gmail.com> ATI/AMD SB600 SATA controller supports 4 modes: legacy IDE native IDE AHCI RAID The ahci driver in FC6 tries to claim all 4 modes of SB600 SATA, but fails in legacy IDE mode. and FC5 does not support any mode at all. Now the root cause is found and patch created. My question is, is it still possible to merge the patch to FC5/FC6 kernel (since the final release comes out)? Looking forward to any reply! Thanks! Conke From enrico.scholz at informatik.tu-chemnitz.de Thu Dec 21 15:43:27 2006 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Thu, 21 Dec 2006 16:43:27 +0100 Subject: [DEP-BLOAT] 'bind' requires 'perl' Message-ID: <87odpxw8yo.fsf@kosh.bigo.ensc.de> Hello, the 'bind' package has a dependency on 'perl'. This huge dependency is introduced by a single '/usr/sbin/namedGetForwarders' script which is not needed for most setups. Because none of bind's base-dependencies requires 'perl' and 'namedGetForwarders' is not part of bind's core functionality this dependency must vanish. Possible solutions: * move this stuff into an own subpackage (e.g. -dbus-tools) * rewrite namedGetForwarders in a programming language or in shell [Bug #176100] Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From drago01 at gmail.com Thu Dec 21 15:56:33 2006 From: drago01 at gmail.com (dragoran) Date: Thu, 21 Dec 2006 16:56:33 +0100 Subject: [BUG] FC5/FC6 does not support ATI SB600 SATA In-Reply-To: <5767b9100612210734udfb2b21ua7da35f2628810a8@mail.gmail.com> References: <5767b9100612210734udfb2b21ua7da35f2628810a8@mail.gmail.com> Message-ID: <458AAEB1.4030104@gmail.com> Conke Hu wrote: > ATI/AMD SB600 SATA controller supports 4 modes: > legacy IDE > native IDE > AHCI > RAID > The ahci driver in FC6 tries to claim all 4 modes of SB600 SATA, but > fails in legacy IDE mode. and FC5 does not support any mode at all. > > Now the root cause is found and patch created. My question is, is it > still possible to merge the patch to FC5/FC6 kernel (since the final > release comes out)? > > Looking forward to any reply! Thanks! > > Conke > it should be no problem when 2.6.19.x is pushed to updates (which will happen when xen works again; thats whats dave said last time) From buc at odusz.so-cdu.ru Thu Dec 21 15:58:16 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 21 Dec 2006 18:58:16 +0300 Subject: [DEP-BLOAT] 'bind' requires 'perl' In-Reply-To: <87odpxw8yo.fsf@kosh.bigo.ensc.de> References: <87odpxw8yo.fsf@kosh.bigo.ensc.de> Message-ID: <458AAF18.1070205@odu.neva.ru> Enrico Scholz wrote: >Hello, > >the 'bind' package has a dependency on 'perl'. This huge dependency is >introduced by a single '/usr/sbin/namedGetForwarders' script which is >not needed for most setups. Because none of bind's base-dependencies >requires 'perl' and 'namedGetForwarders' is not part of bind's core >functionality this dependency must vanish. > >Possible solutions: > >* move this stuff into an own subpackage (e.g. -dbus-tools) >* rewrite namedGetForwarders in a programming language or in shell > > or in awk ... Dmitry Butskoy From kevin.kofler at chello.at Thu Dec 21 15:59:06 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 21 Dec 2006 15:59:06 +0000 (UTC) Subject: [BUG] FC5/FC6 does not support ATI SB600 SATA References: <5767b9100612210734udfb2b21ua7da35f2628810a8@mail.gmail.com> Message-ID: Conke Hu gmail.com> writes: > Now the root cause is found and patch created. My question is, is it > still possible to merge the patch to FC5/FC6 kernel (since the final > release comes out)? Yes. This is not Debian stable. ;-) However (in case you or whoever wrote the patch didn't do that yet), you are supposed to send the patch upstream first, and once it gets accepted upstream, you can file a bug requesting a backport. In the particular case of the kernel, however, the easiest way to get your patch in is probably to ask for inclusion in the upstream stable branches (currently 2.6.18.x and 2.6.19.x), so it will get into Fedora as soon as Dave Jones pulls a new upstream release from that branch (and he does regularly - Fedora even gets updates like 2.6.18->2.6.19, however in this case 2.6.19 is apparently pretty disruptive, so it's still on 2.6.18.x for now). Kevin Kofler From conke.hu at gmail.com Thu Dec 21 16:07:02 2006 From: conke.hu at gmail.com (Conke Hu) Date: Fri, 22 Dec 2006 00:07:02 +0800 Subject: [BUG] FC5/FC6 does not support ATI SB600 SATA In-Reply-To: <458AAEB1.4030104@gmail.com> References: <5767b9100612210734udfb2b21ua7da35f2628810a8@mail.gmail.com> <458AAEB1.4030104@gmail.com> Message-ID: <5767b9100612210807v148e4b1ek6053fc7c6d8bf03@mail.gmail.com> Hi dragoran, On 12/21/06, dragoran wrote: > Conke Hu wrote: > > ATI/AMD SB600 SATA controller supports 4 modes: > > legacy IDE > > native IDE > > AHCI > > RAID > > The ahci driver in FC6 tries to claim all 4 modes of SB600 SATA, but > > fails in legacy IDE mode. and FC5 does not support any mode at all. > > > > Now the root cause is found and patch created. My question is, is it > > still possible to merge the patch to FC5/FC6 kernel (since the final > > release comes out)? > > > > Looking forward to any reply! Thanks! > > > > Conke > > > it should be no problem when 2.6.19.x is pushed to updates why? which patch have you merged to FC6 kernel? is it similar with the following (which i've sent to kernel org): ----------------------------------------patch----------------------------------------------- diff -puN drivers/ide/pci/atiixp.c~via-sb600-sata-quirk drivers/ide/pci/atiixp.c --- a/drivers/ide/pci/atiixp.c~via-sb600-sata-quirk +++ a/drivers/ide/pci/atiixp.c @@ -368,7 +368,6 @@ static struct pci_device_id atiixp_pci_t { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP300_IDE, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP400_IDE, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP600_IDE, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0}, - { PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP600_SATA, PCI_ANY_ID, PCI_ANY_ID, (PCI_CLASS_STORAGE_IDE<<8)|0x8a, 0xffff05, 1}, { 0, }, }; MODULE_DEVICE_TABLE(pci, atiixp_pci_tbl); diff -puN drivers/pci/quirks.c~via-sb600-sata-quirk drivers/pci/quirks.c --- a/drivers/pci/quirks.c~via-sb600-sata-quirk +++ a/drivers/pci/quirks.c @@ -850,6 +850,23 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_IN DECLARE_PCI_FIXUP_RESUME(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82454NX, quirk_disable_pxb ); +static void __devinit quirk_sb600_sata(struct pci_dev *pdev) +{ + /* set sb600 sata to ahci mode */ + if ((pdev->class >> 8) == PCI_CLASS_STORAGE_IDE) { + u8 tmp; + + pci_read_config_byte(pdev, 0x40, &tmp); + pci_write_config_byte(pdev, 0x40, tmp|1); + pci_write_config_byte(pdev, 0x9, 1); + pci_write_config_byte(pdev, 0xa, 6); + pci_write_config_byte(pdev, 0x40, tmp); + + pdev->class = 0x010601; + } +} +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP600_SATA, quirk_sb600_sata); + /* * Serverworks CSB5 IDE does not fully support native mode */ From stransky at redhat.com Thu Dec 21 16:36:10 2006 From: stransky at redhat.com (Martin Stransky) Date: Thu, 21 Dec 2006 17:36:10 +0100 Subject: [DEP-BLOAT] 'bind' requires 'perl' In-Reply-To: <87odpxw8yo.fsf@kosh.bigo.ensc.de> References: <87odpxw8yo.fsf@kosh.bigo.ensc.de> Message-ID: <458AB7FA.9050000@redhat.com> > * rewrite namedGetForwarders in a programming language or in shell IMHO this is the best one. If you rewrite it to any other language I'll use it. Martin Enrico Scholz wrote: > Hello, > > the 'bind' package has a dependency on 'perl'. This huge dependency is > introduced by a single '/usr/sbin/namedGetForwarders' script which is > not needed for most setups. Because none of bind's base-dependencies > requires 'perl' and 'namedGetForwarders' is not part of bind's core > functionality this dependency must vanish. > > Possible solutions: > > * move this stuff into an own subpackage (e.g. -dbus-tools) > * rewrite namedGetForwarders in a programming language or in shell > > [Bug #176100] > > > > > Enrico > From conke.hu at gmail.com Thu Dec 21 17:20:40 2006 From: conke.hu at gmail.com (Conke Hu) Date: Fri, 22 Dec 2006 01:20:40 +0800 Subject: [BUG] FC5/FC6 does not support ATI SB600 SATA In-Reply-To: References: <5767b9100612210734udfb2b21ua7da35f2628810a8@mail.gmail.com> Message-ID: <5767b9100612210920i66ce2246p26626dca17dea4a6@mail.gmail.com> On 12/21/06, Kevin Kofler wrote: > Conke Hu gmail.com> writes: > > Now the root cause is found and patch created. My question is, is it > > still possible to merge the patch to FC5/FC6 kernel (since the final > > release comes out)? > > Yes. This is not Debian stable. ;-) > > However (in case you or whoever wrote the patch didn't do that yet), you are > supposed to send the patch upstream first, and once it gets accepted upstream, > you can file a bug requesting a backport. In the particular case of the kernel, > however, the easiest way to get your patch in is probably to ask for inclusion > in the upstream stable branches (currently 2.6.18.x and 2.6.19.x), so it will > get into Fedora as soon as Dave Jones pulls a new upstream release from that > branch (and he does regularly - Fedora even gets updates like 2.6.18->2.6.19, > however in this case 2.6.19 is apparently pretty disruptive, so it's still on > 2.6.18.x for now). > > Kevin Kofler Thank you so much, Kevin! :) I will file an EPR on this issue tomorrow morring. BTW, the patch that I've upstreamed now is accepted by kernel org and can be git from git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/pci-2.6.git Patch subject: PCI: ATI sb600 sata quirk From conke.hu at gmail.com Fri Dec 22 02:53:05 2006 From: conke.hu at gmail.com (Conke Hu) Date: Fri, 22 Dec 2006 10:53:05 +0800 Subject: A general question about FC iso update In-Reply-To: References: <5767b9100612210734udfb2b21ua7da35f2628810a8@mail.gmail.com> Message-ID: <1166755985.28190.9.camel@localhost.localdomain> Hi Kevin and all, I saw many files in the directory http://download.fedora.redhat.com/pub/fedora/linux/core/updates/6, will they be merged to new FC6 ISO? Will the FC6 maintainers update FC6 iso? best regards, conke From david at lovesunix.net Thu Dec 21 19:03:41 2006 From: david at lovesunix.net (David Nielsen) Date: Thu, 21 Dec 2006 20:03:41 +0100 Subject: A general question about FC iso update In-Reply-To: <1166755985.28190.9.camel@localhost.localdomain> References: <5767b9100612210734udfb2b21ua7da35f2628810a8@mail.gmail.com> <1166755985.28190.9.camel@localhost.localdomain> Message-ID: <1166727821.23336.0.camel@dawkins> fre, 22 12 2006 kl. 10:53 +0800, skrev Conke Hu: > Hi Kevin and all, > I saw many files in the directory > http://download.fedora.redhat.com/pub/fedora/linux/core/updates/6, will > they be merged to new FC6 ISO? Will the FC6 maintainers update FC6 iso? I believe Fedora Unity provides respun ISOs - David -- "Ridicule s the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From tibbs at math.uh.edu Thu Dec 21 19:59:46 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 21 Dec 2006 13:59:46 -0600 Subject: [DEP-BLOAT] 'bind' requires 'perl' In-Reply-To: <458AB7FA.9050000@redhat.com> References: <87odpxw8yo.fsf@kosh.bigo.ensc.de> <458AB7FA.9050000@redhat.com> Message-ID: >>>>> "MS" == Martin Stransky writes: >> * rewrite namedGetForwarders in a programming language or in shell MS> IMHO this is the best one. If you rewrite it to any other language MS> I'll use it. Ruby? Erlang? Perl-hate can go too far, you know. Still, I like Perl write a lot of it, but the Perl in that file gives me hives. It's as if someone was trying to make Perl look even worse than it actually is. - J< From kevin.kofler at chello.at Thu Dec 21 20:20:28 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 21 Dec 2006 20:20:28 +0000 (UTC) Subject: A general question about FC iso update References: <5767b9100612210734udfb2b21ua7da35f2628810a8@mail.gmail.com> <1166755985.28190.9.camel@localhost.localdomain> Message-ID: Conke Hu gmail.com> writes: > I saw many files in the directory > http://download.fedora.redhat.com/pub/fedora/linux/core/updates/6, will > they be merged to new FC6 ISO? Will the FC6 maintainers update FC6 iso? No. As David Nielsen said, the FedoraUnity project tries to produce respins, but they're not officially part of Fedora and their respins are not official Fedora ISOs. They do however fill that niche. Kevin Kofler From lamont at gurulabs.com Thu Dec 21 21:19:28 2006 From: lamont at gurulabs.com (Lamont Peterson) Date: Thu, 21 Dec 2006 14:19:28 -0700 Subject: [DEP-BLOAT] 'bind' requires 'perl' In-Reply-To: <87odpxw8yo.fsf@kosh.bigo.ensc.de> References: <87odpxw8yo.fsf@kosh.bigo.ensc.de> Message-ID: <200612211419.28417.lamont@gurulabs.com> On Thursday 21 December 2006 08:43am, Enrico Scholz wrote: > Hello, > > the 'bind' package has a dependency on 'perl'. bind 8 & 9 had one perl script (named-bootconf), but bind 9.2 changed that (upstream) to a shell script (/usr/sbin/named-bootconf) in order to eliminate this dependency. Did the bind package maintainer(s) ever remove the dependency from the SPEC file for 9.2? Though, as you note here, there's been another perl script added recently: > This huge dependency is > introduced by a single '/usr/sbin/namedGetForwarders' script which is > not needed for most setups. Because none of bind's base-dependencies > requires 'perl' and 'namedGetForwarders' is not part of bind's core > functionality this dependency must vanish. > > Possible solutions: > > * move this stuff into an own subpackage (e.g. -dbus-tools) > * rewrite namedGetForwarders in a programming language or in shell IMHO, the second one is better. It looks like it would be very easy to rewrite in C. I'm not sure about a shell script, but that might be the best choice given the architecture of bind. > [Bug #176100] -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From clydekunkel7734 at cox.net Thu Dec 21 22:57:31 2006 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Thu, 21 Dec 2006 17:57:31 -0500 Subject: New device drivers don't see beyond 15 partitions in fc7 Message-ID: <458B115B.7060606@cox.net> Hello, With the change from traditional /dev/hd* type device nodes to /dev/sd* type nodes, I see that the highest partition number that can be used is 15. Will this change so that higher numbers will be available? I do have a system that has a drive with almost 30 small partitions used in a research effort and the number of partitions has not been an issue thru fc6. -- Regards, Old Fart (my reply-to address is "munged" to defeat spambots) From davej at redhat.com Fri Dec 22 05:31:21 2006 From: davej at redhat.com (Dave Jones) Date: Fri, 22 Dec 2006 00:31:21 -0500 Subject: New device drivers don't see beyond 15 partitions in fc7 In-Reply-To: <458B115B.7060606@cox.net> References: <458B115B.7060606@cox.net> Message-ID: <20061222053121.GA22833@redhat.com> On Thu, Dec 21, 2006 at 05:57:31PM -0500, Clyde E. Kunkel wrote: > Hello, > > With the change from traditional /dev/hd* type device nodes to /dev/sd* > type nodes, I see that the highest partition number that can be used is > 15. Will this change so that higher numbers will be available? I do > have a system that has a drive with almost 30 small partitions used in a > research effort and the number of partitions has not been an issue thru fc6. afaik, The only way to achieve > 15 "partitions" per disk with /dev/sd* is to use device mapper. I'm not sure the upper limit of logical volumes per PV, but I'm fairly sure it's higher than 15. Dave -- http://www.codemonkey.org.uk From gilboad at gmail.com Fri Dec 22 06:48:46 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Fri, 22 Dec 2006 08:48:46 +0200 Subject: New device drivers don't see beyond 15 partitions in fc7 In-Reply-To: <458B115B.7060606@cox.net> References: <458B115B.7060606@cox.net> Message-ID: <1166770126.27377.1.camel@gilboa-home-dev.localdomain> On Thu, 2006-12-21 at 17:57 -0500, Clyde E. Kunkel wrote: > Hello, > > With the change from traditional /dev/hd* type device nodes to /dev/sd* > type nodes, I see that the highest partition number that can be used is > 15. Will this change so that higher numbers will be available? I do > have a system that has a drive with almost 30 small partitions used in a > research effort and the number of partitions has not been an issue thru fc6. > > -- Use LVM. Trust me. You won't be sorry. - Gilboa From j.w.r.degoede at hhs.nl Fri Dec 22 07:32:53 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 22 Dec 2006 08:32:53 +0100 Subject: New device drivers don't see beyond 15 partitions in fc7 In-Reply-To: <1166770126.27377.1.camel@gilboa-home-dev.localdomain> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> Message-ID: <458B8A25.6020409@hhs.nl> Gilboa Davara wrote: > On Thu, 2006-12-21 at 17:57 -0500, Clyde E. Kunkel wrote: >> Hello, >> >> With the change from traditional /dev/hd* type device nodes to /dev/sd* >> type nodes, I see that the highest partition number that can be used is >> 15. Will this change so that higher numbers will be available? I do >> have a system that has a drive with almost 30 small partitions used in a >> research effort and the number of partitions has not been an issue thru fc6. >> >> -- > > Use LVM. > Trust me. > You won't be sorry. > Use lvm is not the answer, if this was possible before the system should upgrade to FC-7 flawlessly, if /dev/hdx accomodated more then 15 partitions, then so should the new /dev/sdx when it becomes the new device for this disk. Regards, Hans From rob at choralone.org Fri Dec 22 08:28:51 2006 From: rob at choralone.org (Rob Andrews) Date: Fri, 22 Dec 2006 08:28:51 +0000 Subject: New device drivers don't see beyond 15 partitions in fc7 In-Reply-To: <458B115B.7060606@cox.net> References: <458B115B.7060606@cox.net> Message-ID: <20061222082851.GC6739@aphasia.badger.choralone.org> On 21-Dec-2006 22:57.31 (GMT), Clyde E. Kunkel wrote: > With the change from traditional /dev/hd* type device nodes to /dev/sd* > type nodes, I see that the highest partition number that can be used is > 15. Will this change so that higher numbers will be available? I do > have a system that has a drive with almost 30 small partitions used in a > research effort and the number of partitions has not been an issue thru fc6. devices.txt says that hdN device numbering supports up to 63 partitions per disk. It also says that sdN device numbering follows the same trend as hdN numbering (unified partition table handling, and all). I didn't think that PC BIOS partition tables supported > 15 partitions. To the best of my knowledge, the 63-partition numbering scheme was there for partition table formats that *did* support it (Amiga RDB, BSD disk label, etc). To quote the fdisk(8) manual page: The partition is a device name followed by a partition number. For example, /dev/hda1 is the first partition on the first IDE hard disk in the system. Disks can have up to 15 partitions. See also /usr/src/linux/Documentation/devices.txt. To reiterate what another writer has said, lvm is a smashing way of working. And it has a much more flexible ("meaningful") volume naming scheme. -- rob andrews :: pgp 0x01e00563 :: rob at choralone.org From gilboad at gmail.com Fri Dec 22 08:35:42 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Fri, 22 Dec 2006 10:35:42 +0200 Subject: New device drivers don't see beyond 15 partitions in fc7 In-Reply-To: <458B8A25.6020409@hhs.nl> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458B8A25.6020409@hhs.nl> Message-ID: <1166776542.27377.36.camel@gilboa-home-dev.localdomain> On Fri, 2006-12-22 at 08:32 +0100, Hans de Goede wrote: > Gilboa Davara wrote: > > On Thu, 2006-12-21 at 17:57 -0500, Clyde E. Kunkel wrote: > >> Hello, > >> > >> With the change from traditional /dev/hd* type device nodes to /dev/sd* > >> type nodes, I see that the highest partition number that can be used is > >> 15. Will this change so that higher numbers will be available? I do > >> have a system that has a drive with almost 30 small partitions used in a > >> research effort and the number of partitions has not been an issue thru fc6. > >> > >> -- > > > > Use LVM. > > Trust me. > > You won't be sorry. > > > > Use lvm is not the answer, if this was possible before the system should > upgrade to FC-7 flawlessly, if /dev/hdx accomodated more then 15 > partitions, then so should the new /dev/sdx when it becomes the new > device for this disk. > > Regards, > > Hans > Short answer: Use LVM! Long answer: Asking the kernel hackers to risk breaking compatibility inside inside the SCSI layer [1] and break God-knows-how-many-different-user-land-applications just to handle a 0.001% end case that can be handled differently (disable libata, use LVM), is pure madness. You can argue the it should be possible to disable libata in special end-cases such as the OP's case (and I'll second your motion), but that's another matter altogether. - Gilboa [1] I'm not very familiar with the partition/fs code, but something tells me the 16x minor->physical ID translation is hard coded everywhere. Plus, increasing the number of partitions to 63 will reduce the number of possible SCSI drives to 8 (?? I'm not sure. should be 512/64) and there are many people (including myself) that have more then 8 SCSI/SATA drives configurations running software RAID5/6. From pemboa at gmail.com Fri Dec 22 08:54:24 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 23 Dec 2006 02:54:24 +1800 Subject: [offtopic] Ignacio Vazquez-Abrams In-Reply-To: <16de708d0608282246x7b7a1eabi89e782f085efe636@mail.gmail.com> References: <16de708d0608282246x7b7a1eabi89e782f085efe636@mail.gmail.com> Message-ID: <16de708d0612220054h59fcd7f4u7b3182a095e531ae@mail.gmail.com> On 8/29/06, Arthur Pemberton wrote: > Hi guys, > > I apologize ahead of time for the offtopic nature of this thread, and > if desired, I will cease any continuation. Threads over on > fedora-extras-list have brought my attention to the e-dissappearance > of one "Ignacio Vazquez-Abrams". > > This guy has helped me out many times over of #fedora, and was always > online, despite me changing time zone twice - to the point where I > asked if he was a bot. He seemed to have also had a large load in > package maintaince. Fedora being partly about the community, I have to > ask: does anyone know what happened to this guy? His online presence > seems to have simply ceased as of May-2006. I searched Gmail for > emails from him, the last was in May. His blog > (http://www.ivazquez.net) seems also to have gone quiet as of May. > > Just felt that the guy has helped me enough to at least care if he > suddenly died or something. > > Peace. > > -- > To be updated... > Is it safe to say that this guy has gone to a better place? Even his domain has expired now. -- Fedora Core 6 and proud From dyek at real.com Fri Dec 22 09:13:49 2006 From: dyek at real.com (Daniel Yek) Date: Fri, 22 Dec 2006 01:13:49 -0800 Subject: Development machine setup for both i386 and x86_64 work Message-ID: <6.2.1.2.2.20061222004303.462804b0@mailone.real.com> Hi, How Fedora developers set up dev. machines to do both 32-bit and 64-bit development on a single AMD64 machine? Does it complicate 32-bit dev. work if the development machine is set up with x86_64 Fedora Core OS? I'm not asking what is possible, but how most developers deal with both 32-bit and 64-bit development environment; if different development is done on different dev. machines, fine, I will try to do that, rather than trying out something that may not work that well. Feedback is greatly appreciated. Thanks. -- Daniel Yek From j.w.r.degoede at hhs.nl Fri Dec 22 09:21:47 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 22 Dec 2006 10:21:47 +0100 Subject: Development machine setup for both i386 and x86_64 work In-Reply-To: <6.2.1.2.2.20061222004303.462804b0@mailone.real.com> References: <6.2.1.2.2.20061222004303.462804b0@mailone.real.com> Message-ID: <458BA3AB.3040300@hhs.nl> Daniel Yek wrote: > Hi, > > How Fedora developers set up dev. machines to do both 32-bit and 64-bit > development on a single AMD64 machine? > > Does it complicate 32-bit dev. work if the development machine is set up > with x86_64 Fedora Core OS? > > I'm not asking what is possible, but how most developers deal with both > 32-bit and 64-bit development environment; if different development is > done on different dev. machines, fine, I will try to do that, rather > than trying out something that may not work that well. > > Feedback is greatly appreciated. Thanks. > > Building 32bit binaries under an x86_64 install is possible but not easy, the easiest is to just install FC twice, one i386 version and one x86_64 and then chroot to the i386 root under a booted x86_64 instance. Regards, Hans From galibert at pobox.com Fri Dec 22 11:00:16 2006 From: galibert at pobox.com (Olivier Galibert) Date: Fri, 22 Dec 2006 12:00:16 +0100 Subject: Development machine setup for both i386 and x86_64 work In-Reply-To: <458BA3AB.3040300@hhs.nl> References: <6.2.1.2.2.20061222004303.462804b0@mailone.real.com> <458BA3AB.3040300@hhs.nl> Message-ID: <20061222110016.GA83575@dspnet.fr.eu.org> On Fri, Dec 22, 2006 at 10:21:47AM +0100, Hans de Goede wrote: > Building 32bit binaries under an x86_64 install is possible but not > easy, the easiest is to just install FC twice, one i386 version and one > x86_64 and then chroot to the i386 root under a booted x86_64 instance. Works up to a point, which is uname. uname -m still reports x86_64 in the chroot, and some stupid applications use that at compile time to decide what they are compiling on. Mozilla and friends and Openoffice are the ones I remember of, but there was others. OG. From dominik at greysector.net Fri Dec 22 11:03:16 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 22 Dec 2006 12:03:16 +0100 Subject: Development machine setup for both i386 and x86_64 work In-Reply-To: <20061222110016.GA83575@dspnet.fr.eu.org> References: <6.2.1.2.2.20061222004303.462804b0@mailone.real.com> <458BA3AB.3040300@hhs.nl> <20061222110016.GA83575@dspnet.fr.eu.org> Message-ID: <20061222110316.GB6933@ryvius.pekin.waw.pl> On Friday, 22 December 2006 at 12:00, Olivier Galibert wrote: > On Fri, Dec 22, 2006 at 10:21:47AM +0100, Hans de Goede wrote: > > Building 32bit binaries under an x86_64 install is possible but not > > easy, the easiest is to just install FC twice, one i386 version and one > > x86_64 and then chroot to the i386 root under a booted x86_64 instance. > > Works up to a point, which is uname. uname -m still reports x86_64 in > the chroot, and some stupid applications use that at compile time to > decide what they are compiling on. Mozilla and friends and Openoffice > are the ones I remember of, but there was others. Use setarch. $ uname -m x86_64 $ setarch i686 uname -m i686 Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From buildsys at redhat.com Fri Dec 22 11:09:21 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Fri, 22 Dec 2006 06:09:21 -0500 Subject: rawhide report: 20061222 changes Message-ID: <200612221109.kBMB9LGl013321@hs20-bc2-6.build.redhat.com> Updated Packages: audit-1.3.1-2.fc7 ----------------- * Sun Dec 10 2006 Steve Grubb 1.3.1-2 - Make more adjustments for python 2.5 dev86-0.16.17-2.2 ----------------- * Wed Jul 12 2006 Jesse Keating - 0.16.17-2.2 - rebuild * Tue Feb 07 2006 Jesse Keating - 0.16.17-2.1 - rebuilt for new gcc4.1 snapshot and glibc changes * Wed Jan 25 2006 Jeremy Katz - 0.16.17-2 - build on x86_64 - don't build elks (it's not happy on x86_64) evolution-2.9.4-3.fc7 --------------------- * Thu Dec 21 2006 Matthew Barnes - 2.9.4-3.fc7 - Add patch for RH bug #218898 (viewing message source). gettext-0.16.1-1.fc7 -------------------- * Fri Dec 22 2006 Jens Petersen - 0.16.1-1 - update to 0.16.1 gnome-icon-theme-2.17.4.1-1.fc7 ------------------------------- * Thu Dec 21 2006 Matthias Clasen - 2.17.4.1-1 - Update to 2.17.4.1 gnuplot-4.0.0-15.fc7 -------------------- * Fri Dec 22 2006 Ivana Varekova - 4.0.0-15 - Resolves: 173752 - gnuplot refers to /usr/X11R6/lib/fonts/Type1 * Thu Dec 21 2006 Ivana Varekova - 4.0.0-14 - remove --without-gd options (#173922, #172565) - spec file cleanup gtk2-2.10.6-9.fc7 ----------------- * Thu Dec 21 2006 Matthias Clasen - 2.10.4-9 - Make gdk_pixbuf_loader_close() idempotent - Always emit the closed signal when the loader is closed * Thu Dec 21 2006 Matthias Clasen - 2.10.6-8 - Make update scripts handle slight variations in $host * Sat Dec 09 2006 Matthias Clasen - 2.10.6-7 - Fix error handling in pixbuf loaders (#218755) - Fix clipping of mnemonic underlines (#218615) - Give accessible names to message dialogs (#215472) - Fix a crash in the handling of invalid icon themes (#218247) - Make the print dialog work when the 'BrowseShortNames Off' cups option is used (#217220) icu-3.6-13 ---------- * Thu Dec 21 2006 Caolan McNamara - 3.6-13 - Resolves: rhbz#220433 modify icu.icu5431.malayam.patch * Fri Nov 10 2006 Caolan McNamara - 3.6-12 - Resolves: rhbz#214948 icu.icu5506.multiplevowels.patch intltool-0.35.2-1.fc7 --------------------- * Thu Dec 21 2006 Matthias Clasen - 0.35.2-1 - Update to 0.35.2 kernel-2.6.19-1.2891.fc7 ------------------------ * Thu Dec 21 2006 David Woodhouse - Fix IPv6 checksum handling logwatch-7.3.2-1.fc7 -------------------- mc-1:4.6.1a-38.fc7 ------------------ * Thu Dec 21 2006 Jindrich Novy 4.6.1a-38 - rebuild because of the %{_host} macro change (Related: #220273) openssh-4.5p1-1.fc7 ------------------- * Thu Dec 21 2006 Tomas Mraz - 4.5p1-1 - update to 4.5p1 (#212606) pango-1.15.2-1.fc7 ------------------ * Thu Dec 21 2006 Matthias Clasen - 1.15.2-1 - Update to 1.15.2 selinux-policy-2.4.6-16.fc7 --------------------------- * Tue Dec 19 2006 Dan Walsh 2.4.6-16 - Allow semanage to exec it self. Label genhomedircon as semanage_exec_t Resolves: #219421 - Allow sysadm_lpr_t to manage other print spool jobs Resolves: #220080 shadow-utils-2:4.0.18.1-8.fc7 ----------------------------- * Thu Dec 21 2006 Dan Walsh 2:4.0.18.1-8 - Fix execution and creation of Home Directories under SELinux - Resolves: rhbz#217441 system-config-printer-0.7.43-1.fc7 ---------------------------------- * Thu Dec 21 2006 Tim Waugh 0.7.43-1 - Don't check against IEEE 1284 DES field at all. - Merged device matching code (bug #219518). - Catch non-fatal errors when auto-matching device. - Fixed driver checking bug involving pipelines (bug #220347). - Show PPD errors (bug #220136). system-config-soundcard-2.0.6-1.fc7 ----------------------------------- * Thu Dec 21 2006 Martin Stransky 2.0.6-1 - translation update system-config-users-1.2.51-1.fc7 -------------------------------- * Thu Dec 21 2006 Nils Philippsen - 1.2.51 - pick up updated translations (#216396) xen-3.0.3-3 ----------- * Thu Dec 14 2006 Jeremy Katz - 3.0.3-3 - fix the build * Thu Dec 07 2006 Jeremy Katz - 3.0.3-2 - rebuild for python 2.5 Broken deps for s390 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ppc64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) Broken deps for i386 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 Broken deps for ia64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) Broken deps for x86_64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) Broken deps for ppc ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 Broken deps for s390x ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) From dyek at real.com Fri Dec 22 11:50:16 2006 From: dyek at real.com (Daniel Yek) Date: Fri, 22 Dec 2006 03:50:16 -0800 Subject: Development machine setup for both i386 and x86_64 work In-Reply-To: <20061222110316.GB6933@ryvius.pekin.waw.pl> References: <6.2.1.2.2.20061222004303.462804b0@mailone.real.com> <458BA3AB.3040300@hhs.nl> <20061222110016.GA83575@dspnet.fr.eu.org> <20061222110316.GB6933@ryvius.pekin.waw.pl> Message-ID: <6.2.1.2.2.20061222034526.465ffca8@mailone.real.com> At 03:03 AM 12/22/2006, Dominik 'Rathann' Mierzejewski wrote: >On Friday, 22 December 2006 at 12:00, Olivier Galibert wrote: > > On Fri, Dec 22, 2006 at 10:21:47AM +0100, Hans de Goede wrote: > > > Building 32bit binaries under an x86_64 install is possible but not > > > easy, the easiest is to just install FC twice, one i386 version and one > > > x86_64 and then chroot to the i386 root under a booted x86_64 instance. > > Great information. Thank you all. I'm already using the 32-bit LSB chroot Build Environment, so it appears that I should be able to use x86_64 OS as my main dev. machine. Merry Christmas! -- Daniel Yek > > Works up to a point, which is uname. uname -m still reports x86_64 in > > the chroot, and some stupid applications use that at compile time to > > decide what they are compiling on. Mozilla and friends and Openoffice > > are the ones I remember of, but there was others. > >Use setarch. > >$ uname -m >x86_64 >$ setarch i686 uname -m >i686 > >Regards, >R. From clydekunkel7734 at cox.net Fri Dec 22 15:04:48 2006 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Fri, 22 Dec 2006 10:04:48 -0500 Subject: New device drivers don't see beyond 15 partitions in fc7 In-Reply-To: <20061222082851.GC6739@aphasia.badger.choralone.org> References: <458B115B.7060606@cox.net> <20061222082851.GC6739@aphasia.badger.choralone.org> Message-ID: <458BF410.1070303@cox.net> Rob Andrews wrote: > On 21-Dec-2006 22:57.31 (GMT), Clyde E. Kunkel wrote: > > With the change from traditional /dev/hd* type device nodes to /dev/sd* > > type nodes, I see that the highest partition number that can be used is > > 15. Will this change so that higher numbers will be available? I do > > have a system that has a drive with almost 30 small partitions used in a > > research effort and the number of partitions has not been an issue thru fc6. > > devices.txt says that hdN device numbering supports up to 63 partitions per > disk. It also says that sdN device numbering follows the same trend as hdN > numbering (unified partition table handling, and all). > > I didn't think that PC BIOS partition tables supported > 15 partitions. To > the best of my knowledge, the 63-partition numbering scheme was there for > partition table formats that *did* support it (Amiga RDB, BSD disk label, > etc). > > To quote the fdisk(8) manual page: > > The partition is a device name followed by a partition number. > For example, /dev/hda1 is the first partition on the first IDE > hard disk in the system. Disks can have up to 15 partitions. > See also /usr/src/linux/Documentation/devices.txt. > > To reiterate what another writer has said, lvm is a smashing way of working. > And it has a much more flexible ("meaningful") volume naming scheme. > I do use LVM extensively and appreciate its flexibility. The use of > 15 partitions on one spindle was a deliberate design to accommodate a specific research method. AFAIK, grub will not boot from an LV, but beyond that, not sure if there is any other software that would prohibit converting everything to LVM. (BTW, will grub be modified to boot from an LV?) -- Regards, Old Fart (my reply-to address is "munged" to defeat spambots) From jkeating at redhat.com Fri Dec 22 15:31:45 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Dec 2006 10:31:45 -0500 Subject: New device drivers don't see beyond 15 partitions in fc7 In-Reply-To: <458BF410.1070303@cox.net> References: <458B115B.7060606@cox.net> <20061222082851.GC6739@aphasia.badger.choralone.org> <458BF410.1070303@cox.net> Message-ID: <200612221031.45683.jkeating@redhat.com> On Friday 22 December 2006 10:04, Clyde E. Kunkel wrote: > (BTW, will grub be modified to boot from an LV?) Grub2 has this, and other improvements. Too bad about it being utterly broken though and not suitable for even rawhide at this point. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jreiser at BitWagon.com Fri Dec 22 15:50:59 2006 From: jreiser at BitWagon.com (John Reiser) Date: Fri, 22 Dec 2006 07:50:59 -0800 Subject: LVM not fit for Fedora Core In-Reply-To: <1166770126.27377.1.camel@gilboa-home-dev.localdomain> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> Message-ID: <458BFEE3.9060601@BitWagon.com> Gilboa Davara wrote: > Use LVM. > Trust me. > You won't be sorry. I've been there, done that, and regretted it deeply. I got rid of LVM the first chance I could. LVM does not inter-operate with anything else. Grub does not work under LVM. Parted does not grok LVM: you cannot create a hard partition from LVM free space. Using the rescue CDs is a nightmare under LVM: the LVM setup is not recognized automatically (you must remember what it is) and the rescue environment contains no help or documentation on LVM (such as: the _syntax_ for naming the pieces!) LVM probably kills all low-level backup and recovery. Do not use LVM unless you are 100.000000% certain that you will never be faced with a hardware disaster. -- From jkeating at redhat.com Fri Dec 22 16:05:17 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 22 Dec 2006 11:05:17 -0500 Subject: LVM not fit for Fedora Core In-Reply-To: <458BFEE3.9060601@BitWagon.com> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458BFEE3.9060601@BitWagon.com> Message-ID: <200612221105.17838.jkeating@redhat.com> On Friday 22 December 2006 10:50, John Reiser wrote: > Using the rescue CDs is a nightmare under LVM: the LVM > setup is not recognized automatically I call BS. I test the rescueCD quite a lot during development process, and it _always_ find the LVM and sets it up automatically. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gilboad at gmail.com Fri Dec 22 16:11:28 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Fri, 22 Dec 2006 18:11:28 +0200 Subject: LVM not fit for Fedora Core In-Reply-To: <458BFEE3.9060601@BitWagon.com> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458BFEE3.9060601@BitWagon.com> Message-ID: <1166803888.27377.48.camel@gilboa-home-dev.localdomain> On Fri, 2006-12-22 at 07:50 -0800, John Reiser wrote: > Gilboa Davara wrote: > > > Use LVM. > > Trust me. > > You won't be sorry. > > I've been there, done that, and regretted it deeply. > I got rid of LVM the first chance I could. > > LVM does not inter-operate with anything else. > Grub does not work under LVM. Why should it? > Parted does not grok LVM: LVM doesn't require parted for in-order to resize partitions. It's called logical volume manager for a reason, you know? > you cannot create a hard partition from LVM free space. HUH? Why-on-earth-would-you-want-to-do-that? > Using the rescue CDs is a nightmare under LVM: the LVM > setup is not recognized automatically (you must remember > what it is) and the rescue environment contains no help > or documentation on LVM (such as: the _syntax_ for naming > the pieces!) I can agree that Feodra documentation on the subject is... missing. A. TLDP has an excellent on-line documentation. [1] B. system-config-lvm is improvement constantly. C. Documentation missing? Join the documentation team and help them fix it. Never the less, I never had any problem mounting lvm under rescue CDs. > > LVM probably kills all low-level backup and recovery. At also "kills" when you meed to dynamically set and modify large number of partitions on multiple drives. > Do not use LVM unless you are 100.000000% certain > that you will never be faced with a hardware disaster. ... If LVM is stable enough to be the default option under RHEL, its stable enough for me. Either way, no-body is forcing LVM down your throat. Don't like it? Don't use it. Nobody is forcing it down your throat. - Gilboa [1] http://tldp.org/HOWTO/LVM-HOWTO/ From icon at fedoraproject.org Fri Dec 22 16:42:34 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Fri, 22 Dec 2006 11:42:34 -0500 Subject: [offtopic] Ignacio Vazquez-Abrams In-Reply-To: <16de708d0612220054h59fcd7f4u7b3182a095e531ae@mail.gmail.com> References: <16de708d0608282246x7b7a1eabi89e782f085efe636@mail.gmail.com> <16de708d0612220054h59fcd7f4u7b3182a095e531ae@mail.gmail.com> Message-ID: On 12/22/06, Arthur Pemberton wrote: > Is it safe to say that this guy has gone to a better place? Even his > domain has expired now. I've done some investigative work, but I'm afraid unless he announces himself, we won't be able to find anything out. I've used the whitepages to look up his last known address, and then called a few neighbours on the same street. It seems that the house was owned by someone else, who was renting out an apartment -- I'm guessing Ignacio was their tenant. According to one of the neighbours, earlier this year the house went for sale, and the old owner moved elsewhere -- Ignacio probably also had to move at that point. Sadly, that's where the trail ends. I called the Bampton police department, but they have no records for Ignacio Vazquez-Abrams, so if anything happened to him, it must have happened outside of Brampton. I guess we can call the Toronto police department, but I doubt they would be as helpful as Brampton's. There you have it, folks. Let's hope he's just been busy with life, since we have no reason to believe otherwise. Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From dyek at real.com Fri Dec 22 16:55:57 2006 From: dyek at real.com (Daniel Yek) Date: Fri, 22 Dec 2006 08:55:57 -0800 Subject: LVM not fit for Fedora Core In-Reply-To: <1166803888.27377.48.camel@gilboa-home-dev.localdomain> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458BFEE3.9060601@BitWagon.com> <1166803888.27377.48.camel@gilboa-home-dev.localdomain> Message-ID: <6.2.1.2.2.20061222083537.48f16778@mailone.real.com> At 08:11 AM 12/22/2006, Gilboa Davara wrote: >On Fri, 2006-12-22 at 07:50 -0800, John Reiser wrote: > > Gilboa Davara wrote: > > > > > Use LVM. > > > Trust me. > > > You won't be sorry. > > > > I've been there, done that, and regretted it deeply. I used LVM for a few years to double up hard drives (in stripes) to increase performance. I think it worked well that way, even though I don't exactly need that kind of performance most of the time. It was just a casual way of trying out new technologies. I did stop using it after one of my hard drive started to fail and I plug both hard drives into another Fedora Core machine also configured with LVM, and I couldn't find a way to boot up that machine with both sets of LVM. IIRC, it complained about 2 logical partitions of the same names (collision), or something like that. With the extra LVM volume removed, I could boot; but with them plugged in, I couldn't boot (the otherwise healthy LVM volumes) at all. Is there a solution for such situation? I admit that I never emailed this mailing list for help and perhaps didn't read up enough documentation, even though I read up a lot years before that. I gave up using LVM, partly because after reading it up so much, I was still having troubles rescuing data on my failing hard drives. I think with improved tools, it need not be so difficult. I'm having a lot of problems remembering just which partitions belong to which LVM volumes and which I can format to free some partitions out. Partition labelling support should be added to be practical. Or maybe I should not choose a potentially hard-to-remember partitioning scheme, but should use only one LVM per disk and not striped. Hope I'm not choosing any side here. I'm just hoping the experience with LVM, especially when working at the partition level can be improved. -- Daniel Yek From jreiser at BitWagon.com Fri Dec 22 16:57:14 2006 From: jreiser at BitWagon.com (John Reiser) Date: Fri, 22 Dec 2006 08:57:14 -0800 Subject: LVM not fit for Fedora Core In-Reply-To: <200612221105.17838.jkeating@redhat.com> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458BFEE3.9060601@BitWagon.com> <200612221105.17838.jkeating@redhat.com> Message-ID: <458C0E6A.1080400@BitWagon.com> Jesse Keating wrote: > On Friday 22 December 2006 10:50, John Reiser wrote: > >>Using the rescue CDs is a nightmare under LVM: the LVM >>setup is not recognized automatically > > > I call BS. I test the rescueCD quite a lot during development process, and it > _always_ find the LVM and sets it up automatically. Didn't work for me in March 2006 on x86_64 using a then-reasonbly-current rescue CD (probably a couple months old). -- From skvidal at linux.duke.edu Fri Dec 22 17:03:58 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 22 Dec 2006 12:03:58 -0500 Subject: [offtopic] Ignacio Vazquez-Abrams In-Reply-To: References: <16de708d0608282246x7b7a1eabi89e782f085efe636@mail.gmail.com> <16de708d0612220054h59fcd7f4u7b3182a095e531ae@mail.gmail.com> Message-ID: <1166807038.7782.23.camel@cutter> On Fri, 2006-12-22 at 11:42 -0500, Konstantin Ryabitsev wrote: > On 12/22/06, Arthur Pemberton wrote: > > Is it safe to say that this guy has gone to a better place? Even his > > domain has expired now. > > I've done some investigative work, but I'm afraid unless he announces > himself, we won't be able to find anything out. > > I've used the whitepages to look up his last known address, and then > called a few neighbours on the same street. It seems that the house > was owned by someone else, who was renting out an apartment -- I'm > guessing Ignacio was their tenant. According to one of the neighbours, > earlier this year the house went for sale, and the old owner moved > elsewhere -- Ignacio probably also had to move at that point. > > Sadly, that's where the trail ends. I called the Bampton police > department, but they have no records for Ignacio Vazquez-Abrams, so if > anything happened to him, it must have happened outside of Brampton. I > guess we can call the Toronto police department, but I doubt they > would be as helpful as Brampton's. > > There you have it, folks. Let's hope he's just been busy with life, > since we have no reason to believe otherwise. > Icon, Thank you for looking into it as much as you did. It's appreciated. -sv From jreiser at BitWagon.com Fri Dec 22 17:32:50 2006 From: jreiser at BitWagon.com (John Reiser) Date: Fri, 22 Dec 2006 09:32:50 -0800 Subject: LVM not fit for Fedora Core In-Reply-To: <1166803888.27377.48.camel@gilboa-home-dev.localdomain> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458BFEE3.9060601@BitWagon.com> <1166803888.27377.48.camel@gilboa-home-dev.localdomain> Message-ID: <458C16C2.8080400@BitWagon.com> Gilboa Davara wrote: > On Fri, 2006-12-22 at 07:50 -0800, John Reiser wrote: > >>Gilboa Davara wrote: >> >> >>>Use LVM. >>>Trust me. >>>You won't be sorry. >> >>I've been there, done that, and regretted it deeply. >>I got rid of LVM the first chance I could. >> >>LVM does not inter-operate with anything else. >>Grub does not work under LVM. > > > Why should it? Why shouldn't it? LVM is touted as "the solution" to restrictions on disk partitioning. Except that LVM doesn't work for the first logical access to disk partitions: booting. >> Parted does not grok LVM: > > > LVM doesn't require parted for in-order to resize partitions. > It's called logical volume manager for a reason, you know? > > >>you cannot create a hard partition from LVM free space. > > > HUH? > Why-on-earth-would-you-want-to-do-that? To interoperate with the rest of the world, such as other operating systems, even other distributions of Linux, that understand DOS partition tables but not LVM. If you don't have infinitely many boxes then it is useful to be able to "compromise". > > >>Using the rescue CDs is a nightmare under LVM: the LVM >>setup is not recognized automatically (you must remember >>what it is) and the rescue environment contains no help >>or documentation on LVM (such as: the _syntax_ for naming >>the pieces!) > > > I can agree that Feodra documentation on the subject is... missing. > A. TLDP has an excellent on-line documentation. [1] > B. system-config-lvm is improvement constantly. > C. Documentation missing? Join the documentation team and help them fix > it. "Get off the bus one stop before I do." I didn't recognize that LVM documentation was missing from the rescue CD until I needed it but it wasn't there. > > Never the less, I never had any problem mounting lvm under rescue CDs. > > >>LVM probably kills all low-level backup and recovery. > > > At also "kills" when you meed to dynamically set and modify large number > of partitions on multiple drives. > > >>Do not use LVM unless you are 100.000000% certain >>that you will never be faced with a hardware disaster. > > > ... If LVM is stable enough to be the default option under RHEL, its > stable enough for me. Data longevity is not the strong suit of RHEL/Fedora Core/Linux. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137068 > Either way, no-body is forcing LVM down your throat. > Don't like it? Don't use it. Nobody is forcing it down your throat. _You_ strongly advocated LVM and suggested "You won't be sorry" without any disclaimers. I'm supplying some of the omissions. -- From pemboa at gmail.com Fri Dec 22 17:53:41 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 22 Dec 2006 11:53:41 -0600 Subject: [offtopic] Ignacio Vazquez-Abrams In-Reply-To: References: <16de708d0608282246x7b7a1eabi89e782f085efe636@mail.gmail.com> <16de708d0612220054h59fcd7f4u7b3182a095e531ae@mail.gmail.com> Message-ID: <16de708d0612220953h406da369xca5c93848d3ae9de@mail.gmail.com> On 12/22/06, Konstantin Ryabitsev wrote: > On 12/22/06, Arthur Pemberton wrote: > > Is it safe to say that this guy has gone to a better place? Even his > > domain has expired now. > > I've done some investigative work, but I'm afraid unless he announces > himself, we won't be able to find anything out. > > I've used the whitepages to look up his last known address, and then > called a few neighbours on the same street. It seems that the house > was owned by someone else, who was renting out an apartment -- I'm > guessing Ignacio was their tenant. According to one of the neighbours, > earlier this year the house went for sale, and the old owner moved > elsewhere -- Ignacio probably also had to move at that point. > > Sadly, that's where the trail ends. I called the Bampton police > department, but they have no records for Ignacio Vazquez-Abrams, so if > anything happened to him, it must have happened outside of Brampton. I > guess we can call the Toronto police department, but I doubt they > would be as helpful as Brampton's. > > There you have it, folks. Let's hope he's just been busy with life, > since we have no reason to believe otherwise. > > Cheers, > -- > Konstantin Ryabitsev > Montr?al, Qu?bec Thanks a lot for at checking up on the guy. I too hope all is well with him and he did just get busy with life. -- Fedora Core 6 and proud From davidz at redhat.com Fri Dec 22 18:32:46 2006 From: davidz at redhat.com (David Zeuthen) Date: Fri, 22 Dec 2006 13:32:46 -0500 Subject: Announcing the Fedora 6 Zod live CD and live CD tools Message-ID: <1166812366.2752.99.camel@zelda.fubar.dk> Hi, After lots of feedback, bug fixing and testing of the beta live CD announced 3 weeks ago, I'm pleased to announce the first official Fedora live CD. This live CD is based on packages from the Fedora Core 6 (codenamed "Zod") and Fedora Extras package collections and is such 100% free software. At a glance, the live CD features o Linux 2.6.18 o GNOME 2.16 desktop environment o GStreamer 0.10 multimedia framework o X.org 7.1 o AIGLX and Compiz for 3D desktop o Lots of applications including, but not limited to o Beagle (Desktop Search) o F-Spot (Photo Management) o Evolution (Email and Calendering) o Firefox (Web Browsing) o Ekiga (IP telephony) o Rhythmbox (Music Player) o Totem (Movie Player) o Games (Games) o The Gimp (Graphics) o Inkscape (Vector Graphics) o Abiword (Word Processor) o Gnumeric (Spreadsheet) o nautilus-open-terminal (For the adult in you) o Assistive Technology including the Orca screen reader o NetworkManager is on by default o VPN connectivity software including vnpc and OpenVPN o Partition editing via GParted o SELinux targeted mode including the SELinux trouble shooter o Many many fonts; almost 100% coverage o All the localizations included in FC6 and FC6 o All the input methods (SCIM) present in FC6 o Exclusive live CD wallpaper you won't find in FC6 or FE6! o R/W file system so you can install software on the running live CD o Ability to run from RAM if you have 1GB or more of memory o and lots and lots more.. The live CD is currently only available for i386 architectures. Support for other architectures including ppc and x86_64 is planned. The live cd weighs around 682MB. Download from http://download.fedora.redhat.com/pub/fedora/projects/live/FC-6-i386-livecd-1.iso SHA1SUM: 8771d21af1974492424438cbe42f1bae0161ea96 FC-6-i386-livecd-1.iso or get on the Torrent using http://torrent.fedoraproject.org/torrents/Zod-livecd-1-i386.torrent Feedback can be given in Bugzilla; file a bug against the component you have an issue with.. and make it block this tracker bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FC6LiveCDTracker if you believe it's a live CD specific bug. Don't get burned on Christmas shopping, burn the gift of a live CD! ==== This live CD is built using a source code based on the pilgrim project. This is an open project and participation is encouraged and appreciated. See these documents on how to get involved hacking on the code and what it's all about http://gitweb.freedesktop.org/?p=users/david/livecd-tools.git;a=blob;hb=HEAD;f=HACKING http://gitweb.freedesktop.org/?p=users/david/livecd-tools.git;a=blob;hb=HEAD;f=README Participate on the Fedora Live CD mailing list and the Wiki page to make the Fedora live CD experience even better http://fedoraproject.org/wiki/FedoraLiveCD http://www.redhat.com/mailman/listinfo/fedora-livecd-list The livecd-tools and fedora-livecd packages, which is required to rebuild the live CD, have just been submitted to Fedora Extras, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220635 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220637 for details. Until these packages are in Extras, you can grab source and binary i386 packages from here http://people.redhat.com/davidz/livecd/ and start cranking out your own live CD's. Thanks and a merry Christmas break to everyone! David From pemboa at gmail.com Fri Dec 22 18:39:40 2006 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 22 Dec 2006 12:39:40 -0600 Subject: Announcing the Fedora 6 Zod live CD and live CD tools In-Reply-To: <1166812366.2752.99.camel@zelda.fubar.dk> References: <1166812366.2752.99.camel@zelda.fubar.dk> Message-ID: <16de708d0612221039w793cb950w14160a41d04182aa@mail.gmail.com> On 12/22/06, David Zeuthen wrote: > > Hi, > > After lots of feedback, bug fixing and testing of the beta live CD > announced 3 weeks ago, I'm pleased to announce the first official Fedora > live CD. This live CD is based on packages from the Fedora Core 6 > (codenamed "Zod") and Fedora Extras package collections and is such 100% > free software. At a glance, the live CD features > > o Linux 2.6.18 > o GNOME 2.16 desktop environment > o GStreamer 0.10 multimedia framework > o X.org 7.1 > o AIGLX and Compiz for 3D desktop > o Lots of applications including, but not limited to > o Beagle (Desktop Search) > o F-Spot (Photo Management) > o Evolution (Email and Calendering) > o Firefox (Web Browsing) > o Ekiga (IP telephony) > o Rhythmbox (Music Player) > o Totem (Movie Player) > o Games (Games) > o The Gimp (Graphics) > o Inkscape (Vector Graphics) > o Abiword (Word Processor) > o Gnumeric (Spreadsheet) > o nautilus-open-terminal (For the adult in you) > o Assistive Technology including the Orca screen reader > o NetworkManager is on by default > o VPN connectivity software including vnpc and OpenVPN > o Partition editing via GParted > o SELinux targeted mode including the SELinux trouble shooter > o Many many fonts; almost 100% coverage > o All the localizations included in FC6 and FC6 > o All the input methods (SCIM) present in FC6 > o Exclusive live CD wallpaper you won't find in FC6 or FE6! > o R/W file system so you can install software on the running live CD > o Ability to run from RAM if you have 1GB or more of memory > > o and lots and lots more.. > > The live CD is currently only available for i386 architectures. Support > for other architectures including ppc and x86_64 is planned. The live cd > weighs around 682MB. Download from > > http://download.fedora.redhat.com/pub/fedora/projects/live/FC-6-i386-livecd-1.iso > SHA1SUM: 8771d21af1974492424438cbe42f1bae0161ea96 FC-6-i386-livecd-1.iso > > or get on the Torrent using > > http://torrent.fedoraproject.org/torrents/Zod-livecd-1-i386.torrent > > Feedback can be given in Bugzilla; file a bug against the component you > have an issue with.. and make it block this tracker bug > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=FC6LiveCDTracker > > if you believe it's a live CD specific bug. > > Don't get burned on Christmas shopping, burn the gift of a live CD! > > ==== > > This live CD is built using a source code based on the pilgrim project. > This is an open project and participation is encouraged and appreciated. > See these documents on how to get involved hacking on the code and what > it's all about > > http://gitweb.freedesktop.org/?p=users/david/livecd-tools.git;a=blob;hb=HEAD;f=HACKING > http://gitweb.freedesktop.org/?p=users/david/livecd-tools.git;a=blob;hb=HEAD;f=README > > Participate on the Fedora Live CD mailing list and the Wiki page to make > the Fedora live CD experience even better > > http://fedoraproject.org/wiki/FedoraLiveCD > http://www.redhat.com/mailman/listinfo/fedora-livecd-list > > The livecd-tools and fedora-livecd packages, which is required to > rebuild the live CD, have just been submitted to Fedora Extras, see > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220635 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220637 > > for details. Until these packages are in Extras, you can grab source and > binary i386 packages from here > > http://people.redhat.com/davidz/livecd/ > > and start cranking out your own live CD's. > > Thanks and a merry Christmas break to everyone! > > David > Any plans to make Live CDs with KDE? Would be nice to replace Knoppix with something more Fedora like -- Fedora Core 6 and proud From davidz at redhat.com Fri Dec 22 18:48:04 2006 From: davidz at redhat.com (David Zeuthen) Date: Fri, 22 Dec 2006 13:48:04 -0500 Subject: Announcing the Fedora 6 Zod live CD and live CD tools In-Reply-To: <16de708d0612221039w793cb950w14160a41d04182aa@mail.gmail.com> References: <1166812366.2752.99.camel@zelda.fubar.dk> <16de708d0612221039w793cb950w14160a41d04182aa@mail.gmail.com> Message-ID: <1166813284.2752.106.camel@zelda.fubar.dk> On Fri, 2006-12-22 at 12:39 -0600, Arthur Pemberton wrote: > Any plans to make Live CDs with KDE? Would be nice to replace Knoppix > with something more Fedora like Certainly and I, for one, would be happy to see someone step up and do live cd flavors for KDE and heck, also Eclipse, Music, Games and the other SIG's in the Fedora Universe. Also, when we add the "install live cd to hard disk" feature such live cd's suddenly becomes derived distributions in it's own sense. All backed by the Fedora Package Collections. I don't think it's hard; it's all encoded in the fedora-live source RPM. Questions should probably be directed to fedora-livecd-list. Thanks. David From lamont at gurulabs.com Fri Dec 22 19:14:52 2006 From: lamont at gurulabs.com (Lamont Peterson) Date: Fri, 22 Dec 2006 12:14:52 -0700 Subject: LVM not fit for Fedora Core In-Reply-To: <458BFEE3.9060601@BitWagon.com> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458BFEE3.9060601@BitWagon.com> Message-ID: <200612221214.58614.lamont@gurulabs.com> On Friday 22 December 2006 08:50am, John Reiser wrote: > Gilboa Davara wrote: > > Use LVM. > > Trust me. > > You won't be sorry. > > I've been there, done that, and regretted it deeply. > I got rid of LVM the first chance I could. The very first thought in my mind is that you never understood what role LVM plays or how it actually works. By that, I don't mean the internal workings of LVM itself, I mean what LVM does for you and how to take advantage of it. > LVM does not inter-operate with anything else. Bull. LVM takes one or more block devices, aggregates them together into a single volume group (VG) and then manages the disbursement of available storage in the VG by creating block devices called logical volumes (VG). Notice, block devices in, block devices out. It's part of the sheer genius of the design of Linux that the RAID, LVM, multipath-I/O, filesystem "drivers" and other related code doesn't have to know *anything* about any of the other systems. They just work on top of block devices LVM is extremely inter-operable with everything else. > Grub does not work under LVM. There are patches available that let GRUB boot kernel images stored on LVM. But why would you want to? Also, IIRC, GRUB 2 will have this support out-of-the-box. > Parted does not grok LVM: parted doesn't grok a lot of things. In this case, it doesn't need to and shouldn't. parted is a [part]ition [ed]itor. It would be considered inappropriate by many for it to manipulate LVM. That's what the LVM commands are for. But if you want a frontend there is a new on in Fedora/RHEL called "system-config-lvm". SUSE has had extensive LVM support in YaST's partitioning tools for several years. There are frontends available. > you cannot create a hard partition from LVM free space. Nope. But I have no idea what you are thinking here. Not to sound condescending or anything, but that's a completely idiotic thing to suggest. LVM creates block devices that look just like a plain old partition (POP? :) ) to everything that uses them (block devices, partitions, etc.), there is no difference. You can put LVM on RAID on LVM on RAID on iSCSI if wanted to. It's all just block devices. > Using the rescue CDs is a nightmare under LVM: The individual LVM commands are not found in the rescue environment. You have to run "lvm" and then at the "lvm>" prompt you can run LVM commands just like on the normal, running systems. I've wondered why the rescue environment doesn't just have all the lvm commands as symlinks to "lvm", like on the installed systems. That would make it a little easier to use. > the LVM > setup is not recognized automatically Yes, it is. It's always worked just fine as far back as I can remember Red Hat having LVM support at all. I have no idea what you did that prevented it from picking things up. For it to fail, the root filesystem would have to be unavailable or the /etc/fstab file on it would have to be wrong or corrupted (I think that's the whole list). > (you must remember > what it is) and the rescue environment contains no help > or documentation on LVM (such as: the _syntax_ for naming > the pieces!) Sounds like you've only used the stupid names for VGs and LVs that anaconda defaults to, like LogVol00, which are really useless names. > LVM probably kills all low-level backup and recovery. Nope, you're wrong there. IN fact, it has features like snapshotting that make low-level backup and recovery significantly easier and even make it possible to get consistent backups without taking anything offline. Let that DB keep running while you backup it's files (or use it's own backup tool) against an unchanging, read-only copy. > Do not use LVM unless you are 100.000000% certain > that you will never be faced with a hardware disaster. Use RAID (and not linear or RAID0) for redundancy to deal with/weather hardware failures. LVM has nothing to do with improving redundancy. Yes, it does have some striping abilities, very similar to RAID, but that's not what it's for. It's Logical Volume *Management*. Use LVM to make all that space manageable. Don't want to decide right now which "partition" to allocate all that space to? Then don't. With LVM, you can allocate space, *as needed*. Besides, on the few occasions that I have had to deal with hardware failures *i.e. disks and disk controllers), having LVM has been very helpful for me. -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lamont at gurulabs.com Fri Dec 22 19:15:14 2006 From: lamont at gurulabs.com (Lamont Peterson) Date: Fri, 22 Dec 2006 12:15:14 -0700 Subject: LVM not fit for Fedora Core In-Reply-To: <6.2.1.2.2.20061222083537.48f16778@mailone.real.com> References: <458B115B.7060606@cox.net> <1166803888.27377.48.camel@gilboa-home-dev.localdomain> <6.2.1.2.2.20061222083537.48f16778@mailone.real.com> Message-ID: <200612221215.15365.lamont@gurulabs.com> On Friday 22 December 2006 09:55am, Daniel Yek wrote: > At 08:11 AM 12/22/2006, Gilboa Davara wrote: > >On Fri, 2006-12-22 at 07:50 -0800, John Reiser wrote: > > > Gilboa Davara wrote: > > > > Use LVM. > > > > Trust me. > > > > You won't be sorry. > > > > > > I've been there, done that, and regretted it deeply. > > I used LVM for a few years to double up hard drives (in stripes) to > increase performance. I think it worked well that way, even though I don't > exactly need that kind of performance most of the time. It was just a > casual way of trying out new technologies. Software RAID would have been a little better for that. Personally, I subscribe to the "use the right tool for the job" theory. RAID for RAID things, LVM on top of RAID for manageability. Still, it does work well for that situation. > I did stop using it after one of my hard drive started to fail and I plug > both hard drives into another Fedora Core machine also configured with LVM, > and I couldn't find a way to boot up that machine with both sets of LVM. > IIRC, it complained about 2 logical partitions of the same names > (collision), or something like that. With the extra LVM volume removed, I > could boot; but with them plugged in, I couldn't boot (the otherwise > healthy LVM volumes) at all. Been there. The problem is that you had two volume groups (VG) with the same name. > Is there a solution for such situation? I admit that I never emailed this > mailing list for help and perhaps didn't read up enough documentation, even > though I read up a lot years before that. Yup. Really simple fix. Rename one of the VGs with "vgrename". Some ways of doing this: 1. Give each machine's VG the same name as the box to begin with at installation. That way, when you get into the situation of wanting to mount up the disks from one box in another, there will not be a "conflict" to begin with. 2. Rename the VG on the hosting system (i.e. the box you're putting the disks into. This requires a number of simple steps to complete successfully. To use vgrename, the entire VG must be offline. So, boot a rescue environment (via CD, PXE, however), skip trying to mount up the disk (or use the "nomount" option on the "rescue" boot: line), and run (assuming the old name is "vg0" and the new name should be "herold": # lvm lvm> vgscan . . . output omitted . . . lvm> vgchange -a n vg0 . . . output omitted . . . lvm> vgrename vg0 herold . . . output omitted . . . lvm> vgchange -a y herold . . . output omitted . . . lvm> exit Then, mount up the root LV, the /boot/ partition, and things like /usr/ and /dev/: # mkdir /mnt/sysimage # mount /dev/herold/root /mnt/sysimage # mount /dev/sda1 /mnt/sysimage/boot # mount /dev/herold/usr /mnt/sysimage/usr Of course, change the names of the devices appropriately. You can then "chroot" and run "mkinitrd" to fix up the name of the root device (because the VG name changed). Also, don't forget to change the "root=" value(s) in grub.conf (menu.lst on any other distribution). I usually just snag the mkinitrd command out of the "/sbin/new-kernel-pkg" script (use "rpm -q --scripts kernel-`uname -r`" to see that's what the kernel RPMs run). 3. Rename the VG of the system that you are moving the drive(s) from. Just use a rescue environment, like I just showed. However, in this case, if you are not planing on returning the disks to the other machine (i.e., you're replacing them with new ones or rebuilding the system after getting some data off the disks, etc.), then you don't need to run mkinitrd or edit the grub.conf (or menu.lst for those using these instructions on other distros) file. 4. Disconnect the host systems drive(s), boot with a rescue CD (or PXE, etc.) and do what you need to do to the disks. > I gave up using LVM, partly because after reading it up so much, I was > still having troubles rescuing data on my failing hard drives. I think > with improved tools, it need not be so difficult. > > I'm having a lot of problems remembering just which partitions belong to > which LVM volumes and which I can format to free some partitions out. > Partition labelling support should be added to be practical. Or maybe I > should not choose a potentially hard-to-remember partitioning scheme, but > should use only one LVM per disk and not striped. The default LV names that anaconda suggests/uses are stupid. I say that because the LV names are meaningless and lead to just this problem. I have *always* named my LVs such as to indicate which part of the filesystem is on them. For example, when I create and LV for /ver/log/, I run (use whatever size you like, it's just a placeholder in this example): # lvcreate -L 256M -n varlog vg_name Entries in /etc/fstab are extremely easy to read like this. > Hope I'm not choosing any side here. I'm just hoping the experience with > LVM, especially when working at the partition level can be improved. I don't think you are. LVM is one of the coolest things there is. Many people don't understand the basics of how & why LVM is, simply because they don't know where to get the education about it. Although there is good documentation about how to use LVMs commands to get things done, but not much about how to really benefit and organize and make decisions about how to use LVM at the system level. There are only a small handful of the available LVM commands that are needed for regular stuff. They all have common consistent switches for their command lines and are very easy to use. -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lamont at gurulabs.com Fri Dec 22 19:26:38 2006 From: lamont at gurulabs.com (Lamont Peterson) Date: Fri, 22 Dec 2006 12:26:38 -0700 Subject: New device drivers don't see beyond 15 partitions in fc7 In-Reply-To: <20061222082851.GC6739@aphasia.badger.choralone.org> References: <458B115B.7060606@cox.net> <20061222082851.GC6739@aphasia.badger.choralone.org> Message-ID: <200612221226.38408.lamont@gurulabs.com> On Friday 22 December 2006 01:28am, Rob Andrews wrote: > On 21-Dec-2006 22:57.31 (GMT), Clyde E. Kunkel wrote: > > With the change from traditional /dev/hd* type device nodes to /dev/sd* > > type nodes, I see that the highest partition number that can be used is > > 15. Will this change so that higher numbers will be available? I do > > have a system that has a drive with almost 30 small partitions used in a > > research effort and the number of partitions has not been an issue thru > > fc6. > > devices.txt says that hdN device numbering supports up to 63 partitions per > disk. It also says that sdN device numbering follows the same trend as hdN > numbering (unified partition table handling, and all). > > I didn't think that PC BIOS partition tables supported > 15 partitions. To > the best of my knowledge, the 63-partition numbering scheme was there for > partition table formats that *did* support it (Amiga RDB, BSD disk label, > etc). > > To quote the fdisk(8) manual page: > > The partition is a device name followed by a partition number. > For example, /dev/hda1 is the first partition on the first IDE > hard disk in the system. Disks can have up to 15 partitions. > See also /usr/src/linux/Documentation/devices.txt. That's an old holdover. Older versions of fdisk took the lazy way out and didn't try to figure out if you had a SCSI or an IDE drive. It just went with the lowest common denominator (i.e. 15 partitions( that worked on all disks. The kernel has supported up to 63 partitions on a single IDE drive for a long time. It was the partitioning tools (most notably, fdisk) that didn't. BTW, the numbers 63 & 15 are not arbitrary. It comes from the 256 major numbers, 256 minor numbers for device nodes that kernels prior to 2.6 used. So, since you can have up to 4 drives on a single (typical) IDE controller (2 channels, one master one slave drive on each), take the 256 minor numbers for that controller and divide by 4. You get 64 minor numbers to use for partitions on that drive, however, one of them is used for the whole drive (i.e. /dev/hda) leaving 63 for partitions (i.e. /dev/hda1 -> /dev/hda63). For SCSI (and SATA, etc.), there can be a maximum of 16 devices on any SCSI bus (or channel, if you prefer that term), so 256/16 = 16. One for the whole drive (/dev/sda) and 15 for the partitions (/dev/sda1 -> /dev/sda15). Now, if you're wondering about the 16 devices on a SCSI bus, one of them will be the controller, usually at SCSI ID 7. That leave 15 SCSI IDs to assign to drives. However, faster bus speeds and longer cables both lower the total number of devices a SCSI bus can support, so the newer, better, shinier SCSI stuff doesn't support 15 drives on a single SCSI channel. > To reiterate what another writer has said, lvm is a smashing way of > working. And it has a much more flexible ("meaningful") volume naming > scheme. Only if you give LVs meaningful names. anaconda (as I've already pointed out in this thread) uses fairly useless names for LVs. For years, I always named the VGs something like vg0, since I didn't much care what that name was. Today, I name the VG the same as the machine name (this notebook is "corsair" so that's what the VG is named). -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lamont at gurulabs.com Fri Dec 22 19:34:26 2006 From: lamont at gurulabs.com (Lamont Peterson) Date: Fri, 22 Dec 2006 12:34:26 -0700 Subject: New device drivers don't see beyond 15 partitions in fc7 In-Reply-To: <20061222053121.GA22833@redhat.com> References: <458B115B.7060606@cox.net> <20061222053121.GA22833@redhat.com> Message-ID: <200612221234.26387.lamont@gurulabs.com> On Thursday 21 December 2006 10:31pm, Dave Jones wrote: > On Thu, Dec 21, 2006 at 05:57:31PM -0500, Clyde E. Kunkel wrote: > > Hello, > > > > With the change from traditional /dev/hd* type device nodes to /dev/sd* > > type nodes, I see that the highest partition number that can be used is > > 15. Will this change so that higher numbers will be available? I do > > have a system that has a drive with almost 30 small partitions used in a > > research effort and the number of partitions has not been an issue thru > > fc6. > > afaik, The only way to achieve > 15 "partitions" per disk with /dev/sd* is > to use device mapper. I'm not sure the upper limit of logical volumes per > PV, but I'm fairly sure it's higher than 15. Under LVM1 (2.4 kernel and earlier) it was 256 LVs per *system* (only one major number is used for all of LVM). The number of VGs (limited to 99, BTW) was not a factor, nor the number of PVs. Because the 32-bit device number space is split at 20 bits major and 12 bits for the minor number (have I got that right way around), I would guess that LVM2 (kernel 2.6 & later) supports a maximum of 4096 LVs per system. -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bojan at rexursive.com Fri Dec 22 21:20:17 2006 From: bojan at rexursive.com (Bojan Smojver) Date: Sat, 23 Dec 2006 08:20:17 +1100 Subject: Firefox 1.5.0.9 for FC5 in FC6 updates Message-ID: <1166822417.2947.9.camel@shrek.rexursive.com> Not sure how that package got into the repository: http://download.fedora.redhat.com/pub/fedora/linux/core/updates/6/i386/firefox-1.5.0.9-1.fc5.i386.rpm -- Bojan From andy at warmcat.com Fri Dec 22 21:48:05 2006 From: andy at warmcat.com (Andy Green) Date: Fri, 22 Dec 2006 21:48:05 +0000 Subject: LVM not fit for default In-Reply-To: <200612221215.15365.lamont@gurulabs.com> References: <458B115B.7060606@cox.net> <1166803888.27377.48.camel@gilboa-home-dev.localdomain> <6.2.1.2.2.20061222083537.48f16778@mailone.real.com> <200612221215.15365.lamont@gurulabs.com> Message-ID: <458C5295.9020805@warmcat.com> Lamont Peterson wrote: > LVM is one of the coolest things there is. Many people don't understand the > basics of how & why LVM is, simply because they don't know where to get the When LVM fails though, there are no recovery tools. You can recover the filesystem inside an LVM (I speak from experience) but your only friends are dd and a hex editor. There is no redundancy unlike genuine filesystems like ext2/3, if the LVM chunk before the actual filesystem is corrupted, the volume won't mount as LVM and that's your lot from the One True Way. LVM binding raided storage together makes sense and buys you something. LVM being the default -- even for a laptop that cannot increase its permanent storage -- only has the capacity to make a crisis into a disaster. -Andy From caillon at redhat.com Fri Dec 22 22:43:08 2006 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 22 Dec 2006 17:43:08 -0500 Subject: Firefox 1.5.0.9 for FC5 in FC6 updates In-Reply-To: <1166822417.2947.9.camel@shrek.rexursive.com> References: <1166822417.2947.9.camel@shrek.rexursive.com> Message-ID: <458C5F7C.40506@redhat.com> Bojan Smojver wrote: > Not sure how that package got into the repository: > > http://download.fedora.redhat.com/pub/fedora/linux/core/updates/6/i386/firefox-1.5.0.9-1.fc5.i386.rpm If I had a dollar[1] every time someone pointed that out to me today... It was fixed around noon and a new advisory was issued. Sorry if my goof ruined yet another person's holiday. To make it up to you, here's a picture of furry things in boxes.[2] Bah Humbug[3]. --- [1] Actually, at this point, I'd probably be rich with just a penny per incident. [2] http://mfrost.typepad.com/cute_overload/2006/12/ham_n_seek.html [3] http://tinyurl.com/y6gau5 From jeff at ocjtech.us Fri Dec 22 22:52:01 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Fri, 22 Dec 2006 16:52:01 -0600 Subject: LVM not fit for default In-Reply-To: <458C5295.9020805@warmcat.com> References: <458B115B.7060606@cox.net> <1166803888.27377.48.camel@gilboa-home-dev.localdomain> <6.2.1.2.2.20061222083537.48f16778@mailone.real.com> <200612221215.15365.lamont@gurulabs.com> <458C5295.9020805@warmcat.com> Message-ID: <1166827921.3952.4.camel@lt21223.campus.dmacc.edu> On Fri, 2006-12-22 at 21:48 +0000, Andy Green wrote: > > When LVM fails though, there are no recovery tools. You can recover the > filesystem inside an LVM (I speak from experience) but your only friends > are dd and a hex editor. There is no redundancy unlike genuine > filesystems like ext2/3, if the LVM chunk before the actual filesystem > is corrupted, the volume won't mount as LVM and that's your lot from the > One True Way. And you could have set your laptop on top of a tape degausser. You have been making regular backups haven't you? Jeff -------------- 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 gilboad at gmail.com Fri Dec 22 22:51:23 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 23 Dec 2006 00:51:23 +0200 Subject: LVM not fit for Fedora Core In-Reply-To: <458C0E6A.1080400@BitWagon.com> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458BFEE3.9060601@BitWagon.com> <200612221105.17838.jkeating@redhat.com> <458C0E6A.1080400@BitWagon.com> Message-ID: <1166827883.16457.19.camel@gilboa-home-dev.localdomain> On Fri, 2006-12-22 at 08:57 -0800, John Reiser wrote: > Jesse Keating wrote: > > On Friday 22 December 2006 10:50, John Reiser wrote: > > > >>Using the rescue CDs is a nightmare under LVM: the LVM > >>setup is not recognized automatically > > > > > > I call BS. I test the rescueCD quite a lot during development process, and it > > _always_ find the LVM and sets it up automatically. > > Didn't work for me in March 2006 on x86_64 using a then-reasonbly-current > rescue CD (probably a couple months old). Bugzilla #? - Gilboa From gilboad at gmail.com Fri Dec 22 22:52:53 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 23 Dec 2006 00:52:53 +0200 Subject: LVM not fit for Fedora Core In-Reply-To: <458C16C2.8080400@BitWagon.com> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458BFEE3.9060601@BitWagon.com> <1166803888.27377.48.camel@gilboa-home-dev.localdomain> <458C16C2.8080400@BitWagon.com> Message-ID: <1166827973.16457.22.camel@gilboa-home-dev.localdomain> On Fri, 2006-12-22 at 09:32 -0800, John Reiser wrote: > Gilboa Davara wrote: > > On Fri, 2006-12-22 at 07:50 -0800, John Reiser wrote: > > > >>Gilboa Davara wrote: > >> > >> > >>>Use LVM. > >>>Trust me. > >>>You won't be sorry. > >> > >>I've been there, done that, and regretted it deeply. > >>I got rid of LVM the first chance I could. > >> > >>LVM does not inter-operate with anything else. > >>Grub does not work under LVM. > > > > > > Why should it? > > Why shouldn't it? LVM is touted as "the solution" to restrictions > on disk partitioning. Except that LVM doesn't work for the first > logical access to disk partitions: booting. No you are wrong. -grub- doesn't support LVM. (Same goes for xfs, reiserfs and at least 95 other file systems) > > > > HUH? > > Why-on-earth-would-you-want-to-do-that? > > To interoperate with the rest of the world, such as other > operating systems, even other distributions of Linux, > that understand DOS partition tables but not LVM. > If you don't have infinitely many boxes then it is useful > to be able to "compromise". If you remove Linux from the equation. Does Windows support ZFS-lvm? Does Solaris support dynamic disks? What OSs are you talk about exactly? As for other distributions... well, on my old workstation I had Slackware, Debian, Fedora and CentOS all sharing the same LVM. If you favorite distro doesn't support LVM, you have a very, very, old distro. > > > > > > >>Using the rescue CDs is a nightmare under LVM: the LVM > >>setup is not recognized automatically (you must remember > >>what it is) and the rescue environment contains no help > >>or documentation on LVM (such as: the _syntax_ for naming > >>the pieces!) > > > > > > I can agree that Feodra documentation on the subject is... missing. > > A. TLDP has an excellent on-line documentation. [1] > > B. system-config-lvm is improvement constantly. > > C. Documentation missing? Join the documentation team and help them fix > > it. > > "Get off the bus one stop before I do." I didn't recognize that > LVM documentation was missing from the rescue CD until I needed it > but it wasn't there. As I said, TDLP has a very comprehensive LVM documentation. Last time I checked, it was the first google result to LVM howto. > Data longevity is not the strong suit of RHEL/Fedora Core/Linux. > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=137068 Now you're just trolling. > _You_ strongly advocated LVM and suggested "You won't be sorry" > without any disclaimers. I'm supplying some of the omissions. No you're not. Out of your initial post, only two items stand: A. Documentation is missing. (You'll have to open google - oh my God!) B. Hardware failure will require manual intervention. (Though in 3 years and countless hardware crashes, I only had to manually mount lvm once, and even this was caused by a broken software RAID) The rest of your post(s) were pure senseless ranting. (Especially the BZ#) BTW, if you consider Fedora/RHEL to be an unstable junk, -why- are you here? - Gilboa From alain.portal at free.fr Fri Dec 22 23:18:08 2006 From: alain.portal at free.fr (Alain PORTAL) Date: Sat, 23 Dec 2006 00:18:08 +0100 Subject: [offtopic] Ignacio Vazquez-Abrams In-Reply-To: References: <16de708d0608282246x7b7a1eabi89e782f085efe636@mail.gmail.com> <16de708d0612220054h59fcd7f4u7b3182a095e531ae@mail.gmail.com> Message-ID: <200612230018.09567.alain.portal@free.fr> Le vendredi 22 d?cembre 2006 17:42, Konstantin Ryabitsev a ?crit : > There you have it, folks. Let's hope he's just been busy with life, > since we have no reason to believe otherwise. Unfortuntely, I'm not agree with you... As Ignacio was a big contributor in Fedora, I think that if he was busy in life, he would have told us "I'm busy and I can't contribute any more for the moment" and he disappeared without telling us anything. So, I think we have to expect the worst... Sorry. If someboby could investigate far.... -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kevin.kofler at chello.at Fri Dec 22 23:26:29 2006 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 Dec 2006 23:26:29 +0000 (UTC) Subject: Announcing the Fedora 6 Zod live CD and live CD tools References: <1166812366.2752.99.camel@zelda.fubar.dk> <16de708d0612221039w793cb950w14160a41d04182aa@mail.gmail.com> <1166813284.2752.106.camel@zelda.fubar.dk> Message-ID: David Zeuthen redhat.com> writes: > Certainly and I, for one, would be happy to see someone step up and do > live cd flavors for KDE and heck, also Eclipse, Music, Games and the > other SIG's in the Fedora Universe. What about a live DVD with all of the above? FedoraUnity's unofficial "live spins" also have a DVD version, and that allows them to include both GNOME and KDE, as well as other stuff. Kevin Kofler From benjy.grogan at gmail.com Sat Dec 23 00:28:20 2006 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Fri, 22 Dec 2006 19:28:20 -0500 Subject: [offtopic] Ignacio Vazquez-Abrams In-Reply-To: <200612230018.09567.alain.portal@free.fr> References: <16de708d0608282246x7b7a1eabi89e782f085efe636@mail.gmail.com> <16de708d0612220054h59fcd7f4u7b3182a095e531ae@mail.gmail.com> <200612230018.09567.alain.portal@free.fr> Message-ID: On 12/22/06, Alain PORTAL wrote: > Le vendredi 22 d?cembre 2006 17:42, Konstantin Ryabitsev a ?crit : > > > There you have it, folks. Let's hope he's just been busy with life, > > since we have no reason to believe otherwise. > > Unfortuntely, I'm not agree with you... > As Ignacio was a big contributor in Fedora, I think that if he was busy in > life, he would have told us "I'm busy and I can't contribute any more for the > moment" and he disappeared without telling us anything. > So, I think we have to expect the worst... Sorry. > > If someboby could investigate far.... Perhaps someone should sum up his contributions and give him thanks in the next Fedora Weekly News? Who was he, how he made a difference, and what finally happened to him. Benjy > > -- > Les pages de manuel Linux en fran?ais > http://manpagesfr.free.fr/ > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > From jon.nettleton at gmail.com Sat Dec 23 02:26:32 2006 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Fri, 22 Dec 2006 21:26:32 -0500 Subject: [offtopic] Ignacio Vazquez-Abrams In-Reply-To: References: <16de708d0608282246x7b7a1eabi89e782f085efe636@mail.gmail.com> <16de708d0612220054h59fcd7f4u7b3182a095e531ae@mail.gmail.com> Message-ID: <1166840792.2463.1.camel@averatec> On Fri, 2006-12-22 at 11:42 -0500, Konstantin Ryabitsev wrote: > On 12/22/06, Arthur Pemberton wrote: > > Is it safe to say that this guy has gone to a better place? Even his > > domain has expired now. > > I've done some investigative work, but I'm afraid unless he announces > himself, we won't be able to find anything out. > > I've used the whitepages to look up his last known address, and then > called a few neighbours on the same street. It seems that the house > was owned by someone else, who was renting out an apartment -- I'm > guessing Ignacio was their tenant. According to one of the neighbours, > earlier this year the house went for sale, and the old owner moved > elsewhere -- Ignacio probably also had to move at that point. > > Sadly, that's where the trail ends. I called the Bampton police > department, but they have no records for Ignacio Vazquez-Abrams, so if > anything happened to him, it must have happened outside of Brampton. I > guess we can call the Toronto police department, but I doubt they > would be as helpful as Brampton's. > > There you have it, folks. Let's hope he's just been busy with life, > since we have no reason to believe otherwise. > > Cheers, > -- > Konstantin Ryabitsev > Montr?al, Qu?bec > Has anyone tried to snail mail his last known mailing address? He might be having his mail forwarded. Just a thought. Jon From mattdm at mattdm.org Sat Dec 23 03:52:40 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 22 Dec 2006 22:52:40 -0500 Subject: [offtopic] Ignacio Vazquez-Abrams In-Reply-To: <200612230018.09567.alain.portal@free.fr> References: <16de708d0608282246x7b7a1eabi89e782f085efe636@mail.gmail.com> <16de708d0612220054h59fcd7f4u7b3182a095e531ae@mail.gmail.com> <200612230018.09567.alain.portal@free.fr> Message-ID: <20061223035240.GA26889@jadzia.bu.edu> On Sat, Dec 23, 2006 at 12:18:08AM +0100, Alain PORTAL wrote: > > There you have it, folks. Let's hope he's just been busy with life, > > since we have no reason to believe otherwise. > Unfortuntely, I'm not agree with you... > As Ignacio was a big contributor in Fedora, I think that if he was busy in > life, he would have told us "I'm busy and I can't contribute any more for the > moment" and he disappeared without telling us anything. > So, I think we have to expect the worst... Sorry. Plus, he let his personal-name domain name expire. That's surprising behavior from anyone geeky enough to be that big of a contributor to Fedora. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From seg at haxxed.com Sat Dec 23 10:13:06 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 23 Dec 2006 04:13:06 -0600 Subject: Development machine setup for both i386 and x86_64 work In-Reply-To: <6.2.1.2.2.20061222004303.462804b0@mailone.real.com> References: <6.2.1.2.2.20061222004303.462804b0@mailone.real.com> Message-ID: <1166868786.16008.2.camel@max.booze> On Fri, 2006-12-22 at 01:13 -0800, Daniel Yek wrote: > Hi, > > How Fedora developers set up dev. machines to do both 32-bit and 64-bit > development on a single AMD64 machine? > > Does it complicate 32-bit dev. work if the development machine is set up > with x86_64 Fedora Core OS? I just compile for i386 using mock. Works great, assuming you obsessively RPM package everything you deploy to other machines like I do. :) -------------- 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 seg at haxxed.com Sat Dec 23 10:26:04 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 23 Dec 2006 04:26:04 -0600 Subject: LVM not fit for Fedora Core In-Reply-To: <458C0E6A.1080400@BitWagon.com> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458BFEE3.9060601@BitWagon.com> <200612221105.17838.jkeating@redhat.com> <458C0E6A.1080400@BitWagon.com> Message-ID: <1166869564.16008.12.camel@max.booze> On Fri, 2006-12-22 at 08:57 -0800, John Reiser wrote: > > I call BS. I test the rescueCD quite a lot during development process, and it > > _always_ find the LVM and sets it up automatically. > > Didn't work for me in March 2006 on x86_64 using a then-reasonbly-current > rescue CD (probably a couple months old). Even when it doesn't: lvm vgchange -a y And all your VGs should appear. Now if only enabling !@#$ RAID were as easy. Also, renaming a VG is a total bitch if you're booting from it. The name seems to get hardwired into the inird. And... changing that is such an arcane ritual I'm not going to go into it. ... Unless I've missed something. Naming your VGs after the hostname maybe isn't such a great idea. -------------- 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 andy at warmcat.com Sat Dec 23 10:35:52 2006 From: andy at warmcat.com (Andy Green) Date: Sat, 23 Dec 2006 10:35:52 +0000 Subject: LVM not fit for default In-Reply-To: <1166827921.3952.4.camel@lt21223.campus.dmacc.edu> References: <458B115B.7060606@cox.net> <1166803888.27377.48.camel@gilboa-home-dev.localdomain> <6.2.1.2.2.20061222083537.48f16778@mailone.real.com> <200612221215.15365.lamont@gurulabs.com> <458C5295.9020805@warmcat.com> <1166827921.3952.4.camel@lt21223.campus.dmacc.edu> Message-ID: <458D0688.4020502@warmcat.com> Jeffrey C. Ollie wrote: > On Fri, 2006-12-22 at 21:48 +0000, Andy Green wrote: >> When LVM fails though, there are no recovery tools. You can recover the >> filesystem inside an LVM (I speak from experience) but your only friends >> are dd and a hex editor. There is no redundancy unlike genuine >> filesystems like ext2/3, if the LVM chunk before the actual filesystem >> is corrupted, the volume won't mount as LVM and that's your lot from the >> One True Way. > > And you could have set your laptop on top of a tape degausser. You have > been making regular backups haven't you? I had a backup a week old, but that doesn't excuse LVM from *escalating a lost sector into a lost filesystem*. Why ask me about my personal disaster recovery when we talk about taking action to minimize the chance of disaster for the whole class of storage? When LVM is inflicted on to situations that cannot benefit from it, the end result is you made something more fragile for no gain: that can't be right. -Andy From buildsys at redhat.com Sat Dec 23 11:02:56 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 23 Dec 2006 06:02:56 -0500 Subject: rawhide report: 20061223 changes Message-ID: <200612231102.kBNB2u8i019620@hs20-bc2-6.build.redhat.com> Updated Packages: devhelp-0.12-10.fc7 ------------------- * Thu Dec 21 2006 Christopher Aillon 0.12-10 - Rebuild against newer gecko epiphany-2.17.4-2.fc7 --------------------- * Thu Dec 21 2006 Christopher Aillon 2.17.4-2 - Rebuild against newer gecko firefox-2.0.0.1-2.fc7 --------------------- * Fri Dec 22 2006 Christopher Aillon 2.0.0.1-2 - Strip out some frequent warnings; they muddy up the build output * Thu Dec 21 2006 Christopher Aillon 2.0.0.1-1 - Update to 2001 frysk-0.0.1.2006.12.22.rh1-1.fc7 -------------------------------- * Tue Dec 19 2006 Stepan Kasal - 0.0.1.2006.12.22.rh1-1 - New upstream version. - libexecdir -> libdir and other file list updates - Remove frysk-arch32-disable.patch, use --disable-arch32-tests instead. - Add frysk-no-dejagnu.patch and create $RPM_BUILD_ROOT/${pkgdatadir}, to work around a bug in install-dejagnu-testsuite-local rule. - Resolves: #218819 * Tue Dec 19 2006 Stepan Kasal - 0.0.1.2006.12.01.rh1-4 - Add frysk-20061201-i386_is_not_64bit.patch - Related: #218835 * Tue Dec 19 2006 Stepan Kasal - 0.0.1.2006.12.01.rh1-3 - Use libexecdir with the old version. - Related: #218835 libsemanage-1.9.1-3.fc7 ----------------------- * Fri Dec 22 2006 Dan Walsh - 1.9.1-3 - Apply Karl MacMillan patch to get proper error codes. selinux-policy-2.4.6-17.fc7 --------------------------- * Fri Dec 22 2006 Dan Walsh 2.4.6-17 - Fix to allow ftp to bind to ports > 1024 Resolves: #219349 system-config-kickstart-2.7.0-1.fc7 ----------------------------------- * Fri Dec 22 2006 Chris Lumens 2.7.0-1 - Use system-config-securitylevel to provide the firewall page. - Speed up startup and shutdown. - If package selection is disabled, don't forget whatever was in the original kickstart file (#217165). system-config-securitylevel-1.6.30-1.fc7 ---------------------------------------- * Fri Dec 22 2006 Chris Lumens 1.6.30-1 - Reorganize code to be more useful as a library. - Allow changing the SELinux setting from text mode (#217767). yelp-2.16.2-2.fc7 ----------------- * Thu Dec 21 2006 Christopher Aillon 2.16.2-2 - Rebuild against newer gecko ypserv-2.19-4.fc7 ----------------- * Fri Dec 22 2006 Steve Dickson - 2.19-4 - Made ypserver less verbose on common errors (bz #199236) - Don't allow a make for empty domainname's or domainname's set to (none) (bz #197646) Broken deps for i386 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 Broken deps for ppc64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) Broken deps for x86_64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) Broken deps for s390 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ppc ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 Broken deps for ia64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) Broken deps for s390x ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) From seg at haxxed.com Sat Dec 23 11:18:24 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 23 Dec 2006 05:18:24 -0600 Subject: LVM not fit for default In-Reply-To: <458D0688.4020502@warmcat.com> References: <458B115B.7060606@cox.net> <1166803888.27377.48.camel@gilboa-home-dev.localdomain> <6.2.1.2.2.20061222083537.48f16778@mailone.real.com> <200612221215.15365.lamont@gurulabs.com> <458C5295.9020805@warmcat.com> <1166827921.3952.4.camel@lt21223.campus.dmacc.edu> <458D0688.4020502@warmcat.com> Message-ID: <1166872705.16008.47.camel@max.booze> On Sat, 2006-12-23 at 10:35 +0000, Andy Green wrote: > Jeffrey C. Ollie wrote: > > On Fri, 2006-12-22 at 21:48 +0000, Andy Green wrote: > >> When LVM fails though, there are no recovery tools. You can recover the > >> filesystem inside an LVM (I speak from experience) but your only friends > >> are dd and a hex editor. There is no redundancy unlike genuine > >> filesystems like ext2/3, if the LVM chunk before the actual filesystem > >> is corrupted, the volume won't mount as LVM and that's your lot from the > >> One True Way. > > > > And you could have set your laptop on top of a tape degausser. You have > > been making regular backups haven't you? > > I had a backup a week old, but that doesn't excuse LVM from *escalating > a lost sector into a lost filesystem*. Why ask me about my personal > disaster recovery when we talk about taking action to minimize the > chance of disaster for the whole class of storage? > > When LVM is inflicted on to situations that cannot benefit from it, the > end result is you made something more fragile for no gain: that can't be > right. Every PV keeps duplicate copies of the metadata by default. You can optionally make it store three. Two at the start, one at the end. And every PV in a VG has a copy of the metadata as well. So with two PVs that's four copies of the metadata by default, and optionally 6. ... And backing up your LVM metadata to your /boot partition isn't a bad idea either. As well as an offline backup. So I have 11 copies of my LVM metadata. That seems rather redundant to me. -------------- 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 andy at warmcat.com Sat Dec 23 13:24:19 2006 From: andy at warmcat.com (Andy Green) Date: Sat, 23 Dec 2006 13:24:19 +0000 Subject: LVM not fit for default In-Reply-To: <1166872705.16008.47.camel@max.booze> References: <458B115B.7060606@cox.net> <1166803888.27377.48.camel@gilboa-home-dev.localdomain> <6.2.1.2.2.20061222083537.48f16778@mailone.real.com> <200612221215.15365.lamont@gurulabs.com> <458C5295.9020805@warmcat.com> <1166827921.3952.4.camel@lt21223.campus.dmacc.edu> <458D0688.4020502@warmcat.com> <1166872705.16008.47.camel@max.booze> Message-ID: <458D2E03.6090804@warmcat.com> Callum Lerwick wrote: >> When LVM is inflicted on to situations that cannot benefit from it, the >> end result is you made something more fragile for no gain: that can't be >> right. > > Every PV keeps duplicate copies of the metadata by default. You can > optionally make it store three. Two at the start, one at the end. And > every PV in a VG has a copy of the metadata as well. So with two PVs > that's four copies of the metadata by default, and optionally 6. > > ... And backing up your LVM metadata to your /boot partition isn't a bad > idea either. As well as an offline backup. > > So I have 11 copies of my LVM metadata. That seems rather redundant to > me. Sounds impressive, but the LVM that was damaged here was not visible nor mountable in Fedora, although the filesystem behind it was mostly intact and mounted okay when I had a copy of it without the LVM stuff in front of it. Googling at the time didn't bring up anything about how to use these proposed copied of "metadata" nor was anything done about them or mentioned about them by the LVM stuff in Fedora, nor have I heard about LVM metadata before today. All the damaged LVM header had for me was to hide my mostly intact filesystem from being fsck'd or mounted. Further, you are full of care to have 11 copies of something you don't even need in, say, a laptop usage case, in case it breaks (because if it does break, you experience the truth of what I previously related about not being able to get at your filesystem). This looks like a pointless and dangerous burden to place on someone who is getting nothing from having LVM there in the first place. LVM on raid can make sense, in other common usage cases it is only a net risk. -Andy From leomon.chris at gmail.com Sat Dec 23 14:45:00 2006 From: leomon.chris at gmail.com (Christopher Rutherford) Date: Sat, 23 Dec 2006 09:45:00 -0500 Subject: LVM not fit for default In-Reply-To: <458D2E03.6090804@warmcat.com> References: <458B115B.7060606@cox.net> <1166803888.27377.48.camel@gilboa-home-dev.localdomain> <6.2.1.2.2.20061222083537.48f16778@mailone.real.com> <200612221215.15365.lamont@gurulabs.com> <458C5295.9020805@warmcat.com> <1166827921.3952.4.camel@lt21223.campus.dmacc.edu> <458D0688.4020502@warmcat.com> <1166872705.16008.47.camel@max.booze> <458D2E03.6090804@warmcat.com> Message-ID: <77FAA761-5839-499B-9269-087008CB53D8@gmail.com> Personally I agree with Andy in what he's said before on the part of LVM. First of all I have experienced the same "no help hell" with lvm when it crashes. (not if, when) I had FC3 installed on my Compaq R3000 Series notebook, default settings, except for package options. Ran that for about three weeks. I reinstall testing out new distros quite a lot, so I don't worry about backing up the entire system, and something happened with the system, the kernel panicked when it couldn't find a root FS. Same problem as andy. Basically All I'm trying to say is that yes it fails sometime, no it is a cool thing to have, but either give us some tools on default install/rescue disc to combat the issue, or take it out unless the system detects a RAID array. Thanks guys, Chris On Dec 23, 2006, at 8:24 AM, Andy Green wrote: > Callum Lerwick wrote: > >>> When LVM is inflicted on to situations that cannot benefit from >>> it, the end result is you made something more fragile for no >>> gain: that can't be right. >> Every PV keeps duplicate copies of the metadata by default. You can >> optionally make it store three. Two at the start, one at the end. And >> every PV in a VG has a copy of the metadata as well. So with two PVs >> that's four copies of the metadata by default, and optionally 6. >> ... And backing up your LVM metadata to your /boot partition isn't >> a bad >> idea either. As well as an offline backup. >> So I have 11 copies of my LVM metadata. That seems rather >> redundant to >> me. > > Sounds impressive, but the LVM that was damaged here was not > visible nor mountable in Fedora, although the filesystem behind it > was mostly intact and mounted okay when I had a copy of it without > the LVM stuff in front of it. Googling at the time didn't bring up > anything about how to use these proposed copied of "metadata" nor > was anything done about them or mentioned about them by the LVM > stuff in Fedora, nor have I heard about LVM metadata before today. > All the damaged LVM header had for me was to hide my mostly intact > filesystem from being fsck'd or mounted. > > Further, you are full of care to have 11 copies of something you > don't even need in, say, a laptop usage case, in case it breaks > (because if it does break, you experience the truth of what I > previously related about not being able to get at your > filesystem). This looks like a pointless and dangerous burden to > place on someone who is getting nothing from having LVM there in > the first place. LVM on raid can make sense, in other common usage > cases it is only a net risk. > > -Andy > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From rob at choralone.org Sat Dec 23 15:07:01 2006 From: rob at choralone.org (Rob Andrews) Date: Sat, 23 Dec 2006 15:07:01 +0000 Subject: LVM not fit for Fedora Core In-Reply-To: <458BFEE3.9060601@BitWagon.com> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458BFEE3.9060601@BitWagon.com> Message-ID: <20061223150701.GA14706@aphasia.badger.choralone.org> On 22-Dec-2006 15:50.59 (GMT), John Reiser wrote: > LVM does not inter-operate with anything else. > Grub does not work under LVM. That's why you have a boot partition to load the kernel and initrd from. The installer outlines this when you install. And the kernels always get put into the /boot partition so they are accessible from grub. > Parted does not grok LVM: > you cannot create a hard partition from LVM free space. No, of course you can't. But you seem to be speaking from an interoperability perspective: If you dedicate an area of disk to a Linux logical volume manager, you don't expect to have the space available for whatever other operating systems you have on your computer. And remember, not everyone dual boots. > Using the rescue CDs is a nightmare under LVM: the LVM > setup is not recognized automatically (you must remember > what it is) and the rescue environment contains no help > or documentation on LVM (such as: the _syntax_ for naming > the pieces!) It's really simple: lvm vgchange -a y And that's all. > LVM probably kills all low-level backup and recovery. "Probably" does not make for a good argument. -- rob andrews :: pgp 0x01e00563 :: rob at choralone.org From cra at WPI.EDU Sat Dec 23 16:00:16 2006 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 23 Dec 2006 11:00:16 -0500 Subject: LVM not fit for Fedora Core In-Reply-To: <1166869564.16008.12.camel@max.booze> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458BFEE3.9060601@BitWagon.com> <200612221105.17838.jkeating@redhat.com> <458C0E6A.1080400@BitWagon.com> <1166869564.16008.12.camel@max.booze> Message-ID: <20061223160016.GA4424@angus.ind.WPI.EDU> On Sat, Dec 23, 2006 at 04:26:04AM -0600, Callum Lerwick wrote: > Also, renaming a VG is a total bitch if you're booting from it. The name > seems to get hardwired into the inird. And... changing that is such an > arcane ritual I'm not going to go into it. > > ... Unless I've missed something. Naming your VGs after the hostname > maybe isn't such a great idea. After being bitten with the duplicate VG name thing, I think the installer should assign a random UUID-like name to VGs. From jkeating at redhat.com Sat Dec 23 18:00:51 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 23 Dec 2006 13:00:51 -0500 Subject: Announcing the Fedora 6 Zod live CD and live CD tools In-Reply-To: References: <1166812366.2752.99.camel@zelda.fubar.dk> <1166813284.2752.106.camel@zelda.fubar.dk> Message-ID: <200612231300.55543.jkeating@redhat.com> On Friday 22 December 2006 18:26, Kevin Kofler wrote: > What about a live DVD with all of the above? FedoraUnity's unofficial "live > spins" also have a DVD version, and that allows them to include both GNOME > and KDE, as well as other stuff. This may fall out for F7, however we wanted to get something out for FC6 before the holiday break. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sat Dec 23 18:01:36 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 23 Dec 2006 13:01:36 -0500 Subject: Firefox 1.5.0.9 for FC5 in FC6 updates In-Reply-To: <1166822417.2947.9.camel@shrek.rexursive.com> References: <1166822417.2947.9.camel@shrek.rexursive.com> Message-ID: <200612231301.36834.jkeating@redhat.com> On Friday 22 December 2006 16:20, Bojan Smojver wrote: > Not sure how that package got into the repository: > > http://download.fedora.redhat.com/pub/fedora/linux/core/updates/6/i386/fire >fox-1.5.0.9-1.fc5.i386.rpm A comedy of errors, that causes 0 harm. Should be taken care of soon. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From angray at beeb.net Sat Dec 23 22:26:28 2006 From: angray at beeb.net (Aaron Gray) Date: Sat, 23 Dec 2006 22:26:28 -0000 Subject: FC-6-i386-livecd-1.iso boot sequence errors Message-ID: <010f01c726e1$641f52e0$0200a8c0@AMD2500> Hello, Got two different errors in startup sequence. The following error repeated about 12 times in boot up sequence :- Illegal mode for this track or incomplete medium The failed "Read 10" packet command was: Buffer I/O error on device hdd, logical block xxxxxx The CD was verified after writing, and SHA checked. Then later in boot up sequence we have :- Starting system message bus: Unknown group "netdev" in message bus configuration file Though I should report these to the list. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From giallu at gmail.com Sat Dec 23 22:32:47 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Sat, 23 Dec 2006 23:32:47 +0100 Subject: FC-6-i386-livecd-1.iso boot sequence errors In-Reply-To: <010f01c726e1$641f52e0$0200a8c0@AMD2500> References: <010f01c726e1$641f52e0$0200a8c0@AMD2500> Message-ID: On 12/23/06, Aaron Gray wrote: > Then later in boot up sequence we have :- > > Starting system message bus: Unknown group "netdev" in message bus > configuration file > I am also seeing this one, but with a regular installation in my laptop. Is it something worth a BZ ticket? From angray at beeb.net Sat Dec 23 22:48:28 2006 From: angray at beeb.net (Aaron Gray) Date: Sat, 23 Dec 2006 22:48:28 -0000 Subject: FC-6-i386-livecd-1.iso boot sequence errors References: <010f01c726e1$641f52e0$0200a8c0@AMD2500> Message-ID: <011601c726e4$7683b310$0200a8c0@AMD2500> >> Then later in boot up sequence we have :- >> >> Starting system message bus: Unknown group "netdev" in message bus >> configuration file >> > > I am also seeing this one, but with a regular installation in my > laptop. AFAICT I am not getting it in FC6 on the same system as I ran the live CD. What release are you running ? >Is it something worth a BZ ticket? Um, not yet, let more experienced people comment and possibly check it out first. Aaron From michael.wiktowy at gmail.com Sun Dec 24 05:24:47 2006 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Sun, 24 Dec 2006 00:24:47 -0500 Subject: FC-6-i386-livecd-1.iso boot sequence errors In-Reply-To: <011601c726e4$7683b310$0200a8c0@AMD2500> References: <010f01c726e1$641f52e0$0200a8c0@AMD2500> <011601c726e4$7683b310$0200a8c0@AMD2500> Message-ID: <3e4ec4600612232124r7f4a46bfv9d982b0f874b34f1@mail.gmail.com> On 12/23/06, Aaron Gray wrote: > >> Then later in boot up sequence we have :- > >> > >> Starting system message bus: Unknown group "netdev" in message bus > >> configuration file > >> > > > > I am also seeing this one, but with a regular installation in my > > laptop. > > AFAICT I am not getting it in FC6 on the same system as I ran the live CD. > > What release are you running ? > > >Is it something worth a BZ ticket? > > Um, not yet, let more experienced people comment and possibly check it out > first. > > Aaron I just end up getting the grub command line on this system. I haven't entered the manual commands to boot to get further or checked the SHA1SUM or tried it on other systems yet though. /Mike From buildsys at redhat.com Sun Dec 24 11:14:42 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sun, 24 Dec 2006 06:14:42 -0500 Subject: rawhide report: 20061224 changes Message-ID: <200612241114.kBOBEg2d014269@hs20-bc2-6.build.redhat.com> Updated Packages: binutils-2.17.50.0.8-2 ---------------------- * Sat Dec 23 2006 Jakub Jelinek 2.17.50.0.8-2 - fix --as-needed on ppc64 (#219629) cairo-1.3.10-1.fc7 ------------------ * Sat Dec 23 2006 Carl Worth 1.3.10-1 - Update to 1.3.10 * Thu Dec 14 2006 Carl Worth 1.3.8-1 - Update to 1.3.8 * Sat Dec 09 2006 Matthias Clasen 1.3.6-2 - Small spec file cleanups gdb-6.5-21.fc7 -------------- * Sat Dec 23 2006 Jan Kratochvil - 6.5-21 - Try to reduce sideeffects of skipping ppc .so libs trampolines (BZ 218379). - Fix lockup on trampoline vs. its function lookup; unreproducible (BZ 218379). thunderbird-1.5.0.9-5.fc7 ------------------------- * Thu Dec 21 2006 Behdad Esfahbod 1.5.0.9-5 - Added firefox-1.5-pango-underline.patch * Wed Dec 20 2006 Behdad Esfahbod 1.5.0.9-4 - Added firefox-1.5-pango-justified-range.patch * Tue Dec 19 2006 Behdad Esfahbod 1.5.0.9-3 - Added firefox-1.5-pango-cursor-position-more.patch Broken deps for ppc64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) Broken deps for i386 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 Broken deps for s390 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for x86_64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) Broken deps for ia64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) Broken deps for ppc ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 Broken deps for s390x ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) From jfrieben at gmx.de Sun Dec 24 11:22:33 2006 From: jfrieben at gmx.de (Joachim Frieben) Date: Sun, 24 Dec 2006 12:22:33 +0100 Subject: LVM not fit for default In-Reply-To: <77FAA761-5839-499B-9269-087008CB53D8@gmail.com> References: <458B115B.7060606@cox.net> <1166803888.27377.48.camel@gilboa-home-dev.localdomain> <6.2.1.2.2.20061222083537.48f16778@mailone.real.com> <200612221215.15365.lamont@gurulabs.com> <458C5295.9020805@warmcat.com> <1166827921.3952.4.camel@lt21223.campus.dmacc.edu> <458D0688.4020502@warmcat.com> <1166872705.16008.47.camel@max.booze> <458D2E03.6090804@warmcat.com> <77FAA761-5839-499B-9269-087008CB53D8@gmail.com> Message-ID: <20061224112233.21380@gmx.net> > First of all I have experienced the same "no help hell" with lvm when > it crashes. (not if, when) I had FC3 installed on my Compaq R3000 > Series notebook, default settings, except for package options. Ran > that for about three weeks. I reinstall testing out new distros quite > a lot, so I don't worry about backing up the entire system, and > something happened with the system, the kernel panicked when it > couldn't find a root FS. Same problem as andy. > > Basically All I'm trying to say is that yes it fails sometime, no it > is a cool thing to have, but either give us some tools on default > install/rescue disc to combat the issue, or take it out unless the > system detects a RAID array. > > Thanks guys, > > Chris Come on, "FC3" got released *three*years* ago, so it's not appropriate to make an argument out of this for discussing today's maturity of "LVM". Btw, I have been using "LVM" exclusively for 3 years now [exact, since I first installed "FC3"], and I have never ever had any trouble with it at all. Maybe you encountered a hardware problem? -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From rafael.espindola at gmail.com Sun Dec 24 14:46:31 2006 From: rafael.espindola at gmail.com (=?UTF-8?Q?Rafael_Esp=C3=ADndola?=) Date: Sun, 24 Dec 2006 12:46:31 -0200 Subject: packet writing Message-ID: <564d96fb0612240646mfa9f5b9q5703b0a7c1c5ba6c@mail.gmail.com> Fedora 6 has a very minimal support for packet writing. I was able to use it, but I had to run pktsetup and mount manually. Debian has an init script that runs pktsetup for each cd rw driver. The list of cd rw drivers is read from a config file. It should be easy to port this script, but I think that we can do better. I am planning to write an udev rule to run pktsetup every time check-cdrom.sh detects a cd-rw or a dvd-rw. Do you think that it would be a good thing to do? Best Regards, Rafael From sertac.liste at gmail.com Sun Dec 24 15:37:38 2006 From: sertac.liste at gmail.com (=?utf-8?B?U2VydGHDpyDDli4gWcSxbGTEsXo=?=) Date: Sun, 24 Dec 2006 17:37:38 +0200 Subject: FC-6-i386-livecd-1.iso boot sequence errors In-Reply-To: References: <010f01c726e1$641f52e0$0200a8c0@AMD2500> Message-ID: <20061224153738.GA3550@kerouac> * [23.Ara.06 23:32 +0100] Gianluca Sforna: > On 12/23/06, Aaron Gray wrote: > >Then later in boot up sequence we have :- > > > > Starting system message bus: Unknown group "netdev" in message bus > >configuration file > > I am also seeing this one, but with a regular installation in my > laptop. Is it something worth a BZ ticket? This is caused by the avahi package. Since I?m not using that service, this fixes the error message on dbus startup for me: # mv /etc/dbus-1/system.d/avahi-dbus.conf{,.broken} Or you can try adding a netdev group? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219218 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219269 -- ~serta? From dominik at greysector.net Sun Dec 24 16:08:51 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 24 Dec 2006 17:08:51 +0100 Subject: packet writing In-Reply-To: <564d96fb0612240646mfa9f5b9q5703b0a7c1c5ba6c@mail.gmail.com> References: <564d96fb0612240646mfa9f5b9q5703b0a7c1c5ba6c@mail.gmail.com> Message-ID: <20061224160851.GB32361@ryvius.pekin.waw.pl> On Sunday, 24 December 2006 at 15:46, Rafael Esp?ndola wrote: > Fedora 6 has a very minimal support for packet writing. I was able to > use it, but I had to run pktsetup and mount manually. > > Debian has an init script that runs pktsetup for each cd rw driver. > The list of cd rw drivers is read from a config file. > > It should be easy to port this script, but I think that we can do > better. I am planning to write an udev rule to run pktsetup every time > check-cdrom.sh detects a cd-rw or a dvd-rw. Do you think that it would > be a good thing to do? +1 This will be most useful. After all, UDF-formatted RW media was supposed to be used like any removable RW storage device, so it should be as easy to use, as, for example, a USB stick. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dyek at real.com Sun Dec 24 16:26:58 2006 From: dyek at real.com (Daniel Yek) Date: Sun, 24 Dec 2006 08:26:58 -0800 Subject: LVM not fit for Fedora Core In-Reply-To: <200612221215.15365.lamont@gurulabs.com> References: <458B115B.7060606@cox.net> <1166803888.27377.48.camel@gilboa-home-dev.localdomain> <6.2.1.2.2.20061222083537.48f16778@mailone.real.com> <200612221215.15365.lamont@gurulabs.com> Message-ID: <6.2.1.2.2.20061224081841.06dfbf58@mailone.real.com> At 11:15 AM 12/22/2006, Lamont Peterson wrote: >On Friday 22 December 2006 09:55am, Daniel Yek wrote: >... > > I did stop using it after one of my hard drive started to fail and I plug > > both hard drives into another Fedora Core machine also configured with LVM, > > and I couldn't find a way to boot up that machine with both sets of LVM. > > IIRC, it complained about 2 logical partitions of the same names > > (collision), or something like that. With the extra LVM volume removed, I > > could boot; but with them plugged in, I couldn't boot (the otherwise > > healthy LVM volumes) at all. >... > > Is there a solution for such situation? ... > >Yup. Really simple fix. Rename one of the VGs with "vgrename". Some >ways of >doing this: >... >2. Rename the VG on the hosting system (i.e. the box you're putting the >disks >into. This requires a number of simple steps to complete successfully. > >To use vgrename, the entire VG must be offline. So, boot a rescue >environment >(via CD, PXE, however), skip trying to mount up the disk (or use >the "nomount" option on the "rescue" boot: line), and run (assuming the old >name is "vg0" and the new name should be "herold": > ># lvm >lvm> vgscan >. . . output omitted . . . >lvm> vgchange -a n vg0 >. . . output omitted . . . >lvm> vgrename vg0 herold >. . . output omitted . . . >lvm> vgchange -a y herold >. . . output omitted . . . >lvm> exit > >Then, mount up the root LV, the /boot/ partition, and things like /usr/ >and /dev/: > ># mkdir /mnt/sysimage ># mount /dev/herold/root /mnt/sysimage ># mount /dev/sda1 /mnt/sysimage/boot ># mount /dev/herold/usr /mnt/sysimage/usr > >Of course, change the names of the devices appropriately. > >You can then "chroot" and run "mkinitrd" to fix up the name of the root >device >(because the VG name changed). Also, don't forget to change the "root=" >value(s) in grub.conf (menu.lst on any other distribution). I usually just >snag the mkinitrd command out of the "/sbin/new-kernel-pkg" script >(use "rpm -q --scripts kernel-`uname -r`" to see that's what the kernel RPMs >run). A bit complicated perhaps and haven't tried it yet, but that is great information for me to try out later. Thanks much. >... >-- >Lamont Peterson >Senior Instructor >Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -- Daniel Yek From dyek at real.com Sun Dec 24 16:31:01 2006 From: dyek at real.com (Daniel Yek) Date: Sun, 24 Dec 2006 08:31:01 -0800 Subject: Development machine setup for both i386 and x86_64 work In-Reply-To: <1166868786.16008.2.camel@max.booze> References: <6.2.1.2.2.20061222004303.462804b0@mailone.real.com> <1166868786.16008.2.camel@max.booze> Message-ID: <6.2.1.2.2.20061224082832.02203ab8@mailone.real.com> At 02:13 AM 12/23/2006, Callum Lerwick wrote: >On Fri, 2006-12-22 at 01:13 -0800, Daniel Yek wrote: > > Hi, > > > > How Fedora developers set up dev. machines to do both 32-bit and 64-bit > > development on a single AMD64 machine? > > > > Does it complicate 32-bit dev. work if the development machine is set up > > with x86_64 Fedora Core OS? > >I just compile for i386 using mock. Works great, assuming you >obsessively RPM package everything you deploy to other machines like I >do. :) Sound cool, but I would be happier if you would point me to information about mock -- how to use it and what it is for, etc. Didn't find too much useful information googling... -- Daniel Yek From fedora at camperquake.de Sun Dec 24 17:09:00 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 24 Dec 2006 18:09:00 +0100 Subject: rawhide report: 20061222 changes In-Reply-To: <200612221109.kBMB9LGl013321@hs20-bc2-6.build.redhat.com> References: <200612221109.kBMB9LGl013321@hs20-bc2-6.build.redhat.com> Message-ID: <20061224180900.66d8ef70@nausicaa.camperquake.de> Hi. buildsys at redhat.com wrote: > kernel-2.6.19-1.2891.fc7 > ------------------------ > * Thu Dec 21 2006 David Woodhouse > - Fix IPv6 checksum handling Is that really all that was done? 2891 thinks that the EEPROM checksum of my e1000 network card is invalid. 2890 works fine. -- Eagles may soar, but weasels don't get sucked into jet engines. From arjan at fenrus.demon.nl Sun Dec 24 17:17:44 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 24 Dec 2006 18:17:44 +0100 Subject: rawhide report: 20061222 changes In-Reply-To: <20061224180900.66d8ef70@nausicaa.camperquake.de> References: <200612221109.kBMB9LGl013321@hs20-bc2-6.build.redhat.com> <20061224180900.66d8ef70@nausicaa.camperquake.de> Message-ID: <1166980664.3281.1398.camel@laptopd505.fenrus.org> On Sun, 2006-12-24 at 18:09 +0100, Ralf Ertzinger wrote: > Hi. > > buildsys at redhat.com wrote: > > > kernel-2.6.19-1.2891.fc7 > > ------------------------ > > * Thu Dec 21 2006 David Woodhouse > > - Fix IPv6 checksum handling > > Is that really all that was done? 2891 thinks that the EEPROM checksum > of my e1000 network card is invalid. 2890 works fine. can you get a full diff of the 2 dmesg's ? From fedora at camperquake.de Sun Dec 24 17:23:47 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 24 Dec 2006 18:23:47 +0100 Subject: rawhide report: 20061222 changes In-Reply-To: <1166980664.3281.1398.camel@laptopd505.fenrus.org> References: <200612221109.kBMB9LGl013321@hs20-bc2-6.build.redhat.com> <20061224180900.66d8ef70@nausicaa.camperquake.de> <1166980664.3281.1398.camel@laptopd505.fenrus.org> Message-ID: <20061224182347.4f8705f9@nausicaa.camperquake.de> Hi. Arjan van de Ven wrote: > can you get a full diff of the 2 dmesg's ? I just filed https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220725 Is that enough information? -- All computers wait at the same speed. From leomon.chris at gmail.com Sun Dec 24 17:32:05 2006 From: leomon.chris at gmail.com (leomon) Date: Sun, 24 Dec 2006 12:32:05 -0500 Subject: LVM not fit for default In-Reply-To: <20061224112233.21380@gmx.net> References: <458B115B.7060606@cox.net> <6.2.1.2.2.20061222083537.48f16778@mailone.real.com> <200612221215.15365.lamont@gurulabs.com> <458C5295.9020805@warmcat.com> <1166827921.3952.4.camel@lt21223.campus.dmacc.edu> <458D0688.4020502@warmcat.com> <1166872705.16008.47.camel@max.booze> <458D2E03.6090804@warmcat.com> <77FAA761-5839-499B-9269-087008CB53D8@gmail.com> <20061224112233.21380@gmx.net> Message-ID: yeah one of the few, the proud. I don't really see the need for desktop users, and would like to see some sort of intelligent feature in Anaconda to keep it of unless there would be an advantage, like in a server, and give the end users of such server the tools to adequately recover his system if/when it does fall through. I'm not trying to make some sort of wave in the community or anything I'm just asking a reasonable request that I'm sure some of the top users of fedora core would enjoy to have in the iso's. It may not be a feature that will get much critical acclaim, but it is a feature that is desperately needed, and if I'm shooting my mouth off and there's now something that does the trick, let me know. thanks, Chris On 12/24/06, Joachim Frieben wrote: > > > First of all I have experienced the same "no help hell" with lvm when > > it crashes. (not if, when) I had FC3 installed on my Compaq R3000 > > Series notebook, default settings, except for package options. Ran > > that for about three weeks. I reinstall testing out new distros quite > > a lot, so I don't worry about backing up the entire system, and > > something happened with the system, the kernel panicked when it > > couldn't find a root FS. Same problem as andy. > > > > Basically All I'm trying to say is that yes it fails sometime, no it > > is a cool thing to have, but either give us some tools on default > > install/rescue disc to combat the issue, or take it out unless the > > system detects a RAID array. > > > > Thanks guys, > > > > Chris > > Come on, "FC3" got released *three*years* ago, so it's not appropriate to > make an argument out of this for discussing today's maturity of "LVM". Btw, > I have been using "LVM" exclusively for 3 years now [exact, since I first > installed "FC3"], and I have never ever had any trouble with it at all. > Maybe you encountered a hardware problem? > -- > Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! > Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leomon.chris at gmail.com Sun Dec 24 17:37:02 2006 From: leomon.chris at gmail.com (leomon) Date: Sun, 24 Dec 2006 12:37:02 -0500 Subject: LVM not fit for default In-Reply-To: <20061224112233.21380@gmx.net> References: <458B115B.7060606@cox.net> <6.2.1.2.2.20061222083537.48f16778@mailone.real.com> <200612221215.15365.lamont@gurulabs.com> <458C5295.9020805@warmcat.com> <1166827921.3952.4.camel@lt21223.campus.dmacc.edu> <458D0688.4020502@warmcat.com> <1166872705.16008.47.camel@max.booze> <458D2E03.6090804@warmcat.com> <77FAA761-5839-499B-9269-087008CB53D8@gmail.com> <20061224112233.21380@gmx.net> Message-ID: Oh, and Joachim, I don't think it was a Hardware issue, I just think I got some sort of data corruption and it messed up the partition table, and since LVM handles the management of Logical Volumes on Real Partitions, there were no partitions that I could e2fsck..... later, Chris On 12/24/06, Joachim Frieben wrote: > > > First of all I have experienced the same "no help hell" with lvm when > > it crashes. (not if, when) I had FC3 installed on my Compaq R3000 > > Series notebook, default settings, except for package options. Ran > > that for about three weeks. I reinstall testing out new distros quite > > a lot, so I don't worry about backing up the entire system, and > > something happened with the system, the kernel panicked when it > > couldn't find a root FS. Same problem as andy. > > > > Basically All I'm trying to say is that yes it fails sometime, no it > > is a cool thing to have, but either give us some tools on default > > install/rescue disc to combat the issue, or take it out unless the > > system detects a RAID array. > > > > Thanks guys, > > > > Chris > > Come on, "FC3" got released *three*years* ago, so it's not appropriate to > make an argument out of this for discussing today's maturity of "LVM". Btw, > I have been using "LVM" exclusively for 3 years now [exact, since I first > installed "FC3"], and I have never ever had any trouble with it at all. > Maybe you encountered a hardware problem? > -- > Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! > Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cra at WPI.EDU Sun Dec 24 17:44:51 2006 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 24 Dec 2006 12:44:51 -0500 Subject: LVM not fit for default In-Reply-To: References: <6.2.1.2.2.20061222083537.48f16778@mailone.real.com> <200612221215.15365.lamont@gurulabs.com> <458C5295.9020805@warmcat.com> <1166827921.3952.4.camel@lt21223.campus.dmacc.edu> <458D0688.4020502@warmcat.com> <1166872705.16008.47.camel@max.booze> <458D2E03.6090804@warmcat.com> <77FAA761-5839-499B-9269-087008CB53D8@gmail.com> <20061224112233.21380@gmx.net> Message-ID: <20061224174451.GB4424@angus.ind.WPI.EDU> On Sun, Dec 24, 2006 at 12:32:05PM -0500, leomon wrote: > yeah one of the few, the proud. I don't really see the need for desktop > users, and would like to see some sort of intelligent feature in Anaconda to > keep it of unless there would be an advantage, like in a server, and give > the end users of such server the tools to adequately recover his system > if/when it does fall through. There already is the "Allow me to set up the partitioning" feature in Anaconda. Heck, you can even use fdisk on Ctrl-Alt-F2 if you don't like disk druid. I disagree that LVM isn't useful for desktop users. I've already used it many times to expand my /home when I run out of space, by using free space I left on the disk, or by shrinking another logical volume, or by adding a disk. From fedora at camperquake.de Sun Dec 24 17:57:20 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 24 Dec 2006 18:57:20 +0100 Subject: rawhide report: 20061222 changes In-Reply-To: <20061224182347.4f8705f9@nausicaa.camperquake.de> References: <200612221109.kBMB9LGl013321@hs20-bc2-6.build.redhat.com> <20061224180900.66d8ef70@nausicaa.camperquake.de> <1166980664.3281.1398.camel@laptopd505.fenrus.org> <20061224182347.4f8705f9@nausicaa.camperquake.de> Message-ID: <20061224185720.1660eb9b@nausicaa.camperquake.de> Hi. Ralf Ertzinger wrote: > I just filed https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220725 > Is that enough information? Fun! This is not deterministic after all. During the last few reboots the driver has found the card. -- Im Auftrag ewiger Jugend und Gl?ckseligkeit. From smooge at gmail.com Sun Dec 24 18:01:29 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 24 Dec 2006 11:01:29 -0700 Subject: LVM not fit for Fedora Core In-Reply-To: <458C16C2.8080400@BitWagon.com> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458BFEE3.9060601@BitWagon.com> <1166803888.27377.48.camel@gilboa-home-dev.localdomain> <458C16C2.8080400@BitWagon.com> Message-ID: <80d7e4090612241001t391ec6f3ubc30d0c7e7579b12@mail.gmail.com> On 12/22/06, John Reiser wrote: > Gilboa Davara wrote: > > On Fri, 2006-12-22 at 07:50 -0800, John Reiser wrote: > > > >>Gilboa Davara wrote: > >> > >> > >>>Use LVM. > >>>Trust me. > >>>You won't be sorry. > >> > >>I've been there, done that, and regretted it deeply. > >>I got rid of LVM the first chance I could. > >> > >>LVM does not inter-operate with anything else. > >>Grub does not work under LVM. > > > > > > Why should it? > > Why shouldn't it? LVM is touted as "the solution" to restrictions > on disk partitioning. Except that LVM doesn't work for the first > logical access to disk partitions: booting. > Ok I am going to call cranky old man not wanting to learn new tricks. Its different, its new, and it makes me think about ways that I havent ever before... therefore its bad. The only people I have heard LVM touted as "THE" solution.. are people who don't like LVM. If there are people who tout it as "THE" solution for everything should be ignored.. getting them in your gander is a waste of energy and time. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From angray at beeb.net Sun Dec 24 18:30:42 2006 From: angray at beeb.net (Aaron Gray) Date: Sun, 24 Dec 2006 18:30:42 -0000 Subject: FC-6-i386-livecd-1.iso boot sequence errors References: <010f01c726e1$641f52e0$0200a8c0@AMD2500> <20061224153738.GA3550@kerouac> Message-ID: <002001c72789$a3ca3790$0200a8c0@AMD2500> >> >Then later in boot up sequence we have :- >> > >> > Starting system message bus: Unknown group "netdev" in message bus >> >configuration file >> >> I am also seeing this one, but with a regular installation in my >> laptop. Is it something worth a BZ ticket? > >This is caused by the avahi package. Since I?m not using that service, >this fixes the error message on dbus startup for me: > > # mv /etc/dbus-1/system.d/avahi-dbus.conf{,.broken} > >Or you can try adding a netdev group? > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219218 >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219269 Many thanks, Aaron From cra at WPI.EDU Sun Dec 24 18:46:53 2006 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 24 Dec 2006 13:46:53 -0500 Subject: LVM not fit for Fedora Core In-Reply-To: <80d7e4090612241001t391ec6f3ubc30d0c7e7579b12@mail.gmail.com> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458BFEE3.9060601@BitWagon.com> <1166803888.27377.48.camel@gilboa-home-dev.localdomain> <458C16C2.8080400@BitWagon.com> <80d7e4090612241001t391ec6f3ubc30d0c7e7579b12@mail.gmail.com> Message-ID: <20061224184653.GF4424@angus.ind.WPI.EDU> On Sun, Dec 24, 2006 at 11:01:29AM -0700, Stephen John Smoogen wrote: > Ok I am going to call cranky old man not wanting to learn new tricks. > Its different, its new, and it makes me think about ways that I havent > ever before... therefore its bad. The only people I have heard LVM > touted as "THE" solution.. are people who don't like LVM. If there are > people who tout it as "THE" solution for everything should be > ignored.. getting them in your gander is a waste of energy and time. I'm having difficulty determining if there is any sarcasm here. I don't understand your last sentence above at all. What are you saying? If you don't like new tricks, then you shouldn't be using Fedora. Fedora is all about bleeding edge, pushing the envelope, trying new technologies. All the tools to rescue a system are there on the rescue disk, either with or without LVM. Is there a lack of documentation about LVM on the rescue disk? Perhaps. Isn't the same true about fdisk, parted, fsck, etc? You still have the ability to install a system without LVM. From wtogami at redhat.com Sun Dec 24 19:44:08 2006 From: wtogami at redhat.com (Warren Togami) Date: Sun, 24 Dec 2006 14:44:08 -0500 Subject: ESR "fedora-submit" Message-ID: <458ED888.6050608@redhat.com> http://www.catb.org/~esr/fedora-submit/ "fedora-submit will be a command-line tool that ships RPMs to the Fedora project for inclusion in their repository. It will ship with a future release of Fedora Core." No it will not. "Warren Togami Fedora project honcho. Has backed this concept." I am not the "honcho", and I have never supported your crack-filled ideas. Dear ESR, Nobody in the Fedora Project has endorsed your fedora-submit tool. We have stated on multiple occasions that your reasons for fedora-submit *COMPLETELY MISS THE POINT*. By the existence of this page with its stated falsehoods you potentially confuse the community into thinking that we support your idea. Please delete this page, or at least remove the false statements. Warren Togami wtogami at redhat.com From esr at thyrsus.com Sun Dec 24 20:29:00 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 24 Dec 2006 15:29:00 -0500 Subject: ESR "fedora-submit" In-Reply-To: <458ED888.6050608@redhat.com> References: <458ED888.6050608@redhat.com> Message-ID: <20061224202900.GA17840@thyrsus.com> Warren Togami : > http://www.catb.org/~esr/fedora-submit/ > "fedora-submit will be a command-line tool that ships RPMs to the Fedora > project for inclusion in their repository. It will ship with a future > release of Fedora Core." > > No it will not. > > "Warren Togami > Fedora project honcho. Has backed this concept." > > I am not the "honcho", and I have never supported your crack-filled ideas. >From <3F78168A.4050508 at togami.com>, September 2003: > Your suggestion of a fedora-submit script sounds like a good way to > reduce overhead in submitting Bugzilla reports for packages. I am glad > somebody finally wants to implement it. I suggest to you to read > through many of the fedora.us reports to see the steps involved in this > process. Your script would need to (off the top of my head) > > 1) Check for duplicates. > 2) Submit a new report for a package, along with GPG signatures. > 3) Submit revised packages along with new GPG signatures after some > discussion points out flaws. > 4) Upload packages to *somewhere* which we still haven't worked out. We > obviously cannot give CVS access to everyone, and there may be issues > with a public upload location at an official server. I much prefer the > GPG signatures + submitter controlled URL process that fedora.us > currently uses, but perhaps a future process may have a hybrid. The > more senior trusted packagers have upload access to an official staging > area or CVS, while everyone else uses GPG + URLs. Not only did you back the idea, you came fairly close to writing a spec for it. I don't know what side of the bed you got up on this morning, but I suggest you try the other one. The fundamental structural problem fedora-submit would address is still present and still pressing. Fedora's failure to address it effectively is one of two big reasons why, after more than ten years as a loyal Fedora user and developer, I'm being forced to the conclusion that I must migrate to another distribution where the maintainers are less of an inward-looking circle-jerk. (The other big one is the codec problem.) Time is running out for you. Ubuntu is eating your lunch. Even Linspire looks smarter and fresher than Fedora these days. Your failure to adapt implies merely a system-administration inconvenience for me, but it's going to be a disaster for you. (Note to Michael Tiemann: if you have any ability to wield a clue-bat on these people, now would be the time to do it. The level of don't-get-it I'm seeing appears certain to cause Red Hat business problems in the 18- to 24-month timeframe.) -- Eric S. Raymond From wtogami at redhat.com Sun Dec 24 22:46:29 2006 From: wtogami at redhat.com (Warren Togami) Date: Sun, 24 Dec 2006 17:46:29 -0500 Subject: ESR "fedora-submit" In-Reply-To: <20061224202900.GA17840@thyrsus.com> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> Message-ID: <458F0345.5010902@redhat.com> Eric S. Raymond wrote: > Not only did you back the idea, you came fairly close to writing a > spec for it. I don't know what side of the bed you got up on this > morning, but I suggest you try the other one. This was a *LONG* time ago, long before the current Fedora package process. Subsequent to me writing those suggestions, your idea of fedora-submit and desired method of software submission turned out to be missing the point entirely. Reading through the mail archives and what you state on the fedora-submit page, you seem to have wanted a fire-and-forget tool for submitting software to Fedora, both for initial submission and further updates. Fedora simply did NOT want to do it this way. (I am unable to find the post in the mail archive now, but I vaguely recall you wanting a "contrib" style upload system where you could submit RPMS for Fedora to directly consume. If my memory has properly attributed this to your desires for Fedora, then this was furthermore crack.) Fedora has a review process that has allowed the project to scale in a responsible manner. Dozens of Reviewer/contributors have been promoted as they did work over time. THOUSANDS of packages have been approved. The backlog of the review queue has shrank to a manageable level, indicating that the process has been working. The current incarnation of this process uses Bugzilla during review, and CVS there-after for package updating by the maintainer. This process has done a tremendous job of growing Fedora's software catalog. Further improvement is on-going, with better tools and processes to reduce maintainer and process overhead. Your fedora-submit tool tried to optimize a problem that wasn't very problematic. We simply did not agree with your desired process of software submission. In any case, please remove statements from your page like, "It will ship with a future release of Fedora Core." and my explicit endorsement of your tool, because they are simply not true. > > The fundamental structural problem fedora-submit would address is still > present and still pressing. Fedora's failure to address it effectively > is one of two big reasons why, after more than ten years as a loyal Fedora > user and developer, I'm being forced to the conclusion that I must > migrate to another distribution where the maintainers are less of an > inward-looking circle-jerk. You claim that Fedora's submission process even today is a failure. To date you have never even TRIED to submit a package to Fedora or to maintain a package here. > > Time is running out for you. Ubuntu is eating your lunch. Even > Linspire looks smarter and fresher than Fedora these days. Your > failure to adapt implies merely a system-administration inconvenience > for me, but it's going to be a disaster for you. Ubuntu already has eaten our lunch in the aftermath of Red Hat's past mistakes in community relationship in the 2003 timeframe. Red Hat was too focused on doing the right thing (100% FOSS software development), and not enough on community outreach (simply talking to the community). Since then great improvements have been happening in the Fedora Project, and even larger improvements are coming with the Fedora merge[1]. http://www.groklaw.net/article.php?story=20061103073628401 An astute observer recognizes that Fedora is doing the right thing for the long-term success of FOSS. http://www.catb.org/~esr/writings/world-domination/world-domination-201.html (Offtopic) By the way, ATI driver is not a resolved issue for FOSS. The reverse engineered drivers with 3D support are only for older series of cards. Most newer cards are poorly supported, and most users still rely on ATI's proprietary, GPL violating fglrx drivers. Warren Togami wtogami at redhat.com [1] http://lwn.net/Articles/214925/ http://fedoraproject.org/wiki/Extras/Schedule/MergeCoreAndExtras From seg at haxxed.com Sun Dec 24 22:54:49 2006 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 24 Dec 2006 16:54:49 -0600 Subject: ESR "fedora-submit" In-Reply-To: <20061224202900.GA17840@thyrsus.com> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> Message-ID: <1167000890.16008.65.camel@max.booze> On Sun, 2006-12-24 at 15:29 -0500, Eric S. Raymond wrote: > >From <3F78168A.4050508 at togami.com>, September 2003: Three years ago? I suspect circumstances have changed a bit since then. For those of us who only joined the project in the last year or so, could you please point us to the original thread? WTF is this all about? Whats the problem, and how exactly is it leading to the Imminent Death of Fedora Also Red Hat? -------------- 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 esr at thyrsus.com Sun Dec 24 23:57:40 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 24 Dec 2006 18:57:40 -0500 Subject: ESR "fedora-submit" In-Reply-To: <458F0345.5010902@redhat.com> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> Message-ID: <20061224235740.GA19176@thyrsus.com> Warren Togami : > >Not only did you back the idea, you came fairly close to writing a > >spec for it. I don't know what side of the bed you got up on this > >morning, but I suggest you try the other one. > > This was a *LONG* time ago, long before the current Fedora package > process. Subsequent to me writing those suggestions, your idea of > fedora-submit and desired method of software submission turned out to be > missing the point entirely. Let's suppose I had a package approved for Extras, or whatever Extras is called this week. Would it still be necessary for me to do work by hand to get a point release into the repo, as opposed to being able to script the process? If your answer is "yes" then, from my POV as a maintainer of thirty-six projects, the submission system is still broken as designed. It imposes an overhead on me that I find unacceptable. > (I am unable to find the post in the mail archive now, but I vaguely > recall you wanting a "contrib" style upload system where you could > submit RPMS for Fedora to directly consume. If my memory has properly > attributed this to your desires for Fedora, then this was furthermore > crack.) Your memory is faulty. I specifically told you (and I can produce the email to prove it -- I reread it less than an hour ago) that I *don't care* whether the update packet I'd have to ship is an RPM, a tarball, or a patch and a job card. The functional point is that *it must be possible for me to fully script my release process*. I'm willing to do hand-work on initial submissions, but not on update releases. If I can't fire-and-forget those, I won't play. Dammit, I don't have the *time* to jump through clicky-webby hoops or go through protocol exchanges I have to pay attention to with my one precious brain. Not over thirty-six projects. Your apparent inability to grasp this point, instead obsessing about technical details such as whether or not the submission queue is "RPMS to be consumed" speaks to me of a fundamental failure in Fedora's vision of its relationship with developers. You're not seeing the forest for the trees. You're passing tactics but failing strategy. > Fedora has a review process that has allowed the project to scale in a > responsible manner. Dozens of Reviewer/contributors have been promoted > as they did work over time. THOUSANDS of packages have been approved. > The backlog of the review queue has shrank to a manageable level, > indicating that the process has been working. *sigh* Fine, fine. Motherhood, apple pie, wave the flag. I'm happy for you that you think your process is working. The question remains. Do I have to *do shit by hand* to get point releases into the receiving end of your wonderful review process? If I do, your design is still unusable for me. No matter how marvellous you think it is, it fails to scale to my needs. I can't stop you from dismissing this evaluation as 'on crack', but I can and will simply dismiss you as an oblivious idiot if you do. > The current incarnation of this process uses Bugzilla during review, and > CVS there-after for package updating by the maintainer. This process > has done a tremendous job of growing Fedora's software catalog. Further > improvement is on-going, with better tools and processes to reduce > maintainer and process overhead. Can I script an update to the CVS? Can I write a procedure in shell or Python, to be invoked by 'make ship' from my project's top-level makefile, that will automate my release process so I *don't have to think about it*? I *don't* *fucking* *care* what happens on the back end. If one of the possible consequences is email bounceback that says "your point release failed QA because *BLAH*, that's OK. I'll fix the problem and try again. > In any case, please remove statements from your page like, "It will ship > with a future release of Fedora Core." and my explicit endorsement of > your tool, because they are simply not true. Would you prefer "Warren Togami liked this idea when I proposed it, but has since gone as crazy as a rabid dingo and changed his mind?" Because that's how reality looks to me right now. > You claim that Fedora's submission process even today is a failure. To > date you have never even TRIED to submit a package to Fedora or to > maintain a package here. That's right. If it isn't obvious to you why I haven't by now, you really are insane. It's because you made the perceived overhead of submitting a package and update releases too high. Your submission process scared me away. *Me*. Mr. Open Source himself, as experienced and battle-scarred a developer in this mode as walks the planet and breathes. That makes your submission process a failure. I've still got the bloody printed application form on my desk. But I never filled it out because nobody persuaded me that I wouldn't be letting myself in for a nightmare of bureaucracy and repetitive hand-work. Go ahead. Persuade me. I would love to believe that all the sweat I've put into improving RedHat/Fedora, and all the abuse I've taken from my Debian- and Ubuntu-loving friends, was not in vain. My previous offer still stands. If you're willing to make it technically possible for me to automate pushing my point releases into your queue. I'll write the client tool to do it. -- Eric S. Raymond From icon at fedoraproject.org Mon Dec 25 00:09:03 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Sun, 24 Dec 2006 19:09:03 -0500 Subject: ESR "fedora-submit" In-Reply-To: <20061224235740.GA19176@thyrsus.com> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> Message-ID: On 12/24/06, Eric S. Raymond wrote: > The question remains. Do I have to *do shit by hand* Why not, you're doing an admirable job so far. Regards, -- Konstantin Ryabitsev Montr?al, Qu?bec From tiemann at redhat.com Mon Dec 25 00:18:08 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Sun, 24 Dec 2006 19:18:08 -0500 Subject: ESR "fedora-submit" In-Reply-To: References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> Message-ID: <1167005888.6039.9.camel@localhost.localdomain> On Sun, 2006-12-24 at 19:09 -0500, Konstantin Ryabitsev wrote: > On 12/24/06, Eric S. Raymond wrote: > > The question remains. Do I have to *do shit by hand* > > Why not, you're doing an admirable job so far. Konstantin--how many packages do you maintain? I think that rather than sniping at a would-be contributor, I'd like to see somebody who is maintaining at least 30, and perhaps 50 packages explain how *they* do it. Maybe they have a better way. Maybe it drives them almost as crazy Eric. How *does* a maintainer of 36 packages would with the Fedora process? How *should* one do it? This is the question and the problem to be solved. M From icon at fedoraproject.org Mon Dec 25 00:50:00 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Sun, 24 Dec 2006 19:50:00 -0500 Subject: ESR "fedora-submit" In-Reply-To: <1167005888.6039.9.camel@localhost.localdomain> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <1167005888.6039.9.camel@localhost.localdomain> Message-ID: On 12/24/06, Michael Tiemann wrote: > Konstantin--how many packages do you maintain? I think that rather than > sniping at a would-be contributor, I'd like to see somebody who is > maintaining at least 30, and perhaps 50 packages explain how *they* do > it. Maybe they have a better way. Maybe it drives them almost as crazy > Eric. How *does* a maintainer of 36 packages would with the Fedora > process? How *should* one do it? This is the question and the problem > to be solved. I maintain a very small number -- only 15. From my own experience, I can tell you that work spent actually doing something with spec files is negligeable compared to how much effort is spent tracking what is going on with a project, doing test builds and verifying that they work, running rpmlint, responding to bugzilla requests, opening upstream bugzilla requests for bugs filed with a package, monitoring cvs commits to see if someone was "messing" with your projects, etc. You can't script that. If project "a" releases a "point update" to "1.1.2" from "1.1.1," it's not enough to run "make new-sources". You have to read the Changelog to see why they have issued this update (security? rush it through. fixes for solaris builds? whatever, ignore it). You then have to spend a few days just monitoring the list to see if there is an "oh shit, that release breaks something" moment -- those tend to happen frequently. Only then, after a few days, you get to actually run "make new-sources", run a test mock build, run rpmlint against the packages, then copy sources, .cvsignore, foo.spec into FC-5 and devel. CVS commit, make tag, make build. Can it be scripted? I have no doubt. Will that actually be solving any problems? I don't think so. The integral part of caring for fedora packages is the human element -- making sure that you don't commit something broken. Even with all that time-consuming care, things slip up and break all the time. I don't see how removing all "palliative care" from the process is going to result in anything but more broken packages in the long-run. Sure, I don't have "36 projects" -- I don't even have catchy 3 letters to go by, but I assure you that I keep just as busy. Regards, -- Konstantin Ryabitsev Montr?al, Qu?bec From jspaleta at gmail.com Mon Dec 25 00:54:23 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 24 Dec 2006 15:54:23 -0900 Subject: ESR "fedora-submit" In-Reply-To: <1167005888.6039.9.camel@localhost.localdomain> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <1167005888.6039.9.camel@localhost.localdomain> Message-ID: <604aa7910612241654y32335934j15791eee80abfb2b@mail.gmail.com> On 12/24/06, Michael Tiemann wrote: > This is the question and the problem > to be solved. cvs commits into the cvs trees are of course scriptable. Once your package has been reviewed and you have gotten approval, its just a set of cvs operations to keep the package updated. The caveat being creation of release branches which you have to request, so its not possible to script branch creation at all, since as a contributor you can't do this on your own. Branch requests are just edits to a wikipage so even that is of course scriptable. Once the branches are created, all future operations are done with a set of cvs commands. Update the spec file and the patch files, update the source look-aside, make tag, make build, not much to it really. Scripting of the submission into the review process is as scriptable as opening a bugzilla ticket is. But I see little or no value here in scripting the opening of review tickets, since even if a person maintains 100+ projects, its certaintly not a good idea to initiate 100+ review tickets in one push. And you cerntaintly can't script the communication you have with the reviewers on each of your open submission tickets. The potential problem with scripted interactions, as I see it, is can you have scripted actions that producee the spec files that conform to the current Fedora Packaging guidelines? If the automation ends up adding non-obvious specfile elements which impair human reading of the specfile, then we are going to have a problem. -jef From esr at thyrsus.com Mon Dec 25 00:56:16 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 24 Dec 2006 19:56:16 -0500 Subject: ESR "fedora-submit" In-Reply-To: <1167000890.16008.65.camel@max.booze> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <1167000890.16008.65.camel@max.booze> Message-ID: <20061225005616.GC19176@thyrsus.com> Callum Lerwick : > For those of us who only joined the project in the last year or so, > could you please point us to the original thread? WTF is this all about? In a nutshell, I won't be a Fedora package maintainer if it means I have to do special hand-work every time I ship a release. The more general problem is that the Fedora submission system doesn't scale (or at least, appears to me not to scale) for maintainers with *lots* of projects. In 2003 I offered to write tools to attack this problem by automating the client end of release submissions. I actually did write a script that can enter bugs with attachments to a Bugzilla instance under program control; it's been part of the mainline Bugzilla release since, hmm, 2004 I think. The next step was going to be to write a 'fedora-submit' wrapper around that. Warren Togami liked the idea at the time, but seems to have changed his mind since. I trust my reply to Warren Togami will supply sufficient additional context. > Whats the problem, and how exactly is it leading to the Imminent Death > of Fedora Also Red Hat? In 2003, when I first tried to attack this problem, Fedora was riding high. Since then, a series of strategic blunders on the part of both Red Hat and the Fedora project leadership have thrown away most of the advantages in reality and perception that Fedora had at the time. The best index of their failure is the rising popularity of Ubuntu. I view the failure of Fedora to address my scaling issue as a symptom or indicator of a larger failure to do what it took to retain community and developer support at the level it enjoyed in 2003. When a developer of my stature and experience feels like he's being forced away from a distribution he's supported for over ten years, that's damn bad news for a distribution which, on the market- and mind-share evidence, has already screwed lots of other pooches. How do I put this delicately...oh, to hell with delicately. If they won't listen respectfully to a guy who helped found the entire fricking open-source movement, my confidence that they'll pay the attention they must to J. Random Developer is *nil*. Warren Togami's "on crack" remarks have just demonstrated that he has his head jammed firmly up his ass, and (sadly) I have no evidence that the rest of the project leadership is any less ingrown and cut off from reality. I'm not predicting Imminent Death Of Fedora. I'm saying that you are running out of time and room to maneuver. Your project leadership has been displaying every sign of strategic incompetence since before 2003. I honestly wish you luck pulling out of that dive. -- Eric S. Raymond From fedora at wir-sind-cool.org Mon Dec 25 01:14:11 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 25 Dec 2006 02:14:11 +0100 Subject: ESR "fedora-submit" In-Reply-To: <20061224235740.GA19176@thyrsus.com> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> Message-ID: <20061225021411.7093bf53.fedora@wir-sind-cool.org> On Sun, 24 Dec 2006 18:57:40 -0500, Eric S. Raymond wrote: > Let's suppose I had a package approved for Extras, or whatever Extras > is called this week. Would it still be necessary for me to do work by > hand to get a point release into the repo, as opposed to being able to > script the process? make new-sources FILES="foo-2.0.tar.bz2 foo-data-2.0.tar.bz2" blah-blah > foo.spec make clog make commit -F clog make tag && make build However, before you think you feel capable enough to script that and submit each and every update like that, you still cannot avoid spending time on creating good quality packages which are not infested with lots of packaging bugs. The point where some package submitters still fail nowadays in the same way they would have failed with the old fedora.us-style "poor man's infrastructure and procedures" is the package review process. It _still_ takes place in bugzilla. This is where reviewers find out whether a submitter knows what he's doing and whether he shows interest in the package. > If your answer is "yes" then, from my POV as a maintainer of thirty-six > projects, the submission system is still broken as designed. It imposes > an overhead on me that I find unacceptable. > The question remains. Do I have to *do shit by hand* to get point > releases into the receiving end of your wonderful review process? There is no review process for updates. > Can I script an update to the CVS? Can you script the updates to your spec files in a reliable way? And let me point out that you cannot script the testing of your rpms prior to submitting them as official updates for Fedora. ;) > I *don't* *fucking* *care* what happens on the back end. If one > of the possible consequences is email bounceback that says "your > point release failed QA because *BLAH*, that's OK. I'll fix the > problem and try again. Once more. There is no post-build QA process. There is no review process for updates. > I've still got the bloody printed application form on my desk. But > I never filled it out because nobody persuaded me that I wouldn't > be letting myself in for a nightmare of bureaucracy and repetitive > hand-work. FUD. From esr at thyrsus.com Mon Dec 25 01:25:08 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 24 Dec 2006 20:25:08 -0500 Subject: ESR "fedora-submit" In-Reply-To: References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <1167005888.6039.9.camel@localhost.localdomain> Message-ID: <20061225012508.GD19176@thyrsus.com> Konstantin Ryabitsev : > On 12/24/06, Michael Tiemann wrote: > >Konstantin--how many packages do you maintain? I think that rather than > >sniping at a would-be contributor, I'd like to see somebody who is > >maintaining at least 30, and perhaps 50 packages explain how *they* do > >it. Maybe they have a better way. Maybe it drives them almost as crazy > >Eric. How *does* a maintainer of 36 packages would with the Fedora > >process? How *should* one do it? This is the question and the problem > >to be solved. > > I maintain a very small number -- only 15. From my own experience, I > can tell you that work spent actually doing something with spec files > is negligeable compared to how much effort is spent tracking what is > going on with a project, doing test builds and verifying that they > work, running rpmlint, responding to bugzilla requests, opening > upstream bugzilla requests for bugs filed with a package, monitoring > cvs commits to see if someone was "messing" with your projects, etc. I already do all of these things except running rpmlint. They're part of being a project lead. I'd be happy to add running rpmlint to my process. > You can't script that. If project "a" releases a "point update" to > "1.1.2" from "1.1.1," it's not enough to run "make new-sources". You > have to read the Changelog to see why they have issued this update > (security? rush it through. fixes for solaris builds? whatever, ignore > it). You then have to spend a few days just monitoring the list to see > if there is an "oh shit, that release breaks something" moment -- > those tend to happen frequently. Yes, this sounds very familiar. > Only then, after a few days, you get > to actually run "make new-sources", run a test mock build, run rpmlint > against the packages, then copy sources, .cvsignore, foo.spec into > FC-5 and devel. CVS commit, make tag, make build. > > Can it be scripted? I have no doubt. Will that actually be solving any > problems? I don't think so. With respect, sir, I decline to substitute your speculation for my experience. At 36 projects I find that the mechanical overhead of manual point releases drives me batshit. I've written a tool called 'shipper' to avoid it; you can download it from my site. What I want to be able to do is add a channel to shipper that lets me script-ship to Fedora the way it presently can to Freshmeat and my own website. > The integral part of caring for fedora > packages is the human element -- making sure that you don't commit > something broken. I don't disagree. But I also don't understand why you think this is relevant to my complaint. When I've done all my QA, passed all ny regression tests, test-built my RPM and done everything I know how to do to ensure I don't ship a broken release, I want to be able to push a button and *go*. There's no virtue in my having to remember details or perform rituals by hand at that point. > Sure, I don't have "36 projects" -- I don't even have catchy 3 letters > to go by, but I assure you that I keep just as busy. Ouch. Please don't blame me for "ESR" -- people hung that on me by analogy with "RMS" and I've never been entirely comfortable with it. As I note on my Slashdot profile, I didn't ask to be triletterized, I merely found that my role left me unable to escape it. -- Eric S. Raymond From fedora at wir-sind-cool.org Mon Dec 25 01:30:31 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 25 Dec 2006 02:30:31 +0100 Subject: ESR "fedora-submit" In-Reply-To: <1167000890.16008.65.camel@max.booze> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <1167000890.16008.65.camel@max.booze> Message-ID: <20061225023031.e7c0e901.fedora@wir-sind-cool.org> On Sun, 24 Dec 2006 16:54:49 -0600, Callum Lerwick wrote: > On Sun, 2006-12-24 at 15:29 -0500, Eric S. Raymond wrote: > > > >From <3F78168A.4050508 at togami.com>, September 2003: > > Three years ago? I suspect circumstances have changed a bit since then. > > For those of us who only joined the project in the last year or so, > could you please point us to the original thread? WTF is this all In order to understand what ESR refers to you need to be familiar with the roots of Fedora Extras at fedora.us. Not only did we use a bugzilla based package review process, we also used the same bugzilla for reviews of updated src.rpms and for build requests. All that because of limited infrastructure and the requirement for new contributors to earn trust. Only approved packages were accepted, built and published. Trusted packagers didn't need to wait for reviews, but they still needed to upload their src.rpms to some place and submit build requests in bugzilla. No CVS for packages. No upload mechanism. No build servers. While the extra amount of reviewing increased the quality for a variety of packages and their updates and helped a lot in creating packaging guidelines, overall it didn't scale. Too many new packages in the queue, too few reviewers. From fedora at wir-sind-cool.org Mon Dec 25 01:44:10 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 25 Dec 2006 02:44:10 +0100 Subject: ESR "fedora-submit" In-Reply-To: <20061225005616.GC19176@thyrsus.com> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <1167000890.16008.65.camel@max.booze> <20061225005616.GC19176@thyrsus.com> Message-ID: <20061225024410.6ace3969.fedora@wir-sind-cool.org> On Sun, 24 Dec 2006 19:56:16 -0500, Eric S. Raymond wrote: > In a nutshell, I won't be a Fedora package maintainer if it means I have > to do special hand-work every time I ship a release. The more general > problem is that the Fedora submission system doesn't scale (or at least, > appears to me not to scale) for maintainers with *lots* of projects. One request, please, get up-to-date on how packages are submitted and built _nowadays_ instead of beating dead procedures. > In 2003 I offered to write tools to attack this problem by automating > the client end of release submissions. I actually did write a script > that can enter bugs with attachments to a Bugzilla instance under > program control; it's been part of the mainline Bugzilla release > since, hmm, 2004 I think. There is a cvs-import.sh script which can import entire src.rpms to Fedora Extras CVS (its primary use is in the initial import). It takes care of adding/removing and committing files. It is used by several packagers, who prefer using it over working in CVS themselves, for *all* their updates. What it doesn't automate, however, is all the stuff you need to do prior to creating your source rpms. From esr at thyrsus.com Mon Dec 25 01:52:11 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 24 Dec 2006 20:52:11 -0500 Subject: ESR "fedora-submit" In-Reply-To: <604aa7910612241654y32335934j15791eee80abfb2b@mail.gmail.com> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <1167005888.6039.9.camel@localhost.localdomain> <604aa7910612241654y32335934j15791eee80abfb2b@mail.gmail.com> Message-ID: <20061225015211.GE19176@thyrsus.com> Jeff Spaleta : > cvs commits into the cvs trees are of course scriptable. Once your > package has been reviewed and you have gotten approval, its just a set > of cvs operations to keep the package updated. Aha! This begins to sound like a constructive response! > Update the spec file and the patch files, update the source > look-aside, make tag, make build, not much to it really. What's a "source look-aside" in this context? > Scripting of the submission into the review process is as scriptable > as opening a bugzilla ticket is. But I see little or no value here in > scripting the opening of review tickets, since even if a person > maintains 100+ projects, its certaintly not a good idea to initiate > 100+ review tickets in one push. And you cerntaintly can't script the > communication you have with the reviewers on each of your open > submission tickets. I wholeheartedly agree. The reason I did Bugzilla scripting in 2003 was that I understood that to be the mechanism in plan for updates. Trying to script initial submission would be loopy, and I never proposed it. > The potential problem with scripted interactions, as I see it, is can > you have scripted actions that producee the spec files that conform to > the current Fedora Packaging guidelines? If the automation ends up > adding non-obvious specfile elements which impair human reading of the > specfile, then we are going to have a problem. See, now *this* is material to the issue in a way that Warren Togami stupidly and arrogantly telling me I'm "on crack" is not. Let me tell you what I do on my projects. I normally have a spec.in file in which I keep my project changelog. I start my release process with 'make dist', which generates a spec file with the current version number plugged in. When I invoke 'shipper', one of the things it does is build RPMs from the generated specfile. Those get uploaded to whatever channels I have designated for the project. Note: I am *not* describing this because I necessarily want or need to drop my RPM directly into a Fedora repo. I'm describing this so you understand that I could actually build an rpmlint check into shipper. If it doesn't pass, shipping would get aborted *immediately*, before anything got shipped to anywhere. This would be in conformance with shipper's design philosophy -- part of which is, if you automate testing *you will do more of it*. I think I can ensure that bad things don't get written into the spec file you see by (a) rpmlinting every time I generate, and (b) keeping an eye on the semantic correctness of the stuff in the spec.in file header. And (b) probably won't involve much -- only the version number and the changelog typically change on a point release. Jef, am I answering the question you were trying to ask? -- Eric S. Raymond From esr at thyrsus.com Mon Dec 25 01:58:40 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 24 Dec 2006 20:58:40 -0500 Subject: ESR "fedora-submit" In-Reply-To: <20061225021411.7093bf53.fedora@wir-sind-cool.org> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <20061225021411.7093bf53.fedora@wir-sind-cool.org> Message-ID: <20061225015840.GF19176@thyrsus.com> Michael Schwendt : > make new-sources FILES="foo-2.0.tar.bz2 foo-data-2.0.tar.bz2" > blah-blah > foo.spec > make clog > make commit -F clog > make tag && make build > > However, before you think you feel capable enough to script that and > submit each and every update like that, you still cannot avoid spending > time on creating good quality packages which are not infested with lots of > packaging bugs. I agree with you. What I don't understand is why you think this has anything to do with my complaint. No matter how much stuff I have to do before the mechanical part of shipping, when it gets to that mechanical part, I want to *push a button and be done*! > > The question remains. Do I have to *do shit by hand* to get point > > releases into the receiving end of your wonderful review process? > > There is no review process for updates. OK, it's helpful to know that. > > Can I script an update to the CVS? > > Can you script the updates to your spec files in a reliable way? Yes. I do that already. > And let me point out that you cannot script the testing of your rpms prior > to submitting them as official updates for Fedora. ;) True, but I think you added the smiley because you know it isn't really relevant. > > I've still got the bloody printed application form on my desk. But > > I never filled it out because nobody persuaded me that I wouldn't > > be letting myself in for a nightmare of bureaucracy and repetitive > > hand-work. > > FUD. Yes, FUD. Too much FUD in your process, or at least your representation of it to the world. You need to fix that. -- Eric S. Raymond From fedora at wir-sind-cool.org Mon Dec 25 02:04:35 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 25 Dec 2006 03:04:35 +0100 Subject: ESR "fedora-submit" In-Reply-To: <20061225015211.GE19176@thyrsus.com> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <1167005888.6039.9.camel@localhost.localdomain> <604aa7910612241654y32335934j15791eee80abfb2b@mail.gmail.com> <20061225015211.GE19176@thyrsus.com> Message-ID: <20061225030435.3637c8d1.fedora@wir-sind-cool.org> On Sun, 24 Dec 2006 20:52:11 -0500, Eric S. Raymond wrote: > Jeff Spaleta: > > > Update the spec file and the patch files, update the source > > look-aside, make tag, make build, not much to it really. > > What's a "source look-aside" in this context? Large binary files (like tarballs) are not stored in CVS, but on a separate HTTP-based "look-aside cache server". It's where the Makefiles in CVS upload/download them to/from. The files' names and checksums are stored in CVS (in a file with the name "sources") together with the package spec file, patch files, ... From sundaram at fedoraproject.org Mon Dec 25 02:00:27 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 25 Dec 2006 07:30:27 +0530 Subject: ESR "fedora-submit" In-Reply-To: <20061225015840.GF19176@thyrsus.com> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <20061225021411.7093bf53.fedora@wir-sind-cool.org> <20061225015840.GF19176@thyrsus.com> Message-ID: <458F30BB.8030207@fedoraproject.org> Eric S. Raymond wrote: > > Yes, FUD. Too much FUD in your process, or at least your representation > of it to the world. You need to fix that. Can you read http://fedoraproject.org/wiki/Extras/Contributors and point out what you would "FUD" in the process or representation? Rahul From esr at thyrsus.com Mon Dec 25 02:10:27 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 24 Dec 2006 21:10:27 -0500 Subject: ESR "fedora-submit" In-Reply-To: <20061225030435.3637c8d1.fedora@wir-sind-cool.org> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <1167005888.6039.9.camel@localhost.localdomain> <604aa7910612241654y32335934j15791eee80abfb2b@mail.gmail.com> <20061225015211.GE19176@thyrsus.com> <20061225030435.3637c8d1.fedora@wir-sind-cool.org> Message-ID: <20061225021027.GG19176@thyrsus.com> Michael Schwendt : > > > Update the spec file and the patch files, update the source > > > look-aside, make tag, make build, not much to it really. > > > > What's a "source look-aside" in this context? > > Large binary files (like tarballs) are not stored in CVS, but on a > separate HTTP-based "look-aside cache server". It's where the Makefiles in > CVS upload/download them to/from. The files' names and checksums are > stored in CVS (in a file with the name "sources") together with the > package spec file, patch files, ... Thanks. This sounds like the kind of detail I need to know to write my script. -- Eric S. Raymond From esr at thyrsus.com Mon Dec 25 02:19:45 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 24 Dec 2006 21:19:45 -0500 Subject: ESR "fedora-submit" In-Reply-To: <458F30BB.8030207@fedoraproject.org> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <20061225021411.7093bf53.fedora@wir-sind-cool.org> <20061225015840.GF19176@thyrsus.com> <458F30BB.8030207@fedoraproject.org> Message-ID: <20061225021945.GH19176@thyrsus.com> Rahul Sundaram : > >Yes, FUD. Too much FUD in your process, or at least your representation > >of it to the world. You need to fix that. > > Can you read http://fedoraproject.org/wiki/Extras/Contributors and point > out what you would "FUD" in the process or representation? Yes, I will do that. Can't guarantee to give feedback immediately, I have holiday/family things to do tomorrow. But it will go on the medium-priority part of my to-do list. -- Eric S. Raymond From esr at thyrsus.com Mon Dec 25 02:21:07 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 24 Dec 2006 21:21:07 -0500 Subject: ESR "fedora-submit" In-Reply-To: <20061225024410.6ace3969.fedora@wir-sind-cool.org> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <1167000890.16008.65.camel@max.booze> <20061225005616.GC19176@thyrsus.com> <20061225024410.6ace3969.fedora@wir-sind-cool.org> Message-ID: <20061225022107.GI19176@thyrsus.com> Michael Schwendt : > On Sun, 24 Dec 2006 19:56:16 -0500, Eric S. Raymond wrote: > > > In a nutshell, I won't be a Fedora package maintainer if it means I have > > to do special hand-work every time I ship a release. The more general > > problem is that the Fedora submission system doesn't scale (or at least, > > appears to me not to scale) for maintainers with *lots* of projects. > > One request, please, get up-to-date on how packages are submitted and > built _nowadays_ instead of beating dead procedures. I will do so. I have promised to review the Wiki guidelines. > There is a cvs-import.sh script which can import entire src.rpms to > Fedora Extras CVS (its primary use is in the initial import). It takes > care of adding/removing and committing files. It is used by several > packagers, who prefer using it over working in CVS themselves, for > *all* their updates. What it doesn't automate, however, is all the > stuff you need to do prior to creating your source rpms. I will look into this. -- Eric S. Raymond From jspaleta at gmail.com Mon Dec 25 02:21:16 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 24 Dec 2006 17:21:16 -0900 Subject: ESR "fedora-submit" In-Reply-To: <20061225015211.GE19176@thyrsus.com> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <1167005888.6039.9.camel@localhost.localdomain> <604aa7910612241654y32335934j15791eee80abfb2b@mail.gmail.com> <20061225015211.GE19176@thyrsus.com> Message-ID: <604aa7910612241821y60e7a469l6057206767a450@mail.gmail.com> On 12/24/06, Eric S. Raymond wrote: > Jeff Spaleta : > > cvs commits into the cvs trees are of course scriptable. Once your > > package has been reviewed and you have gotten approval, its just a set > > of cvs operations to keep the package updated. > > Aha! This begins to sound like a constructive response! > > > Update the spec file and the patch files, update the source > > look-aside, make tag, make build, not much to it really. > > What's a "source look-aside" in this context? the look-aside cache is the magical place where cvs can hold binaries, like an upstream tarball. make new-sources is the makefile target which does the necessary magic which I don't care enough about to understand completely. As Micheal pointed out, the process to update an srpm in fedora extras is pretty simple now and is controlled via Makefile.common available in the cvs trees. While you can use the available cvs-import.sh script for all the srpm's uploaded into cvs, I personally don't like do it, because I've gotten into trouble with incorrect cvs tagging across release branches when I've used cvs-import incorrectly. > I wholeheartedly agree. The reason I did Bugzilla scripting in 2003 was > that I understood that to be the mechanism in plan for updates. Trying > to script initial submission would be loopy, and I never proposed it. Things have changed, 2003 was a long time ago for project policy and infrastructure. We are in the 2nd age of fedora contributor infrastructure now, with a reasonably scriptable cvs server and build automation. In fact we will soon see the birth of a 3rd age of infrastructure when Core and Extras merge into a common buildsystem. > See, now *this* is material to the issue in a way that Warren Togami > stupidly and arrogantly telling me I'm "on crack" is not. Shrug, just as long as you realize that nothing I'm saying now should be interpreted as endorsement of any idea you may have now, may have had in the past, or might have in the future. And you should know that I reserve the right to verbally rip out your spleen through your left ear if I find that you have decided to quote anything I say out of context and without direct citation back to this mailinglist archive. > Note: I am *not* describing this because I necessarily want or need to > drop my RPM directly into a Fedora repo. I'm describing this so you > understand that I could actually build an rpmlint check into shipper. What rpmlint does is not fully equivalent to what people do when they read over specfiles. One concern is that the specfiles state somewhat human-readable, and depending on how one automates the creation of their specfiles, this could leave some decidedly un-intuitive artifacts which hamper a human's ability to read the specfile without causing an rpmlint warning or error. > Jef, am I answering the question you were trying to ask? Not really, the only thing that's going to answer all questions is to shove one of your packages through the review process and see if your scripts can deal with an ever-evolving Fedora Packaging Guideline policy and if reviewers can deal with any automation artifacts that are a result of your scripts. It would help however if you got re-acquainted with the fedora contributor policy state-of-the-art. http://fedoraproject.org/wiki/Extras/Contributors -jef From fedora at wir-sind-cool.org Mon Dec 25 02:26:53 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Mon, 25 Dec 2006 03:26:53 +0100 Subject: ESR "fedora-submit" In-Reply-To: <20061225015840.GF19176@thyrsus.com> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <20061225021411.7093bf53.fedora@wir-sind-cool.org> <20061225015840.GF19176@thyrsus.com> Message-ID: <20061225032653.0600bf38.fedora@wir-sind-cool.org> On Sun, 24 Dec 2006 20:58:40 -0500, Eric S. Raymond wrote: > > make new-sources FILES="foo-2.0.tar.bz2 foo-data-2.0.tar.bz2" > > blah-blah > foo.spec > > make clog > > make commit -F clog > > make tag && make build > > > > However, before you think you feel capable enough to script that and > > submit each and every update like that, you still cannot avoid spending > > time on creating good quality packages which are not infested with lots of > > packaging bugs. > > I agree with you. What I don't understand is why you think this has > anything to do with my complaint. No matter how much stuff I have to > do before the mechanical part of shipping, when it gets to that > mechanical part, I want to *push a button and be done*! Its relevance is in the fundamental requirements of being a Fedora Extras packager who has a deeper interest beyond just dumping something into another repository. In order to be able to produce fine packages and avoid many packaging pitfalls you need to understand and accept things like packaging guidelines and/or policies. Else you won't have fun with "using CVS tags for package releases", %{?dist} tag macros, invalid rpaths and things like that. Whether you're done with the push of a button depends a lot on whether your input to the Fedora Extras build system is sufficient and whether the package will build in "mock", for example. Over time it is likely that automated post-build package tests will be added. I still find that updating a source rpm or packages files in CVS and submitting a build job takes the least time. Evaluating new releases, updating the spec files, building test-builds and testing the test-builds takes much more time if it's done painstakingly. > > > I've still got the bloody printed application form on my desk. But > > > I never filled it out because nobody persuaded me that I wouldn't > > > be letting myself in for a nightmare of bureaucracy and repetitive > > > hand-work. > > > > FUD. > > Yes, FUD. Too much FUD in your process, or at least your representation > of it to the world. You need to fix that. Can you point to existing documentation which you refer to? From knightmerc at yahoo.com Mon Dec 25 02:27:50 2006 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Sun, 24 Dec 2006 21:27:50 -0500 Subject: ESR "fedora-submit" In-Reply-To: References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> Message-ID: <1167013670.29306.53.camel@localhost.localdomain> On Sun, 2006-12-24 at 19:09 -0500, Konstantin Ryabitsev wrote: > On 12/24/06, Eric S. Raymond wrote: > > The question remains. Do I have to *do shit by hand* > > Why not, you're doing an admirable job so far. > > Regards, > -- > Konstantin Ryabitsev > Montr?al, Qu?bec > Why don't you answer his question in a civilized manner instead of being some punk asshole? LX From sundaram at fedoraproject.org Mon Dec 25 02:25:53 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 25 Dec 2006 07:55:53 +0530 Subject: ESR "fedora-submit" In-Reply-To: <1167013670.29306.53.camel@localhost.localdomain> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <1167013670.29306.53.camel@localhost.localdomain> Message-ID: <458F36B1.2060502@fedoraproject.org> Lyvim Xaphir wrote: > On Sun, 2006-12-24 at 19:09 -0500, Konstantin Ryabitsev wrote: >> On 12/24/06, Eric S. Raymond wrote: >>> The question remains. Do I have to *do shit by hand* >> Why not, you're doing an admirable job so far. >> >> Regards, >> -- >> Konstantin Ryabitsev >> Montr?al, Qu?bec >> > > Why don't you answer his question in a civilized manner instead of being > some punk asshole? > Amusing. You contradict yourself. Rahul From esr at thyrsus.com Mon Dec 25 02:35:26 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 24 Dec 2006 21:35:26 -0500 Subject: ESR "fedora-submit" In-Reply-To: <604aa7910612241821y60e7a469l6057206767a450@mail.gmail.com> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <1167005888.6039.9.camel@localhost.localdomain> <604aa7910612241654y32335934j15791eee80abfb2b@mail.gmail.com> <20061225015211.GE19176@thyrsus.com> <604aa7910612241821y60e7a469l6057206767a450@mail.gmail.com> Message-ID: <20061225023526.GL19176@thyrsus.com> Jeff Spaleta : > >See, now *this* is material to the issue in a way that Warren Togami > >stupidly and arrogantly telling me I'm "on crack" is not. > > Shrug, just as long as you realize that nothing I'm saying now should > be interpreted as endorsement of any idea you may have now, may have > had in the past, or might have in the future. And you should know > that I reserve the right to verbally rip out your spleen through your > left ear if I find that you have decided to quote anything I say out > of context and without direct citation back to this mailinglist > archive. Fair enough :-). > What rpmlint does is not fully equivalent to what people do when they > read over specfiles. Right, I understand that. I'm guessing that the things you have to check by eyeball are in parts of specfiles that don't tend to change every point release, though. > It would help however if you got re-acquainted with the fedora > contributor policy state-of-the-art. > > http://fedoraproject.org/wiki/Extras/Contributors I shall do so. -- Eric S. Raymond From esr at thyrsus.com Mon Dec 25 02:38:13 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Sun, 24 Dec 2006 21:38:13 -0500 Subject: ESR "fedora-submit" In-Reply-To: <20061225032653.0600bf38.fedora@wir-sind-cool.org> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <20061225021411.7093bf53.fedora@wir-sind-cool.org> <20061225015840.GF19176@thyrsus.com> <20061225032653.0600bf38.fedora@wir-sind-cool.org> Message-ID: <20061225023813.GM19176@thyrsus.com> Michael Schwendt : > > Yes, FUD. Too much FUD in your process, or at least your representation > > of it to the world. You need to fix that. > > Can you point to existing documentation which you refer to? I probably should have mentioned sooner that the form on my desk was pretty scary. Of course, by what you guys are saying now, it's probably obsolete. -- Eric S. Raymond From icon at fedoraproject.org Mon Dec 25 02:41:48 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Sun, 24 Dec 2006 21:41:48 -0500 Subject: ESR "fedora-submit" In-Reply-To: <1167013670.29306.53.camel@localhost.localdomain> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <1167013670.29306.53.camel@localhost.localdomain> Message-ID: On 12/24/06, Lyvim Xaphir wrote: > Why don't you answer his question in a civilized manner instead of being > some punk asshole? Hey-hey, now. I'm goth, GOTH asshole. -kvr -- Konstantin Ryabitsev Montr?al, Qu?bec From jspaleta at gmail.com Mon Dec 25 02:47:16 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 24 Dec 2006 17:47:16 -0900 Subject: ESR "fedora-submit" In-Reply-To: <20061225023526.GL19176@thyrsus.com> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <1167005888.6039.9.camel@localhost.localdomain> <604aa7910612241654y32335934j15791eee80abfb2b@mail.gmail.com> <20061225015211.GE19176@thyrsus.com> <604aa7910612241821y60e7a469l6057206767a450@mail.gmail.com> <20061225023526.GL19176@thyrsus.com> Message-ID: <604aa7910612241847m25093839tf449aa2197983deb@mail.gmail.com> On 12/24/06, Eric S. Raymond wrote: > I shall do so. while your at it, you can use anonymous cvs check-out and get the common module and look over Makefile, Makefile.common and cvs.import.sh so you can poke at the internals of what makes cvs based contributor access work now-a-days. -jef From knightmerc at yahoo.com Mon Dec 25 02:53:00 2006 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Sun, 24 Dec 2006 21:53:00 -0500 Subject: ESR "fedora-submit" In-Reply-To: References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <1167013670.29306.53.camel@localhost.localdomain> Message-ID: <1167015180.29306.67.camel@localhost.localdomain> On Sun, 2006-12-24 at 21:41 -0500, Konstantin Ryabitsev wrote: > On 12/24/06, Lyvim Xaphir wrote: > > Why don't you answer his question in a civilized manner instead of being > > some punk asshole? > > Hey-hey, now. I'm goth, GOTH asshole. > > -kvr Thanks, it all makes sense now. LX From lamont at gurulabs.com Mon Dec 25 05:19:55 2006 From: lamont at gurulabs.com (Lamont Peterson) Date: Sun, 24 Dec 2006 22:19:55 -0700 Subject: LVM not fit for default In-Reply-To: <458C5295.9020805@warmcat.com> References: <458B115B.7060606@cox.net> <200612221215.15365.lamont@gurulabs.com> <458C5295.9020805@warmcat.com> Message-ID: <200612242220.00217.lamont@gurulabs.com> On Friday 22 December 2006 02:48pm, Andy Green wrote: > Lamont Peterson wrote: > > LVM is one of the coolest things there is. Many people don't understand > > the basics of how & why LVM is, simply because they don't know where to > > get the > > When LVM fails though, there are no recovery tools. You can recover the > filesystem inside an LVM (I speak from experience) but your only friends > are dd and a hex editor. There is no redundancy unlike genuine > filesystems like ext2/3, if the LVM chunk before the actual filesystem > is corrupted, the volume won't mount as LVM and that's your lot from the > One True Way. > > LVM binding raided storage together makes sense and buys you something. > LVM being the default -- even for a laptop that cannot increase its > permanent storage -- only has the capacity to make a crisis into a > disaster. On my laptops, the hard drive is quite a bit bigger than I "knew what to do with" at the time I installed. For example, this notebook has an 80GB drive. The last 20GB is WinXP, the first 100MB is /boot/, the next 1GB is swap and the rest is LVM (4 partitions total). When I installed FC on here, I created a 512MB /, 3GB /usr/, 256MB /var/, 128MB /var/log/, 128MB /tmp/ and 5GB /home/. Later, I created a 2GB /var/lib/mysql/, 2GB /var/lib/pgsql/ and a 10GB /download/. At one point, I was playing around with a 4GB /opt/oracle/ and a 4GB /opt/db2/. I once expanded /home/ to 15GB and /download/ to 10GB while downloading some DVD .iso files. Even on a notebook, without RAID, I've found that being able to reallocate space to/from LVs to grow/shrink the filesystems has been incredibly handy. Of course, the alternatives are use one big / partition (that sucks) or keep moving partitions around in order to grow/shrink filesystems (that sucks, too). I think I'll stick with LVM. BTW, I'm thinking that my next notebook just might be one of these models that can house 2 2.5-inch hard drives internally (not in a docking bay) and use LVM on RAID1. As much traveling as I do, I have lost a couple of hard drives over the years (I have another that started exhibiting bad sectors just the other day). -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lamont at gurulabs.com Mon Dec 25 05:24:00 2006 From: lamont at gurulabs.com (Lamont Peterson) Date: Sun, 24 Dec 2006 22:24:00 -0700 Subject: LVM not fit for default In-Reply-To: <20061224112233.21380@gmx.net> References: <458B115B.7060606@cox.net> <77FAA761-5839-499B-9269-087008CB53D8@gmail.com> <20061224112233.21380@gmx.net> Message-ID: <200612242224.00898.lamont@gurulabs.com> On Sunday 24 December 2006 04:22am, Joachim Frieben wrote: > > First of all I have experienced the same "no help hell" with lvm when > > it crashes. (not if, when) I had FC3 installed on my Compaq R3000 > > Series notebook, default settings, except for package options. Ran > > that for about three weeks. I reinstall testing out new distros quite > > a lot, so I don't worry about backing up the entire system, and > > something happened with the system, the kernel panicked when it > > couldn't find a root FS. Same problem as andy. > > > > Basically All I'm trying to say is that yes it fails sometime, no it > > is a cool thing to have, but either give us some tools on default > > install/rescue disc to combat the issue, or take it out unless the > > system detects a RAID array. > > > > Thanks guys, > > > > Chris > > Come on, "FC3" got released *three*years* ago, FC1 was released in November of 2003, just after RHEL3 (October 2003). FC3 was released in November 2004. Last I checked 2006 - 2004 = 2 years ago. > so it's not appropriate to > make an argument out of this for discussing today's maturity of "LVM". Btw, > I have been using "LVM" exclusively for 3 years now [exact, since I first > installed "FC3"], and I have never ever had any trouble with it at all. > Maybe you encountered a hardware problem? Likely in my mind. BTW, I've been using LVM on all my notebooks and workstations since FC1/RHEL3 and have been using it on all my servers for nearly 7 years. I've never encountered a problem that couldn't be fixed with the LVM commands other than outright hardware (i.e. storage) failure. -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lamont at gurulabs.com Mon Dec 25 05:29:56 2006 From: lamont at gurulabs.com (Lamont Peterson) Date: Sun, 24 Dec 2006 22:29:56 -0700 Subject: LVM not fit for Fedora Core In-Reply-To: <1166827973.16457.22.camel@gilboa-home-dev.localdomain> References: <458B115B.7060606@cox.net> <458C16C2.8080400@BitWagon.com> <1166827973.16457.22.camel@gilboa-home-dev.localdomain> Message-ID: <200612242229.56799.lamont@gurulabs.com> On Friday 22 December 2006 03:52pm, Gilboa Davara wrote: > On Fri, 2006-12-22 at 09:32 -0800, John Reiser wrote: [snip] > -grub- doesn't support LVM. > (Same goes for xfs, reiserfs and at least 95 other file systems) On FC5 (this notebook): # ls /boot/grub/ default fat_stage1_5 jfs_stage1_5 reiserfs_stage1_5 stage2.old device.map ffs_stage1_5 menu.lst splash.xpm.gz ufs2_stage1_5 device.map.old grub.conf menu.lst.old stage1 vstafs_stage1_5 e2fs_stage1_5 iso9660_stage1_5 minix_stage1_5 stage2 xfs_stage1_5 I see xfs and reiserfs there. IIRC, both have been present in GRUB at least as far back as RHL8.0, though xfs might not have appeared until FC2 (I don't remember for sure, but I think it was there earlier). [snip] -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gilboad at gmail.com Mon Dec 25 10:25:03 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 25 Dec 2006 12:25:03 +0200 Subject: LVM not fit for Fedora Core In-Reply-To: <200612242229.56799.lamont@gurulabs.com> References: <458B115B.7060606@cox.net> <458C16C2.8080400@BitWagon.com> <1166827973.16457.22.camel@gilboa-home-dev.localdomain> <200612242229.56799.lamont@gurulabs.com> Message-ID: <1167042303.22791.4.camel@gilboa-work-dev.localdomain> On Sun, 2006-12-24 at 22:29 -0700, Lamont Peterson wrote: > On Friday 22 December 2006 03:52pm, Gilboa Davara wrote: > > On Fri, 2006-12-22 at 09:32 -0800, John Reiser wrote: > [snip] > > -grub- doesn't support LVM. > > (Same goes for xfs, reiserfs and at least 95 other file systems) > > On FC5 (this notebook): > > # ls /boot/grub/ > default fat_stage1_5 jfs_stage1_5 reiserfs_stage1_5 > stage2.old > device.map ffs_stage1_5 menu.lst splash.xpm.gz > ufs2_stage1_5 > device.map.old grub.conf menu.lst.old stage1 > vstafs_stage1_5 > e2fs_stage1_5 iso9660_stage1_5 minix_stage1_5 stage2 > xfs_stage1_5 > > I see xfs and reiserfs there. IIRC, both have been present in GRUB at least > as far back as RHL8.0, though xfs might not have appeared until FC2 (I don't > remember for sure, but I think it was there earlier). I stand corrected then. Last time I tried using boot on xfs (back in FC3) it failed miserably. (root (hdx,x) failed to detect the stage 1.5) Never the less, it does not change what I said. Grub doesn't support software RAID5/6 - should I stop using them? - Gilboa From jfrieben at gmx.de Mon Dec 25 10:33:54 2006 From: jfrieben at gmx.de (Joachim Frieben) Date: Mon, 25 Dec 2006 11:33:54 +0100 Subject: LVM not fit for default In-Reply-To: <200612242224.00898.lamont@gurulabs.com> References: <458B115B.7060606@cox.net> <77FAA761-5839-499B-9269-087008CB53D8@gmail.com> <20061224112233.21380@gmx.net> <200612242224.00898.lamont@gurulabs.com> Message-ID: <20061225103354.19870@gmx.net> Err, sorry for the wrong figure: indeed "FC3" has been released in late 2004. Thanks for correcting me! However, this still means more that 2 years of flawless operation of "LVM" on my various "GNU/Linux" systems running "Fedora Core". ;o) And as stated elsewhere, "LVM" was a proven and mature technology long time ago, e.g. I used to set up some "HP/UX" boxes back in 2001 and was immediately convinced by the benefits of this technology. > > Come on, "FC3" got released *three*years* ago, > > FC1 was released in November of 2003, just after RHEL3 (October 2003). > FC3 > was released in November 2004. Last I checked 2006 - 2004 = 2 years ago. -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer From drago01 at gmail.com Mon Dec 25 10:42:52 2006 From: drago01 at gmail.com (dragoran) Date: Mon, 25 Dec 2006 11:42:52 +0100 Subject: packet writing In-Reply-To: <20061224160851.GB32361@ryvius.pekin.waw.pl> References: <564d96fb0612240646mfa9f5b9q5703b0a7c1c5ba6c@mail.gmail.com> <20061224160851.GB32361@ryvius.pekin.waw.pl> Message-ID: <458FAB2C.6060601@gmail.com> Dominik 'Rathann' Mierzejewski wrote: > On Sunday, 24 December 2006 at 15:46, Rafael Esp?ndola wrote: > >> Fedora 6 has a very minimal support for packet writing. I was able to >> use it, but I had to run pktsetup and mount manually. >> >> Debian has an init script that runs pktsetup for each cd rw driver. >> The list of cd rw drivers is read from a config file. >> >> It should be easy to port this script, but I think that we can do >> better. I am planning to write an udev rule to run pktsetup every time >> check-cdrom.sh detects a cd-rw or a dvd-rw. Do you think that it would >> be a good thing to do? >> > > +1 > This will be most useful. After all, UDF-formatted RW media was supposed > to be used like any removable RW storage device, so it should be as easy > to use, as, for example, a USB stick. > > Regards, > R. > > +1 this should be added to the udftools package.. From buildsys at redhat.com Mon Dec 25 11:02:27 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 25 Dec 2006 06:02:27 -0500 Subject: rawhide report: 20061225 changes Message-ID: <200612251102.kBPB2RYh020535@hs20-bc2-6.build.redhat.com> Updated Packages: selinux-policy-2.4.6-18.fc7 --------------------------- * Sat Dec 23 2006 Dan Walsh 2.4.6-18 - Many fixes for strict policy and by extension mls. Broken deps for i386 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 Broken deps for ppc64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) Broken deps for x86_64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) Broken deps for s390 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ia64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) Broken deps for ppc ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 Broken deps for s390x ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) From dominik at greysector.net Mon Dec 25 14:46:10 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 25 Dec 2006 15:46:10 +0100 Subject: Development machine setup for both i386 and x86_64 work In-Reply-To: <6.2.1.2.2.20061224082832.02203ab8@mailone.real.com> References: <6.2.1.2.2.20061222004303.462804b0@mailone.real.com> <1166868786.16008.2.camel@max.booze> <6.2.1.2.2.20061224082832.02203ab8@mailone.real.com> Message-ID: <20061225144610.GA4731@ryvius.pekin.waw.pl> On Sunday, 24 December 2006 at 17:31, Daniel Yek wrote: > At 02:13 AM 12/23/2006, Callum Lerwick wrote: > >On Fri, 2006-12-22 at 01:13 -0800, Daniel Yek wrote: > >> Hi, > >> > >> How Fedora developers set up dev. machines to do both 32-bit and 64-bit > >> development on a single AMD64 machine? > >> > >> Does it complicate 32-bit dev. work if the development machine is set up > >> with x86_64 Fedora Core OS? > > > >I just compile for i386 using mock. Works great, assuming you > >obsessively RPM package everything you deploy to other machines like I > >do. :) > > > Sound cool, but I would be happier if you would point me to information > about mock -- how to use it and what it is for, etc. Didn't find too much > useful information googling... yum install mock man mock Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From smooge at gmail.com Mon Dec 25 20:38:24 2006 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 25 Dec 2006 13:38:24 -0700 Subject: ESR "fedora-submit" In-Reply-To: <458ED888.6050608@redhat.com> References: <458ED888.6050608@redhat.com> Message-ID: <80d7e4090612251238p5eb97cder2e2a28b9a1ff378c@mail.gmail.com> On 12/24/06, Warren Togami wrote: > http://www.catb.org/~esr/fedora-submit/ > "fedora-submit will be a command-line tool that ships RPMs to the Fedora > project for inclusion in their repository. It will ship with a future > release of Fedora Core." > > No it will not. > > "Warren Togami > Fedora project honcho. Has backed this concept." > > I am not the "honcho", and I have never supported your crack-filled ideas. > > Dear ESR, > > Nobody in the Fedora Project has endorsed your fedora-submit tool. We > have stated on multiple occasions that your reasons for fedora-submit > *COMPLETELY MISS THE POINT*. By the existence of this page with its > stated falsehoods you potentially confuse the community into thinking > that we support your idea. > > Please delete this page, or at least remove the false statements. Was this email and the rest of the replies really necessary to a public list? Calling out Eric Raymond on a public list is like shooting fish in a barrel with peppershot, you are going to get a response and in the end it will smell pretty bad. A set of private emails would have been a better channel, and if they didn't get what you want a comment to the Fedora Advisory Board and on a web-page that the data was not-accurate would have been ok. -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From wtogami at redhat.com Mon Dec 25 21:48:51 2006 From: wtogami at redhat.com (Warren Togami) Date: Mon, 25 Dec 2006 16:48:51 -0500 Subject: ESR "fedora-submit" In-Reply-To: <80d7e4090612251238p5eb97cder2e2a28b9a1ff378c@mail.gmail.com> References: <458ED888.6050608@redhat.com> <80d7e4090612251238p5eb97cder2e2a28b9a1ff378c@mail.gmail.com> Message-ID: <45904743.8040103@redhat.com> Stephen John Smoogen wrote: > > Was this email and the rest of the replies really necessary to a > public list? Calling out Eric Raymond on a public list is like > shooting fish in a barrel with peppershot, you are going to get a > response and in the end it will smell pretty bad. A set of private > emails would have been a better channel, and if they didn't get what > you want a comment to the Fedora Advisory Board and on a web-page that > the data was not-accurate would have been ok. > You are correct. It was not the best idea to complain about this in public. I apologize for unnecessarily sparking this flamewar here. Warren Togami wtogami at redhat.com From jkeating at redhat.com Mon Dec 25 22:50:18 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 25 Dec 2006 17:50:18 -0500 Subject: ESR "fedora-submit" In-Reply-To: <20061224235740.GA19176@thyrsus.com> References: <458ED888.6050608@redhat.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> Message-ID: <200612251750.22071.jkeating@redhat.com> On Sunday 24 December 2006 18:57, Eric S. Raymond wrote: > Can I write a procedure in shell or Python, to be invoked by > 'make ship' from my project's top-level makefile, that will automate > my release process so I *don't have to think about it*? > > I *don't* *fucking* *care* ?what happens on the back end. If one > of the possible consequences is email bounceback that says "your > point release failed QA because *BLAH*, that's OK. ?I'll fix the > problem and try again. One big thing you need to think about is that within the Fedora package infrastructure, spec files are managed outside of tarballs. One side effect to this is that the specfile can change between tarball releases, be it for an automated rebuild (many reasons), update for new package guidelines, change in a BuildRequires stack, etc... These changes can happen in the package SCM which is outside of the source SCM by nature. Therefor, you can't always blindly shove what comes from upstream into our package infrastructure without making sure that nothing has changed downstream first. Doing this has led to re-introduction of bugs in packaging, inconsistent package changelogs, etc... There really is a difference between downstream and upstream. Fedora is a downstream of many upstream projects. Many times the upstream maintainer/author is the same as the downstream, but there are different needs/procedures that need to be kept in mind. However, quite often the downstream maintainer is _not_ the upstream, for many reasons. Sometimes its a time issue, upstream doesn't want to deal with downstream issues (yes, there are more issues than just 'get my latest release into downstream, local rebuilds, SCM changes, guideline updates, release freezes, etc...), othertimes it is to prevent a conflict of interst. Downstream interests are at times different than upstreams. Release timelines, features, freezes, but priorities, all of these things could lead to conflicts if the same person runs upstream as downstream. So, while a tool to automatically do an upstream _and_ downstream release might be nice/interesting, it by nature cannot handle many of the things I've outlined above. Instead what can be done, if you're upstream process produces an srpm that is suitable for the Fedora infrastructure, you can make use of the cvs-import.sh script which can import an srpm onto a given "branch". This automates the update of the source tarball and spec file changes. If (this is a BIG IF) you _KNOW_ that no changes have been made that your upstream spec doesn't take into consideration, it can be used to import the new release. 'make tag build' still needs to be ran, and frankly that could be scriptable as part of the script that handles cvs-import.sh, but as I said there are many issues that a human has to take into consideration when doing a downstream release. Especially on released branches, where we're moving to doing specific updates with email notifications which will require even more human thought/consideration. You can't just bump a package that will break a ton of deps, that's irresponsible as a downstream maintainer. Not something that an upstream maintainer will really care about, but most certainly something a downstream should. I think the bottom line here (sorry for the long email) is that for YOU Eric, it may not be in your best interst to be both the upstream and the downstream maintainer of your software. It may be better for you to find an intersted party to be your downstream within Fedora who will keep all the above issues (and more!) in mind while doing releases of your software for us. This allows you to continue doing the upstream thing as you need, and we the downstream will consume it when it is appropriate and in a way that is appropriate. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dcbw at redhat.com Mon Dec 25 22:56:08 2006 From: dcbw at redhat.com (Dan Williams) Date: Mon, 25 Dec 2006 17:56:08 -0500 Subject: FC-6-i386-livecd-1.iso boot sequence errors In-Reply-To: <010f01c726e1$641f52e0$0200a8c0@AMD2500> References: <010f01c726e1$641f52e0$0200a8c0@AMD2500> Message-ID: <1167087368.2938.8.camel@localhost.localdomain> On Sat, 2006-12-23 at 22:26 +0000, Aaron Gray wrote: > Hello, > > Got two different errors in startup sequence. > > The following error repeated about 12 times in boot up sequence :- > > Illegal mode for this track or incomplete medium > The failed "Read 10" packet command was: > Buffer I/O error on device hdd, logical block xxxxxx > > The CD was verified after writing, and SHA checked. > > Then later in boot up sequence we have :- > > Starting system message bus: Unknown group "netdev" in message bus > configuration file The avahi project added some Debian specific bits to their config file upstream, which sneaked into the Fedora packages via an update. This was also the cause of the recent 'yum update' breakage that would kill X and screw up your yum update leaving duplicate packages. The avahi dbus config file needs to have the Debian specific bits removed, and an update pushed. The message is harmless, and the operation of Avahi is unaffected however. Dan > > Though I should report these to the list. > > Aaron > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From dcbw at redhat.com Mon Dec 25 22:57:48 2006 From: dcbw at redhat.com (Dan Williams) Date: Mon, 25 Dec 2006 17:57:48 -0500 Subject: FC-6-i386-livecd-1.iso boot sequence errors In-Reply-To: <002001c72789$a3ca3790$0200a8c0@AMD2500> References: <010f01c726e1$641f52e0$0200a8c0@AMD2500> <20061224153738.GA3550@kerouac> <002001c72789$a3ca3790$0200a8c0@AMD2500> Message-ID: <1167087468.2938.11.camel@localhost.localdomain> On Sun, 2006-12-24 at 18:30 +0000, Aaron Gray wrote: > >> >Then later in boot up sequence we have :- > >> > > >> > Starting system message bus: Unknown group "netdev" in message bus > >> >configuration file > >> > >> I am also seeing this one, but with a regular installation in my > >> laptop. Is it something worth a BZ ticket? > > > >This is caused by the avahi package. Since I?m not using that service, > >this fixes the error message on dbus startup for me: > > > > # mv /etc/dbus-1/system.d/avahi-dbus.conf{,.broken} > > > >Or you can try adding a netdev group? > > > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219218 > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=219269 The netdev group stuff is debian specific and not needed on Fedora. Change the text 'group="netdev"' to 'at_console="true"' and you'll fix it. Dan > Many thanks, > > Aaron > From esr at thyrsus.com Tue Dec 26 04:47:34 2006 From: esr at thyrsus.com (Eric S. Raymond) Date: Mon, 25 Dec 2006 23:47:34 -0500 Subject: ESR "fedora-submit" In-Reply-To: <200612251750.22071.jkeating@redhat.com> References: <458ED888.6050608@redhat.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <200612251750.22071.jkeating@redhat.com> Message-ID: <20061226044734.GC12744@thyrsus.com> Jesse Keating : > I think the bottom line here (sorry for the long email) is that for > YOU Eric, it may not be in your best interst to be both the upstream > and the downstream maintainer of your software. It may be better > for you to find an intersted party to be your downstream within > Fedora who will keep all the above issues (and more!) in mind while > doing releases of your software for us. This allows you to continue > doing the upstream thing as you need, and we the downstream will > consume it when it is appropriate and in a way that is appropriate. This was also a constructive response; thank you. You may be correct in your argument that I shouldn't try to fill both roles. But I promised to evaluate your contributor guidelines, and I've taken Michael Schwendt's suggestion that the best way to do that would be to try to push a package through the system and see what I discover on the way. One positive thing I can tell you about the early stages is that I am rather impressed with rpmlint. -- Eric S. Raymond From aphukan at redhat.com Tue Dec 26 09:42:45 2006 From: aphukan at redhat.com (Amitakhya Phukan) Date: Tue, 26 Dec 2006 15:12:45 +0530 Subject: help for firefox needed Message-ID: <4590EE95.6080607@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi all! first of all, serious apologies if this mail shouldn't have been in this list. I was initially having RHEL4 U4 in my laptop and was able to listen to most of the music online. Trouble has started now with FC6. The site is : musicindiaonline.com. I try to listen to any music here..the thing is that, it pops out a winidow which detects the presence of Java and players installed. Then it asks for choosing a player between RealPlayer and Windows Media Player. I choose RealPlayer and click ok button (or whatever is there). It then doesn't play the song/music but throws an error window stating --- Error: Methods Missing. Please help. I have realplay, mplayer etc all installed. I am able to play mpeg,ogg files but from sites like the one I mentioned above, I am not able to listen to any music. The same error is thrown in Seamonkey and epiphany. Regards, Amitakhya Phukan. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFkO6UDlUL5E3antERAifmAJ9I2IAledFvo12sr+ZmJPvxSuUKrgCgwmDV NQehgMntvv7gDSIyr/E/z0Y= =Wrfo -----END PGP SIGNATURE----- From buildsys at redhat.com Tue Dec 26 10:43:19 2006 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 26 Dec 2006 05:43:19 -0500 Subject: rawhide report: 20061226 changes Message-ID: <200612261043.kBQAhJ4a026786@hs20-bc2-6.build.redhat.com> Updated Packages: e2fsprogs-1.39-9 ---------------- * Mon Dec 25 2006 Thomas Woerner - 1.39-9 - build fixes for new automake 1.10 (#220715) * Mon Dec 18 2006 Thomas Woerner - 1.39-8 - make uuid_generate_time generate unique uuids (#218606) * Wed Sep 20 2006 Jarod Wilson - 1.39-7 - 32-bit 16T fixups from esandeen (#202807) - Update summaries and descriptions gphoto2-2.3.1-1.fc7 ------------------- * Mon Dec 25 2006 Jindrich Novy 2.3.1-1 - update to 2.3.1 - merry christmas! Broken deps for i386 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.i386 requires libpq.so.4 Broken deps for ppc64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc64 requires libpq.so.4()(64bit) Broken deps for x86_64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.x86_64 requires libpq.so.4()(64bit) Broken deps for s390 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390 requires libpq.so.4 systemtap - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.10-1.fc7.s390 requires kernel >= 0:2.6.9-11 Broken deps for ppc ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ppc requires libpq.so.4 Broken deps for ia64 ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.ia64 requires libpq.so.4()(64bit) Broken deps for s390x ---------------------------------------------------------- cyrus-sasl-sql - 2.1.22-4.s390x requires libpq.so.4()(64bit) From n0dalus+redhat at gmail.com Tue Dec 26 11:15:25 2006 From: n0dalus+redhat at gmail.com (n0dalus) Date: Tue, 26 Dec 2006 21:45:25 +1030 Subject: help for firefox needed In-Reply-To: <4590EE95.6080607@redhat.com> References: <4590EE95.6080607@redhat.com> Message-ID: <6280325c0612260315yac58109v72e7cfe1451479af@mail.gmail.com> On 12/26/06, Amitakhya Phukan wrote: > > first of all, serious apologies if this mail shouldn't have been in > this list. > Yeah, this kind of thing really belongs in fedora-users. n0dalus. From lamont at gurulabs.com Tue Dec 26 18:16:44 2006 From: lamont at gurulabs.com (Lamont Peterson) Date: Tue, 26 Dec 2006 11:16:44 -0700 Subject: LVM not fit for Fedora Core In-Reply-To: <1167042303.22791.4.camel@gilboa-work-dev.localdomain> References: <458B115B.7060606@cox.net> <200612242229.56799.lamont@gurulabs.com> <1167042303.22791.4.camel@gilboa-work-dev.localdomain> Message-ID: <200612261116.51019.lamont@gurulabs.com> On Monday 25 December 2006 03:25am, Gilboa Davara wrote: > On Sun, 2006-12-24 at 22:29 -0700, Lamont Peterson wrote: > > On Friday 22 December 2006 03:52pm, Gilboa Davara wrote: > > > On Fri, 2006-12-22 at 09:32 -0800, John Reiser wrote: > > > > [snip] > > > > > -grub- doesn't support LVM. > > > (Same goes for xfs, reiserfs and at least 95 other file systems) > > > > On FC5 (this notebook): > > > > # ls /boot/grub/ > > default fat_stage1_5 jfs_stage1_5 reiserfs_stage1_5 > > stage2.old > > device.map ffs_stage1_5 menu.lst splash.xpm.gz > > ufs2_stage1_5 > > device.map.old grub.conf menu.lst.old stage1 > > vstafs_stage1_5 > > e2fs_stage1_5 iso9660_stage1_5 minix_stage1_5 stage2 > > xfs_stage1_5 > > > > I see xfs and reiserfs there. IIRC, both have been present in GRUB at > > least as far back as RHL8.0, though xfs might not have appeared until FC2 > > (I don't remember for sure, but I think it was there earlier). > > I stand corrected then. > Last time I tried using boot on xfs (back in FC3) it failed miserably. > (root (hdx,x) failed to detect the stage 1.5) > Never the less, it does not change what I said. > Grub doesn't support software RAID5/6 - should I stop using them? You are correct there, and I agree with you. What GRUB supports has nothing to do with what the kernel supports. GRUB reads the kernel (vmlinuz) and initrd into memory and punts the ball. From that point on, GRUB support doesn't matter. FYI, I use reiserfs, xfs and (sometimes) ext3 for my systems' partitions, but I always use ext3 for /boot/ (100-250MB, depending on how many distros are to be installed). BTW, just for the benefit of those reading this in the archives in the future, GRUB will work when /boot/ is on top of software RAID1, but it is rarely done as one might have to alter the /boot/grub/grub.conf (/boot/grub/menu.lst on all other distros) to read the correct disk the first one goes out. For example, changing (hd0,0) to (hd1.0) throughout the file. -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jjoe at flummiball.de Tue Dec 26 19:23:43 2006 From: jjoe at flummiball.de (Jonas G) Date: Tue, 26 Dec 2006 20:23:43 +0100 Subject: help for firefox needed In-Reply-To: <4590EE95.6080607@redhat.com> References: <4590EE95.6080607@redhat.com> Message-ID: <459176BF.1040401@flummiball.de> hi! maybe you should install mozilla-vlc-plugin or mozilla-totem-plugin jonas Amitakhya Phukan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > hi all! > > first of all, serious apologies if this mail shouldn't have been in > this list. > > I was initially having RHEL4 U4 in my laptop and was able to listen to > most of the music online. Trouble has started now with FC6. > > The site is : musicindiaonline.com. > > I try to listen to any music here..the thing is that, it pops out a > winidow which detects the presence of Java and players installed. Then > it asks for choosing a player between RealPlayer and Windows Media > Player. I choose RealPlayer and click ok button (or whatever is > there). It then doesn't play the song/music but throws an error window > stating --- Error: Methods Missing. > > Please help. I have realplay, mplayer etc all installed. I am able to > play mpeg,ogg files but from sites like the one I mentioned above, I > am not able to listen to any music. The same error is thrown in > Seamonkey and epiphany. > > Regards, > Amitakhya Phukan. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFFkO6UDlUL5E3antERAifmAJ9I2IAledFvo12sr+ZmJPvxSuUKrgCgwmDV > NQehgMntvv7gDSIyr/E/z0Y= > =Wrfo > -----END PGP SIGNATURE----- > > From jwboyer at jdub.homelinux.org Tue Dec 26 19:33:23 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 26 Dec 2006 13:33:23 -0600 Subject: ESR "fedora-submit" In-Reply-To: <45904743.8040103@redhat.com> References: <458ED888.6050608@redhat.com> <80d7e4090612251238p5eb97cder2e2a28b9a1ff378c@mail.gmail.com> <45904743.8040103@redhat.com> Message-ID: <20061226193322.GA23475@yoda.jdub.homelinux.org> On Mon, Dec 25, 2006 at 04:48:51PM -0500, Warren Togami wrote: > Stephen John Smoogen wrote: > > > >Was this email and the rest of the replies really necessary to a > >public list? Calling out Eric Raymond on a public list is like > >shooting fish in a barrel with peppershot, you are going to get a > >response and in the end it will smell pretty bad. A set of private > >emails would have been a better channel, and if they didn't get what > >you want a comment to the Fedora Advisory Board and on a web-page that > >the data was not-accurate would have been ok. > > > > You are correct. It was not the best idea to complain about this in > public. I apologize for unnecessarily sparking this flamewar here. It hasn't resulted in all badness. Eric has at least said he'd go off and evaluate the current process to see if he can write tools to script some things. One that will need to be able to adapt to policy changes and possible future technical adaptations. If that results in a tool for others to use, great. If not, well at least it was an entertaining read. josh From jspaleta at gmail.com Tue Dec 26 21:06:35 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 26 Dec 2006 12:06:35 -0900 Subject: Does Core have an accurate count of packages which are built against libraries from firefox? Message-ID: <604aa7910612261306p4a5e32cagbf44d0fe87862c01@mail.gmail.com> Since the last firefox update I have been trying to trackdown ALL the packages which are affected by the change in location of libraries that come in the versioned firefox. The problem here is, is that the autogenerated requires on libraries doesn't catch the fact that the library has moved, so you won't actually get any depchain errors from rpm. This makes its pretty tough to track all the affected packages down as an end-user without installing the world. Does anyone anywhere have a complete list of affected packages, or is clever enough to generate such a list programmatically that doesn't involved installing all of fedora space? In Core I already know about gnome-python2-extras because it affected applications that I use. But I just ran into the fact that esc was also affect by the firefox update by accident. /usr/lib/esc-1.0.0/xulrunner/xulrunner-bin links against libmozjs.so libxpcom.so which can't be found by the linker since these are both packages in the versioned firefox directory tree. My god damn home workstation died yesterday(merry christmas to me!) so if someone else can bugzilla this before I get a chance...go right ahead. The main point of this post however is that I don't think we are doing a good job of coordinating maintainers so they can respond as quickly as possible when a firefox update is pushed so they can rebuild their packages. We've had a lovely little chat in #fedora-extras with the firefox maintainer, and he's absolutely right there needs to be a toolized way for each maintainer with a package who builds against firefox to set a sort of watch in the build or update system against firefox looking for new builds. So what exactly can we do, in the form of policy and in the form toolized automation which can help prevent or mitigate an unreasonable amount of lag between when a firefox package is built and when maintainers finally notice that other packages need to be rebuilt? Are there additional review steps we can do to check for this condition at the time of package review? The Core packages have to be reviewed before the merger right? I'd like to see if we can bury this issue as part of those reviews. Should everyone building against firefox libraries be using versioned firefox requires? Can we add an rpmlint check for this? -jef"word to the wise, do not eat expresso chocolate mousse cake at 9 PM if you want to go to sleep before 2 AM"spaleta From jjoe at flummiball.de Tue Dec 26 21:11:55 2006 From: jjoe at flummiball.de (Jonas G) Date: Tue, 26 Dec 2006 22:11:55 +0100 Subject: developer needed? Message-ID: <4591901B.7050207@flummiball.de> Hi! I'm looking for a project (game) where help is needed. The project should be written in C+SDL. Please let me know whether your project needs help! (I prefer small projects, maybe 2D-game). greetings from germany jonas From paul at all-the-johnsons.co.uk Tue Dec 26 23:01:30 2006 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 26 Dec 2006 23:01:30 +0000 Subject: developer needed? In-Reply-To: <4591901B.7050207@flummiball.de> References: <4591901B.7050207@flummiball.de> Message-ID: <1167174090.3520.47.camel@T7.Linux> Hi, > I'm looking for a project (game) where help is needed. > The project should be written in C+SDL. > Please let me know whether your project needs help! (I prefer small > projects, maybe 2D-game). Really speaking, this email (and the reply) is off topic for this list - it really should be directed at the standard fedora list as this one is purely for the developers of Fedora. In answer to your question, have a look at either sourceforge, freshmeat or the Linux game tome (http://www.happypenguin.org) where you'll more than likely find what you're after. Good luck :-) TTFN Paul -- "Mmmmmmmm....Shakira geschmiert mit schokolade" sagt Homer -------------- 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 steve at silug.org Tue Dec 26 23:13:19 2006 From: steve at silug.org (Steven Pritchard) Date: Tue, 26 Dec 2006 17:13:19 -0600 Subject: maintaining lots of packages (was Re: ESR "fedora-submit") In-Reply-To: <1167005888.6039.9.camel@localhost.localdomain> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <1167005888.6039.9.camel@localhost.localdomain> Message-ID: <20061226231319.GA5315@osiris.silug.org> I didn't see any real answers to this, so I'll give it a shot... On Sun, Dec 24, 2006 at 07:18:08PM -0500, Michael Tiemann wrote: > I'd like to see somebody who is maintaining at least 30, and perhaps > 50 packages explain how *they* do it. Maybe they have a better way. > Maybe it drives them almost as crazy Eric. How *does* a maintainer of > 36 packages would with the Fedora process? How *should* one do it? > This is the question and the problem to be solved. I maintain a bunch (98 at the moment) of perl-related packages. Three things make the perl packages easy to maintain: * CPAN has enough metadata to figure out if something needs an update, and, if so, where to get it. * The perl packages mostly follow a clear template. * The majority of those packages run "make test", so, generally speaking, if the package builds, it works. I have a script called cpancheck (an older version is available at http://fedoraproject.org/wiki/Extras/UsefulScripts) that I use to find any of the perl packages that need to be updated. If any packages need to be updated, I use cpanspec (in Extras) to download the latest source and generate a new spec for each. I use a script called bump (not on Extras/UsefulScripts, but probably should be) to update EVR of the spec in CVS, add a new changelog entry, and do some repetitive cleanup. I then diff the output of cpanspec with the updated spec in CVS to make sure there aren't any necessary changes in BuildRequires and such. (I try really hard to make the spec match cpanspec output, either by changing the spec or cpanspec, to make this easier.) At that point, all that's left is a test build and rpmlint check (which, admittedly, sometimes I skip if I'm just building in the development branch) before I "cvs commit && make tag && make plague". I don't have all this as automated as I could yet, mostly because I just haven't spent the time to script it all out yet. I'll probably get everything done just in time for the whole process to change. :-) For the non-perl packages, I basically only mess with them when I am told about an upgrade (either through whatever mailing list or a user letting me know in Bugzilla) or when we're doing mass rebuilds shortly before a new release. Even given that, I probably spend more time on the dozen or so non-perl packages that I maintain than I do on all of the perl packages combined. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From vnpenguin at vnoss.org Tue Dec 26 23:27:53 2006 From: vnpenguin at vnoss.org (Vnpenguin) Date: Wed, 27 Dec 2006 00:27:53 +0100 Subject: Announcing the Fedora 6 Zod live CD and live CD tools In-Reply-To: <1166812366.2752.99.camel@zelda.fubar.dk> References: <1166812366.2752.99.camel@zelda.fubar.dk> Message-ID: On 12/22/06, David Zeuthen wrote: > > Hi, > > After lots of feedback, bug fixing and testing of the beta live CD > announced 3 weeks ago, I'm pleased to announce the first official Fedora > live CD. This live CD is based on packages from the Fedora Core 6 > (codenamed "Zod") and Fedora Extras package collections and is such 100% > free software. At a glance, the live CD features > ... > > for details. Until these packages are in Extras, you can grab source and > binary i386 packages from here > > http://people.redhat.com/davidz/livecd/ > > and start cranking out your own live CD's. > Hi, I'm trying to build a live cd with tool from http://people.redhat.com/davidz/livecd/i386/ I see error: /usr/sbin/chroot: cannot run command `/sbin/fixfiles': No such file or directory In Python script, I see this command: os.system("/usr/sbin/chroot %s/install_root /sbin/fixfiles restore"%(self.build_dir)) How to fix this error please. TIA, -- http://vnoss.org -- http://vnoss.org From giallu at gmail.com Tue Dec 26 23:37:40 2006 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 27 Dec 2006 00:37:40 +0100 Subject: Does Core have an accurate count of packages which are built against libraries from firefox? In-Reply-To: <604aa7910612261306p4a5e32cagbf44d0fe87862c01@mail.gmail.com> References: <604aa7910612261306p4a5e32cagbf44d0fe87862c01@mail.gmail.com> Message-ID: On 12/26/06, Jeff Spaleta wrote: > We've had a lovely little chat in #fedora-extras with the > firefox maintainer, and he's absolutely right there needs to be a > toolized way for each maintainer with a package who builds against > firefox to set a sort of watch in the build or update system against > firefox looking for new builds. Actually, I think such a tool would be useful also for others: for example, in order to know when a new kernel is released and I need to rebuild the kmod I am maintaining I can: 1. watch each and every Build report (rawhide), test and/or pkg-announce lists (FC5 and FC6) 2. wait for the Broken deps script to wake me. I am trying to use the RSS infofeeds but right now the solution is still suboptimal. From tgl at redhat.com Wed Dec 27 04:08:34 2006 From: tgl at redhat.com (Tom Lane) Date: Tue, 26 Dec 2006 23:08:34 -0500 Subject: Does Core have an accurate count of packages which are built against libraries from firefox? In-Reply-To: References: <604aa7910612261306p4a5e32cagbf44d0fe87862c01@mail.gmail.com> Message-ID: <11468.1167192514@sss.pgh.pa.us> "Gianluca Sforna" writes: > On 12/26/06, Jeff Spaleta wrote: >> We've had a lovely little chat in #fedora-extras with the >> firefox maintainer, and he's absolutely right there needs to be a >> toolized way for each maintainer with a package who builds against >> firefox to set a sort of watch in the build or update system against >> firefox looking for new builds. > Actually, I think such a tool would be useful also for others: +1 --- although I suspect Jeff meant that already, ie, he was just using firefox as an example of a package with many dependent packages. I'd like to see an automatic notification mechanism that "package FOO that your package BAR Requires: or BuildRequires: was just updated". To make life interesting: sometimes a package rebuild is for trivial reasons. If there were such a notification mechanism, then ideally the owner of the package-having-dependencies should be able to mark a particular rebuild as "all hands on deck!" or "take a look but probably no problemo" or "fear not, nothing interesting here". regards, tom lane From jspaleta at gmail.com Wed Dec 27 05:30:25 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 26 Dec 2006 20:30:25 -0900 Subject: Does Core have an accurate count of packages which are built against libraries from firefox? In-Reply-To: <11468.1167192514@sss.pgh.pa.us> References: <604aa7910612261306p4a5e32cagbf44d0fe87862c01@mail.gmail.com> <11468.1167192514@sss.pgh.pa.us> Message-ID: <604aa7910612262130g2c95cb97q5f2b8e89bbaf9e16@mail.gmail.com> On 12/26/06, Tom Lane wrote: > +1 --- although I suspect Jeff meant that already, ie, he was just > using firefox as an example of a package with many dependent packages. Its more than that, the firefox situation is extraordinary because of the way the dependencies are handled. Something needs to be done, which goes above and beyond the available dependency chain checking script mechanisms that we currently have to catch what is happening with broken packages with firefox library deps. If whatever that new mechanism is, is a generally welcomed tool which all maintainers can benefit from to help manage dependency coordination issues, great. But I want to be clear, this is not a navel gazing exercise, where I want to dream up the ideal notification tools meant to solve all maintainer coordination problems and cure cancer. I am looking to solve a very specific problem. We need a way to prevent undue delay in correcting packages which are broken by firefox rebuilds (or other packages) because of changes in the versioned directory tree location which are currently undiscoverable from an rpm based dependency checking perspective. We have a situation right now where linked in libraries are going missing on installed system and our available rpm based depchecking scripts are not catching it. I've caught two CORE packages now which are broken on my system in this way, as an end-user. We have to do better, we need to find a way to detect this broken dependancy chain situation asap in the published tree so the community of maintainers can react without waiting for bugreports from endusers which could come days or weeks after the breakage actually occured. I'd be happy if there was a scriptable way to detect this and add it to the summary of broken dep reports that go out to the lists. -jef From aphukan at redhat.com Wed Dec 27 05:36:06 2006 From: aphukan at redhat.com (Amitakhya Phukan) Date: Wed, 27 Dec 2006 11:06:06 +0530 Subject: help for firefox needed In-Reply-To: <459176BF.1040401@flummiball.de> References: <4590EE95.6080607@redhat.com> <459176BF.1040401@flummiball.de> Message-ID: <45920646.3010506@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonas G wrote: > hi! maybe you should install mozilla-vlc-plugin or > mozilla-totem-plugin > > jonas hi jonas! well, thanks for the advice.. i will definitely try it.. may i also add that this query has put up a very long discussion in fedora-list. do you mind having a look at that??.. today morning i came to office and found around 7-8 mails for it. thanks, amit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFkgZGDlUL5E3antERAtuiAJ9TkGCj7vOgsI8Oz/7Hismms0mqeACfX3r5 YcCmSfYUvxnU25UJ6Gj22pM= =1tHR -----END PGP SIGNATURE----- From skvidal at linux.duke.edu Wed Dec 27 05:52:19 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 27 Dec 2006 00:52:19 -0500 Subject: Does Core have an accurate count of packages which are built against libraries from firefox? In-Reply-To: <604aa7910612262130g2c95cb97q5f2b8e89bbaf9e16@mail.gmail.com> References: <604aa7910612261306p4a5e32cagbf44d0fe87862c01@mail.gmail.com> <11468.1167192514@sss.pgh.pa.us> <604aa7910612262130g2c95cb97q5f2b8e89bbaf9e16@mail.gmail.com> Message-ID: <1167198739.23408.38.camel@cutter> On Tue, 2006-12-26 at 20:30 -0900, Jeff Spaleta wrote: > On 12/26/06, Tom Lane wrote: > > +1 --- although I suspect Jeff meant that already, ie, he was just > > using firefox as an example of a package with many dependent packages. > > Its more than that, the firefox situation is extraordinary because of > the way the dependencies are handled. Something needs to be done, > which goes above and beyond the available dependency chain checking > script mechanisms that we currently have to catch what is happening > with broken packages with firefox library deps. If whatever that new > mechanism is, is a generally welcomed tool which all maintainers can > benefit from to help manage dependency coordination issues, great. > > But I want to be clear, this is not a navel gazing exercise, where I > want to dream up the ideal notification tools meant to solve all > maintainer coordination problems and cure cancer. I am looking to > solve a very specific problem. We need a way to prevent undue delay in > correcting packages which are broken by firefox rebuilds (or other > packages) because of changes in the versioned directory tree location > which are currently undiscoverable from an rpm based dependency > checking perspective. We have a situation right now where linked in > libraries are going missing on installed system and our available rpm > based depchecking scripts are not catching it. I've caught two CORE > packages now which are broken on my system in this way, as an > end-user. We have to do better, we need to find a way to detect this > broken dependancy chain situation asap in the published tree so the > community of maintainers can react without waiting for bugreports from > endusers which could come days or weeks after the breakage actually > occured. I'd be happy if there was a scriptable way to detect this and > add it to the summary of broken dep reports that go out to the lists. Isn't this a function of the package database some of the infrastructure folks are working on? Or, alternatively, couldn't we have it tracked from the srpm builddep relationships? here's what it sounds like to me: 1. package X gets rebuilt/updated 2. package Y has a dep/build dep relationship with package X 3. package owner of package Y gets a notice that package Y has been rebuilt/updated. none of the above is really all that hard, you'd just have to iterate the packages looking for ones that have any dep relationship with any of the packages that have been updated/rebuilt. It'd probably be best if it could be a script that we ran automatically and one that a package maintainer could run to report on any of his/her packages. -sv From fedora at leemhuis.info Wed Dec 27 06:04:44 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 27 Dec 2006 07:04:44 +0100 Subject: Does Core have an accurate count of packages which are built against libraries from firefox? In-Reply-To: References: <604aa7910612261306p4a5e32cagbf44d0fe87862c01@mail.gmail.com> Message-ID: <45920CFC.6010505@leemhuis.info> Hi all! BTW, I added "the firefox updates in stable often breaks quite some packages (galeon, liferia, ...); do we need some kind of task force that steps up to rebuild the stuff? Same for kmods!" to the FESCo schedule some days ago already ;-) Gianluca Sforna schrieb: > On 12/26/06, Jeff Spaleta wrote: >> We've had a lovely little chat in #fedora-extras with the >> firefox maintainer, and he's absolutely right there needs to be a >> toolized way for each maintainer with a package who builds against >> firefox to set a sort of watch in the build or update system against >> firefox looking for new builds. Well, maybe that could work. But I think for the merged Core and Extras world the maintainer of a update for now should be responsible of poking the downstream packagers and/or even rebuild the packages and push them at the same time. Sure, a technical solution would be best, but I want a solution now until we have a technical one in place. I'd suggest: For a stable distro (like FC6 in this case) we normally should not update stuff that breaks other stuff in the repo in any case. If we have to (firefox) then it's up to the maintainer of that package and his co-maintainers to make sure the updates works smoothly for most of the users. That means: make sure other stuff in the repos (galeon, liferia,...) depending on that package still works. That would normal mean: just rebuild it and poke the signers afterwards to push the rebuild stuff. That should be able to script and should not take more then 5 minutes of work in total. Sure, that would mean a bit more work for the firefox maintainer in this case (sorry callion, but that's due to firefox fault as it does not provide a stable ABI/API), but it's the best for all afaics as firefox updates are often security relevant and that's the quickest and smoothest way to get it out for everyone. And btw, sure, if a downstream package (galeon, liferia,...) breaks with the new firefox, then their maintainers should fix it and it should not delay the push of the new firefox. That will get a bit easier in the merged Core and Extras world. For now (FC5 and FC6) I'd say: Maintain a list somewhere in the wiki with the names of packages that need a rebuild when a new firefox is published. If a new firefox was pushed by Core let someone (callion, me, f13, the signers, FESCo members, ...) increase EVR on these packages and queue a rebuild. How does that sound? > Actually, I think such a tool would be useful also for others: for > example, in order to know when a new kernel is released and I need to > rebuild the kmod I am maintaining I can: The plan for kmods always was to let the buildsys handle that automatically. Just no one got around to implement it. Any volunteers? CU thl From tgl at redhat.com Wed Dec 27 06:33:58 2006 From: tgl at redhat.com (Tom Lane) Date: Wed, 27 Dec 2006 01:33:58 -0500 Subject: Does Core have an accurate count of packages which are built against libraries from firefox? In-Reply-To: <1167198739.23408.38.camel@cutter> References: <604aa7910612261306p4a5e32cagbf44d0fe87862c01@mail.gmail.com> <11468.1167192514@sss.pgh.pa.us> <604aa7910612262130g2c95cb97q5f2b8e89bbaf9e16@mail.gmail.com> <1167198739.23408.38.camel@cutter> Message-ID: <14133.1167201238@sss.pgh.pa.us> seth vidal writes: > On Tue, 2006-12-26 at 20:30 -0900, Jeff Spaleta wrote: >> On 12/26/06, Tom Lane wrote: >>> +1 --- although I suspect Jeff meant that already, ie, he was just >>> using firefox as an example of a package with many dependent packages. >> >> Its more than that, the firefox situation is extraordinary because of >> the way the dependencies are handled. Something needs to be done, > Isn't this a function of the package database some of the infrastructure > folks are working on? Or, alternatively, couldn't we have it tracked > from the srpm builddep relationships? well, Jeff makes it perfectly clear that he thinks firefox has a special problem. I'm still in favor of some kind of generic solution, because I know I've broken a few downstream packages in my time :-( ... but perhaps firefox needs some extra mechanism. regards, tom lane From dyek at real.com Wed Dec 27 08:16:14 2006 From: dyek at real.com (Daniel Yek) Date: Wed, 27 Dec 2006 00:16:14 -0800 Subject: Development machine setup for both i386 and x86_64 work / Mock In-Reply-To: <20061225144610.GA4731@ryvius.pekin.waw.pl> References: <6.2.1.2.2.20061222004303.462804b0@mailone.real.com> <1166868786.16008.2.camel@max.booze> <6.2.1.2.2.20061224082832.02203ab8@mailone.real.com> <20061225144610.GA4731@ryvius.pekin.waw.pl> Message-ID: <6.2.1.2.2.20061227001333.2a7967b0@mailone.real.com> At 06:46 AM 12/25/2006, Dominik 'Rathann' Mierzejewski wrote: >On Sunday, 24 December 2006 at 17:31, Daniel Yek wrote: > > At 02:13 AM 12/23/2006, Callum Lerwick wrote: > > >I just compile for i386 using mock. Works great, assuming you > > >obsessively RPM package everything you deploy to other machines like I > > >do. :) > > > > > > Sound cool, but I would be happier if you would point me to information > > about mock -- how to use it and what it is for, etc. Didn't find too much > > useful information googling... > >yum install mock >man mock Got it. Thanks. It seems to me that LSB Build Environment will work just as well for me. Thanks. -- Daniel Yek >Regards, >R. > >-- From knightmerc at yahoo.com Wed Dec 27 09:10:02 2006 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Wed, 27 Dec 2006 04:10:02 -0500 Subject: Move Evolution to Extras? In-Reply-To: <1144848525.2294.274.camel@sundaram.pnq.redhat.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> Message-ID: <1167210602.2786.38.camel@localhost.localdomain> On Wed, 2006-04-12 at 18:58 +0530, Rahul Sundaram wrote: > On Wed, 2006-04-12 at 09:11 -0400, Dimi Paun wrote: > > On Wed, 2006-04-12 at 07:42 -0400, Alan Cox wrote: > > > Evolution belongs in the bitbucket. > > > > Alan, > > > > This is pretty scary. Switching people off email clients like > > this is a big problem. People get really attached to their MUAs > > for lots of reasons, not in the least being that their mail > > archives can't be easily moved from client to client. > > > > Guys, Red Hat has been pushing Evo for a _long_ time now. It has > > to stay behind their choices, not force millions of users to switch > > at a drop of a hat (pun intended :)). > > > > This is a lot more serious than switching web browsers or other > > apps. Too many people will get affected, and rightfully pissed > > at RH. Silly excuses that you couldn't hire people to work on it > > will not fly. > > > > I'm really surprised that folks at RH throw around such scenarios > > without thinking a bit about consequences. How can enterprises trust > > you with any technological guidance/decision when you are willing to > > do things that would cost them untold millions without even blinking? > > You are over over-dramatizing. This is not a place for enterprises to > get technology guidance and nobody's personal opinions here is going to > cost anyone untold millions. > > > Rahul He's not over-dramatizing anything, he's telling the truth. Evo occupies a slot now, and it's stupid to throw it in the bitbucket. Period. LX From seg at haxxed.com Wed Dec 27 09:14:56 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 27 Dec 2006 03:14:56 -0600 Subject: Does Core have an accurate count of packages which are built against libraries from firefox? In-Reply-To: <604aa7910612262130g2c95cb97q5f2b8e89bbaf9e16@mail.gmail.com> References: <604aa7910612261306p4a5e32cagbf44d0fe87862c01@mail.gmail.com> <11468.1167192514@sss.pgh.pa.us> <604aa7910612262130g2c95cb97q5f2b8e89bbaf9e16@mail.gmail.com> Message-ID: <1167210901.9279.25.camel@max.booze> On Tue, 2006-12-26 at 20:30 -0900, Jeff Spaleta wrote: > But I want to be clear, this is not a navel gazing exercise, where I > want to dream up the ideal notification tools meant to solve all > maintainer coordination problems and cure cancer. I am looking to > solve a very specific problem. We need a way to prevent undue delay in > correcting packages which are broken by firefox rebuilds (or other > packages) because of changes in the versioned directory tree location > which are currently undiscoverable from an rpm based dependency > checking perspective. We have a situation right now where linked in > libraries are going missing on installed system and our available rpm > based depchecking scripts are not catching it. Seems to me FireFox's packaging is fundamentally broken if RPM dep tracking can't detect this already. Some judicious use of virtual provides and dep-filtering maybe? Since the packages are apparently dependent on a versioned directory, maybe they all need to just Require: firefox = 1.5.foo.bar ... -------------- 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 knightmerc at yahoo.com Wed Dec 27 09:14:39 2006 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Wed, 27 Dec 2006 04:14:39 -0500 Subject: Move Evolution to Extras? In-Reply-To: <1167210602.2786.38.camel@localhost.localdomain> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> Message-ID: <1167210880.2786.41.camel@localhost.localdomain> On Wed, 2006-12-27 at 04:10 -0500, Lyvim Xaphir wrote: > On Wed, 2006-04-12 at 18:58 +0530, Rahul Sundaram wrote: > > On Wed, 2006-04-12 at 09:11 -0400, Dimi Paun wrote: > > > On Wed, 2006-04-12 at 07:42 -0400, Alan Cox wrote: > > > > Evolution belongs in the bitbucket. > > > > > > Alan, > > > > > > This is pretty scary. Switching people off email clients like > > > this is a big problem. People get really attached to their MUAs > > > for lots of reasons, not in the least being that their mail > > > archives can't be easily moved from client to client. > > > > > > Guys, Red Hat has been pushing Evo for a _long_ time now. It has > > > to stay behind their choices, not force millions of users to switch > > > at a drop of a hat (pun intended :)). > > > > > > This is a lot more serious than switching web browsers or other > > > apps. Too many people will get affected, and rightfully pissed > > > at RH. Silly excuses that you couldn't hire people to work on it > > > will not fly. > > > > > > I'm really surprised that folks at RH throw around such scenarios > > > without thinking a bit about consequences. How can enterprises trust > > > you with any technological guidance/decision when you are willing to > > > do things that would cost them untold millions without even blinking? > > > > You are over over-dramatizing. This is not a place for enterprises to > > get technology guidance and nobody's personal opinions here is going to > > cost anyone untold millions. > > > > > > Rahul > > > He's not over-dramatizing anything, he's telling the truth. Evo > occupies a slot now, and it's stupid to throw it in the bitbucket. > Period. > > LX Forget any other posts that I send in this thread, there was a date screwup on my system. Sorry about the confusion. LX From jspaleta at gmail.com Wed Dec 27 10:00:54 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 27 Dec 2006 01:00:54 -0900 Subject: Does Core have an accurate count of packages which are built against libraries from firefox? In-Reply-To: <1167210901.9279.25.camel@max.booze> References: <604aa7910612261306p4a5e32cagbf44d0fe87862c01@mail.gmail.com> <11468.1167192514@sss.pgh.pa.us> <604aa7910612262130g2c95cb97q5f2b8e89bbaf9e16@mail.gmail.com> <1167210901.9279.25.camel@max.booze> Message-ID: <604aa7910612270200s5c786a8y17cc8c94c38186ca@mail.gmail.com> On 12/27/06, Callum Lerwick wrote: > firefox = 1.5.foo.bar ... I'm thinking this is the best way to prevent this situation from going unnoticed by the currently available rpm dep checking. It's a policy fix. Make an explicit check during the review process to ensure that a versioned firefox requires is used if and only if libraries from inside the versioned firefox directory tree are pulled in as requires. We may want to think about this as part of Core package review for the upcoming merger. Is anyone got a few spare cycles to script a Core+Extras wide check looking for all packages which end up requiring shared libraries required by firefox? My frelling home workstation died, so I don't have my normal development environment at my fingertips. I'm thinking we can brute-force this with some repetitive calls of repoquery --whatrequires using the output rpm -q --provides firefox |grep \.so Doing some simple exploratory surgery with rpm --provides and --whatrequires I noticed that esc doesn't actually require libxpcom.so. I took a closer look at the esc in Core 6 and the esc situation is even more confusing than I originally thought. esc-1.0.0-16.fc6 actually includes its own copy of /usr/lib/esc-1.0.0/xulrunner/libxpcom.so but ldd /usr/lib/esc-1.0.0/xulrunner/xulrunner-bin returns: libmozjs.so => not found libxpcom.so => not found libxul.so => not found I'd be interested to know if esc in the development tree as a similiar problem. All three of these libraries are provided by firefox AND by esc itself. WTF. esc's specfile must completely short-circuit rpm's normal auto-generation of library dependancies, and according to the changelog entries it does short circuit the process. Whereever esc's xulrunner-bin is looking for libxpcom.so its not from its own xulrunner library directory nor from any firefox versioned directory of any firefox rpm released for fc6 afaict. I'm gonna have to try to file this in bugzilla tomorrow. Something tells me I'm going to need a couple of ultra-strong eye-poking sticks. I might even have to buy the white-hot heated upgrade this time. -jef"Is it okay if I make MST3K-like commentary on some of the more interesting Core package reviews when they start happening. The esc review is already on my short-list. I want to understand wtf is so wrong with esc's build process that automatic library dependency calculations had to be explictly turned off. There is absolutely no way to catch that xulrunner-bin is missing library references at the packaging level as it stands. I had to blunder into this looking for other problems on an installed system. I'm coming to this review with a large tub of popcorn and bat wielding sock puppets."spaleta From naoki at valuecommerce.com Wed Dec 27 10:36:05 2006 From: naoki at valuecommerce.com (Naoki) Date: Wed, 27 Dec 2006 19:36:05 +0900 Subject: Dependancies crack me up. Message-ID: <1167215765.23083.371.camel@dragon.valuecommerce.ne.jp> Was trying to fix this ( because I have both i386 & x86_64 versions installed ): Transaction Check Error: file /usr/share/hal/fdi/information/20thirdparty/10-camera-libgphoto2.fdi from install of gphoto2-2.3.1-1.fc7 conflicts with file from package gphoto2-2.2.0-2.1 file /usr/share/man/man1/gphoto2.1.gz from install of gphoto2-2.3.1-1.fc7 conflicts with file from package gphoto2-2.2.0-2.1 And found this : # rpm -e gphoto2-2.2.0-2.1.x86_64 error: Failed dependencies: libgphoto2.so.2()(64bit) is needed by (installed) gthumb-2.7.8-3.fc6.x86_64 libgphoto2_port.so.0()(64bit) is needed by (installed) gthumb-2.7.8-3.fc6.x86_64 # rpm -e gphoto2-2.2.0-2.1.x86_64 gthumb-2.7.8-3.fc6.x86_64 error: Failed dependencies: gthumb is needed by (installed) gnome-volume-manager-2.15.0-4.fc6.x86_64 # rpm -e gphoto2-2.2.0-2.1.x86_64 gthumb-2.7.8-3.fc6.x86_64 gnome-volume-manager-2.15.0-4.fc6.x86_64 error: Failed dependencies: gnome-volume-manager is needed by (installed) gnome-session-2.16.0-7.fc6.x86_64 I can't see gnome-session really needing volume manager, or why volume manager needs gthumb? Anybody ever make a big tree diagram out of FC dependencies? I recall the source code image and I think this would be just as cool. From a.badger at gmail.com Wed Dec 27 16:40:23 2006 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 27 Dec 2006 08:40:23 -0800 Subject: Does Core have an accurate count of packages which are built against libraries from firefox? In-Reply-To: <1167198739.23408.38.camel@cutter> References: <604aa7910612261306p4a5e32cagbf44d0fe87862c01@mail.gmail.com> <11468.1167192514@sss.pgh.pa.us> <604aa7910612262130g2c95cb97q5f2b8e89bbaf9e16@mail.gmail.com> <1167198739.23408.38.camel@cutter> Message-ID: <1167237623.19928.169.camel@localhost.localdomain> On Wed, 2006-12-27 at 00:52 -0500, seth vidal wrote: > On Tue, 2006-12-26 at 20:30 -0900, Jeff Spaleta wrote: > > Its more than that, the firefox situation is extraordinary because of > > the way the dependencies are handled. Something needs to be done, > > which goes above and beyond the available dependency chain checking > > script mechanisms that we currently have to catch what is happening > > with broken packages with firefox library deps. If whatever that new > > mechanism is, is a generally welcomed tool which all maintainers can > > benefit from to help manage dependency coordination issues, great. > > > > But I want to be clear, this is not a navel gazing exercise, where I > > want to dream up the ideal notification tools meant to solve all > > maintainer coordination problems and cure cancer. I am looking to > > solve a very specific problem. We need a way to prevent undue delay in > > correcting packages which are broken by firefox rebuilds (or other > > packages) because of changes in the versioned directory tree location > > which are currently undiscoverable from an rpm based dependency > > checking perspective. We have a situation right now where linked in > > libraries are going missing on installed system and our available rpm > > based depchecking scripts are not catching it. I've caught two CORE > > packages now which are broken on my system in this way, as an > > end-user. We have to do better, we need to find a way to detect this > > broken dependancy chain situation asap in the published tree so the > > community of maintainers can react without waiting for bugreports from > > endusers which could come days or weeks after the breakage actually > > occured. I'd be happy if there was a scriptable way to detect this and > > add it to the summary of broken dep reports that go out to the lists. > > Isn't this a function of the package database some of the infrastructure > folks are working on? Or, alternatively, couldn't we have it tracked > from the srpm builddep relationships? > Not for the first iteration[1]. I think we should be able to pull the initial data from the repodata. After that we'd want our ties into the buildsystem to alert us to each rebuild. The notification can trigger a dep checking run against that package and notification to all the dependent package maintainers. > here's what it sounds like to me: > > 1. package X gets rebuilt/updated > 2. package Y has a dep/build dep relationship with package X > 3. package owner of package Y gets a notice that package Y has been > rebuilt/updated. > > none of the above is really all that hard, you'd just have to iterate > the packages looking for ones that have any dep relationship with any of > the packages that have been updated/rebuilt. > Sounds right. [1] Note -- I don't know how many revisions we'll get to before FC7. The essential functions that I want to definitely see are: * Replacement for owners.list * Able to configure ACLs in the VCS * Able to branch packages in the VCS * Web front end for both read-only, anonymous access and read-write, package owner access. -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 caillon at redhat.com Wed Dec 27 17:09:04 2006 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 27 Dec 2006 12:09:04 -0500 Subject: Does Core have an accurate count of packages which are built against libraries from firefox? In-Reply-To: <604aa7910612261306p4a5e32cagbf44d0fe87862c01@mail.gmail.com> References: <604aa7910612261306p4a5e32cagbf44d0fe87862c01@mail.gmail.com> Message-ID: <4592A8B0.3080401@redhat.com> Jeff Spaleta wrote: > But I just ran into the fact that esc was also affect by the firefox > update by accident. > /usr/lib/esc-1.0.0/xulrunner/xulrunner-bin links against > libmozjs.so > libxpcom.so > which can't be found by the linker since these are both packages in > the versioned firefox directory tree. My god damn home workstation > died yesterday(merry christmas to me!) so if someone else can bugzilla > this before I get a chance...go right ahead. This is a serious bug. What the hell is ESC doing packaging an entire copy of every gecko library and shipping with an entire gecko source tree if it's going to rely on the system installed copies? This aside from the fact that ESC using gecko at all is a calamity of an engineering decision, IMO. From sean.bruno at dsl-only.net Wed Dec 27 17:09:44 2006 From: sean.bruno at dsl-only.net (Sean Bruno) Date: Wed, 27 Dec 2006 09:09:44 -0800 Subject: Move Evolution to Extras? In-Reply-To: <1167210880.2786.41.camel@localhost.localdomain> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> Message-ID: <1167239384.6753.3.camel@home-desk> On Wed, 2006-12-27 at 04:14 -0500, Lyvim Xaphir wrote: > On Wed, 2006-12-27 at 04:10 -0500, Lyvim Xaphir wrote: > > On Wed, 2006-04-12 at 18:58 +0530, Rahul Sundaram wrote: > > > On Wed, 2006-04-12 at 09:11 -0400, Dimi Paun wrote: > > > > On Wed, 2006-04-12 at 07:42 -0400, Alan Cox wrote: > > > > > Evolution belongs in the bitbucket. > > > > > > > > Alan, > > > > > > > > This is pretty scary. Switching people off email clients like > > > > this is a big problem. People get really attached to their MUAs > > > > for lots of reasons, not in the least being that their mail > > > > archives can't be easily moved from client to client. > > > > > > > > Guys, Red Hat has been pushing Evo for a _long_ time now. It has > > > > to stay behind their choices, not force millions of users to switch > > > > at a drop of a hat (pun intended :)). > > > > > > > > This is a lot more serious than switching web browsers or other > > > > apps. Too many people will get affected, and rightfully pissed > > > > at RH. Silly excuses that you couldn't hire people to work on it > > > > will not fly. > > > > > > > > I'm really surprised that folks at RH throw around such scenarios > > > > without thinking a bit about consequences. How can enterprises trust > > > > you with any technological guidance/decision when you are willing to > > > > do things that would cost them untold millions without even blinking? > > > > > > You are over over-dramatizing. This is not a place for enterprises to > > > get technology guidance and nobody's personal opinions here is going to > > > cost anyone untold millions. > > > > > > > > > Rahul > > > > > > He's not over-dramatizing anything, he's telling the truth. Evo > > occupies a slot now, and it's stupid to throw it in the bitbucket. > > Period. > > > > LX > > > Forget any other posts that I send in this thread, there was a date > screwup on my system. Sorry about the confusion. > > LX > Isn't Evolution sort of, kind of, maintained by our fair friends over at Novell/Suse ? Does that have anything to do with this "Death to Evo" thread? The only over riding reason to _still_ use Evolution is to interface directly to a MS Exchange server. I happen to use it out of habit, not because it's better/worse. I perceive the mail filtering rules to be easier to configure and more robust than Thunderbird, but that may be _MY_ perception. Sean Sean From dakingun at gmail.com Wed Dec 27 17:12:58 2006 From: dakingun at gmail.com (Deji Akingunola) Date: Wed, 27 Dec 2006 12:12:58 -0500 Subject: java-1.4.2-gcj-compat postinstall (in mock) fault - [WAS]Re: rawhide report: 20060802 changes Message-ID: On 8/2/06, Erwin Rol wrote: > This update also caused the following errors on x86_&4; > > Running Transaction > Updating : java-1.4.2-gcj-compat ####################### [ 1/66] > dirname: missing operand > Try `dirname --help' for more information. > mkdir: missing operand > Try `mkdir --help' for more information. > /usr/bin/rebuild-gcj-db: line 17: 20713 Segmentation fault /usr/bin/gcj-dbtool -n $dbLocation 64 > xargs: /usr/bin/gcj-dbtool: terminated by signal 11 > dirname: missing operand > Try `dirname --help' for more information. > mkdir: missing operand > Try `mkdir --help' for more information. > /usr/bin/rebuild-gcj-db: line 17: 20722 Segmentation fault /usr/bin/gcj-dbtool -n $dbLocation 64 > xargs: /usr/bin/gcj-dbtool: terminated by signal 11 I'm getting this same segmentation fault in the root log of a mock build that needs java-1.4.2-gcj-compat. Which package should I filled this against, glibc or libgcj or java-1.4.2-gcj-compat. Deji From david at lovesunix.net Wed Dec 27 18:20:02 2006 From: david at lovesunix.net (David Nielsen) Date: Wed, 27 Dec 2006 19:20:02 +0100 Subject: Move Evolution to Extras? In-Reply-To: <1167239384.6753.3.camel@home-desk> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> Message-ID: <1167243602.1287.44.camel@dawkins> ons, 27 12 2006 kl. 09:09 -0800, skrev Sean Bruno: > > Isn't Evolution sort of, kind of, maintained by our fair friends over at > Novell/Suse ? Does that have anything to do with this "Death to Evo" > thread? > > The only over riding reason to _still_ use Evolution is to interface > directly to a MS Exchange server. > > I happen to use it out of habit, not because it's better/worse. I > perceive the mail filtering rules to be easier to configure and more > robust than Thunderbird, but that may be _MY_ perception. As much as I absolutely loath Evolution I tend to agree, the filtering and the way it displays threads seem much more natural than any other mailer I've tried. That doesn't stop the massive amount of unrelated suckage though, like the infamous #217567 wherein Evolution entirely refuses to send mail for no apparent reason or the many other quirks. Evolution currently is the best of a lot of bad choices, it would be nice if somewhere down the line we could find a replacement, especially one that didn't come bundled with all this groupware functionality all in one app. A simple mailer which can inter-operate with something like Contacts and Dates to make a nicely separated PIM suite which shares information would be ideal in my mind. Anything else seems to be begging for disaster to me, complexity breeds the kind of madness Evolution has become. - David Nielsen -- "Ridicule s the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From lamont at gurulabs.com Wed Dec 27 18:40:03 2006 From: lamont at gurulabs.com (Lamont Peterson) Date: Wed, 27 Dec 2006 11:40:03 -0700 Subject: Move Evolution to Extras? In-Reply-To: <1167243602.1287.44.camel@dawkins> References: <1144155199.2808.94.camel@dimi> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> Message-ID: <200612271140.10618.lamont@gurulabs.com> On Wednesday 27 December 2006 11:20am, David Nielsen wrote: > ons, 27 12 2006 kl. 09:09 -0800, skrev Sean Bruno: > > Isn't Evolution sort of, kind of, maintained by our fair friends over at > > Novell/Suse ? Does that have anything to do with this "Death to Evo" > > thread? As I understood the state of things, all (or nearly all) of the developers who originally worked on Evolution (i.e., the Ximian guys) left it nearly 2 years ago. That was part of the problem, that Evolution was almost abandoned for a while and then some other people stepped up. I could be wrong about that, but that's what I remember hearing. > > The only over riding reason to _still_ use Evolution is to interface > > directly to a MS Exchange server. See below. > > I happen to use it out of habit, not because it's better/worse. I > > perceive the mail filtering rules to be easier to configure and more > > robust than Thunderbird, but that may be _MY_ perception. I think that's an excellent reason for choosing which of the apps for a given task to use. First, does it get t he job done and if not, is there an app then gets closer? Next, which app is the most comfortable for me. Personally, I like to get my work done. Familiarity with an app let's me work more quickly. I don't think about, "How do I do [something] with this app?" I just do it. > As much as I absolutely loath Evolution I tend to agree, the filtering > and the way it displays threads seem much more natural than any other > mailer I've tried. That doesn't stop the massive amount of unrelated > suckage though, like the infamous #217567 wherein Evolution entirely > refuses to send mail for no apparent reason or the many other quirks. > > Evolution currently is the best of a lot of bad choices, it would be > nice if somewhere down the line we could find a replacement, especially > one that didn't come bundled with all this groupware functionality all > in one app. A simple mailer which can inter-operate with something like > Contacts and Dates to make a nicely separated PIM suite which shares > information would be ideal in my mind. Anything else seems to be begging > for disaster to me, complexity breeds the kind of madness Evolution has > become. Sounds like KMail, KAddressBook and kdepim to me. Of course, you meant that "Evolution currently is the best of a lot of bad choices" for Gnome, right? Oh, and BTW, these apps can integrate with all sorts of servers like Exchange, Groupwise, etc. -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dimi at lattica.com Wed Dec 27 18:49:44 2006 From: dimi at lattica.com (Dimi Paun) Date: Wed, 27 Dec 2006 13:49:44 -0500 (EST) Subject: Move Evolution to Extras? In-Reply-To: <1167243602.1287.44.camel@dawkins> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> Message-ID: <4580.207.245.37.34.1167245384.squirrel@lattica.com> On Wed, December 27, 2006 1:20 pm, David Nielsen wrote: > mailer I've tried. That doesn't stop the massive amount of unrelated > suckage though, like the infamous #217567 wherein Evolution entirely > refuses to send mail for no apparent reason or the many other quirks. Not to mention that after the latest set of updates, Evolution simply refuses to send any email that is not addressed to someone in my domain (lattica.com). A mailer that refuses to send email is not very useful, is it? I can't be the only person hit by this, and yet people seem to just look the other way. Anyway, the Composer in Evo is in many ways better than in other mailers, especially when dealing with code. For example, you can select a bit of the message so it is the only part that's quoted, you can easily mark part of the message as Preformatted to prevent it from wrapping lines, etc. These are very handy for people dealing with code reviews and so forth. -- Dimi Paun Lattica, Inc. From dennis at ausil.us Wed Dec 27 18:57:28 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 27 Dec 2006 12:57:28 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1167243602.1287.44.camel@dawkins> References: <1144155199.2808.94.camel@dimi> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> Message-ID: <200612271257.29072.dennis@ausil.us> On Wednesday 27 December 2006 12:20, David Nielsen wrote: > > Evolution currently is the best of a lot of bad choices, it would be > nice if somewhere down the line we could find a replacement, especially > one that didn't come bundled with all this groupware functionality all > in one app. A simple mailer which can inter-operate with something like > Contacts and Dates to make a nicely separated PIM suite which shares > information would be ideal in my mind. Anything else seems to be begging > for disaster to me, complexity breeds the kind of madness Evolution has > become. sounds like you want kdepim suite of apps they can be tied together using kontact or used separately -- ?,-._|\ ? ?Dennis Gilmore, RHCE /Aussie\ ? Proud Australian \_.--._/ ? | Aurora | Fedora | ? ? ? v ? ? From knightmerc at yahoo.com Wed Dec 27 19:05:20 2006 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Wed, 27 Dec 2006 14:05:20 -0500 Subject: Move Evolution to Extras? In-Reply-To: <1167239384.6753.3.camel@home-desk> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> Message-ID: <1167246320.2429.125.camel@localhost.localdomain> On Wed, 2006-12-27 at 09:09 -0800, Sean Bruno wrote: > > Isn't Evolution sort of, kind of, maintained by our fair friends over at > Novell/Suse ? Does that have anything to do with this "Death to Evo" > thread? > > The only over riding reason to _still_ use Evolution is to interface > directly to a MS Exchange server. > > I happen to use it out of habit, not because it's better/worse. I > perceive the mail filtering rules to be easier to configure and more > robust than Thunderbird, but that may be _MY_ perception. No, you are exactly right. Evo was originally conceived to be a competitor for Outlook (otherwise known in some circles as Outhouse) and in fact it does an excellent job at that. There were alot of bells and whistles added to get it to compare to Outlook, which basically had the effect of making Evo user friendly. That's because the overriding design consideration of Outlook is to cater to the user. (I am in no way an O-fan, but I have to deal with it for other people's sake). Evo provides a user alternative in the linux world for Outlook, and gives people another reason to migrate to Linux. I've used it as a rail greaser many times, and it works. It also blows away any excuses corporate pinheads might have for NOT integrating linux boxen into an Exchange network. > > Sean > LX From knightmerc at yahoo.com Wed Dec 27 19:11:44 2006 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Wed, 27 Dec 2006 14:11:44 -0500 Subject: Move Evolution to Extras? In-Reply-To: <1167243602.1287.44.camel@dawkins> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> Message-ID: <1167246704.2429.132.camel@localhost.localdomain> On Wed, 2006-12-27 at 19:20 +0100, David Nielsen wrote: > ons, 27 12 2006 kl. 09:09 -0800, skrev Sean Bruno: > > > > > Isn't Evolution sort of, kind of, maintained by our fair friends over at > > Novell/Suse ? Does that have anything to do with this "Death to Evo" > > thread? > > > > The only over riding reason to _still_ use Evolution is to interface > > directly to a MS Exchange server. > > > > I happen to use it out of habit, not because it's better/worse. I > > perceive the mail filtering rules to be easier to configure and more > > robust than Thunderbird, but that may be _MY_ perception. > > As much as I absolutely loath Evolution I tend to agree, the filtering > and the way it displays threads seem much more natural than any other > mailer I've tried. That doesn't stop the massive amount of unrelated > suckage though, like the infamous #217567 wherein Evolution entirely > refuses to send mail for no apparent reason or the many other quirks. > > Evolution currently is the best of a lot of bad choices, it would be > nice if somewhere down the line we could find a replacement, especially > one that didn't come bundled with all this groupware functionality all > in one app. A simple mailer which can inter-operate with something like > Contacts and Dates to make a nicely separated PIM suite which shares > information would be ideal in my mind. Anything else seems to be begging > for disaster to me, complexity breeds the kind of madness Evolution has > become. > > - David Nielsen Evo has it's problems, but currently it's indispensable. I don't agree that complexity necessarily has to involve madness; there are programs more complex than Evo that work just fine. The issue is simply just getting competent help to fix it. This thing of just dumping it and going to something else was lazy and shortsighted. It's easier to protect your existing user base than it is to alienate and amputate them, then try to get them back. LX From pmr at pajato.com Wed Dec 27 19:14:15 2006 From: pmr at pajato.com (Paul Michael Reilly) Date: Wed, 27 Dec 2006 14:14:15 -0500 Subject: Sharing devices "out of the box" Message-ID: <4592C607.4070000@pajato.com> I've made my FC6 laptop available to family members (including grandma) as a shared machine. I've taught them to log into their own session using "switch user" so that they are on their own vt session. Works nice until they want to share devices, like audio and the CD burner. For FC6 I have to take pains to set up permissions appropriately but it does occur to me to ask how Rawhide should deal with this. There seem to be two schools of thought: 1) Sharing devices automagically is a no-brainer; it must be turned on by default. 2) Sharing devices is a security weakness and no self respecting distro would enable such a thing by default. It's all well and good when the PC is set up by a someone reading any of the Redhat lists but should there come a day when Dell (or some such) ships RHEL this issue and lots more like it will be on the table. It does occur to me that maybe the current user (the one who currently owns X, the "selected" user for lack of a better description) should dynamically own devices but this is not very satisfying: perhaps the various users set their own special IM sounds in which case the distro is setting policy rather than mechanism. So the issue does get complicated quickly. Left to my own devices, I'd share the devices by default and build in the ability to graphically configure device sharing which smacks of a desktop (Gnome/KDE/Xfce/?) solution which might just already exist and I haven't come across such a beast. -pmr From nutello at sweetness.com Wed Dec 27 19:16:39 2006 From: nutello at sweetness.com (Rudi Chiarito) Date: Wed, 27 Dec 2006 20:16:39 +0100 Subject: Move Evolution to Extras? In-Reply-To: <1167246320.2429.125.camel@localhost.localdomain> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167246320.2429.125.camel@localhost.localdomain> Message-ID: <20061227191639.GM12390@plain.rackshack.net> On Wed, Dec 27, 2006 at 02:05:20PM -0500, Lyvim Xaphir wrote: > It also blows away any excuses corporate pinheads might have for NOT > integrating linux boxen into an Exchange network. If it worked, sure. Since the migration to Exchange 2003 or whatever it is called, I never got any new mail, despite having Evolution set up to check every few minutes. I have to double click the Inbox folder. And even in half of those cases it will fail with a message like "Could not refresh folder". People ask me why I don't get email until hours later. Well, if only I had more time to baby-sit Evolution and double click the Inbox folder throughout the day.. and just don't get me started on how long it takes for Evolution at startup to check folders that haven't changed since last time. I hope they kept the IMAP service up, because I am finally ditching the Outlook account. If you stick to IMAP, Evolution is almost sane in comparison, as if it were a totally different application. If the Exchange connector works the way I suspect it does (by scraping HTML pages from the Outlook web interface), I am not surprised at all by its flakiness. -- Rudi From david at lovesunix.net Wed Dec 27 19:30:55 2006 From: david at lovesunix.net (David Nielsen) Date: Wed, 27 Dec 2006 20:30:55 +0100 Subject: Move Evolution to Extras? In-Reply-To: <200612271257.29072.dennis@ausil.us> References: <1144155199.2808.94.camel@dimi> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <200612271257.29072.dennis@ausil.us> Message-ID: <1167247855.1287.55.camel@dawkins> ons, 27 12 2006 kl. 12:57 -0600, skrev Dennis Gilmore: > On Wednesday 27 December 2006 12:20, David Nielsen wrote: > > > > > Evolution currently is the best of a lot of bad choices, it would be > > nice if somewhere down the line we could find a replacement, especially > > one that didn't come bundled with all this groupware functionality all > > in one app. A simple mailer which can inter-operate with something like > > Contacts and Dates to make a nicely separated PIM suite which shares > > information would be ideal in my mind. Anything else seems to be begging > > for disaster to me, complexity breeds the kind of madness Evolution has > > become. > > sounds like you want kdepim suite of apps they can be tied together using > kontact or used separately I have used KDEs PIM suite in the past and it just feels wrong to me and it looks out of place on my GNOME desktop. I can't get it to fit with my natural workflow, call me strange but I like the GNOME way of doing things. I'm sure it's fine if you are used to KDE though, I just haven't used KDE as my desktop in a number of years. Besides installing half of KDE for a mailer seems a bit silly when basically Evolution is fine for my needs, despite its flaws. The PIM framework they are working on for KDE4 looks very interesting though, I'll be interested in seeing how that pans out for them. - David -- "Ridicule s the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From saikat at cs.cornell.edu Wed Dec 27 20:00:00 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Wed, 27 Dec 2006 15:00:00 -0500 Subject: rawhide report: 20061219 changes In-Reply-To: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> References: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> Message-ID: <1167249600.2952.5.camel@sioux.systems.cs.cornell.edu> On Tue, 2006-12-19 at 06:02 -0500, buildsys at redhat.com wrote: > ORBit2-2.14.4-1.fc7 > ------------------- > * Tue Dec 19 2006 Matthias Clasen - 2.14.4-1 > - Update to 2.14.4 After a full update today, a number of gnome apps are crashing on close. The crashes seem to be inside ORBit2 (but I could be mistaken). http://bugzilla.gnome.org/show_bug.cgi?id=390111 http://bugzilla.gnome.org/show_bug.cgi?id=390065 http://bugzilla.gnome.org/show_bug.cgi?id=390057 Possibly related, but any access to files through gnome VFS seems to freeze the application. I cannot launch nautilus, do file>open in various apps (not all) and so on. -- Saikat -------------- 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 seg at haxxed.com Wed Dec 27 19:53:58 2006 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 27 Dec 2006 13:53:58 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1167239384.6753.3.camel@home-desk> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> Message-ID: <1167249239.3903.7.camel@goat.booze> RISE FROM YOUR GRAVE! (I apologize if this message is a horrible failure) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ab-rise.gif Type: image/gif Size: 10645 bytes Desc: not available URL: From kzak at redhat.com Wed Dec 27 20:56:08 2006 From: kzak at redhat.com (Karel Zak) Date: Wed, 27 Dec 2006 21:56:08 +0100 Subject: New device drivers don't see beyond 15 partitions in fc7 In-Reply-To: <20061222053121.GA22833@redhat.com> References: <458B115B.7060606@cox.net> <20061222053121.GA22833@redhat.com> Message-ID: <20061227205608.GE17785@petra.dvoda.cz> On Fri, Dec 22, 2006 at 12:31:21AM -0500, Dave Jones wrote: > On Thu, Dec 21, 2006 at 05:57:31PM -0500, Clyde E. Kunkel wrote: > > Hello, > > > > With the change from traditional /dev/hd* type device nodes to /dev/sd* > > type nodes, I see that the highest partition number that can be used is > > 15. Will this change so that higher numbers will be available? I do > > have a system that has a drive with almost 30 small partitions used in a > > research effort and the number of partitions has not been an issue thru fc6. > > afaik, The only way to achieve > 15 "partitions" per disk with /dev/sd* is to > use device mapper. I'm not sure the upper limit of logical volumes > per PV, but I'm fairly sure it's higher than 15. You can also use GPT (GUID Partition Table) for non-boot disks (or for all disks at ia64/s390). If I good remember the number of partitions is unlimited by GPT specification (= the limit depends on implementation; usually 128 partitions). The 'parted' supports GPT. http://en.wikipedia.org/wiki/GUID_Partition_Table Karel -- Karel Zak From dominik at greysector.net Wed Dec 27 21:54:20 2006 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 27 Dec 2006 22:54:20 +0100 Subject: Sharing devices "out of the box" In-Reply-To: <4592C607.4070000@pajato.com> References: <4592C607.4070000@pajato.com> Message-ID: <20061227215420.GA25226@ryvius.pekin.waw.pl> On Wednesday, 27 December 2006 at 20:14, Paul Michael Reilly wrote: > I've made my FC6 laptop available to family members (including grandma) > as a shared machine. I've taught them to log into their own session > using "switch user" so that they are on their own vt session. Works > nice until they want to share devices, like audio and the CD burner. > For FC6 I have to take pains to set up permissions appropriately but it > does occur to me to ask how Rawhide should deal with this. There seem > to be two schools of thought: > > 1) Sharing devices automagically is a no-brainer; it must be turned on > by default. > > 2) Sharing devices is a security weakness and no self respecting distro > would enable such a thing by default. > > It's all well and good when the PC is set up by a someone reading any of > the Redhat lists but should there come a day when Dell (or some such) > ships RHEL this issue and lots more like it will be on the table. > > It does occur to me that maybe the current user (the one who currently > owns X, the "selected" user for lack of a better description) should > dynamically own devices but this is not very satisfying: perhaps the > various users set their own special IM sounds in which case the distro > is setting policy rather than mechanism. So the issue does get > complicated quickly. Left to my own devices, I'd share the devices by > default and build in the ability to graphically configure device sharing > which smacks of a desktop (Gnome/KDE/Xfce/?) solution which might just > already exist and I haven't come across such a beast. You could put a question in anaconda (or firstboot) if you want to share devices with console users by default and configure accordingly (g+rw for devices and add local users to some special group?) On another note, I've just had an idea: upon installation, you are first presented not with a choice of software (that comes later), but with "profiles" (for a lack of a better term). For example: 1. mobile/laptop 2. desktop/workstation 3. server 1 will get, for example, bluetooth, wireless and NetworkManager enabled by default. 2 will get none of the above (by default) 3 will get no Xserver and desktop environments I think something like that was present in earlier RedHat releases. Regards, R. -- Fedora Extras contributor http://fedoraproject.org/wiki/DominikMierzejewski Livna contributor http://rpm.livna.org MPlayer developer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From green at redhat.com Thu Dec 28 00:20:30 2006 From: green at redhat.com (Anthony Green) Date: Wed, 27 Dec 2006 16:20:30 -0800 Subject: java-1.4.2-gcj-compat postinstall (in mock) fault - [WAS]Re: rawhide report: 20060802 changes In-Reply-To: References: Message-ID: <1167265230.3365.42.camel@localhost.localdomain> On Wed, 2006-12-27 at 12:12 -0500, Deji Akingunola wrote: > I'm getting this same segmentation fault in the root log of a mock > build that needs java-1.4.2-gcj-compat. Which package should I filled > this against, glibc or libgcj or java-1.4.2-gcj-compat. java-1.4.2-gcj-compat Thanks, AG From jspaleta at gmail.com Thu Dec 28 01:31:01 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 27 Dec 2006 16:31:01 -0900 Subject: Dependancies crack me up. In-Reply-To: <1167215765.23083.371.camel@dragon.valuecommerce.ne.jp> References: <1167215765.23083.371.camel@dragon.valuecommerce.ne.jp> Message-ID: <604aa7910612271731r67583cbdyff20779f760ddcf7@mail.gmail.com> On 12/27/06, Naoki wrote: > I can't see gnome-session really needing volume manager It's an explicit requires added by the packager because /usr/share/gnome/default.session includes volume-manager in the default session > or why volume manager needs gthumb? It's an explict requires added by the packager because /usr/bin/gthumb-import which is the default handler of cameras/photo cards and is included in gnome-volume-manager -jef From florin at andrei.myip.org Thu Dec 28 01:45:23 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 27 Dec 2006 17:45:23 -0800 Subject: Move Evolution to Extras? In-Reply-To: <4580.207.245.37.34.1167245384.squirrel@lattica.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> Message-ID: <459321B3.6040600@andrei.myip.org> Dimi Paun wrote: > Anyway, the Composer in Evo is in many ways better than in other mailers, > especially when dealing with code. For example, you can select a bit of > the message so it is the only part that's quoted, you can easily mark > part of the message as Preformatted to prevent it from wrapping lines, etc. > These are very handy for people dealing with code reviews and so forth. Hm, actually, the composer, to me, seemed like one of the worst Evo components. I don't use HTML formatting too often, but on those rare occasions when I do, Evo had pretty nasty formatting issues. Anyway, I've been using Evo since... I don't know, maybe version 0.1 :-) and recently, when upgrading to FC6, I just couldn't take it anymore and switched to Thunderbird. Now I can use the same mail client on any OS, but that's not the point. The point is, Thunderbird is orders of magnitude faster than Evo. I am not exaggerating. I have a couple IMAP accounts on two Cyrus IMAPd servers that I use concurrently, each one with perhaps around 100 folders or so, with server-side filtering (Sieve rocks!), probably up to 100k messages in each account, I would say several GB total. Depending on where I am located physically, at most one account or the other is "local", the other (or both) is via OpenVPN over broadband. (*) In these conditions, Evo takes ages to "boot up". I could literally fire it up then go and make a cup of tea before it finishes reading all those folders. And it's not the VPN that's slowing it down, even the local account is very slow to open. Thunderbird, OTOH, takes a couple seconds. The decision to switch was a no-brainer. The Evo team need to get their act together really quick. Their software currently is a mess. (*) - Cyrus IMAPd with Sieve server-side filtering, plus OpenVPN and Thunderbird is an absolutely amazing combination. No matter where I am, no matter what OS I am using, my email looks and behaves exactly the same. Throw a Squirrelmail or a Roundcube in, for good measure, and I can read my email even when all I have is a browser. Add a Google Browser Sync extension and my Firefox browser, too, can look and behave exactly the same everywhere and on any OS. Offtopic, but I just had to say it. :-) -- Florin Andrei http://florin.myip.org/ From dimi at lattica.com Thu Dec 28 05:20:10 2006 From: dimi at lattica.com (Dimi Paun) Date: Thu, 28 Dec 2006 00:20:10 -0500 (EST) Subject: Move Evolution to Extras? In-Reply-To: <459321B3.6040600@andrei.myip.org> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> Message-ID: <47263.74.96.19.63.1167283210.squirrel@lattica.com> On Wed, December 27, 2006 8:45 pm, Florin Andrei wrote: > Hm, actually, the composer, to me, seemed like one of the worst Evo > components. I don't use HTML formatting too often, but on those rare > occasions when I do, Evo had pretty nasty formatting issues. Hmm. maybe so, but I never use it in HTML mail, so I can't really comment on that. For plain text, it's pretty good. > Anyway, I've been using Evo since... I don't know, maybe version 0.1 :-) > and recently, when upgrading to FC6, I just couldn't take it anymore and > switched to Thunderbird. It's great you could do that. I tried, believe me! (I've updated to FC6 months ago, and I still can't send email!!! HTF is this an acceptable situation is beyond me, but people seem generally unconcerned about it) However, there are a couple of things that make Thunderbird not useful to me (due to the fact that I need to use it to comment on code): 1. The ability to select the portion that you want to reply to. For large patches, this is priceless, I don't want to have a huge reply that I have to trim to a few relevant lines. 2. More importantly, I need to be able to disable line wrapping, which doesn't seem possible in Thunderbird. Regardless, I'm sure a lot of folks will find it hard to switch from Evo willy-nilly. RH needs to get its act together and fix this situation before RHEL5. -- Dimi Paun Lattica, Inc. From sundaram at fedoraproject.org Thu Dec 28 06:01:37 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 Dec 2006 11:31:37 +0530 Subject: Sharing devices "out of the box" In-Reply-To: <20061227215420.GA25226@ryvius.pekin.waw.pl> References: <4592C607.4070000@pajato.com> <20061227215420.GA25226@ryvius.pekin.waw.pl> Message-ID: <45935DC1.7030303@fedoraproject.org> Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 27 December 2006 at 20:14, Paul Michael Reilly wrote: >> I've made my FC6 laptop available to family members (including grandma) >> as a shared machine. I've taught them to log into their own session >> using "switch user" so that they are on their own vt session. Works >> nice until they want to share devices, like audio and the CD burner. >> For FC6 I have to take pains to set up permissions appropriately but it >> does occur to me to ask how Rawhide should deal with this. There seem >> to be two schools of thought: >> >> 1) Sharing devices automagically is a no-brainer; it must be turned on >> by default. >> >> 2) Sharing devices is a security weakness and no self respecting distro >> would enable such a thing by default. >> >> It's all well and good when the PC is set up by a someone reading any of >> the Redhat lists but should there come a day when Dell (or some such) >> ships RHEL this issue and lots more like it will be on the table. >> >> It does occur to me that maybe the current user (the one who currently >> owns X, the "selected" user for lack of a better description) should >> dynamically own devices but this is not very satisfying: perhaps the >> various users set their own special IM sounds in which case the distro >> is setting policy rather than mechanism. So the issue does get >> complicated quickly. Left to my own devices, I'd share the devices by >> default and build in the ability to graphically configure device sharing >> which smacks of a desktop (Gnome/KDE/Xfce/?) solution which might just >> already exist and I haven't come across such a beast. > > You could put a question in anaconda (or firstboot) if you want to share > devices with console users by default and configure accordingly (g+rw for > devices and add local users to some special group?) These sort of questions shouldnt be pushed to the user. Choose a good default and make it easily configurable without relying on Anaconda. Also see http://fedoraproject.org/wiki/Desktop/FastUserSwitching which talks about device permissions. Rahul From sb at monkey-mind.net Thu Dec 28 08:11:52 2006 From: sb at monkey-mind.net (Steven Bakker) Date: Thu, 28 Dec 2006 09:11:52 +0100 Subject: Move Evolution to Extras? In-Reply-To: <47263.74.96.19.63.1167283210.squirrel@lattica.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <47263.74.96.19.63.1167283210.squirrel@lattica.com> Message-ID: <20061228091152.7d0f2601@cluestix.noc.ams-ix.net> On Thu, 28 Dec 2006 00:20:10 -0500 (EST) "Dimi Paun" wrote: > However, there are a couple of things that make Thunderbird not useful > to me (due to the fact that I need to use it to comment on code): > 1. The ability to select the portion that you want to reply to. > For large patches, this is priceless, I don't want to have a huge > reply that I have to trim to a few relevant lines. > 2. More importantly, I need to be able to disable line wrapping, > which doesn't seem possible in Thunderbird. 3. It only allows the user to set an automatic "Bcc" on composed messages, not a "Cc". For me, "3" was the reason to stick with Evo for so long. Haven't had too much trouble sending mail with Evo, but checking new mail is not always working (I only have IMAP folders) and it frequently hangs when I try to close it. This happens so often that I aliased "killev='evolution --force-shutdown'" :-/ Right now, I'm writing this from Sylpheed-Claws (Claws-Mail in development), which has improved a lot since I tried it last. It does not have the three limitations mentioned above, and the default composer has a very nice ruler at the top so I can always see how long my lines are :-) It doesn't compose HTML, but there is a plugin to view HTML. Cheers, Steven From promac at gmail.com Thu Dec 28 09:38:19 2006 From: promac at gmail.com (Paulo Cavalcanti) Date: Thu, 28 Dec 2006 07:38:19 -0200 Subject: LCD via VGA port Message-ID: <68720af30612280138p4f3b315ayee96a07112f7ce1d@mail.gmail.com> Hi, I have already posted this message at the user list and received no answer. If someone could say if he (or she) is using an LCD via a vga port, it would be a beginning. ------------------------------------------------------------------------------------------------------------- I am having problems connecting an LCD to a nvidia card using a VGA port in FC6. I only succeeded using either a DVI port or a DVI-VGA adaptor. With a real CRT everything works fine. I tried the VGA port approach in two different computers with two different graphics cards (GeForce 4 and FX-5200), two different Samsung LCDs (510N and 710N), and got the same result. With the nv driver, generally, the screen becomes black after a logout and X does not return. The nvidia driver is even worse. If I manage to login, the system hangs during a video intensive application, and opengl does not work. I have never had any problem using FC5, what makes me believe that the problem stems from xorg 7.1 Any suggestion will be really appreciated. Thanks, /Paulo Roma. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kmaraas at broadpark.no Thu Dec 28 10:19:49 2006 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Thu, 28 Dec 2006 11:19:49 +0100 Subject: rawhide report: 20061219 changes In-Reply-To: <1167249600.2952.5.camel@sioux.systems.cs.cornell.edu> References: <200612191102.kBJB2Uku026538@hs20-bc2-6.build.redhat.com> <1167249600.2952.5.camel@sioux.systems.cs.cornell.edu> Message-ID: <1167301190.26589.4.camel@rivendell> ons, 27.12.2006 kl. 15.00 -0500, skrev Saikat Guha: > On Tue, 2006-12-19 at 06:02 -0500, buildsys at redhat.com wrote: > > ORBit2-2.14.4-1.fc7 > > ------------------- > > * Tue Dec 19 2006 Matthias Clasen - 2.14.4-1 > > - Update to 2.14.4 > > After a full update today, a number of gnome apps are crashing on close. > The crashes seem to be inside ORBit2 (but I could be mistaken). > Looks like a g_return_if_fail (str != NULL); is needed there. This code hasn't changed in ages though, so I think the real cause of this is at-spi/gail changes lately. > http://bugzilla.gnome.org/show_bug.cgi?id=390111 > http://bugzilla.gnome.org/show_bug.cgi?id=390065 > http://bugzilla.gnome.org/show_bug.cgi?id=390057 > Commented in the bug too. > Possibly related, but any access to files through gnome VFS seems to > freeze the application. I cannot launch nautilus, do file>open in > various apps (not all) and so on. > Please file bugs and attach gdb to the process while it's hung to get a backtrace of it. Cheers Kjartan From wtogami at redhat.com Thu Dec 28 10:18:48 2006 From: wtogami at redhat.com (Warren Togami) Date: Thu, 28 Dec 2006 05:18:48 -0500 Subject: Move Evolution to Extras? In-Reply-To: <1167243602.1287.44.camel@dawkins> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> Message-ID: <45939A08.5070703@redhat.com> I don't know where this thread began, but note that Evolution *IS* moving to Extras... along with everything else in Core. Then Extras will be renamed. http://fedoraproject.org/wiki/Extras/Schedule/MergeCoreAndExtras Warren Togami wtogami at redhat.com From pbrobinson at gmail.com Thu Dec 28 11:07:43 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 28 Dec 2006 11:07:43 +0000 Subject: Move Evolution to Extras? In-Reply-To: <1167243602.1287.44.camel@dawkins> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> Message-ID: <5256d0b0612280307q574f981bt7275a7f9a242a706@mail.gmail.com> > > Isn't Evolution sort of, kind of, maintained by our fair friends over at > > Novell/Suse ? Does that have anything to do with this "Death to Evo" > > thread? > > > > The only over riding reason to _still_ use Evolution is to interface > > directly to a MS Exchange server. > > > > I happen to use it out of habit, not because it's better/worse. I > > perceive the mail filtering rules to be easier to configure and more > > robust than Thunderbird, but that may be _MY_ perception. > > As much as I absolutely loath Evolution I tend to agree, the filtering > and the way it displays threads seem much more natural than any other > mailer I've tried. That doesn't stop the massive amount of unrelated > suckage though, like the infamous #217567 wherein Evolution entirely > refuses to send mail for no apparent reason or the many other quirks. > > Evolution currently is the best of a lot of bad choices, it would be > nice if somewhere down the line we could find a replacement, especially > one that didn't come bundled with all this groupware functionality all > in one app. A simple mailer which can inter-operate with something like > Contacts and Dates to make a nicely separated PIM suite which shares > information would be ideal in my mind. Anything else seems to be begging > for disaster to me, complexity breeds the kind of madness Evolution has > become. Well the tinymail framework is sort of on the way to this. I think evo would be an improved beast if the evo team would start integrated a lot of the work the guys at openedhand have done like some of the memory improvements, the conversion from ORBit to dbus etc. At the moment I think there are 3+ branches of evo code so it would be nice to see some of that merged to actually see what the state of play with evo is. Peter From pbrobinson at gmail.com Thu Dec 28 11:10:09 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 28 Dec 2006 11:10:09 +0000 Subject: Move Evolution to Extras? In-Reply-To: <20061227191639.GM12390@plain.rackshack.net> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167246320.2429.125.camel@localhost.localdomain> <20061227191639.GM12390@plain.rackshack.net> Message-ID: <5256d0b0612280310t6edcb2bfg19935f92d70ce6b4@mail.gmail.com> > > It also blows away any excuses corporate pinheads might have for NOT > > integrating linux boxen into an Exchange network. > > If it worked, sure. Since the migration to Exchange 2003 or whatever it > is called, I never got any new mail, despite having Evolution set up to > check every few minutes. I have to double click the Inbox folder. And > even in half of those cases it will fail with a message like "Could not > refresh folder". People ask me why I don't get email until hours later. > Well, if only I had more time to baby-sit Evolution and double click the > Inbox folder throughout the day.. and just don't get me started on how > long it takes for Evolution at startup to check folders that haven't > changed since last time. While the evo-exchange does randomly crash (mostly while doing lookups for contacts on the server) I find it reasonable stable for mail and calendar on exchange 2003. > I hope they kept the IMAP service up, because I am finally ditching the > Outlook account. If you stick to IMAP, Evolution is almost sane in > comparison, as if it were a totally different application. If the > Exchange connector works the way I suspect it does (by scraping HTML > pages from the Outlook web interface), I am not surprised at all by its > flakiness. > > -- > Rudi > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From redhat at olen.net Thu Dec 28 11:51:36 2006 From: redhat at olen.net (Ola Thoresen) Date: Thu, 28 Dec 2006 12:51:36 +0100 Subject: Fwd: 32-bit AS Numbers Message-ID: <1167306697.10808.15.camel@ws21.ns5.powertech.no> Just a heads up. This might or might not affect things like whois, traceroute and maybe a few more binaries. -------- Forwarded Message -------- > > Dear Colleagues, > > We are pleased to announce that from 1 January 2007 we will > accept requests for 4-byte (32-bit) AS Numbers. The request > form and supporting notes are available in the RIPE Document > Store at: > http://www.ripe.net/ripe/docs/asnrequestform.html > http://www.ripe.net/ripe/docs/asnsupport.html > > Assignments will come from the following range: > > 3.0 - 3.1023 > > ASN32 objects will appear in the RIPE Database from 1 January 2007. > Their format is different from the current 16-bit ASNs. The new > format is described in these documents: > > http://www.ietf.org/internet-drafts/draft-michaelson-4byte-as-representation-02.txt > http://www.ietf.org/internet-drafts/draft-uijterwaal-rpsl-4byteas-ext-01.txt > > The introduction of 32-bit AS Numbers may have an effect on tools > that query the RIPE Database or those based on RPSL. > Rgds. Ola Thoresen From buc at odusz.so-cdu.ru Thu Dec 28 12:29:12 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 28 Dec 2006 15:29:12 +0300 Subject: Fwd: 32-bit AS Numbers In-Reply-To: <1167306697.10808.15.camel@ws21.ns5.powertech.no> References: <1167306697.10808.15.camel@ws21.ns5.powertech.no> Message-ID: <4593B898.8030609@odu.neva.ru> Ola Thoresen wrote: >Just a heads up. This might or might not affect things like whois, >traceroute and maybe a few more binaries. > > >-------- Forwarded Message -------- > > >>Dear Colleagues, >> >>We are pleased to announce that from 1 January 2007 we will >>accept requests for 4-byte (32-bit) AS Numbers. The request >>form and supporting notes are available in the RIPE Document >>Store at: >>http://www.ripe.net/ripe/docs/asnrequestform.html >>http://www.ripe.net/ripe/docs/asnsupport.html >> >>Assignments will come from the following range: >> >>3.0 - 3.1023 >> >>ASN32 objects will appear in the RIPE Database from 1 January 2007. >>Their format is different from the current 16-bit ASNs. >> ACK: It is safe for the current traceroute-2.0.x (when "traceroute -A" etc...) Dmitry Butskoy http://www.fedoraproject.org/wiki/DmitryButskoy From sundaram at fedoraproject.org Thu Dec 28 13:02:15 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 28 Dec 2006 18:32:15 +0530 Subject: Move Evolution to Extras? In-Reply-To: <47263.74.96.19.63.1167283210.squirrel@lattica.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <47263.74.96.19.63.1167283210.squirrel@lattica.com> Message-ID: <4593C057.2010605@fedoraproject.org> Dimi Paun wrote: > On Wed, December 27, 2006 8:45 pm, Florin Andrei wrote: >> Hm, actually, the composer, to me, seemed like one of the worst Evo >> components. I don't use HTML formatting too often, but on those rare >> occasions when I do, Evo had pretty nasty formatting issues. > > Hmm. maybe so, but I never use it in HTML mail, so I can't really > comment on that. For plain text, it's pretty good. > >> Anyway, I've been using Evo since... I don't know, maybe version 0.1 :-) >> and recently, when upgrading to FC6, I just couldn't take it anymore and >> switched to Thunderbird. > > It's great you could do that. I tried, believe me! (I've updated to FC6 > months ago, and I still can't send email!!! HTF is this an acceptable > situation is beyond me, but people seem generally unconcerned about it) Maybe that's because people are able to do it generally. Rahul From ben at burbong.com Thu Dec 28 13:14:34 2006 From: ben at burbong.com (Ben Stringer) Date: Fri, 29 Dec 2006 00:14:34 +1100 Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: <47263.74.96.19.63.1167283210.squirrel@lattica.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <47263.74.96.19.63.1167283210.squirrel@lattica.com> Message-ID: <1167311674.16672.10.camel@hillary> On Thu, 2006-12-28 at 00:20 -0500, Dimi Paun wrote: > > It's great you could do that. I tried, believe me! (I've updated to FC6 > months ago, and I still can't send email!!! HTF is this an acceptable > situation is beyond me, but people seem generally unconcerned about it) Have you confirmed other people have this problem? Evolution is sending email fine for me under FC6. What error do you receive when you try and send? Cheers, Ben Ben Stringer ===== ben at burbong.com ================================== From knightmerc at yahoo.com Thu Dec 28 13:17:06 2006 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Thu, 28 Dec 2006 08:17:06 -0500 Subject: Move Evolution to Extras? In-Reply-To: <5256d0b0612280310t6edcb2bfg19935f92d70ce6b4@mail.gmail.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167246320.2429.125.camel@localhost.localdomain> <20061227191639.GM12390@plain.rackshack.net> <5256d0b0612280310t6edcb2bfg19935f92d70ce6b4@mail.gmail.com> Message-ID: <1167311826.2429.162.camel@localhost.localdomain> On Thu, 2006-12-28 at 11:10 +0000, Peter Robinson wrote: > > > It also blows away any excuses corporate pinheads might have for NOT > > > integrating linux boxen into an Exchange network. > > > > If it worked, sure. Since the migration to Exchange 2003 or whatever it > > is called, I never got any new mail, despite having Evolution set up to > > check every few minutes. I have to double click the Inbox folder. And > > even in half of those cases it will fail with a message like "Could not > > refresh folder". People ask me why I don't get email until hours later. > > Well, if only I had more time to baby-sit Evolution and double click the > > Inbox folder throughout the day.. and just don't get me started on how > > long it takes for Evolution at startup to check folders that haven't > > changed since last time. > > While the evo-exchange does randomly crash (mostly while doing lookups > for contacts on the server) I find it reasonable stable for mail and > calendar on exchange 2003. This is my experience as well. --LX From sdl.web at gmail.com Thu Dec 28 13:48:17 2006 From: sdl.web at gmail.com (Leo) Date: Thu, 28 Dec 2006 13:48:17 +0000 Subject: Move Evolution to Extras? References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> Message-ID: * Florin Andrei (2006-12-27 17:45 -0800) said: ^^^^^^^^^^^^^ > Dimi Paun wrote: > >> Anyway, the Composer in Evo is in many ways better than in other mailers, >> especially when dealing with code. For example, you can select a bit of >> the message so it is the only part that's quoted, you can easily mark >> part of the message as Preformatted to prevent it from wrapping lines, etc. >> These are very handy for people dealing with code reviews and so forth. > > Hm, actually, the composer, to me, seemed like one of the worst Evo > components. I don't use HTML formatting too often, but on those rare > occasions when I do, Evo had pretty nasty formatting issues. > > Anyway, I've been using Evo since... I don't know, maybe version 0.1 > :-) > and recently, when upgrading to FC6, I just couldn't take it anymore > and switched to Thunderbird. > Now I can use the same mail client on any OS, but that's not the point. > > The point is, Thunderbird is orders of magnitude faster than Evo. I am > not exaggerating. I have a couple IMAP accounts on two Cyrus IMAPd > servers that I use concurrently, each one with perhaps around 100 > folders or so, with server-side filtering (Sieve rocks!), probably up > to 100k messages in each account, I would say several GB > total. Depending on where I am located physically, at most one account > or the other is "local", the other (or both) is via OpenVPN over > broadband. (*) > In these conditions, Evo takes ages to "boot up". I could literally > fire it up then go and make a cup of tea before it finishes reading > all those folders. And it's not the VPN that's slowing it down, even > the local account is very slow to open. > Thunderbird, OTOH, takes a couple seconds. > > The decision to switch was a no-brainer. > > The Evo team need to get their act together really quick. Their > software currently is a mess. 100% agreed. Evolution is useless for most users now. Not much has changed in the past few years. I used to keep it around but since I upgrade to Fedora 6, I have removed it completely. -- Leo (GPG Key: 9283AA3F) From jeff at ocjtech.us Thu Dec 28 14:48:12 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 28 Dec 2006 08:48:12 -0600 Subject: Move Evolution to Extras? In-Reply-To: References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> Message-ID: <1167317293.4579.23.camel@lt21223.campus.dmacc.edu> On Thu, 2006-12-28 at 13:48 +0000, Leo wrote: > > Evolution is useless for most users now. I think that you over-generalize. I find it quite useful. I'm sure that there are many other people that find it useful. Sure it has a few warts, but name me a piece of software that doesn't. > Not much has changed in the past few years. I disagree. > I used to keep it around but since I upgrade to Fedora 6, I have removed it completely. That's the beauty of open source, if you don't like it, use something else. Jeff -------------- 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 jeff at ocjtech.us Thu Dec 28 14:51:12 2006 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 28 Dec 2006 08:51:12 -0600 Subject: Move Evolution to Extras? In-Reply-To: <1167311826.2429.162.camel@localhost.localdomain> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167246320.2429.125.camel@localhost.localdomain> <20061227191639.GM12390@plain.rackshack.net> <5256d0b0612280310t6edcb2bfg19935f92d70ce6b4@mail.gmail.com> <1167311826.2429.162.camel@localhost.localdomain> Message-ID: <1167317472.4579.26.camel@lt21223.campus.dmacc.edu> On Thu, 2006-12-28 at 08:17 -0500, Lyvim Xaphir wrote: > > > > While the evo-exchange does randomly crash (mostly while doing lookups > > for contacts on the server) I find it reasonable stable for mail and > > calendar on exchange 2003. > > This is my experience as well. Here too... I use it daily to access my Exchange 2003 email and calendar. Jeff -------------- 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 gilboad at gmail.com Thu Dec 28 15:03:40 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Thu, 28 Dec 2006 17:03:40 +0200 Subject: Move Evolution to Extras? In-Reply-To: References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> Message-ID: <1167318220.6805.15.camel@gilboa-work-dev.localdomain> On Thu, 2006-12-28 at 13:48 +0000, Leo wrote: > * Florin Andrei (2006-12-27 17:45 -0800) said: > > 100% agreed. > > Evolution is useless for most users now. Not much has changed in the > past few years. I used to keep it around but since I upgrade to Fedora > 6, I have removed it completely. > > -- "Most" people? Do you have hard number to back these bold statement? Or are you just using TEST_GROUP == ( Florin Andrei)? - Gilboa From saikat at cs.cornell.edu Thu Dec 28 15:09:52 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Thu, 28 Dec 2006 10:09:52 -0500 Subject: Move Evolution to Extras? In-Reply-To: References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> Message-ID: <1167318592.17863.10.camel@sioux.systems.cs.cornell.edu> On Thu, 2006-12-28 at 13:48 +0000, Leo wrote: > Evolution is useless for most users now. Do you have data to support your claim? On Fedora-devel, Evolution is responsible for 78% of the emails. The next closest is Sylpheed with 9% [saikat at sniper ~]$ grep -h '^X-Mailer' .mail/.Lists.Fedora/cur -r | awk '{print $2}' | sort | uniq -c | sort -n 1 Claws 1 Lotus 1 OpenWebMail 1 PHP/4.3.9 1 phpmailer 2 Apple 2 Balsa 2 Mew 2 SquirrelMail/1.4.3a 2 WWW-Mail 3 eMail 4 http://www.courier-mta.org/cone/ 4 SnapperMail 4 Ximian 6 QUALCOMM 11 VM 15 SquirrelMail 19 MH-E 20 Microsoft 32 Sylpheed 40 Sylpheed-Claws 619 Evolution -- Saikat -------------- 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 saikat at cs.cornell.edu Thu Dec 28 15:21:11 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Thu, 28 Dec 2006 10:21:11 -0500 Subject: Move Evolution to Extras? In-Reply-To: <1167318592.17863.10.camel@sioux.systems.cs.cornell.edu> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318592.17863.10.camel@sioux.systems.cs.cornell.edu> Message-ID: <1167319271.17863.18.camel@sioux.systems.cs.cornell.edu> On Thu, 2006-12-28 at 10:09 -0500, Saikat Guha wrote: > On Fedora-devel, Evolution is responsible for 78% of the emails. > The next closest is Sylpheed with 9% Correction. I didn't test for the User-Agent header. Out of 2075 mails, Evolution 29.8313% Thunderbird 21.3976% Mutt 18.8916% KMail 8.8675% Mozilla 5.4940% SquirrelMail 2.2651% ---- [saikat at sniper ~]$ grep -h '^\(X-Mailer\|User-Agent \)' .mail/.Lists.Fedora/cur -r | tr '/' ' ' | awk '{print $2}' | sort | uniq -c | sort -nr 619 Evolution 444 Thunderbird 392 Mutt 184 KMail 114 Mozilla 47 SquirrelMail 40 Sylpheed-Claws 39 Loom 32 Sylpheed 32 Gnus 27 KNode 20 Microsoft 19 MH-E 11 VM 8 mutt-ng 6 QUALCOMM 6 Pan 4 Ximian 4 SnapperMail 4 http: 3 %p!0,0! 3 Internet 3 eMail 2 WWW-Mail 2 Mew 2 Balsa 2 Apple 1 phpmailer 1 PHP 1 OpenWebMail 1 Microsoft-Entourage 1 Lotus 1 Claws -- Saikat -------------- 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 pertusus at free.fr Thu Dec 28 15:28:26 2006 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 28 Dec 2006 16:28:26 +0100 Subject: Move Evolution to Extras? In-Reply-To: <1167318592.17863.10.camel@sioux.systems.cs.cornell.edu> References: <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318592.17863.10.camel@sioux.systems.cs.cornell.edu> Message-ID: <20061228152826.GC3714@free.fr> On Thu, Dec 28, 2006 at 10:09:52AM -0500, Saikat Guha wrote: > On Thu, 2006-12-28 at 13:48 +0000, Leo wrote: > > Evolution is useless for most users now. > > On Fedora-devel, Evolution is responsible for 78% of the emails. > The next closest is Sylpheed with 9% Not all mailer use X-Mailer. Others use User-Agent. With the following: grep -h '^\(User-Agent\|X-Mailer\)' fedora-devel-list -r | awk '{print $2}' | sed 's;/.*;;' | sort | uniq -c | sort -n I get (for the mail saved in my fedora-devel-list mailbox, which may be biased): 1 AT&T 1 Mulberry 1 Null 1 SnapperMail 1 Wanderlust 2 Apple 2 http: 2 %p!0,0! 2 Pan 4 Loom 5 Balsa 5 Internet 7 VM 8 MH-E 10 Mail 16 KNode 16 Mew 20 SquirrelMail 23 Sylpheed-Claws 32 Gnus 43 Sylpheed 49 KMail 91 Ximian 134 Mozilla 148 Thunderbird 295 Mutt 330 Evolution There still seems to be about 200 mails not counted. Evolution is still first, but with a lower share. Maybe Ximian is also evolution, though. This is not very relevant, though, since mutt is second, this is certainly biased numbers. -- Pat From buc at odusz.so-cdu.ru Thu Dec 28 15:32:04 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 28 Dec 2006 18:32:04 +0300 Subject: Move Evolution to Extras? In-Reply-To: <45939A08.5070703@redhat.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <45939A08.5070703@redhat.com> Message-ID: <4593E374.3030402@odu.neva.ru> Warren Togami wrote: > I don't know where this thread began, but note that Evolution *IS* > moving to Extras... > > along with everything else in Core. > > Then Extras will be renamed. > > http://fedoraproject.org/wiki/Extras/Schedule/MergeCoreAndExtras > BTW, what about upcoming EPEL in this context? "Core + Extras(FC-N branches)" => "some common stuff", "Extras(EPEL-N branches)" => ??? Dmitry Butskoy From dimi at lattica.com Thu Dec 28 15:38:22 2006 From: dimi at lattica.com (Dimi Paun) Date: Thu, 28 Dec 2006 10:38:22 -0500 (EST) Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: <1167311674.16672.10.camel@hillary> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <47263.74.96.19.63.1167283210.squirrel@lattica.com> <1167311674.16672.10.camel@hillary> Message-ID: <2896.207.245.37.34.1167320302.squirrel@lattica.com> On Thu, December 28, 2006 8:14 am, Ben Stringer wrote: > Have you confirmed other people have this problem? Evolution is sending > email fine for me under FC6. What error do you receive when you try and > send? Well, I filed a bug at the beginning at the month: http://bugzilla.gnome.org/show_bug.cgi?id=383618 Nobody even looked at it. I have a fairly standard configuration: postfix as the server + SMTP over SSL + user authentication. It worked just fine until I've upgraded to FC6. It also works with other mailers (like Thunderbird, Claws, etc). I can't see what I have so special that the darn thing decided to not work. And after it refuses to send email, you can't close it, etc -- a symptom reported by lots of folks. Sad. -- Dimi Paun Lattica, Inc. From denis at poolshark.org Thu Dec 28 16:31:31 2006 From: denis at poolshark.org (Denis Leroy) Date: Thu, 28 Dec 2006 17:31:31 +0100 Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: <2896.207.245.37.34.1167320302.squirrel@lattica.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <47263.74.96.19.63.1167283210.squirrel@lattica.com> <1167311674.16672.10.camel@hillary> <2896.207.245.37.34.1167320302.squirrel@lattica.com> Message-ID: <4593F163.8060909@poolshark.org> Dimi Paun wrote: > On Thu, December 28, 2006 8:14 am, Ben Stringer wrote: >> Have you confirmed other people have this problem? Evolution is sending >> email fine for me under FC6. What error do you receive when you try and >> send? > > Well, I filed a bug at the beginning at the month: > http://bugzilla.gnome.org/show_bug.cgi?id=383618 > > Nobody even looked at it. I have a fairly standard configuration: > postfix as the server + SMTP over SSL + user authentication. > > It worked just fine until I've upgraded to FC6. It also works with > other mailers (like Thunderbird, Claws, etc). > > I can't see what I have so special that the darn thing decided to > not work. And after it refuses to send email, you can't close it, > etc -- a symptom reported by lots of folks. Yup, exact same thing here. I use evo to access my work mail with IMAPS. Sending usually works right after evo starts, but eventually it'll stop working. Reading mail still work, but trying to close the app causes it to hang. Some sort of network connection timeout not being handled right. It's also a FC-6 regression for me, FC-5 had no problems. From briang at pmccorp.com Thu Dec 28 17:09:47 2006 From: briang at pmccorp.com (Brian Gaynor) Date: Thu, 28 Dec 2006 09:09:47 -0800 Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: <4593F163.8060909@poolshark.org> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <47263.74.96.19.63.1167283210.squirrel@lattica.com> <1167311674.16672.10.camel@hillary> <2896.207.245.37.34.1167320302.squirrel@lattica.com> <4593F163.8060909@poolshark.org> Message-ID: <1167325787.3507.1.camel@brians-laptop> On Thu, 2006-12-28 at 17:31 +0100, Denis Leroy wrote: > Dimi Paun wrote: > Yup, exact same thing here. I use evo to access my work mail with IMAPS. > Sending usually works right after evo starts, but eventually it'll stop > working. Reading mail still work, but trying to close the app causes it > to hang. Some sort of network connection timeout not being handled > right. It's also a FC-6 regression for me, FC-5 had no problems. Identical behavior here as well. FC6 Evo has made the Gnome "Force Quit" panel applet a must have. Brian From buc at odusz.so-cdu.ru Thu Dec 28 17:27:23 2006 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 28 Dec 2006 20:27:23 +0300 Subject: Xawtv: some questions Message-ID: <4593FE7B.3020107@odu.neva.ru> Since FC-2, "xawtv" package was replaced by "tvtime". Whereas it gives some improvements in GUI, there is a regression too -- an absence of some useful command-line tools and console radio. I'm still using "radio" (console/cmdline radio application) and "v4lctl" (for example, to set the TV channel when an application is not capable for this). Anyway, such tools could be useful for scripting and network streaming (i.e. start to record radio from the crond, etc.) Project page is http://linux.bytesex.org/xawtv/ I'm thinking about xawtv for Extras, but there are a couple of questions: 1) What reasons have led to decision-making on change of TV viewer? Are there some technical or legal issues? 2) Xawtv includes code for "avi" file format, for "mjpeg" and for "quicktime" (by an external library). Are this things allowed, or we must strip the tarball properly (on the same manner as "xine-lib" is done now)? 3) Is it applicable to provide the needed tools only, without TV viewer at all? 4) Should the package be splitted to subpackages (as some distros use it) or one big package is better (Fedora way)? 5) What about "tv-fonts", accompanied with xawtv? Whether it is required or not? How it should be named ("xawtv-tv-fonts" or just "tv-fonts")? ... Note, that one of the problem for the "radio" was unicode console support, which I've added recently. :) Regards, Dmitry Butskoy, http://www.fedoraproject.org/wiki/DmitryButskoy From netmask at webset.net Thu Dec 28 18:09:43 2006 From: netmask at webset.net (Mauricio Teixeira (netmask)) Date: Thu, 28 Dec 2006 15:09:43 -0300 Subject: [OT] Re: Move Evolution to Extras? In-Reply-To: <1167325787.3507.1.camel@brians-laptop> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <47263.74.96.19.63.1167283210.squirrel@lattica.com> <1167311674.16672.10.camel@hillary> <2896.207.245.37.34.1167320302.squirrel@lattica.com> <4593F163.8060909@poolshark.org> <1167325787.3507.1.camel@brians-laptop> Message-ID: <1167329383.2819.12.camel@scrat.homelinux.net> Em Qui, 2006-12-28 ?s 09:09 -0800, Brian Gaynor escreveu: > > Yup, exact same thing here. I use evo to access my work mail with IMAPS. > > Identical behavior here as well. FC6 Evo has made the Gnome "Force Quit" > panel applet a must have. I have Evolution on FC6 connecting to IMAPS for reading and SMTP+TLS for sending, and it works flawlessly. Nothing hangs, never loses any msgs, and the boxes update pretty fast. -- % Mauricio Teixeira (netmask) | Maceio/AL/BR % % mteixeira{a}webset{d}net | http://smartpm.org % % http://mteixeira.webset.net | http://pmping.sf.net % From sdl.web at gmail.com Fri Dec 29 00:37:39 2006 From: sdl.web at gmail.com (Leo) Date: Fri, 29 Dec 2006 00:37:39 +0000 Subject: Move Evolution to Extras? References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318220.6805.15.camel@gilboa-work-dev.localdomain> Message-ID: * Gilboa Davara (2006-12-28 17:03 +0200) said: ^^^^^^^^^^^^^ > On Thu, 2006-12-28 at 13:48 +0000, Leo wrote: >> * Florin Andrei (2006-12-27 17:45 -0800) said: >> >> 100% agreed. >> >> Evolution is useless for most users now. Not much has changed in the >> past few years. I used to keep it around but since I upgrade to Fedora >> 6, I have removed it completely. >> >> -- > > "Most" people? > > Do you have hard number to back these bold statement? Or are you > just using TEST_GROUP == ( Florin Andrei)? There are many polls on the Internet. For example one done by Mozilla, http://www.mozillazine.org/poll_results.html?id=7542. -- Leo (GPG Key: 9283AA3F) From dyek at real.com Fri Dec 29 00:37:36 2006 From: dyek at real.com (Daniel Yek) Date: Thu, 28 Dec 2006 16:37:36 -0800 Subject: Move Evolution to Extras? / Annoying "ability" to select the portion that you want to reply In-Reply-To: <47263.74.96.19.63.1167283210.squirrel@lattica.com> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <47263.74.96.19.63.1167283210.squirrel@lattica.com> Message-ID: <6.2.1.2.2.20061228162424.3b564ff0@mailone.real.com> At 09:20 PM 12/27/2006, Dimi Paun wrote: >However, there are a couple of things that make Thunderbird not useful >to me (due to the fact that I need to use it to comment on code): > 1. The ability to select the portion that you want to reply to. Personally, this is one of the most annoying feature added to Evolution. When I read my email, I habitually highlight words, indicating where I was reading. When I'm done reading, I hit reply, and gosh, I got some incomplete words in the email body. So, I have to repeatedly cancel the reply message window, highlight some text, then it will proceed to the next stage of highlighting the whole line, then I could remove the highlight in such a way that the reply message body is complete, not empty. If there is an option to optionally disable this feature, I would then not be annoyed so much. (I apologize if my expression is a bit too strong somehow...) > For large patches, this is priceless, I don't want to have a huge > reply that I have to trim to a few relevant lines. -- Daniel Yek From warren at togami.com Fri Dec 29 00:38:39 2006 From: warren at togami.com (Warren Togami) Date: Thu, 28 Dec 2006 19:38:39 -0500 Subject: Move Evolution to Extras? In-Reply-To: <4593E374.3030402@odu.neva.ru> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <45939A08.5070703@redhat.com> <4593E374.3030402@odu.neva.ru> Message-ID: <4594638F.6070301@togami.com> Dmitry Butskoy wrote: > Warren Togami wrote: > >> I don't know where this thread began, but note that Evolution *IS* >> moving to Extras... >> >> along with everything else in Core. >> >> Then Extras will be renamed. >> >> http://fedoraproject.org/wiki/Extras/Schedule/MergeCoreAndExtras >> > > BTW, what about upcoming EPEL in this context? > > "Core + Extras(FC-N branches)" => "some common stuff", > "Extras(EPEL-N branches)" => ??? RHEL's contents have nothing to do with Fedora's contents and vice versa. Warren Togami wtogami at redhat.com From sdl.web at gmail.com Fri Dec 29 00:40:05 2006 From: sdl.web at gmail.com (Leo) Date: Fri, 29 Dec 2006 00:40:05 +0000 Subject: Move Evolution to Extras? References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318592.17863.10.camel@sioux.systems.cs.cornell.edu> Message-ID: * Saikat Guha (2006-12-28 10:09 -0500) said: ^^^^^^^^^^^ > On Thu, 2006-12-28 at 13:48 +0000, Leo wrote: >> Evolution is useless for most users now. > > Do you have data to support your claim? > > On Fedora-devel, Evolution is responsible for 78% of the emails. > The next closest is Sylpheed with 9% > > > [saikat at sniper ~]$ grep -h '^X-Mailer' .mail/.Lists.Fedora/cur -r | awk > '{print $2}' | sort | uniq -c | sort -n > 1 Claws > 1 Lotus > 1 OpenWebMail > 1 PHP/4.3.9 > 1 phpmailer > 2 Apple > 2 Balsa > 2 Mew > 2 SquirrelMail/1.4.3a > 2 WWW-Mail > 3 eMail > 4 http://www.courier-mta.org/cone/ > 4 SnapperMail > 4 Ximian > 6 QUALCOMM > 11 VM > 15 SquirrelMail > 19 MH-E > 20 Microsoft > 32 Sylpheed > 40 Sylpheed-Claws > 619 Evolution No surprise to see such result. I guess most users visiting this group are using Fedora system and evolution is the default email client. -- Leo (GPG Key: 9283AA3F) From sdl.web at gmail.com Fri Dec 29 00:49:51 2006 From: sdl.web at gmail.com (Leo) Date: Fri, 29 Dec 2006 00:49:51 +0000 Subject: Move Evolution to Extras? References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318592.17863.10.camel@sioux.systems.cs.cornell.edu> <1167319271.17863.18.camel@sioux.systems.cs.cornell.edu> Message-ID: * Saikat Guha (2006-12-28 10:21 -0500) said: ^^^^^^^^^^^ > On Thu, 2006-12-28 at 10:09 -0500, Saikat Guha wrote: >> On Fedora-devel, Evolution is responsible for 78% of the emails. >> The next closest is Sylpheed with 9% > > Correction. I didn't test for the User-Agent header. > Out of 2075 mails, > > Evolution 29.8313% > Thunderbird 21.3976% > Mutt 18.8916% > KMail 8.8675% > Mozilla 5.4940% > SquirrelMail 2.2651% Thank you for verifying my claim. The only reason Evolution has a slight edge over other email clients is the fact that it is the default email client installed and even put on gnome panel. If we stop doing this, I expect the percentage of Evolution to drop sharply. -- Leo (GPG Key: 9283AA3F) From pp at ee.oulu.fi Fri Dec 29 00:51:04 2006 From: pp at ee.oulu.fi (Pekka Pietikainen) Date: Fri, 29 Dec 2006 02:51:04 +0200 Subject: Move Evolution to Extras? In-Reply-To: <4594638F.6070301@togami.com> References: <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <45939A08.5070703@redhat.com> <4593E374.3030402@odu.neva.ru> <4594638F.6070301@togami.com> Message-ID: <20061229005104.GA710@ee.oulu.fi> On Thu, Dec 28, 2006 at 07:38:39PM -0500, Warren Togami wrote: > RHEL's contents have nothing to do with Fedora's contents and vice versa. Could we get rid of tog-pegasus.i386 2:2.5.2-2.fc6 core Matched from: tog-pegasus OpenPegasus WBEM Services for Linux OpenPegasus WBEM Services for Linux enables management solutions that deliver increased control of enterprise resources. WBEM is a platform and resource independent DMTF standard that defines a common information model and communication protocol for monitoring and controlling resources from diverse sources. http://www.openpegasus.org in core, then :) (I have yet to find anyone find a use for it, and am under the impression it's some sort of middleware that some Enterprise Software from Enterprise Vendors (tm) uses and then it might do something semi-useful) -- Pekka Pietikainen From sdl.web at gmail.com Fri Dec 29 00:54:53 2006 From: sdl.web at gmail.com (Leo) Date: Fri, 29 Dec 2006 00:54:53 +0000 Subject: Move Evolution to Extras? / Annoying "ability" to select the portion that you want to reply References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <47263.74.96.19.63.1167283210.squirrel@lattica.com> <6.2.1.2.2.20061228162424.3b564ff0@mailone.real.com> Message-ID: * Daniel Yek (2006-12-28 16:37 -0800) said: ^^^^^^^^^^ > Personally, this is one of the most annoying feature added to > Evolution. When I read my email, I habitually highlight words, > indicating where I was reading. When I'm done reading, I hit reply, > and gosh, I got some incomplete words in the email body. So, I have > to repeatedly cancel the reply message window, highlight some text, > then it will proceed to the next stage of highlighting the whole > line, then I could remove the highlight in such a way that the reply > message body is complete, not empty. If there is an option to > optionally disable this feature, I would then not be annoyed so > much. It is a nice feature compared to append the whole original message like outlook does. Anyway, it is a personal preference. -- Leo (GPG Key: 9283AA3F) From peterwu at canada.com Fri Dec 29 01:23:08 2006 From: peterwu at canada.com (Peter Wu) Date: Thu, 28 Dec 2006 20:23:08 -0500 Subject: Move Evolution to Extras? In-Reply-To: (Leo's message of "Thu\, 28 Dec 2006 13\:48\:17 +0000") References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> Message-ID: On Thu, 28 Dec 2006 13:48:17 +0000, Leo wrote: > Evolution is useless for most users now. Not much has changed in the > past few years. I used to keep it around but since I upgrade to Fedora > 6, I have removed it completely. Did you remove the annoying evolution-data-server completely as well in FC6? It seems that the following important apps depend on it. ,---- | Dependencies Resolved | | ============================================================================= | Package Arch Version Repository Size | ============================================================================= | Removing: | evolution-data-server i386 1.8.2-1.fc6 installed 9.8 M | Removing for dependencies: | NetworkManager-gnome i386 1:0.6.4-5.fc6 installed 393 k | beagle i386 0.2.13-1.fc6 installed 3.3 M | beagle-gui i386 0.2.13-1.fc6 installed 469 k | bug-buddy i386 1:2.16.0-3.fc6 installed 1.6 M | compiz i386 0.0.13-0.32.20060817git.fc6 installed 1.9 M | control-center i386 1:2.16.0-11.fc6 installed 8.1 M | evolution-data-server-devel i386 1.8.2-1.fc6 installed 3.5 M | gaim i386 2:2.0.0-0.26.beta5.fc6 installed 17 M | gnome-applets i386 1:2.16.0.1-12.fc6 installed 32 M | gnome-netstatus i386 2.12.0-5.1 installed 971 k | gnome-panel i386 2.16.1-3.fc6 installed 10 M | gnome-pilot i386 2.0.15-1.fc6 installed 1.9 M | gnome-python2-applet i386 2.16.0-1.fc6 installed 16 k | gnome-session i386 2.16.0-7.fc6 installed 1.3 M | gnome-sharp i386 2.16.0-1.fc6 installed 1.7 M | gnome-utils i386 1:2.16.0-1.fc6 installed 8.5 M | gnome-volume-manager i386 2.15.0-4.fc6 installed 1.9 M | libgail-gnome i386 1.1.3-1.2.1 installed 60 k | nautilus-sendto i386 0.7-5.fc6 installed 174 k | nautilus-sendto-bluetooth i386 0.7-5.fc6 installed 8.6 k | orca i386 1.0.0-4.fc6 installed 3.4 M | tomboy i386 0.4.1-1.fc6 installed 1.7 M `---- -- Peter Wu Powered by Fedora Core 6 "I know nothing except the fact of my ignorance." -- Socrates (470-399 B.C.) From sdl.web at gmail.com Fri Dec 29 01:59:50 2006 From: sdl.web at gmail.com (Leo) Date: Fri, 29 Dec 2006 01:59:50 +0000 Subject: Move Evolution to Extras? References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> Message-ID: * Peter Wu (2006-12-28 20:23 -0500) said: ^^^^^^^^ > On Thu, 28 Dec 2006 13:48:17 +0000, Leo wrote: > >> Evolution is useless for most users now. Not much has changed in the >> past few years. I used to keep it around but since I upgrade to Fedora >> 6, I have removed it completely. > > Did you remove the annoying evolution-data-server completely as well > in FC6? It seems that the following important apps depend on it. No. evolution-data-server is just a dependence happen to have "evolution" in it. I remember there is one article in "desktop-devel-list at gnome.org" explaining this. -- Leo (GPG Key: 9283AA3F) From gilboad at gmail.com Fri Dec 29 07:36:02 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Fri, 29 Dec 2006 09:36:02 +0200 Subject: Move Evolution to Extras? In-Reply-To: References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318220.6805.15.camel@gilboa-work-dev.localdomain> Message-ID: <1167377762.8348.5.camel@gilboa-home-dev.localdomain> On Fri, 2006-12-29 at 00:37 +0000, Leo wrote: > * Gilboa Davara (2006-12-28 17:03 +0200) said: > ^^^^^^^^^^^^^ > > On Thu, 2006-12-28 at 13:48 +0000, Leo wrote: > >> * Florin Andrei (2006-12-27 17:45 -0800) said: > >> > >> 100% agreed. > >> > >> Evolution is useless for most users now. Not much has changed in the > >> past few years. I used to keep it around but since I upgrade to Fedora > >> 6, I have removed it completely. > >> > >> -- > > > > "Most" people? > > > > Do you have hard number to back these bold statement? Or are you > > just using TEST_GROUP == ( Florin Andrei)? > > There are many polls on the Internet. For example one done by Mozilla, > http://www.mozillazine.org/poll_results.html?id=7542. > > -- > Leo (GPG Key: 9283AA3F) > This pole is irrelevant as the test group consists of non Fedora/Linux users. More-ever having this pole in... Mozillazine makes it less, err, objective. The OP made a bold statement about *Fedora* users. I would have been nice if he took the time to back it up with solid numbers. BTW, once Thunderbird / Lightning get OpenSync/Pilot support, I'll be the first one to dump Evo. Until such time (and as long as KMail remains a usability nightmare [and this from an avid KDE user...]), leave Evolution be. - Gilboa From pbrobinson at gmail.com Fri Dec 29 09:27:56 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 29 Dec 2006 09:27:56 +0000 Subject: Move Evolution to Extras? In-Reply-To: References: <1144155199.2808.94.camel@dimi> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318592.17863.10.camel@sioux.systems.cs.cornell.edu> <1167319271.17863.18.camel@sioux.systems.cs.cornell.edu> Message-ID: <5256d0b0612290127w6cce8701h65ccaa0dbf1b859@mail.gmail.com> > * Saikat Guha (2006-12-28 10:21 -0500) said: > ^^^^^^^^^^^ > > On Thu, 2006-12-28 at 10:09 -0500, Saikat Guha wrote: > >> On Fedora-devel, Evolution is responsible for 78% of the emails. > >> The next closest is Sylpheed with 9% > > > > Correction. I didn't test for the User-Agent header. > > Out of 2075 mails, > > > > Evolution 29.8313% > > Thunderbird 21.3976% > > Mutt 18.8916% > > KMail 8.8675% > > Mozilla 5.4940% > > SquirrelMail 2.2651% > > Thank you for verifying my claim. > > The only reason Evolution has a slight edge over other email clients > is the fact that it is the default email client installed and even put > on gnome panel. If we stop doing this, I expect the percentage of > Evolution to drop sharply. I disagree entirely. If the mailing-list was something like fedora users or a newbies list that would be quite likely but on fedora-devel people should know how to select their own mail client, whether it be in core or extras, and be generally able to make up their own mind. For the general population I think evo is fine, it is without doubt that it definitely needs help on edge cases and some stability stuff but I think that if the evo team would merge some of the branches out there we'd fix the majority of the problems and see a great improvement. Peter From sundaram at fedoraproject.org Fri Dec 29 10:05:56 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 29 Dec 2006 15:35:56 +0530 Subject: Move Evolution to Extras? In-Reply-To: <20061229005104.GA710@ee.oulu.fi> References: <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <45939A08.5070703@redhat.com> <4593E374.3030402@odu.neva.ru> <4594638F.6070301@togami.com> <20061229005104.GA710@ee.oulu.fi> Message-ID: <4594E884.6040403@fedoraproject.org> Pekka Pietikainen wrote: > On Thu, Dec 28, 2006 at 07:38:39PM -0500, Warren Togami wrote: >> RHEL's contents have nothing to do with Fedora's contents and vice versa. > Could we get rid of > > tog-pegasus.i386 2:2.5.2-2.fc6 core > Matched from: > tog-pegasus > OpenPegasus WBEM Services for Linux > OpenPegasus WBEM Services for Linux enables management solutions that > deliver > increased control of enterprise resources. WBEM is a platform and resource > independent DMTF standard that defines a common information model and > communication protocol for monitoring and controlling resources from diverse > sources. > http://www.openpegasus.org > > in core, then :) You want to move it to extras I suppose. Since the plan is to merge them anyway, it is not useful to talk about movement of packages at this stage. Rahul From miles.lane at gmail.com Fri Dec 29 16:18:39 2006 From: miles.lane at gmail.com (Miles Lane) Date: Fri, 29 Dec 2006 08:18:39 -0800 Subject: Fwd: 2.6.19-1.2891.fc7 -- INFO: soft-safe -> soft-unsafe lock order detected In-Reply-To: References: Message-ID: Since I have received no reply on the development testers list, I'll try here. ---------- Forwarded message ---------- From: Miles Lane Date: Dec 29, 2006 1:17 AM Subject: 2.6.19-1.2891.fc7 -- INFO: soft-safe -> soft-unsafe lock order detected To: For testers of Fedora Core development releases [ INFO: soft-safe -> soft-unsafe lock order detected ] 2.6.19-1.2891.fc7 #1 ------------------------------------------------------ cupsd/1884 [HC0[0]:SC0[1]:HE1:SE0] is trying to acquire: (&ssec->nlbl_lock){--..}, at: [] selinux_netlbl_socket_setsid+0xbb/0x123 and this task is already holding: (af_callback_keys + sk->sk_family#3){-.-+}, at: [] inet_accept+0x70/0xb5 which would create a new lock dependency: (af_callback_keys + sk->sk_family#3){-.-+} -> (&ssec->nlbl_lock){--..} but this new dependency connects a soft-irq-safe lock: (af_callback_keys + sk->sk_family#3){-.-+} ... which became soft-irq-safe at: [] __lock_acquire+0x37d/0x9f8 [] lock_acquire+0x56/0x6f [] _read_lock_bh+0x30/0x3d [] selinux_socket_sock_rcv_skb+0xbd/0x252 [] tcp_v4_rcv+0x37a/0x909 [] ip_local_deliver+0x185/0x22e [] ip_rcv+0x418/0x450 [] netif_receive_skb+0x2db/0x35a [] process_backlog+0x95/0xf6 [] net_rx_action+0xa1/0x1a8 [] __do_softirq+0x6f/0xe2 [] do_softirq+0x61/0xc7 [] 0xffffffff to a soft-irq-unsafe lock: (&ssec->nlbl_lock){--..} ... which became soft-irq-unsafe at: ... [] __lock_acquire+0x409/0x9f8 [] lock_acquire+0x56/0x6f [] _spin_lock+0x2b/0x38 [] selinux_netlbl_socket_setsid+0xbb/0x123 [] selinux_netlbl_socket_post_create+0x2d/0x2f [] selinux_socket_post_create+0x156/0x15c [] __sock_create+0x179/0x1b2 [] sock_create+0x1a/0x1f [] sys_socket+0x1b/0x3c [] sys_socketcall+0x77/0x241 [] syscall_call+0x7/0xb [] 0xffffffff other info that might help us debug this: 3 locks held by cupsd/1884: #0: (sk_lock-AF_INET){--..}, at: [] inet_accept+0x31/0xb5 #1: (af_callback_keys + sk->sk_family#3){-.-+}, at: [] inet_accept+0x70/0xb5 #2: (policy_rwlock){..-?}, at: [] selinux_netlbl_socket_setsid+0x54/0x123 the soft-irq-safe lock's dependencies: -> (af_callback_keys + sk->sk_family#3){-.-+} ops: 0 { initial-use at: [] __lock_acquire+0x424/0x9f8 [] lock_acquire+0x56/0x6f [] _write_lock_bh+0x30/0x3d [] tcp_close+0x24b/0x52b [] inet_release+0x43/0x49 [] sock_release+0x17/0x68 [] sock_close+0x2d/0x33 [] __fput+0xbe/0x168 [] fput+0x17/0x19 [] filp_close+0x54/0x5c [] sys_close+0x78/0xb0 [] syscall_call+0x7/0xb [] 0xffffffff hardirq-on-W at: [] __lock_acquire+0x3e2/0x9f8 [] lock_acquire+0x56/0x6f [] _write_lock_bh+0x30/0x3d [] tcp_close+0x24b/0x52b [] inet_release+0x43/0x49 [] sock_release+0x17/0x68 [] sock_close+0x2d/0x33 [] __fput+0xbe/0x168 [] fput+0x17/0x19 [] filp_close+0x54/0x5c [] sys_close+0x78/0xb0 [] syscall_call+0x7/0xb [] 0xffffffff in-softirq-R at: [] __lock_acquire+0x37d/0x9f8 [] lock_acquire+0x56/0x6f [] _read_lock_bh+0x30/0x3d [] selinux_socket_sock_rcv_skb+0xbd/0x252 [] tcp_v4_rcv+0x37a/0x909 [] ip_local_deliver+0x185/0x22e [] ip_rcv+0x418/0x450 [] netif_receive_skb+0x2db/0x35a [] process_backlog+0x95/0xf6 [] net_rx_action+0xa1/0x1a8 [] __do_softirq+0x6f/0xe2 [] do_softirq+0x61/0xc7 [] 0xffffffff hardirq-on-R at: [] __lock_acquire+0x3ab/0x9f8 [] lock_acquire+0x56/0x6f [] _read_lock_bh+0x30/0x3d [] selinux_socket_sock_rcv_skb+0xbd/0x252 [] tcp_v4_rcv+0x37a/0x909 [] ip_local_deliver+0x185/0x22e [] ip_rcv+0x418/0x450 [] netif_receive_skb+0x2db/0x35a [] process_backlog+0x95/0xf6 [] net_rx_action+0xa1/0x1a8 [] __do_softirq+0x6f/0xe2 [] do_softirq+0x61/0xc7 [] 0xffffffff } ... key at: [] af_callback_keys+0x10/0x100 the soft-irq-unsafe lock's dependencies: -> (&ssec->nlbl_lock){--..} ops: 0 { initial-use at: [] __lock_acquire+0x424/0x9f8 [] lock_acquire+0x56/0x6f [] _spin_lock+0x2b/0x38 [] selinux_netlbl_socket_setsid+0xbb/0x123 [] selinux_netlbl_socket_post_create+0x2d/0x2f [] selinux_socket_post_create+0x156/0x15c [] __sock_create+0x179/0x1b2 [] sock_create+0x1a/0x1f [] sys_socket+0x1b/0x3c [] sys_socketcall+0x77/0x241 [] syscall_call+0x7/0xb [] 0xffffffff softirq-on-W at: [] __lock_acquire+0x409/0x9f8 [] lock_acquire+0x56/0x6f [] _spin_lock+0x2b/0x38 [] selinux_netlbl_socket_setsid+0xbb/0x123 [] selinux_netlbl_socket_post_create+0x2d/0x2f [] selinux_socket_post_create+0x156/0x15c [] __sock_create+0x179/0x1b2 [] sock_create+0x1a/0x1f [] sys_socket+0x1b/0x3c [] sys_socketcall+0x77/0x241 [] syscall_call+0x7/0xb [] 0xffffffff hardirq-on-W at: [] __lock_acquire+0x3e2/0x9f8 [] lock_acquire+0x56/0x6f [] _spin_lock+0x2b/0x38 [] selinux_netlbl_socket_setsid+0xbb/0x123 [] selinux_netlbl_socket_post_create+0x2d/0x2f [] selinux_socket_post_create+0x156/0x15c [] __sock_create+0x179/0x1b2 [] sock_create+0x1a/0x1f [] sys_socket+0x1b/0x3c [] sys_socketcall+0x77/0x241 [] syscall_call+0x7/0xb [] 0xffffffff } ... key at: [] __key.27522+0x0/0x8 stack backtrace: [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x16/0x18 [] check_usage+0x242/0x24c [] __lock_acquire+0x87f/0x9f8 [] lock_acquire+0x56/0x6f [] _spin_lock+0x2b/0x38 [] selinux_netlbl_socket_setsid+0xbb/0x123 [] selinux_netlbl_sock_graft+0xc7/0xcf [] selinux_sock_graft+0x32/0x36 [] inet_accept+0x8f/0xb5 [] sys_accept+0xd0/0x180 [] sys_socketcall+0xd0/0x241 [] syscall_call+0x7/0xb From pbrobinson at gmail.com Fri Dec 29 17:03:07 2006 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 29 Dec 2006 17:03:07 +0000 Subject: 2.6.19-1.2891.fc7 -- INFO: soft-safe -> soft-unsafe lock order detected In-Reply-To: References: Message-ID: <5256d0b0612290903w16d69f62u3da4740c2e1739b5@mail.gmail.com> Some more info would be nice, but generally it should be bugzillaed against the kernel. There's already a number of lockdep bugs there so make sure its not already noted https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora+Core&version=devel&component=kernel&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=MODIFIED&short_desc_type=allwordssubstr&short_desc=lockdep&long_desc_type=allwordssubstr&long_desc= Peter On 12/29/06, Miles Lane wrote: > Since I have received no reply on the development testers list, I'll try here. > > ---------- Forwarded message ---------- > From: Miles Lane > Date: Dec 29, 2006 1:17 AM > Subject: 2.6.19-1.2891.fc7 -- INFO: soft-safe -> soft-unsafe lock order detected > To: For testers of Fedora Core development releases > > > > [ INFO: soft-safe -> soft-unsafe lock order detected ] > 2.6.19-1.2891.fc7 #1 > ------------------------------------------------------ > cupsd/1884 [HC0[0]:SC0[1]:HE1:SE0] is trying to acquire: > (&ssec->nlbl_lock){--..}, at: [] > selinux_netlbl_socket_setsid+0xbb/0x123 > > and this task is already holding: > (af_callback_keys + sk->sk_family#3){-.-+}, at: [] > inet_accept+0x70/0xb5 > which would create a new lock dependency: > (af_callback_keys + sk->sk_family#3){-.-+} -> (&ssec->nlbl_lock){--..} > > but this new dependency connects a soft-irq-safe lock: > (af_callback_keys + sk->sk_family#3){-.-+} > ... which became soft-irq-safe at: > [] __lock_acquire+0x37d/0x9f8 > [] lock_acquire+0x56/0x6f > [] _read_lock_bh+0x30/0x3d > [] selinux_socket_sock_rcv_skb+0xbd/0x252 > [] tcp_v4_rcv+0x37a/0x909 > [] ip_local_deliver+0x185/0x22e > [] ip_rcv+0x418/0x450 > [] netif_receive_skb+0x2db/0x35a > [] process_backlog+0x95/0xf6 > [] net_rx_action+0xa1/0x1a8 > [] __do_softirq+0x6f/0xe2 > [] do_softirq+0x61/0xc7 > [] 0xffffffff > > to a soft-irq-unsafe lock: > (&ssec->nlbl_lock){--..} > ... which became soft-irq-unsafe at: > ... [] __lock_acquire+0x409/0x9f8 > [] lock_acquire+0x56/0x6f > [] _spin_lock+0x2b/0x38 > [] selinux_netlbl_socket_setsid+0xbb/0x123 > [] selinux_netlbl_socket_post_create+0x2d/0x2f > [] selinux_socket_post_create+0x156/0x15c > [] __sock_create+0x179/0x1b2 > [] sock_create+0x1a/0x1f > [] sys_socket+0x1b/0x3c > [] sys_socketcall+0x77/0x241 > [] syscall_call+0x7/0xb > [] 0xffffffff > > other info that might help us debug this: > > 3 locks held by cupsd/1884: > #0: (sk_lock-AF_INET){--..}, at: [] inet_accept+0x31/0xb5 > #1: (af_callback_keys + sk->sk_family#3){-.-+}, at: [] > inet_accept+0x70/0xb5 > #2: (policy_rwlock){..-?}, at: [] > selinux_netlbl_socket_setsid+0x54/0x123 > > the soft-irq-safe lock's dependencies: > -> (af_callback_keys + sk->sk_family#3){-.-+} ops: 0 { > initial-use at: > [] __lock_acquire+0x424/0x9f8 > [] lock_acquire+0x56/0x6f > [] _write_lock_bh+0x30/0x3d > [] tcp_close+0x24b/0x52b > [] inet_release+0x43/0x49 > [] sock_release+0x17/0x68 > [] sock_close+0x2d/0x33 > [] __fput+0xbe/0x168 > [] fput+0x17/0x19 > [] filp_close+0x54/0x5c > [] sys_close+0x78/0xb0 > [] syscall_call+0x7/0xb > [] 0xffffffff > hardirq-on-W at: > [] __lock_acquire+0x3e2/0x9f8 > [] lock_acquire+0x56/0x6f > [] _write_lock_bh+0x30/0x3d > [] tcp_close+0x24b/0x52b > [] inet_release+0x43/0x49 > [] sock_release+0x17/0x68 > [] sock_close+0x2d/0x33 > [] __fput+0xbe/0x168 > [] fput+0x17/0x19 > [] filp_close+0x54/0x5c > [] sys_close+0x78/0xb0 > [] syscall_call+0x7/0xb > [] 0xffffffff > in-softirq-R at: > [] __lock_acquire+0x37d/0x9f8 > [] lock_acquire+0x56/0x6f > [] _read_lock_bh+0x30/0x3d > [] selinux_socket_sock_rcv_skb+0xbd/0x252 > [] tcp_v4_rcv+0x37a/0x909 > [] ip_local_deliver+0x185/0x22e > [] ip_rcv+0x418/0x450 > [] netif_receive_skb+0x2db/0x35a > [] process_backlog+0x95/0xf6 > [] net_rx_action+0xa1/0x1a8 > [] __do_softirq+0x6f/0xe2 > [] do_softirq+0x61/0xc7 > [] 0xffffffff > hardirq-on-R at: > [] __lock_acquire+0x3ab/0x9f8 > [] lock_acquire+0x56/0x6f > [] _read_lock_bh+0x30/0x3d > [] selinux_socket_sock_rcv_skb+0xbd/0x252 > [] tcp_v4_rcv+0x37a/0x909 > [] ip_local_deliver+0x185/0x22e > [] ip_rcv+0x418/0x450 > [] netif_receive_skb+0x2db/0x35a > [] process_backlog+0x95/0xf6 > [] net_rx_action+0xa1/0x1a8 > [] __do_softirq+0x6f/0xe2 > [] do_softirq+0x61/0xc7 > [] 0xffffffff > } > ... key at: [] af_callback_keys+0x10/0x100 > > the soft-irq-unsafe lock's dependencies: > -> (&ssec->nlbl_lock){--..} ops: 0 { > initial-use at: > [] __lock_acquire+0x424/0x9f8 > [] lock_acquire+0x56/0x6f > [] _spin_lock+0x2b/0x38 > [] selinux_netlbl_socket_setsid+0xbb/0x123 > [] selinux_netlbl_socket_post_create+0x2d/0x2f > [] selinux_socket_post_create+0x156/0x15c > [] __sock_create+0x179/0x1b2 > [] sock_create+0x1a/0x1f > [] sys_socket+0x1b/0x3c > [] sys_socketcall+0x77/0x241 > [] syscall_call+0x7/0xb > [] 0xffffffff > softirq-on-W at: > [] __lock_acquire+0x409/0x9f8 > [] lock_acquire+0x56/0x6f > [] _spin_lock+0x2b/0x38 > [] selinux_netlbl_socket_setsid+0xbb/0x123 > [] selinux_netlbl_socket_post_create+0x2d/0x2f > [] selinux_socket_post_create+0x156/0x15c > [] __sock_create+0x179/0x1b2 > [] sock_create+0x1a/0x1f > [] sys_socket+0x1b/0x3c > [] sys_socketcall+0x77/0x241 > [] syscall_call+0x7/0xb > [] 0xffffffff > hardirq-on-W at: > [] __lock_acquire+0x3e2/0x9f8 > [] lock_acquire+0x56/0x6f > [] _spin_lock+0x2b/0x38 > [] selinux_netlbl_socket_setsid+0xbb/0x123 > [] selinux_netlbl_socket_post_create+0x2d/0x2f > [] selinux_socket_post_create+0x156/0x15c > [] __sock_create+0x179/0x1b2 > [] sock_create+0x1a/0x1f > [] sys_socket+0x1b/0x3c > [] sys_socketcall+0x77/0x241 > [] syscall_call+0x7/0xb > [] 0xffffffff > } > ... key at: [] __key.27522+0x0/0x8 > > stack backtrace: > [] show_trace_log_lvl+0x1a/0x2f > [] show_trace+0x12/0x14 > [] dump_stack+0x16/0x18 > [] check_usage+0x242/0x24c > [] __lock_acquire+0x87f/0x9f8 > [] lock_acquire+0x56/0x6f > [] _spin_lock+0x2b/0x38 > [] selinux_netlbl_socket_setsid+0xbb/0x123 > [] selinux_netlbl_sock_graft+0xc7/0xcf > [] selinux_sock_graft+0x32/0x36 > [] inet_accept+0x8f/0xb5 > [] sys_accept+0xd0/0x180 > [] sys_socketcall+0xd0/0x241 > [] syscall_call+0x7/0xb > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From david at lovesunix.net Fri Dec 29 17:12:46 2006 From: david at lovesunix.net (David Nielsen) Date: Fri, 29 Dec 2006 18:12:46 +0100 Subject: Fwd: 2.6.19-1.2891.fc7 -- INFO: soft-safe -> soft-unsafe lock order detected In-Reply-To: References: Message-ID: <1167412366.3115.15.camel@dawkins> fre, 29 12 2006 kl. 08:18 -0800, skrev Miles Lane: > Since I have received no reply on the development testers list, I'll try here. > > ---------- Forwarded message ---------- > From: Miles Lane > Date: Dec 29, 2006 1:17 AM > Subject: 2.6.19-1.2891.fc7 -- INFO: soft-safe -> soft-unsafe lock order detected > To: For testers of Fedora Core development releases > > I hate to tell you but if it's not in bugzilla it doesn't exist so could you please file a bug? - David -- "Ridicule s the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From sdl.web at gmail.com Fri Dec 29 17:22:54 2006 From: sdl.web at gmail.com (Leo) Date: Fri, 29 Dec 2006 17:22:54 +0000 Subject: Don't make Evolution the default mailer (was: Move Evolution to Extras?) References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318220.6805.15.camel@gilboa-work-dev.localdomain> <1167377762.8348.5.camel@gilboa-home-dev.localdomain> Message-ID: Since Core and Extras are to be merged. I have changed the subject. * Gilboa Davara (2006-12-29 09:36 +0200) said: ^^^^^^^^^^^^^ > The OP made a bold statement about *Fedora* users. I would have been > nice if he took the time to back it up with solid numbers. What kind of number do you need? Evolution may be useful for users need to sync with PDA or connect to an EXCHANGE server. But that is a very small portion. Being bloated, slow and memory hog, evolution is useless. There are other MUAs doing a better job in almost all things. > BTW, once Thunderbird / Lightning get OpenSync/Pilot support, I'll > be the first one to dump Evo. Until such time (and as long as KMail > remains a usability nightmare [and this from an avid KDE user...]), > leave Evolution be. So there is no point making it a default mailer. -- Leo (GPG Key: 9283AA3F) From knightmerc at yahoo.com Fri Dec 29 17:41:37 2006 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Fri, 29 Dec 2006 12:41:37 -0500 Subject: Please make Evolution the default mailer (was: Move Evolution to Extras?) In-Reply-To: References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318220.6805.15.camel@gilboa-work-dev.localdomain> <1167377762.8348.5.camel@gilboa-home-dev.localdomain> Message-ID: <1167414097.2429.245.camel@localhost.localdomain> On Fri, 2006-12-29 at 17:22 +0000, Leo wrote: > Since Core and Extras are to be merged. I have changed the subject. > > * Gilboa Davara (2006-12-29 09:36 +0200) said: > ^^^^^^^^^^^^^ > > The OP made a bold statement about *Fedora* users. I would have been > > nice if he took the time to back it up with solid numbers. > > What kind of number do you need? > > Evolution may be useful for users need to sync with PDA or connect to > an EXCHANGE server. But that is a very small portion. Being bloated, > slow and memory hog, evolution is useless. There are other MUAs doing > a better job in almost all things. > > > BTW, once Thunderbird / Lightning get OpenSync/Pilot support, I'll > > be the first one to dump Evo. Until such time (and as long as KMail > > remains a usability nightmare [and this from an avid KDE user...]), > > leave Evolution be. > > So there is no point making it a default mailer. > > -- > Leo (GPG Key: 9283AA3F) > You are flat wrong. I use it in two environments and it works. I know others that get good use out of Evo, even with the Evo demonizers hard at work on this list. BTW the man asked you for proof and you provided none. If you value your user base, you don't pull a valuable plug like Evo out of the chain. It's stupid. That would be like Micro$haft nixing Outlook, which would not make sense to them cause they have a userbase on it. Just as stupid to do it here cause, like there, it would alienate a solid user base. (That might be what you want, since that is what you are suggesting.) Not that some developers are overly worried about that. But there are a few of us that actually are worried about Fedora within the context of Ubuntu and generally more successful distributions. The concerns continue to be valid as long as some developers continue on a socialist bend. --LX From knightmerc at yahoo.com Fri Dec 29 17:50:55 2006 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Fri, 29 Dec 2006 12:50:55 -0500 Subject: Move Evolution to Extras? In-Reply-To: <1167317293.4579.23.camel@lt21223.campus.dmacc.edu> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167317293.4579.23.camel@lt21223.campus.dmacc.edu> Message-ID: <1167414655.2429.252.camel@localhost.localdomain> On Thu, 2006-12-28 at 08:48 -0600, Jeffrey C. Ollie wrote: > On Thu, 2006-12-28 at 13:48 +0000, Leo wrote: > > > > Evolution is useless for most users now. > > I think that you over-generalize. I find it quite useful. I'm sure > that there are many other people that find it useful. Sure it has a few > warts, but name me a piece of software that doesn't. > > > Not much has changed in the past few years. > > I disagree. > > > I used to keep it around but since I upgrade to Fedora 6, I have removed it completely. > > That's the beauty of open source, if you don't like it, use something > else. > > Jeff Right now Evo has no competition for the functions that it offers. The problem with the open source world (and the free world in general) is that it's possible for a few narcissistic trolls to ruin functionality for the user population at large. Sometimes it's by stupidity, sometimes it's by design. There is a sizable group out there that doesn't want an Outlook competitor in the Linux world, cause it eats too much M$ lunch. --LX From knightmerc at yahoo.com Fri Dec 29 17:55:30 2006 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Fri, 29 Dec 2006 12:55:30 -0500 Subject: Move Evolution to Extras? In-Reply-To: <1167318592.17863.10.camel@sioux.systems.cs.cornell.edu> References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318592.17863.10.camel@sioux.systems.cs.cornell.edu> Message-ID: <1167414930.2429.255.camel@localhost.localdomain> On Thu, 2006-12-28 at 10:09 -0500, Saikat Guha wrote: > On Thu, 2006-12-28 at 13:48 +0000, Leo wrote: > > Evolution is useless for most users now. > > Do you have data to support your claim? > > On Fedora-devel, Evolution is responsible for 78% of the emails. And that, my friend, is *exactly* why someone would NOT want Evo around in the Linux world. Think on this while you watch your back. --LX From knightmerc at yahoo.com Fri Dec 29 18:07:46 2006 From: knightmerc at yahoo.com (Lyvim Xaphir) Date: Fri, 29 Dec 2006 13:07:46 -0500 Subject: Move Evolution to Extras? In-Reply-To: <20061228152826.GC3714@free.fr> References: <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318592.17863.10.camel@sioux.systems.cs.cornell.edu> <20061228152826.GC3714@free.fr> Message-ID: <1167415666.2429.259.camel@localhost.localdomain> On Thu, 2006-12-28 at 16:28 +0100, Patrice Dumas wrote: > On Thu, Dec 28, 2006 at 10:09:52AM -0500, Saikat Guha wrote: > > On Thu, 2006-12-28 at 13:48 +0000, Leo wrote: > > > Evolution is useless for most users now. > > > > On Fedora-devel, Evolution is responsible for 78% of the emails. > > The next closest is Sylpheed with 9% > > Not all mailer use X-Mailer. Others use User-Agent. With the following: > grep -h '^\(User-Agent\|X-Mailer\)' fedora-devel-list -r | awk '{print $2}' | sed 's;/.*;;' | sort | uniq -c | sort -n > > > I get (for the mail saved in my fedora-devel-list mailbox, which may be biased): > > 1 AT&T > 1 Mulberry > 1 Null > 1 SnapperMail > 1 Wanderlust > 2 Apple > 2 http: > 2 %p!0,0! > 2 Pan > 4 Loom > 5 Balsa > 5 Internet > 7 VM > 8 MH-E > 10 Mail > 16 KNode > 16 Mew > 20 SquirrelMail > 23 Sylpheed-Claws > 32 Gnus > 43 Sylpheed > 49 KMail > 91 Ximian > 134 Mozilla > 148 Thunderbird > 295 Mutt > 330 Evolution > > There still seems to be about 200 mails not counted. > Evolution is still first, but with a lower share. Maybe Ximian is also evolution, > though. This is not very relevant, though, since mutt is second, this is > certainly biased numbers. Yes, since we are probably not considering a majority of users that used Evo to get integrated into M$ networks, thus encroaching into M$ territory. Even taking your statements above into consideration, I did a check on the kernel mailing list; Evo was number two right behind Mutt. --LX From sdl.web at gmail.com Fri Dec 29 18:30:45 2006 From: sdl.web at gmail.com (Leo) Date: Fri, 29 Dec 2006 18:30:45 +0000 Subject: Please make Evolution the default mailer References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318220.6805.15.camel@gilboa-work-dev.localdomain> <1167377762.8348.5.camel@gilboa-home-dev.localdomain> <1167414097.2429.245.camel@localhost.localdomain> Message-ID: * Lyvim Xaphir (2006-12-29 12:41 -0500) said: ^^^^^^^^^^^^ > On Fri, 2006-12-29 at 17:22 +0000, Leo wrote: >> Since Core and Extras are to be merged. I have changed the subject. >> >> * Gilboa Davara (2006-12-29 09:36 +0200) said: > >> ^^^^^^^^^^^^^ >> > The OP made a bold statement about *Fedora* users. I would have been >> > nice if he took the time to back it up with solid numbers. >> >> What kind of number do you need? >> >> Evolution may be useful for users need to sync with PDA or connect to >> an EXCHANGE server. But that is a very small portion. Being bloated, >> slow and memory hog, evolution is useless. There are other MUAs doing >> a better job in almost all things. >> >> > BTW, once Thunderbird / Lightning get OpenSync/Pilot support, I'll >> > be the first one to dump Evo. Until such time (and as long as KMail >> > remains a usability nightmare [and this from an avid KDE user...]), >> > leave Evolution be. >> >> So there is no point making it a default mailer. >> >> -- >> Leo (GPG Key: 9283AA3F) >> > > You are flat wrong. I use it in two environments and it works. I know > others that get good use out of Evo, even with the Evo demonizers hard > at work on this list. Can't that be achieved using other mailer? > BTW the man asked you for proof and you provided none. Have you not read What Saikat Guha wrote in ? Gmane has a very comprehensive stats. It's a bit dated. I will ask the team to update that page if possible. See: http://gmane.org/user-agents.php > If you value your user base, you don't pull a valuable plug like Evo > out of the chain. It's stupid. That would be like Micro$haft > nixing Outlook, which would not make sense to them cause they have a > userbase on it. Just as stupid to do it here cause, like there, it > would alienate a solid user base. Your argument would be convincing if we are talking about removing Evolution from the distro. > (That might be what you want, since that is what you are > suggesting.) No. There being equally popular mailer indicates a sensible solution not making Evolution the default mailer. > Not that some developers are overly worried about that. But there > are a few of us that actually are worried about Fedora within the > context of Ubuntu and generally more successful distributions. The > concerns continue to be valid as long as some developers continue on > a socialist bend. That lies in making a reasonably popular collection of apps that work out of box. -- Leo (GPG Key: 9283AA3F) From david at lovesunix.net Fri Dec 29 20:05:54 2006 From: david at lovesunix.net (David Nielsen) Date: Fri, 29 Dec 2006 21:05:54 +0100 Subject: The cdrecord debate Message-ID: <1167422754.3244.5.camel@dawkins> Shortly before FC6 was released we backed down to an older version of cdrecord because of conflicts between the GPL and the CDDL licenses. Debian also at that point forked cdrecord into cdrkit and other alternatives like libburn exist as well. There seemed at that point to be a concensus that we should stick to cdrecord for FC6 and talk about replacing it for FC7 since we were already far long into the FC6 cycle. Don't change horses in the middle of a stream and all that. So what is the plan here are we going to stick with an old version of cdrecord or will we be looking for alternatives? - David Nielsen -- "Ridicule s the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From seg at haxxed.com Fri Dec 29 20:38:28 2006 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 29 Dec 2006 14:38:28 -0600 Subject: Please make Evolution the default mailer In-Reply-To: References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318220.6805.15.camel@gilboa-work-dev.localdomain> <1167377762.8348.5.camel@gilboa-home-dev.localdomain> <1167414097.2429.245.camel@localhost.localdomain> Message-ID: <1167424709.3762.24.camel@max.booze> On Fri, 2006-12-29 at 18:30 +0000, Leo wrote: > Gmane has a very comprehensive stats. It's a bit dated. I will ask the > team to update that page if possible. See: > http://gmane.org/user-agents.php Oh for christ sakes can we stop with the numbers and statistics crap? None of it means a goddamn thing. http://video.google.com/videoplay?docid=8741712104711499419 Scream about how awful Evolution is all you want, no one's going to care unless you can offer an acceptable alternative. -------------- 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 saikat at cs.cornell.edu Fri Dec 29 20:50:45 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Fri, 29 Dec 2006 15:50:45 -0500 Subject: Please make Evolution the default mailer In-Reply-To: References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318220.6805.15.camel@gilboa-work-dev.localdomain> <1167377762.8348.5.camel@gilboa-home-dev.localdomain> <1167414097.2429.245.camel@localhost.localdomain> Message-ID: <1167425445.13150.5.camel@sioux.systems.cs.cornell.edu> On Fri, 2006-12-29 at 18:30 +0000, Leo wrote: > * Lyvim Xaphir (2006-12-29 12:41 -0500) said: > > BTW the man asked you for proof and you provided none. > > Have you not read What Saikat Guha wrote in > ? I think you misread my response. I was pointing out that Evolution is #1 on the fedora-devel list where one would expect to find people who can make an informed decision on which mailer to use. As such you original claim that "Evolution is useless for most users" is completely baseless, sensationalist and imho, wrong. -- Saikat -------------- 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 sdl.web at gmail.com Fri Dec 29 21:40:05 2006 From: sdl.web at gmail.com (Leo) Date: Fri, 29 Dec 2006 21:40:05 +0000 Subject: Please make Evolution the default mailer References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318220.6805.15.camel@gilboa-work-dev.localdomain> <1167377762.8348.5.camel@gilboa-home-dev.localdomain> <1167414097.2429.245.camel@localhost.localdomain> <1167425445.13150.5.camel@sioux.systems.cs.cornell.edu> Message-ID: * Saikat Guha (2006-12-29 15:50 -0500) said: ^^^^^^^^^^^ [...] >> Have you not read What Saikat Guha wrote in >> ? > > I think you misread my response. > > I was pointing out that Evolution is #1 on the fedora-devel list > where one would expect to find people who can make an informed > decision on which mailer to use. Regarding the fact that Evolution has been in Redhat/Fedora since RH7 or maybe earlier and Thunderbird 1.0 was released at the end of 2004, that #1 does explain something in favor of my claim. *NB* I use neither Evolution nor Thunderbird. > As such you original claim that "Evolution is useless for most > users" is completely baseless, sensationalist and imho, wrong. ...... -- Leo (GPG Key: 9283AA3F) From linux_4ever at yahoo.com Fri Dec 29 22:58:22 2006 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 29 Dec 2006 14:58:22 -0800 (PST) Subject: Fwd: 2.6.19-1.2891.fc7 -- INFO: soft-safe -> soft-unsafe lock order detected In-Reply-To: Message-ID: <20061229225822.61483.qmail@web51510.mail.yahoo.com> >Since I have received no reply on the development testers list, I'll try here. This looks like the netlabel code in the recent kernels. This needs to be bugzilla'd but I'd like to know the bug number after you file it. I can get the right people looking at it. Thanks, -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From gilboad at gmail.com Sat Dec 30 00:07:37 2006 From: gilboad at gmail.com (Gilboa Davara) Date: Sat, 30 Dec 2006 02:07:37 +0200 Subject: Don't make Evolution the default mailer (was: Move Evolution to Extras?) In-Reply-To: References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318220.6805.15.camel@gilboa-work-dev.localdomain> <1167377762.8348.5.camel@gilboa-home-dev.localdomain> Message-ID: <1167437257.6957.10.camel@gilboa-home-dev.localdomain> On Fri, 2006-12-29 at 17:22 +0000, Leo wrote: > Since Core and Extras are to be merged. I have changed the subject. > > * Gilboa Davara (2006-12-29 09:36 +0200) said: > ^^^^^^^^^^^^^ > > The OP made a bold statement about *Fedora* users. I would have been > > nice if he took the time to back it up with solid numbers. > > What kind of number do you need? The only number that means jack sh*t is Fedora head count. I don't care about Windows users - no do I care about Slackware users (that dropped GNOME long ago). I can about Fedora users. As such, the mailing list numbers seem to contradict your initial claim ("Evolution is useless for most users now. ") because as it stands, most of people reading your post, are doing it using Evolution. > > Evolution may be useful for users need to sync with PDA or connect to > an EXCHANGE server. But that is a very small portion. Small portion? Again. BACK_THIS_UP_WITH_NUMBERS. > Being bloated, slow and memory hog, evolution is useless. There are other MUAs doing > a better job in almost all things. For me evolution works. Not great, but works. If it doesn't work for you... it is your choice to remove it. Don't take away my -right- to use Evolution, just because you're too lazy to exercises yours. (To remove it) > > > BTW, once Thunderbird / Lightning get OpenSync/Pilot support, I'll > > be the first one to dump Evo. Until such time (and as long as KMail > > remains a usability nightmare [and this from an avid KDE user...]), > > leave Evolution be. > > So there is no point making it a default mailer. > If Fedora users were the mind-less-drones that you consider them to be, they would be using Windows. instead of Linux "Because it there by default" The mere number of non-Evolution users combined with the mere number of KMAIL and/or KDE users on this list makes your post look over simplified and narrow-minded. - Gilboa From miles.lane at gmail.com Sat Dec 30 02:38:27 2006 From: miles.lane at gmail.com (Miles Lane) Date: Fri, 29 Dec 2006 18:38:27 -0800 Subject: Fwd: 2.6.19-1.2891.fc7 -- INFO: soft-safe -> soft-unsafe lock order detected In-Reply-To: <20061229225822.61483.qmail@web51510.mail.yahoo.com> References: <20061229225822.61483.qmail@web51510.mail.yahoo.com> Message-ID: Here you go: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220966 Thanks, Miles On 12/29/06, Steve G wrote: > > >Since I have received no reply on the development testers list, I'll try here. > > This looks like the netlabel code in the recent kernels. This needs to be > bugzilla'd but I'd like to know the bug number after you file it. I can get the > right people looking at it. > > Thanks, > -Steve From rc040203 at freenet.de Sat Dec 30 05:05:45 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 30 Dec 2006 06:05:45 +0100 Subject: ESR "fedora-submit" In-Reply-To: <1167005888.6039.9.camel@localhost.localdomain> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <1167005888.6039.9.camel@localhost.localdomain> Message-ID: <1167455145.14972.34.camel@mccallum.corsepiu.local> On Sun, 2006-12-24 at 19:18 -0500, Michael Tiemann wrote: > On Sun, 2006-12-24 at 19:09 -0500, Konstantin Ryabitsev wrote: > > On 12/24/06, Eric S. Raymond wrote: > > > The question remains. Do I have to *do shit by hand* > > > > Why not, you're doing an admirable job so far. > > Konstantin--how many packages do you maintain? I think that rather than > sniping at a would-be contributor, I'd like to see somebody who is > maintaining at least 30, and perhaps 50 packages explain how *they* I am one of those ;) > do it. By hand - It's largely trivial and __way__ less effort than some people seem to expect. > Maybe they have a better way. Maybe it drives them almost as crazy > Eric. How *does* a maintainer of 36 packages would with the Fedora > process? How *should* one do it? This is the question and the problem > to be solved. IMO, this is largely a non-issue. The real issues with maintaining 50+ packages in Fedora are elsewhere. Some examples: * Lack of automated rebuilds (manual mass rebuilds are a PITA). * Lack of automated "distro-consistency checks" (E.g. broken EVRs could fairly easily be avoided - Check a package before releasing it). * Lack of control over the release process (Currently, packages are automatically being pushed - No chance for a maintainer to withdraw a broken/mis-compiled built). I would expect maintainers to give "explicit clearance" before a package is being released. ... But ... all these issues are comparatively minor. The real road-blocks rendering Fedora non-attractive are of non-technical nature. Ralf From fedora at wir-sind-cool.org Sat Dec 30 09:56:16 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sat, 30 Dec 2006 10:56:16 +0100 Subject: ESR "fedora-submit" In-Reply-To: <1167455145.14972.34.camel@mccallum.corsepiu.local> References: <458ED888.6050608@redhat.com> <20061224202900.GA17840@thyrsus.com> <458F0345.5010902@redhat.com> <20061224235740.GA19176@thyrsus.com> <1167005888.6039.9.camel@localhost.localdomain> <1167455145.14972.34.camel@mccallum.corsepiu.local> Message-ID: <20061230105616.8012e14d.fedora@wir-sind-cool.org> On Sat, 30 Dec 2006 06:05:45 +0100, Ralf Corsepius wrote: > Some examples: > * Lack of control over the release process (Currently, packages are > automatically being pushed - No chance for a maintainer to withdraw a > broken/mis-compiled built). Except when you mail the Extras signers before the next push, a broken build can be skipped easily. And of course, the %check section is very useful for custom sanity checks, too. > I would expect maintainers to give "explicit > clearance" before a package is being released. Which sounds more like the future web-based updates system. From rms at 1407.org Sat Dec 30 12:26:48 2006 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Sat, 30 Dec 2006 12:26:48 +0000 Subject: Don't make Evolution the default mailer (was: Move Evolution to Extras?) In-Reply-To: References: <1144155199.2808.94.camel@dimi> <20060404131520.19567.qmail@hm196.locaweb.com.br> <20060412114214.GA28564@devserv.devel.redhat.com> <1144847486.6382.144.camel@dimi> <1144848525.2294.274.camel@sundaram.pnq.redhat.com> <1167210602.2786.38.camel@localhost.localdomain> <1167210880.2786.41.camel@localhost.localdomain> <1167239384.6753.3.camel@home-desk> <1167243602.1287.44.camel@dawkins> <4580.207.245.37.34.1167245384.squirrel@lattica.com> <459321B3.6040600@andrei.myip.org> <1167318220.6805.15.camel@gilboa-work-dev.localdomain> <1167377762.8348.5.camel@gilboa-home-dev.localdomain> Message-ID: <1167481608.4881.170.camel@localhost> Sex, 2006-12-29 ?s 17:22 +0000, Leo escreveu: > Evolution may be useful for users need to sync with PDA or connect to > an EXCHANGE server. But that is a very small portion. Being bloated, > slow and memory hog, evolution is useless. There are other MUAs doing > a better job in almost all things. You obviously are fortunate enough not to have an important enough role in a Microsoft-enabled-lan company, medium size to big. In fact, it would appear as if your email needs are quite satisfied with gmail, which says a lot :) If you *only* do email, sure... Evolution is a massive hog. Heck, even the adorable mutt does a better job. However, as you have meetings, and need to properly reply to invitations, and such other things, even without connecting to the exchange server as I don't (I got to have email forwarded to a more sane server) you will need such kind of integrated features. I tried Kontact and it seemed yet worse at the time, and integrates badly on the "GNOME way" of the desktop. Right now I have a series of links in mutt's mail folder in order to access my emails from mutt for when an accident might happen (see how I *don't* trust Evolution even though I use it?)... If you are unfortunate to work on a Micrsoft-enabled-lan as I do, then you'd appreciate it more. 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...? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Esta ? uma parte de mensagem assinada digitalmente URL: From thomas.canniot at laposte.net Sat Dec 30 16:28:59 2006 From: thomas.canniot at laposte.net (Thomas Canniot) Date: Sat, 30 Dec 2006 17:28:59 +0100 Subject: The cdrecord debate In-Reply-To: <1167422754.3244.5.camel@dawkins> References: <1167422754.3244.5.camel@dawkins> Message-ID: <1167496139.2972.13.camel@localhost.localdomain> Le vendredi 29 d?cembre 2006 ? 21:05 +0100, David Nielsen a ?crit : > Shortly before FC6 was released we backed down to an older version of > cdrecord because of conflicts between the GPL and the CDDL licenses. > Debian also at that point forked cdrecord into cdrkit and other > alternatives like libburn exist as well. There seemed at that point to > be a concensus that we should stick to cdrecord for FC6 and talk about > replacing it for FC7 since we were already far long into the FC6 cycle. > Don't change horses in the middle of a stream and all that. > > So what is the plan here are we going to stick with an old version of > cdrecord or will we be looking for alternatives? > > - David Nielsen > It's been a long time cdrecord was broken into fedora. I think we should move to cdrkit of debian : it based on cdrecord and its licence stands as our. Moreover, I think we can trust Debian for the quality of software development. -- Thomas Canniot http://fedoraproject.org/wiki/ThomasCanniot From sundaram at fedoraproject.org Sat Dec 30 17:37:35 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 30 Dec 2006 23:07:35 +0530 Subject: The cdrecord debate In-Reply-To: <1167496139.2972.13.camel@localhost.localdomain> References: <1167422754.3244.5.camel@dawkins> <1167496139.2972.13.camel@localhost.localdomain> Message-ID: <4596A3DF.1060600@fedoraproject.org> Thomas Canniot wrote: > It's been a long time cdrecord was broken into fedora. I think we should > move to cdrkit of debian : it based on cdrecord and its licence stands > as our. Moreover, I think we can trust Debian for the quality of > software development. What do you mean by saying that cdrecord is broken in Fedora? Do you have bug reports? Rahul From david at lovesunix.net Sat Dec 30 18:51:48 2006 From: david at lovesunix.net (David Nielsen) Date: Sat, 30 Dec 2006 19:51:48 +0100 Subject: The cdrecord debate In-Reply-To: <4596A3DF.1060600@fedoraproject.org> References: <1167422754.3244.5.camel@dawkins> <1167496139.2972.13.camel@localhost.localdomain> <4596A3DF.1060600@fedoraproject.org> Message-ID: <1167504708.3138.14.camel@dawkins> l?r, 30 12 2006 kl. 23:07 +0530, skrev Rahul Sundaram: > Thomas Canniot wrote: > > > It's been a long time cdrecord was broken into fedora. I think we should > > move to cdrkit of debian : it based on cdrecord and its licence stands > > as our. Moreover, I think we can trust Debian for the quality of > > software development. > > What do you mean by saying that cdrecord is broken in Fedora? Do you > have bug reports? #220972 just being one case of breaking cdrecord... post release. - David Nielsen -- "Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.? -Thomas Jefferson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dette er en digitalt underskrevet brevdel URL: From jdogalt at yahoo.com Sat Dec 30 23:15:15 2006 From: jdogalt at yahoo.com (Jane Dogalt) Date: Sat, 30 Dec 2006 15:15:15 -0800 (PST) Subject: LCD via VGA port In-Reply-To: <68720af30612280138p4f3b315ayee96a07112f7ce1d@mail.gmail.com> Message-ID: <591474.52410.qm@web56901.mail.re3.yahoo.com> You seem lost, so I'll attempt to help though nothing I'm about to say obviously does... I just upgraded my main system from fc5 to fc6. I have an nvidia BFG something or other, with one vga and one dvi port. I was connected to two monitors, one big CRT via VGA and one small LCD via VGA. One of the VGAs via an adapter to the DVI port. So I clearly have an fc6 system, an nvidia card, and an LCD with only a VGA interface. Thus my reply. I'm actually in flux, and am giving away the CRT. I had been in fc5 with the nvidia drivers and using RandR for multihead, which I got to work after some pains. Now, I am just using the LCD-VGA, and haven't yet installed the nvidia driver (using nv). I did notice, that my CRT which is still connected displays text garbage. And I think I did have to manually add a monitor section to my xorg.conf. Anyway, if there is a specific question or experiment you would like me to try, let me know. Good luck... -dmc --- Paulo Cavalcanti wrote: > Hi, > > I have already posted this message at the user list and received no > answer. > If someone could say if he (or she) is using an LCD via a vga port, > it would be a beginning. > > ------------------------------------------------------------------------------------------------------------- > > I am having problems connecting an LCD to a nvidia card > using a VGA port in FC6. I only succeeded using > either a DVI port or a DVI-VGA adaptor. With a real CRT > everything works fine. > > I tried the VGA port approach in two different computers with two > different > graphics cards > (GeForce 4 and FX-5200), two different Samsung LCDs (510N and 710N), > and got > the same > result. With the nv driver, generally, the screen becomes black after > a > logout > and X does not return. The nvidia driver is even worse. If I manage > to > login, > the system hangs during a video intensive application, and opengl > does not > work. > > I have never had any problem using FC5, what makes me believe that > the problem stems from xorg 7.1 > > > Any suggestion will be really appreciated. > > Thanks, > > > > /Paulo Roma. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From alan at redhat.com Sat Dec 30 23:55:43 2006 From: alan at redhat.com (Alan Cox) Date: Sat, 30 Dec 2006 18:55:43 -0500 Subject: New device drivers don't see beyond 15 partitions in fc7 In-Reply-To: <458B8A25.6020409@hhs.nl> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458B8A25.6020409@hhs.nl> Message-ID: <20061230235543.GA2893@devserv.devel.redhat.com> On Fri, Dec 22, 2006 at 08:32:53AM +0100, Hans de Goede wrote: > upgrade to FC-7 flawlessly, if /dev/hdx accomodated more then 15 > partitions, then so should the new /dev/sdx when it becomes the new > device for this disk. Thats something you need to take upstream. I would also like to see it happen but previous patches to allow sparse minor numbers have always been vetoed by some of the fs maintainers. From promac at gmail.com Sun Dec 31 00:48:32 2006 From: promac at gmail.com (Paulo Cavalcanti) Date: Sat, 30 Dec 2006 22:48:32 -0200 Subject: LCD via VGA port Message-ID: <68720af30612301648t567fb55bm77af13d6bc36350a@mail.gmail.com> > I just upgraded my main system from fc5 to fc6. I have an nvidia BFG > something or other, with one vga and one dvi port. I was connected to > two monitors, one big CRT via VGA and one small LCD via VGA. One of > the VGAs via an adapter to the DVI port. > So I clearly have an fc6 system, an nvidia card, and an LCD with only a > VGA interface. Thus my reply. > I'm actually in flux, and am giving away the CRT. I had been in fc5 > with the nvidia drivers and using RandR for multihead, which I got to > work after some pains. Now, I am just using the LCD-VGA, and haven't > yet installed the nvidia driver (using nv). I did notice, that my CRT > which is still connected displays text garbage. And I think I did have > to manually add a monitor section to my xorg.conf. > Anyway, if there is a specific question or experiment you would like me > to try, let me know. could you try to connect your LCD using the VGA port without the adapter? This is what I am not being able to accomplish. It is like the modelines were wrong. Thank you for the reply. /Paulo Roma. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael.espindola at gmail.com Sun Dec 31 02:14:08 2006 From: rafael.espindola at gmail.com (=?UTF-8?Q?Rafael_Esp=C3=ADndola?=) Date: Sun, 31 Dec 2006 00:14:08 -0200 Subject: packet writing In-Reply-To: <564d96fb0612240646mfa9f5b9q5703b0a7c1c5ba6c@mail.gmail.com> References: <564d96fb0612240646mfa9f5b9q5703b0a7c1c5ba6c@mail.gmail.com> Message-ID: <564d96fb0612301814pa457a48rb944d3f7706f2ae8@mail.gmail.com> > It should be easy to port this script, but I think that we can do > better. I am planning to write an udev rule to run pktsetup every time > check-cdrom.sh detects a cd-rw or a dvd-rw. Do you think that it would > be a good thing to do? Loading the kernel module is easy, I just added a "RUN+=" line to /etc/udev/rules/50-udev.rules: --------------------------------------------------- KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="1", PROGRAM=="check-cdrom.sh %k CD-R", SYMLINK+="cdwriter cdwriter-%k cdrw cdrw-%k", RUN+="/sbin/modprobe pktcdvd" ..... -------------------------------------------------- I am a bit confused on how to run pktsetup. I think that the commands should be in a new file that can be included in udevtools, so I create a file named 52-pktsetup.rules: ---------------------------------------------- KERNEL=="hd[a-z]", BUS=="ide", SYSFS{removable}=="1", PROGRAM=="check-cdrom.sh %k CD-R", RUN+="/usr/bin/pktsetup %k %p" ---------------------------------------------- Apparently pktsetup is not being run. Replacing the command with a "/bin/sh -c 'echo hi > /root/test" doesn't create a test file.... Is there a log file I can check? Best Regards, Rafael From icon at fedoraproject.org Sun Dec 31 04:58:31 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Sat, 30 Dec 2006 23:58:31 -0500 Subject: [Offtopic] Rather amusing diagram on wikipedia Message-ID: There's an "organizational" diagram on wikipedia that seems a little fishy to me: http://en.wikipedia.org/wiki/Fedora_Project . I'm not up to speed on the finer details of Fedora Project organizational chart, but I believe that diagram is a little... random, especially seeing as apparently the ultimate goal of everything Fedora Project does is RHEL releases. :) Maybe someone from the project who is familiar with the orgranization cares enough to update the page? Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From sundaram at fedoraproject.org Sun Dec 31 04:59:56 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 31 Dec 2006 10:29:56 +0530 Subject: The cdrecord debate In-Reply-To: <1167504708.3138.14.camel@dawkins> References: <1167422754.3244.5.camel@dawkins> <1167496139.2972.13.camel@localhost.localdomain> <4596A3DF.1060600@fedoraproject.org> <1167504708.3138.14.camel@dawkins> Message-ID: <459743CC.9030800@fedoraproject.org> David Nielsen wrote: > l?r, 30 12 2006 kl. 23:07 +0530, skrev Rahul Sundaram: >> Thomas Canniot wrote: >> >>> It's been a long time cdrecord was broken into fedora. I think we should >>> move to cdrkit of debian : it based on cdrecord and its licence stands >>> as our. Moreover, I think we can trust Debian for the quality of >>> software development. >> What do you mean by saying that cdrecord is broken in Fedora? Do you >> have bug reports? > > #220972 just being one case of breaking cdrecord... post release. Anyone else seeing this problem? Rahul From lamont at gurulabs.com Sun Dec 31 05:34:00 2006 From: lamont at gurulabs.com (Lamont Peterson) Date: Sat, 30 Dec 2006 22:34:00 -0700 Subject: New device drivers don't see beyond 15 partitions in fc7 In-Reply-To: <20061230235543.GA2893@devserv.devel.redhat.com> References: <458B115B.7060606@cox.net> <458B8A25.6020409@hhs.nl> <20061230235543.GA2893@devserv.devel.redhat.com> Message-ID: <200612302234.01954.lamont@gurulabs.com> On Saturday 30 December 2006 04:55pm, Alan Cox wrote: > On Fri, Dec 22, 2006 at 08:32:53AM +0100, Hans de Goede wrote: > > upgrade to FC-7 flawlessly, if /dev/hdx accomodated more then 15 > > partitions, then so should the new /dev/sdx when it becomes the new > > device for this disk. > > Thats something you need to take upstream. I would also like to see it > happen but previous patches to allow sparse minor numbers have always been > vetoed by some of the fs maintainers. Since 2.6 and the 32-bit device ID space? -- Lamont Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Sun Dec 31 06:33:25 2006 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 31 Dec 2006 01:33:25 -0500 Subject: [Offtopic] Rather amusing diagram on wikipedia In-Reply-To: References: Message-ID: <200612310133.29550.jkeating@redhat.com> On Saturday 30 December 2006 23:58, Konstantin Ryabitsev wrote: > but I believe that diagram is a little... random, especially seeing as > apparently the ultimate goal of everything Fedora Project does is RHEL > releases. :) I guess this depends on your point of view. This might make a good RHEL diagram, given that RHEL does come from Fedora. It looks pretty right up until the RHEL part, because RHEL is a part of the RHEL project flow, not necessarily the Fedora project flow. The Fedora project really "ends" at the distribution releases. How those releases are used by various "downstream" distributions is up to those distributions. OLPC comes to mind. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From arjan at fenrus.demon.nl Sun Dec 31 09:12:22 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 31 Dec 2006 10:12:22 +0100 Subject: New device drivers don't see beyond 15 partitions in fc7 In-Reply-To: <20061230235543.GA2893@devserv.devel.redhat.com> References: <458B115B.7060606@cox.net> <1166770126.27377.1.camel@gilboa-home-dev.localdomain> <458B8A25.6020409@hhs.nl> <20061230235543.GA2893@devserv.devel.redhat.com> Message-ID: <1167556342.20929.642.camel@laptopd505.fenrus.org> On Sat, 2006-12-30 at 18:55 -0500, Alan Cox wrote: > On Fri, Dec 22, 2006 at 08:32:53AM +0100, Hans de Goede wrote: > > upgrade to FC-7 flawlessly, if /dev/hdx accomodated more then 15 > > partitions, then so should the new /dev/sdx when it becomes the new > > device for this disk. > > Thats something you need to take upstream. I would also like to see it happen > but previous patches to allow sparse minor numbers have always been vetoed by > some of the fs maintainers. when libata moves away from scsi this is easily solvable ;) > From wtogami at redhat.com Sun Dec 31 11:42:31 2006 From: wtogami at redhat.com (Warren Togami) Date: Sun, 31 Dec 2006 06:42:31 -0500 Subject: [Offtopic] Rather amusing diagram on wikipedia In-Reply-To: References: Message-ID: <4597A227.6030207@redhat.com> Konstantin Ryabitsev wrote: > There's an "organizational" diagram on wikipedia that seems a little > fishy to me: http://en.wikipedia.org/wiki/Fedora_Project . I'm not up > to speed on the finer details of Fedora Project organizational chart, > but I believe that diagram is a little... random, especially seeing as > apparently the ultimate goal of everything Fedora Project does is RHEL > releases. :) > > Maybe someone from the project who is familiar with the orgranization > cares enough to update the page? > > Cheers, My thoughts... 1) RHEL helps to drive inputs of resource priorities and technology directions. 2) RHEL however as an output is a fork of Fedora. 3) Third party repositories don't really belong on this chart, unless the chart is referring to arbitrary forks. Then there could be two different kinds of forks, distro forks (RHEL, Aurora, etc.) or add-on/replacement repo forks. In any case, it should be the Fedora Project itself making an official org chart instead of some unknown person posting this kind of thing. Warren Togami wtogami at redhat.com From alan at redhat.com Sun Dec 31 12:12:16 2006 From: alan at redhat.com (Alan Cox) Date: Sun, 31 Dec 2006 07:12:16 -0500 Subject: New device drivers don't see beyond 15 partitions in fc7 In-Reply-To: <200612302234.01954.lamont@gurulabs.com> References: <458B115B.7060606@cox.net> <458B8A25.6020409@hhs.nl> <20061230235543.GA2893@devserv.devel.redhat.com> <200612302234.01954.lamont@gurulabs.com> Message-ID: <20061231121216.GA10511@devserv.devel.redhat.com> On Sat, Dec 30, 2006 at 10:34:00PM -0700, Lamont Peterson wrote: > > happen but previous patches to allow sparse minor numbers have always been > > vetoed by some of the fs maintainers. > > Since 2.6 and the 32-bit device ID space? Yes From rafael.espindola at gmail.com Sun Dec 31 13:13:15 2006 From: rafael.espindola at gmail.com (=?UTF-8?Q?Rafael_Esp=C3=ADndola?=) Date: Sun, 31 Dec 2006 11:13:15 -0200 Subject: packet writing In-Reply-To: <564d96fb0612301814pa457a48rb944d3f7706f2ae8@mail.gmail.com> References: <564d96fb0612240646mfa9f5b9q5703b0a7c1c5ba6c@mail.gmail.com> <564d96fb0612301814pa457a48rb944d3f7706f2ae8@mail.gmail.com> Message-ID: <564d96fb0612310513k2e3e5909i2f300ba93649f0f5@mail.gmail.com> > I am a bit confused on how to run pktsetup. I think that the commands > should be in a new file that can be included in udevtools, so I create > a file named 52-pktsetup.rules: Fortunately, pktsetup loads the appropriate kernel module. There is no need to call modprobe and the attached file implements the proposed functionality. What is missing: make gnome and kde use /dev/pktcdvd/%d instead of /dev/%d to mount a nice frontend to "cdrwtool -d /dev/cdrw -q" :-) Best Regards, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: 52-pktsetup.rules Type: application/octet-stream Size: 460 bytes Desc: not available URL: From tbrinkman at sbcglobal.net Sun Dec 31 14:57:22 2006 From: tbrinkman at sbcglobal.net (Tom Brinkman) Date: Sun, 31 Dec 2006 08:57:22 -0600 Subject: The cdrecord debate In-Reply-To: <459743CC.9030800@fedoraproject.org> References: <1167422754.3244.5.camel@dawkins> <1167504708.3138.14.camel@dawkins> <459743CC.9030800@fedoraproject.org> Message-ID: <200612310857.22647.tbrinkman@sbcglobal.net> On Saturday 30 December 2006 10:59 pm, Rahul Sundaram wrote: > David Nielsen wrote: > > l?r, 30 12 2006 kl. 23:07 +0530, skrev Rahul Sundaram: > >> Thomas Canniot wrote: > >>> It's been a long time cdrecord was broken into fedora. I > >>> think we should move to cdrkit of debian : it based on > >>> cdrecord and its licence stands as our. Moreover, I think we > >>> can trust Debian for the quality of software development. > >> > >> What do you mean by saying that cdrecord is broken in Fedora? > >> Do you have bug reports? > > > > #220972 just being one case of breaking cdrecord... post > > release. > > Anyone else seeing this problem? > > Rahul No. For burning iso's as in the BZ I use, 'cdrecord -v -eject driveropts=burnfree speed=16 dev=ATA:1,1,0 -dao' (burner an media are 52x) Has the reporter tried this as root? Some hardware, particularly Plextor's can only burn as root. # cdrecord -checkdrive dev=ATA:1,1,0 scsidev: 'ATA:1,1,0' devname: 'ATA' scsibus: 1 target: 1 lun: 0 Linux sg driver version: 3.5.27 Using libscg version 'schily-0.8'. cdrecord: Warning: using inofficial libscg transport code version (schily - Red Hat-scsi-linux-sg.c-1.83-RH '@(#)scsi-linux-sg.c 1.83 04/05/20 Copyright 1997 J. Schilling'). Device type : Removable CD-ROM Version : 0 Response Format: 1 Vendor_info : 'PLEXTOR ' Identifikation : 'CD-R PREMIUM ' Revision : '1.05' -- Tom Brinkman Corpus Christi, Texas From jamatos at fc.up.pt Sun Dec 31 17:34:05 2006 From: jamatos at fc.up.pt (=?utf-8?q?Jos=C3=A9_Matos?=) Date: Sun, 31 Dec 2006 17:34:05 +0000 Subject: [Offtopic] Rather amusing diagram on wikipedia In-Reply-To: <4597A227.6030207@redhat.com> References: <4597A227.6030207@redhat.com> Message-ID: <200612311734.05425.jamatos@fc.up.pt> On Sunday 31 December 2006 11:42 am, Warren Togami wrote: > In any case, it should be the Fedora Project itself making an official > org chart instead of some unknown person posting this kind of thing. Do you realise that you are talking about wikipedia, right? ;-) > Warren Togami > wtogami at redhat.com -- Jos? Ab?lio From fedora at wir-sind-cool.org Sun Dec 31 18:59:53 2006 From: fedora at wir-sind-cool.org (Michael Schwendt) Date: Sun, 31 Dec 2006 19:59:53 +0100 Subject: [Offtopic] Rather amusing diagram on wikipedia In-Reply-To: <200612311734.05425.jamatos@fc.up.pt> References: <4597A227.6030207@redhat.com> <200612311734.05425.jamatos@fc.up.pt> Message-ID: <20061231195953.9b5546a6.fedora@wir-sind-cool.org> On Sun, 31 Dec 2006 17:34:05 +0000, Jos? Matos wrote: > On Sunday 31 December 2006 11:42 am, Warren Togami wrote: > > In any case, it should be the Fedora Project itself making an official > > org chart instead of some unknown person posting this kind of thing. > > Do you realise that you are talking about wikipedia, right? ;-) http://en.wikipedia.org/w/index.php?title=Fedora_Project&action=history | 06:43, 29 April 2006 Nicubunu (Talk | contribs) (replaced the diagram to | reflect the current structure. the new one is SVG.) He's a Fedora Arts contributor, unless this is a strange coincidence in choice of nicknames. From jpmahowald at gmail.com Sun Dec 31 23:12:13 2006 From: jpmahowald at gmail.com (John Mahowald) Date: Mon, 1 Jan 2007 17:12:13 +1800 Subject: [Offtopic] Rather amusing diagram on wikipedia In-Reply-To: <4597A227.6030207@redhat.com> References: <4597A227.6030207@redhat.com> Message-ID: <3ea997540612311512u784fc6f2ka2c7ff2334fa1dd6@mail.gmail.com> Be thankful my original attempt, user Jman, did not survive. This was my stab at getting some concept of how the Fedora project relates to things out to the masses. Supposedly a picture is worth a thousand words. I agree that, if the Fedora project wants to be the authority on such a chart, it should come from the project. John On 1/1/07, Warren Togami wrote: > > In any case, it should be the Fedora Project itself making an official > org chart instead of some unknown person posting this kind of thing. > > Warren Togami > wtogami at redhat.com > From mike at miketc.com Sun Dec 31 23:50:22 2006 From: mike at miketc.com (Mike Chambers) Date: Sun, 31 Dec 2006 17:50:22 -0600 Subject: Rawhide status Message-ID: <1167609022.3549.1.camel@scrappy.miketc.com> Is rawhide status sort of broken due to kernel, dev stuff (hdx to sdx) or whatever? Or is that part fixed and even installable or whatever now? Hvaen't tried it in a week or longer, and ended up having to reinstall FC6+updates to get back a usable system. -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless your not getting any!"