From zaitcev at redhat.com Thu Mar 1 00:05:55 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 28 Feb 2007 16:05:55 -0800 Subject: usb storage regression? (was: experimental 2.6.19 kernel preview.) In-Reply-To: <20070107183517.GF5870@redhat.com> References: <1167812088.3567.9.camel@sonlaptop> <20070103173644.GA3862@kerouac> <20070103190743.6bd0fef8@lain.camperquake.de> <20070103191657.GB3862@kerouac> <20070103225824.GA11354@redhat.com> <20070104090244.115940@gmx.net> <20070104172302.GB3129@redhat.com> <20070107040605.GC1905@redhat.com> <1168184972.3138.12.camel@sioux.systems.cs.cornell.edu> <20070107183517.GF5870@redhat.com> Message-ID: <20070228160555.780f081c.zaitcev@redhat.com> Was there anything new about the issue with USB storage (quoted below)? I don't see anything in archives. -- Pete On Sun, 7 Jan 2007 13:35:17 -0500, Dave Jones wrote: > > kernel-2.6.19-1.2905.fc7.x86_64 on booting always drops me into fsck for > > a non-root USB disk [0] that is formatted as an ext3 volume and mounted > > from fstab as ext3. Incidentally, I just noticed that the partition type > > as reported by fdisk is still W95FAT(LBA). The fsck error is that it > > cannot find the superblock. Manually giving the alternate block > > locations doesn't help. dmesg output is lost since the boot process > > doesn't complete and I am afraid of forcing it through incase it results > > in any FS corruption on the USB disk (which works on other kernels). > > > > The same setup works flawlessly on 2.6.18-1.2849.fc6.x86_64, finds the > > superblocks and mounts the disk at boot time without reporting any > > errors. > > > > Do let me know if there are any relatively safe things I can do with > > 2.6.19 that'll help diagnose the problem better. > > > > [0] Bus 002 Device 005: ID 1058:0900 Western Digital Technologies, Inc. > > Hmm, odd. Pete, any ideas? From jwilson at redhat.com Thu Mar 1 02:50:57 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 28 Feb 2007 21:50:57 -0500 Subject: *-devel.x86_64 In-Reply-To: <1172705649.10428.73.camel@lat.home.erwinrol.com> References: <1172705649.10428.73.camel@lat.home.erwinrol.com> Message-ID: <45E63F91.3080204@redhat.com> Erwin Rol wrote: > What happened to a lot of devel.x86_64 packages. For example i can't > compile X11 apps that use pkg-config anymore because things like > xproto.pc only exist in /usr/lib/pkgconfig/ and not > in /usr/lib64/pkgconfig/, but /usr/lib64/pkgconfig/x11.pc has a require > xproto. > > Any idea what happend here, i already tried to install .x86_64 versions > but they are just not available. Rawhide repos had a bit of a problem today w/their metadata. Looks like its fixed on the master mirror, but may need a bit to trickle out to mirrors. -- Jarod Wilson jwilson at redhat.com From bojan at rexursive.com Thu Mar 1 04:41:35 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 1 Mar 2007 04:41:35 +0000 (UTC) Subject: ViewVC References: <20070209152809.1s4bir200k04cgsg@www.rexursive.com> <45CC6610.9070201@fedoraproject.org> Message-ID: Rahul Sundaram fedoraproject.org> writes: > afaik, No https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230512 -- Bojan From Lam at Lam.pl Thu Mar 1 06:31:24 2007 From: Lam at Lam.pl (Leszek Matok) Date: Thu, 01 Mar 2007 07:31:24 +0100 Subject: kernels oops - bug report In-Reply-To: <45E6175C.8040805@laposte.net> References: <45E6175C.8040805@laposte.net> Message-ID: <1172730684.4309.6.camel@pensja.lam.pl> Dnia 01-03-2007, czw o godzinie 00:59 +0100, Axel napisa?(a): > Hello > I d like to report a kernel oops, but I don't know how to catch the > kernel log. If you have two machines and the oops is coming relatively late in the boot stage, try netconsole (search Google for netconsole.txt). There's also a simpler method: if it doesn't reboot immediately, you can use digital camera - the kernel developers accept such screen shots :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From nicolas.mailhot at laposte.net Thu Mar 1 07:03:08 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 01 Mar 2007 08:03:08 +0100 Subject: [Fedora-i18n-list] Re: naming scheme for fonts packages? In-Reply-To: <45E61058.1020801@redhat.com> References: <45E54A39.7030104@redhat.com> <63347.192.54.193.51.1172657012.squirrel@rousalka.dyndns.org> <45E61058.1020801@redhat.com> Message-ID: <1172732588.15284.12.camel@rousalka.dyndns.org> Le jeudi 01 mars 2007 ? 09:29 +1000, Jens Petersen a ?crit : > Hi, > > Thanks for the followup. No charge ;) > Nicolas Mailhot wrote: > > To be honest I'm not too fond of foo-font packages. > > Sorry, did you mean "fonts-*"? Right, sorry > I agree with you for fonts for Western languages for which it is > possible to have reasonable coverage with limited resources. A general font like DejaVu does lao, arabic (better support is waiting on better opentype support pango & qt-side) aboriginal canadian syllabics, armenian, greek, cyrillic so I don't think the "western only" qualifier applies. You just need to get people to work together, doing a whole unicode block is no harder within an unicode font than within a specific font (in fact it's easier since you don't have to redo latin like all the asian fonts do now) > > IMHO (which if worth what it's worth) you're not packaging generic fonts > > for tibetan but a specific font project, and it deserves name recognition > > just like any other upstream. So upstreamname-fonts seems more respectful > > for me. Also have you though of what will happen should someone want to > > package another tibetan font in a few months ? > > Well in the review we are actually now discussing putting two GPL > Tibetan fonts in the same package if it is going by the generic language > name. That's the logical next step. It feels like putting kmail and evolution in the same "MUA" package though. Can't you get by with a "Tibetan support" comps group instead ? I will work with font packages crossing langage boundaries, not force users to install every single font for one langage (and in CJK countries that weights quite a lot), allow you to follow two separate upstream release schedules, etc. 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 nicolas.mailhot at laposte.net Thu Mar 1 08:01:02 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 1 Mar 2007 09:01:02 +0100 (CET) Subject: naming scheme for fonts packages? In-Reply-To: <45E60E84.5010006@redhat.com> References: <45E54A39.7030104@redhat.com> <53d4ffb80702280501l553785e1g7493889452a880ee@mail.gmail.com> <45E60E84.5010006@redhat.com> Message-ID: <23393.192.54.193.51.1172736062.squirrel@rousalka.dyndns.org> Le Jeu 1 mars 2007 00:21, Jens Petersen a ?crit : > But I see that as less of a problem since normal users > shouldn't really have to worry about the names of fonts packages for > languages but just use pirut to add appropriate language support. All the more reason not to bundle different projects in a single package but use comps groups instead -- Nicolas Mailhot From paul at city-fan.org Thu Mar 1 09:00:13 2007 From: paul at city-fan.org (Paul Howarth) Date: Thu, 01 Mar 2007 09:00:13 +0000 Subject: ANNOUNCE: bittorrent downgrade Message-ID: <45E6961D.9010703@city-fan.org> The bittorrent (and bittorrent-gui) package has been downgraded in the Extras development repo from version 5.0.5 to 4.4.0, due to compatibility problems between the GUI and wxPython 2.8.x (http://bugzilla.redhat.com/223623). Since bittorrent upstream is still doing development on wxPython 2.6, there is little prospect of a fix for this before FC7 release, so the package has been downgraded to the last version that had a working (pygtk2-based) GUI. As this is still the development phase of the release, the downgrade was done without an epoch bump, so: MANUAL DOWNGRADE WILL BE NEEDED IF YOU USE THE bittorrent PACKAGE ON RAWHIDE. Regards, Paul. From david at fubar.dk Thu Mar 1 09:35:59 2007 From: david at fubar.dk (David Zeuthen) Date: Thu, 01 Mar 2007 04:35:59 -0500 Subject: ANNOUNCE: bittorrent downgrade In-Reply-To: <45E6961D.9010703@city-fan.org> References: <45E6961D.9010703@city-fan.org> Message-ID: <1172741759.2617.12.camel@zelda.fubar.dk> Hi, On Thu, 2007-03-01 at 09:00 +0000, Paul Howarth wrote: > The bittorrent (and bittorrent-gui) package has been downgraded in the > Extras development repo from version 5.0.5 to 4.4.0, due to > compatibility problems between the GUI and wxPython 2.8.x Thanks for ensuring that packages are usable; sometimes, sadly, downgrading is the only option. Having said that... > As this is still the development phase of the release, the downgrade was > done without an epoch bump, so: > > MANUAL DOWNGRADE WILL BE NEEDED IF YOU USE THE bittorrent PACKAGE ON > RAWHIDE. Can we please stop doing such things just because some people don't like the Epoch being bumped? No-one have ever given good technical reasons for this, only - "it's ugly"; or - "some software is broken and don't know about Epoch"; or - "it's Rawhide, nobody should expect Rawhide to work" To me it just seems, how shall I put it, non-constructive to put users through a manual downgrade ordeal just to preserve one number that, for the record, is meaningless already. So, consider this a request for our various packaging committees to take action and make our packaging guidelines reflect that we just don't do things like this. Of course, if there exist technical reasons for not bumping the Epoch, I don't pretend to be a packaging gure by any means, that I'm not aware of I apologize for this noise. Thanks. David "I have an OCD about other people's OCD's" Zeuthen From kevin.verma at gmail.com Thu Mar 1 10:38:12 2007 From: kevin.verma at gmail.com (Anuj Verma (Kevin)) Date: Thu, 1 Mar 2007 10:38:12 +0000 (UTC) Subject: FYI: epiphany 2.16.3-2.fc6 crashes - BZ# 230333 Message-ID: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230333 From kzak at redhat.com Thu Mar 1 10:50:26 2007 From: kzak at redhat.com (Karel Zak) Date: Thu, 1 Mar 2007 11:50:26 +0100 Subject: announce: readahead-1.4 Message-ID: <20070301105026.GF4449@petra.dvoda.cz> I have just pushed out a new 1.4 version of the readahead util. The changes are: * move project to hosted.fedoraproject.org * source code maintained by GIT * various cleanups * new build-system based on autotools * --sort / --dont-sort support * add readahead-collector (based on audit system, requires audit-libs[-devel]) * improve init scripts (supports full, custom and fast mode) * add /etc/cron.daily/readahead.cron (with readahead --sort) Web page: https://hosted.fedoraproject.org/projects/readahead The code is not tested with FC7, because libauparse (from audit-libs-devel) is broken in FC7 now. If you want to generate your customized version of readahead lists you need to boot with "init=/sbin/readahead-collector". Also see /etc/readahead.conf and /usr/share/doc/readahead-1.4/README*. I welcome your feedback! Send me your comments, ideas for enhancements or bug reports. Karel -- Karel Zak From jonathan.underwood at gmail.com Thu Mar 1 12:36:47 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 1 Mar 2007 12:36:47 +0000 Subject: Plans for the (La)TeX stack for F7? Message-ID: <645d17210703010436t59ed5eecpe04b7ed7cf6722b5@mail.gmail.com> Hi, I notice that Jindrich Novy (tetex packages maintainer) is away until 27th March. Jindrich had previously mentioned his intention to move to TeXLive for F7, due to tetex being unmaintained and quite out of date. Is this still the intention? It would be useful to know from both a user and packager perspective if there's any kind of roadmap in place for this? Best wishes, Jonathan From jonathan.underwood at gmail.com Thu Mar 1 12:41:19 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 1 Mar 2007 12:41:19 +0000 Subject: Plans for the (La)TeX stack for F7? In-Reply-To: <645d17210703010436t59ed5eecpe04b7ed7cf6722b5@mail.gmail.com> References: <645d17210703010436t59ed5eecpe04b7ed7cf6722b5@mail.gmail.com> Message-ID: <645d17210703010441h1d68f163l5cc32b4def354f4@mail.gmail.com> On 01/03/07, Jonathan Underwood wrote: > I notice that Jindrich Novy (tetex packages maintainer) is away until > 27th March. Jindrich had previously mentioned his intention to move to > TeXLive for F7, due to tetex being unmaintained and quite out of date. > Is this still the intention? It would be useful to know from both a > user and packager perspective if there's any kind of roadmap in place > for this? Actually, I notice Jindrich has filed review request bugs for texlive packages - BZ 229180 and 229182, and this wiki page details his plans etc: http://fedoraproject.org/wiki/Releases/FeatureTexLive From buildsys at redhat.com Thu Mar 1 12:41:56 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 1 Mar 2007 07:41:56 -0500 Subject: rawhide report: 20070301 changes Message-ID: <200703011241.l21Cfue1025916@hs20-bc2-6.build.redhat.com> Updated Packages: a2ps-4.13b-61.fc7 ----------------- * Wed Feb 28 2007 Tim Waugh 4.13b-61 - Clean up tmpdir in pdiff (bug #214400). - Fixed permissions on C source files (bug #225235). - Use %configure (bug #225235). - Preserve timestamps (bug #225235). - Use smp_mflags (bug #225235). - Requires install-info for post and preun scriptlets (bug #225235). - Avoid tabs (bug #225235). - Explicity versioning for obsoletes/provides (bug #225235). - PreReq->Requires(post) (bug #225235). - Fixed macros in changelog (bug #225235). - Fixed summary (bug #225235). - Converted spec file to UTF-8 (bug #225235). - Fixed build root (bug #225235). - Remove ExcludeArch (bug #225235). - Use buildroot macro consistently (bug #225235). - Don't ship the library file or header (bug #203536). apr-util-1.2.8-4 ---------------- * Wed Feb 28 2007 Joe Orton 1.2.8-4 - add mysql driver in -mysql subpackage (Bojan Smojver, #222237) autofs-1:5.0.1-3 ---------------- * Thu Mar 01 2007 Ian Kent - 5.0.1-3 - change file map lexer to allow white-space only blank lines (bz 229434). cdrtools-9:2.01-11.fc7 ---------------------- * Wed Feb 28 2007 Harald Hoyer - 9:2.01-11.fc7 - specfile review devhelp-0.13-4.fc7 ------------------ * Wed Feb 28 2007 Matthew Barnes - 0.13-4 - Rebuild against newer gecko. dialog-1.1-1.20070227svn.fc7 ---------------------------- * Wed Feb 28 2007 Harald Hoyer - 1.1-1.20070227svn.fc7 - version 1.1-20070227 - added devel subpackage - specfile fixes (bug#225693) - Resolves: rhbz#225693 emacspeak-25-3.fc7 ------------------ * Thu Mar 01 2007 Jens Petersen - 25-3 - require emacs (lxo) f-spot-0.3.4-1.fc7 ------------------ * Wed Feb 28 2007 Matthias Clasen - 0.3.4-1 - Update to 0.3.4 firstboot-1.4.31-1.fc7 ---------------------- * Wed Feb 28 2007 Chris Lumens - 1.4.31-1 - Fix navigation when the language screen is enabled (#229515, #214962). - Remove duplicate warnings on create_user module. - Fix navigation when the create user module is last. gdm-1:2.17.8-1.fc7 ------------------ * Wed Feb 28 2007 Matthias Clasen - 1:2.17.8-1 - Update to 2.17.8 gnome-python2-desktop-2.17.93-1.fc7 ----------------------------------- * Wed Feb 28 2007 Matthias Clasen - 2.17.93-1 - Update to 2.17.93 gnome-screensaver-2.17.8-1.fc7 ------------------------------ * Wed Feb 28 2007 Ray Strode - 2.17.8-1 - Update to 2.17.8 (Matthias) - Drop obsolete patches (Matthias) - rework smart card patch gnome-themes-2.17.92-1.fc7 -------------------------- * Tue Feb 27 2007 Matthias Clasen - 2.17.92-1 - Update to 2.17.92 gok-1.2.2-1.fc7 --------------- * Tue Feb 27 2007 Matthias Clasen - 1.2.2-1 - Update to 1.2.2 libXrandr-1.2.0-2.fc7 --------------------- * Wed Feb 28 2007 Adam Jackson 1.2.0-2 - libXrandr-1.2.0-appease-cee-plus-plus.patch: don't use C++ keywords as function argument names. libart_lgpl-2.3.19-1.fc7 ------------------------ * Wed Feb 28 2007 Matthias Clasen - 2.3.19-1 - Update to 2.3.19 libbtctl-0.8.2-3.fc7 -------------------- * Wed Feb 28 2007 Harald Hoyer - 0.8.2-3.fc7 - specfile review - portet crash patch to 0.8.2 * Thu Dec 07 2006 Jeremy Katz - 0.8.2-2.fc7 - rebuild for python 2.5 * Mon Nov 13 2006 Harald Hoyer - 0.8.2-1.fc7 - version 0.8.2 - Resolves: rhbz#215230 mod_perl-2.0.3-7 ---------------- * Wed Feb 28 2007 Joe Orton 2.0.3-7 - also restore Apache::Test to devel - add BR for perl-devel openoffice.org-1:2.2.0-9.1 -------------------------- * Mon Feb 26 2007 Caolan McNamara - 1:2.2.0-9.1 - next release candidate - add openoffice.org-2.2.0.gccXXXXX.solenv.javaregistration.patch to workaround strange gcj component registration problem - a better fix for the persistant visibility markup problem * Wed Feb 21 2007 Caolan McNamara - 1:2.2.0-8.3 - add workspace.configrefactor01.patch and knock approx 1/2 sec off warm start * Tue Feb 20 2007 Caolan McNamara - 1:2.2.0-8.2 - ooo#74692 64bit form controls openssh-4.5p1-4.fc7 ------------------- * Tue Feb 27 2007 Tomas Mraz - 4.5p1-4 - reject connection if requested mls range is not obtained (#229278) openswan-2.4.7-2.fc7 -------------------- * Wed Feb 28 2007 Harald Hoyer - 2.4.7-2.fc7 - specfile review perl-4:5.8.8-14.fc7 ------------------- * Tue Feb 27 2007 Robin Norwood - 4:5.8.8-14 - Add a description for most of the patches, to reflect Spot's work to report said patches upstream. * Sat Feb 03 2007 Tom "spot" Callaway - 4:5.8.8-13 - massive cleanups * Wed Jan 24 2007 Jindrich Novy - 4:5.8.8-12 - put dist tag directly to perlrel to fix dependency to suidperl redhat-artwork-5.0.11-1.fc7 --------------------------- * Thu Mar 01 2007 David Zeuthen 5.0.11-1 - New release with Fedora 7 gdm theme - Require recent gtk2-engines to fix dark scrollbars in Clearlooks * Mon Feb 26 2007 Matthias Clasen 5.0.10-4 - Remove the start-here icon rhpl-0.202-1 ------------ * Wed Feb 28 2007 Chris Lumens - 0.202-1 - Replace deprecated exceptions with real classes (#220802). selinux-policy-2.5.6-1.fc7 -------------------------- * Wed Feb 28 2007 Dan Walsh 2.5.6-1 - Update to remove security_t:filesystem getattr problems shadow-utils-2:4.0.18.1-10.fc7 ------------------------------ * Wed Feb 28 2007 Peter Vrabec 2:4.0.18.1-10 - spec file fixes to meet fedora standarts. - fix useless call of restorecon(). (#222159) system-config-kickstart-2.7.3-1.fc7 ----------------------------------- * Wed Feb 28 2007 Chris Lumens 2.7.3-1 - Updated for the newer pykickstart interface. tn5250-0.17.3-14.fc7 -------------------- * Wed Feb 28 2007 Karsten Hopp 0.17.3-14 - copy readme instead of moving it - fix desktop file - fix scriptlets vixie-cron-4:4.1-75.fc7 ----------------------- * Wed Feb 28 2007 Marcela Maslanova - 4:4.1-75 - rhbz#226529 merge review xorg-x11-proto-devel-7.2-5.fc7 ------------------------------ * Wed Feb 28 2007 Adam Jackson 7.2-5 - Package review cleanups (#226641) * Wed Feb 28 2007 Adam Jackson 7.2-4 - Appease RPM. (#229336) yelp-2.16.2-5.fc7 ----------------- * Wed Feb 28 2007 Matthew Barnes - 2.16.2-5 - Rebuild against newer gecko. * Fri Feb 23 2007 Matthias Clasen 2.16.2-4 - Don't own /usr/share/icons/hicolor Broken deps for i386 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.i386 requires libgcj.so.7rh frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh openoffice.org-langpack-af_ZA - 1:2.2.0-9.1.i386 requires hunspell-af openoffice.org-langpack-bg_BG - 1:2.2.0-9.1.i386 requires hunspell-bg openoffice.org-langpack-ca_ES - 1:2.2.0-9.1.i386 requires hunspell-ca openoffice.org-langpack-cy_GB - 1:2.2.0-9.1.i386 requires hunspell-cy openoffice.org-langpack-da_DK - 1:2.2.0-9.1.i386 requires hunspell-da openoffice.org-langpack-de - 1:2.2.0-9.1.i386 requires hunspell-de openoffice.org-langpack-el_GR - 1:2.2.0-9.1.i386 requires hunspell-el openoffice.org-langpack-es - 1:2.2.0-9.1.i386 requires hunspell-es openoffice.org-langpack-et_EE - 1:2.2.0-9.1.i386 requires hunspell-ee openoffice.org-langpack-fr - 1:2.2.0-9.1.i386 requires hunspell-fr openoffice.org-langpack-ga_IE - 1:2.2.0-9.1.i386 requires hunspell-ga openoffice.org-langpack-gl_ES - 1:2.2.0-9.1.i386 requires hunspell-gl openoffice.org-langpack-he_IL - 1:2.2.0-9.1.i386 requires hunspell-he openoffice.org-langpack-hr_HR - 1:2.2.0-9.1.i386 requires hunspell-hr openoffice.org-langpack-hu_HU - 1:2.2.0-9.1.i386 requires hunspell-hu openoffice.org-langpack-it - 1:2.2.0-9.1.i386 requires hunspell-it openoffice.org-langpack-lt_LT - 1:2.2.0-9.1.i386 requires hunspell-lt openoffice.org-langpack-ms_MY - 1:2.2.0-9.1.i386 requires hunspell-ms openoffice.org-langpack-nb_NO - 1:2.2.0-9.1.i386 requires hunspell-nb openoffice.org-langpack-nl - 1:2.2.0-9.1.i386 requires hunspell-nl openoffice.org-langpack-nn_NO - 1:2.2.0-9.1.i386 requires hunspell-nn openoffice.org-langpack-pl_PL - 1:2.2.0-9.1.i386 requires hunspell-pl openoffice.org-langpack-pt_BR - 1:2.2.0-9.1.i386 requires hunspell-pt openoffice.org-langpack-pt_PT - 1:2.2.0-9.1.i386 requires hunspell-pt openoffice.org-langpack-ru - 1:2.2.0-9.1.i386 requires hunspell-ru openoffice.org-langpack-sk_SK - 1:2.2.0-9.1.i386 requires hunspell-sk openoffice.org-langpack-sl_SI - 1:2.2.0-9.1.i386 requires hunspell-sl openoffice.org-langpack-sv - 1:2.2.0-9.1.i386 requires hunspell-sv openoffice.org-langpack-th_TH - 1:2.2.0-9.1.i386 requires hunspell-th openoffice.org-langpack-zu_ZA - 1:2.2.0-9.1.i386 requires hunspell-zu Broken deps for ia64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ia64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ia64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.ia64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ia64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ia64 requires lm_sensors-devel Broken deps for x86_64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) cairo-java - 1.0.5-4.fc7.i386 requires libgcj.so.7rh frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.x86_64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh openoffice.org-langpack-af_ZA - 1:2.2.0-9.1.x86_64 requires hunspell-af openoffice.org-langpack-bg_BG - 1:2.2.0-9.1.x86_64 requires hunspell-bg openoffice.org-langpack-ca_ES - 1:2.2.0-9.1.x86_64 requires hunspell-ca openoffice.org-langpack-cy_GB - 1:2.2.0-9.1.x86_64 requires hunspell-cy openoffice.org-langpack-da_DK - 1:2.2.0-9.1.x86_64 requires hunspell-da openoffice.org-langpack-de - 1:2.2.0-9.1.x86_64 requires hunspell-de openoffice.org-langpack-el_GR - 1:2.2.0-9.1.x86_64 requires hunspell-el openoffice.org-langpack-es - 1:2.2.0-9.1.x86_64 requires hunspell-es openoffice.org-langpack-et_EE - 1:2.2.0-9.1.x86_64 requires hunspell-ee openoffice.org-langpack-fr - 1:2.2.0-9.1.x86_64 requires hunspell-fr openoffice.org-langpack-ga_IE - 1:2.2.0-9.1.x86_64 requires hunspell-ga openoffice.org-langpack-gl_ES - 1:2.2.0-9.1.x86_64 requires hunspell-gl openoffice.org-langpack-he_IL - 1:2.2.0-9.1.x86_64 requires hunspell-he openoffice.org-langpack-hr_HR - 1:2.2.0-9.1.x86_64 requires hunspell-hr openoffice.org-langpack-hu_HU - 1:2.2.0-9.1.x86_64 requires hunspell-hu openoffice.org-langpack-it - 1:2.2.0-9.1.x86_64 requires hunspell-it openoffice.org-langpack-lt_LT - 1:2.2.0-9.1.x86_64 requires hunspell-lt openoffice.org-langpack-ms_MY - 1:2.2.0-9.1.x86_64 requires hunspell-ms openoffice.org-langpack-nb_NO - 1:2.2.0-9.1.x86_64 requires hunspell-nb openoffice.org-langpack-nl - 1:2.2.0-9.1.x86_64 requires hunspell-nl openoffice.org-langpack-nn_NO - 1:2.2.0-9.1.x86_64 requires hunspell-nn openoffice.org-langpack-pl_PL - 1:2.2.0-9.1.x86_64 requires hunspell-pl openoffice.org-langpack-pt_BR - 1:2.2.0-9.1.x86_64 requires hunspell-pt openoffice.org-langpack-pt_PT - 1:2.2.0-9.1.x86_64 requires hunspell-pt openoffice.org-langpack-ru - 1:2.2.0-9.1.x86_64 requires hunspell-ru openoffice.org-langpack-sk_SK - 1:2.2.0-9.1.x86_64 requires hunspell-sk openoffice.org-langpack-sl_SI - 1:2.2.0-9.1.x86_64 requires hunspell-sl openoffice.org-langpack-sv - 1:2.2.0-9.1.x86_64 requires hunspell-sv openoffice.org-langpack-th_TH - 1:2.2.0-9.1.x86_64 requires hunspell-th openoffice.org-langpack-zu_ZA - 1:2.2.0-9.1.x86_64 requires hunspell-zu Broken deps for ppc ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ppc requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.ppc requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.ppc requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.ppc requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.ppc requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.ppc requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.ppc requires lm_sensors-devel openoffice.org-langpack-af_ZA - 1:2.2.0-9.1.ppc requires hunspell-af openoffice.org-langpack-bg_BG - 1:2.2.0-9.1.ppc requires hunspell-bg openoffice.org-langpack-ca_ES - 1:2.2.0-9.1.ppc requires hunspell-ca openoffice.org-langpack-cy_GB - 1:2.2.0-9.1.ppc requires hunspell-cy openoffice.org-langpack-da_DK - 1:2.2.0-9.1.ppc requires hunspell-da openoffice.org-langpack-de - 1:2.2.0-9.1.ppc requires hunspell-de openoffice.org-langpack-el_GR - 1:2.2.0-9.1.ppc requires hunspell-el openoffice.org-langpack-es - 1:2.2.0-9.1.ppc requires hunspell-es openoffice.org-langpack-et_EE - 1:2.2.0-9.1.ppc requires hunspell-ee openoffice.org-langpack-fr - 1:2.2.0-9.1.ppc requires hunspell-fr openoffice.org-langpack-ga_IE - 1:2.2.0-9.1.ppc requires hunspell-ga openoffice.org-langpack-gl_ES - 1:2.2.0-9.1.ppc requires hunspell-gl openoffice.org-langpack-he_IL - 1:2.2.0-9.1.ppc requires hunspell-he openoffice.org-langpack-hr_HR - 1:2.2.0-9.1.ppc requires hunspell-hr openoffice.org-langpack-hu_HU - 1:2.2.0-9.1.ppc requires hunspell-hu openoffice.org-langpack-it - 1:2.2.0-9.1.ppc requires hunspell-it openoffice.org-langpack-lt_LT - 1:2.2.0-9.1.ppc requires hunspell-lt openoffice.org-langpack-ms_MY - 1:2.2.0-9.1.ppc requires hunspell-ms openoffice.org-langpack-nb_NO - 1:2.2.0-9.1.ppc requires hunspell-nb openoffice.org-langpack-nl - 1:2.2.0-9.1.ppc requires hunspell-nl openoffice.org-langpack-nn_NO - 1:2.2.0-9.1.ppc requires hunspell-nn openoffice.org-langpack-pl_PL - 1:2.2.0-9.1.ppc requires hunspell-pl openoffice.org-langpack-pt_BR - 1:2.2.0-9.1.ppc requires hunspell-pt openoffice.org-langpack-pt_PT - 1:2.2.0-9.1.ppc requires hunspell-pt openoffice.org-langpack-ru - 1:2.2.0-9.1.ppc requires hunspell-ru openoffice.org-langpack-sk_SK - 1:2.2.0-9.1.ppc requires hunspell-sk openoffice.org-langpack-sl_SI - 1:2.2.0-9.1.ppc requires hunspell-sl openoffice.org-langpack-sv - 1:2.2.0-9.1.ppc requires hunspell-sv openoffice.org-langpack-th_TH - 1:2.2.0-9.1.ppc requires hunspell-th openoffice.org-langpack-zu_ZA - 1:2.2.0-9.1.ppc requires hunspell-zu Broken deps for ppc64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ppc64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.ppc64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ppc64 requires lm_sensors-devel Broken deps for s390 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.s390 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel 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 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.s390 requires libgcj.so.7rh cairo-java - 1.0.5-4.fc7.s390x requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.s390x requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390x requires libgcj.so.7rh()(64bit) libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390x requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.s390x requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.s390 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.s390x requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.s390x requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel net-snmp-devel - 1:5.4-10.fc7.s390x requires lm_sensors-devel From dennis at ausil.us Thu Mar 1 12:47:05 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 1 Mar 2007 06:47:05 -0600 Subject: ANNOUNCE: bittorrent downgrade In-Reply-To: <45E6961D.9010703@city-fan.org> References: <45E6961D.9010703@city-fan.org> Message-ID: <200703010647.11656.dennis@ausil.us> Once upon a time Thursday 01 March 2007, Paul Howarth wrote: > The bittorrent (and bittorrent-gui) package has been downgraded in the > Extras development repo from version 5.0.5 to 4.4.0, due to > compatibility problems between the GUI and wxPython 2.8.x > (http://bugzilla.redhat.com/223623). Since bittorrent upstream is still > doing development on wxPython 2.6, there is little prospect of a fix for > this before FC7 release, so the package has been downgraded to the last > version that had a working (pygtk2-based) GUI. Why don't you add a compat-wxPython 2.6 if it works with that? Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Thu Mar 1 13:01:03 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 1 Mar 2007 14:01:03 +0100 Subject: ANNOUNCE: bittorrent downgrade In-Reply-To: <1172741759.2617.12.camel@zelda.fubar.dk> References: <45E6961D.9010703@city-fan.org> <1172741759.2617.12.camel@zelda.fubar.dk> Message-ID: <20070301140103.56ed4c38.mschwendt.tmp0701.nospam@arcor.de> On Thu, 01 Mar 2007 04:35:59 -0500, David Zeuthen wrote: > Can we please stop doing such things just because some people don't like > the Epoch being bumped? No-one have ever given good technical reasons > for this, only > > - "it's ugly"; or > - "some software is broken and don't know about Epoch"; or > - "it's Rawhide, nobody should expect Rawhide to work" > > To me it just seems, how shall I put it, non-constructive to put users > through a manual downgrade ordeal just to preserve one number that, for > the record, is meaningless already. > > So, consider this a request for our various packaging committees to take > action and make our packaging guidelines reflect that we just don't do > things like this. Of course, if there exist technical reasons for not > bumping the Epoch, I don't pretend to be a packaging gure by any means, > that I'm not aware of I apologize for this noise. A technical reason for avoiding Epochs is that at the RPM level, the software version of a package is not independent from the package version. When adding an Epoch to a package, the Epoch becomes a necessary part of all forms of RPM version comparison. This introduces weaknesses in non-automatic versioned dependencies and requires packagers to specify the exact %{epoch} in all such dependencies to keep them strict. Example: Name: bar Requires: foo >= 1.0 would be satisfied by Name: foo Version: 0.5 Epoch: 1 because due to the Epoch, the smaller %version wins RPM version comparison. A solution to the problem would be to either avoid explicit dependencies on versioned _package names_ or introduce more virtual capabilities of the form Provides: foo(api) = 1.0 Provides: foo(abi) = 1.0 which would remain free of Epochs. From paul at city-fan.org Thu Mar 1 13:10:39 2007 From: paul at city-fan.org (Paul Howarth) Date: Thu, 01 Mar 2007 13:10:39 +0000 Subject: ANNOUNCE: bittorrent downgrade In-Reply-To: <200703010647.11656.dennis@ausil.us> References: <45E6961D.9010703@city-fan.org> <200703010647.11656.dennis@ausil.us> Message-ID: <45E6D0CF.6080909@city-fan.org> Dennis Gilmore wrote: > Once upon a time Thursday 01 March 2007, Paul Howarth wrote: >> The bittorrent (and bittorrent-gui) package has been downgraded in the >> Extras development repo from version 5.0.5 to 4.4.0, due to >> compatibility problems between the GUI and wxPython 2.8.x >> (http://bugzilla.redhat.com/223623). Since bittorrent upstream is still >> doing development on wxPython 2.6, there is little prospect of a fix for >> this before FC7 release, so the package has been downgraded to the last >> version that had a working (pygtk2-based) GUI. > > Why don't you add a compat-wxPython 2.6 if it works with that? The wxPython maintainer didn't think that a compat-wxPython26 package was a particularly good idea, and would prefer to try to get the wxPython 2.8 issues resolved instead: http://www.redhat.com/archives/fedora-maintainers/2007-February/msg00633.html Paul. From jkeating at redhat.com Thu Mar 1 13:22:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 1 Mar 2007 08:22:09 -0500 Subject: ANNOUNCE: bittorrent downgrade In-Reply-To: <1172741759.2617.12.camel@zelda.fubar.dk> References: <45E6961D.9010703@city-fan.org> <1172741759.2617.12.camel@zelda.fubar.dk> Message-ID: <200703010822.12387.jkeating@redhat.com> On Thursday 01 March 2007 04:35:59 David Zeuthen wrote: > Can we please stop doing such things just because some people don't like > the Epoch being bumped? No-one have ever given good technical reasons > for this, only I'd really rather not introduce epochs before the final freeze point. I'm perfectly happy with a policy that says no broken upgrade paths from the final freeze on (be that Test3 or Test4), but before that one should be free to back down a broken version. We don't seriously want people starting at fc6 going to f7test1, then yum upgrading to some point before test3 and complaining about some bug or such. The first thing we usually do is ask them to reproduce on a clean install from the latest test release or a clean anaconda upgrade from FX to the latest test release. The various state of packages along the way often contribute to a system being in an unreproducible state which doesn't help anybody when trying to fix bugs. -- 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 Matt_Domsch at dell.com Thu Mar 1 13:22:46 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 1 Mar 2007 07:22:46 -0600 Subject: kernels oops - bug report In-Reply-To: <45E6175C.8040805@laposte.net> References: <45E6175C.8040805@laposte.net> Message-ID: <20070301132246.GA5813@lists.us.dell.com> On Thu, Mar 01, 2007 at 12:59:24AM +0100, Axel wrote: > Hello > I d like to report a kernel oops, but I don't know how to catch the > kernel log. I highly recommend using serial console capturing for this. On the crashing machine, use this on the kernel command line: console=ttyS0,115200 console=tty0 and on the serial-connected capture machine, run minicom or my favorite, ttywatch, which writes everything it sees on the serial ports into a logfile. (ttywatch's advantage over minicom is its ease of setup - a simple well-documented config file, and it can capture arbitrarily many serial ports at once - e.g. my Digi 64port serial box as easily as it does a single serial port. In our lab, our machines-under-test are almost always attached to one of the Digi serial ports, so if/when we do crash them, we've got the data immediately - we don't have to try to reproduce it again just to get the capture data. Thanks, Matt -- 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 ndbecker2 at gmail.com Thu Mar 1 13:43:41 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 01 Mar 2007 08:43:41 -0500 Subject: Plans for the (La)TeX stack for F7? References: <645d17210703010436t59ed5eecpe04b7ed7cf6722b5@mail.gmail.com> <645d17210703010441h1d68f163l5cc32b4def354f4@mail.gmail.com> Message-ID: Jonathan Underwood wrote: > On 01/03/07, Jonathan Underwood wrote: >> I notice that Jindrich Novy (tetex packages maintainer) is away until >> 27th March. Jindrich had previously mentioned his intention to move to >> TeXLive for F7, due to tetex being unmaintained and quite out of date. >> Is this still the intention? It would be useful to know from both a >> user and packager perspective if there's any kind of roadmap in place >> for this? > > Actually, I notice Jindrich has filed review request bugs for texlive > packages - BZ 229180 and 229182, and this wiki page details his plans > etc: > > http://fedoraproject.org/wiki/Releases/FeatureTexLive > I'm playing around with trying to build/install these packages on fc6. I wonder if the texlive packages should provide the corresponding tetex packages? Otherwise, it seems that a lot of packages that require TeX are going to break. From denis at poolshark.org Thu Mar 1 13:50:31 2007 From: denis at poolshark.org (Denis Leroy) Date: Thu, 01 Mar 2007 14:50:31 +0100 Subject: Issues with rawhide mptspi module Message-ID: <45E6DA27.80904@poolshark.org> Is anyone else having issues with the LSI Fusion SPI host driver (mptspi.ko) on rawhide ? rawhide is running as VMware guest OS. mptspi loads but fails to correctly scan any of the connected disk. I had to change the VM disk from scsi/lsilogic to an ide drive to be able to boot. I'll check with the VMWare folks as well. -denis From jacliburn at bellsouth.net Thu Mar 1 13:59:12 2007 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Thu, 01 Mar 2007 07:59:12 -0600 Subject: kernels oops - bug report In-Reply-To: <20070301132246.GA5813@lists.us.dell.com> References: <45E6175C.8040805@laposte.net> <20070301132246.GA5813@lists.us.dell.com> Message-ID: <45E6DC30.7020003@bellsouth.net> Matt Domsch wrote: > and on the serial-connected capture machine, run minicom or my > favorite, ttywatch, which writes everything it sees on the serial > ports into a logfile. Thanks for this pointer to ttywatch. I'd never heard of it before now. I've always used minicom for console capture. From buc at odusz.so-cdu.ru Thu Mar 1 14:05:46 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 01 Mar 2007 17:05:46 +0300 Subject: Issues with rawhide mptspi module In-Reply-To: <45E6DA27.80904@poolshark.org> References: <45E6DA27.80904@poolshark.org> Message-ID: <45E6DDBA.9020305@odu.neva.ru> Denis Leroy wrote: > Is anyone else having issues with the LSI Fusion SPI host driver > (mptspi.ko) on rawhide ? > > rawhide is running as VMware guest OS. mptspi loads but fails to > correctly scan any of the connected disk. I had to change the VM disk > from scsi/lsilogic to an ide drive to be able to boot. I'll check with > the VMWare folks as well. > > -denis > Yeah... Since 2.6.17 :( http://bugzilla.redhat.com/bugzilla/200787 http://bugzilla.redhat.com/bugzilla/208033 ~buc From jwilson at redhat.com Thu Mar 1 14:47:18 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 01 Mar 2007 09:47:18 -0500 Subject: kernels oops - bug report In-Reply-To: <45E6DC30.7020003@bellsouth.net> References: <45E6175C.8040805@laposte.net> <20070301132246.GA5813@lists.us.dell.com> <45E6DC30.7020003@bellsouth.net> Message-ID: <45E6E776.8020705@redhat.com> Jay Cliburn wrote: > Matt Domsch wrote: > >> and on the serial-connected capture machine, run minicom or my >> favorite, ttywatch, which writes everything it sees on the serial >> ports into a logfile. > > Thanks for this pointer to ttywatch. I'd never heard of it before now. > I've always used minicom for console capture. I'm not familiar with ttywatch myself, but I rather like conman. Sounds like the functionality is fairly similar. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From rdieter at math.unl.edu Thu Mar 1 16:00:19 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 01 Mar 2007 10:00:19 -0600 Subject: Plans for the (La)TeX stack for F7? In-Reply-To: References: <645d17210703010436t59ed5eecpe04b7ed7cf6722b5@mail.gmail.com> <645d17210703010441h1d68f163l5cc32b4def354f4@mail.gmail.com> Message-ID: Neal Becker wrote: > Jonathan Underwood wrote: > >> On 01/03/07, Jonathan Underwood wrote: >>> I notice that Jindrich Novy (tetex packages maintainer) is away until >>> 27th March. Jindrich had previously mentioned his intention to move to >>> TeXLive for F7, due to tetex being unmaintained and quite out of date. >>> Is this still the intention? It would be useful to know from both a >>> user and packager perspective if there's any kind of roadmap in place >>> for this? >> Actually, I notice Jindrich has filed review request bugs for texlive >> packages - BZ 229180 and 229182, and this wiki page details his plans >> etc: >> >> http://fedoraproject.org/wiki/Releases/FeatureTexLive >> > > I'm playing around with trying to build/install these packages on fc6. > > I wonder if the texlive packages should provide the corresponding tetex > packages? Otherwise, it seems that a lot of packages that require TeX are > going to break. Upgrade paths are certainly an issue that should be addressed in the package review. -- Rex From jkeating at redhat.com Thu Mar 1 16:12:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 1 Mar 2007 11:12:11 -0500 Subject: Announcing Fedora 7 Test 2 (6.91) Message-ID: <200703011112.12348.jkeating@redhat.com> Welcome to Fedora 7 Test 2 I am please to announce the second test release for Fedora 7. Downloads ======== DVD and network installation are available. Please read the Important Warnings below in this announcement for more details. http://torrent.fedoraproject.org/ The recommended method of download is via BitTorrent from this site. http://fedora.redhat.com/Download/mirrors.html HTTP, FTP, and RSYNC downloads are available from Fedora Project mirrors listed above. Note that not all mirrors may be synced at this time. ***Important Warnings about the Test Release*** Problems with mkinitrd ======== This test release has an rpm ordering issue that seems to affect some people with regard to mkinitrd being installed correctly. If your install seems to stall at installing the kernel and never continues, please try the updates image http://people.redhat.com/~katzj/updates-f7t2.img. Refer to http://fedoraproject.org/wiki/Anaconda/Updates for more information on using updates images. Upgrading with PATA Hard Disks ======== If you are using PATA (parallel or "original" style ATA) hard disks and you attempt to do a manual yum upgrade to this release, you may be unable to boot your system when finished. To avoid this problem, use the installer program (Anaconda) to upgrade your system instead of using yum. New in Fedora 7 Test 2 ======== This test release includes significant new versions of many key components and technologies. The following sections provide a brief overview of major changes from the last release of Fedora. Merger of Core and Extras ======== * The Fedora Core and Extras software repositories are being merged, resulting in a shared infrastructure and a single repository of packages to which everyone is invited to contribute. * Fedora 7 Test 2 is packaged initially as a Desktop/Development Workstation/Server implementation, called "Prime". This spin is delivered in DVD iso format only as a trial, see https://www.redhat.com/archives/fedora-devel-list/2007-February/msg00993.html for the discussion on this. * Many more packages are available in the development repositories. * Three targetted spins are now under discussion: Fedora Prime, Fedora KDE, and Fedora Everything. See http://fedoraproject.org/wiki/Releases/FeatureFedoraTargettedSpins for more details. Live CD ======== * This test release includes an i386 ISO for a Desktop Live CD. This Live CD features the ability to install to a hard disk using the same graphical Anaconda installer as the non-live CD variant. Desktop ======== * This test release features GNOME 2.17.91. * A brand new Echo icon theme is included as the default in this release. This icon theme is incomplete, but with appropriate feedback and progress, may become the default in the general release. * KDE and Xfce, among several other packages, are included in the development repositories, but not on the media. They can be installed using the appropriate software management tools. * Fast User Switching is now available via the fast-user-switch-applet. See http://fedoraproject.org/wiki/Releases/FeatureFastUserSwitching for more details. Performance ======== * System performance is generally slower in the test releases as compared to the general release since we enable several options that help with debugging. System Administration ======== * System administration tools may be modified under the testing process. System Level Changes ======== * Fedora 7 Test 2 features a 2.6.21rc1 based kernel. Current release information is being tracked on the kernel release notes source page. (http://fedoraproject.org/wiki/Docs/Beats/Kernel) Amanda Users who upgrade from older releases need to read the amanda.conf and amanda-client.conf man pages to learn about the the new syntax for calling amandad, as well as edit the /etc/xinetd.d/amanda configuration file to follow the new syntax. Road Map And Release Schedule ======== * http://fedoraproject.org/wiki/Releases/7/ Intended Audience for Test Releases ======== Test 1 is targeted for developers, who use it "at their own risk", and contains many bleeding edge packages. Test 2 is for early adopters. Most things should work and we need to your help to find what is broken. Test 3 is for early adopters. Most things should work and we need to your help to find what is broken. Test 4 is for beta users. This is the time when we must have full community participation. Without this participation both hardware and software functionality suffers. Quality Assurance for Test Releases ======== The Fedora Project has a process in place for ensuring the highest possible quality even in our test releases. Many bugs are identified, prioritized and fixed during the testing process. We also have a list of known bugs in this release. Refer to http://fedoraproject.org/wiki/QA/7/Test2TreeTesting for more details. Translations of Release Notes ======== Due to the rapidly changing nature of test releases, translations of release notes for test releases are not practical. The initial goal is to have a translation of the release notes included in the test4 release and to allow community review and correction before the general release. As always, the general release is translated following the established practices for localization (l10n) and internationalization (i18n) (http://fedoraproject.org/wiki/L10N), which result in comprehensive, high-quality release notes in a variety of languages. About Fedora ======== Fedora is a set of projects sponsored by Red Hat and guided by the contributors. These projects are developed by a large community of people who strive to provide and maintain the very best in free, open source software and standards. The central Fedora project is an operating system and platform based on Linux that is always free for anyone to use, modify, and distribute, now and forever. You can help the Fedora Project community continue to improve Fedora if you file bug reports and enhancement requests. Refer to http://fedoraproject.org/wiki/BugsAndFeatureRequests for more information. Thank you for your participation. To find out more general information about Fedora, refer to the following Web pages: * Fedora Overview (http://fedoraproject.org/wiki/Overview) * Fedora FAQ (http://fedoraproject.org/wiki/FAQ) * Help and Support (http://fedoraproject.org/wiki/Communicate) * Participate in the Fedora Project (http://fedoraproject.org/wiki/HelpWanted) -- 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 buc at odusz.so-cdu.ru Thu Mar 1 16:28:14 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Thu, 01 Mar 2007 19:28:14 +0300 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <200703011112.12348.jkeating@redhat.com> References: <200703011112.12348.jkeating@redhat.com> Message-ID: <45E6FF1E.2030405@odu.neva.ru> Jesse Keating wrote: > Upgrading with PATA Hard Disks > ======== > If you are using PATA (parallel or "original" style ATA) hard disks and you > attempt to do a manual yum upgrade to this release, you may be unable to boot > your system when finished. To avoid this problem, use the installer program > (Anaconda) to upgrade your system instead of using yum. > "*Manual* yum upgrade" implies that I would prefer some *manual* (not Anaconda) way to fix this issue... In other words, what I should do after the "yum upgrade" and before the reboot? Dmitry Butskoy From dennis at ausil.us Thu Mar 1 16:35:20 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 1 Mar 2007 10:35:20 -0600 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <45E6FF1E.2030405@odu.neva.ru> References: <200703011112.12348.jkeating@redhat.com> <45E6FF1E.2030405@odu.neva.ru> Message-ID: <200703011035.20921.dennis@ausil.us> On Thursday 01 March 2007 10:28:14 am Dmitry Butskoy wrote: > Jesse Keating wrote: > > Upgrading with PATA Hard Disks > > ======== > > If you are using PATA (parallel or "original" style ATA) hard disks and > > you attempt to do a manual yum upgrade to this release, you may be unable > > to boot your system when finished. To avoid this problem, use the > > installer program (Anaconda) to upgrade your system instead of using yum. > > "*Manual* yum upgrade" implies that I would prefer some *manual* (not > Anaconda) way to fix this issue... > > In other words, what I should do after the "yum upgrade" and before the > reboot? you would need to setup modprobe.conf before you do your yum update make sure it has the correct entry for the module for your pata controller. -- Dennis Gilmore, RHCE From j.w.r.degoede at hhs.nl Thu Mar 1 16:55:25 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 01 Mar 2007 17:55:25 +0100 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <200703011035.20921.dennis@ausil.us> References: <200703011112.12348.jkeating@redhat.com> <45E6FF1E.2030405@odu.neva.ru> <200703011035.20921.dennis@ausil.us> Message-ID: <45E7057D.4010606@hhs.nl> Dennis Gilmore wrote: > On Thursday 01 March 2007 10:28:14 am Dmitry Butskoy wrote: >> Jesse Keating wrote: >>> Upgrading with PATA Hard Disks >>> ======== >>> If you are using PATA (parallel or "original" style ATA) hard disks and >>> you attempt to do a manual yum upgrade to this release, you may be unable >>> to boot your system when finished. To avoid this problem, use the >>> installer program (Anaconda) to upgrade your system instead of using yum. >> "*Manual* yum upgrade" implies that I would prefer some *manual* (not >> Anaconda) way to fix this issue... >> >> In other words, what I should do after the "yum upgrade" and before the >> reboot? > you would need to setup modprobe.conf before you do your yum update make sure > it has the correct entry for the module for your pata controller. > Heuh? Isn't this about libata making /dev/hdx /dev/sdy, and thus that you need to make sure that you're filesystems are mounted by label, and then after reboot and you know which sdy is your old hdx, fixup /etc/fstab for swap Regards, Hans From cra at WPI.EDU Thu Mar 1 16:41:19 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 1 Mar 2007 11:41:19 -0500 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <45E7057D.4010606@hhs.nl> References: <200703011112.12348.jkeating@redhat.com> <45E6FF1E.2030405@odu.neva.ru> <200703011035.20921.dennis@ausil.us> <45E7057D.4010606@hhs.nl> Message-ID: <20070301164119.GO3334@angus.ind.WPI.EDU> On Thu, Mar 01, 2007 at 05:55:25PM +0100, Hans de Goede wrote: > >>In other words, what I should do after the "yum upgrade" and before the > >>reboot? > >you would need to setup modprobe.conf before you do your yum update make > >sure it has the correct entry for the module for your pata controller. > > > > Heuh? Isn't this about libata making /dev/hdx /dev/sdy, and thus that > you need to make sure that you're filesystems are mounted by label, and > then after reboot and you know which sdy is your old hdx, fixup > /etc/fstab for swap It's probably a good idea to fix up /etc/sysconfig/grub before running Anaconda too [1] [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229704 From paul at city-fan.org Thu Mar 1 16:46:20 2007 From: paul at city-fan.org (Paul Howarth) Date: Thu, 01 Mar 2007 16:46:20 +0000 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <45E7057D.4010606@hhs.nl> References: <200703011112.12348.jkeating@redhat.com> <45E6FF1E.2030405@odu.neva.ru> <200703011035.20921.dennis@ausil.us> <45E7057D.4010606@hhs.nl> Message-ID: <45E7035C.8020702@city-fan.org> Hans de Goede wrote: > > > Dennis Gilmore wrote: >> On Thursday 01 March 2007 10:28:14 am Dmitry Butskoy wrote: >>> Jesse Keating wrote: >>>> Upgrading with PATA Hard Disks >>>> ======== >>>> If you are using PATA (parallel or "original" style ATA) hard disks and >>>> you attempt to do a manual yum upgrade to this release, you may be >>>> unable >>>> to boot your system when finished. To avoid this problem, use the >>>> installer program (Anaconda) to upgrade your system instead of using >>>> yum. >>> "*Manual* yum upgrade" implies that I would prefer some *manual* (not >>> Anaconda) way to fix this issue... >>> >>> In other words, what I should do after the "yum upgrade" and before the >>> reboot? >> you would need to setup modprobe.conf before you do your yum update >> make sure it has the correct entry for the module for your pata >> controller. >> > > Heuh? Isn't this about libata making /dev/hdx /dev/sdy, and thus that > you need to make sure that you're filesystems are mounted by label, and > then after reboot and you know which sdy is your old hdx, fixup > /etc/fstab for swap Nope, this is about the PATA drivers being built as modules now. http://kernelslacker.livejournal.com/72836.html Paul. From dennis at ausil.us Thu Mar 1 16:46:31 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 1 Mar 2007 10:46:31 -0600 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <45E7057D.4010606@hhs.nl> References: <200703011112.12348.jkeating@redhat.com> <200703011035.20921.dennis@ausil.us> <45E7057D.4010606@hhs.nl> Message-ID: <200703011046.32048.dennis@ausil.us> On Thursday 01 March 2007 10:55:25 am Hans de Goede wrote: > Dennis Gilmore wrote: > > On Thursday 01 March 2007 10:28:14 am Dmitry Butskoy wrote: > >> Jesse Keating wrote: > >>> Upgrading with PATA Hard Disks > >>> ======== > >>> If you are using PATA (parallel or "original" style ATA) hard disks and > >>> you attempt to do a manual yum upgrade to this release, you may be > >>> unable to boot your system when finished. To avoid this problem, use > >>> the installer program (Anaconda) to upgrade your system instead of > >>> using yum. > >> > >> "*Manual* yum upgrade" implies that I would prefer some *manual* (not > >> Anaconda) way to fix this issue... > >> > >> In other words, what I should do after the "yum upgrade" and before the > >> reboot? > > > > you would need to setup modprobe.conf before you do your yum update make > > sure it has the correct entry for the module for your pata controller. > > Heuh? Isn't this about libata making /dev/hdx /dev/sdy, and thus that > you need to make sure that you're filesystems are mounted by label, and > then after reboot and you know which sdy is your old hdx, fixup > /etc/fstab for swap Thats part of it to. the ata drivers are modules now and not built into the kernel. I probably missed something else also. -- Dennis Gilmore, RHCE From notting at redhat.com Thu Mar 1 16:49:30 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Mar 2007 11:49:30 -0500 Subject: ANNOUNCE: bittorrent downgrade In-Reply-To: <20070301140103.56ed4c38.mschwendt.tmp0701.nospam@arcor.de> References: <45E6961D.9010703@city-fan.org> <1172741759.2617.12.camel@zelda.fubar.dk> <20070301140103.56ed4c38.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070301164930.GC14783@nostromo.devel.redhat.com> Michael Schwendt (mschwendt.tmp0701.nospam at arcor.de) said: > A technical reason for avoiding Epochs is that at the RPM level, the > software version of a package is not independent from the package > version. When adding an Epoch to a package, the Epoch becomes a necessary > part of all forms of RPM version comparison. This introduces weaknesses in > non-automatic versioned dependencies and requires packagers to specify the > exact %{epoch} in all such dependencies to keep them strict. > > Example: > > Name: bar > Requires: foo >= 1.0 > > would be satisfied by > > Name: foo > Version: 0.5 > Epoch: 1 > > because due to the Epoch, the smaller %version wins RPM version comparison. However, these can be queried and accounted for when an epoch is introduced. I'd agree with David - if we *can* make the upgrade path clean, we should. Sometimes, there will be things that fail (horribly broken %pre/%post scripts), but if the solution is clean (and adding epoch where needed is clean), we should do it. Bill From notting at redhat.com Thu Mar 1 16:51:14 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Mar 2007 11:51:14 -0500 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <200703011035.20921.dennis@ausil.us> References: <200703011112.12348.jkeating@redhat.com> <45E6FF1E.2030405@odu.neva.ru> <200703011035.20921.dennis@ausil.us> Message-ID: <20070301165114.GD14783@nostromo.devel.redhat.com> Dennis Gilmore (dennis at ausil.us) said: > you would need to setup modprobe.conf before you do your yum update make sure > it has the correct entry for the module for your pata controller. This *should not* be needed. If it is, it's a bug that needs to be fixed. Bill From ajackson at redhat.com Thu Mar 1 16:42:27 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 01 Mar 2007 11:42:27 -0500 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <45E6FF1E.2030405@odu.neva.ru> References: <200703011112.12348.jkeating@redhat.com> <45E6FF1E.2030405@odu.neva.ru> Message-ID: <1172767347.22136.112.camel@localhost.localdomain> On Thu, 2007-03-01 at 19:28 +0300, Dmitry Butskoy wrote: > Jesse Keating wrote: > > Upgrading with PATA Hard Disks > > ======== > > If you are using PATA (parallel or "original" style ATA) hard disks and you > > attempt to do a manual yum upgrade to this release, you may be unable to boot > > your system when finished. To avoid this problem, use the installer program > > (Anaconda) to upgrade your system instead of using yum. > > > > "*Manual* yum upgrade" implies that I would prefer some *manual* (not > Anaconda) way to fix this issue... > > In other words, what I should do after the "yum upgrade" and before the > reboot? AFAIK this works now. I upgraded from FC6 to rawhide yesterday on a PATA laptop with no problems, and no special dancing required. - ajax From jkeating at redhat.com Thu Mar 1 16:58:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 1 Mar 2007 11:58:52 -0500 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <1172767347.22136.112.camel@localhost.localdomain> References: <200703011112.12348.jkeating@redhat.com> <45E6FF1E.2030405@odu.neva.ru> <1172767347.22136.112.camel@localhost.localdomain> Message-ID: <200703011158.52931.jkeating@redhat.com> On Thursday 01 March 2007 11:42:27 Adam Jackson wrote: > AFAIK this works now. ?I upgraded from FC6 to rawhide yesterday on a > PATA laptop with no problems, and no special dancing required. Rawhide yesterday is newer than what Test2 is. -- 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 jonathan.underwood at gmail.com Thu Mar 1 16:59:27 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 1 Mar 2007 16:59:27 +0000 Subject: Plans for the (La)TeX stack for F7? In-Reply-To: References: <645d17210703010436t59ed5eecpe04b7ed7cf6722b5@mail.gmail.com> <645d17210703010441h1d68f163l5cc32b4def354f4@mail.gmail.com> Message-ID: <645d17210703010859y5165324bue334e6f3afbcd8bf@mail.gmail.com> On 01/03/07, Rex Dieter wrote: > Upgrade paths are certainly an issue that should be addressed in the > package review. As well as that, add-on packages at the moment are named tetex-foo, which will clearly be confusing for users after a move to texlive. A package naming policy is needed for add on packages, with either tex-foo or latex-bar being obvious choices, depending on whether they're add on packages for tex, or latex.I've previously mentioned this on this list, but noone cared :) Jonathan. From notting at redhat.com Thu Mar 1 16:59:01 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Mar 2007 11:59:01 -0500 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <200703011158.52931.jkeating@redhat.com> References: <200703011112.12348.jkeating@redhat.com> <45E6FF1E.2030405@odu.neva.ru> <1172767347.22136.112.camel@localhost.localdomain> <200703011158.52931.jkeating@redhat.com> Message-ID: <20070301165901.GE14783@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > > AFAIK this works now. ?I upgraded from FC6 to rawhide yesterday on a > > PATA laptop with no problems, and no special dancing required. > > Rawhide yesterday is newer than what Test2 is. Sure, but nothing changed in that area between test2 and now. Bill From tibbs at math.uh.edu Thu Mar 1 17:21:50 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 Mar 2007 11:21:50 -0600 Subject: Plans for the (La)TeX stack for F7? In-Reply-To: <645d17210703010859y5165324bue334e6f3afbcd8bf@mail.gmail.com> References: <645d17210703010436t59ed5eecpe04b7ed7cf6722b5@mail.gmail.com> <645d17210703010441h1d68f163l5cc32b4def354f4@mail.gmail.com> <645d17210703010859y5165324bue334e6f3afbcd8bf@mail.gmail.com> Message-ID: >>>>> "JU" == Jonathan Underwood writes: JU> A package naming policy is needed for add on packages, with either JU> tex-foo or latex-bar being obvious choices, depending on whether JU> they're add on packages for tex, or latex.I've previously JU> mentioned this on this list, but noone cared :) Well, I don't recall seeing you mention it before, but I have poor recall so that's not saying much. Care to write up a draft in somewhere like http://fedoraproject.org/wiki/PackagingDrafts/TeXNaming so the packaging committee can consider it? - J< From tonynelson at georgeanelson.com Thu Mar 1 17:34:12 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Thu, 1 Mar 2007 12:34:12 -0500 Subject: announce: readahead-1.4 In-Reply-To: <20070301105026.GF4449@petra.dvoda.cz> References: <20070301105026.GF4449@petra.dvoda.cz> Message-ID: At 11:50 AM +0100 3/1/07, Karel Zak wrote: ... > I welcome your feedback! Send me your comments, ideas for > enhancements or bug reports. Gitweb would like you to name the repository and give it an owner. The links to Bugzilla should probably not point to gnome-applet-vm. -- ____________________________________________________________________ TonyN.:' ' From jonathan.underwood at gmail.com Thu Mar 1 17:42:27 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 1 Mar 2007 17:42:27 +0000 Subject: Plans for the (La)TeX stack for F7? In-Reply-To: References: <645d17210703010436t59ed5eecpe04b7ed7cf6722b5@mail.gmail.com> <645d17210703010441h1d68f163l5cc32b4def354f4@mail.gmail.com> <645d17210703010859y5165324bue334e6f3afbcd8bf@mail.gmail.com> Message-ID: <645d17210703010942k788d13c1v740e46156b86a3f3@mail.gmail.com> On 01 Mar 2007 11:21:50 -0600, Jason L Tibbitts III wrote: > Care to write up a draft in somewhere like > http://fedoraproject.org/wiki/PackagingDrafts/TeXNaming so the > packaging committee can consider it? OK, I will do shortly. From kloczek at zie.pg.gda.pl Thu Mar 1 17:55:38 2007 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Thu, 01 Mar 2007 18:55:38 +0100 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <200703011112.12348.jkeating@redhat.com> References: <200703011112.12348.jkeating@redhat.com> Message-ID: <1172771738.25356.2.camel@kloczek01.pracownicy.zie> Dnia 01-03-2007, czw o godzinie 11:12 -0500, Jesse Keating napisa?(a): [..] Any chanse for fix X server memory leak before final Fedora 7 ? Anyone working on this ? PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 25851 root 15 0 1941m 729m 7868 S 15 36.2 43:33.34 Xorg kloczek From ajackson at redhat.com Thu Mar 1 17:49:04 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 01 Mar 2007 12:49:04 -0500 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <1172771738.25356.2.camel@kloczek01.pracownicy.zie> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> Message-ID: <1172771344.22136.118.camel@localhost.localdomain> On Thu, 2007-03-01 at 18:55 +0100, Tomasz K?oczko wrote: > Dnia 01-03-2007, czw o godzinie 11:12 -0500, Jesse Keating napisa?(a): > [..] > > Any chanse for fix X server memory leak before final Fedora 7 ? > Anyone working on this ? You say this as though there were only one X server memory leak. Or as though you had a working testcase. Or as though it were actually X's fault instead of some boneheaded application you happen to be running. - ajax From kloczek at zie.pg.gda.pl Thu Mar 1 18:54:02 2007 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Thu, 01 Mar 2007 19:54:02 +0100 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <1172771344.22136.118.camel@localhost.localdomain> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> <1172771344.22136.118.camel@localhost.localdomain> Message-ID: <1172773609.25356.9.camel@kloczek01.pracownicy.zie> Dnia 01-03-2007, czw o godzinie 12:49 -0500, Adam Jackson napisa?(a): > You say this as though there were only one X server memory leak. > > Or as though you had a working testcase. > > Or as though it were actually X's fault instead of some boneheaded > application you happen to be running. [..] Run any gecko application (firefox, galeon, epiphany) and open page with short refresh time (I have usualy openned page with system monitoring like mrtg or zabbix) and start observe groving X server memory consumption. Module section from my /etc/X11/xorg.conf: Section "Module" Load "bitmap" Load "dbe" Load "dbe" Load "dri" Load "extmod" Load "fbdevhw" Load "freetype" Load "glx" Load "record" Load "type1" Load "xtrap" EndSection Fill free for as for any more details :) kloczek From nhruby at gmail.com Thu Mar 1 18:57:40 2007 From: nhruby at gmail.com (Nathan Hruby) Date: Thu, 1 Mar 2007 12:57:40 -0600 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <1172773609.25356.9.camel@kloczek01.pracownicy.zie> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> <1172771344.22136.118.camel@localhost.localdomain> <1172773609.25356.9.camel@kloczek01.pracownicy.zie> Message-ID: On 3/1/07, Tomasz K?oczko wrote: > Fill free for as for any more details :) Bugzilla id? -n -- ------------------------------------------- nathan hruby metaphysically wrinkle-free ------------------------------------------- From blizzard at redhat.com Thu Mar 1 19:01:09 2007 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 01 Mar 2007 14:01:09 -0500 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <1172773609.25356.9.camel@kloczek01.pracownicy.zie> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> <1172771344.22136.118.camel@localhost.localdomain> <1172773609.25356.9.camel@kloczek01.pracownicy.zie> Message-ID: <1172775669.32357.27.camel@localhost.localdomain> On Thu, 2007-03-01 at 19:54 +0100, Tomasz K?oczko wrote: > Dnia 01-03-2007, czw o godzinie 12:49 -0500, Adam Jackson napisa?(a): > > You say this as though there were only one X server memory leak. > > > > Or as though you had a working testcase. > > > > Or as though it were actually X's fault instead of some boneheaded > > application you happen to be running. > [..] > > Run any gecko application (firefox, galeon, epiphany) and open page with > short refresh time (I have usualy openned page with system monitoring > like mrtg or zabbix) and start observe groving X server memory > consumption. That's Gecko, not the X server. It has pretty aggressive image caching and stores the pixmaps on the server, not in its own memory. If you shut down that process and the X server returns to something sane it's not an X leak. (It's even arguable that if it doesn't shrink it's still not an X leak but is a fragmented allocator, but that's another discussion.) --Chris From jwboyer at jdub.homelinux.org Thu Mar 1 19:16:58 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 01 Mar 2007 13:16:58 -0600 Subject: kernels oops - bug report In-Reply-To: <20070301132246.GA5813@lists.us.dell.com> References: <45E6175C.8040805@laposte.net> <20070301132246.GA5813@lists.us.dell.com> Message-ID: <1172776618.2839.0.camel@vader.jdub.homelinux.org> On Thu, 2007-03-01 at 07:22 -0600, Matt Domsch wrote: > On Thu, Mar 01, 2007 at 12:59:24AM +0100, Axel wrote: > > Hello > > I d like to report a kernel oops, but I don't know how to catch the > > kernel log. > > I highly recommend using serial console capturing for this. On the > crashing machine, use this on the kernel command line: This assumes the machine has a serial port. Many laptops these days do not. josh From kloczek at zie.pg.gda.pl Thu Mar 1 19:32:51 2007 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Thu, 01 Mar 2007 20:32:51 +0100 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <1172775669.32357.27.camel@localhost.localdomain> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> <1172771344.22136.118.camel@localhost.localdomain> <1172773609.25356.9.camel@kloczek01.pracownicy.zie> <1172775669.32357.27.camel@localhost.localdomain> Message-ID: <1172777571.32335.11.camel@kloczek01.pracownicy.zie> Dnia 01-03-2007, czw o godzinie 14:01 -0500, Christopher Blizzard napisa?(a): > That's Gecko, not the X server. It has pretty aggressive image > caching and stores the pixmaps on the server, not in its own memory. > If you shut down that process and the X server returns to something > sane it's not an X leak. (It's even arguable that if it doesn't > shrink it's still not an X leak but is a fragmented allocator, but > that's another discussion.) I don't think it is in not only gecko bug because after kill all gecko applications amount of memory reserved by X server not back to start amount. Also xrestop don't shows anything about allocated big amount of memory on X server side for pixmaps. I'm just kill on my system all gecko applications and amount of memory used by X serwer drop down *only* from ~2.2GB to ~1.9GB. If it is not ML .. OK. Anyone working on fix X server "fragmented allocator" or so ? Also another fact: I have on my hands Sunray thin X terminal which uses own X server and as long I use the same scenario (gecko application with refreshing page) I never observe for example killing X session by some symptoms like X server memory leaks (SunRay server it is Solaris 10U2). X session on SunRay can be runed many days without even growing amount of memory consumed by gecko application on X client side and X server on Solaris side. This ML^H^Hfragmentation allocator bug not occurs probably because Solaris uses older version of Xorg X server (without this nasty bug) so probably shorter way fo fix this can be some regression tests observation. The same gecko application on remote Linux X server in my case can kills my X session (OOM) in ~2 days (X server is runed on computer with 4GB memory and 8GB swap). So IMO it is definitely something wrong on X server side. Even it it is not my question stays .. Q: anyone working on fix this ? kloczek From davej at redhat.com Thu Mar 1 19:40:08 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 1 Mar 2007 14:40:08 -0500 Subject: announce: readahead-1.4 In-Reply-To: <20070301105026.GF4449@petra.dvoda.cz> References: <20070301105026.GF4449@petra.dvoda.cz> Message-ID: <20070301194008.GA11931@redhat.com> On Thu, Mar 01, 2007 at 11:50:26AM +0100, Karel Zak wrote: > > I have just pushed out a new 1.4 version of the readahead util. > The changes are: > > * move project to hosted.fedoraproject.org > * source code maintained by GIT > * various cleanups > * new build-system based on autotools > * --sort / --dont-sort support > * add readahead-collector (based on audit system, > requires audit-libs[-devel]) > * improve init scripts (supports full, custom and fast mode) > * add /etc/cron.daily/readahead.cron (with readahead --sort) > > Web page: > > https://hosted.fedoraproject.org/projects/readahead > > > The code is not tested with FC7, because libauparse (from > audit-libs-devel) is broken in FC7 now. > > If you want to generate your customized version of readahead lists > you need to boot with "init=/sbin/readahead-collector". Also see > /etc/readahead.conf and /usr/share/doc/readahead-1.4/README*. Out of curiousity, how much overhead would it add to always run the collector without needing any boot arguments? Dave -- http://www.codemonkey.org.uk From drago01 at gmail.com Thu Mar 1 19:42:07 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 01 Mar 2007 20:42:07 +0100 Subject: kernels oops - bug report In-Reply-To: <1172776618.2839.0.camel@vader.jdub.homelinux.org> References: <45E6175C.8040805@laposte.net> <20070301132246.GA5813@lists.us.dell.com> <1172776618.2839.0.camel@vader.jdub.homelinux.org> Message-ID: <45E72C8F.10903@gmail.com> Josh Boyer wrote: > On Thu, 2007-03-01 at 07:22 -0600, Matt Domsch wrote: > >> On Thu, Mar 01, 2007 at 12:59:24AM +0100, Axel wrote: >> >>> Hello >>> I d like to report a kernel oops, but I don't know how to catch the >>> kernel log. >>> >> I highly recommend using serial console capturing for this. On the >> crashing machine, use this on the kernel command line: >> > > This assumes the machine has a serial port. Many laptops these days do > not. > > not only laptops... my mobo does not have serial/parallel ports ... > josh > > From ajackson at redhat.com Thu Mar 1 19:31:00 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 01 Mar 2007 14:31:00 -0500 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <1172777571.32335.11.camel@kloczek01.pracownicy.zie> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> <1172771344.22136.118.camel@localhost.localdomain> <1172773609.25356.9.camel@kloczek01.pracownicy.zie> <1172775669.32357.27.camel@localhost.localdomain> <1172777571.32335.11.camel@kloczek01.pracownicy.zie> Message-ID: <1172777460.22136.134.camel@localhost.localdomain> On Thu, 2007-03-01 at 20:32 +0100, Tomasz K?oczko wrote: > Dnia 01-03-2007, czw o godzinie 14:01 -0500, Christopher Blizzard > napisa?(a): > > That's Gecko, not the X server. It has pretty aggressive image > > caching and stores the pixmaps on the server, not in its own memory. > > If you shut down that process and the X server returns to something > > sane it's not an X leak. (It's even arguable that if it doesn't > > shrink it's still not an X leak but is a fragmented allocator, but > > that's another discussion.) > > I don't think it is in not only gecko bug because after kill all gecko > applications amount of memory reserved by X server not back to start > amount. Also xrestop don't shows anything about allocated big amount of > memory on X server side for pixmaps. The memory usage won't always drop back to where it was when you started, because the allocation arena is shared. Mozilla's pixmaps will be interleaved with those of other apps, so the highest-address allocation not belonging to Mozilla will stick around. > I'm just kill on my system all gecko applications and amount of memory > used by X serwer drop down *only* from ~2.2GB to ~1.9GB. If it is not > ML .. OK. Anyone working on fix X server "fragmented allocator" or so ? There's nobody working on an allocation repacker for X, no, and it would be a rather brutal thing to implement. I started hacking some page-out code for inactive pixmaps, but never got it working, and it's unclear that it would help. > So IMO it is definitely something wrong on X server side. Even it it is > not my question stays .. Q: anyone working on fix this ? It's really hard to fix memory leaks you can't reproduce, and I've left X and firefox running for months on end without hitting this behaviour. - ajax From kloczek at zie.pg.gda.pl Thu Mar 1 19:59:24 2007 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Thu, 01 Mar 2007 20:59:24 +0100 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <1172777460.22136.134.camel@localhost.localdomain> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> <1172771344.22136.118.camel@localhost.localdomain> <1172773609.25356.9.camel@kloczek01.pracownicy.zie> <1172775669.32357.27.camel@localhost.localdomain> <1172777571.32335.11.camel@kloczek01.pracownicy.zie> <1172777460.22136.134.camel@localhost.localdomain> Message-ID: <1172779164.32335.20.camel@kloczek01.pracownicy.zie> Dnia 01-03-2007, czw o godzinie 14:31 -0500, Adam Jackson napisa?(a): [..] > It's really hard to fix memory leaks you can't reproduce, and I've left > X and firefox running for months on end without hitting this behaviour. Moment .. You can't reproduce this bug using my test case on refreshing pages with big pixmaps ? Are you try this on the same loaded modules set ? (maybe it is core of problem ?) Anyone else observe this kind buggy effects with growing X serer memory ? kloczek From opensource at till.name Thu Mar 1 20:11:14 2007 From: opensource at till.name (Till Maas) Date: Thu, 01 Mar 2007 21:11:14 +0100 Subject: [EPEL] Seperate Mailinglist for EPEL discussions In-Reply-To: <45E520DE.6030907@leemhuis.info> References: <45E475BB.1080806@leemhuis.info> <200702272224.01015.opensource@till.name> <45E520DE.6030907@leemhuis.info> Message-ID: <200703012111.36286.opensource@till.name> On Mittwoch 28 Februar 2007, Thorsten Leemhuis wrote: > I would have much preferred just a "epel" list for both users and > developers for now, to split out the developers list later *if* it > becomes to noisy. This sounds good, 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 ajackson at redhat.com Thu Mar 1 20:01:35 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 01 Mar 2007 15:01:35 -0500 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <1172779164.32335.20.camel@kloczek01.pracownicy.zie> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> <1172771344.22136.118.camel@localhost.localdomain> <1172773609.25356.9.camel@kloczek01.pracownicy.zie> <1172775669.32357.27.camel@localhost.localdomain> <1172777571.32335.11.camel@kloczek01.pracownicy.zie> <1172777460.22136.134.camel@localhost.localdomain> <1172779164.32335.20.camel@kloczek01.pracownicy.zie> Message-ID: <1172779295.22136.142.camel@localhost.localdomain> On Thu, 2007-03-01 at 20:59 +0100, Tomasz K?oczko wrote: > Dnia 01-03-2007, czw o godzinie 14:31 -0500, Adam Jackson napisa?(a): > [..] > > It's really hard to fix memory leaks you can't reproduce, and I've left > > X and firefox running for months on end without hitting this behaviour. > > Moment .. You can't reproduce this bug using my test case on refreshing > pages with big pixmaps ? Are you try this on the same loaded modules > set ? (maybe it is core of problem ?) Pick any given page on flickr, whack F5 for 10 minutes or so, no change in VSZ. I'm almost certain that your module set is irrelevant; you could verify this claim by deleting your Modules section, since it's autoconfigured now anyway. - ajax From opensource at till.name Thu Mar 1 20:20:43 2007 From: opensource at till.name (Till Maas) Date: Thu, 01 Mar 2007 21:20:43 +0100 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <200703011112.12348.jkeating@redhat.com> References: <200703011112.12348.jkeating@redhat.com> Message-ID: <200703012120.43328.opensource@till.name> On Donnerstag 01 M?rz 2007, Jesse Keating wrote: > System Level Changes > ======== > ? ? * Fedora 7 Test 2 features a 2.6.21rc1 based kernel. Current release > information is being tracked on the kernel release notes source page. > (http://fedoraproject.org/wiki/Docs/Beats/Kernel) | Kernel Flavors | | Fedora 7 test2 includes the following kernel builds: | | * kernel-PAE, for use in 32-bit x86 systems with > 4GB of RAM, or with CPUs | that have a 'NX (No eXecute)' feature. This kernel support both uniprocessor | and multi-processor systems. | * Virtualization kernel for use with the Xen emulator package. Configured | sources are available in the kernel-xen-devel-..rpm package. Afaik the xen kernel also enables PAE / NX, can anybody confirm this? And unless it gets fixed before the final F7 release, imho it should also be stressed that software suspend does not work with PAE / NX: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215396 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 ericm24x7 at gmail.com Thu Mar 1 20:41:49 2007 From: ericm24x7 at gmail.com (eric magaoay) Date: Thu, 01 Mar 2007 15:41:49 -0500 Subject: kernels oops - bug report In-Reply-To: <20070301132246.GA5813@lists.us.dell.com> References: <45E6175C.8040805@laposte.net> <20070301132246.GA5813@lists.us.dell.com> Message-ID: <45E73A8D.7050803@gmail.com> Matt Domsch wrote: > On Thu, Mar 01, 2007 at 12:59:24AM +0100, Axel wrote: > >> Hello >> I d like to report a kernel oops, but I don't know how to catch the >> kernel log. >> > > I highly recommend using serial console capturing for this. On the > crashing machine, use this on the kernel command line: > > console=ttyS0,115200 console=tty0 > I'm looking for ways to capture/dump kernel log through USB port and/or through LAN port. Any info on that would be appreciated. eric From egmont at uhulinux.hu Thu Mar 1 20:51:23 2007 From: egmont at uhulinux.hu (Egmont Koblinger) Date: Thu, 1 Mar 2007 21:51:23 +0100 Subject: Proposal: Convert .mo files to UTF-8 Message-ID: <20070301205123.GA17541@uhulinux.hu> Hi, I'd like to propose a small change that involves many Fedora packages. (First I thought I'd put it in bugzilla, but I don't know what the right component would be.) The proposed change is the following: when building RPM packages, let's convert all .mo files (gettext translations) to UTF-8. Why? - As Fedora is a fully UTF-8 system, applications are likely to request translations in UTF-8. (There might be a few applications that are exceptions, and some users may have special setup or special wrappers to run certain applications in some other charset, but in the vast majority of the cases gettext is required to return UTF-8 string.) If the .mo file is already in UTF-8, the gettext() call simply returns a pointer pointing somewhere in the area where the .mo file is mmap()ed to. This can simply be checked with strace. This way no run-time conversion happens and no per-proecess memory is involved; translations are shared by all the processes that use the same message catalog. If, however, .mo file uses a different encoding, gettext() has to allocate memory for the converted string and has to perform the conversion. This way if more processes display the same localized string, they all allocate their own memory area to store the UTF-8 version of the string and they all perform the charset conversion. And actually they all load the corresponding gconv module which could be avoided, too. To summarize, having all the .mo files in UTF-8 would save both memory and CPU time. - Currently the encoding of the .mo files is completely arbitrary; it is always what the software developers or the translators happened to use. With this change, it would be consistently UTF-8. This would make it easier to find which package ships a particular translation. It often happens that I want to locate which package a particular message comes from. It might happen because a word is misspelled, or because the whole message shouldn't appear and I'd like to fix the buggy package. The obvious solution is to do a recursive grep on /usr/share/locale/. If all the .mo files of the distribution are converted to UTF-8, I can do it simply, without having to worry about accented characters. (grep in UTF-8 mode works fine and finds the matching UTF-8 .mo files even though they are not fully valid UTF-8 files, the UTF-8 strings are surrounded by other binary data.) However, if multiple encodings are used, there is no straightforward way to find accented letters, it becomes a much harder job. How? - Due to RPM's flexibility, none of the packages needs to be modified, only the RPM macros. I recommend to perform the conversion on the .mo files after the '%install' step (in '%__install_post' or whatever it's called), this way this whole story is independent from the package's build procedure (does it use autotools or not; does it re-generate .mo files from .po or ships pre-built .mo files; no need to worry about faulty and hence skipped .po files; no need to take care of non-standard places of po/mo files within the source tree; etc...) - The only thing that needs to be done is an "msgunfmt" followed by "msgconv -t UTF-8" and finally "msgfmt" for all the .mo files under the standard locale directories. - So, after all, it is _very_ easy to implement it. Is it safe? - The encoding inside the .mo files is completely transparent to the applications as gettext() and its friends always convert the strings to the charset requested by the application. So applications won't notice any change. - We performed this step when building all the packages of the UHU-Linux 2.0 distribution, which was released a half year ago, and so far no known problems arised. (During the test period there was only 1 package (namely coreutils) where the converted .mo files were corrupted, but as it turned out, it was caused by a bug in msgunfmt in gettext-0.15, which is already fixed in gettext-0.16.) Any drawbacks? - Not known by me, except for a negligible growth in the packages' sizes. Well, I hope you like my idea :-) bye, Egmont From notting at redhat.com Thu Mar 1 20:54:47 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Mar 2007 15:54:47 -0500 Subject: Proposal: Convert .mo files to UTF-8 In-Reply-To: <20070301205123.GA17541@uhulinux.hu> References: <20070301205123.GA17541@uhulinux.hu> Message-ID: <20070301205447.GA29645@nostromo.devel.redhat.com> Egmont Koblinger (egmont at uhulinux.hu) said: > - The only thing that needs to be done is an "msgunfmt" followed by "msgconv > -t UTF-8" and finally "msgfmt" for all the .mo files under the standard > locale directories. > > - So, after all, it is _very_ easy to implement it. So, what this has the potential to do is encode the timestamp of this conversion in the final .mo file. Which then will cause multilib conflicts on package installs. Bill From hughsient at gmail.com Thu Mar 1 21:03:26 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 1 Mar 2007 21:03:26 +0000 Subject: Proposal: Convert .mo files to UTF-8 In-Reply-To: <20070301205447.GA29645@nostromo.devel.redhat.com> References: <20070301205123.GA17541@uhulinux.hu> <20070301205447.GA29645@nostromo.devel.redhat.com> Message-ID: <15e53e180703011303j2716436fy6420c2dd24447f43@mail.gmail.com> On 01/03/07, Bill Nottingham wrote: > Egmont Koblinger (egmont at uhulinux.hu) said: > > - The only thing that needs to be done is an "msgunfmt" followed by "msgconv > > -t UTF-8" and finally "msgfmt" for all the .mo files under the standard > > locale directories. > > > > - So, after all, it is _very_ easy to implement it. > > So, what this has the potential to do is encode the timestamp of this > conversion in the final .mo file. Which then will cause multilib conflicts > on package installs. Surely this sort of good idea should be done on much higher level than fedora? If this sort of thing is done in the automake type level then all the distros benefit, although I can't pretend that I understand all the msgfmt stuff. Richard. From kmaraas at broadpark.no Thu Mar 1 21:05:28 2007 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Thu, 01 Mar 2007 22:05:28 +0100 Subject: Proposal: Convert .mo files to UTF-8 In-Reply-To: <20070301205447.GA29645@nostromo.devel.redhat.com> References: <20070301205123.GA17541@uhulinux.hu> <20070301205447.GA29645@nostromo.devel.redhat.com> Message-ID: <1172783128.26327.0.camel@rivendell> tor, 01.03.2007 kl. 15.54 -0500, skrev Bill Nottingham: > Egmont Koblinger (egmont at uhulinux.hu) said: > > - The only thing that needs to be done is an "msgunfmt" followed by "msgconv > > -t UTF-8" and finally "msgfmt" for all the .mo files under the standard > > locale directories. > > > > - So, after all, it is _very_ easy to implement it. > > So, what this has the potential to do is encode the timestamp of this > conversion in the final .mo file. Which then will cause multilib conflicts > on package installs. > We've had a policy in the GNOME project that says all .po files should be UTF-8 encoded. Why not do it at that level so it has no chance of impacting packaging? Are there any reasons why translators would need a different encoding? Cheers Kjartan From notting at redhat.com Thu Mar 1 21:13:07 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Mar 2007 16:13:07 -0500 Subject: Proposal: Convert .mo files to UTF-8 In-Reply-To: <1172783128.26327.0.camel@rivendell> References: <20070301205123.GA17541@uhulinux.hu> <20070301205447.GA29645@nostromo.devel.redhat.com> <1172783128.26327.0.camel@rivendell> Message-ID: <20070301211307.GA31835@nostromo.devel.redhat.com> Kjartan Maraas (kmaraas at broadpark.no) said: > We've had a policy in the GNOME project that says all .po files should > be UTF-8 encoded. Why not do it at that level so it has no chance of > impacting packaging? Are there any reasons why translators would need a > different encoding? Other than potentially using cranky tools that only understand local charsets, I can't think of one. Heck, if someone wants this unilaterally done on all the i18n.redhat.com po files, it can happen. He he he. Bill From kzak at redhat.com Thu Mar 1 21:15:37 2007 From: kzak at redhat.com (Karel Zak) Date: Thu, 1 Mar 2007 22:15:37 +0100 Subject: announce: readahead-1.4 In-Reply-To: References: <20070301105026.GF4449@petra.dvoda.cz> Message-ID: <20070301211537.GH4449@petra.dvoda.cz> On Thu, Mar 01, 2007 at 12:34:12PM -0500, Tony Nelson wrote: > At 11:50 AM +0100 3/1/07, Karel Zak wrote: > ... > > I welcome your feedback! Send me your comments, ideas for > > enhancements or bug reports. > > Gitweb would like you to name the repository and give it an owner. Fixed. > The links to Bugzilla should probably not point to gnome-applet-vm. oops.. copy & past from my other project. Good catch. Thanks. Karel -- Karel Zak From egmont at uhulinux.hu Thu Mar 1 21:16:57 2007 From: egmont at uhulinux.hu (Egmont Koblinger) Date: Thu, 1 Mar 2007 22:16:57 +0100 Subject: Proposal: Convert .mo files to UTF-8 In-Reply-To: <1172783128.26327.0.camel@rivendell> References: <20070301205123.GA17541@uhulinux.hu> <20070301205447.GA29645@nostromo.devel.redhat.com> <1172783128.26327.0.camel@rivendell> Message-ID: <20070301211657.GB17541@uhulinux.hu> On Thu, Mar 01, 2007 at 10:05:28PM +0100, Kjartan Maraas wrote: > Are there any reasons why translators would need a different encoding? No, there isn't. But many translators or software developers still use other encodings nowadays, and there are stalling projects too. You can't get every software developer to convert .po files to UTF-8 and release a new mainstream version :( Still you want to have many of these software in Fedora... -- Egmont From jacliburn at bellsouth.net Thu Mar 1 21:19:25 2007 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Thu, 01 Mar 2007 15:19:25 -0600 Subject: kernels oops - bug report In-Reply-To: <45E72C8F.10903@gmail.com> References: <45E6175C.8040805@laposte.net> <20070301132246.GA5813@lists.us.dell.com> <1172776618.2839.0.camel@vader.jdub.homelinux.org> <45E72C8F.10903@gmail.com> Message-ID: <45E7435D.5050400@bellsouth.net> dragoran wrote: > my mobo does not have serial/parallel ports ... One of my motherboards doesn't have a DB9 on the rear connector panel, but it does have an internal serial port connector on the board itself, to which you can connect one of those PCI card-slot DB9 thingies. Like this: http://www.cablestogo.com/product.asp?cat%5fid=908&sku=28300 From tibbs at math.uh.edu Thu Mar 1 21:24:36 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 Mar 2007 15:24:36 -0600 Subject: kernels oops - bug report In-Reply-To: <45E73A8D.7050803@gmail.com> References: <45E6175C.8040805@laposte.net> <20070301132246.GA5813@lists.us.dell.com> <45E73A8D.7050803@gmail.com> Message-ID: >>>>> "em" == eric magaoay writes: em> I'm looking for ways to capture/dump kernel log through USB port em> and/or through LAN port. Well, there's netconsole, if it's supported by your hardware. Install the kernel-doc package and then read /usr/share/doc/kernel-doc-*/Documentation/networking/netconsole.txt - J< From notting at redhat.com Thu Mar 1 21:30:10 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Mar 2007 16:30:10 -0500 Subject: Proposal: Convert .mo files to UTF-8 In-Reply-To: <20070301211657.GB17541@uhulinux.hu> References: <20070301205123.GA17541@uhulinux.hu> <20070301205447.GA29645@nostromo.devel.redhat.com> <1172783128.26327.0.camel@rivendell> <20070301211657.GB17541@uhulinux.hu> Message-ID: <20070301213010.GA32113@nostromo.devel.redhat.com> Egmont Koblinger (egmont at uhulinux.hu) said: > > Are there any reasons why translators would need a different encoding? > > No, there isn't. But many translators or software developers still use other > encodings nowadays, and there are stalling projects too. You can't get every > software developer to convert .po files to UTF-8 and release a new > mainstream version :( Still you want to have many of these software in > Fedora... True, but at least for packages where Fedora is the upstream, might as well do it. There seem to be only 36 or so files that need fixed (out of 3900+). Bill From kzak at redhat.com Thu Mar 1 21:34:00 2007 From: kzak at redhat.com (Karel Zak) Date: Thu, 1 Mar 2007 22:34:00 +0100 Subject: announce: readahead-1.4 In-Reply-To: <20070301194008.GA11931@redhat.com> References: <20070301105026.GF4449@petra.dvoda.cz> <20070301194008.GA11931@redhat.com> Message-ID: <20070301213400.GI4449@petra.dvoda.cz> On Thu, Mar 01, 2007 at 02:40:08PM -0500, Dave Jones wrote: > On Thu, Mar 01, 2007 at 11:50:26AM +0100, Karel Zak wrote: > > > > I have just pushed out a new 1.4 version of the readahead util. > > The changes are: > > > > * move project to hosted.fedoraproject.org > > * source code maintained by GIT > > * various cleanups > > * new build-system based on autotools > > * --sort / --dont-sort support > > * add readahead-collector (based on audit system, > > requires audit-libs[-devel]) > > * improve init scripts (supports full, custom and fast mode) > > * add /etc/cron.daily/readahead.cron (with readahead --sort) > > > > Web page: > > > > https://hosted.fedoraproject.org/projects/readahead > > > > > > The code is not tested with FC7, because libauparse (from > > audit-libs-devel) is broken in FC7 now. > > > > If you want to generate your customized version of readahead lists > > you need to boot with "init=/sbin/readahead-collector". Also see > > /etc/readahead.conf and /usr/share/doc/readahead-1.4/README*. > > Out of curiousity, how much overhead would it add to always run > the collector without needing any boot arguments? I don't have any numbers (yet), but I expect that audit rules for all open(), stat(), ... have a negative performance impact for kernel. (Well, Steve Grubb added to CC:-) The second problem is that auditd removes all rules during start up. It doesn't assume that there is any other tool that use kernel audit system :-) (you need "chkconfig auditd off" now) I think for FC7 it's fine keep it for advanced uses only. I hope we will found a way how integrate the collector to distro. Maybe we will see better solution based on kernel -- for example fcache. Karel -- Karel Zak From linux_4ever at yahoo.com Thu Mar 1 22:03:41 2007 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 1 Mar 2007 14:03:41 -0800 (PST) Subject: announce: readahead-1.4 In-Reply-To: <20070301213400.GI4449@petra.dvoda.cz> Message-ID: <905461.4832.qm@web51505.mail.yahoo.com> > > The code is not tested with FC7, because libauparse (from > > audit-libs-devel) is broken in FC7 now. Right, audit 1.5 should be out soon and has the hidden variable problem fixed. If you link statically, I don't think there is a problem. Never-the-less 1.5 will be out soon. >I don't have any numbers (yet), but I expect that audit rules for all > open(), stat(), ... have a negative performance impact for kernel. Yes, they do have an impact. But depending on what's needed, they can probably be combined to 1 rule. > The second problem is that auditd removes all rules during start up. That can be fixed if we needed to. > I think for FC7 it's fine keep it for advanced uses only. I hope we will > found a way how integrate the collector to distro. Actually, I think we could probably fix this too, but may need some time to address a couple kernel problems that this would impose. We might want to change the audit rule evaluation strategy to do all rules rather than first match. This is so that the rules for boot monitoring won't interfere with rules for security monitoring. There might be a few other tweaks, too. -Steve ____________________________________________________________________________________ It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ From kmaraas at broadpark.no Thu Mar 1 23:08:57 2007 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Fri, 02 Mar 2007 00:08:57 +0100 Subject: Removal of obsolete norwegian =?iso-8859-1?q?bokm=E5l?= translations Message-ID: <1172790538.26327.9.camel@rivendell> Hi. I'd like to see all traces of no.po removed from the modules where fedora is upstream. These were replaced by nb.po a while back and I've added replacements to all modules AFAIR. You probably also have to remove traces of these in the build like ALL_LINGUAS in configure.in|ac etc. Cheers Kjartan From kzak at redhat.com Thu Mar 1 23:14:56 2007 From: kzak at redhat.com (Karel Zak) Date: Fri, 2 Mar 2007 00:14:56 +0100 Subject: announce: readahead-1.4 In-Reply-To: <905461.4832.qm@web51505.mail.yahoo.com> References: <20070301213400.GI4449@petra.dvoda.cz> <905461.4832.qm@web51505.mail.yahoo.com> Message-ID: <20070301231456.GJ4449@petra.dvoda.cz> On Thu, Mar 01, 2007 at 02:03:41PM -0800, Steve G wrote: > > > The code is not tested with FC7, because libauparse (from > > > audit-libs-devel) is broken in FC7 now. > > Right, audit 1.5 should be out soon and has the hidden variable problem fixed. If > you link statically, I don't think there is a problem. Never-the-less 1.5 will be > out soon. Cool. > >I don't have any numbers (yet), but I expect that audit rules for all > > open(), stat(), ... have a negative performance impact for kernel. > > Yes, they do have an impact. But depending on what's needed, they can probably be > combined to 1 rule. It's one rule: rc |= audit_rule_syscallbyname_data(audit_rule, "open"); rc |= audit_rule_syscallbyname_data(audit_rule, "creat"); rc |= audit_rule_syscallbyname_data(audit_rule, "truncate"); rc |= audit_rule_syscallbyname_data(audit_rule, "execve"); rc |= audit_rule_syscallbyname_data(audit_rule, "sendfile"); if (rc < 0) goto err; rc = audit_add_rule_data(rac->fd, audit_rule, AUDIT_FILTER_ENTRY, AUDIT_ALWAYS); I'll try to check it and prepare some numbers. Maybe it's really so fast. No clue now. > > I think for FC7 it's fine keep it for advanced uses only. I hope we will > > found a way how integrate the collector to distro. > > Actually, I think we could probably fix this too, but may need some time to > address a couple kernel problems that this would impose. We might want to change > the audit rule evaluation strategy to do all rules rather than first match. This > is so that the rules for boot monitoring won't interfere with rules for security > monitoring. There might be a few other tweaks, too. Sounds good. It's nothing urgent. Karel -- Karel Zak From notting at redhat.com Thu Mar 1 23:16:52 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Mar 2007 18:16:52 -0500 Subject: Removal of obsolete =?iso-8859-1?q?norwegian_bokm=E5l?= translations In-Reply-To: <1172790538.26327.9.camel@rivendell> References: <1172790538.26327.9.camel@rivendell> Message-ID: <20070301231652.GA5046@nostromo.devel.redhat.com> Kjartan Maraas (kmaraas at broadpark.no) said: > I'd like to see all traces of no.po removed from the modules where > fedora is upstream. These were replaced by nb.po a while back and I've > added replacements to all modules AFAIR. > > You probably also have to remove traces of these in the build like > ALL_LINGUAS in configure.in|ac etc. So, what would need to happen: 1) file bugs for everything that has 'no' in ALL_LINGUAS 2) move all translators that aren't signed up for 'nb' but are for 'no' over 3) nuke 'no' from the translation system 4) nuke the files 5) clean up the builds that fail :) I can do #2-#4, if someone wants to do #1. Bill From kmaraas at broadpark.no Thu Mar 1 23:53:13 2007 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Fri, 02 Mar 2007 00:53:13 +0100 Subject: Removal of obsolete norwegian =?iso-8859-1?q?bokm=E5l?= translations In-Reply-To: <20070301231652.GA5046@nostromo.devel.redhat.com> References: <1172790538.26327.9.camel@rivendell> <20070301231652.GA5046@nostromo.devel.redhat.com> Message-ID: <1172793193.26327.11.camel@rivendell> tor, 01.03.2007 kl. 18.16 -0500, skrev Bill Nottingham: > Kjartan Maraas (kmaraas at broadpark.no) said: > > I'd like to see all traces of no.po removed from the modules where > > fedora is upstream. These were replaced by nb.po a while back and I've > > added replacements to all modules AFAIR. > > > > You probably also have to remove traces of these in the build like > > ALL_LINGUAS in configure.in|ac etc. > > So, what would need to happen: > > 1) file bugs for everything that has 'no' in ALL_LINGUAS > 2) move all translators that aren't signed up for 'nb' but are > for 'no' over > 3) nuke 'no' from the translation system > 4) nuke the files > 5) clean up the builds that fail :) > > I can do #2-#4, if someone wants to do #1. > I'll start on #1 Cheers Kjartan From jonathan.underwood at gmail.com Fri Mar 2 01:21:09 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 2 Mar 2007 01:21:09 +0000 Subject: Plans for the (La)TeX stack for F7? In-Reply-To: <645d17210703010942k788d13c1v740e46156b86a3f3@mail.gmail.com> References: <645d17210703010436t59ed5eecpe04b7ed7cf6722b5@mail.gmail.com> <645d17210703010441h1d68f163l5cc32b4def354f4@mail.gmail.com> <645d17210703010859y5165324bue334e6f3afbcd8bf@mail.gmail.com> <645d17210703010942k788d13c1v740e46156b86a3f3@mail.gmail.com> Message-ID: <645d17210703011721q5a4961ffu2147a8874266aeb1@mail.gmail.com> On 01/03/07, Jonathan Underwood wrote: > On 01 Mar 2007 11:21:50 -0600, Jason L Tibbitts III wrote: > > Care to write up a draft in somewhere like > > http://fedoraproject.org/wiki/PackagingDrafts/TeXNaming so the > > packaging committee can consider it? > > OK, I will do shortly. > OK, I have collected a few thoughts on the matter (no firm proposal yet) at http://fedoraproject.org/wiki/PackagingDrafts/TeXNaming. Comments welcome - collect them on the wiki page. From dimitris at glezos.com Fri Mar 2 03:34:38 2007 From: dimitris at glezos.com (Dimitris Glezos) Date: Fri, 02 Mar 2007 03:34:38 +0000 Subject: Proposal: Convert .mo files to UTF-8 In-Reply-To: <20070301213010.GA32113@nostromo.devel.redhat.com> References: <20070301205123.GA17541@uhulinux.hu> <20070301205447.GA29645@nostromo.devel.redhat.com> <1172783128.26327.0.camel@rivendell> <20070301211657.GB17541@uhulinux.hu> <20070301213010.GA32113@nostromo.devel.redhat.com> Message-ID: <45E79B4E.5050109@glezos.com> O/H Bill Nottingham ??????: > Egmont Koblinger (egmont at uhulinux.hu) said: >>> Are there any reasons why translators would need a different encoding? >> No, there isn't. But many translators or software developers still use other >> encodings nowadays, and there are stalling projects too. You can't get every >> software developer to convert .po files to UTF-8 and release a new >> mainstream version :( Still you want to have many of these software in >> Fedora... > > True, but at least for packages where Fedora is the upstream, might > as well do it. There seem to be only 36 or so files that need fixed > (out of 3900+). For which packages is Fedora the upstream? -d -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From notting at redhat.com Fri Mar 2 04:11:08 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 1 Mar 2007 23:11:08 -0500 Subject: Proposal: Convert .mo files to UTF-8 In-Reply-To: <45E79B4E.5050109@glezos.com> References: <20070301205123.GA17541@uhulinux.hu> <20070301205447.GA29645@nostromo.devel.redhat.com> <1172783128.26327.0.camel@rivendell> <20070301211657.GB17541@uhulinux.hu> <20070301213010.GA32113@nostromo.devel.redhat.com> <45E79B4E.5050109@glezos.com> Message-ID: <20070302041108.GB29411@nostromo.devel.redhat.com> Dimitris Glezos (dimitris at glezos.com) said: > > True, but at least for packages where Fedora is the upstream, might > > as well do it. There seem to be only 36 or so files that need fixed > > (out of 3900+). > > For which packages is Fedora the upstream? system-config-*, anaconda, initscripts, various other things. :pserver:rhlinux.redhat.com:/usr/local/CVS translate will get you some sort of idea. Bill From ndbecker2 at gmail.com Fri Mar 2 02:03:00 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 01 Mar 2007 21:03:00 -0500 Subject: Plans for the (La)TeX stack for F7? References: <645d17210703010436t59ed5eecpe04b7ed7cf6722b5@mail.gmail.com> <645d17210703010441h1d68f163l5cc32b4def354f4@mail.gmail.com> <645d17210703010859y5165324bue334e6f3afbcd8bf@mail.gmail.com> <645d17210703010942k788d13c1v740e46156b86a3f3@mail.gmail.com> <645d17210703011721q5a4961ffu2147a8874266aeb1@mail.gmail.com> Message-ID: Jonathan Underwood wrote: > On 01/03/07, Jonathan Underwood wrote: >> On 01 Mar 2007 11:21:50 -0600, Jason L Tibbitts III >> wrote: >> > Care to write up a draft in somewhere like >> > http://fedoraproject.org/wiki/PackagingDrafts/TeXNaming so the >> > packaging committee can consider it? >> >> OK, I will do shortly. >> > > OK, I have collected a few thoughts on the matter (no firm proposal > yet) at http://fedoraproject.org/wiki/PackagingDrafts/TeXNaming. > Comments welcome - collect them on the wiki page. > +1 for your first set of proposals. BTW, what is a virtual provides? From fedora at leemhuis.info Fri Mar 2 06:02:25 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 02 Mar 2007 07:02:25 +0100 Subject: [EPEL] Seperate Mailinglist for EPEL discussions In-Reply-To: <200703012111.36286.opensource@till.name> References: <45E475BB.1080806@leemhuis.info> <200702272224.01015.opensource@till.name> <45E520DE.6030907@leemhuis.info> <200703012111.36286.opensource@till.name> Message-ID: <45E7BDF1.4000809@leemhuis.info> On 01.03.2007 21:11, Till Maas wrote: > On Mittwoch 28 Februar 2007, Thorsten Leemhuis wrote: >> I would have much preferred just a "epel" list for both users and >> developers for now, to split out the developers list later *if* it >> becomes to noisy. > This sounds good, Well, it's probably not worth the trouble to rename it now again (if you think it's worth the trouble speak up now and bug those people that created that list without discussing it in public beforehand (?)). I'd say we go for just make it a "epel" list during the mailing list reorganization (with is waiting for hardware to get installed -- that might take another two months two happen). Cu thl (?) -- yes there is a bitter tone in it From tonynelson at georgeanelson.com Fri Mar 2 06:07:05 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Fri, 2 Mar 2007 01:07:05 -0500 Subject: ( In-Reply-To: <20070301213400.GI4449@petra.dvoda.cz> References: <20070301105026.GF4449@petra.dvoda.cz> <20070301194008.GA11931@redhat.com> <20070301213400.GI4449@petra.dvoda.cz> Message-ID: At 10:34 PM +0100 3/1/07, Karel Zak wrote: >On Thu, Mar 01, 2007 at 02:40:08PM -0500, Dave Jones wrote: >> On Thu, Mar 01, 2007 at 11:50:26AM +0100, Karel Zak wrote: >> > >> > I have just pushed out a new 1.4 version of the readahead util. >> > The changes are: >> > >> > * move project to hosted.fedoraproject.org >> > * source code maintained by GIT >> > * various cleanups >> > * new build-system based on autotools >> > * --sort / --dont-sort support >> > * add readahead-collector (based on audit system, >> > requires audit-libs[-devel]) >> > * improve init scripts (supports full, custom and fast mode) >> > * add /etc/cron.daily/readahead.cron (with readahead --sort) >> > >> > Web page: >> > >> > https://hosted.fedoraproject.org/projects/readahead >> > >> > >> > The code is not tested with FC7, because libauparse (from >> > audit-libs-devel) is broken in FC7 now. >> > >> > If you want to generate your customized version of readahead lists >> > you need to boot with "init=/sbin/readahead-collector". Also see >> > /etc/readahead.conf and /usr/share/doc/readahead-1.4/README*. >> >> Out of curiousity, how much overhead would it add to always run >> the collector without needing any boot arguments? > > I don't have any numbers (yet), but I expect that audit rules for all > open(), stat(), ... have a negative performance impact for kernel. > > (Well, Steve Grubb added to CC:-) > > The second problem is that auditd removes all rules during start up. > It doesn't assume that there is any other tool that use kernel audit > system :-) (you need "chkconfig auditd off" now) Also, if it were to always run: Readahead-collector allocates memory in big chunks. It uses lots of memory -- when I ran it, 39 MB of /var/log/readahead-rac.log (which produced about .33 MB of /etc/readahead.d/custom.* -- but see bz 230687). (I note that readahead-collector will collect without limit, but that readahead will only use the first 32K entries.) Thus, while readahead-collect uses too much memory now to run every time, if it used a better data structure, say a balanced tree, and parsed the audit data into the tree as the data arrived, it could use about 2% of what is currently does. Neither program seems to take account of the memory used by the files that are read, though readahead can report it. (Possibly readahead-collect should avoid the largest files, as they probably aren't mostly used and don't cause so much seeking.) Readahead-collector runs for 5 minutes, so its output might need pruning if it ran each boot. When run manually, one knows to start stuff up and then wait for readahead to finish. BTW, the collection loop has a 30 second timeout that isn't being used. It might be reasonable to stop collecting if no event has come in in that time. If readahead-collect could run automatically, readahead might request it for the next boot if "too many" files are not found (say, after a firefox update). -- ____________________________________________________________________ TonyN.:' ' From petersen at redhat.com Fri Mar 2 06:58:22 2007 From: petersen at redhat.com (Jens Petersen) Date: Fri, 02 Mar 2007 16:58:22 +1000 Subject: [Fedora-i18n-list] Re: naming scheme for fonts packages? In-Reply-To: <1172732588.15284.12.camel@rousalka.dyndns.org> References: <45E54A39.7030104@redhat.com> <63347.192.54.193.51.1172657012.squirrel@rousalka.dyndns.org> <45E61058.1020801@redhat.com> <1172732588.15284.12.camel@rousalka.dyndns.org> Message-ID: <45E7CB0E.3030403@redhat.com> Nicolas Mailhot wrote: > A general font like DejaVu does lao, arabic (better support is waiting > on better opentype support pango & qt-side) aboriginal canadian > syllabics, armenian, greek, cyrillic so I don't think the "western only" > qualifier applies. Ok I don't know how many glyphs dejavu currently supports. But there is no coverage for CJK for example and CJK fonts are huge. > You just need to get people to work together, doing a > whole unicode block is no harder within an unicode font than within a > specific font (in fact it's easier since you don't have to redo latin > like all the asian fonts do now) True. I am all for it in principle. Not sure if everyone wants to have truetype fonts each over 30MB in size installed by default. It would certainly stop me having to worry about how we can have good international font coverage installed by default in Fedora. :) > That's the logical next step. It feels like putting kmail and evolution > in the same "MUA" package though. Can't you get by with a "Tibetan > support" comps group instead ? It will work with font packages crossing > langage boundaries, not force users to install every single font for one > langage (and in CJK countries that weights quite a lot), allow you to > follow two separate upstream release schedules, etc. Those are good points. Jens From kzak at redhat.com Fri Mar 2 08:50:55 2007 From: kzak at redhat.com (Karel Zak) Date: Fri, 2 Mar 2007 09:50:55 +0100 Subject: ( In-Reply-To: References: <20070301105026.GF4449@petra.dvoda.cz> <20070301194008.GA11931@redhat.com> <20070301213400.GI4449@petra.dvoda.cz> Message-ID: <20070302085055.GK4449@petra.dvoda.cz> On Fri, Mar 02, 2007 at 01:07:05AM -0500, Tony Nelson wrote: > Also, if it were to always run: > > Readahead-collector allocates memory in big chunks. It uses lots of memory > -- when I ran it, 39 MB of /var/log/readahead-rac.log (which produced about > .33 MB of /etc/readahead.d/custom.* -- but see bz 230687). (I note that > readahead-collector will collect without limit, but that readahead will > only use the first 32K entries.) Thus, while readahead-collect uses too > much memory now to run every time, if it used a better data structure, say > a balanced tree, and parsed the audit data into the tree as the data > arrived, it could use about 2% of what is currently does. It's not so easy. My first implementation has collected only paths, but this way is not reliable. You need to collect all events and parse it by libauparse, because every syscall produces three events (syscall, cwd and path) and the collector requires data from all three events. The order of events could be *random* and before parsing you need to all events for the syscall. I think a simple solution is reduce number of fields in events and store to memory simplificated event strings. I hope libauparse doesn't have care about number of fields. This way can save 80% of used memory (I think). I'll try to implement it. Frankly, I'm not sure if 30MB of RAM is so big problem in particular case that readahead is effective solution for machines where is a lot of memory for kernel cache. But you're right that there is a place for optimization. > Neither program seems to take account of the memory used by the files that > are read, though readahead can report it. (Possibly readahead-collect > should avoid the largest files, as they probably aren't mostly used and > don't cause so much seeking.) Any example of really large file (during boot)? > Readahead-collector runs for 5 minutes, so its output might need pruning if > it ran each boot. When run manually, one knows to start stuff up and then > wait for readahead to finish. BTW, the collection loop has a 30 second > timeout that isn't being used. It might be reasonable to stop collecting > if no event has come in in that time. Good idea, but I'm pessimistic that there is 30s when system doesn't call open() :-) > If readahead-collect could run automatically, readahead might request it > for the next boot if "too many" files are not found (say, after a firefox > update). Very good point. TODO updated: http://git.fedoraproject.org/?p=hosted/readahead;a=blob_plain;f=TODO;hb=HEAD Thanks. Karel -- Karel Zak From jeroen.janssen at gmail.com Fri Mar 2 09:29:01 2007 From: jeroen.janssen at gmail.com (Jeroen Janssen) Date: Fri, 2 Mar 2007 10:29:01 +0100 Subject: bugzilla version for fc7test2 bugs? Message-ID: Hello, I'm looking at the redhat bugzilla and I'm wondering what version to use for fc7test2 bugs. There is fc7test1, but no fc7test2. Should I use test2? Best regards, Jeroen Janssen. From buildsys at redhat.com Fri Mar 2 12:18:11 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Fri, 2 Mar 2007 07:18:11 -0500 Subject: rawhide report: 20070302 changes Message-ID: <200703021218.l22CIBHv001323@hs20-bc2-6.build.redhat.com> Removed package libofx Removed package gwenhywfar Removed package aqbanking Updated Packages: ConsoleKit-0.1.3-0.git20070301.fc7 ---------------------------------- * Thu Mar 01 2007 David Zeuthen - 0.1.3-0.git20070301 - Update to git snapshot - Drop all patches as they are committed upstream - New tool ck-list-sessions - New -libs subpackage with run-time libraries and a PAM module - New -devel subpackage with headers anaconda-11.2.0.28-1 -------------------- * Thu Mar 01 2007 Chris Lumens - 11.2.0.28-1 - Support multiple %ksappend lines (#222201). - Set the ksdata after setting the initial timezone values (#230472). - New progress screen interface that's easier on backends (katzj). - Handle KickstartError exns better than just dumping a backtrace. - Add an updates ks command. - Apply a patch to support RAID10 (Orion Poplawski , - Fix reserve-size option on splittree.py (katzj, #230343). - Apply a patch to clean up strings (Paul W. Frields , - Focus the next button when enter is pressed on the password screen (#206568). binutils-2.17.50.0.12-1 ----------------------- * Thu Mar 01 2007 Jakub Jelinek 2.17.50.0.12-1 - update to 2.17.50.0.12 - revert the misdesigned LD_SYMBOLIC{,_FUNCTIONS} env var support, only support -Bsymbolic/-Bsymbolic-functions/--dynamic-list* crypto-utils-2.3-2 ------------------ * Thu Mar 01 2007 Joe Orton 2.3-2 - various cleanups; require perl(Newt) throughout not newt-perl dejavu-lgc-fonts-2.15-1 ----------------------- * Thu Mar 01 2007 Behdad Esfahbod - 2.15-1 - Update to 2.15 - Define fontconffile and use it fonts-japanese-0.20061016-3.fc7 ------------------------------- * Thu Mar 01 2007 Akira TAGOH - 0.20061016-3 - cleanup spec file. - updated mplus to 2.2.4 * Fri Nov 24 2006 Akira TAGOH - 0.20061016-2 - added CIDFnmap.ja (#215980) * Fri Oct 27 2006 Akira TAGOH - 0.20061016-1 - correct U+7E6B. (#196433) kernel-2.6.20-1.2960.fc7 ------------------------ * Thu Mar 01 2007 John W. Linville - update git-wireless-dev.patch (current as of 2007-02-27) * Thu Mar 01 2007 Dave Jones - 2.6.21rc2-git1 * Wed Feb 28 2007 Dave Jones - reenable tickless on 32bit x86. libart_lgpl-2.3.19-2.fc7 ------------------------ * Thu Mar 01 2007 Behdad Esfahbod - 2.3.19-2 - Add upstreamed patch libart-2.3.19-header.patch - Resolves: #230571 logrotate-3.7.5-1.fc7 --------------------- * Thu Mar 01 2007 Peter Vrabec 3.7.5-1 - new upstream release. lsof-4.78-5.fc7 --------------- * Thu Mar 01 2007 Karel Zak 4.78-5 - fix License * Thu Mar 01 2007 Karel Zak 4.78-4 - fix #226108 - Merge Review: lsof mcstrans-0.2.5-1.fc7 -------------------- * Thu Mar 01 2007 Dan Walsh 0.2.5-1 - Fix case where s0="" newt-perl-1.08-14 ----------------- * Thu Mar 01 2007 Joe Orton 1.08-14 - various cleanups (Jason Tibbs, #226196) - require perl-devel * Tue Feb 27 2007 Joe Orton 1.08-13 - clean up URL, Source, BuildRoot, BuildRequires * Thu Dec 14 2006 Joe Orton 1.08-12 - fix test.pl (Charlie Brady, #181674) policycoreutils-2.0.7-1.fc7 --------------------------- * Thu Mar 01 2007 Dan Walsh 2.0.7-1 - Update to upstream * Merged restorecond init script LSB compliance patch from Steve Grubb. -sepolgen * Merged better matching for refpolicy style from Karl MacMillan * Merged support for extracting interface paramaters from interface calls from Karl MacMillan * Merged support for parsing USER_AVC audit messages from Karl MacMillan. poppler-0.5.4-7.fc7 ------------------- * Thu Mar 01 2007 Bill Nottingham - 0.5.4-7 - fix it so the qt pkgconfig/.so aren't in the main poppler-devel psmisc-22.3-1.fc7 ----------------- * Thu Mar 01 2007 Karel Zak 22.3-1 - update to upstream 22.3 - backport ipv6 bugfix from upstream CVS - clean up spec file rhpl-0.203-1 ------------ * Thu Mar 01 2007 Jeremy Katz - 0.203-1 - Fix pSeries detection (Jerone Young, #229231) vlock-1.3-25.fc7 ---------------- * Thu Mar 01 2007 Karel Zak - 1.3-25 - add missing -p to install calls * Thu Mar 01 2007 Karel Zak - 1.3-24 - fix #226530 - Merge Review: vlock vte-0.15.6-1.fc7 ---------------- * Thu Mar 01 2007 Behdad Esfahbod 0.15.6-1 - Update to 0.15.6 yum-3.1.3-1.fc7 --------------- * Thu Mar 01 2007 Jeremy Katz - 3.1.3-1 - update to 3.1.3 - add patch to fix a case where broken deps weren't detected correctly * Wed Feb 21 2007 Jeremy Katz - 3.1.2-1 - 3.1.2 * Wed Feb 14 2007 Jeremy Katz - 3.1.1-3 - learn about kernel-debug (#228709) Broken deps for ppc64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ppc64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.ppc64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ppc64 requires lm_sensors-devel Broken deps for i386 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.i386 requires libgcj.so.7rh frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh openoffice.org-langpack-af_ZA - 1:2.2.0-9.1.i386 requires hunspell-af openoffice.org-langpack-bg_BG - 1:2.2.0-9.1.i386 requires hunspell-bg openoffice.org-langpack-ca_ES - 1:2.2.0-9.1.i386 requires hunspell-ca openoffice.org-langpack-cy_GB - 1:2.2.0-9.1.i386 requires hunspell-cy openoffice.org-langpack-da_DK - 1:2.2.0-9.1.i386 requires hunspell-da openoffice.org-langpack-de - 1:2.2.0-9.1.i386 requires hunspell-de openoffice.org-langpack-el_GR - 1:2.2.0-9.1.i386 requires hunspell-el openoffice.org-langpack-es - 1:2.2.0-9.1.i386 requires hunspell-es openoffice.org-langpack-et_EE - 1:2.2.0-9.1.i386 requires hunspell-ee openoffice.org-langpack-fr - 1:2.2.0-9.1.i386 requires hunspell-fr openoffice.org-langpack-ga_IE - 1:2.2.0-9.1.i386 requires hunspell-ga openoffice.org-langpack-gl_ES - 1:2.2.0-9.1.i386 requires hunspell-gl openoffice.org-langpack-he_IL - 1:2.2.0-9.1.i386 requires hunspell-he openoffice.org-langpack-hr_HR - 1:2.2.0-9.1.i386 requires hunspell-hr openoffice.org-langpack-hu_HU - 1:2.2.0-9.1.i386 requires hunspell-hu openoffice.org-langpack-it - 1:2.2.0-9.1.i386 requires hunspell-it openoffice.org-langpack-lt_LT - 1:2.2.0-9.1.i386 requires hunspell-lt openoffice.org-langpack-ms_MY - 1:2.2.0-9.1.i386 requires hunspell-ms openoffice.org-langpack-nb_NO - 1:2.2.0-9.1.i386 requires hunspell-nb openoffice.org-langpack-nl - 1:2.2.0-9.1.i386 requires hunspell-nl openoffice.org-langpack-nn_NO - 1:2.2.0-9.1.i386 requires hunspell-nn openoffice.org-langpack-pl_PL - 1:2.2.0-9.1.i386 requires hunspell-pl openoffice.org-langpack-pt_BR - 1:2.2.0-9.1.i386 requires hunspell-pt openoffice.org-langpack-pt_PT - 1:2.2.0-9.1.i386 requires hunspell-pt openoffice.org-langpack-ru - 1:2.2.0-9.1.i386 requires hunspell-ru openoffice.org-langpack-sk_SK - 1:2.2.0-9.1.i386 requires hunspell-sk openoffice.org-langpack-sl_SI - 1:2.2.0-9.1.i386 requires hunspell-sl openoffice.org-langpack-sv - 1:2.2.0-9.1.i386 requires hunspell-sv openoffice.org-langpack-th_TH - 1:2.2.0-9.1.i386 requires hunspell-th openoffice.org-langpack-zu_ZA - 1:2.2.0-9.1.i386 requires hunspell-zu Broken deps for s390 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.s390 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel 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 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.i386 requires libgcj.so.7rh cairo-java - 1.0.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.x86_64 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libgconf-java - 2.12.4-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh openoffice.org-langpack-af_ZA - 1:2.2.0-9.1.x86_64 requires hunspell-af openoffice.org-langpack-bg_BG - 1:2.2.0-9.1.x86_64 requires hunspell-bg openoffice.org-langpack-ca_ES - 1:2.2.0-9.1.x86_64 requires hunspell-ca openoffice.org-langpack-cy_GB - 1:2.2.0-9.1.x86_64 requires hunspell-cy openoffice.org-langpack-da_DK - 1:2.2.0-9.1.x86_64 requires hunspell-da openoffice.org-langpack-de - 1:2.2.0-9.1.x86_64 requires hunspell-de openoffice.org-langpack-el_GR - 1:2.2.0-9.1.x86_64 requires hunspell-el openoffice.org-langpack-es - 1:2.2.0-9.1.x86_64 requires hunspell-es openoffice.org-langpack-et_EE - 1:2.2.0-9.1.x86_64 requires hunspell-ee openoffice.org-langpack-fr - 1:2.2.0-9.1.x86_64 requires hunspell-fr openoffice.org-langpack-ga_IE - 1:2.2.0-9.1.x86_64 requires hunspell-ga openoffice.org-langpack-gl_ES - 1:2.2.0-9.1.x86_64 requires hunspell-gl openoffice.org-langpack-he_IL - 1:2.2.0-9.1.x86_64 requires hunspell-he openoffice.org-langpack-hr_HR - 1:2.2.0-9.1.x86_64 requires hunspell-hr openoffice.org-langpack-hu_HU - 1:2.2.0-9.1.x86_64 requires hunspell-hu openoffice.org-langpack-it - 1:2.2.0-9.1.x86_64 requires hunspell-it openoffice.org-langpack-lt_LT - 1:2.2.0-9.1.x86_64 requires hunspell-lt openoffice.org-langpack-ms_MY - 1:2.2.0-9.1.x86_64 requires hunspell-ms openoffice.org-langpack-nb_NO - 1:2.2.0-9.1.x86_64 requires hunspell-nb openoffice.org-langpack-nl - 1:2.2.0-9.1.x86_64 requires hunspell-nl openoffice.org-langpack-nn_NO - 1:2.2.0-9.1.x86_64 requires hunspell-nn openoffice.org-langpack-pl_PL - 1:2.2.0-9.1.x86_64 requires hunspell-pl openoffice.org-langpack-pt_BR - 1:2.2.0-9.1.x86_64 requires hunspell-pt openoffice.org-langpack-pt_PT - 1:2.2.0-9.1.x86_64 requires hunspell-pt openoffice.org-langpack-ru - 1:2.2.0-9.1.x86_64 requires hunspell-ru openoffice.org-langpack-sk_SK - 1:2.2.0-9.1.x86_64 requires hunspell-sk openoffice.org-langpack-sl_SI - 1:2.2.0-9.1.x86_64 requires hunspell-sl openoffice.org-langpack-sv - 1:2.2.0-9.1.x86_64 requires hunspell-sv openoffice.org-langpack-th_TH - 1:2.2.0-9.1.x86_64 requires hunspell-th openoffice.org-langpack-zu_ZA - 1:2.2.0-9.1.x86_64 requires hunspell-zu Broken deps for ppc ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ppc requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.ppc requires libofx.so.3 gnucash - 2.0.5-1.fc6.ppc requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.ppc requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.ppc requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.ppc requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.ppc requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.ppc requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.ppc requires lm_sensors-devel openoffice.org-langpack-af_ZA - 1:2.2.0-9.1.ppc requires hunspell-af openoffice.org-langpack-bg_BG - 1:2.2.0-9.1.ppc requires hunspell-bg openoffice.org-langpack-ca_ES - 1:2.2.0-9.1.ppc requires hunspell-ca openoffice.org-langpack-cy_GB - 1:2.2.0-9.1.ppc requires hunspell-cy openoffice.org-langpack-da_DK - 1:2.2.0-9.1.ppc requires hunspell-da openoffice.org-langpack-de - 1:2.2.0-9.1.ppc requires hunspell-de openoffice.org-langpack-el_GR - 1:2.2.0-9.1.ppc requires hunspell-el openoffice.org-langpack-es - 1:2.2.0-9.1.ppc requires hunspell-es openoffice.org-langpack-et_EE - 1:2.2.0-9.1.ppc requires hunspell-ee openoffice.org-langpack-fr - 1:2.2.0-9.1.ppc requires hunspell-fr openoffice.org-langpack-ga_IE - 1:2.2.0-9.1.ppc requires hunspell-ga openoffice.org-langpack-gl_ES - 1:2.2.0-9.1.ppc requires hunspell-gl openoffice.org-langpack-he_IL - 1:2.2.0-9.1.ppc requires hunspell-he openoffice.org-langpack-hr_HR - 1:2.2.0-9.1.ppc requires hunspell-hr openoffice.org-langpack-hu_HU - 1:2.2.0-9.1.ppc requires hunspell-hu openoffice.org-langpack-it - 1:2.2.0-9.1.ppc requires hunspell-it openoffice.org-langpack-lt_LT - 1:2.2.0-9.1.ppc requires hunspell-lt openoffice.org-langpack-ms_MY - 1:2.2.0-9.1.ppc requires hunspell-ms openoffice.org-langpack-nb_NO - 1:2.2.0-9.1.ppc requires hunspell-nb openoffice.org-langpack-nl - 1:2.2.0-9.1.ppc requires hunspell-nl openoffice.org-langpack-nn_NO - 1:2.2.0-9.1.ppc requires hunspell-nn openoffice.org-langpack-pl_PL - 1:2.2.0-9.1.ppc requires hunspell-pl openoffice.org-langpack-pt_BR - 1:2.2.0-9.1.ppc requires hunspell-pt openoffice.org-langpack-pt_PT - 1:2.2.0-9.1.ppc requires hunspell-pt openoffice.org-langpack-ru - 1:2.2.0-9.1.ppc requires hunspell-ru openoffice.org-langpack-sk_SK - 1:2.2.0-9.1.ppc requires hunspell-sk openoffice.org-langpack-sl_SI - 1:2.2.0-9.1.ppc requires hunspell-sl openoffice.org-langpack-sv - 1:2.2.0-9.1.ppc requires hunspell-sv openoffice.org-langpack-th_TH - 1:2.2.0-9.1.ppc requires hunspell-th openoffice.org-langpack-zu_ZA - 1:2.2.0-9.1.ppc requires hunspell-zu Broken deps for ia64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ia64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ia64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.ia64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ia64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ia64 requires lm_sensors-devel Broken deps for s390x ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.s390x requires libgcj.so.7rh()(64bit) cairo-java - 1.0.5-4.fc7.s390 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.s390x requires libofx.so.3()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.s390x requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390x requires libgcj.so.7rh()(64bit) libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390x requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.s390x requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.s390x requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390x requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.s390x requires lm_sensors-devel net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel From denis at poolshark.org Fri Mar 2 12:35:23 2007 From: denis at poolshark.org (Denis Leroy) Date: Fri, 02 Mar 2007 13:35:23 +0100 Subject: Issues with rawhide mptspi module In-Reply-To: <45E6DDBA.9020305@odu.neva.ru> References: <45E6DA27.80904@poolshark.org> <45E6DDBA.9020305@odu.neva.ru> Message-ID: <45E81A0B.9090001@poolshark.org> Dmitry Butskoy wrote: > Denis Leroy wrote: >> Is anyone else having issues with the LSI Fusion SPI host driver >> (mptspi.ko) on rawhide ? >> >> rawhide is running as VMware guest OS. mptspi loads but fails to >> correctly scan any of the connected disk. I had to change the VM disk >> from scsi/lsilogic to an ide drive to be able to boot. I'll check with >> the VMWare folks as well. >> >> -denis >> > Yeah... > Since 2.6.17 :( > > http://bugzilla.redhat.com/bugzilla/200787 > http://bugzilla.redhat.com/bugzilla/208033 I read through those bug reports, but this is not what I'm seeing. In my case, mptspi detects the SCSI host controller, but simply doesn't see any disks attached. I have no problems with the latest FC-6 kernel (2.6.19). It's only the FC-7 kernel. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230703 From jkeating at redhat.com Fri Mar 2 13:00:30 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 2 Mar 2007 08:00:30 -0500 Subject: bugzilla version for fc7test2 bugs? In-Reply-To: References: Message-ID: <200703020800.36747.jkeating@redhat.com> On Friday 02 March 2007 04:29:01 Jeroen Janssen wrote: > I'm looking at the redhat bugzilla and I'm wondering what version to > use for fc7test2 bugs. > There is fc7test1, but no fc7test2. Should I use test2? Use devel please. Especially if you can reproduce with the latest package set from rawhide/extras devel. -- 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 linux_4ever at yahoo.com Fri Mar 2 13:59:31 2007 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 2 Mar 2007 05:59:31 -0800 (PST) Subject: ( In-Reply-To: <20070302085055.GK4449@petra.dvoda.cz> Message-ID: <367624.24777.qm@web51514.mail.yahoo.com> > I think a simple solution is reduce number of fields in events and > store to memory simplificated event strings. Yes. Use libauparse to get the 3 fields and just store those in another data structure. -Steve ____________________________________________________________________________________ TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ From linux_4ever at yahoo.com Fri Mar 2 14:09:38 2007 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 2 Mar 2007 06:09:38 -0800 (PST) Subject: announce: readahead-1.4 In-Reply-To: <20070301231456.GJ4449@petra.dvoda.cz> Message-ID: <639506.74795.qm@web51510.mail.yahoo.com> > It's one rule: > > rc |= audit_rule_syscallbyname_data(audit_rule, "open"); > rc |= audit_rule_syscallbyname_data(audit_rule, "creat"); > rc |= audit_rule_syscallbyname_data(audit_rule, "truncate"); > rc |= audit_rule_syscallbyname_data(audit_rule, "execve"); > rc |= audit_rule_syscallbyname_data(audit_rule, "sendfile"); I think you are missing some events. I added a feature to autrace to help with threat modeling. (The idea is run your program with autrace -r, exercise it, extract audit data, and feed that to UML diagrammer.) I would suggest using code similar to the threat model: rc |= audit_rule_syscallbyname_data(rule, "open"); rc |= audit_rule_syscallbyname_data(rule, "creat"); rc |= audit_rule_syscallbyname_data(rule, "truncate"); rc |= audit_rule_syscallbyname_data(rule, "rename"); rc |= audit_rule_syscallbyname_data(rule, "unlink"); rc |= audit_rule_syscallbyname_data(rule, "mknod"); rc |= audit_rule_syscallbyname_data(rule, "mkdir"); rc |= audit_rule_syscallbyname_data(rule, "rmdir"); rc |= audit_rule_syscallbyname_data(rule, "chdir"); rc |= audit_rule_syscallbyname_data(rule, "chown"); rc |= audit_rule_syscallbyname_data(rule, "lchown"); rc |= audit_rule_syscallbyname_data(rule, "chmod"); rc |= audit_rule_syscallbyname_data(rule, "link"); rc |= audit_rule_syscallbyname_data(rule, "symlink"); rc |= audit_rule_syscallbyname_data(rule, "readlink"); rc |= audit_rule_syscallbyname_data(rule, "execve"); rc |= audit_rule_syscallbyname_data(rule, "connect"); rc |= audit_rule_syscallbyname_data(rule, "bind"); rc |= audit_rule_syscallbyname_data(rule, "accept"); rc |= audit_rule_syscallbyname_data(rule, "sendto"); rc |= audit_rule_syscallbyname_data(rule, "recvfrom"); rc |= audit_rule_syscallbyname_data(rule, "sendfile"); which admittedly does not contain the *at syscalls. The threat model is so that you can see all the boundaries/resources that your apps are using. You could turn off the networking, mknod, & mkdir if you like. > I'll try to check it and prepare some numbers. Maybe it's really so > fast. No clue now. 1 rule is not a big deal. -Steve ____________________________________________________________________________________ Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front From pknirsch at redhat.com Fri Mar 2 15:33:19 2007 From: pknirsch at redhat.com (Phil Knirsch) Date: Fri, 02 Mar 2007 16:33:19 +0100 Subject: Installation order of basesystem, filesystem and setup. Message-ID: <45E843BF.4080201@redhat.com> Hi folks. During the review of basesystem we came upon a rather interesting fact which some might already have seen and wondered about. The packages basesystem, filesystem and setup have a rather odd and not necessarily intuitive dependency order: basesystem Requires: filesystem setup filesystem Requires: setup setup Requires: (nothing) So the final install order after properly ordering those is: setup filesystem basesystem which imo is exactly the opposite of what i'd expect. Take the description of basesystem e.g. where it explicitly says: "Basesystem should be the first package installed on a system, and it should never be removed." And for filesystem: "Filesystem contains the basic directory layout for a Linux operating system, including the correct permissions for the directories." So imo the order should be: basesystem filesystem setup Currently the way to get basesystem always pulled in (and thereby filesystem and setup) is by having a: glibc Requires: basesystem Now the question is, do we just keep it this way and ignore the fact that those 3 packages are installed in the wrong order (without actually affecting anything as they are installed even before glibc) or do we want to fix it? The simple fix would be to turn around the requirement order and let glibc require setup instead: glibc Requires: setup setup Requires: filesystem filesystem Requires: basesystem Any thoughts? Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From galibert at pobox.com Fri Mar 2 15:37:03 2007 From: galibert at pobox.com (Olivier Galibert) Date: Fri, 2 Mar 2007 16:37:03 +0100 Subject: Kernel 2.6.19 squashfs problem and bugzilla Message-ID: <20070302153703.GA7038@dspnet.fr.eu.org> The kernel from kernel-2.6.19-1.2288.fc5.x86_64.rpm is not able to loop-mount the fc5 install Fedora/base/stage2.img file, at least through nfs. You get: squashfs: version 3.2-alpha (2006/12/12) Phillip Lougher SQUASHFS error: sb_bread failed reading block 0x9e8be8e1 SQUASHFS error: unable to read inode lookup table As for bugzilla, I was wondering where to file that one, would it be bugzilla.redhat.com or bugzilla.fedora.us? And if the latter, is it going to actually work any time soon? I don't think I've ever been able to contact it. OG. From jakub at redhat.com Fri Mar 2 15:40:04 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 2 Mar 2007 10:40:04 -0500 Subject: Installation order of basesystem, filesystem and setup. In-Reply-To: <45E843BF.4080201@redhat.com> References: <45E843BF.4080201@redhat.com> Message-ID: <20070302154004.GX355@devserv.devel.redhat.com> On Fri, Mar 02, 2007 at 04:33:19PM +0100, Phil Knirsch wrote: > During the review of basesystem we came upon a rather interesting fact > which some might already have seen and wondered about. > > The packages basesystem, filesystem and setup have a rather odd and not > necessarily intuitive dependency order: > > basesystem Requires: filesystem setup > filesystem Requires: setup > setup Requires: (nothing) > > So the final install order after properly ordering those is: > > setup > filesystem > basesystem > > which imo is exactly the opposite of what i'd expect. Take the > description of basesystem e.g. where it explicitly says: > > "Basesystem should be the first package installed on a system, and it > should never be removed." > > And for filesystem: > > "Filesystem contains the basic directory layout for a Linux operating > system, including the correct permissions for the directories." > > So imo the order should be: > > basesystem > filesystem > setup Well, basesystem contains no files at all and only contains the requires for filesystem/setup, so if you remove the requires, the package is completely useless. Jakub From jkeating at redhat.com Fri Mar 2 15:42:44 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 2 Mar 2007 10:42:44 -0500 Subject: Installation order of basesystem, filesystem and setup. In-Reply-To: <45E843BF.4080201@redhat.com> References: <45E843BF.4080201@redhat.com> Message-ID: <200703021042.44445.jkeating@redhat.com> On Friday 02 March 2007 10:33:19 Phil Knirsch wrote: > basesystem Requires: filesystem setup > filesystem Requires: setup > setup Requires: (nothing) > > So the final install order after properly ordering those is: > > setup > filesystem > basesystem Requires doesn't do much for ordering. The %post / %pre requires or PreReq: do help for ordering. Since basesystem has no files, there probably isn't any need for it to be installed before anything else, it just needs to be in the same transaction with the things that require it. -- 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 mls at suse.de Fri Mar 2 16:06:27 2007 From: mls at suse.de (Michael Schroeder) Date: Fri, 2 Mar 2007 17:06:27 +0100 Subject: Installation order of basesystem, filesystem and setup. In-Reply-To: <200703021042.44445.jkeating@redhat.com> References: <45E843BF.4080201@redhat.com> <200703021042.44445.jkeating@redhat.com> Message-ID: <20070302160627.GA12143@suse.de> On Fri, Mar 02, 2007 at 10:42:44AM -0500, Jesse Keating wrote: > Requires doesn't do much for ordering. The %post / %pre requires or PreReq: > do help for ordering. Not true, rpm uses requires and prereqs for ordering purposes. Cheers, Michael. -- Michael Schroeder mls at suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} From jkeating at redhat.com Fri Mar 2 16:35:46 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 2 Mar 2007 11:35:46 -0500 Subject: Installation order of basesystem, filesystem and setup. In-Reply-To: <20070302160627.GA12143@suse.de> References: <45E843BF.4080201@redhat.com> <200703021042.44445.jkeating@redhat.com> <20070302160627.GA12143@suse.de> Message-ID: <200703021135.46733.jkeating@redhat.com> On Friday 02 March 2007 11:06:27 Michael Schroeder wrote: > Not true, rpm uses requires and prereqs for ordering purposes. Ok, let me clarify. A plain Requires: doesn't guarantee that the Required package will be installed before the package Requiring it. It just means it either needs to be there before hand, or in the same transaction. Things like %post/%pre requires and PreReq help rpm in ordering the transaction to make sure the the things that are needed at install time are actually there, vs things needed at runtime. -- 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 pknirsch at redhat.com Fri Mar 2 16:55:19 2007 From: pknirsch at redhat.com (Phil Knirsch) Date: Fri, 02 Mar 2007 17:55:19 +0100 Subject: Installation order of basesystem, filesystem and setup. In-Reply-To: <200703021135.46733.jkeating@redhat.com> References: <45E843BF.4080201@redhat.com> <200703021042.44445.jkeating@redhat.com> <20070302160627.GA12143@suse.de> <200703021135.46733.jkeating@redhat.com> Message-ID: <45E856F7.4040502@redhat.com> Jesse Keating wrote: > On Friday 02 March 2007 11:06:27 Michael Schroeder wrote: >> Not true, rpm uses requires and prereqs for ordering purposes. > > Ok, let me clarify. A plain Requires: doesn't guarantee that the Required > package will be installed before the package Requiring it. It just means it > either needs to be there before hand, or in the same transaction. Things > like %post/%pre requires and PreReq help rpm in ordering the transaction to > make sure the the things that are needed at install time are actually there, > vs things needed at runtime. > > Well, current rpm code as it is still honors this, Jesse, and i think thats what Michael just wanted to point out. Simple Require chains will get ordered properly today in rpm and should in any future version of it too (Although stricktly speak you're of course right. Only any pre requires need to be absolutely followed as otherwise during installation things will go badly wrong). I don't wanna beat a dead horse here and i'm certainly not biased to any form of proper order we're installing basesystem, filesystem and setup here. I was just surprised that the Requires were setup in like this between the those packages in that order (as was the package reviewer of basesystem) with a description like that in basesystem. I'd wouldn't have any problems dropping basesystem and just keeping filesystem and setup either. Or just leave it everything as it is. I just wanted to bring this up during the review of basesystem as both my reviewer and myself found it a little wierd that "first package installed on a system" actually could never be the first package actively installed. Final option ofc would be to just change the description ofc (doh!) and be done with it. Like: Basesystem defines the components of a basic Fedora system (for example, the package installation order to use during bootstrapping). Basesystem should be in every installation of a system, and it should never be removed. How's that? Read ya, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From mls at suse.de Fri Mar 2 16:40:44 2007 From: mls at suse.de (Michael Schroeder) Date: Fri, 2 Mar 2007 17:40:44 +0100 Subject: Installation order of basesystem, filesystem and setup. In-Reply-To: <200703021135.46733.jkeating@redhat.com> References: <45E843BF.4080201@redhat.com> <200703021042.44445.jkeating@redhat.com> <20070302160627.GA12143@suse.de> <200703021135.46733.jkeating@redhat.com> Message-ID: <20070302164044.GA31429@suse.de> On Fri, Mar 02, 2007 at 11:35:46AM -0500, Jesse Keating wrote: > Ok, let me clarify. A plain Requires: doesn't guarantee that the Required > package will be installed before the package Requiring it. It just means it > either needs to be there before hand, or in the same transaction. Things > like %post/%pre requires and PreReq help rpm in ordering the transaction to > make sure the the things that are needed at install time are actually there, > vs things needed at runtime. Well, it's just so that rpm treats PreReqs and Requires pretty much the same, the only difference is when there is a dependency cycles. And dependency cycles with PreReqs aren't installable at all, so there really is no difference... Cheers, Michael. -- Michael Schroeder mls at suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} From kevin.verma at gmail.com Fri Mar 2 16:57:12 2007 From: kevin.verma at gmail.com (Anuj Verma (Kevin)) Date: Fri, 2 Mar 2007 16:57:12 +0000 (UTC) Subject: Lcars Standards for Star Trek fan developers Message-ID: Hello, While following on an issue for Lcars Padd theme for Nokia N800 and then following with Lcars GDM & GTK1 theme, I came across - http:// lcarsdeveloper.com/ I hope few of you will sure enjoy this one. Cheers, Kevin From jkeating at redhat.com Fri Mar 2 17:16:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 2 Mar 2007 12:16:36 -0500 Subject: Reduction of Fedora releases Message-ID: <200703021216.39477.jkeating@redhat.com> In an effort to make Bugzilla easier to use, we've been experimenting with not creating new versions of Fedora for every test release. Reason being is that the typical response to a bug filed against a test release is a request to duplicate it with the current development package set. It also makes it harder for a user to find dups of a bug they're about to file if they have to search through N testN versions. Instead we're asking all bugs encountered in test releases to be filed against devel. (yes you may still get asked to repro with current devel packages, but at least the bug will be assigned to the right release then). I didn't communicate this experiment clearly last time around and an fc7test1 bugzilla version got created. We're killing that and moving all the bugs to the devel version. -- 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 notting at redhat.com Fri Mar 2 17:15:39 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 Mar 2007 12:15:39 -0500 Subject: Installation order of basesystem, filesystem and setup. In-Reply-To: <45E856F7.4040502@redhat.com> References: <45E843BF.4080201@redhat.com> <200703021042.44445.jkeating@redhat.com> <20070302160627.GA12143@suse.de> <200703021135.46733.jkeating@redhat.com> <45E856F7.4040502@redhat.com> Message-ID: <20070302171539.GC9050@nostromo.devel.redhat.com> Phil Knirsch (pknirsch at redhat.com) said: > Final option ofc would be to just change the description ofc (doh!) and > be done with it. > > Like: > > Basesystem defines the components of a basic Fedora system (for > example, the package installation order to use during bootstrapping). > Basesystem should be in every installation of a system, and it > should never be removed. > > How's that? I like that solution. Don't touch the seven deadly packages! Bill From jerone at gmail.com Fri Mar 2 19:16:12 2007 From: jerone at gmail.com (Jerone Young) Date: Fri, 2 Mar 2007 13:16:12 -0600 Subject: Todays Anaconda is broken...breaking Fedora installer In-Reply-To: <9f50a7a00703021107o6eed1b70g78a9bbae3746808d@mail.gmail.com> References: <9f50a7a00703021107o6eed1b70g78a9bbae3746808d@mail.gmail.com> Message-ID: <9f50a7a00703021116i4d30d12bk3c1068139d6a5071@mail.gmail.com> Taking a quick took at the code. The problem is there should be a ")" and not a ":" at the end. On 3/2/07, Jerone Young wrote: > Seems like an extra ":" was added by accident. Don't have the source > in front of me but here is the back trace. > > unning anaconda, the Fedora Core system installer - please wait... > Traceback (most recent call last): > File "/usr/bin/anaconda", line 564, in > from exception import handleException > File "/usr/lib/anaconda/exception.py", line 33, in > import kickstart > File "/usr/lib/anaconda/kickstart.py", line 18, in > from autopart import * > File "/usr/lib/anaconda/autopart.py", line 19, in > import fsset > File "/usr/lib/anaconda/fsset.py", line 28, in > import partedUtils > File "/usr/lib/anaconda/partedUtils.py", line 27, in > import raid > File "/usr/lib/anaconda/raid.py", line 192 > isRaid10(raidLevel): > ^ > SyntaxError: invalid syntax > install exited abnormally [1/1] > From jerone at gmail.com Fri Mar 2 19:17:05 2007 From: jerone at gmail.com (Jerone Young) Date: Fri, 2 Mar 2007 13:17:05 -0600 Subject: Todays Anaconda is broken...breaking Fedora installer In-Reply-To: <9f50a7a00703021116i4d30d12bk3c1068139d6a5071@mail.gmail.com> References: <9f50a7a00703021107o6eed1b70g78a9bbae3746808d@mail.gmail.com> <9f50a7a00703021116i4d30d12bk3c1068139d6a5071@mail.gmail.com> Message-ID: <9f50a7a00703021117s5fd15985pb67d49efd828974e@mail.gmail.com> I meant it needs a ")". On 3/2/07, Jerone Young wrote: > Taking a quick took at the code. The problem is there should be a ")" > and not a ":" at the end. > > On 3/2/07, Jerone Young wrote: > > Seems like an extra ":" was added by accident. Don't have the source > > in front of me but here is the back trace. > > > > unning anaconda, the Fedora Core system installer - please wait... > > Traceback (most recent call last): > > File "/usr/bin/anaconda", line 564, in > > from exception import handleException > > File "/usr/lib/anaconda/exception.py", line 33, in > > import kickstart > > File "/usr/lib/anaconda/kickstart.py", line 18, in > > from autopart import * > > File "/usr/lib/anaconda/autopart.py", line 19, in > > import fsset > > File "/usr/lib/anaconda/fsset.py", line 28, in > > import partedUtils > > File "/usr/lib/anaconda/partedUtils.py", line 27, in > > import raid > > File "/usr/lib/anaconda/raid.py", line 192 > > isRaid10(raidLevel): > > ^ > > SyntaxError: invalid syntax > > install exited abnormally [1/1] > > > From jkeating at redhat.com Fri Mar 2 19:31:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 2 Mar 2007 14:31:12 -0500 Subject: Todays Anaconda is broken...breaking Fedora installer In-Reply-To: <9f50a7a00703021117s5fd15985pb67d49efd828974e@mail.gmail.com> References: <9f50a7a00703021107o6eed1b70g78a9bbae3746808d@mail.gmail.com> <9f50a7a00703021116i4d30d12bk3c1068139d6a5071@mail.gmail.com> <9f50a7a00703021117s5fd15985pb67d49efd828974e@mail.gmail.com> Message-ID: <200703021431.12317.jkeating@redhat.com> On Friday 02 March 2007 14:17:05 Jerone Young wrote: > I meant it needs a ")". This has already been fixed. -- 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 tonynelson at georgeanelson.com Fri Mar 2 19:33:15 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Fri, 2 Mar 2007 14:33:15 -0500 Subject: ( In-Reply-To: <20070302085055.GK4449@petra.dvoda.cz> References: <20070301105026.GF4449@petra.dvoda.cz> <20070301194008.GA11931@redhat.com> <20070301213400.GI4449@petra.dvoda.cz> <20070302085055.GK4449@petra.dvoda.cz> Message-ID: At 9:50 AM +0100 3/2/07, Karel Zak wrote: >On Fri, Mar 02, 2007 at 01:07:05AM -0500, Tony Nelson wrote: >> Also, if it were to always run: >> >> Readahead-collector allocates memory in big chunks. It uses lots of memory >> -- when I ran it, 39 MB of /var/log/readahead-rac.log (which produced about >> .33 MB of /etc/readahead.d/custom.* -- but see bz 230687). (I note that >> readahead-collector will collect without limit, but that readahead will >> only use the first 32K entries.) Thus, while readahead-collect uses too >> much memory now to run every time, if it used a better data structure, say >> a balanced tree, and parsed the audit data into the tree as the data >> arrived, it could use about 2% of what is currently does. > > It's not so easy. My first implementation has collected only paths, but > this way is not reliable. You need to collect all events and parse it > by libauparse, because every syscall produces three events (syscall, > cwd and path) and the collector requires data from all three events. The > order of events could be *random* and before parsing you need to > all events for the syscall. I suggested parsing as the events are received. The order may vary, but all events for a particular file come in a group, according to parse_events and man auparse_next_record. It's the same event while the strings match up to the first ")" ("audit(1234567890.123:1): "). Collect strings until it changes and then auparse the preceding event. (For "balanced tree" read whatever mapping type you prefer.) > I think a simple solution is reduce number of fields in events and > store to memory simplificated event strings. I hope libauparse > doesn't have care about number of fields. This way can save 80% of > used memory (I think). I'll try to implement it. That would help, but it seems to rely on more of auparse's internals than would looking at the start of the string. > Frankly, I'm not sure if 30MB of RAM is so big problem in particular > case that readahead is effective solution for machines where is a lot of > memory for kernel cache. ISTM that it is too much memory if readahead-collector is to run every boot. > But you're right that there is a place for optimization. > >> Neither program seems to take account of the memory used by the files that >> are read, though readahead can report it. (Possibly readahead-collect >> should avoid the largest files, as they probably aren't mostly used and >> don't cause so much seeking.) > > Any example of really large file (during boot)? default.early 54204 KB /usr/lib/locale/locale-archive default.later 54204 KB /usr/lib/locale/locale-archive 46556 KB /var/lib/rpm/Packages 13748 KB /usr/share/icons/Bluecurve/icon-theme.cache custom.early 54204 KB /usr/lib/locale/locale-archive 10240 KB /var/lib/mysql/ibdata1 7373 KB /usr/share/fonts/japanese/TrueType/sazanami-gothic.ttf 5120 KB /var/lib/mysql/ib_logfie0 5120 KB /var/lib/mysql/ib_logfile1 custom.later 54204 KB /usr/lib/locale/locale-archive 25254 KB /usr/share/icons/crystalsvg/icon-theme.cache 13748 KB /usr/share/icons/Bluecurve/icon-theme.cache 7373 KB /usr/share/fonts/japanese/TrueType/sazanami-gothic.ttf 7356 KB /usr/lib/firerfox-1.5.0.10/components/libgklayoyut.so 6518 KB /usr/share/icons/gnome/icon-themee.cache 4756 KB /etrc/gconf/gconf.xml.defaults/%gconf-tree.xxml 4623 KB /usr/share/icons/hicolor/icon-theme.cache (I wrote a tool at , but this is hand-copied.) Note that locale-archive is read twice, in both early and later. The early files list should be subtracted from the later files list, by a merge after sorting. (Ask me to do it?) Packages is for yum-updatesd, which I'm not running, and which, as a daemon, doesn't need to be sped up anyway. The mysql stuff is also for a daemon. Probably all daemons' files should be skipped? I think it unlikely that reading an icon-theme.cache is as useful as its size. I'm using gnome and Bluecurve, but I have some KDE stuff installed, so that's where the crystalsvg stuff comes from. It's clearly not worth its weight. Another issue is files opened for writing and not reading. There's no use reading them in at all. I don't have any examples right away. I expect that the open mode is in the message somewhere, but I can't read it well enough. >> Readahead-collector runs for 5 minutes, so its output might need pruning if >> it ran each boot. When run manually, one knows to start stuff up and then >> wait for readahead to finish. BTW, the collection loop has a 30 second >> timeout that isn't being used. It might be reasonable to stop collecting >> if no event has come in in that time. > > Good idea, but I'm pessimistic that there is 30s when system doesn't > call open() :-) In that case, readahead isn't going to help anyway. 8-b >> If readahead-collect could run automatically, readahead might request it >> for the next boot if "too many" files are not found (say, after a firefox >> update). > > Very good point. > > TODO updated: > > >http://git.fedoraproject.org/?p=hosted/readahead;a=blob_plain;f=TODO;hb=HEAD > > > Thanks. You're welcome. -- ____________________________________________________________________ TonyN.:' ' From tonynelson at georgeanelson.com Fri Mar 2 19:32:43 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Fri, 2 Mar 2007 14:32:43 -0500 Subject: announce: readahead-1.4 In-Reply-To: <639506.74795.qm@web51510.mail.yahoo.com> References: <639506.74795.qm@web51510.mail.yahoo.com> Message-ID: At 6:09 AM -0800 3/2/07, Steve G wrote: >> It's one rule: >> >> rc |= audit_rule_syscallbyname_data(audit_rule, "open"); >> rc |= audit_rule_syscallbyname_data(audit_rule, "creat"); >> rc |= audit_rule_syscallbyname_data(audit_rule, "truncate"); >> rc |= audit_rule_syscallbyname_data(audit_rule, "execve"); >> rc |= audit_rule_syscallbyname_data(audit_rule, "sendfile"); > >I think you are missing some events. I added a feature to autrace to help with >threat modeling. (The idea is run your program with autrace -r, exercise it, >extract audit data, and feed that to UML diagrammer.) I would suggest >using code >similar to the threat model: > > rc |= audit_rule_syscallbyname_data(rule, "open"); > rc |= audit_rule_syscallbyname_data(rule, "creat"); > rc |= audit_rule_syscallbyname_data(rule, "truncate"); > rc |= audit_rule_syscallbyname_data(rule, "rename"); > rc |= audit_rule_syscallbyname_data(rule, "unlink"); > rc |= audit_rule_syscallbyname_data(rule, "mknod"); > rc |= audit_rule_syscallbyname_data(rule, "mkdir"); > rc |= audit_rule_syscallbyname_data(rule, "rmdir"); > rc |= audit_rule_syscallbyname_data(rule, "chdir"); > rc |= audit_rule_syscallbyname_data(rule, "chown"); > rc |= audit_rule_syscallbyname_data(rule, "lchown"); > rc |= audit_rule_syscallbyname_data(rule, "chmod"); > rc |= audit_rule_syscallbyname_data(rule, "link"); > rc |= audit_rule_syscallbyname_data(rule, "symlink"); > rc |= audit_rule_syscallbyname_data(rule, "readlink"); > rc |= audit_rule_syscallbyname_data(rule, "execve"); > rc |= audit_rule_syscallbyname_data(rule, "connect"); > rc |= audit_rule_syscallbyname_data(rule, "bind"); > rc |= audit_rule_syscallbyname_data(rule, "accept"); > rc |= audit_rule_syscallbyname_data(rule, "sendto"); > rc |= audit_rule_syscallbyname_data(rule, "recvfrom"); > rc |= audit_rule_syscallbyname_data(rule, "sendfile"); > >which admittedly does not contain the *at syscalls. The threat model is so >that you can see all the boundaries/resources that your apps are using. >You could turn off the networking, mknod, & mkdir if you like. ... Probably none of the added syscalls refer to files that are being read from? I suppose readhead could cache the inodes, but I don't think it is doing any of that now. I don't think that even 'creat' or 'truncate' make sense. Is there a way to tell if a file is opened for reading from the message? Only files that are read from should be readahead. -- ____________________________________________________________________ TonyN.:' ' From enrico.scholz at informatik.tu-chemnitz.de Fri Mar 2 20:39:32 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Fri, 02 Mar 2007 21:39:32 +0100 Subject: Installation order of basesystem, filesystem and setup. In-Reply-To: <45E843BF.4080201@redhat.com> (Phil Knirsch's message of "Fri, 02 Mar 2007 16:33:19 +0100") References: <45E843BF.4080201@redhat.com> Message-ID: <87ps7rcrcr.fsf@kosh.bigo.ensc.de> pknirsch at redhat.com (Phil Knirsch) writes: > basesystem Requires: filesystem setup > filesystem Requires: setup > setup Requires: (nothing) > > So the final install order after properly ordering those is: > > setup > filesystem > basesystem I would expect this order: 1. filesystem (there must be something where files can be stored) 2. setup (stuff like /etc/passwd); this should require the package which is shipping /etc and perhaps /usr/share/doc 3. basesystem; requires filesystem + setup There is a problem with 'filesystem' because it ships files owned by non-root and requires /etc/passwd therefore. My suggestion: * split 'filesystem' into: - 'filesystem-base' -> owns '/', '/etc' + '/usr/share/doc' (and all parents); perhaps some toplevel dirs like /var and /bin too - 'filesystem' -> owns the other dirs from current 'filesystem' * keep 'filesystem-base' dependency-less * add: - to 'basesystem' | Requires(pre): setup, filesystem | Requires(postun): setup, filesystem - to 'setup' | Requires(pre): filesystem-base | Requires(postun): filesystem-base - to 'filesystem' | Requires(pre): setup, filesystem-base | Requires(postun): setup, filesystem-base Perhaps the redundant deps can be removed Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From davej at redhat.com Fri Mar 2 21:17:58 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 2 Mar 2007 16:17:58 -0500 Subject: Kernel 2.6.19 squashfs problem and bugzilla In-Reply-To: <20070302153703.GA7038@dspnet.fr.eu.org> References: <20070302153703.GA7038@dspnet.fr.eu.org> Message-ID: <20070302211758.GB20893@redhat.com> On Fri, Mar 02, 2007 at 04:37:03PM +0100, Olivier Galibert wrote: > The kernel from kernel-2.6.19-1.2288.fc5.x86_64.rpm is not able to > loop-mount the fc5 install Fedora/base/stage2.img file, at least > through nfs. You get: > squashfs: version 3.2-alpha (2006/12/12) Phillip Lougher > SQUASHFS error: sb_bread failed reading block 0x9e8be8e1 > SQUASHFS error: unable to read inode lookup table squashfs isn't compatible between releases. Dave -- http://www.codemonkey.org.uk From florin at andrei.myip.org Fri Mar 2 22:54:20 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Fri, 02 Mar 2007 14:54:20 -0800 Subject: detect all hard-drives (maybe all storage devices) Message-ID: <45E8AB1C.1010105@andrei.myip.org> Using the Fedora 6.91 Live CD, is there a simple way to do a query from a script and obtain a list with all the hard-drives in the system? (PATA, SATA, SCSI) -- Florin Andrei http://florin.myip.org/ From tmus at tmus.dk Fri Mar 2 21:54:53 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 02 Mar 2007 22:54:53 +0100 Subject: Reduction of Fedora releases In-Reply-To: <200703021216.39477.jkeating@redhat.com> References: <200703021216.39477.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > In an effort to make Bugzilla easier to use, we've been experimenting with not > creating new versions of Fedora for every test release. Reason being is that > the typical response to a bug filed against a test release is a request to > duplicate it with the current development package set. It also makes it > harder for a user to find dups of a bug they're about to file if they have to > search through N testN versions. Instead we're asking all bugs encountered > in test releases to be filed against devel. (yes you may still get asked to > repro with current devel packages, but at least the bug will be assigned to > the right release then). > > I didn't communicate this experiment clearly last time around and an fc7test1 > bugzilla version got created. We're killing that and moving all the bugs to > the devel version. > > Good call! After the initial install, most test releases, i suspect, are "yum update"d and essentially morphed into devel anyways... /Thomas From tibbs at math.uh.edu Fri Mar 2 23:51:50 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Mar 2007 17:51:50 -0600 Subject: detect all hard-drives (maybe all storage devices) In-Reply-To: <45E8AB1C.1010105@andrei.myip.org> References: <45E8AB1C.1010105@andrei.myip.org> Message-ID: >>>>> "FA" == Florin Andrei writes: FA> Using the Fedora 6.91 Live CD, is there a simple way to do a query FA> from a script and obtain a list with all the hard-drives in the FA> system? (PATA, SATA, SCSI) > lshal -s|grep '^storage' storage_model_DVD_16X storage_model_LITE_ON_DVDRW_SHM_165H6S storage_serial_SATA_ST380811AS_5PS0DY4N storage_serial_SATA_ST3500641AS_3PM06NY8 I've no idea if lshal is on the livecd. - J< From galibert at pobox.com Sat Mar 3 00:48:39 2007 From: galibert at pobox.com (Olivier Galibert) Date: Sat, 3 Mar 2007 01:48:39 +0100 Subject: Kernel 2.6.19 squashfs problem and bugzilla In-Reply-To: <20070302211758.GB20893@redhat.com> References: <20070302153703.GA7038@dspnet.fr.eu.org> <20070302211758.GB20893@redhat.com> Message-ID: <20070303004839.GA73629@dspnet.fr.eu.org> On Fri, Mar 02, 2007 at 04:17:58PM -0500, Dave Jones wrote: > On Fri, Mar 02, 2007 at 04:37:03PM +0100, Olivier Galibert wrote: > > The kernel from kernel-2.6.19-1.2288.fc5.x86_64.rpm is not able to > > loop-mount the fc5 install Fedora/base/stage2.img file, at least > > through nfs. You get: > > squashfs: version 3.2-alpha (2006/12/12) Phillip Lougher > > SQUASHFS error: sb_bread failed reading block 0x9e8be8e1 > > SQUASHFS error: unable to read inode lookup table > > squashfs isn't compatible between releases. And Linus allowed it in the kernel? In any case, the decision to use it for the stage2 should probably revisited in that light... OG. From sundaram at fedoraproject.org Sat Mar 3 00:54:20 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 03 Mar 2007 06:24:20 +0530 Subject: Kernel 2.6.19 squashfs problem and bugzilla In-Reply-To: <20070303004839.GA73629@dspnet.fr.eu.org> References: <20070302153703.GA7038@dspnet.fr.eu.org> <20070302211758.GB20893@redhat.com> <20070303004839.GA73629@dspnet.fr.eu.org> Message-ID: <45E8C73C.3030604@fedoraproject.org> Olivier Galibert wrote: > On Fri, Mar 02, 2007 at 04:17:58PM -0500, Dave Jones wrote: >> On Fri, Mar 02, 2007 at 04:37:03PM +0100, Olivier Galibert wrote: >> > The kernel from kernel-2.6.19-1.2288.fc5.x86_64.rpm is not able to >> > loop-mount the fc5 install Fedora/base/stage2.img file, at least >> > through nfs. You get: >> > squashfs: version 3.2-alpha (2006/12/12) Phillip Lougher >> > SQUASHFS error: sb_bread failed reading block 0x9e8be8e1 >> > SQUASHFS error: unable to read inode lookup table >> >> squashfs isn't compatible between releases. > > And Linus allowed it in the kernel? Nope. It is a custom patch instead of using cramfs because the compression and performance is better. > > In any case, the decision to use it for the stage2 should probably > revisited in that light... It is fine for that purpose. Just dont use it anywhere else. Rahul From denis at poolshark.org Sat Mar 3 00:57:23 2007 From: denis at poolshark.org (Denis Leroy) Date: Sat, 03 Mar 2007 01:57:23 +0100 Subject: detect all hard-drives (maybe all storage devices) In-Reply-To: References: <45E8AB1C.1010105@andrei.myip.org> Message-ID: <45E8C7F3.6050105@poolshark.org> Jason L Tibbitts III wrote: >>>>>> "FA" == Florin Andrei writes: > > FA> Using the Fedora 6.91 Live CD, is there a simple way to do a query > FA> from a script and obtain a list with all the hard-drives in the > FA> system? (PATA, SATA, SCSI) > >> lshal -s|grep '^storage' > storage_model_DVD_16X > storage_model_LITE_ON_DVDRW_SHM_165H6S > storage_serial_SATA_ST380811AS_5PS0DY4N > storage_serial_SATA_ST3500641AS_3PM06NY8 > > I've no idea if lshal is on the livecd. I like to do # cat /sys/block/*/device/model but # kudzu -p CDROM is probably better From galibert at pobox.com Sat Mar 3 00:58:37 2007 From: galibert at pobox.com (Olivier Galibert) Date: Sat, 3 Mar 2007 01:58:37 +0100 Subject: Kernel 2.6.19 squashfs problem and bugzilla In-Reply-To: <45E8C73C.3030604@fedoraproject.org> References: <20070302153703.GA7038@dspnet.fr.eu.org> <20070302211758.GB20893@redhat.com> <20070303004839.GA73629@dspnet.fr.eu.org> <45E8C73C.3030604@fedoraproject.org> Message-ID: <20070303005837.GB73629@dspnet.fr.eu.org> On Sat, Mar 03, 2007 at 06:24:20AM +0530, Rahul Sundaram wrote: > Olivier Galibert wrote: > >In any case, the decision to use it for the stage2 should probably > >revisited in that light... > > It is fine for that purpose. Just dont use it anywhere else. "Fine" as in "be ready to lose some days tracking what's going on when you've had to upgrade the kernel of the minimal boot/install image to support newer hardware". Why do you hate sysadmins so much? OG. From galibert at pobox.com Sat Mar 3 00:59:50 2007 From: galibert at pobox.com (Olivier Galibert) Date: Sat, 3 Mar 2007 01:59:50 +0100 Subject: detect all hard-drives (maybe all storage devices) In-Reply-To: <45E8AB1C.1010105@andrei.myip.org> References: <45E8AB1C.1010105@andrei.myip.org> Message-ID: <20070303005950.GC73629@dspnet.fr.eu.org> On Fri, Mar 02, 2007 at 02:54:20PM -0800, Florin Andrei wrote: > Using the Fedora 6.91 Live CD, is there a simple way to do a query from > a script and obtain a list with all the hard-drives in the system? > (PATA, SATA, SCSI) I kinda like /proc/partitions. OG. From sundaram at fedoraproject.org Sat Mar 3 01:03:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 03 Mar 2007 06:33:23 +0530 Subject: Kernel 2.6.19 squashfs problem and bugzilla In-Reply-To: <20070303005837.GB73629@dspnet.fr.eu.org> References: <20070302153703.GA7038@dspnet.fr.eu.org> <20070302211758.GB20893@redhat.com> <20070303004839.GA73629@dspnet.fr.eu.org> <45E8C73C.3030604@fedoraproject.org> <20070303005837.GB73629@dspnet.fr.eu.org> Message-ID: <45E8C95B.8030100@fedoraproject.org> Olivier Galibert wrote: > On Sat, Mar 03, 2007 at 06:24:20AM +0530, Rahul Sundaram wrote: >> Olivier Galibert wrote: >>> In any case, the decision to use it for the stage2 should probably >>> revisited in that light... >> It is fine for that purpose. Just dont use it anywhere else. > > "Fine" as in "be ready to lose some days tracking what's going on when > you've had to upgrade the kernel of the minimal boot/install image to > support newer hardware". Why do you hate sysadmins so much? ... because I spend 2 years of my life being one ;-) Rahul From linux_4ever at yahoo.com Sat Mar 3 01:41:38 2007 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 2 Mar 2007 17:41:38 -0800 (PST) Subject: ( In-Reply-To: Message-ID: <26395.16668.qm@web51502.mail.yahoo.com> > The order may vary, but all events for a particular file come in a group, > according to parse_events and man auparse_next_record. It's the same event > while the strings match up to the first ")" ("audit(1234567890.123:1): "). The events can come at random order but its not something that happens much. > but it seems to rely on more of auparse's internals than would looking at the > start of the string. I will be fixing auparse to handle out of order events. If you just assume it does the right thing for now, I should have it doing the right thing in all cases in the next release or two. -Steve ____________________________________________________________________________________ Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know. From tonynelson at georgeanelson.com Sat Mar 3 02:24:52 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Fri, 2 Mar 2007 21:24:52 -0500 Subject: ( In-Reply-To: <26395.16668.qm@web51502.mail.yahoo.com> References: <26395.16668.qm@web51502.mail.yahoo.com> Message-ID: At 5:41 PM -0800 3/2/07, Steve G wrote: >> The order may vary, but all events for a particular file come in a group, >> according to parse_events and man auparse_next_record. It's the same event >> while the strings match up to the first ")" ("audit(1234567890.123:1): "). > >The events can come at random order but its not something that happens much. > >> but it seems to rely on more of auparse's internals than would looking >>at the >> start of the string. > >I will be fixing auparse to handle out of order events. If you just assume >it does the right thing for now, I should have it doing the right thing in >all cases in the next release or two. I'm not sure that I understand you. Are you saying that the code in readahead-collector parse_events() currently doesn't work? In any case, what does that have to do with my statement, that writing events by hand to pass to auparse relies more on auparse's internals than gathering all events for a file by looking at the ""audit(1234567890.123:1): " at the beginning of each event? -- ____________________________________________________________________ TonyN.:' ' From seg at haxxed.com Sat Mar 3 03:19:36 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 02 Mar 2007 21:19:36 -0600 Subject: detect all hard-drives (maybe all storage devices) In-Reply-To: <45E8AB1C.1010105@andrei.myip.org> References: <45E8AB1C.1010105@andrei.myip.org> Message-ID: <1172891976.7876.3.camel@localhost.localdomain> On Fri, 2007-03-02 at 14:54 -0800, Florin Andrei wrote: > Using the Fedora 6.91 Live CD, is there a simple way to do a query from > a script and obtain a list with all the hard-drives in the system? > (PATA, SATA, SCSI) $ ls -lI "*-part?" /dev/disk/by-id/ total 0 lrwxrwxrwx 1 root root 9 Mar 2 15:34 ata-Maxtor_53073H4_M0000000 -> ../../hdc lrwxrwxrwx 1 root root 9 Mar 2 15:34 ata-Maxtor_6L250R0_L60WLQ7H -> ../../hda lrwxrwxrwx 1 root root 9 Mar 2 15:34 usb-Maxtor_5_T040H4_DEF107679C83 -> ../../sda -------------- 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 Fri Mar 2 05:04:36 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 1 Mar 2007 23:04:36 -0600 Subject: Fedora safe/recovery mode Message-ID: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> It seems like a common enough recurrence that someone, often times a person new to Fedora needs to boot to runlevel 3. Seems like it would be advantageous to have a boot target that goes to runlevel 3 all the time. What does the list think? Arthur Pemberton -- Fedora Core 6 and proud From tibbs at math.uh.edu Sat Mar 3 05:03:45 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 02 Mar 2007 23:03:45 -0600 Subject: Fedora safe/recovery mode In-Reply-To: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> Message-ID: >>>>> "AP" == Arthur Pemberton writes: AP> Seems like it would be advantageous to have a boot target that AP> goes to runlevel 3 all the time. Add "3" to the kernel boot parameters, the same way you'd add "single" or "s" to boot to single user mode. If you feel the need to have an actual grub entry for this, it's just a few seconds with an editor in /etc/grub.conf. - J< From davehoz at gmail.com Fri Mar 2 06:28:20 2007 From: davehoz at gmail.com (David Hunter) Date: Fri, 2 Mar 2007 17:28:20 +1100 Subject: Yum problem version yum-3.1.2-1.fc7 Message-ID: <6bb886180703012228p68285f9axc90fbaa073a1365d@mail.gmail.com> Yum works fine, except for the inability to delete the header files after updating packages. Such an example of this is: Cannot remove //var/cache/yum/development/headers/bitmap- fonts-0.3-5.1.2.fc7.noarch.hdr Bug or known issue? -- David Hunter -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at linux.duke.edu Sat Mar 3 05:08:26 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sat, 03 Mar 2007 00:08:26 -0500 Subject: Yum problem version yum-3.1.2-1.fc7 In-Reply-To: <6bb886180703012228p68285f9axc90fbaa073a1365d@mail.gmail.com> References: <6bb886180703012228p68285f9axc90fbaa073a1365d@mail.gmail.com> Message-ID: <1172898506.30992.0.camel@cutter> On Fri, 2007-03-02 at 17:28 +1100, David Hunter wrote: > Yum works fine, except for the inability to delete the header files > after updating packages. Such an example of this is: > > Cannot > remove //var/cache/yum/development/headers/bitmap-fonts-0.3-5.1.2.fc7.noarch.hdr > > Bug or known issue? it was a bug but it has been fixed. -sv From kagesenshi.87 at gmail.com Sat Mar 3 05:29:25 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Sat, 3 Mar 2007 13:29:25 +0800 Subject: Fedora safe/recovery mode In-Reply-To: References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> Message-ID: On 02 Mar 2007 23:03:45 -0600, Jason L Tibbitts III wrote: > >>>>> "AP" == Arthur Pemberton writes: > > AP> Seems like it would be advantageous to have a boot target that > AP> goes to runlevel 3 all the time. > > Add "3" to the kernel boot parameters, the same way you'd add "single" > or "s" to boot to single user mode. > > If you feel the need to have an actual grub entry for this, it's just > a few seconds with an editor in /etc/grub.conf. > > - J< I think he suggesting a default entry for that in a fedora installation .. eg: a grub option with the title "Recovery Console" ... but then .. if the user know how to use the "Recovery Console" ... supposedly he/she should already know how to change the init in grub ... however, there still exist some special people with special cases :) .. /my 2cent -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? Universiti Teknologi PETRONAS ICT 2nd Year 1st Semester mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com GPG: http://www.rootshell.be/~kagesens/public-key.asc Blog: http://kagesenshi.blogspot.com ----------------------------------------------- From jerone at gmail.com Fri Mar 2 19:07:39 2007 From: jerone at gmail.com (Jerone Young) Date: Fri, 2 Mar 2007 13:07:39 -0600 Subject: Todays Anaconda is broken...breaking Fedora installer Message-ID: <9f50a7a00703021107o6eed1b70g78a9bbae3746808d@mail.gmail.com> Seems like an extra ":" was added by accident. Don't have the source in front of me but here is the back trace. unning anaconda, the Fedora Core system installer - please wait... Traceback (most recent call last): File "/usr/bin/anaconda", line 564, in from exception import handleException File "/usr/lib/anaconda/exception.py", line 33, in import kickstart File "/usr/lib/anaconda/kickstart.py", line 18, in from autopart import * File "/usr/lib/anaconda/autopart.py", line 19, in import fsset File "/usr/lib/anaconda/fsset.py", line 28, in import partedUtils File "/usr/lib/anaconda/partedUtils.py", line 27, in import raid File "/usr/lib/anaconda/raid.py", line 192 isRaid10(raidLevel): ^ SyntaxError: invalid syntax install exited abnormally [1/1] From buildsys at redhat.com Sat Mar 3 12:07:49 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 3 Mar 2007 07:07:49 -0500 Subject: rawhide report: 20070303 changes Message-ID: <200703031207.l23C7nnJ009509@hs20-bc2-6.build.redhat.com> Updated Packages: audit-1.5-2.fc7 --------------- * Fri Mar 02 2007 Steve Grubb 1.5-2 - rebuild * Fri Mar 02 2007 Steve Grubb 1.5-1 - NEW audit dispatcher program & plugin framework - Correct hidden variables in libauparse - Added NISPOM sample rules - Verify accessibility of files passed in auparse_init - Fix bug in parser library interpreting socketcalls - Add support for stdio FILE pointer in auparse_init - Adjust init script to allow anyone to status auditd (#230626) binutils-2.17.50.0.12-2 ----------------------- * Fri Mar 02 2007 Jakub Jelinek 2.17.50.0.12-2 - ignore install-info errors from scriptlets (#223678) cups-1:1.2.8-3.fc7 ------------------ * Fri Mar 02 2007 Tim Waugh 1:1.2.8-3 - Updated LSPP patch (bug #229673). glib-java-0.2.6-7.fc7 --------------------- * Fri Mar 02 2007 Stepan Kasal - 0.2.6-7 - Force -fPIC and avoid -Wall with gcj/ecj. * Tue Feb 27 2007 Stepan Kasal - 0.2.6-6 - The gjavah patch should change configure.ac first, then configure. kasumi-2.2-1.fc7 ---------------- * Fri Mar 02 2007 Akira TAGOH - 2.2-1 - Updated to 2.2 - Remove kasumi-2.0.1-errorcode.patch. no longer needed. * Wed Jul 12 2006 Jesse Keating - 2.0.1-1.1 - rebuild * Fri Jun 30 2006 Akira TAGOH - 2.0.1-1 - New upstream release. - use dist tag. - kasumi-2.0.1-errorcode.patch: fixed not working when the private dictionary is empty. (#197313) kernel-2.6.20-1.2962.fc7 ------------------------ * Fri Mar 02 2007 Dave Jones - 2.6.21rc2-git2 * Fri Mar 02 2007 Dave Jones - Enable PM_TRACE man-pages-cs-0.16-7.fc7 ----------------------- * Fri Mar 02 2007 Ivana Varekova - 0.16-7 - Resolves: 226121 incorporate the package review feedback man-pages-da-0.1.1-13.fc7 ------------------------- * Fri Mar 02 2007 Ivana Varekova - 0.1.1-13 - Resolves: 226122 incorporate package review feedback man-pages-pl-0.24-3.fc7 ----------------------- * Fri Mar 02 2007 Ivana Varekova - 0.24-3 - Resolves: 226128 incorporate package review feedback man-pages-ru-0.97-2.fc7 ----------------------- * Fri Mar 02 2007 Ivana Varekova - 0.97-2 - Resolves: 226129 incorporate package review feedback mesa-6.5.2-7.fc7 ---------------- * Fri Mar 02 2007 Adam Jackson 6.5.2-7 - mesa-6.5.2-picify-dri-drivers.patch: Attempt to make the DRI drivers PIC. - mesa-6.5.1-build-config.patch: Apply RPM_OPT_FLAGS to OSMesa too. nautilus-2.17.92-2.fc7 ---------------------- * Thu Mar 01 2007 Alexander Larsson - 2.17.92-2 - Add xdg-user-dirs patch newt-0.52.6-1.fc7 ----------------- * Fri Mar 02 2007 Miroslav Lichvar - 0.52.6-1 - add newtSetColor() to allow changing individual colors - add newtPopWindowNoRefresh() (patch by Forest Bond) - move static library to -static subpackage, spec cleanup (#226195) (patch by Jason Tibbitts) nss-3.11.5-2.fc7 ---------------- * Fri Mar 02 2007 Kai Engert - 3.11.5-2 - Fix rhbz#230545, failure to enable FIPS mode - Fix rhbz#220542, make NSS more tolerant of resets when in the middle of prompting for a user password. openoffice.org-1:2.2.0-9.2 -------------------------- * Fri Mar 02 2007 Caolan McNamara - 1:2.2.0-9.2 - jumped the run on requiring extras from a core package, back out for now - -finline-limit=64 http://blogs.linux.ie/caolan/2007/03/02/finline-limit-and-ooo pirut-1.3.3-1.fc7 ----------------- * Fri Mar 02 2007 Jeremy Katz - 1.3.3-1 - Support installing a single package from a repo by passing a package name to system-install-packages (Owen Taylor) - Don't force downloading of headers python-virtinst-0.101.0-3.fc7 ----------------------------- * Fri Mar 02 2007 Daniel P. Berrange - 0.101.0-3.fc7 - Fixed restart of guests after install completes readahead-1:1.3-7.fc6 --------------------- * Thu Mar 01 2007 Karel Zak - 1:1.3-7 - new lists (generated by readahead-1.4) thunderbird-1.5.0.10-1.fc7 -------------------------- * Fri Mar 02 2007 Martin Stransky 1.5.0.10-1 - Update to 1.5.0.10 virt-manager-0.3.1-3.fc7 ------------------------ * Fri Mar 02 2007 Daniel P. Berrange - 0.3.1-3.fc7 - Fixed keyboard ungrab in VNC widget vnc-4.1.2-14.fc7 ---------------- * Fri Mar 02 2007 Adam Tkac 4.1.2-14.fc7 - enabled RENDER, Composite and GLX extensions by default on all architectures - new relation between Xvnc and xorg's source. Xvnc now uses latest xorg's sources from xorg-x11-server-source package - fired away obsolete patches - vnc-mesa-6.5.2.patch - vnc-mesa.patch - vnc-selinux.patch - vnc-render-sigfault.patch - vnc-fontpath.patch - vnc-null-interface.patch xen-3.0.4-7.fc7 --------------- * Fri Mar 02 2007 Daniel Berrange - 3.0.4-7.fc7 - Fix interaction of bootloader with blktap (bz 230702) - Ensure PFVB daemon terminates if domain doesn't startup (bz 230634) * Thu Feb 08 2007 Daniel Berrange - 3.0.4-6.fc7 - Setup readonly loop devices for readonly disks - Extended error reporting for hotplug scripts - Pass all 8 mouse buttons from VNC through to kernel * Tue Jan 30 2007 Daniel P. Berrange - 3.0.4-5.fc7 - Don't run the pvfb daemons for HVM guests (bz 225413) - Fix handling of vnclisten parameter for HVM guests xorg-x11-server-1.2.0-10.fc7 ---------------------------- * Fri Mar 02 2007 Adam Tkac 1.2.0-10 - change permissions of files in source package to default from read-only xsane-0.993-1.fc7 ----------------- * Fri Mar 02 2007 Nils Philippsen - 0.993-1 - version 0.993 (#230706) yum-3.1.3-2.fc7 --------------- * Fri Mar 02 2007 Jeremy Katz - 3.1.3-2 - pile of bugfixes committed upstream (#230734, #230771, and others) Broken deps for ppc64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ppc64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.ppc64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ppc64 requires lm_sensors-devel Broken deps for i386 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.i386 requires libgcj.so.7rh frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh Broken deps for x86_64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) cairo-java - 1.0.5-4.fc7.i386 requires libgcj.so.7rh frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.x86_64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libgconf-java - 2.12.4-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) Broken deps for ppc ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ppc requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.ppc requires libofx.so.3 gnucash - 2.0.5-1.fc6.ppc requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.ppc requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.ppc requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.ppc requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.ppc requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.ppc requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.ppc requires lm_sensors-devel Broken deps for ia64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ia64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ia64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.ia64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ia64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ia64 requires lm_sensors-devel Broken deps for s390 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.s390 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel 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 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.s390 requires libgcj.so.7rh cairo-java - 1.0.5-4.fc7.s390x requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libofx.so.3()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.s390x requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libgconf-java - 2.12.4-5.fc7.s390x requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390x requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.s390x requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.s390 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.s390x requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.s390x requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel net-snmp-devel - 1:5.4-10.fc7.s390x requires lm_sensors-devel From linux_4ever at yahoo.com Sat Mar 3 13:20:36 2007 From: linux_4ever at yahoo.com (Steve G) Date: Sat, 3 Mar 2007 05:20:36 -0800 (PST) Subject: ( In-Reply-To: Message-ID: <789679.48508.qm@web51503.mail.yahoo.com> >I'm not sure that I understand you. Are you saying that the code in >readahead-collector parse_events() currently doesn't work? I haven't looked at it. But it should rely on libauparse to separate into events and then the read-ahead program can pick the fields out that it needs and store those to a more permanent/compact representation. -Steve ____________________________________________________________________________________ TV dinner still cooling? Check out "Tonight's Picks" on Yahoo! TV. http://tv.yahoo.com/ From stickster at gmail.com Sat Mar 3 15:14:00 2007 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 03 Mar 2007 10:14:00 -0500 Subject: Fedora safe/recovery mode In-Reply-To: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> Message-ID: <1172934840.21116.22.camel@localhost.localdomain> On Thu, 2007-03-01 at 23:04 -0600, Arthur Pemberton wrote: > It seems like a common enough recurrence that someone, often times a > person new to Fedora needs to boot to runlevel 3. Seems like it would > be advantageous to have a boot target that goes to runlevel 3 all the > time. > > What does the list think? -1: First, inexperienced users would equate this with functionality (?) in Windows and expect a GUI, and when they didn't get it, would instead get the mistaken impression it was a bug. In cases where something more horrendous was broken, like a file system problem that needed intervention/checking, this doesn't really help since almost any runlevel target drops them to the same maintenance (root password) prompt. Second, anyone "new" trying to perform fixes requiring a different runlevel, console skills, and so forth, would have to check all the normal information sources (including books, FAQs, forums, friends, et al.), which multitudinously include the advice for editing the GRUB boot configuration. If a fix is going to require editing an X configuration file, certainly it's a much lower bar to require adding " 3" (or whatever) to a line in the boot loader. Third, when there's an X problem, in many cases the system will already present a configuration error dialog and drop the user back to a getty for login -- not always, but very often. IMHO this would be misleading and have dubious value. We already provide functionality with the intallation discs and/or the rescue ISO that is much like a Windows recovery console (booting from the installation CD). Maybe you're looking for a failsafe "vesa" type X configuration, but this seems like a real quagmire looking for unwary developers to swallow up. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 linville at redhat.com Sat Mar 3 16:11:01 2007 From: linville at redhat.com (John W. Linville) Date: Sat, 3 Mar 2007 11:11:01 -0500 Subject: mac80211 and iwlwifi (was Re: d80211 and iwlwifi) In-Reply-To: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> Message-ID: <20070303161100.GC3511@redhat.com> On Sat, Feb 24, 2007 at 09:56:25PM +0000, Mike Cohler wrote: > I hope this is not a repeat question but is it planned to have d80211 > and iwlwifi in the F7 release? I have test kernels w/ iwlwifi here: http://people.redhat.com/linville/kernels/fc7/ If you have ipw3945 hardware, please give them a try. You will need to get the firmware from here: http://intellinuxwireless.org YMMV...I haven't been able to make it work yet on my Sony Vaio... Send the bug reports (and patches!) to me...thanks! John -- John W. Linville linville at redhat.com From andy at warmcat.com Sat Mar 3 17:17:32 2007 From: andy at warmcat.com (Andy Green) Date: Sat, 03 Mar 2007 17:17:32 +0000 Subject: mac80211 and iwlwifi (was Re: d80211 and iwlwifi) In-Reply-To: <20070303161100.GC3511@redhat.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <20070303161100.GC3511@redhat.com> Message-ID: <45E9ADAC.6070003@warmcat.com> John W. Linville wrote: > YMMV...I haven't been able to make it work yet on my Sony Vaio... > > Send the bug reports (and patches!) to me...thanks! Working great for me in a Samsung Q35. Note I am using wpa_supplicant patched with the "dscape patch" http://kernel.org/pub/linux/kernel/people/jbenc/ieee80211-utils/wpa_supplicant/wpa_supplicant-0.4.7_dscape-02.patch Not certain if that is a necessary ingredient for success or not. -Andy From pemboa at gmail.com Sat Mar 3 09:20:01 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 4 Mar 2007 03:20:01 +1800 Subject: Fedora safe/recovery mode In-Reply-To: References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> Message-ID: <16de708d0703030120r123bc791g28dfc25a7c66b079@mail.gmail.com> On 3/3/07, Hikaru Amano wrote: > On 02 Mar 2007 23:03:45 -0600, Jason L Tibbitts III wrote: > > >>>>> "AP" == Arthur Pemberton writes: > > > > AP> Seems like it would be advantageous to have a boot target that > > AP> goes to runlevel 3 all the time. > > > > Add "3" to the kernel boot parameters, the same way you'd add "single" > > or "s" to boot to single user mode. > > > > If you feel the need to have an actual grub entry for this, it's just > > a few seconds with an editor in /etc/grub.conf. > > > > - J< > > I think he suggesting a default entry for that in a fedora > installation .. eg: a grub option with the title "Recovery Console" > ... > > but then .. if the user know how to use the "Recovery Console" ... > supposedly he/she should already know how to change the init in grub > ... however, there still exist some special people with special cases > :) .. > > /my 2cent Not necessarily. Often, peopel trying to fix their machine via following a tutorial or instructions from an IRC member: trust me, it can take quite a few lines of instuctions to direct a newbie from their BIOS's POST to getting into GRUB to append the '3' and booting that. Infact it may even be more troublesome than the few commands they will need to enter (since they need only type in what they are told). Peace -- Fedora Core 6 and proud From tonynelson at georgeanelson.com Sat Mar 3 18:13:50 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Sat, 3 Mar 2007 13:13:50 -0500 Subject: ( In-Reply-To: <789679.48508.qm@web51503.mail.yahoo.com> References: <789679.48508.qm@web51503.mail.yahoo.com> Message-ID: At 5:20 AM -0800 3/3/07, Steve G wrote: >>I'm not sure that I understand you. Are you saying that the code in >>readahead-collector parse_events() currently doesn't work? > >I haven't looked at it. Ah. >But it should rely on libauparse to separate into events >and then the read-ahead program can pick the fields out that it needs and >store >those to a more permanent/compact representation. It does, at the end, after collecting all the messages. So it should be OK. Thanks. -- ____________________________________________________________________ TonyN.:' ' From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 3 18:09:07 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 03 Mar 2007 19:09:07 +0100 Subject: Fedora safe/recovery mode In-Reply-To: (Hikaru Amano's message of "Sat, 3 Mar 2007 13:29:25 +0800") References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> Message-ID: <87tzx2rygs.fsf@kosh.bigo.ensc.de> kagesenshi.87 at gmail.com ("Hikaru Amano") writes: >> AP> Seems like it would be advantageous to have a boot target that >> AP> goes to runlevel 3 all the time. > ... > I think he suggesting a default entry for that in a fedora > installation .. eg: a grub option with the title "Recovery Console" /me would expect runlevel 1 behind 'Recovery Console', but not 3... Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From redhat at olen.net Sat Mar 3 18:28:53 2007 From: redhat at olen.net (Ola Thoresen) Date: Sat, 03 Mar 2007 19:28:53 +0100 Subject: mac80211 and iwlwifi (was Re: d80211 and iwlwifi) In-Reply-To: <20070303161100.GC3511@redhat.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <20070303161100.GC3511@redhat.com> Message-ID: <45E9BE65.2000204@olen.net> John W. Linville wrote: > On Sat, Feb 24, 2007 at 09:56:25PM +0000, Mike Cohler wrote: >> I hope this is not a repeat question but is it planned to have d80211 >> and iwlwifi in the F7 release? > > I have test kernels w/ iwlwifi here: > > http://people.redhat.com/linville/kernels/fc7/ Well. The kernel boots, and the modules seems to load fine. There is a problem however - that I am unsure how to resolve. No matter what I do, the driver reports that the Kill Switch is on. iwlwifi: Intel(R) Wirless Link driver for Linux, 0.0.10k iwlwifi: Copyright(c) 2003-2006 Intel Corporation ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 19 PCI: Setting latency timer of device 0000:02:00.0 to 64 iwlwifi: Detected Intel PRO/Wireless 3945ABG Network Connection PM: Adding info for No Bus:0000:02:00.0 PM: Removing info for No Bus:0000:02:00.0 iwlwifi: Radio Frequency Kill Switch is On: Kill switch must be turned off for wireless networking to work. iwlwifi: MAC is in deep sleep! iwlwifi: MAC is in deep sleep! iwlwifi: MAC is in deep sleep! iwlwifi: MAC is in deep sleep! There is a hardware-switch that is supposed to turn the radio on and off, but it does not matter if it is set to on or off - even if I reboot the laptop witih the switch in either position. When I turn this switch, nothing happens, but tho feollowing is logged to syslog: atkbd.c: Unknown key pressed (translated set 2, code 0xf1 on isa0060/serio0). atkbd.c: Use 'setkeycodes e071 ' to make it known. atkbd.c: Unknown key released (translated set 2, code 0xf1 on isa0060/serio0). atkbd.c: Use 'setkeycodes e071 ' to make it known. If I try with Fn-F2 which is also supposed to turn the radio on, the following is logged: atkbd.c: Unknown key pressed (translated set 2, code 0x84 on isa0060/serio0). atkbd.c: Use 'setkeycodes e004 ' to make it known. atkbd.c: Unknown key released (translated set 2, code 0x84 on isa0060/serio0). atkbd.c: Use 'setkeycodes e004 ' to make it known. Not sure what I should set these keycodes to to actually enable the radio. Also, I am not able to read the value of rf_kill: # cat /sys/devices/pci0000\:00/0000\:00\:1c.0/0000\:02\:00.0/rf_kill cat: /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/rf_kill: Resource temporarily unavailable The output of lspci: 02:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) Subsystem: Intel Corporation Unknown device 1001 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- .' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From jonathan.underwood at gmail.com Fri Mar 2 10:46:27 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 2 Mar 2007 10:46:27 +0000 Subject: Plans for the (La)TeX stack for F7? In-Reply-To: References: <645d17210703010436t59ed5eecpe04b7ed7cf6722b5@mail.gmail.com> <645d17210703010441h1d68f163l5cc32b4def354f4@mail.gmail.com> <645d17210703010859y5165324bue334e6f3afbcd8bf@mail.gmail.com> <645d17210703010942k788d13c1v740e46156b86a3f3@mail.gmail.com> <645d17210703011721q5a4961ffu2147a8874266aeb1@mail.gmail.com> Message-ID: <645d17210703020246y49e71c68t58477a9a9d9a3307@mail.gmail.com> On 02/03/07, Neal Becker wrote: > > BTW, what is a virtual provides? Perhaps I'm using the wrong terminology - I mean an explcitly added Provides: foo to eh package, where foo isn't any particular file in the package, basically saying "this package has capability foo". From ericm24x7 at gmail.com Sat Mar 3 19:35:10 2007 From: ericm24x7 at gmail.com (eric magaoay) Date: Sat, 03 Mar 2007 14:35:10 -0500 Subject: mac80211 and iwlwifi (was Re: d80211 and iwlwifi) In-Reply-To: <20070303161100.GC3511@redhat.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <20070303161100.GC3511@redhat.com> Message-ID: <45E9CDEE.6050609@gmail.com> John W. Linville wrote: > I have test kernels w/ iwlwifi here: > > http://people.redhat.com/linville/kernels/fc7/ > > If you have ipw3945 hardware, please give them a try. You will need > to get the firmware from here: > > http://intellinuxwireless.org > > YMMV...I haven't been able to make it work yet on my Sony Vaio... > > Send the bug reports (and patches!) to me...thanks! > > John > John, Will zd1211rw (zydas) module be included into the latest FC devel. build? I tried to git clone your wireless-2.6 a couple of days ago for testing but failed to complete due checksum error. eric From selinux at gmail.com Sat Mar 3 18:18:32 2007 From: selinux at gmail.com (Tom London) Date: Sat, 3 Mar 2007 10:18:32 -0800 Subject: mac80211 and iwlwifi (was Re: d80211 and iwlwifi) In-Reply-To: <20070303161100.GC3511@redhat.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <20070303161100.GC3511@redhat.com> Message-ID: <4c4ba1530703031018s44d72eb7va6331af3b72e382e@mail.gmail.com> On 3/3/07, John W. Linville wrote: > On Sat, Feb 24, 2007 at 09:56:25PM +0000, Mike Cohler wrote: > > I hope this is not a repeat question but is it planned to have d80211 > > and iwlwifi in the F7 release? > > I have test kernels w/ iwlwifi here: > > http://people.redhat.com/linville/kernels/fc7/ > > If you have ipw3945 hardware, please give them a try. You will need > to get the firmware from here: > > http://intellinuxwireless.org > > YMMV...I haven't been able to make it work yet on my Sony Vaio... > > Send the bug reports (and patches!) to me...thanks! > > John > -- > John W. Linville > linville at redhat.com Does not work for me on Thinkpad X60 using 'stock Rawhide' NetworkManager. Association fails both with WEP and 'no key'. tom -- Tom London From tmus at tmus.dk Sat Mar 3 19:29:28 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sat, 03 Mar 2007 20:29:28 +0100 Subject: Fedora safe/recovery mode In-Reply-To: <87tzx2rygs.fsf@kosh.bigo.ensc.de> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> Message-ID: Enrico Scholz wrote: > kagesenshi.87 at gmail.com ("Hikaru Amano") writes: > >>> AP> Seems like it would be advantageous to have a boot target that >>> AP> goes to runlevel 3 all the time. >> ... >> I think he suggesting a default entry for that in a fedora >> installation .. eg: a grub option with the title "Recovery Console" > > /me would expect runlevel 1 behind 'Recovery Console', but not 3... > > > Enrico > There are some security considerations with runlevel 1. On runlevel 2-5, the user is presented with a login screen. I haven't tested this in fedora for some months, but last I checked, runlevel 1 dropped the user directly in a root shell. Runlevel 3 is at least as safe as runlevel 5 and could be used with no security implications. So I guess the approach for something like this depends a lot on what the rescue shell should be used for? System recovery would probably call for runlevel 1 (or perhaps a safe-mode runlevel 2 with no drivers, nosmp, noacpi, noapic nolapic and whatever we can think off), but in the runlevel 1 case at least, we should make absolutely sure, the grub stanza is password protected and/or 2) the "drop to root shell without a password" feature is disabled (for all imaginable scenarios). I realize that the grub bootloader is not password protected by default in fedora, so putting an init=/bin/bash on the kernel cmdline and booting is an easy way in. But for the setups that actually tries to protect against these easy ways in, we should be really careful not to introduce a just-as-easy backdoor via the new recovery option... /Thomas From andy at warmcat.com Sat Mar 3 20:38:12 2007 From: andy at warmcat.com (Andy Green) Date: Sat, 03 Mar 2007 20:38:12 +0000 Subject: mac80211 and iwlwifi (was Re: d80211 and iwlwifi) In-Reply-To: <4c4ba1530703031018s44d72eb7va6331af3b72e382e@mail.gmail.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <20070303161100.GC3511@redhat.com> <4c4ba1530703031018s44d72eb7va6331af3b72e382e@mail.gmail.com> Message-ID: <45E9DCB4.10905@warmcat.com> Tom London wrote: > Does not work for me on Thinkpad X60 using 'stock Rawhide' NetworkManager. > > Association fails both with WEP and 'no key'. It's just like old times... NetworkManager destroys the possibility to connect. If you service NetworkManager stop it and restart wpa_supplicant by hand, here at least it works. I had it turned off anyway. But there is another bug in mac80211 or iwlwifi... when iwlwifi registers its capabilities with mac80211, the order matters. As it stands, iwlwifi will only connect at 802.11b speeds, ie, 11Mbps. If you swap the order of the registration: diff -urN iwlwifi-0.0.8-orig/compatible/base.c iwlwifi-0.0.8/compatible/base.c --- iwlwifi-0.0.8-orig/compatible/base.c 2007-02-25 17:56:44.000000000 +0000 +++ iwlwifi-0.0.8/compatible/base.c 2007-02-25 09:33:43.000000000 +0000 @@ -4560,10 +4561,10 @@ if (modes[A].num_channels) ieee80211_register_hwmode(priv->ieee, &modes[A]); + if (modes[G].num_channels) // andy at warmcat.com swapped registration order of b and g + ieee80211_register_hwmode(priv->ieee, &modes[G]); if (modes[B].num_channels) ieee80211_register_hwmode(priv->ieee, &modes[B]); - if (modes[G].num_channels) - ieee80211_register_hwmode(priv->ieee, &modes[G]); priv->status |= STATUS_GEO_CONFIGURED; } then you get 11g speeds. -Andy From selinux at gmail.com Sat Mar 3 20:38:26 2007 From: selinux at gmail.com (Tom London) Date: Sat, 3 Mar 2007 12:38:26 -0800 Subject: mac80211 and iwlwifi (was Re: d80211 and iwlwifi) In-Reply-To: <4c4ba1530703031018s44d72eb7va6331af3b72e382e@mail.gmail.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <20070303161100.GC3511@redhat.com> <4c4ba1530703031018s44d72eb7va6331af3b72e382e@mail.gmail.com> Message-ID: <4c4ba1530703031238l6144ffa9t22411c86cbd9f987@mail.gmail.com> On 3/3/07, Tom London wrote: > On 3/3/07, John W. Linville wrote: > > On Sat, Feb 24, 2007 at 09:56:25PM +0000, Mike Cohler wrote: > > > I hope this is not a repeat question but is it planned to have d80211 > > > and iwlwifi in the F7 release? > > > > I have test kernels w/ iwlwifi here: > > > > http://people.redhat.com/linville/kernels/fc7/ > > > > If you have ipw3945 hardware, please give them a try. You will need > > to get the firmware from here: > > > > http://intellinuxwireless.org > > > > YMMV...I haven't been able to make it work yet on my Sony Vaio... > > > > Send the bug reports (and patches!) to me...thanks! > > > > John > > -- > > John W. Linville > > linville at redhat.com > > Does not work for me on Thinkpad X60 using 'stock Rawhide' NetworkManager. > > Association fails both with WEP and 'no key'. > Rebooting, killing off NetworkManager, I get: [root at localhost ~]# ifup wlan0 Error for wireless request "Set Encode" (8B2A) : SET failed on device wmaster0 ; Operation not supported. Determining IP information for wmaster0... failed. [root at localhost ~]# tom -- Tom London From kwizart at gmail.com Sat Mar 3 17:26:07 2007 From: kwizart at gmail.com (KH KH) Date: Sat, 3 Mar 2007 18:26:07 +0100 Subject: mac80211 and iwlwifi (was Re: d80211 and iwlwifi) In-Reply-To: <45E9ADAC.6070003@warmcat.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <20070303161100.GC3511@redhat.com> <45E9ADAC.6070003@warmcat.com> Message-ID: 2007/3/3, Andy Green : > Working great for me in a Samsung Q35. Note I am using wpa_supplicant > patched with the "dscape patch" > > http://kernel.org/pub/linux/kernel/people/jbenc/ieee80211-utils/wpa_supplicant/wpa_supplicant-0.4.7_dscape-02.patch > > Not certain if that is a necessary ingredient for success or not. I'm quite sure it is because this the the same case for hosapd. I was testing d80211 stack with rt2x00 for a moment and this seems to be necessary. If you also want to test hosapd with this stack try https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230449 (i'm using d80211 from intel website until d80211 headers will be in kernel-headers) usage is : config /etc/hostapd/hostapd.conf launch hostapd /etc/hostapd/hostapd.conf Nicolas (kwizart) From drago01 at gmail.com Sat Mar 3 17:33:36 2007 From: drago01 at gmail.com (dragoran dragoran) Date: Sat, 3 Mar 2007 18:33:36 +0100 Subject: mac80211 and iwlwifi (was Re: d80211 and iwlwifi) In-Reply-To: <45E9ADAC.6070003@warmcat.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <20070303161100.GC3511@redhat.com> <45E9ADAC.6070003@warmcat.com> Message-ID: On 3/3/07, Andy Green wrote: > > John W. Linville wrote: > > > YMMV...I haven't been able to make it work yet on my Sony Vaio... > > what is exactly your problem? I have to load it by hand with no alias in modprobe.conf to get it to wotk... > Send the bug reports (and patches!) to me...thanks! > > Working great for me in a Samsung Q35. Note I am using wpa_supplicant > patched with the "dscape patch" > > > http://kernel.org/pub/linux/kernel/people/jbenc/ieee80211-utils/wpa_supplicant/wpa_supplicant-0.4.7_dscape-02.patch > > Not certain if that is a necessary ingredient for success or not. it is if you want to use wpa/wpa2 -Andy > > -- > 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 michel.salim at gmail.com Sun Mar 4 00:36:20 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sat, 3 Mar 2007 19:36:20 -0500 Subject: Regression in importing Word document Message-ID: <883cfe6d0703031636u4adff1e7o8b74bc943c596d50@mail.gmail.com> bz #230867: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230867 (OO.o) bz #230868: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230868 (Abiword) This following Word document: http://hircus.org/fedora/word-bug/CDF-Flyer.doc reliably crashes Abiword and OpenOffice in Rawhide on my x86_64 machine. Could someone take a look and see if it crashes on Rawhide/i386 and FC6/any ? It opens fine on a friend's Ubuntu installation, with OpenOffice 2.1 Thanks! PS Rawhide + Crossover + Office 2003 opens it fine, and ClamAV does not detect any virus -- Michel Salim http://hircus.wordpress.com/ From bernie at develer.com Sun Mar 4 01:10:55 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Sun, 04 Mar 2007 02:10:55 +0100 Subject: Fedora safe/recovery mode In-Reply-To: References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> Message-ID: <45EA1C9F.2000102@develer.com> Thomas M Steenholdt wrote: > On runlevel 2-5, the user is presented with a login screen. I haven't > tested this in fedora for some months, but last I checked, runlevel 1 > dropped the user directly in a root shell. Other distros ask for the root password, but I prefer the Fedora way. Rationale: if I can tell grub to boot in single-user mode, then I can also edit the kernel command line to add "init=/bin/bash" and skip the password prompt altogether. If you want the local console to be secure, you'd need to set a bios password, grub password, disable floppy/cdrom boot and probably also lock the case so it can't be tampered. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Sun Mar 4 01:18:37 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Sun, 04 Mar 2007 02:18:37 +0100 Subject: failsafe X session Message-ID: <45EA1E6D.7010404@develer.com> Where has the "failsafe" X session gone? I can only see Gnome and KDE in the GDM session menu. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Sun Mar 4 01:17:07 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Sun, 04 Mar 2007 02:17:07 +0100 Subject: Fedora safe/recovery mode In-Reply-To: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> Message-ID: <45EA1E13.9010102@develer.com> Arthur Pemberton wrote: > It seems like a common enough recurrence that someone, often times a > person new to Fedora needs to boot to runlevel 3. Seems like it would > be advantageous to have a boot target that goes to runlevel 3 all the > time. > > What does the list think? I favor it. And as we're there, we could also add the typical set of troubleshooting options: noacpi, noapic, nosmp, noioapic, pci=irqroute... Actually, I've recently seen many boxes hanging during boot with ACPI or SMP disabled. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From otto_rey at yahoo.com.ar Sun Mar 4 02:38:25 2007 From: otto_rey at yahoo.com.ar (Otto Rey) Date: Sat, 3 Mar 2007 18:38:25 -0800 (PST) Subject: Regression in importing Word document Message-ID: <444288.83309.qm@web52408.mail.yahoo.com> Under updated FC6, load without problems. ----- Mensaje original ---- De: Michel Salim Para: Fedora Devel ; Fedora Test Enviado: s?bado 3 de marzo de 2007, 21:36:20 Asunto: Regression in importing Word document bz #230867: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230867 (OO.o) bz #230868: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230868 (Abiword) This following Word document: http://hircus.org/fedora/word-bug/CDF-Flyer.doc reliably crashes Abiword and OpenOffice in Rawhide on my x86_64 machine. Could someone take a look and see if it crashes on Rawhide/i386 and FC6/any ? It opens fine on a friend's Ubuntu installation, with OpenOffice 2.1 Thanks! PS Rawhide + Crossover + Office 2003 opens it fine, and ClamAV does not detect any virus -- Michel Salim http://hircus.wordpress.com/ -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list __________________________________________________ Pregunt?. Respond?. Descubr?. Todo lo que quer?as saber, y lo que ni imaginabas, est? en Yahoo! Respuestas (Beta). ?Probalo ya! http://www.yahoo.com.ar/respuestas -------------- next part -------------- An HTML attachment was scrubbed... URL: From cr33dog at gmail.com Sun Mar 4 02:21:39 2007 From: cr33dog at gmail.com (Chris Mohler) Date: Sat, 3 Mar 2007 20:21:39 -0600 Subject: Regression in importing Word document In-Reply-To: <883cfe6d0703031636u4adff1e7o8b74bc943c596d50@mail.gmail.com> References: <883cfe6d0703031636u4adff1e7o8b74bc943c596d50@mail.gmail.com> Message-ID: On 3/3/07, Michel Salim wrote: > This following Word document: http://hircus.org/fedora/word-bug/CDF-Flyer.doc > reliably crashes Abiword and OpenOffice in Rawhide on my x86_64 > machine. Could someone take a look and see if it crashes on > Rawhide/i386 and FC6/any ? Opens for me OK: FC6 & OO 2.0.4. Also OK with Abiword 2.4.6, although the clipart doesn't show up. Chris From kagesenshi.87 at gmail.com Sun Mar 4 05:00:50 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Sun, 4 Mar 2007 13:00:50 +0800 Subject: Regression in importing Word document In-Reply-To: References: <883cfe6d0703031636u4adff1e7o8b74bc943c596d50@mail.gmail.com> Message-ID: On 3/3/07, Michel Salim wrote: > This following Word document: http://hircus.org/fedora/word-bug/CDF-Flyer.doc > reliably crashes Abiword and OpenOffice in Rawhide on my x86_64 > machine. Could someone take a look and see if it crashes on > Rawhide/i386 and FC6/any ? Opens fine on rawhide -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? Universiti Teknologi PETRONAS ICT 2nd Year 1st Semester mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com GPG: http://www.rootshell.be/~kagesens/public-key.asc Blog: http://kagesenshi.blogspot.com ----------------------------------------------- From fedora-gmane.00003 at genesis-x.nildram.co.uk Sun Mar 4 08:03:58 2007 From: fedora-gmane.00003 at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Sun, 04 Mar 2007 08:03:58 +0000 Subject: Is there a String Resource equivalent in RPM? In-Reply-To: <1172618962.4032.39.camel@shinybook.infradead.org> References: <6.2.1.2.2.20070227110450.059ac750@mailone.real.com> <1172618962.4032.39.camel@shinybook.infradead.org> Message-ID: <64bqb4-lol.ln1@sky.matrix> Verily I say unto thee, that David Woodhouse spake thusly: > On Tue, 2007-02-27 at 11:15 -0800, Daniel Yek wrote: >> I guess a less-optimal compromise is to repackage the RPM only, without >> rebuild the binary tar ball, so that files can be modified or added before >> repackaging. >> >> What is the least effort, best practice? > > If you want to _add_ files, it's best to ship them in a separate > package. If you're thinking of separate codecs, for example, that's > probably the best way to do it. > > Modifying files sounds wrong, And would break GPG signing. -- K. http://slated.org - Slated, Rated & Blogged Fedora Core release 5 (Bordeaux) on sky, running kernel 2.6.19-1.2288.fc5 08:02:17 up 12 days, 19:27, 2 users, load average: 1.16, 0.59, 0.22 From fedora-gmane.00003 at genesis-x.nildram.co.uk Sun Mar 4 08:01:02 2007 From: fedora-gmane.00003 at genesis-x.nildram.co.uk (Keith G. Robertson-Turner) Date: Sun, 04 Mar 2007 08:01:02 +0000 Subject: Why Firefox's About Window is Resizable In-Reply-To: References: <20070228075513.GB15997@yantp.dyndns.org> Message-ID: Verily I say unto thee, that DElyMyth spake thusly: > On 2/28/07, Yan Li wrote: >> >> Sorry if OT, since I haven't tried Firefox on distros other than >> Fedora. > > It's resizable on SuSE too, I guess it's related to the browser itself > and not to the distribution... Surely this is a feature of X11, rather than application specific. IIRC a noresize bit must be set in the app, and not overridden by the Window Manager. So either Mozilla have missed a bit setting or Metacity is overriding fixed windows. -- K. http://slated.org - Slated, Rated & Blogged Fedora Core release 5 (Bordeaux) on sky, running kernel 2.6.19-1.2288.fc5 07:58:17 up 12 days, 19:23, 2 users, load average: 0.13, 0.07, 0.02 From tmus at tmus.dk Sun Mar 4 07:36:11 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sun, 04 Mar 2007 08:36:11 +0100 Subject: Fedora safe/recovery mode In-Reply-To: <45EA1C9F.2000102@develer.com> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> <45EA1C9F.2000102@develer.com> Message-ID: Bernardo Innocenti wrote: > > Other distros ask for the root password, but I prefer the Fedora way. > > Rationale: if I can tell grub to boot in single-user mode, then I > can also edit the kernel command line to add "init=/bin/bash" and > skip the password prompt altogether. > > If you want the local console to be secure, you'd need to set > a bios password, grub password, disable floppy/cdrom boot and > probably also lock the case so it can't be tampered. > We just have to make sure that we don't end up with an easy way in, presented right there in the grub menu... You can choose another stanza to boot from grub without the password, but with the password set, you cannot set init=/bin/bash. There's a thousand other ways to gain access once you're at the machine, but we should not make it that easy. /Thomas From kagesenshi.87 at gmail.com Sun Mar 4 10:16:32 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Sun, 4 Mar 2007 18:16:32 +0800 Subject: Why Firefox's About Window is Resizable In-Reply-To: References: <20070228075513.GB15997@yantp.dyndns.org> Message-ID: On 3/4/07, Keith G. Robertson-Turner wrote: > IIRC a noresize bit must be set in the app, and not overridden by the > Window Manager. So either Mozilla have missed a bit setting or Metacity > is overriding fixed windows. its resizable on Beryl/Compiz too, so metacity is not the reason. The problem most probably from Firefox itself. or maybe the graphic library /my 2c -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? Universiti Teknologi PETRONAS ICT 2nd Year 1st Semester mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com GPG: http://www.rootshell.be/~kagesens/public-key.asc Blog: http://kagesenshi.blogspot.com ----------------------------------------------- From buildsys at redhat.com Sun Mar 4 11:32:06 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sun, 4 Mar 2007 06:32:06 -0500 Subject: rawhide report: 20070304 changes Message-ID: <200703041132.l24BW6Mc002326@hs20-bc2-6.build.redhat.com> Updated Packages: ConsoleKit-0.1.3-0.git20070301.1.fc7 ------------------------------------ * Sat Mar 03 2007 David Zeuthen - 0.1.3-0.git20070301.1 - Allow caller to pass uid=0 in libck-connector compat-gcc-34-3.4.6-7 --------------------- util-linux-2.13-0.50.fc7 ------------------------ * Sat Mar 03 2007 David Zeuthen 2.13-0.50 - include ConsoleKit session module by default (#229172) Broken deps for i386 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.i386 requires libgcj.so.7rh frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh Broken deps for ia64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ia64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ia64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.ia64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ia64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ia64 requires lm_sensors-devel Broken deps for x86_64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) cairo-java - 1.0.5-4.fc7.i386 requires libgcj.so.7rh frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.x86_64 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libgconf-java - 2.12.4-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) Broken deps for s390 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.s390 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel 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 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ppc64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.ppc64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ppc64 requires lm_sensors-devel Broken deps for ppc ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ppc requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.ppc requires libofx.so.3 gnucash - 2.0.5-1.fc6.ppc requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.ppc requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.ppc requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.ppc requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.ppc requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.ppc requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.ppc requires lm_sensors-devel Broken deps for s390x ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.s390 requires libgcj.so.7rh cairo-java - 1.0.5-4.fc7.s390x requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libofx.so.3()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.s390x requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libgconf-java - 2.12.4-5.fc7.s390x requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390x requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.s390x requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.s390x requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390x requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel net-snmp-devel - 1:5.4-10.fc7.s390x requires lm_sensors-devel From mschwendt.tmp0701.nospam at arcor.de Sun Mar 4 12:34:21 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 4 Mar 2007 13:34:21 +0100 Subject: umask in rpm scriptlets - yes or no? Message-ID: <20070304133421.94f858e1.mschwendt.tmp0701.nospam@arcor.de> I believe we've tried to discuss this in the past, but I'm unable to find a related topic on several lists (packaging, extras, maintainers) and in the Wiki. A restrictive umask still causes RPM scriptlets to create inaccessible files (and it still affects unowned directories, too, btw). For example, a superuser with umask 077 installs a package, which runs "/usr/bin/update-mime-database /usr/share/mime" in %post. The result will be files that are readable only by root. A very recent example, that might be related could be this: https://bugzilla.redhat.com/230781 Does anybody know whether anything has been decided on setting an explicit "umask 022" at the beginning of scriptlets? From mtasaka at ioa.s.u-tokyo.ac.jp Sun Mar 4 12:33:42 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 04 Mar 2007 21:33:42 +0900 Subject: umask in rpm scriptlets - yes or no? In-Reply-To: <20070304133421.94f858e1.mschwendt.tmp0701.nospam@arcor.de> References: <20070304133421.94f858e1.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45EABCA6.1000703@ioa.s.u-tokyo.ac.jp> Michael Schwendt wrote: > Does anybody know whether anything has been decided on setting an > explicit "umask 022" at the beginning of scriptlets? I don't know the example of 022, however for 133 I know a example. -------------------------------------------------------- [tasaka1 at localhost i386]$ rpm -q --scripts fonts-japanese postinstall scriptlet (using /bin/sh): { umask 133 touch /usr/share/fonts/japanese/TrueType 2> /dev/null && { /usr/bin/ttmkfdir -d /usr/share/fonts/japanese/TrueType -o /usr/share/fonts/japanese/TrueType/fonts.scale mkfontdir /usr/share/fonts/japanese/TrueType /usr/sbin/chkfontpath -q -a /usr/share/fonts/japanese/TrueType } mkfontdir /usr/share/fonts/japanese/misc && /usr/sbin/chkfontpath -q -a /usr/share/fonts/japanese/misc if [ -x /usr/bin/fc-cache ]; then /usr/bin/fc-cache /usr/share/fonts fi } postuninstall scriptlet (using /bin/sh): -------------------------------------------------------- Mamoru From mschwendt.tmp0701.nospam at arcor.de Sun Mar 4 12:52:15 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sun, 4 Mar 2007 13:52:15 +0100 Subject: umask in rpm scriptlets - yes or no? In-Reply-To: <45EABCA6.1000703@ioa.s.u-tokyo.ac.jp> References: <20070304133421.94f858e1.mschwendt.tmp0701.nospam@arcor.de> <45EABCA6.1000703@ioa.s.u-tokyo.ac.jp> Message-ID: <20070304135215.b1bfee30.mschwendt.tmp0701.nospam@arcor.de> On Sun, 04 Mar 2007 21:33:42 +0900, Mamoru Tasaka wrote: > > Does anybody know whether anything has been decided on setting an > > explicit "umask 022" at the beginning of scriptlets? > > I don't know the example of 022, however for 133 I know > a example. 022 (g-w,o-w) is a subset of 0133 (u-x,g-wx,o-wx), so they are closely related. From rdieter at math.unl.edu Sun Mar 4 13:27:12 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 04 Mar 2007 07:27:12 -0600 Subject: umask in rpm scriptlets - yes or no? In-Reply-To: <20070304133421.94f858e1.mschwendt.tmp0701.nospam@arcor.de> References: <20070304133421.94f858e1.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt wrote: > Does anybody know whether anything has been decided on setting an > explicit "umask 022" at the beginning of scriptlets? Looks like it's not a bad idea. -- Rex From caolanm at redhat.com Sun Mar 4 13:14:39 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Sun, 04 Mar 2007 13:14:39 +0000 Subject: Regression in importing Word document, a11y In-Reply-To: References: <883cfe6d0703031636u4adff1e7o8b74bc943c596d50@mail.gmail.com> Message-ID: <1173014080.7701.25.camel@soulcrusher.caolan.org> On Sun, 2007-03-04 at 13:00 +0800, Hikaru Amano wrote: > On 3/3/07, Michel Salim wrote: > > This following Word document: http://hircus.org/fedora/word-bug/CDF-Flyer.doc > > reliably crashes Abiword and OpenOffice in Rawhide on my x86_64 > > machine. Could someone take a look and see if it crashes on > > Rawhide/i386 and FC6/any ? > > Opens fine on rawhide Remember to compare like with like, For the OOo crash, Arch is x86_64, Desktop is GNOME, accessibility is true and SELinux is enabled & permissive. In this case the magic factor is having a11y enabled. Workaround is to disable a11y for the moment while I have a look at it :-) C. From enrico.scholz at informatik.tu-chemnitz.de Sun Mar 4 14:00:05 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 04 Mar 2007 15:00:05 +0100 Subject: Fedora safe/recovery mode In-Reply-To: (Thomas M. Steenholdt's message of "Sat, 03 Mar 2007 20:29:28 +0100") References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> Message-ID: <87slcl6rdm.fsf@kosh.bigo.ensc.de> tmus at tmus.dk (Thomas M Steenholdt) writes: >>>> AP> Seems like it would be advantageous to have a boot target that >>>> AP> goes to runlevel 3 all the time. >>> ... >>> I think he suggesting a default entry for that in a fedora >>> installation .. eg: a grub option with the title "Recovery Console" >> /me would expect runlevel 1 behind 'Recovery Console', but not 3... >> Enrico >> > > There are some security considerations with runlevel 1. Either it is a "Recovery Console", or it is not a "Recovery Console". From such a console, I would expect that I can recover from lost passwords and/or can fix network settings which prevent successful root logins. When you want an extra entry for runlevel 3, then name it like 'Text console' but do not begin DAUification already at the Grub menu and use terms with a completely different meaning. > On runlevel 2-5, the user is presented with a login screen. I haven't > tested this in fedora for some months, but last I checked, runlevel 1 > dropped the user directly in a root shell. > > Runlevel 3 is at least as safe as runlevel 5 and could be used with no > security implications. As long as Grub and the BIOS are not protected with a password by default, we do not need to discuss this.... Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From cra at WPI.EDU Sun Mar 4 14:45:22 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 4 Mar 2007 09:45:22 -0500 Subject: Fedora safe/recovery mode In-Reply-To: <87slcl6rdm.fsf@kosh.bigo.ensc.de> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> <87slcl6rdm.fsf@kosh.bigo.ensc.de> Message-ID: <20070304144522.GR3334@angus.ind.WPI.EDU> On Sun, Mar 04, 2007 at 03:00:05PM +0100, Enrico Scholz wrote: > > tested this in fedora for some months, but last I checked, runlevel 1 > > dropped the user directly in a root shell. > > > > Runlevel 3 is at least as safe as runlevel 5 and could be used with no > > security implications. > > As long as Grub and the BIOS are not protected with a password by > default, we do not need to discuss this.... Does grub have a "secure" flag you can put in a stanza to require grub to prompt for a password? That would solve the security concern. From cra at WPI.EDU Sun Mar 4 15:01:03 2007 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 4 Mar 2007 10:01:03 -0500 Subject: Fedora safe/recovery mode In-Reply-To: <20070304144522.GR3334@angus.ind.WPI.EDU> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> <87slcl6rdm.fsf@kosh.bigo.ensc.de> <20070304144522.GR3334@angus.ind.WPI.EDU> Message-ID: <20070304150103.GS3334@angus.ind.WPI.EDU> On Sun, Mar 04, 2007 at 09:45:22AM -0500, Chuck Anderson wrote: > On Sun, Mar 04, 2007 at 03:00:05PM +0100, Enrico Scholz wrote: > > > tested this in fedora for some months, but last I checked, runlevel 1 > > > dropped the user directly in a root shell. > > > > > > Runlevel 3 is at least as safe as runlevel 5 and could be used with no > > > security implications. > > > > As long as Grub and the BIOS are not protected with a password by > > default, we do not need to discuss this.... > > Does grub have a "secure" flag you can put in a stanza to require grub > to prompt for a password? That would solve the security concern. Answering myself: -- Command: lock Prevent normal users from executing arbitrary menu entries. You must use the command `password' if you really want this command to be useful (*note password::). This command is used in a menu, as shown in this example: title This entry is too dangerous to be executed by normal users lock root (hd0,a) kernel /no-security-os See also *Note Security::. under *Note Security*: Also, you can specify an optional argument to `password'. See this example: password PASSWORD /boot/grub/menu-admin.lst In this case, GRUB will load `/boot/grub/menu-admin.lst' as a configuration file when you enter the valid password. From linville at redhat.com Sun Mar 4 16:12:32 2007 From: linville at redhat.com (John W. Linville) Date: Sun, 4 Mar 2007 11:12:32 -0500 Subject: mac80211 and iwlwifi (was Re: d80211 and iwlwifi) In-Reply-To: <45E9CDEE.6050609@gmail.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <20070303161100.GC3511@redhat.com> <45E9CDEE.6050609@gmail.com> Message-ID: <20070304161232.GA28302@redhat.com> On Sat, Mar 03, 2007 at 02:35:10PM -0500, eric magaoay wrote: > John W. Linville wrote: > >I have test kernels w/ iwlwifi here: > > > > http://people.redhat.com/linville/kernels/fc7/ > > > >If you have ipw3945 hardware, please give them a try. You will need > >to get the firmware from here: > > > > http://intellinuxwireless.org > > > >YMMV...I haven't been able to make it work yet on my Sony Vaio... > > > >Send the bug reports (and patches!) to me...thanks! > > > >John > > > > John, > > Will zd1211rw (zydas) module be included into the latest FC devel. > build? I tried to git clone your wireless-2.6 a couple of days ago for > testing but failed to complete due checksum error. It should be there already, both the mac80211 version and the previous version. You may wish to blacklist the one that you don't want. Hth! John -- John W. Linville linville at redhat.com From hughsient at gmail.com Sun Mar 4 16:17:22 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 4 Mar 2007 16:17:22 +0000 Subject: mac80211 and iwlwifi (was Re: d80211 and iwlwifi) In-Reply-To: <20070304161232.GA28302@redhat.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <20070303161100.GC3511@redhat.com> <45E9CDEE.6050609@gmail.com> <20070304161232.GA28302@redhat.com> Message-ID: <15e53e180703040817h2f00ca1fgc554063259cfffd8@mail.gmail.com> On 04/03/07, John W. Linville wrote: > On Sat, Mar 03, 2007 at 02:35:10PM -0500, eric magaoay wrote: > > John W. Linville wrote: > > >I have test kernels w/ iwlwifi here: > > > > > > http://people.redhat.com/linville/kernels/fc7/ > > > > > >If you have ipw3945 hardware, please give them a try. You will need > > >to get the firmware from here: > > > > > > http://intellinuxwireless.org > > > > > >YMMV...I haven't been able to make it work yet on my Sony Vaio... > > > > > >Send the bug reports (and patches!) to me...thanks! > > > > > >John > > > > > > > John, > > > > Will zd1211rw (zydas) module be included into the latest FC devel. > > build? I tried to git clone your wireless-2.6 a couple of days ago for > > testing but failed to complete due checksum error. > > It should be there already, both the mac80211 version and the previous > version. You may wish to blacklist the one that you don't want. I think the zd1211rw and softmac drivers ought to be disabled in the .config for FC7 release, else both drivers get loaded on boot. I also think the iwlwifi driver should be added to the rawhide kernel, as the worst case scenario is that already-not-working hardware does not work. Best case scenario is that the hardware just works. Richard. From bpepple at fedoraproject.org Sun Mar 4 18:00:40 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 04 Mar 2007 13:00:40 -0500 Subject: FESCo Meeting Summary for 2007-03-01 Message-ID: <1173031240.9205.6.camel@Chuck> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Christian Iseli (ch4chris) * Josh Boyer (jwb) * Rex Dieter (rdieter) * Toshio Kuratomi (abadger1999) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Bill Nottingham (notting) * Jesse Keating (f13) * Jeremy Katz (jeremy) === Absent === * Tom Callaway (spot) * Warren Togami (warren) == Summary == repo-creation using new createrepo * f13 is currently working on using the new createrepo in the development branch. * There is no plan to use the new createrepo in FC6. Sponsor Nominations * Fernando Nasser was nominated and accepted as a new sponsor. Fedora 7 preparation * the plan is not to do a mass rebuild of extras packages. * nirik is going to setup a page on the wiki to track other preparation issues that we need to track for F7. Packaging Committee Report * FESCo approved the Packaging Committee's guidelines regarding: * InitScripts proposal: http://fedoraproject.org/wiki/PackagingDrafts/InitScripts * BuildRoot proposal: http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070301 Thanks. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Sun Mar 4 18:23:35 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 04 Mar 2007 19:23:35 +0100 Subject: FPC Meeting Summaries? (Re: FESCo Meeting Summary for 2007-03-01) In-Reply-To: <1173031240.9205.6.camel@Chuck> References: <1173031240.9205.6.camel@Chuck> Message-ID: <45EB0EA7.8030405@leemhuis.info> Brian Pepple schrieb: > [...] > Packaging Committee Report > * FESCo approved the Packaging Committee's guidelines regarding: > * InitScripts proposal: > http://fedoraproject.org/wiki/PackagingDrafts/InitScripts > * BuildRoot proposal: > http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot Just wondering: Why isn't the PC sending any reports/summaries to fedora-maintainers anymore (or did I miss them all in the past weeks?)? That was part of the arrangement between FESCo and FPC iirc; to quote http://www.fedoraproject.org/wiki/Extras/Schedule "A representative from the packaging committee will send a report after each committee meeting to fedora-maintainers at redhat.com for public discussion. In order to give ample discussion time, this report should be sent no less than 24 hours before the next FESCo meeting; if the report is late, the veto period will be extended by one additional FESCo meeting. FESCo may also extend the veto period if there is still ongoing discussion." That text should be adjusted if the arrangement got changed. But I think Meeting summaries from the FPC with a short notice what got accepted (like Brian did in his FESCo report) are quite important. Yes, I know that it's hard work (I did FESCo reports myself for quite some time), and no, I'm not volunteering to do it myself, as I don't follow the FPCs meetings/discussions that closely (and that's the reasons why I'd like to have a summary). CU thl From jkeating at redhat.com Sun Mar 4 20:41:55 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 4 Mar 2007 15:41:55 -0500 Subject: Fedora safe/recovery mode In-Reply-To: <20070304144522.GR3334@angus.ind.WPI.EDU> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87slcl6rdm.fsf@kosh.bigo.ensc.de> <20070304144522.GR3334@angus.ind.WPI.EDU> Message-ID: <200703041541.55930.jkeating@redhat.com> On Sunday 04 March 2007 09:45:22 Chuck Anderson wrote: > Does grub have a "secure" flag you can put in a stanza to require grub > to prompt for a password? ?That would solve the security concern. Yes, but only for the languages your bios/grub supports, so translations are difficult at best. -- 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 jacliburn at bellsouth.net Sun Mar 4 15:53:26 2007 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sun, 4 Mar 2007 09:53:26 -0600 Subject: yum delay processing exclude list Message-ID: <20070304095326.35414173@osprey.hogchain.net> I have an x86_64 rawhide machine that's configured to exclude all i?86 packages from updates, and lately it takes a *very* long time to go through the global exclude list during a yum update. If I remove "exclude=*i?86" from yum.conf, the update proceeds at the speed to which I'm accustomed. With "exclude=*.i?86" in yum.conf, an (empty) update takes up to a minute and a half, and pegs both my cpus. Without "exclude=*i?86," the same update takes less than 3 seconds. With extras-development enabled, processing the global exclude list takes over 5 minutes. Is this a bug, or expected behavior with rawhide yum (3.1.3-2.fc7)? ********** WITHOUT exclude=*.i?86 ************ [root at osprey ~]# time yum --disablerepo=extras-development update Loading "skip-broken" plugin Loading "installonlyn" plugin Setting up Update Process Excluding Packages in global exclude list Finished No Packages marked for Update/Obsoletion real 0m2.227s user 0m1.454s sys 0m0.759s ********** WITH exclude=*.i?86 ************ [root at hawk ~]# time yum --disablerepo=extras-development update Loading "installonlyn" plugin Setting up Update Process Excluding Packages in global exclude list Finished No Packages marked for Update/Obsoletion real 1m21.764s user 0m49.367s sys 0m31.317s ********** WITH exclude=*.i?86 ************ [root at hawk ~]# time yum update Loading "installonlyn" plugin Setting up Update Process Excluding Packages in global exclude list Finished No Packages marked for Update/Obsoletion real 5m10.460s user 3m27.026s sys 1m43.108s From ndbecker2 at gmail.com Sun Mar 4 21:02:33 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 04 Mar 2007 16:02:33 -0500 Subject: checkpoint/restart Message-ID: One of the features I'd really like to see more widely used in the linux world is checkpoint/restart. I want it for long-running simulations, although there may be other uses. Basic requirement: 1) checkpoint a running process and be able to restart on the same machine. Restore open files, including mappings of shared memory. More advanced: 2) Migrate a process to another machine (probably with same libraries). 3) Handle multiple threads/processes? I am pleased to find that blcr http://ftg.lbl.gov/CheckpointRestart/CheckpointRestart.shtml seems to do just what I need. It has an srpm and (with minor change) builds/runs fine of fc6 x86_64. I have been following this area for last several years. There have been several starts at other checkpoint projects, but all except blcr seem to have died. I think this is really exciting technology and I'm betting others will want to see this added to Fedora. From nicolas.mailhot at laposte.net Sun Mar 4 21:12:14 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 04 Mar 2007 22:12:14 +0100 Subject: yum delay processing exclude list In-Reply-To: <20070304095326.35414173@osprey.hogchain.net> References: <20070304095326.35414173@osprey.hogchain.net> Message-ID: <1173042734.19549.3.camel@rousalka.dyndns.org> Le dimanche 04 mars 2007 ? 09:53 -0600, Jay Cliburn a ?crit : > With extras-development enabled, processing the global exclude list > takes over 5 minutes. > > Is this a bug, or expected behavior with rawhide yum (3.1.3-2.fc7)? It's expected unoptimized behaviour if I understand Seth correctly And yes, I'm thinking unkind things about it too. If I hadn't got a dual core system that would be unbearable -- 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 michael.vanderheeren at gmail.com Sun Mar 4 17:10:13 2007 From: michael.vanderheeren at gmail.com (=?iso-8859-1?Q?Micha=EBl_Vanderheeren?=) Date: Sun, 4 Mar 2007 18:10:13 +0100 Subject: FW: F7 T2 Security Leak? Message-ID: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> I think there's a security leak in F7. I found out the next thing: Look at this situation: There are 2 accounts on a computer, call them A and B. Each account has it's own different password. Person A starts up the computer and logs in. But at a certain point person B wants to use his account for 5 minutes. So he uses the Fast User Switch. As this happens person A's account stays active. But person B can switch back to person A's account without entering a password! So if person A is gone for a while, person B can steal his documents, delete files, Greetings, Micha?l Vanderheeren -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lam at Lam.pl Sun Mar 4 21:15:43 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 04 Mar 2007 22:15:43 +0100 Subject: Fedora safe/recovery mode In-Reply-To: <87slcl6rdm.fsf@kosh.bigo.ensc.de> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> <87slcl6rdm.fsf@kosh.bigo.ensc.de> Message-ID: <1173042943.5427.5.camel@pensja.lam.pl> Dnia 04-03-2007, nie o godzinie 15:00 +0100, Enrico Scholz napisa?(a): > > There are some security considerations with runlevel 1. > Either it is a "Recovery Console", or it is not a "Recovery Console". There already was a brief discussion about adding a small rescue filesystem in /boot, which would be better than running "single" AKA runlevel 1. This would be the true recovery console, operational even when the shell from our "real" fs doesn't even start (because some mor^H^H^HESR^H^H^Huser removed shared libraries). Where did this idea go? Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From jkeating at redhat.com Sun Mar 4 21:18:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 4 Mar 2007 16:18:08 -0500 Subject: FW: F7 T2 Security Leak? In-Reply-To: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> Message-ID: <200703041618.09066.jkeating@redhat.com> On Sunday 04 March 2007 12:10:13 Micha?l Vanderheeren wrote: > There are 2 accounts on a computer, call them A and B. Each account has > it's own different password. > > Person A starts up the computer and logs in. But at a certain point person > B wants to use his account for 5 minutes. So he uses the Fast User Switch. > As this happens person A's account stays active. But? person B can switch > back to person A's account without entering a password! So if person A is > gone for a while, person B can steal his documents, delete files, ? Fast User Switching by default enables the screen lock when a user is switched away from. Could there be a problem with your screen lock? Please keep in mind that any assumption of security is completely out of the water if folks have physical access to your computer, which they must have for fast user switching. -- 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 skvidal at linux.duke.edu Sun Mar 4 21:26:56 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 04 Mar 2007 16:26:56 -0500 Subject: yum delay processing exclude list In-Reply-To: <1173042734.19549.3.camel@rousalka.dyndns.org> References: <20070304095326.35414173@osprey.hogchain.net> <1173042734.19549.3.camel@rousalka.dyndns.org> Message-ID: <1173043616.30992.19.camel@cutter> On Sun, 2007-03-04 at 22:12 +0100, Nicolas Mailhot wrote: > Le dimanche 04 mars 2007 ? 09:53 -0600, Jay Cliburn a ?crit : > > > With extras-development enabled, processing the global exclude list > > takes over 5 minutes. > > > > Is this a bug, or expected behavior with rawhide yum (3.1.3-2.fc7)? > > It's expected unoptimized behaviour if I understand Seth correctly > And yes, I'm thinking unkind things about it too. If I hadn't got a dual > core system that would be unbearable no, that's not what I said. I said if you saw slowness in depsolving that was expected. This is outside of depsolving and is not expected. I'm looking into it to see why the exclude is taking so much time. thanks, -sv From ndbecker2 at gmail.com Sun Mar 4 21:25:59 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Sun, 04 Mar 2007 16:25:59 -0500 Subject: FW: F7 T2 Security Leak? References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <200703041618.09066.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Sunday 04 March 2007 12:10:13 Micha?l Vanderheeren wrote: >> There are 2 accounts on a computer, call them A and B. Each account has >> it's own different password. >> >> Person A starts up the computer and logs in. But at a certain point >> person B wants to use his account for 5 minutes. So he uses the Fast User >> Switch. As this happens person A's account stays active. But? person B >> can switch back to person A's account without entering a password! So if >> person A is gone for a while, person B can steal his documents, delete >> files, ? > > Fast User Switching by default enables the screen lock when a user is > switched > away from. Could there be a problem with your screen lock? > > Please keep in mind that any assumption of security is completely out of > the water if folks have physical access to your computer, which they must > have for fast user switching. > This comment is a bit extreme. True, in principal there is no security without physical security - but that hardly means we should offer an open invitation. From jkeating at redhat.com Sun Mar 4 21:29:17 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 4 Mar 2007 16:29:17 -0500 Subject: FW: F7 T2 Security Leak? In-Reply-To: References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <200703041618.09066.jkeating@redhat.com> Message-ID: <200703041629.17219.jkeating@redhat.com> On Sunday 04 March 2007 16:25:59 Neal Becker wrote: > This comment is a bit extreme. ?True, in principal there is no security > without physical security - but that hardly means we should offer an open > invitation. Sure, but if you have a session running on TTY6 and you give somebody TTY7, they can physically switch back to TTY6 and have your session. Just like if you left yourself logged in at any of the virtual consoles. That said, my original point should stand, that fast user switching relies upon gnome screensaver to lock the screen. Is that failing for the original poster in some way? (note, gnome-screensaver does not lock the Root's screen, don't log in as root) -- 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 skvidal at linux.duke.edu Sun Mar 4 21:37:00 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 04 Mar 2007 16:37:00 -0500 Subject: yum delay processing exclude list In-Reply-To: <1173043616.30992.19.camel@cutter> References: <20070304095326.35414173@osprey.hogchain.net> <1173042734.19549.3.camel@rousalka.dyndns.org> <1173043616.30992.19.camel@cutter> Message-ID: <1173044220.30992.22.camel@cutter> On Sun, 2007-03-04 at 16:26 -0500, seth vidal wrote: > On Sun, 2007-03-04 at 22:12 +0100, Nicolas Mailhot wrote: > > Le dimanche 04 mars 2007 ? 09:53 -0600, Jay Cliburn a ?crit : > > > > > With extras-development enabled, processing the global exclude list > > > takes over 5 minutes. > > > > > > Is this a bug, or expected behavior with rawhide yum (3.1.3-2.fc7)? > > > > It's expected unoptimized behaviour if I understand Seth correctly > > And yes, I'm thinking unkind things about it too. If I hadn't got a dual > > core system that would be unbearable > > no, that's not what I said. I said if you saw slowness in depsolving > that was expected. This is outside of depsolving and is not expected. > I'm looking into it to see why the exclude is taking so much time. > found it. It's been fixed in cvs. It took the exclude processing time from 2 minutes on my little laptop to <10s. I'm willing to accept that. :) thanks for reporting it. -sv From jacliburn at bellsouth.net Sun Mar 4 22:13:59 2007 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Sun, 4 Mar 2007 16:13:59 -0600 Subject: yum delay processing exclude list In-Reply-To: <1173044220.30992.22.camel@cutter> References: <20070304095326.35414173@osprey.hogchain.net> <1173042734.19549.3.camel@rousalka.dyndns.org> <1173043616.30992.19.camel@cutter> <1173044220.30992.22.camel@cutter> Message-ID: <20070304161359.1c3e3e9e@osprey.hogchain.net> On Sun, 04 Mar 2007 16:37:00 -0500 seth vidal wrote: > found it. It's been fixed in cvs. It took the exclude processing time > from 2 minutes on my little laptop to <10s. I'm willing to accept > that. :) Sounds much better. Thanks for fixing it. From kwizart at gmail.com Sat Mar 3 20:48:17 2007 From: kwizart at gmail.com (KH KH) Date: Sat, 3 Mar 2007 21:48:17 +0100 Subject: mac80211 and iwlwifi (was Re: d80211 and iwlwifi) In-Reply-To: <4c4ba1530703031018s44d72eb7va6331af3b72e382e@mail.gmail.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <20070303161100.GC3511@redhat.com> <4c4ba1530703031018s44d72eb7va6331af3b72e382e@mail.gmail.com> Message-ID: >Will zd1211rw (zydas) module be included into the latest FC devel. >build? I tried to git clone your wireless-2.6 a couple of days ago for >testing but failed to complete due checksum error. zd1211-d80211 is already is kernel.org 2.6.21rc1 fedora-devel is using (named 2.6.20 because of release candidate 1) you may need to use echo "blacklist zd1211rw" >> /etc/modprobe.d/blacklist echo "blacklist zd1211" >> /etc/modprobe.d/blacklist echo "alias wmaster0 zd1211rw-mac80211" >> /etc/modprobe.conf echo "alias wlan0 zd1211rw-mac80211" >> /etc/modprobe.conf zd1211-firmware is now GPL and in review here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221675 last version generates firmware from sources I might be tested (you can just rebuild it normally - or find it on the same dir) > > Association fails both with WEP and 'no key'. > > tom Will you have better success with wireless tools and iwconfig iwlist command? Here is a quick HOWTO su - iwconfig wlan0 mode managed iwconfig wlan0 essid $ESSID iwconfig wlan0 channel $CHANNEL iwconfig wlan0 key $WEP_KEY iwconfig wlan0 ap $AP ifconfig wlan0 up ifconfig wlan0 inet 192.168.1.10 netmask 255.255.255.0 route add default gw 192.168.1.1 or dhclient wlan0 Nicolas (kwizart) From david at fubar.dk Sun Mar 4 21:33:34 2007 From: david at fubar.dk (David Zeuthen) Date: Sun, 04 Mar 2007 16:33:34 -0500 Subject: FW: F7 T2 Security Leak? In-Reply-To: <200703041618.09066.jkeating@redhat.com> References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <200703041618.09066.jkeating@redhat.com> Message-ID: <1173044014.7799.29.camel@zelda.fubar.dk> On Sun, 2007-03-04 at 16:18 -0500, Jesse Keating wrote: > On Sunday 04 March 2007 12:10:13 Micha?l Vanderheeren wrote: > > There are 2 accounts on a computer, call them A and B. Each account has > > it's own different password. > > > > Person A starts up the computer and logs in. But at a certain point person > > B wants to use his account for 5 minutes. So he uses the Fast User Switch. > > As this happens person A's account stays active. But? person B can switch > > back to person A's account without entering a password! So if person A is > > gone for a while, person B can steal his documents, delete files, ? > > Fast User Switching by default enables the screen lock when a user is switched > away from. Could there be a problem with your screen lock? Yes, when a session is switched away from, gnome-screensaver, at least (don't know about KDE / others), is supposed to lock the session... that is.. unless you changed the default and asked it to never lock the screen. If that's not the case, please file bugs against gnome-screensaver so we can fix this. Thanks. Btw, at least for FC7t1, gnome-screensaver wasn't included on the live CD; a bug I hope we've fixed for t2. David From seg at haxxed.com Mon Mar 5 00:58:40 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 04 Mar 2007 18:58:40 -0600 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <1172779164.32335.20.camel@kloczek01.pracownicy.zie> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> <1172771344.22136.118.camel@localhost.localdomain> <1172773609.25356.9.camel@kloczek01.pracownicy.zie> <1172775669.32357.27.camel@localhost.localdomain> <1172777571.32335.11.camel@kloczek01.pracownicy.zie> <1172777460.22136.134.camel@localhost.localdomain> <1172779164.32335.20.camel@kloczek01.pracownicy.zie> Message-ID: <1173056320.18771.24.camel@localhost.localdomain> On Thu, 2007-03-01 at 20:59 +0100, Tomasz K?oczko wrote: > Dnia 01-03-2007, czw o godzinie 14:31 -0500, Adam Jackson napisa?(a): > [..] > > It's really hard to fix memory leaks you can't reproduce, and I've left > > X and firefox running for months on end without hitting this behaviour. > > Moment .. You can't reproduce this bug using my test case on refreshing > pages with big pixmaps ? Are you try this on the same loaded modules > set ? (maybe it is core of problem ?) > > Anyone else observe this kind buggy effects with growing X serer > memory ? I have habit of opening hundreds of tabs at a time in Galeon. That's a good way to hit this kind of problem... Also irritating is millions of javascripts and flash adverts and animated gifs eating up assloads of CPU in tabs that aren't even visible. It would be nice if non-visible tabs were completely taken off the events list or maybe unloaded entirely. And have a proper LRU cache of images, images not displayed recently get dumped completely, when they're needed again, decode them from the original jpeg/gif on disk in the browser cache. Crackrock I say, crackrocks everywhere. -------------- 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 pmr at pajato.com Mon Mar 5 01:26:49 2007 From: pmr at pajato.com (Paul Michael Reilly) Date: Sun, 04 Mar 2007 20:26:49 -0500 Subject: FW: F7 T2 Security Leak? In-Reply-To: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> Message-ID: <45EB71D9.9090406@pajato.com> Micha?l Vanderheeren wrote: > I think there's a security leak in F7. I found out the next thing: > > Look at this situation: > > There are 2 accounts on a computer, call them A and B. Each account has > it's own different password. > > Person A starts up the computer and logs in. But at a certain point > person B wants to use his account for 5 minutes. So he uses the Fast > User Switch. As this happens person A's account stays active. But? > person B can switch back to person A's account without entering a > password! So if person A is gone for a while, person B can steal his > documents, delete files, ? Not a bug. Not a security problem. I've tested FUSA on Gnome and it works beautifully. Locks by default, doesn't lock when I disable it, as it should not. However KDE (Switch User) does not honor the locking setting established by Gnome. FUSA may well be FC7's best feature. I use many accounts simultaneously. FUSA and VNC are just a dream. I would be beside myself if Fedora slowed down FUSA by forcing me to use a false sense of security on my own computer. -pmr From szj087 at gmail.com Sun Mar 4 02:38:06 2007 From: szj087 at gmail.com (=?GB2312?B?y+/X2r79?=) Date: Sun, 4 Mar 2007 10:38:06 +0800 Subject: FC7 Test2 can't be installed on vmware Message-ID: Hi, all I download FC7 Test2 DVD image. But it reports that "No valid devices were found on which to create new file systems, Please check you hardware for the cause of this problem" when I install it on vmware My system is P4 with Window XP SP2. Vmware server is 1.0. Does FC7 Test2 support installation on vmware or SATA harddisk? Thanks Best Regards Sun -------------- next part -------------- An HTML attachment was scrubbed... URL: From chengmj at gionee.com Mon Mar 5 01:47:29 2007 From: chengmj at gionee.com (chengmj at gionee.com) Date: Mon, 5 Mar 2007 09:47:29 +0800 Subject: FC7 Test2 can't be installed on vmware References: Message-ID: <200703050947289534347@gionee.com> Development discussions related : ???????? ???? ??? ????? 2007-03-05 09:56:14 ???? fedora-test-list at redhat.com; fedora-devel-list at redhat.com ??? ??? FC7 Test2 can't be installed on vmware Hi, all I download FC7 Test2 DVD image. But it reports that "No valid devices were found on which to create new file systems, Please check you hardware for the cause of this problem" when I install it on vmware My system is P4 with Window XP SP2. Vmware server is 1.0. Does FC7 Test2 support installation on vmware or SATA harddisk? Thanks Best Regards Sun -------------- next part -------------- An HTML attachment was scrubbed... URL: From gajownik at gmail.com Sun Mar 4 02:25:22 2007 From: gajownik at gmail.com (Dawid Gajownik) Date: Sun, 04 Mar 2007 03:25:22 +0100 Subject: failsafe X session In-Reply-To: <45EA1E6D.7010404@develer.com> References: <45EA1E6D.7010404@develer.com> Message-ID: <45EA2E12.8020805@gmail.com> Dnia 03/04/2007 02:19 AM, U?ytkownik Bernardo Innocenti napisa?: > Where has the "failsafe" X session gone? I can only see Gnome and > KDE in the GDM session menu. Please take a look at this bugzilla report ? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227709 HTH, Dawid -- ^_* From jdogalt at yahoo.com Mon Mar 5 02:58:35 2007 From: jdogalt at yahoo.com (Jane Dogalt) Date: Sun, 4 Mar 2007 18:58:35 -0800 (PST) Subject: checkpoint/restart In-Reply-To: Message-ID: <590721.25408.qm@web56915.mail.re3.yahoo.com> --- Neal Becker wrote: > One of the features I'd really like to see more widely used in the > linux > world is checkpoint/restart. I want it for long-running simulations, > although there may be other uses. If you are willing to live with virtualization, you can launch your processes under qemu, then use its monitor commands to hibernate the system to a ram-image file. If the target system is running from ram (e.g. a livecd), then it is even fairly trivial to migrate the process to another heterogeneous host. I.e. scp the hibernated qemu ram image to another host (and the livecd iso) and resume there. -dmc/jdog > > Basic requirement: > 1) checkpoint a running process and be able to restart on the same > machine. > Restore open files, including mappings of shared memory. > > More advanced: > 2) Migrate a process to another machine (probably with same > libraries). > 3) Handle multiple threads/processes? > > I am pleased to find that blcr > http://ftg.lbl.gov/CheckpointRestart/CheckpointRestart.shtml > > seems to do just what I need. It has an srpm and (with minor change) > builds/runs fine of fc6 x86_64. > > I have been following this area for last several years. There have > been > several starts at other checkpoint projects, but all except blcr seem > to > have died. > > I think this is really exciting technology and I'm betting others > will want > to see this added to Fedora. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > ____________________________________________________________________________________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121 From wtogami at redhat.com Mon Mar 5 03:05:21 2007 From: wtogami at redhat.com (Warren Togami) Date: Sun, 04 Mar 2007 22:05:21 -0500 Subject: spamassassin in rawhide buid problem Message-ID: <45EB88F1.1050906@redhat.com> Checking if your kit is complete... Looks good Writing Makefile for Mail::SpamAssassin Makefile written by ExtUtils::MakeMaker 6.30 + /usr/bin/make 'SSLCFLAGS=-DSPAMC_SSL -I/usr/kerberos/include' 'OPTIMIZE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' make: *** No rule to make target `/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/config.h', needed by `Makefile'. Stop. error: Bad exit status from /var/tmp/rpm-tmp.48771 (%build) http://cvs.fedora.redhat.com/viewcvs/devel/spamassassin/ spamassassin-3.2.0-pre2 builds on FC6, but fails here in F7. I am currently traveling without access to a rawhide machine. Anybody have any idea what could be causing this build failure? Warren Togami wtogami at redhat.com From mtasaka at ioa.s.u-tokyo.ac.jp Mon Mar 5 03:26:34 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Mon, 05 Mar 2007 12:26:34 +0900 Subject: spamassassin in rawhide buid problem In-Reply-To: <45EB88F1.1050906@redhat.com> References: <45EB88F1.1050906@redhat.com> Message-ID: <45EB8DEA.8030106@ioa.s.u-tokyo.ac.jp> Warren Togami wrote: > Checking if your kit is complete... > Looks good > Writing Makefile for Mail::SpamAssassin > Makefile written by ExtUtils::MakeMaker 6.30 > + /usr/bin/make 'SSLCFLAGS=-DSPAMC_SSL -I/usr/kerberos/include' > 'OPTIMIZE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' > make: *** No rule to make target > `/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/config.h', needed > by `Makefile'. Stop. > error: Bad exit status from /var/tmp/rpm-tmp.48771 (%build) This is due to the recent change in perl https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226276 Perhaps adding perl-devel as BR should solve your issue, Mamoru From vandrove at vc.cvut.cz Mon Mar 5 04:32:50 2007 From: vandrove at vc.cvut.cz (Petr Vandrovec) Date: Sun, 04 Mar 2007 20:32:50 -0800 Subject: FC7 Test2 can't be installed on vmware In-Reply-To: <200703050947289534347@gionee.com> References: <200703050947289534347@gionee.com> Message-ID: <45EB9D72.5030306@vc.cvut.cz> chengmj at gionee.com wrote: > Development discussions related : > ???????? > > > > ???? ??? > ????? 2007-03-05 09:56:14 > ???? fedora-test-list at redhat.com; fedora-devel-list at redhat.com > ??? > ??? FC7 Test2 can't be installed on vmware > > Hi, all > > I download FC7 Test2 DVD image. But it reports that "No valid devices were found on which to create new file systems, Please check you hardware for the cause of this problem" when I install it on vmware > > My system is P4 with Window XP SP2. Vmware server is 1.0. > > Does FC7 Test2 support installation on vmware or SATA harddisk? Most probably you've selected incorrect guest OS type so you got VM with buslogic. You should use either IDE disks, or you should configure guest OS as 'other 2.6 linux', which will provide VM with LSILogic adapter. If you selected 'linux' or 'redhat' from menu, then those two selections are optimized for very old Linuxes - 'Other Linux' for 2.2.x kernels, and 'Redhat' for RedHat 6.2/7.x. Petr From kwizart at gmail.com Mon Mar 5 02:57:51 2007 From: kwizart at gmail.com (KH KH) Date: Mon, 5 Mar 2007 03:57:51 +0100 Subject: FC7 Test2 can't be installed on vmware In-Reply-To: <200703050947289534347@gionee.com> References: <200703050947289534347@gionee.com> Message-ID: I've installed test1 on vmware but it work until kernel 2914 It fail to discovers LVM devices... I didn't put a bug on it - i will see... Nicolas (kwizart) 2007/3/5, chengmj at gionee.com : > > > Development discussions related : > ???????? > ________________________________ > > ???? ??? > ????? 2007-03-05 09:56:14 > ???? fedora-test-list at redhat.com; fedora-devel-list at redhat.com > ??? > ??? FC7 Test2 can't be installed on vmware > > > Hi, all > > I download FC7 Test2 DVD image. But it reports that "No valid devices were > found on which to create new file systems, Please check you hardware for the > cause of this problem" when I install it on vmware > > My system is P4 with Window XP SP2. Vmware server is 1.0. > > Does FC7 Test2 support installation on vmware or SATA harddisk? > > Thanks > > Best Regards > Sun > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From denis at poolshark.org Mon Mar 5 07:28:18 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 05 Mar 2007 08:28:18 +0100 Subject: FC7 Test2 can't be installed on vmware In-Reply-To: <45EB9D72.5030306@vc.cvut.cz> References: <200703050947289534347@gionee.com> <45EB9D72.5030306@vc.cvut.cz> Message-ID: <45EBC692.1050601@poolshark.org> Petr Vandrovec wrote: > Most probably you've selected incorrect guest OS type so you got VM with > buslogic. You should use either IDE disks, or you should configure > guest OS as 'other 2.6 linux', which will provide VM with LSILogic > adapter. If you selected 'linux' or 'redhat' from menu, then those two > selections are optimized for very old Linuxes - 'Other Linux' for 2.2.x > kernels, and 'Redhat' for RedHat 6.2/7.x. Unfortunately, FC7 ships a broken mptspi kernel module: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230703 Select the disk as an IDE disk or BusLogic disk, and it should work. Edit the vmdk file and change "lsilogic" to "ide", then remove and readd the virtual disk from VMWare edit configuration. I do hope this gets fixed before FC7 ships... -d From jerone at gmail.com Mon Mar 5 07:30:19 2007 From: jerone at gmail.com (Jerone Young) Date: Mon, 5 Mar 2007 01:30:19 -0600 Subject: FC7 Test2 can't be installed on vmware In-Reply-To: References: Message-ID: <9f50a7a00703042330i5c410726s8a39dca96228cd81@mail.gmail.com> I saw this same same issue with Vmware server under Linux. I just removed the scsi hd, and created and IDE hd for the vmware image and it worked. Though this shows that the fedora install enviroment is missing (or just not loading) the scsi driver need for Vmware scsi disks. On 3/3/07, ??? wrote: > Hi, all > > I download FC7 Test2 DVD image. But it reports that "No valid devices were > found on which to create new file systems, Please check you hardware for the > cause of this problem" when I install it on vmware > > My system is P4 with Window XP SP2. Vmware server is 1.0. > > Does FC7 Test2 support installation on vmware or SATA harddisk? > > Thanks > > Best Regards > Sun > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From denis at poolshark.org Mon Mar 5 08:04:16 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 05 Mar 2007 09:04:16 +0100 Subject: FC7 Test2 can't be installed on vmware In-Reply-To: <9f50a7a00703042330i5c410726s8a39dca96228cd81@mail.gmail.com> References: <9f50a7a00703042330i5c410726s8a39dca96228cd81@mail.gmail.com> Message-ID: <45EBCF00.8070307@poolshark.org> Jerone Young wrote: > I saw this same same issue with Vmware server under Linux. I just > removed the scsi hd, and created and IDE hd for the vmware image and > it worked. Though this shows that the fedora install enviroment is > missing (or just not loading) the scsi driver need for Vmware scsi > disks. No it's loading the right driver all right: it's the driver that isn't working. From nicolas.mailhot at laposte.net Mon Mar 5 08:36:58 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 5 Mar 2007 09:36:58 +0100 (CET) Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <1173056320.18771.24.camel@localhost.localdomain> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> <1172771344.22136.118.camel@localhost.localdomain> <1172773609.25356.9.camel@kloczek01.pracownicy.zie> <1172775669.32357.27.camel@localhost.localdomain> <1172777571.32335.11.camel@kloczek01.pracownicy.zie> <1172777460.22136.134.camel@localhost.localdomain> <1172779164.32335.20.camel@kloczek01.pracownicy.zie> <1173056320.18771.24.camel@localhost.localdomain> Message-ID: <48584.192.54.193.51.1173083818.squirrel@rousalka.dyndns.org> Le Lun 5 mars 2007 01:58, Callum Lerwick a ?crit : > It would be nice if non-visible tabs were completely taken off the > events list or maybe unloaded entirely. I'd really love if the desktop variant shipped with a small local squid/apache proxy enabled by default, instead of doing caching in a user-by-user and app-by-app basis Would do wonders for browser responsiveness & resource use -- Nicolas Mailhot From fedora at camperquake.de Mon Mar 5 09:04:55 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 5 Mar 2007 10:04:55 +0100 Subject: Fedora safe/recovery mode In-Reply-To: <1173042943.5427.5.camel@pensja.lam.pl> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> <87slcl6rdm.fsf@kosh.bigo.ensc.de> <1173042943.5427.5.camel@pensja.lam.pl> Message-ID: <20070305100455.36bedae7@banea.int.addix.net> Hi. On Sun, 04 Mar 2007 22:15:43 +0100, Leszek Matok wrote: > There already was a brief discussion about adding a small rescue > filesystem in /boot, which would be better than running "single" AKA > runlevel 1. This would be the true recovery console, operational even > when the shell from our "real" fs doesn't even start (because some > mor^H^H^HESR^H^H^Huser removed shared libraries). > > Where did this idea go? Don't know, but it ought to come back. From nicolas.mailhot at laposte.net Mon Mar 5 08:46:17 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 5 Mar 2007 09:46:17 +0100 (CET) Subject: FW: F7 T2 Security Leak? In-Reply-To: <200703041629.17219.jkeating@redhat.com> References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <200703041618.09066.jkeating@redhat.com> <200703041629.17219.jkeating@redhat.com> Message-ID: <24594.192.54.193.51.1173084377.squirrel@rousalka.dyndns.org> Le Dim 4 mars 2007 22:29, Jesse Keating a ?crit : > That said, my original point should stand, that fast user switching relies > upon gnome screensaver to lock the screen. Is that failing for the > original poster in some way? Does it force the lock on switch or relies on the screensaver default locking timeout? If it does not force the lock it would make it pretty useless even in a home environment (nosy little sibling and/or suspicious spouse may not attack the computer even with physical access but they'll jump at this) -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Mar 5 08:39:33 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 5 Mar 2007 09:39:33 +0100 (CET) Subject: yum delay processing exclude list In-Reply-To: <20070304161359.1c3e3e9e@osprey.hogchain.net> References: <20070304095326.35414173@osprey.hogchain.net> <1173042734.19549.3.camel@rousalka.dyndns.org> <1173043616.30992.19.camel@cutter> <1173044220.30992.22.camel@cutter> <20070304161359.1c3e3e9e@osprey.hogchain.net> Message-ID: <60596.192.54.193.51.1173083973.squirrel@rousalka.dyndns.org> Le Dim 4 mars 2007 23:13, Jay Cliburn a ?crit : > On Sun, 04 Mar 2007 16:37:00 -0500 > seth vidal wrote: > >> found it. It's been fixed in cvs. It took the exclude processing time >> from 2 minutes on my little laptop to <10s. I'm willing to accept >> that. :) > > Sounds much better. Thanks for fixing it. Thanks a lot. Should have done more aggressive problem reporting saturday;) -- Nicolas Mailhot From michel.salim at gmail.com Mon Mar 5 00:28:34 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 4 Mar 2007 19:28:34 -0500 Subject: Regression in importing Word document In-Reply-To: References: <883cfe6d0703031636u4adff1e7o8b74bc943c596d50@mail.gmail.com> Message-ID: <883cfe6d0703041628u6a01a60agc824038e0f861c01@mail.gmail.com> 2007/3/4, Hikaru Amano : > On 3/3/07, Michel Salim wrote: > > This following Word document: http://hircus.org/fedora/word-bug/CDF-Flyer.doc > > reliably crashes Abiword and OpenOffice in Rawhide on my x86_64 > > machine. Could someone take a look and see if it crashes on > > Rawhide/i386 and FC6/any ? > > Opens fine on rawhide > So it's probably x86_64 specific (I've modified the bug to be x86_64-only). OO.o didn't have a x86_64 release until version 2.1, I think, so there's probably some bugs still. Thanks, -- Michel Salim http://hircus.wordpress.com/ From michael.vanderheeren at gmail.com Mon Mar 5 09:55:05 2007 From: michael.vanderheeren at gmail.com (=?ISO-8859-1?Q?Micha=EBl_Vanderheeren?=) Date: Mon, 5 Mar 2007 10:55:05 +0100 Subject: FW: F7 T2 Security Leak? In-Reply-To: <1173044014.7799.29.camel@zelda.fubar.dk> References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <200703041618.09066.jkeating@redhat.com> <1173044014.7799.29.camel@zelda.fubar.dk> Message-ID: <6a29c8790703050155n8403220sc34f3849a84a1597@mail.gmail.com> >> Btw, at least for FC7t1, gnome-screensaver wasn't included on the live >> CD; a bug I hope we've fixed for t2 I installed from F7T2. Could it be that that is the problem? And that the bug isn't fixed... 2007/3/4, David Zeuthen : > > On Sun, 2007-03-04 at 16:18 -0500, Jesse Keating wrote: > > On Sunday 04 March 2007 12:10:13 Micha?l Vanderheeren wrote: > > > There are 2 accounts on a computer, call them A and B. Each account > has > > > it's own different password. > > > > > > Person A starts up the computer and logs in. But at a certain point > person > > > B wants to use his account for 5 minutes. So he uses the Fast User > Switch. > > > As this happens person A's account stays active. But? person B can > switch > > > back to person A's account without entering a password! So if person A > is > > > gone for a while, person B can steal his documents, delete files, ? > > > > Fast User Switching by default enables the screen lock when a user is > switched > > away from. Could there be a problem with your screen lock? > > Yes, when a session is switched away from, gnome-screensaver, at least > (don't know about KDE / others), is supposed to lock the session... that > is.. unless you changed the default and asked it to never lock the > screen. If that's not the case, please file bugs against > gnome-screensaver so we can fix this. Thanks. > > Btw, at least for FC7t1, gnome-screensaver wasn't included on the live > CD; a bug I hope we've fixed for t2. > > David > > > -- > 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 buildsys at redhat.com Mon Mar 5 11:02:15 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 5 Mar 2007 06:02:15 -0500 Subject: rawhide report: 20070305 changes Message-ID: <200703051102.l25B2Fut006911@hs20-bc2-6.build.redhat.com> Updated Packages: ImageMagick-6.3.2.9-1.fc7 ------------------------- * Fri Mar 02 2007 Norm Murray 6.3.2.9-1.fc7.0 - update to 6.3.2-9 * Wed Aug 23 2006 Matthias Clasen - 6.2.8.0-3.fc6 - fix several integer and buffer overflows (#202193, CVE-2006-3743) - fix more integer overflows (#202771, CVE-2006-4144) * Mon Jul 24 2006 Matthias Clasen - 6.2.8.0-2 - Add missing BRs at-3.1.10-9.fc7 --------------- * Sat Mar 03 2007 Marcela Maslanova - 3.1.10-9 - review * Tue Feb 20 2007 Marcela Maslanova - 3.1.10-8 - review - rhbz#225288 * Tue Jan 30 2007 Marcela Maslanova - 3.1.10-7 - no debug file - useless - new pam configuration - rhbz#224597 hal-0.5.9-0.git20070304.fc7 --------------------------- * Sun Mar 04 2007 David Zeuthen - 0.5.9-0.git20070304 - Update to 0.5.9rc1; notable user visible changes: - New /sbin/umount.hal helper (#188193) - Slow down polling if no session is non-idle (#204969) - Refuse to eject busy devices (#207177) - Don't mount noexec unless requested - Use inotify to watch for new fdi files - Support for new Firewire stack - BT killswitch for Sony laptops (hadess) - Pass suspend quirks to pm-utils (need new pm-utils release to use it) mailx-8.1.1-46.fc7 ------------------ * Mon Mar 05 2007 Ivana Varekova - 8.1.1-46 - add /usr/share/mailx directory Broken deps for i386 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.i386 requires libgcj.so.7rh frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh Broken deps for ppc ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ppc requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.ppc requires libofx.so.3 gnucash - 2.0.5-1.fc6.ppc requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.ppc requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.ppc requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.ppc requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.ppc requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.ppc requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.ppc requires lm_sensors-devel Broken deps for ia64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ia64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ia64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.ia64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ia64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ia64 requires lm_sensors-devel Broken deps for x86_64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.i386 requires libgcj.so.7rh cairo-java - 1.0.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.x86_64 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils libgconf-java - 2.12.4-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) Broken deps for s390 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.s390 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel 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 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.s390x requires libgcj.so.7rh()(64bit) cairo-java - 1.0.5-4.fc7.s390 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.s390x requires libofx.so.3()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.s390x requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libgconf-java - 2.12.4-5.fc7.s390x requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.s390x requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.s390x requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.s390 requires libgcj.so.7rh libgtk-java - 2.8.7-2.fc7.s390x requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390x requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel net-snmp-devel - 1:5.4-10.fc7.s390x requires lm_sensors-devel Broken deps for ppc64 ---------------------------------------------------------- cairo-java - 1.0.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ppc64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libgtk-java - 2.8.7-2.fc7.ppc64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ppc64 requires lm_sensors-devel From wolfy at nobugconsulting.ro Mon Mar 5 11:03:18 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Mon, 05 Mar 2007 13:03:18 +0200 Subject: Regression in importing Word document In-Reply-To: <883cfe6d0703041628u6a01a60agc824038e0f861c01@mail.gmail.com> References: <883cfe6d0703031636u4adff1e7o8b74bc943c596d50@mail.gmail.com> <883cfe6d0703041628u6a01a60agc824038e0f861c01@mail.gmail.com> Message-ID: <45EBF8F6.6060801@nobugconsulting.ro> Michel Salim wrote: > 2007/3/4, Hikaru Amano : >> On 3/3/07, Michel Salim wrote: >> > This following Word document: >> http://hircus.org/fedora/word-bug/CDF-Flyer.doc >> > reliably crashes Abiword and OpenOffice in Rawhide on my x86_64 >> > machine. Could someone take a look and see if it crashes on >> > Rawhide/i386 and FC6/any ? >> >> Opens fine on rawhide >> > So it's probably x86_64 specific (I've modified the bug to be > x86_64-only). OO.o didn't have a x86_64 release until version 2.1, I > think, so there's probably some bugs still. > > Thanks, > Works fine for me in FC6/openoffice.org-core-2.0.4-5.5.10.x86_64 From bdwheele at indiana.edu Mon Mar 5 13:34:24 2007 From: bdwheele at indiana.edu (Brian Wheeler) Date: Mon, 05 Mar 2007 08:34:24 -0500 Subject: Fedora safe/recovery mode In-Reply-To: <20070304150103.GS3334@angus.ind.WPI.EDU> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> <87slcl6rdm.fsf@kosh.bigo.ensc.de> <20070304144522.GR3334@angus.ind.WPI.EDU> <20070304150103.GS3334@angus.ind.WPI.EDU> Message-ID: <1173101664.8128.8.camel@wombat.dlib.indiana.edu> On Sun, 2007-03-04 at 10:01 -0500, Chuck Anderson wrote: > On Sun, Mar 04, 2007 at 09:45:22AM -0500, Chuck Anderson wrote: > > On Sun, Mar 04, 2007 at 03:00:05PM +0100, Enrico Scholz wrote: > > > > tested this in fedora for some months, but last I checked, runlevel 1 > > > > dropped the user directly in a root shell. > > > > > > > > Runlevel 3 is at least as safe as runlevel 5 and could be used with no > > > > security implications. > > > > > > As long as Grub and the BIOS are not protected with a password by > > > default, we do not need to discuss this.... > > > > Does grub have a "secure" flag you can put in a stanza to require grub > > to prompt for a password? That would solve the security concern. > > Answering myself: > > -- Command: lock > Prevent normal users from executing arbitrary menu entries. You > must use the command `password' if you really want this command to > be useful (*note password::). > > This command is used in a menu, as shown in this example: > > title This entry is too dangerous to be executed by normal users > lock > root (hd0,a) > kernel /no-security-os > > See also *Note Security::. > > > under *Note Security*: > > Also, you can specify an optional argument to `password'. See this > example: > > password PASSWORD /boot/grub/menu-admin.lst > > In this case, GRUB will load `/boot/grub/menu-admin.lst' as a > configuration file when you enter the valid password. > What's the chances of a user remembering this password if they've forgotten the root password? If its set to a default then everyone knows it anyway and there's no used to having it in the first place... The idea (elsewhere in this thread) of having a recovery root (which would probably be a busybox based system) on /boot is a good one, but it shouldn't have a password either, just a really "stern" warning not to do something stupid like, say, remove shared libraries. Brian From jkeating at redhat.com Mon Mar 5 14:03:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 5 Mar 2007 09:03:21 -0500 Subject: FW: F7 T2 Security Leak? In-Reply-To: <24594.192.54.193.51.1173084377.squirrel@rousalka.dyndns.org> References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <200703041629.17219.jkeating@redhat.com> <24594.192.54.193.51.1173084377.squirrel@rousalka.dyndns.org> Message-ID: <200703050903.22113.jkeating@redhat.com> On Monday 05 March 2007 03:46:17 Nicolas Mailhot wrote: > Does it force the lock on switch or relies on the screensaver default > locking timeout? If it does not force the lock it would make it pretty > useless even in a home environment (nosy little sibling and/or suspicious > spouse may not attack the computer even with physical access but they'll > jump at this) Force lock. -- 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 Mon Mar 5 14:04:02 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 5 Mar 2007 09:04:02 -0500 Subject: FW: F7 T2 Security Leak? In-Reply-To: <6a29c8790703050155n8403220sc34f3849a84a1597@mail.gmail.com> References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <1173044014.7799.29.camel@zelda.fubar.dk> <6a29c8790703050155n8403220sc34f3849a84a1597@mail.gmail.com> Message-ID: <200703050904.02519.jkeating@redhat.com> On Monday 05 March 2007 04:55:05 Micha?l Vanderheeren wrote: > I installed from F7T2. Could it be that that is the problem? And that the > bug isn't fixed... no, we included gnome-screensaver in the F7 Test2 Prime spin. Unless you're talking about the F7 Test2 LiveCD, which I'm also pretty sure we adjusted to get gnome-screensaver on there. I'm not 100% on that though, I didn't compose it. -- 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 dblistsub-fedora at yahoo.it Mon Mar 5 13:51:53 2007 From: dblistsub-fedora at yahoo.it (Davide Bolcioni) Date: Mon, 5 Mar 2007 14:51:53 +0100 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <48584.192.54.193.51.1173083818.squirrel@rousalka.dyndns.org> References: <200703011112.12348.jkeating@redhat.com> <1173056320.18771.24.camel@localhost.localdomain> <48584.192.54.193.51.1173083818.squirrel@rousalka.dyndns.org> Message-ID: <200703051451.53427.dblistsub-fedora@yahoo.it> On Monday 05 March 2007 09:36:58 Nicolas Mailhot wrote: > Le Lun 5 mars 2007 01:58, Callum Lerwick a ?crit : > > It would be nice if non-visible tabs were completely taken off the > > events list or maybe unloaded entirely. > > I'd really love if the desktop variant shipped with a small local > squid/apache proxy enabled by default, instead of doing caching in a > user-by-user and app-by-app basis > > Would do wonders for browser responsiveness & resource use I have been a longtime user of WWWOFFLE, a proxy whose usage pattern matches your description above (and overlaps privoxy to some extent). A Fedora RPM can be found using Google (ATrpms, IIRC). It works well enough for everyday use. I don't think a local proxy would cause Firefox to behave, however. Hope this helps, Davide Bolcioni -- Paranoia is a survival asset. From hughsient at gmail.com Mon Mar 5 11:38:12 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 5 Mar 2007 11:38:12 +0000 Subject: rawhide report: 20070305 changes In-Reply-To: <200703051102.l25B2Fut006911@hs20-bc2-6.build.redhat.com> References: <200703051102.l25B2Fut006911@hs20-bc2-6.build.redhat.com> Message-ID: <15e53e180703050338j4c532bfs94c47cc79718e980@mail.gmail.com> On 05/03/07, buildsys at redhat.com wrote: > Updated Packages: > hal-0.5.9-0.git20070304.fc7 > --------------------------- > * Sun Mar 04 2007 David Zeuthen - 0.5.9-0.git20070304 > - Update to 0.5.9rc1; notable user visible changes: > - New /sbin/umount.hal helper (#188193) > - Slow down polling if no session is non-idle (#204969) > - Refuse to eject busy devices (#207177) > - Don't mount noexec unless requested > - Use inotify to watch for new fdi files > - Support for new Firewire stack > - BT killswitch for Sony laptops (hadess) > - Pass suspend quirks to pm-utils (need new pm-utils release to use it) We also need new versions of radeontool and vbetool (and thus the libx86 library) if pm-utils is going to work correctly. If we build a new pm-utils and the above tools then video resume quirks should be handled automatically for F7. Basically this means that suspend and resume should work for many, many more laptops out of the box. Also, please don't clump these tools into one uber pm-utils package like it was for FC6, as it makes packaging new versions of indervidual tools difficult. All the SRPMS are working and available [1], they just need someone to fast-track these into F7. Thanks, Richard. [1] http://people.freedesktop.org/~hughsient/fedora/7/SRPMS/ From michael.vanderheeren at gmail.com Sun Mar 4 22:48:27 2007 From: michael.vanderheeren at gmail.com (=?utf-8?Q?Micha=C3=ABl_Vanderheeren?=) Date: Sun, 4 Mar 2007 23:48:27 +0100 Subject: FW: F7 T2 Security Leak? In-Reply-To: References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <200703041618.09066.jkeating@redhat.com> Message-ID: <45eb4cbe.179726de.07a2.ffffb5fc@mx.google.com> Note that I dit not change anything from the installation. So if there's a problem with the sreen lock, the cd's are spinned down with that problem. And why not calling it a security leak? Anything related to a password and access, ... is as far as I know security... ------------------------------------------------------------------------------ Jesse Keating wrote: > On Sunday 04 March 2007 12:10:13 Micha?l Vanderheeren wrote: >> There are 2 accounts on a computer, call them A and B. Each account has >> it's own different password. >> >> Person A starts up the computer and logs in. But at a certain point >> person B wants to use his account for 5 minutes. So he uses the Fast User >> Switch. As this happens person A's account stays active. But? person B >> can switch back to person A's account without entering a password! So if >> person A is gone for a while, person B can steal his documents, delete >> files, ? > > Fast User Switching by default enables the screen lock when a user is > switched > away from. Could there be a problem with your screen lock? > > Please keep in mind that any assumption of security is completely out of > the water if folks have physical access to your computer, which they must > have for fast user switching. > This comment is a bit extreme. True, in principal there is no security without physical security - but that hardly means we should offer an open invitation. -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list From camilo at mesias.co.uk Mon Mar 5 14:35:34 2007 From: camilo at mesias.co.uk (Cam) Date: Mon, 05 Mar 2007 14:35:34 +0000 Subject: Announcing Fedora 7 Test 2 (6.91) In-Reply-To: <48584.192.54.193.51.1173083818.squirrel@rousalka.dyndns.org> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> <1172771344.22136.118.camel@localhost.localdomain> <1172773609.25356.9.camel@kloczek01.pracownicy.zie> <1172775669.32357.27.camel@localhost.localdomain> <1172777571.32335.11.camel@kloczek01.pracownicy.zie> <1172777460.22136.134.camel@localhost.localdomain> <1172779164.32335.20.camel@kloczek01.pracownicy.zie> <1173056320.18771.24.camel@localhost.localdomain> <48584.192.54.193.51.1173083818.squirrel@rousalka.dyndns.org> Message-ID: <45EC2AB6.5080108@mesias.co.uk> Nicolas > I'd really love if the desktop variant shipped with a small local > squid/apache proxy enabled by default, instead of doing caching in a > user-by-user and app-by-app basis > > Would do wonders for browser responsiveness & resource use I doubt that replacing the inbuilt app caching with a local proxy would improve responsiveness. I'm not sure if that's what you had in mind though. -Cam -- camilo at mesias.co.uk <-- From jkeating at redhat.com Mon Mar 5 16:05:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 5 Mar 2007 11:05:39 -0500 Subject: FW: F7 T2 Security Leak? In-Reply-To: <45eb4cbe.179726de.07a2.ffffb5fc@mx.google.com> References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <45eb4cbe.179726de.07a2.ffffb5fc@mx.google.com> Message-ID: <200703051105.39926.jkeating@redhat.com> On Sunday 04 March 2007 17:48:27 Micha?l Vanderheeren wrote: > Note that I dit not change anything from the installation. So if there's a > problem with the sreen lock, the cd's are spinned down with that problem. > And why not calling it a security leak? Anything related to a password and > access, ... is as far as I know security... Have you looked into anything regarding gnome-screen-saver yet? Have you tried debugging the problem? -- 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 phillip.lougher at gmail.com Mon Mar 5 16:06:47 2007 From: phillip.lougher at gmail.com (Phillip Lougher) Date: Mon, 5 Mar 2007 16:06:47 +0000 (UTC) Subject: Kernel 2.6.19 squashfs problem and bugzilla References: <20070302153703.GA7038@dspnet.fr.eu.org> Message-ID: Olivier Galibert pobox.com> writes: > > The kernel from kernel-2.6.19-1.2288.fc5.x86_64.rpm is not able to > loop-mount the fc5 install Fedora/base/stage2.img file, at least > through nfs. You get: > squashfs: version 3.2-alpha (2006/12/12) Phillip Lougher > SQUASHFS error: sb_bread failed reading block 0x9e8be8e1 > SQUASHFS error: unable to read inode lookup table > What version of mksquashfs generated that Squashfs image? NFS support was experimental before the 3.2 release, and was work in progress during the alpha releases. If the mksquashfs is 3.1 or before then the necessary information to export via NFS wasn't generated. The 3.2-alpha release should not have been trying to read the inode lookup table if it didn't exist, but a bug existed where it tried to do this for 2.x and older filesystems. However, it should not be trying to do this for a 3.0 or 3.1 filesystem. > As for bugzilla, I was wondering where to file that one, would it be > bugzilla.redhat.com or bugzilla.fedora.us? Squashfs bugs should come to me, as I'm the author, and ultimately the one that has to fix it, if it is a bug. > And if the latter, is it > going to actually work any time soon? I don't think I've ever been > able to contact it. NFS works in the current 3.2 releases. Phillip > > OG. > From rdieter at math.unl.edu Mon Mar 5 16:10:37 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 05 Mar 2007 10:10:37 -0600 Subject: FW: F7 T2 Security Leak? References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <200703041618.09066.jkeating@redhat.com> <1173044014.7799.29.camel@zelda.fubar.dk> Message-ID: David Zeuthen wrote: > On Sun, 2007-03-04 at 16:18 -0500, Jesse Keating wrote: >> On Sunday 04 March 2007 12:10:13 Micha?l Vanderheeren wrote: >> > There are 2 accounts on a computer, call them A and B. Each account has >> > it's own different password. >> > >> > Person A starts up the computer and logs in. But at a certain point >> > person B wants to use his account for 5 minutes. So he uses the Fast >> > User Switch. As this happens person A's account stays active. But? >> > person B can switch back to person A's account without entering a >> > password! So if person A is gone for a while, person B can steal his >> > documents, delete files, ? >> >> Fast User Switching by default enables the screen lock when a user is >> switched >> away from. Could there be a problem with your screen lock? > > Yes, when a session is switched away from, gnome-screensaver, at least > (don't know about KDE / others) Maybe it could/should use xdg-utils' and emit: xdg-screensaver lock on switching? (Hrm, unless someone/somewhere purposefully doesn't want the screen to lock on user switch) -- Rex From phillip.lougher at gmail.com Mon Mar 5 16:17:39 2007 From: phillip.lougher at gmail.com (Phillip Lougher) Date: Mon, 5 Mar 2007 16:17:39 +0000 (UTC) Subject: Kernel 2.6.19 squashfs problem and bugzilla References: <20070302153703.GA7038@dspnet.fr.eu.org> <20070302211758.GB20893@redhat.com> Message-ID: Dave Jones redhat.com> writes: > > On Fri, Mar 02, 2007 at 04:37:03PM +0100, Olivier Galibert wrote: > > The kernel from kernel-2.6.19-1.2288.fc5.x86_64.rpm is not able to > > loop-mount the fc5 install Fedora/base/stage2.img file, at least > > through nfs. You get: > > squashfs: version 3.2-alpha (2006/12/12) Phillip Lougher > > SQUASHFS error: sb_bread failed reading block 0x9e8be8e1 > > SQUASHFS error: unable to read inode lookup table > > squashfs isn't compatible between releases. > Squashfs is now generally compatible between releases. A later release of Squashfs can mount filesystems from earlier releases (i.e. 3.2 can mount 3.1, 3.0 and earlier filesystems). Earlier releases of Squashfs generally couldn't mount later filesystem versions, however, since 3.0 I have tried to maintain both backwards and forwards compatibility, and a 3.0 patched kernel can mount 3.2 filesystems. Phillip From david at fubar.dk Mon Mar 5 16:29:32 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 05 Mar 2007 11:29:32 -0500 Subject: FW: F7 T2 Security Leak? In-Reply-To: <45eb4cbe.179726de.07a2.ffffb5fc@mx.google.com> References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <200703041618.09066.jkeating@redhat.com> <45eb4cbe.179726de.07a2.ffffb5fc@mx.google.com> Message-ID: <1173112172.2638.16.camel@zelda.fubar.dk> On Sun, 2007-03-04 at 23:48 +0100, Micha?l Vanderheeren wrote: > This comment is a bit extreme. True, in principal there is no security > without physical security - but that hardly means we should offer an open > invitation. No one ever disagreed with you there. To recap, it's a *bug* if your session isn't locked when you switch away from it. Again, filing bugs (and pasting the bug reference here) and helping debugging the problem is much more useful. Thanks. David From dcbw at redhat.com Mon Mar 5 16:45:14 2007 From: dcbw at redhat.com (Dan Williams) Date: Mon, 05 Mar 2007 11:45:14 -0500 Subject: mac80211 and iwlwifi (was Re: d80211 and iwlwifi) In-Reply-To: <4c4ba1530703031018s44d72eb7va6331af3b72e382e@mail.gmail.com> References: <3dd77c60702241356sf4c2f4aq58f482612744c0f0@mail.gmail.com> <20070303161100.GC3511@redhat.com> <4c4ba1530703031018s44d72eb7va6331af3b72e382e@mail.gmail.com> Message-ID: <1173113114.10230.5.camel@localhost.localdomain> On Sat, 2007-03-03 at 10:18 -0800, Tom London wrote: > On 3/3/07, John W. Linville wrote: > > On Sat, Feb 24, 2007 at 09:56:25PM +0000, Mike Cohler wrote: > > > I hope this is not a repeat question but is it planned to have d80211 > > > and iwlwifi in the F7 release? > > > > I have test kernels w/ iwlwifi here: > > > > http://people.redhat.com/linville/kernels/fc7/ > > > > If you have ipw3945 hardware, please give them a try. You will need > > to get the firmware from here: > > > > http://intellinuxwireless.org > > > > YMMV...I haven't been able to make it work yet on my Sony Vaio... > > > > Send the bug reports (and patches!) to me...thanks! > > > > John > > -- > > John W. Linville > > linville at redhat.com > > Does not work for me on Thinkpad X60 using 'stock Rawhide' NetworkManager. > > Association fails both with WEP and 'no key'. NM uses wpa_supplicant for all connections in the background. If your wpa_supplicant works with mac80211 (or, really, d80211) then it will likely work with NetworkManager. Dan From pemboa at gmail.com Mon Mar 5 15:18:37 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 6 Mar 2007 09:18:37 +1800 Subject: Fedora safe/recovery mode In-Reply-To: <1173101664.8128.8.camel@wombat.dlib.indiana.edu> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> <87slcl6rdm.fsf@kosh.bigo.ensc.de> <20070304144522.GR3334@angus.ind.WPI.EDU> <20070304150103.GS3334@angus.ind.WPI.EDU> <1173101664.8128.8.camel@wombat.dlib.indiana.edu> Message-ID: <16de708d0703050718qec50b80k84511d4ac63ff499@mail.gmail.com> On 3/6/07, Brian Wheeler wrote: > On Sun, 2007-03-04 at 10:01 -0500, Chuck Anderson wrote: > > On Sun, Mar 04, 2007 at 09:45:22AM -0500, Chuck Anderson wrote: > > > On Sun, Mar 04, 2007 at 03:00:05PM +0100, Enrico Scholz wrote: > > > > > tested this in fedora for some months, but last I checked, runlevel 1 > > > > > dropped the user directly in a root shell. > > > > > > > > > > Runlevel 3 is at least as safe as runlevel 5 and could be used with no > > > > > security implications. > > > > > > > > As long as Grub and the BIOS are not protected with a password by > > > > default, we do not need to discuss this.... > > > > > > Does grub have a "secure" flag you can put in a stanza to require grub > > > to prompt for a password? That would solve the security concern. > > > > Answering myself: > > > > -- Command: lock > > Prevent normal users from executing arbitrary menu entries. You > > must use the command `password' if you really want this command to > > be useful (*note password::). > > > > This command is used in a menu, as shown in this example: > > > > title This entry is too dangerous to be executed by normal users > > lock > > root (hd0,a) > > kernel /no-security-os > > > > See also *Note Security::. > > > > > > under *Note Security*: > > > > Also, you can specify an optional argument to `password'. See this > > example: > > > > password PASSWORD /boot/grub/menu-admin.lst > > > > In this case, GRUB will load `/boot/grub/menu-admin.lst' as a > > configuration file when you enter the valid password. > > > > What's the chances of a user remembering this password if they've > forgotten the root password? If its set to a default then everyone > knows it anyway and there's no used to having it in the first place... > > The idea (elsewhere in this thread) of having a recovery root (which > would probably be a busybox based system) on /boot is a good one, but it > shouldn't have a password either, just a really "stern" warning not to > do something stupid like, say, remove shared libraries. > > Brian Just to remind everyone that I suggested this solution mosly for what (in FC6) was a common occurence of a broken X display. I don't think single user mode should be _that_ easy to get to. -- Fedora Core 6 and proud From rnorwood at redhat.com Mon Mar 5 17:18:11 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Mon, 05 Mar 2007 12:18:11 -0500 Subject: perl, perl-devel, and missing config.h Message-ID: Hi, As part of the package review process, Tom 'Spot' Callaway reviewed the perl spec file[1] to bring it up to Fedora's standards. It needed a lot of work. So much work that Spot ended up essentially rewriting it. The new spec file is much cleaner and more correct, and Spot deserves mad props for fixing it. However, one change has been pretty controversial. In accordance with standard Fedora packaging, he split the C header files into a perl-devel package. These files aren't needed to run perl modules, but they are needed to build many perl modules, both in Core and Extras. Unfortunately, when I accepted the new spec file and built it into rawhide, I didn't think through the consequences fully, and we ended up breaking a lot of builds. It was generally not very obvious *why* the builds were breaking, leading to much frustration[2]. Sorry. :-( Spot, Jesse Keating, and I have discussed the issue via email and on fedora-perl-devel-list[3] - the three of us think this solution is the right way to go, but several people on the list disagree. So we're going to hash things out there and decide what to do. If you want to follow the discussion, see fedora-perl-devel-list. Otherwise, stay tuned, and we'll keep you posted. If you own a package that is failing to build in rawhide with errors like: """ make[2]: *** No rule to make target `/usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/config.h', needed by `Makefile'. Stop. """ Then adding a BuildRequires: perl-devel will fix it for now - however, we might decide to roll perl-devel back into perl or make some other change that could make those changes unnecessary. Thanks, -RN [1] https://bugzilla.redhat.com/226276 [2] https://bugzilla.redhat.com/230608 https://bugzilla.redhat.com/230406 [3] https://www.redhat.com/archives/fedora-perl-devel-list/2007-March/msg00009.html P.S. - fedora-perl-devel-list is moderated, so if you want to be part of the discussion, either join the list or make it clear in the subject line that your message is not spam. ("Not spam", maybe. :-)) -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From michael.vanderheeren at gmail.com Mon Mar 5 17:26:38 2007 From: michael.vanderheeren at gmail.com (=?utf-8?Q?Micha=C3=ABl_Vanderheeren?=) Date: Mon, 5 Mar 2007 18:26:38 +0100 Subject: FW: F7 T2 Security Leak? In-Reply-To: <200703051105.39926.jkeating@redhat.com> References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <45eb4cbe.179726de.07a2.ffffb5fc@mx.google.com> <200703051105.39926.jkeating@redhat.com> Message-ID: <45ec52d1.5926c107.1bfc.ffffb9da@mx.google.com> No I haven't... I want to, but I don't have much time for it... Have to code Java for University and study a lot. But will try to read some logs and maybe find the bug next weekend. If someone has more time before that and experienced the same, be my guest to help! Regards, Micha?l -----Oorspronkelijk bericht----- Van: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] Namens Jesse Keating Verzonden: maandag 5 maart 2007 17:06 Aan: fedora-devel-list at redhat.com Onderwerp: Re: FW: F7 T2 Security Leak? On Sunday 04 March 2007 17:48:27 Micha?l Vanderheeren wrote: > Note that I dit not change anything from the installation. So if > there's a problem with the sreen lock, the cd's are spinned down with that problem. > And why not calling it a security leak? Anything related to a password > and access, ... is as far as I know security... Have you looked into anything regarding gnome-screen-saver yet? Have you tried debugging the problem? -- Jesse Keating Release Engineer: Fedora From wwoods at redhat.com Mon Mar 5 18:02:03 2007 From: wwoods at redhat.com (Will Woods) Date: Mon, 05 Mar 2007 13:02:03 -0500 Subject: FW: F7 T2 Security Leak? In-Reply-To: <45ec52d1.5926c107.1bfc.ffffb9da@mx.google.com> References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <45eb4cbe.179726de.07a2.ffffb5fc@mx.google.com> <200703051105.39926.jkeating@redhat.com> <45ec52d1.5926c107.1bfc.ffffb9da@mx.google.com> Message-ID: <1173117723.19600.37.camel@metroid.rdu.redhat.com> On Mon, 2007-03-05 at 18:26 +0100, Micha?l Vanderheeren wrote: > No I haven't... I want to, but I don't have much time for it... Have to > code Java for University and study a lot. But will try to read some > logs and maybe find the bug next weekend. If someone has more time > before that and experienced the same, be my guest to help! Was one of the users root? gnome-screensaver doesn't lock for root, so I think I noticed that any user could switch to root's session without hindrance.. -w -------------- 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 Mar 5 18:03:04 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 5 Mar 2007 13:03:04 -0500 Subject: FW: F7 T2 Security Leak? In-Reply-To: <1173117723.19600.37.camel@metroid.rdu.redhat.com> References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <45eb4cbe.179726de.07a2.ffffb5fc@mx.google.com> <200703051105.39926.jkeating@redhat.com> <45ec52d1.5926c107.1bfc.ffffb9da@mx.google.com> <1173117723.19600.37.camel@metroid.rdu.redhat.com> Message-ID: <20070305180304.GA22791@jadzia.bu.edu> On Mon, Mar 05, 2007 at 01:02:03PM -0500, Will Woods wrote: > > No I haven't... I want to, but I don't have much time for it... Have to > > code Java for University and study a lot. But will try to read some > > logs and maybe find the bug next weekend. If someone has more time > > before that and experienced the same, be my guest to help! > Was one of the users root? gnome-screensaver doesn't lock for root, so I > think I noticed that any user could switch to root's session without > hindrance.. Ooh. I have a solution for this! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Mon Mar 5 18:10:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 5 Mar 2007 13:10:05 -0500 Subject: FW: F7 T2 Security Leak? In-Reply-To: <20070305180304.GA22791@jadzia.bu.edu> References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <1173117723.19600.37.camel@metroid.rdu.redhat.com> <20070305180304.GA22791@jadzia.bu.edu> Message-ID: <200703051310.05649.jkeating@redhat.com> On Monday 05 March 2007 13:03:04 Matthew Miller wrote: > Ooh. I have a solution for this! Dissallow root logins. -- 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 tiemann at redhat.com Mon Mar 5 18:10:50 2007 From: tiemann at redhat.com (Michael Tiemann) Date: Mon, 05 Mar 2007 13:10:50 -0500 Subject: perl, perl-devel, and missing config.h In-Reply-To: References: Message-ID: <1173118250.4890.41.camel@localhost.localdomain> On Mon, 2007-03-05 at 12:18 -0500, Robin Norwood wrote: > Hi, > However, one change has been pretty controversial. In accordance with > standard Fedora packaging, he split the C header files into a > perl-devel package. These files aren't needed to run perl modules, > but they are needed to build many perl modules, both in Core and > Extras. Unfortunately, when I accepted the new spec file and built it > into rawhide, I didn't think through the consequences fully, and we > ended up breaking a lot of builds. It was generally not very obvious > *why* the builds were breaking, leading to much frustration[2]. My $0.02: now that the reason is known, and known to be a direct consequence of Following The Specs, it seems to me that adding the -devel requirement to packages that do, indeed, need -devel is The Right Thing. I, for one, am always happy to see a more clear and clean distinction between the -devel and the non-devel worlds. M From mattdm at mattdm.org Mon Mar 5 18:12:03 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 5 Mar 2007 13:12:03 -0500 Subject: FW: F7 T2 Security Leak? In-Reply-To: <200703051310.05649.jkeating@redhat.com> References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <1173117723.19600.37.camel@metroid.rdu.redhat.com> <20070305180304.GA22791@jadzia.bu.edu> <200703051310.05649.jkeating@redhat.com> Message-ID: <20070305181203.GA24461@jadzia.bu.edu> On Mon, Mar 05, 2007 at 01:10:05PM -0500, Jesse Keating wrote: > > Ooh. I have a solution for this! > Dissallow root logins. How'd you guess? :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From katzj at redhat.com Mon Mar 5 18:15:14 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 05 Mar 2007 13:15:14 -0500 Subject: perl, perl-devel, and missing config.h In-Reply-To: <1173118250.4890.41.camel@localhost.localdomain> References: <1173118250.4890.41.camel@localhost.localdomain> Message-ID: <1173118514.3121.23.camel@aglarond.local> On Mon, 2007-03-05 at 13:10 -0500, Michael Tiemann wrote: > On Mon, 2007-03-05 at 12:18 -0500, Robin Norwood wrote: > > However, one change has been pretty controversial. In accordance with > > standard Fedora packaging, he split the C header files into a > > perl-devel package. These files aren't needed to run perl modules, > > but they are needed to build many perl modules, both in Core and > > Extras. Unfortunately, when I accepted the new spec file and built it > > into rawhide, I didn't think through the consequences fully, and we > > ended up breaking a lot of builds. It was generally not very obvious > > *why* the builds were breaking, leading to much frustration[2]. > > My $0.02: now that the reason is known, and known to be a direct > consequence of Following The Specs, it seems to me that adding the > -devel requirement to packages that do, indeed, need -devel is The Right > Thing. I, for one, am always happy to see a more clear and clean > distinction between the -devel and the non-devel worlds. And fwiw, this parallels the fact that you now need python-devel installed to build python modules (even if they're pure python). Jeremy From david at fubar.dk Mon Mar 5 16:38:59 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 05 Mar 2007 11:38:59 -0500 Subject: FW: F7 T2 Security Leak? In-Reply-To: References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <200703041618.09066.jkeating@redhat.com> <1173044014.7799.29.camel@zelda.fubar.dk> Message-ID: <1173112739.2638.24.camel@zelda.fubar.dk> On Mon, 2007-03-05 at 10:10 -0600, Rex Dieter wrote: > Maybe it could/should use xdg-utils' and emit: > xdg-screensaver lock > on switching? > (Hrm, unless someone/somewhere purposefully doesn't want the screen to lock > on user switch) If by 'it' you mean 'the session', I think it's much easier just to teach the screensaver to do it. David From vonbrand at inf.utfsm.cl Mon Mar 5 19:28:35 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 05 Mar 2007 16:28:35 -0300 Subject: perl, perl-devel, and missing config.h In-Reply-To: <1173118250.4890.41.camel@localhost.localdomain> References: <1173118250.4890.41.camel@localhost.localdomain> Message-ID: <18138.1173122915@laptop13.inf.utfsm.cl> Michael Tiemann wrote: > On Mon, 2007-03-05 at 12:18 -0500, Robin Norwood wrote: [...] > > However, one change has been pretty controversial. In accordance with > > standard Fedora packaging, he split the C header files into a > > perl-devel package. These files aren't needed to run perl modules, > > but they are needed to build many perl modules, both in Core and > > Extras. Unfortunately, when I accepted the new spec file and built it > > into rawhide, I didn't think through the consequences fully, and we > > ended up breaking a lot of builds. It was generally not very obvious > > *why* the builds were breaking, leading to much frustration[2]. > My $0.02: now that the reason is known, and known to be a direct > consequence of Following The Specs, it seems to me that adding the > -devel requirement to packages that do, indeed, need -devel is The Right > Thing. I, for one, am always happy to see a more clear and clean > distinction between the -devel and the non-devel worlds. Yup. But that means breaking other pieces out of perl into perl-devel, like MakeMaker (creating Makefiles for Perl modules is "development", right?). There are surely other pieces that should follow... -- 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 gajownik at gmail.com Mon Mar 5 19:37:04 2007 From: gajownik at gmail.com (Dawid Gajownik) Date: Mon, 05 Mar 2007 20:37:04 +0100 Subject: perl, perl-devel, and missing config.h In-Reply-To: References: Message-ID: <45EC7160.9060204@gmail.com> Dnia 03/05/2007 06:18 PM, U?ytkownik Robin Norwood napisa?: > Hi, Hi! > standard Fedora packaging, he split the C header files into a > perl-devel package. Maybe manpages from %{_mandir}/man3/ also should be put into -devel subpackage? Regards, Dawid -- ^_* From michael.vanderheeren at gmail.com Mon Mar 5 17:28:01 2007 From: michael.vanderheeren at gmail.com (=?utf-8?Q?Micha=C3=ABl_Vanderheeren?=) Date: Mon, 5 Mar 2007 18:28:01 +0100 Subject: FW: F7 T2 Security Leak? In-Reply-To: <200703050904.02519.jkeating@redhat.com> References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <1173044014.7799.29.camel@zelda.fubar.dk> <6a29c8790703050155n8403220sc34f3849a84a1597@mail.gmail.com> <200703050904.02519.jkeating@redhat.com> Message-ID: <45ec5324.3bac47d2.6f56.1412@mx.google.com> I was talking about the Live CD, sorry about forgetting to mention that... -----Oorspronkelijk bericht----- Van: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] Namens Jesse Keating Verzonden: maandag 5 maart 2007 15:04 Aan: fedora-devel-list at redhat.com Onderwerp: Re: FW: F7 T2 Security Leak? On Monday 05 March 2007 04:55:05 Micha?l Vanderheeren wrote: > I installed from F7T2. Could it be that that is the problem? And that > the bug isn't fixed... no, we included gnome-screensaver in the F7 Test2 Prime spin. Unless you're talking about the F7 Test2 LiveCD, which I'm also pretty sure we adjusted to get gnome-screensaver on there. I'm not 100% on that though, I didn't compose it. -- Jesse Keating Release Engineer: Fedora From rdieter at math.unl.edu Mon Mar 5 20:23:07 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 05 Mar 2007 14:23:07 -0600 Subject: FW: F7 T2 Security Leak? References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <200703041618.09066.jkeating@redhat.com> <1173044014.7799.29.camel@zelda.fubar.dk> <1173112739.2638.24.camel@zelda.fubar.dk> Message-ID: David Zeuthen wrote: > On Mon, 2007-03-05 at 10:10 -0600, Rex Dieter wrote: >> Maybe it could/should use xdg-utils' and emit: >> xdg-screensaver lock >> on switching? >> (Hrm, unless someone/somewhere purposefully doesn't want the screen to >> lock on user switch) > > If by 'it' you mean 'the session', I think it's much easier just to > teach the screensaver to do it. Ah, so there's no magic going on other than gnome-screensaver detecting a VT/user/session switch? -- Rex From rnorwood at redhat.com Mon Mar 5 20:55:55 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Mon, 05 Mar 2007 15:55:55 -0500 Subject: perl, perl-devel, and missing config.h In-Reply-To: <1173118250.4890.41.camel@localhost.localdomain> (Michael Tiemann's message of "Mon, 05 Mar 2007 13:10:50 -0500") References: <1173118250.4890.41.camel@localhost.localdomain> Message-ID: Michael Tiemann writes: > On Mon, 2007-03-05 at 12:18 -0500, Robin Norwood wrote: >> Hi, > >> However, one change has been pretty controversial. In accordance with >> standard Fedora packaging, he split the C header files into a >> perl-devel package. These files aren't needed to run perl modules, >> but they are needed to build many perl modules, both in Core and >> Extras. Unfortunately, when I accepted the new spec file and built it >> into rawhide, I didn't think through the consequences fully, and we >> ended up breaking a lot of builds. It was generally not very obvious >> *why* the builds were breaking, leading to much frustration[2]. > > My $0.02: now that the reason is known, and known to be a direct > consequence of Following The Specs, it seems to me that adding the > -devel requirement to packages that do, indeed, need -devel is The Right > Thing. I, for one, am always happy to see a more clear and clean > distinction between the -devel and the non-devel worlds. I don't think any of the people disagreeing with this change mind splitting devel/non-devel - the problems we're facing now revolve around the fact that splitting the 'devel' bits out tend to pull things that people expect to be in a normal perl distribution - like CPAN, for instance. We're still fighting about how to make this work. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From kloczek at zie.pg.gda.pl Mon Mar 5 09:13:39 2007 From: kloczek at zie.pg.gda.pl (Tomasz =?UTF-8?Q?K=C5=82oczko?=) Date: Mon, 05 Mar 2007 10:13:39 +0100 Subject: X server memory leak ? (Re: Announcing Fedora 7 Test 2 (6.91)) In-Reply-To: <1173056320.18771.24.camel@localhost.localdomain> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> <1172771344.22136.118.camel@localhost.localdomain> <1172773609.25356.9.camel@kloczek01.pracownicy.zie> <1172775669.32357.27.camel@localhost.localdomain> <1172777571.32335.11.camel@kloczek01.pracownicy.zie> <1172777460.22136.134.camel@localhost.localdomain> <1172779164.32335.20.camel@kloczek01.pracownicy.zie> <1173056320.18771.24.camel@localhost.localdomain> Message-ID: <1173086019.21501.28.camel@kloczek01.pracownicy.zie> Dnia 04-03-2007, nie o godzinie 18:58 -0600, Callum Lerwick napisa?(a): [..] > Also irritating is millions of javascripts and flash adverts and > animated gifs eating up assloads of CPU in tabs that aren't even > visible. But are you talking about refreshing pages ? In my case problematic refreshing pages contains png but seems it doesn't matter it is png or gif of jpeg files and I can reproduce this also on by hand reloaded page. I can reproduce this also on opened png file in firefox/galeon by refreshing this using ctrl-r. I'm save single png file from zabbix map page (~40KB 1000x1000 png file), generate copy of this file in jpeg and gif and open this files in separated tabs (png, jpeg and gif). Each time ctrl-r press on each tab causes in my case eats next chunk of memory by X server. Before refresh: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3253 root 16 0 1480m 845m 8148 S 12 42.0 787:18.00 Xorg After five time ctrl-r: 3253 root 15 0 1480m 864m 8148 R 8 42.9 787:30.59 Xorg RES groves ~19MB. This png file have 1000x1000 pixels and X display depth is 24bpp. 1000x1000x3 = ~3MB .. so looks like buffer for keep this previous version of this files was not released. Can you check this on your system using above scenario ? Try to open gif/png file which will take big amount of memory in uncompressed form (1MB or more). kloczek From david at fubar.dk Mon Mar 5 21:03:09 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 05 Mar 2007 16:03:09 -0500 Subject: FW: F7 T2 Security Leak? In-Reply-To: References: <45eafd78.6c3fc3bc.45b5.ffff9a08@mx.google.com> <200703041618.09066.jkeating@redhat.com> <1173044014.7799.29.camel@zelda.fubar.dk> <1173112739.2638.24.camel@zelda.fubar.dk> Message-ID: <1173128589.2638.90.camel@zelda.fubar.dk> On Mon, 2007-03-05 at 14:23 -0600, Rex Dieter wrote: > David Zeuthen wrote: > > > On Mon, 2007-03-05 at 10:10 -0600, Rex Dieter wrote: > >> Maybe it could/should use xdg-utils' and emit: > >> xdg-screensaver lock > >> on switching? > >> (Hrm, unless someone/somewhere purposefully doesn't want the screen to > >> lock on user switch) > > > > If by 'it' you mean 'the session', I think it's much easier just to > > teach the screensaver to do it. > > Ah, so there's no magic going on other than gnome-screensaver detecting a > VT/user/session switch? Yeah, I *think* that's how it works but I haven't read through gnome-screensaver after we put in f-u-s. I'll find out. David From michael.vanderheeren at gmail.com Mon Mar 5 10:00:38 2007 From: michael.vanderheeren at gmail.com (=?ISO-8859-1?Q?Micha=EBl_Vanderheeren?=) Date: Mon, 5 Mar 2007 11:00:38 +0100 Subject: FC7 Test2 can't be installed on vmware In-Reply-To: References: Message-ID: <6a29c8790703050200w1093c8e9t4249d72ac2bddb6b@mail.gmail.com> Expected the same with FC6 2007/3/4, ??? : > > Hi, all > > I download FC7 Test2 DVD image. But it reports that "No valid devices were > found on which to create new file systems, Please check you hardware for the > cause of this problem" when I install it on vmware > > My system is P4 with Window XP SP2. Vmware server is 1.0. > > Does FC7 Test2 support installation on vmware or SATA harddisk? > > Thanks > > Best Regards > Sun > > -- > 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 simonb at thoughtpolice.co.uk Mon Mar 5 22:20:42 2007 From: simonb at thoughtpolice.co.uk (Simon B) Date: Mon, 05 Mar 2007 23:20:42 +0100 Subject: FC7 Test2 can't be installed on vmware In-Reply-To: <6a29c8790703050200w1093c8e9t4249d72ac2bddb6b@mail.gmail.com> References: <6a29c8790703050200w1093c8e9t4249d72ac2bddb6b@mail.gmail.com> Message-ID: <1173133242.3069.38.camel@localhost.localdomain> Am Montag, den 05.03.2007, 11:00 +0100 schrieb Micha?l Vanderheeren: > Expected the same with FC6 > > 2007/3/4, ??? : > Hi, all > > I download FC7 Test2 DVD image. But it reports that "No valid > devices were found on which to create new file systems, Please > check you hardware for the cause of this problem" when I > install it on vmware > > My system is P4 with Window XP SP2. Vmware server is 1.0. > > Does FC7 Test2 support installation on vmware or SATA > harddisk? > > Thanks > > Best Regards > Sun It's a bug. A regression. FC7T1 worked until you upgraded the kernel, then it wouldn't boot. To get it working on FC7T2, use the advanced mode and choose the BusLogic SCSI adaptor, or download this: http://www.thoughtpolice.co.uk/vmware/#fedora7t2desktop Simon From michel.salim at gmail.com Mon Mar 5 22:42:38 2007 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 5 Mar 2007 17:42:38 -0500 Subject: announce: readahead-1.4 In-Reply-To: <20070301105026.GF4449@petra.dvoda.cz> References: <20070301105026.GF4449@petra.dvoda.cz> Message-ID: <883cfe6d0703051442v2d74ebe8w6ef1764cd659cbd5@mail.gmail.com> 2007/3/1, Karel Zak : > > I have just pushed out a new 1.4 version of the readahead util. > I welcome your feedback! Send me your comments, ideas for > enhancements or bug reports. > This is more of a planning-for-the-future request, but with Intel bundling Flash memory into their motherboards starting with the Santa Rosa platform to be released this May, would readahead support the use of cache devices? Only trivial modifications are needed: - at boot time, read the cached files from the cache device rather than from the normal partition - whenever the files are changed (due to package update, etc.), copy the modified files to the cache device Would union-mounting the cache device on top of / work? (What if /usr is a separate partition) Regards, -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From kzak at redhat.com Mon Mar 5 23:24:46 2007 From: kzak at redhat.com (Karel Zak) Date: Tue, 6 Mar 2007 00:24:46 +0100 Subject: announce: readahead-1.4 In-Reply-To: <883cfe6d0703051442v2d74ebe8w6ef1764cd659cbd5@mail.gmail.com> References: <20070301105026.GF4449@petra.dvoda.cz> <883cfe6d0703051442v2d74ebe8w6ef1764cd659cbd5@mail.gmail.com> Message-ID: <20070305232446.GH5345@petra.dvoda.cz> On Mon, Mar 05, 2007 at 05:42:38PM -0500, Michel Salim wrote: > 2007/3/1, Karel Zak : > > > > I have just pushed out a new 1.4 version of the readahead util. > > > I welcome your feedback! Send me your comments, ideas for > > enhancements or bug reports. > > > This is more of a planning-for-the-future request, but with Intel > bundling Flash memory into their motherboards starting with the Santa > Rosa platform to be released this May, would readahead support the use > of cache devices? > > Only trivial modifications are needed: > - at boot time, read the cached files from the cache device rather > than from the normal partition > - whenever the files are changed (due to package update, etc.), copy > the modified files to the cache device > > Would union-mounting the cache device on top of / work? (What if /usr > is a separate partition) See: http://lkml.org/lkml/2006/5/15/46 Yes, I can imagine "bootcache" partition (something like swap) where we will store boot files in more effective way than on normal filesystems. Karel -- Karel Zak From ajackson at redhat.com Mon Mar 5 23:19:41 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 05 Mar 2007 18:19:41 -0500 Subject: RANDR 1.2 heads up Message-ID: <1173136781.9948.22.camel@localhost.localdomain> xorg-x11-server-Xorg 1.2.99.901 has RANDR 1.2 support. The client-side bits have been in rawhide for a while, but this adds the server support. The server itself was very close to what we had in rawhide anyway, excluding the RANDR bits, so this _should_ be a low-impact change. As far as I can tell, drivers that are unaware of RANDR 1.2 work the same as ever, so if you're using anything but the intel driver please yell at me very loudly if this regresses anything for you. If you're using the intel driver, well, you've been in experimental land for a while anyway, and now it's going to do even more fun stuff. Stuff I've already hit: - Gnome randr applet crashes. Like, instantly. - Old school xrandr options sometimes do nonintuitive things, particularly for rotation. - DPI is only loosely related to reality. - panel sometimes gets very confused about positioning. - i865 and below probably don't work. But on the plus side, you can enable and disable monitors at runtime now. It's like living in the future. Please file bugs if you hit them (and fixes if you can!), we should be able to get this pretty polished for 7 final. - ajax From otaylor at redhat.com Tue Mar 6 00:06:25 2007 From: otaylor at redhat.com (Owen Taylor) Date: Mon, 05 Mar 2007 19:06:25 -0500 Subject: What applications do people use? Message-ID: <1173139585.2565.89.camel@localhost.localdomain> Those who were at the Mugshot presentation at Fudcon may remember the mockups we presented around browsing applications based on popularity. You can now find an initial implementation at: http://mugshot.org/applications While we don't have much data yet, you can already see some interesting trends. If you're interested, sign up for Mugshot and add your own statistics. Once you activate your account, you'll need to enable statistics tracking from your account page or from the applications page. (You may also want to join the Mugshot Fedora group http://mugshot.org/group?who=qF6wdtBPcy3D8T.) What other information would you like to see there as a Fedora package maintainer? Do you see something built on this as useful for Fedora users? Let us know. If you want discuss the details of how this works or get involved in the development, the mugshot mailing list (http://groups.google.com/group/mugshot) is the best forum. - Owen PS. A few caveats to keep in mind when browsing the data: - It's still a very small amount of data; this is about 80 people contributing statistics over 4 days. - Various applications are missing because they have unusual WM class names; in particular most gtk# applications are not getting properly matched. I'll be fixing these cases up as I find them. - Because of some bugs I didn't find until today, applications used by KDE users are under-represented. (Application data uploads with konsole in them triggered an exception) - I've started some work at allowing editing the data through the web interface, but for now, all the editing is with the command line tools I used to build the initial contents based on Fedora RPMS and is admin-only. From jrc at jrcormier.com Tue Mar 6 00:51:42 2007 From: jrc at jrcormier.com (Jean-Rene Cormier) Date: Mon, 05 Mar 2007 20:51:42 -0400 Subject: RANDR 1.2 heads up In-Reply-To: <1173136781.9948.22.camel@localhost.localdomain> References: <1173136781.9948.22.camel@localhost.localdomain> Message-ID: <1173142302.4742.20.camel@pluto.jrcormier.com> On Mon, 2007-03-05 at 18:19 -0500, Adam Jackson wrote: > - Gnome randr applet crashes. Like, instantly. > - Old school xrandr options sometimes do nonintuitive things, > particularly for rotation. > - DPI is only loosely related to reality. > - panel sometimes gets very confused about positioning. > - i865 and below probably don't work. What exactly won't work with i865 and below? I have manually rebuilt Xorg and quite a few other packages on my FC6 installation to get RANDR 1.2 and it works for some things on my i855. I can turn monitors on and off, change the resolution (sometimes). Though sometimes the laptop froze after bootup or while the screensaver was on. -- Jean-Rene Cormier From mike at miketc.com Tue Mar 6 02:38:24 2007 From: mike at miketc.com (Mike Chambers) Date: Mon, 05 Mar 2007 20:38:24 -0600 Subject: What applications do people use? In-Reply-To: <1173139585.2565.89.camel@localhost.localdomain> References: <1173139585.2565.89.camel@localhost.localdomain> Message-ID: <1173148704.2322.1.camel@scrappy.miketc.com> On Mon, 2007-03-05 at 19:06 -0500, Owen Taylor wrote: > If you want discuss the details of how this works or get involved in the > development, the mugshot mailing list > (http://groups.google.com/group/mugshot) is the best forum. I take it mugshot won't work with current FC7 builds, in which it looks like it depends currently on libcurl.so.3 , in which FC7 has .4. -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless your not getting any!" From davej at redhat.com Tue Mar 6 03:47:24 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 5 Mar 2007 22:47:24 -0500 Subject: Kernel 2.6.19 squashfs problem and bugzilla In-Reply-To: References: <20070302153703.GA7038@dspnet.fr.eu.org> <20070302211758.GB20893@redhat.com> Message-ID: <20070306034724.GA14486@redhat.com> On Mon, Mar 05, 2007 at 04:17:39PM +0000, Phillip Lougher wrote: > Dave Jones redhat.com> writes: > > > > > On Fri, Mar 02, 2007 at 04:37:03PM +0100, Olivier Galibert wrote: > > > The kernel from kernel-2.6.19-1.2288.fc5.x86_64.rpm is not able to > > > loop-mount the fc5 install Fedora/base/stage2.img file, at least > > > through nfs. You get: > > > squashfs: version 3.2-alpha (2006/12/12) Phillip Lougher > > > SQUASHFS error: sb_bread failed reading block 0x9e8be8e1 > > > SQUASHFS error: unable to read inode lookup table > > > > squashfs isn't compatible between releases. > > > > Squashfs is now generally compatible between releases. A later release > of Squashfs can mount filesystems from earlier releases (i.e. 3.2 > can mount 3.1, 3.0 and earlier filesystems). Earlier releases of > Squashfs generally couldn't mount later filesystem versions, however, > since 3.0 I have tried to maintain both backwards and forwards > compatibility, and a 3.0 patched kernel can mount 3.2 filesystems. Thanks for the info. I'll look at moving our trees from 3.2-alpha to 3.2 final tomorrow. Any signs of this heading upstream any time soon? Dave -- http://www.codemonkey.org.uk From lsof at nodata.co.uk Tue Mar 6 06:56:57 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 06 Mar 2007 07:56:57 +0100 Subject: What applications do people use? In-Reply-To: <1173139585.2565.89.camel@localhost.localdomain> References: <1173139585.2565.89.camel@localhost.localdomain> Message-ID: <1173164217.3035.0.camel@sb-home.lan> Am Montag, den 05.03.2007, 19:06 -0500 schrieb Owen Taylor: > If you're interested, sign up for Mugshot and add your own statistics. I don't want to signup for yet another thing (!) Please can you make it less work for us and add the feature to that hardware profile sender thing? From jspaleta at gmail.com Tue Mar 6 07:21:11 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 5 Mar 2007 22:21:11 -0900 Subject: What applications do people use? In-Reply-To: <1173164217.3035.0.camel@sb-home.lan> References: <1173139585.2565.89.camel@localhost.localdomain> <1173164217.3035.0.camel@sb-home.lan> Message-ID: <604aa7910703052321h776f02d3h9d5749dba2ef121a@mail.gmail.com> On 3/5/07, nodata wrote: > Please can you make it less work for us and add the feature to that > hardware profile sender thing? uhm... smolt would need to be drastically redesigned to make that possible. Since application use is a per-user statistic, and smolt is designed for per operating system stats which does not leak personal information. I'm pretty sure its a bad idea to have smolt track per user activity. I have no problem with smolt being available by default as an opt-in service at install time, if its only tracking hardware information. I'd have a pretty serious problem with it being a default opt-in service that tracked individual user activity. If you don't want to sign up to mugshot, don't. But since this 'service' is tracking individual users, then it definitely need to be a 'service' that individual users MUST register for to participate. As an admin for multi-users systems, I will fight you tooth and nail to keep this sort of 'service' as a per-user registration required opt-in entity. -jef"wtf can't mugshot support online services I actually use.... and how the frell do I request the mugshot maintainers to add support for specific individual services?"spaleta From hughsient at gmail.com Tue Mar 6 08:38:51 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 6 Mar 2007 08:38:51 +0000 Subject: What applications do people use? In-Reply-To: <1173148704.2322.1.camel@scrappy.miketc.com> References: <1173139585.2565.89.camel@localhost.localdomain> <1173148704.2322.1.camel@scrappy.miketc.com> Message-ID: <15e53e180703060038q6d989734n8a63ac8c98d9950a@mail.gmail.com> On 06/03/07, Mike Chambers wrote: > On Mon, 2007-03-05 at 19:06 -0500, Owen Taylor wrote: > > > If you want discuss the details of how this works or get involved in the > > development, the mugshot mailing list > > (http://groups.google.com/group/mugshot) is the best forum. > > I take it mugshot won't work with current FC7 builds, in which it looks > like it depends currently on libcurl.so.3 , in which FC7 has .4. I just rebuilt the SRPM. Seems to work great. Richard. From atkac at redhat.com Tue Mar 6 09:33:33 2007 From: atkac at redhat.com (Adam Tkac) Date: Tue, 06 Mar 2007 10:33:33 +0100 Subject: VNC development plan - discuss Message-ID: <45ED356D.7060204@redhat.com> Hi all, I did thinking about next development on vnc bits. Fedora 7 has three vnc servers - GNOME's vino, KDE's krfb and headless Xvnc with module to X. I'm not sure that we really need three different vnc servers in distribution. krfb and vino are very simillar. Both of these export real display. I think we could try substitute this two servers by one - for example x11vnc (http://www.karlrunge.com/x11vnc/). x11vnc has more features than actual "real desktop" servers. So two programs could be removed and one added => cost of maintaining and bugfixing could be lower. In next stage we could discuss about standardized RFB protocol library which could be used by all vnc servers in distro. In the end we could have one rfb library which will be used by all servers (and viewers), one real server, one virtual server and X module. What do you think about this idea? Regards, Adam From pertusus at free.fr Tue Mar 6 09:32:49 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 6 Mar 2007 10:32:49 +0100 Subject: VNC development plan - discuss In-Reply-To: <45ED356D.7060204@redhat.com> References: <45ED356D.7060204@redhat.com> Message-ID: <20070306093249.GA2867@free.fr> On Tue, Mar 06, 2007 at 10:33:33AM +0100, Adam Tkac wrote: > Hi all, > > viewers), one real server, one virtual server and X module. What do you > think about this idea? Just orphan the vnc servers you don't want to maintain, if somebody is interested then they'll be kept. For the parts that are tighlty integrated in fedora (for example a vnc server used by anaconda) it is indeed better to have only one vnc server used. -- Pat From atkac at redhat.com Tue Mar 6 09:52:41 2007 From: atkac at redhat.com (Adam Tkac) Date: Tue, 06 Mar 2007 10:52:41 +0100 Subject: VNC development plan - discuss In-Reply-To: <20070306093249.GA2867@free.fr> References: <45ED356D.7060204@redhat.com> <20070306093249.GA2867@free.fr> Message-ID: <45ED39E9.3020304@redhat.com> Patrice Dumas napsal(a): > On Tue, Mar 06, 2007 at 10:33:33AM +0100, Adam Tkac wrote: > >> Hi all, >> >> viewers), one real server, one virtual server and X module. What do you >> think about this idea? >> > > Just orphan the vnc servers you don't want to maintain, if somebody is > interested then they'll be kept. For the parts that are tighlty > integrated in fedora (for example a vnc server used by anaconda) it is > indeed better to have only one vnc server used. > > -- > Pat > > I don't want leave vnc maintaning. I only want fire away duplicates (vino + krfb, I don't maintain any of these) and substitute it by more scalable x11vnc. I think vino + krfb maintainers could write comment here what they think about this change. And about only one server - I think it is so hard to write all-in-one server with good "real desktops" and "virtual desktops" performance. But it is development challenge :) Adam From pertusus at free.fr Tue Mar 6 09:58:37 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 6 Mar 2007 10:58:37 +0100 Subject: VNC development plan - discuss In-Reply-To: <45ED39E9.3020304@redhat.com> References: <45ED356D.7060204@redhat.com> <20070306093249.GA2867@free.fr> <45ED39E9.3020304@redhat.com> Message-ID: <20070306095837.GB2867@free.fr> On Tue, Mar 06, 2007 at 10:52:41AM +0100, Adam Tkac wrote: > > > I don't want leave vnc maintaning. I only want fire away duplicates > (vino + krfb, I don't maintain any of these) and substitute it by more > scalable x11vnc. I think vino + krfb maintainers could write comment Duplicates in fedora are good. Why do you want to fire them away? The only criterion for having a package in fedora (besides being free software) is that there is a maintainer for it. In rare cases (for example buggy unmaintained package without upstream that a packager don't have time to fix) it may make sense to discuss about retiring the package, but only if it is broken. Duplication isn't an issue at all, or, rather, is a very good thing. -- Pat From nicolas.mailhot at laposte.net Tue Mar 6 10:08:18 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 6 Mar 2007 11:08:18 +0100 (CET) Subject: VNC development plan - discuss In-Reply-To: <45ED39E9.3020304@redhat.com> References: <45ED356D.7060204@redhat.com> <20070306093249.GA2867@free.fr> <45ED39E9.3020304@redhat.com> Message-ID: <31745.192.54.193.51.1173175698.squirrel@rousalka.dyndns.org> Le Mar 6 mars 2007 10:52, Adam Tkac a ?crit : > I don't want leave vnc maintaning. I only want fire away duplicates > (vino + krfb, I don't maintain any of these) and substitute it by more > scalable x11vnc. Methinks you want to talk to evince & kpdf guys on how they agreed to move to poppler, and follow the same process for vnc stuff Regards, -- Nicolas Mailhot From kwade at redhat.com Tue Mar 6 10:09:33 2007 From: kwade at redhat.com (Karsten Wade) Date: Tue, 06 Mar 2007 02:09:33 -0800 Subject: What applications do people use? In-Reply-To: <604aa7910703052321h776f02d3h9d5749dba2ef121a@mail.gmail.com> References: <1173139585.2565.89.camel@localhost.localdomain> <1173164217.3035.0.camel@sb-home.lan> <604aa7910703052321h776f02d3h9d5749dba2ef121a@mail.gmail.com> Message-ID: <1173175773.2865.293.camel@erato.phig.org> On Mon, 2007-03-05 at 22:21 -0900, Jeff Spaleta wrote: [snip_accurate_assessment_of_the_situation]++ > -jef"wtf can't mugshot support online services I actually use.... and > how the frell do I request the mugshot maintainers to add support for > specific individual services?"spaleta http://bugzilla.mugshot.org/index.cgi However, you have to sign up for yet-another-account. Working on fixing that, but nothing coming this week. :) Here's where to find all the juicy developer-of-mugshot bits: http://developer.mugshot.org/wiki/Mugshot_Project - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- 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 atkac at redhat.com Tue Mar 6 10:13:31 2007 From: atkac at redhat.com (Adam Tkac) Date: Tue, 06 Mar 2007 11:13:31 +0100 Subject: VNC development plan - discuss In-Reply-To: <20070306095837.GB2867@free.fr> References: <45ED356D.7060204@redhat.com> <20070306093249.GA2867@free.fr> <45ED39E9.3020304@redhat.com> <20070306095837.GB2867@free.fr> Message-ID: <45ED3ECB.2060900@redhat.com> Patrice Dumas napsal(a): > On Tue, Mar 06, 2007 at 10:52:41AM +0100, Adam Tkac wrote: > >>> >>> >> I don't want leave vnc maintaning. I only want fire away duplicates >> (vino + krfb, I don't maintain any of these) and substitute it by more >> scalable x11vnc. I think vino + krfb maintainers could write comment >> > > Duplicates in fedora are good. Why do you want to fire them away? The > only criterion for having a package in fedora (besides being free > software) is that there is a maintainer for it. In rare cases (for > example buggy unmaintained package without upstream that a packager > don't have time to fix) it may make sense to discuss about retiring > the package, but only if it is broken. Duplication isn't an issue at > all, or, rather, is a very good thing. > > -- > Pat > > Of course that duplications are really good thinks. I love when I can select best application for my requirement. I want put this packages away because x11vnc has same functions like that packages but brings many new options. If I try compare this change with something I think it is same like you have two standard cars and you could substitute it by one rolls-royce (quite extreme comparsion:) ) Adam From kwade at redhat.com Tue Mar 6 10:13:48 2007 From: kwade at redhat.com (Karsten Wade) Date: Tue, 06 Mar 2007 02:13:48 -0800 Subject: What applications do people use? In-Reply-To: <1173164217.3035.0.camel@sb-home.lan> References: <1173139585.2565.89.camel@localhost.localdomain> <1173164217.3035.0.camel@sb-home.lan> Message-ID: <1173176029.2865.297.camel@erato.phig.org> On Tue, 2007-03-06 at 07:56 +0100, nodata wrote: > Am Montag, den 05.03.2007, 19:06 -0500 schrieb Owen Taylor: > > If you're interested, sign up for Mugshot and add your own statistics. > > I don't want to signup for yet another thing (!) You are heard. Loud and clear. Can't do more at this moment than promise, "We're working on it." In the meantime, all these disparate services are out there, standing alone, for those who want to be on that curve. > Please can you make it less work for us and add the feature to that > hardware profile sender thing? Jef explained this well; the missions are orthogonal. - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- 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 jonathan.underwood at gmail.com Tue Mar 6 10:22:18 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Tue, 6 Mar 2007 10:22:18 +0000 Subject: VNC development plan - discuss In-Reply-To: <45ED356D.7060204@redhat.com> References: <45ED356D.7060204@redhat.com> Message-ID: <645d17210703060222g2e49cd8es1dc90f5730c42b36@mail.gmail.com> On 06/03/07, Adam Tkac wrote: > Hi all, > > I did thinking about next development on vnc bits. Fedora 7 has three > vnc servers - GNOME's vino, KDE's krfb and headless Xvnc with module to > X. I'm not sure that we really need three different vnc servers in > distribution. krfb and vino are very simillar. Both of these export real > display. I think we could try substitute this two servers by one - for > example x11vnc (http://www.karlrunge.com/x11vnc/). x11vnc has more > features than actual "real desktop" servers. So two programs could be > removed and one added => cost of maintaining and bugfixing could be > lower. In next stage we could discuss about standardized RFB protocol > library which could be used by all vnc servers in distro. In the end we > could have one rfb library which will be used by all servers (and > viewers), one real server, one virtual server and X module. What do you > think about this idea? > As an aside... Intrigued about these different possibilities that I wasn't aware of, I googled a bit, and found this excellent summary of the currently available options: http://gentoo-wiki.com/VNC From hughsient at gmail.com Tue Mar 6 10:28:25 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 6 Mar 2007 10:28:25 +0000 Subject: What applications do people use? In-Reply-To: <1173175773.2865.293.camel@erato.phig.org> References: <1173139585.2565.89.camel@localhost.localdomain> <1173164217.3035.0.camel@sb-home.lan> <604aa7910703052321h776f02d3h9d5749dba2ef121a@mail.gmail.com> <1173175773.2865.293.camel@erato.phig.org> Message-ID: <15e53e180703060228vef45347tbb74780b8c8bfd5d@mail.gmail.com> On 06/03/07, Karsten Wade wrote: > Here's where to find all the juicy developer-of-mugshot bits: > > http://developer.mugshot.org/wiki/Mugshot_Project Any reason mugshot client isn't in Fedora Extras? Seems a bit odd to me, considering it's free software, and needs to be updated fairly frequently, and built by a company that understands free software. :-) Richard. From sundaram at fedoraproject.org Tue Mar 6 10:54:08 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 06 Mar 2007 16:24:08 +0530 Subject: What applications do people use? In-Reply-To: <15e53e180703060228vef45347tbb74780b8c8bfd5d@mail.gmail.com> References: <1173139585.2565.89.camel@localhost.localdomain> <1173164217.3035.0.camel@sb-home.lan> <604aa7910703052321h776f02d3h9d5749dba2ef121a@mail.gmail.com> <1173175773.2865.293.camel@erato.phig.org> <15e53e180703060228vef45347tbb74780b8c8bfd5d@mail.gmail.com> Message-ID: <45ED4850.2030005@fedoraproject.org> Richard Hughes wrote: > On 06/03/07, Karsten Wade wrote: >> Here's where to find all the juicy developer-of-mugshot bits: >> >> http://developer.mugshot.org/wiki/Mugshot_Project > > Any reason mugshot client isn't in Fedora Extras? Seems a bit odd to > me, considering it's free software, and needs to be updated fairly > frequently, and built by a company that understands free software. :-) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212003 Rahul From pertusus at free.fr Tue Mar 6 11:26:08 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 6 Mar 2007 12:26:08 +0100 Subject: VNC development plan - discuss In-Reply-To: <45ED3ECB.2060900@redhat.com> References: <45ED356D.7060204@redhat.com> <20070306093249.GA2867@free.fr> <45ED39E9.3020304@redhat.com> <20070306095837.GB2867@free.fr> <45ED3ECB.2060900@redhat.com> Message-ID: <20070306112608.GC2867@free.fr> On Tue, Mar 06, 2007 at 11:13:31AM +0100, Adam Tkac wrote: > > > Of course that duplications are really good thinks. I love when I can > select best application for my requirement. I want put this packages > away because x11vnc has same functions like that packages but brings > many new options. If I try compare this change with something I think it > is same like you have two standard cars and you could substitute it by > one rolls-royce (quite extreme comparsion:) ) Not anybody like rolls-royces. For reasons known only by users they may prefer standard cars. As long as somebody is interested in providing standard cars, this should be done. Of course if the design/requirements of different programs are exactly the same and one is better then it may go away, but it should happen naturally, with upstream stopping to do the duplicate work and work on the best alternative, then the package would be deprecated in fedora. Once again, as long as the package is living somewhere and somebody is interested in maintaining it it should be in fedora. In the particular case of those vnc servers I doubt they are exact substitute. -- Pat From buildsys at redhat.com Tue Mar 6 11:38:53 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 6 Mar 2007 06:38:53 -0500 Subject: rawhide report: 20070306 changes Message-ID: <200703061138.l26Bcrj2012027@hs20-bc2-6.build.redhat.com> Updated Packages: anaconda-11.2.0.29-1 -------------------- * Mon Mar 05 2007 Jeremy Katz - 11.2.0.29-1 - Fix some typos (clumens, dcantrell, katzj) - Use depsolving from yum instead of our own stuff now that the yum depsolving doesn't require header downloads - Misc backend cleanups - Fix deprecation warnings (#230951) - Networking fixing (#210370) - BR newt-static brltty-3.7.2-3.fc7 ------------------ * Mon Mar 05 2007 Tomas Janousek - 3.7.2-3 - added the XWindow driver - build fix for newer byacc cairo-java-1.0.5-6.fc7 ---------------------- * Mon Mar 05 2007 Stepan Kasal - 1.0.5-6 - Touch aclocal.m4, configure, Makefile.in after applying the patch. - Force -fPIC and avoid -Wall with gcj/ecj. * Wed Feb 21 2007 Andrew Overholt 1.0.5-5 - Bump for new gcj. - Add patch for gcjh -> gjavah. cscope-15.5-15.4.fc7 -------------------- * Mon Mar 05 2007 Neil Horman -15.5-15.4.dist - Make sigwinch handler only register for curses mode (bz 230862) dhcdbd-2.6-1.fc7 ---------------- * Mon Mar 05 2007 David Cantrell - 2.6-1 - Spec file cleanups to conform to Fedora packaging guidelines - Run 'chkconfig --del dhcdbd' on package removal (#222514) dhcp-12:3.0.5-25.fc7 -------------------- * Mon Mar 05 2007 David Cantrell - 12:3.0.5-25 - Man pages need 0644 permissions (#222572) * Thu Mar 01 2007 David Cantrell - 12:3.0.5-24 - Include contrib/ subdirectory in /usr/share/doc (#230476) - Added back Requires for perl since dhcpd-conf-to-ldap needs it (#225691) - Put copies of dhcp-options and dhcp-eval man pages in the dhcp and dhclient packages rather than having the elaborate symlink collection - Explicitly name man pages in the %files listings - Use the %{_sysconfdir} and %{_initrddir} macros (#225691) - Use macros for commands in %build and %install - Split README.ldap, draft-ietf-dhc-ldap-schema-01.txt, and dhcpd-conf-to-ldap.pl out of the LDAP patch - Split linux.dbus-example script out of the extended new option info patch - Remove unnecessary changes from the Makefile patch * Wed Feb 28 2007 David Cantrell - 12:3.0.5-23 - Update Xen partial checksums patch - Remove perl Requires (#225691) - Make dhcp-devel depend on dhcp = e:v-r (#225691) - libdhcp4client-devel Requires pkgconfig (#225691) - Do not add to RPM_OPT_FLAGS, use COPTS variable instead (#225691) - Use %{buildroot} macro instead of RPM_BUILD_ROOT variable (#225691) - Preserve timestamps on all installed data files (#225691) - Remove dhcp-options.5.gz and dhcp-eval.5.gz symlinking in post (#225691) - Use %defattr(-,root,root,-) (#225691) - Do not flag init scripts as %config in %files section (#225691) fonts-indic-2.1.4-1.fc7 ----------------------- * Mon Mar 05 2007 Parag Nemade - 2.1.4 - Resolved Bugs from Parag Nemade - Bug 221383: [kn_IN] GSUB combinations has problem with Ra glib-java-0.2.6-8.fc7 --------------------- * Mon Mar 05 2007 Stepan Kasal - 0.2.6-8 - Touch aclocal.m4, configure, Makefile.in after applying the patch. gnupg-1.4.7-3 ------------- * Mon Mar 05 2007 Nalin Dahyabhai - 1.4.7-3 - update to 1.4.7, changing the default to not allow multiple plaintexts in a single stream gzip-1.3.11-1.fc7 ----------------- * Mon Mar 05 2007 Ivana Varekova - 1.3.11-1 - update to 1.3.11 remove uncompress kdeadmin-7:3.5.6-2.fc7 ---------------------- * Mon Mar 05 2007 Than Ngo - 7:3.5.6-2.fc7 - cleanup specfiles kdepim-6:3.5.6-3.fc7 -------------------- * Mon Mar 05 2007 Than Ngo 3.5.6-3.fc7 - cleanup specfile kernel-2.6.20-1.2966.fc7 ------------------------ * Mon Mar 05 2007 Dave Jones - Generate modules.(scsi|libata|networking) * Mon Mar 05 2007 Dave Jones - 2.6.21rc2-git4 * Mon Mar 05 2007 Dave Jones - 2.6.21rc2-git3 libdhcp-1.23-1.fc7 ------------------ * Mon Mar 05 2007 David Cantrell - 1.23-1 - Pass %{_libdir} in %install * Mon Mar 05 2007 David Cantrell - 1.22-1 - Remove unused variables from nic.c * Mon Mar 05 2007 David Cantrell - 1.21-1 - Spec file cleanups for Fedora packaging guidelines - Lose some of the NIC_DEBUG noise (#199481) libgtk-java-2.8.7-4.fc7 ----------------------- * Mon Mar 05 2007 Stepan Kasal - 2.8.7-4 - Touch aclocal.m4, configure, Makefile.in after applying patch1. - Force -fPIC and avoid -Wall with gcj/ecj. * Wed Feb 21 2007 Andrew Overholt 2.8.7-3 - Rebuild for new gcj. - Add patch for gcjh -> gjavah. man-pages-fr-2.39-8.fc7 ----------------------- * Mon Mar 05 2007 Marcela Maslanova 2.39-8 - merge review - rhbz#230061 mlocate-0.16-1 -------------- * Tue Mar 06 2007 Miloslav Trmac - 0.16-1 - Update to mlocate-0.16 - Enable PRUNE_BIND_MOUNTS by default Resolves: #221755 openoffice.org-1:2.2.0-10.1 --------------------------- * Sun Mar 04 2007 Caolan McNamara - 1:2.2.0-10.1 - next release candidate - drop d_type patch, no perceptable difference in performance http://people.redhat.com/caolanm/speed/d_type.ods privoxy-3.0.6-7.fc7 ------------------- * Mon Mar 05 2007 Karsten Hopp 3.0.6-7 - rpmlint fixes * Mon Mar 05 2007 Karsten Hopp 3.0.6-6 - add upstream patch for dynamic pcre (#226316) - use kill -s HUP instead of 'kill -HUP' (#193159) setroubleshoot-1.9.3-1.fc7 -------------------------- * Mon Mar 05 2007 John Dennis - 1.9.3-1 - install icon in /usr/share/icons, refer to icon by name using standard API - Fix performance problems in setroubleshoot browser log file scanning - Significant rewrite of data/view management code in setroubleshoot browser. data and view now cleanly separated, can easily switch between data views while maintaining selections, view state, with proper update of status information in status area - Resolves Bug# 227806: right click context menu resets selection - Logfile scans now operate in independent thread, proper asynchronous updates of browser during scan, browser used to appear to hang - Resolves Bug# 224340: Rewrite Menu/Toobar/Popup to use UIManger instead of glade - Add toobar support - Implement GUI to edit email recipient list in setroubleshoot browser - Added user help to setroubleshoot browser - Related Bug# 224343: Fix setroubleshoot browser to respond to desktop theme changes - improve traceback error reporting in sealert - rewrite AboutDialog, replacing glade version - Resolves bug #229849 Bug# 230115, Relates bug #221850: fix uuid code to resolve '_uuid_generate_random' is not defined error tcp_wrappers-7.6-42.fc7 ----------------------- * Mon Mar 05 2007 Tomas Janousek - 7.6-42 - added Obsoletes field so that the upgrade goes cleanly - added dist tag vixie-cron-4:4.1-76.fc7 ----------------------- * Mon Mar 05 2007 Marcela Maslanova - 4:4.1-76 - rhbz#226529 merge review vnc-4.1.2-15.fc7 ---------------- * Mon Mar 05 2007 Adam Tkac 4.1.2-15.fc7 - improved vnc-always_use_fb patch (some screen defects on 64bits) - removed xserver tarball from source list xorg-x11-drv-i810-1.6.5-13.fc7 ------------------------------ * Mon Mar 05 2007 Adam Jackson 1.6.5-13 - Updated modesetting driver to one that will actually work with a 1.3 server. xorg-x11-server-1.2.99.901-1.fc7 -------------------------------- * Mon Mar 05 2007 Adam Jackson 1.2.99.901-1 - xserver 1.3 RC1. RANDR 1.2 hotness in the hizzouse. - xserver-1.2.0-honor-displaysize.patch: Honor the DisplaySize config directive again (#220248) - Clean up the post-install cleanup * Fri Mar 02 2007 Adam Tkac 1.2.0-10 - change permissions of files in source package to default from read-only * Mon Feb 26 2007 Adam Tkac 1.2.0-9 - Created new package (xorg-x11-server-source) which is needed to build VNC server. zsh-4.2.6-6.fc7 --------------- * Mon Mar 05 2007 James Antill - 4.2.6-6 - Move requires to be scriptlet specific - chmod functions, to shut rpmlint up (false positive warning) - sed only the requied functions (again, shuts rpmlint up) - Remove zsh-4.0.6-make-test-fail.patch - Remove RPM_SOURCE_DIR var, using %{SOURCEx} and basename Resolves: rhbz#226813 Broken deps for i386 ---------------------------------------------------------- frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.i386 requires xdg-utils libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh Broken deps for x86_64 ---------------------------------------------------------- frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.x86_64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.x86_64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.i386 requires libgcj.so.7rh libgconf-java - 2.12.4-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.i386 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.i386 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.x86_64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.i386 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.x86_64 requires libgcj.so.7rh()(64bit) Broken deps for ia64 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ia64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ia64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ia64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ia64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ia64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ia64 requires lm_sensors-devel Broken deps for s390 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390 requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel 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 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ppc requires libofx.so.3 gnucash - 2.0.5-1.fc6.ppc requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.ppc requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ppc requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.ppc requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.ppc requires libgcj.so.7rh libvte-java - 0.12.1-5.fc7.ppc requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.ppc requires lm_sensors-devel Broken deps for s390x ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.s390x requires libofx.so.3()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.s390x requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390x requires xdg-utils libgconf-java - 2.12.4-5.fc7.s390x requires libgcj.so.7rh()(64bit) libgconf-java - 2.12.4-5.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390 requires libgcj.so.7rh libglade-java - 2.12.5-4.fc7.s390x requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.s390 requires libgcj.so.7rh libgnome-java - 2.12.4-4.fc7.s390x requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.s390x requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.s390 requires libgcj.so.7rh net-snmp-devel - 1:5.4-10.fc7.s390x requires lm_sensors-devel net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel Broken deps for ppc64 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ppc64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ppc64 requires xdg-utils libgconf-java - 2.12.4-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) libglade-java - 2.12.5-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libgnome-java - 2.12.4-4.fc7.ppc64 requires libgcj.so.7rh()(64bit) libvte-java - 0.12.1-5.fc7.ppc64 requires libgcj.so.7rh()(64bit) net-snmp-devel - 1:5.4-10.fc7.ppc64 requires lm_sensors-devel From markmc at redhat.com Tue Mar 6 11:53:29 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 06 Mar 2007 11:53:29 +0000 Subject: VNC development plan - discuss In-Reply-To: <45ED356D.7060204@redhat.com> References: <45ED356D.7060204@redhat.com> Message-ID: <1173182009.3288.67.camel@blaa> On Tue, 2007-03-06 at 10:33 +0100, Adam Tkac wrote: > Hi all, > > I did thinking about next development on vnc bits. Fedora 7 has three > vnc servers - GNOME's vino, KDE's krfb and headless Xvnc with module to > X. I'm not sure that we really need three different vnc servers in > distribution. krfb and vino are very simillar. Both of these export real > display. I think we could try substitute this two servers by one - for > example x11vnc (http://www.karlrunge.com/x11vnc/). x11vnc has more > features than actual "real desktop" servers. So two programs could be > removed and one added => cost of maintaining and bugfixing could be > lower. vino and krfb have different goals and UIs that are designed to be well integrated into their respective environments. I don't think merging the two makes any more sense than e.g. merging evolution and kmail because they both talk the SMTP protocol. > In next stage we could discuss about standardized RFB protocol > library which could be used by all vnc servers in distro. In the end we > could have one rfb library which will be used by all servers (and > viewers), one real server, one virtual server and X module. What do you > think about this idea? A common rfb server library would definitely be useful, yes. libvncserver should be it, but it needs serious re-factoring before we could ever hope for API/ABI stability. Indeed, a common library between vino and krfb could do a lot more - e.g. the screen scraping and keyboard handling. Cheers, Mark. From atkac at redhat.com Tue Mar 6 12:23:33 2007 From: atkac at redhat.com (Adam Tkac) Date: Tue, 06 Mar 2007 13:23:33 +0100 Subject: VNC development plan - discuss In-Reply-To: <1173182009.3288.67.camel@blaa> References: <45ED356D.7060204@redhat.com> <1173182009.3288.67.camel@blaa> Message-ID: <45ED5D45.2000903@redhat.com> Mark McLoughlin napsal(a): > On Tue, 2007-03-06 at 10:33 +0100, Adam Tkac wrote: > >> Hi all, >> >> I did thinking about next development on vnc bits. Fedora 7 has three >> vnc servers - GNOME's vino, KDE's krfb and headless Xvnc with module to >> X. I'm not sure that we really need three different vnc servers in >> distribution. krfb and vino are very simillar. Both of these export real >> display. I think we could try substitute this two servers by one - for >> example x11vnc (http://www.karlrunge.com/x11vnc/). x11vnc has more >> features than actual "real desktop" servers. So two programs could be >> removed and one added => cost of maintaining and bugfixing could be >> lower. >> > > vino and krfb have different goals and UIs that are designed to be well > integrated into their respective environments. I don't think merging the > two makes any more sense than e.g. merging evolution and kmail because > they both talk the SMTP protocol. > I don't think that integrating to specified environment is useful in this case. In my opinion kde & gnome use same xserver with same policies so vino and krfb (and x11vnc) is more about xserver than about specific UIs. This is main argument why could be these programs merged to one. It is very easy write simple GUI with two buttons - "start remote desktop" and "stop remote desktop" - which could works under gnome and kde and other window managers. > >> In next stage we could discuss about standardized RFB protocol >> library which could be used by all vnc servers in distro. In the end we >> could have one rfb library which will be used by all servers (and >> viewers), one real server, one virtual server and X module. What do you >> think about this idea? >> > > A common rfb server library would definitely be useful, yes. > libvncserver should be it, but it needs serious re-factoring before we > could ever hope for API/ABI stability. > > Indeed, a common library between vino and krfb could do a lot more - > e.g. the screen scraping and keyboard handling. > > Cheers, > Mark. > > I think this issue is about discuss which current RFB interface has best API design and about write simple binding to this interface (in first stage, then upstream could start using this library and all could works fine) Regards, Adam From jkeating at redhat.com Tue Mar 6 14:32:48 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Mar 2007 09:32:48 -0500 Subject: VNC development plan - discuss In-Reply-To: <45ED356D.7060204@redhat.com> References: <45ED356D.7060204@redhat.com> Message-ID: <200703060932.51860.jkeating@redhat.com> On Tuesday 06 March 2007 04:33:33 Adam Tkac wrote: > I did thinking about next development on vnc bits. Fedora 7 has three > vnc servers - GNOME's vino, KDE's krfb and headless Xvnc with module to > X. I'm not sure that we really need three different vnc servers in > distribution. krfb and vino are very simillar. Both of these export real > display. I think we could try substitute this two servers by one - for > example x11vnc (http://www.karlrunge.com/x11vnc/). x11vnc has more > features than actual "real desktop" servers. So two programs could be > removed and one added => cost of maintaining and bugfixing could be > lower. In next stage we could discuss about standardized RFB protocol > library which could be used by all vnc servers in distro. In the end we > could have one rfb library which will be used by all servers (and > viewers), one real server, one virtual server and X module. What do you > think about this idea? As others have stated, you should move forward with the VNC you wish to support, and we'll try to make sure it is marked as default in the right groups and be the only vnc included in the spins. However the other vncs can remain in the distribution if there is a willing maintainer and if they don't have any conflicts (file conflicts) with the other VNC software. -- 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 mharris at mharris.ca Tue Mar 6 13:46:10 2007 From: mharris at mharris.ca (Mike A. Harris) Date: Tue, 06 Mar 2007 08:46:10 -0500 Subject: X server memory leak ? (Re: Announcing Fedora 7 Test 2 (6.91)) In-Reply-To: <1173086019.21501.28.camel@kloczek01.pracownicy.zie> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> <1172771344.22136.118.camel@localhost.localdomain> <1172773609.25356.9.camel@kloczek01.pracownicy.zie> <1172775669.32357.27.camel@localhost.localdomain> <1172777571.32335.11.camel@kloczek01.pracownicy.zie> <1172777460.22136.134.camel@localhost.localdomain> <1172779164.32335.20.camel@kloczek01.pracownicy.zie> <1173056320.18771.24.camel@localhost.localdomain> <1173086019.21501.28.camel@kloczek01.pracownicy.zie> Message-ID: <45ED70A2.7000006@mharris.ca> Tomasz K?oczko wrote: > Dnia 04-03-2007, nie o godzinie 18:58 -0600, Callum Lerwick napisa?(a): > [..] >> Also irritating is millions of javascripts and flash adverts and >> animated gifs eating up assloads of CPU in tabs that aren't even >> visible. > > But are you talking about refreshing pages ? > In my case problematic refreshing pages contains png but seems it > doesn't matter it is png or gif of jpeg files and I can reproduce this > also on by hand reloaded page. I can reproduce this also on opened png > file in firefox/galeon by refreshing this using ctrl-r. > I'm save single png file from zabbix map page (~40KB 1000x1000 png > file), generate copy of this file in jpeg and gif and open this files in > separated tabs (png, jpeg and gif). > Each time ctrl-r press on each tab causes in my case eats next chunk of > memory by X server. > > Before refresh: > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 3253 root 16 0 1480m 845m 8148 S 12 42.0 787:18.00 Xorg > > After five time ctrl-r: > 3253 root 15 0 1480m 864m 8148 R 8 42.9 787:30.59 > Xorg > > RES groves ~19MB. This png file have 1000x1000 pixels and X display > depth is 24bpp. 1000x1000x3 = ~3MB .. so looks like buffer for keep this > previous version of this files was not released. > > Can you check this on your system using above scenario ? > Try to open gif/png file which will take big amount of memory in > uncompressed form (1MB or more). And when you close the web browser what happens? Chances are that the web browser is leaking pixmaps. That's something not uncommon. From otaylor at redhat.com Tue Mar 6 15:20:10 2007 From: otaylor at redhat.com (Owen Taylor) Date: Tue, 06 Mar 2007 10:20:10 -0500 Subject: What applications do people use? In-Reply-To: <1173164217.3035.0.camel@sb-home.lan> References: <1173139585.2565.89.camel@localhost.localdomain> <1173164217.3035.0.camel@sb-home.lan> Message-ID: <1173194411.2565.105.camel@localhost.localdomain> On Tue, 2007-03-06 at 07:56 +0100, nodata wrote: > Am Montag, den 05.03.2007, 19:06 -0500 schrieb Owen Taylor: > > If you're interested, sign up for Mugshot and add your own statistics. > > I don't want to signup for yet another thing (!) > > Please can you make it less work for us and add the feature to that > hardware profile sender thing? Certainly if the goal was just collecting application statistics, doing it with the Mugshot client is probably overkill. But the global application-statistics tracking is really just a side-effect of larger things we are trying to do with Mugshot / client interaction; just in the area of application browsing and launching we are thinking about features like: - Automatically have launchers for a user's most frequently launched applications; even when they first create an account on a computer. - Synchronize application launching preferences among multiple computers. - Show you what applications are used among your friends (maybe... not sure if this is interesting yet or not) - Have the ability to comment on applications or recommend alternate applications. Many of these only make sense in the context of an account. We've tried to keep Mugshot signup as lightweight as possible ... for example, the default sign-in is *only* by emailed link; we don't ask you to set a password as part of the initial setup, though you have the option of doing that later if you want. There is also some possibility of some sort of single sign-on between Mugshot and the Fedora services like the wiki or the account system, possibly using OpenID. - Owen From ajackson at redhat.com Tue Mar 6 15:31:45 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 06 Mar 2007 10:31:45 -0500 Subject: X server memory leak ? (Re: Announcing Fedora 7 Test 2 (6.91)) In-Reply-To: <45ED70A2.7000006@mharris.ca> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> <1172771344.22136.118.camel@localhost.localdomain> <1172773609.25356.9.camel@kloczek01.pracownicy.zie> <1172775669.32357.27.camel@localhost.localdomain> <1172777571.32335.11.camel@kloczek01.pracownicy.zie> <1172777460.22136.134.camel@localhost.localdomain> <1172779164.32335.20.camel@kloczek01.pracownicy.zie> <1173056320.18771.24.camel@localhost.localdomain> <1173086019.21501.28.camel@kloczek01.pracownicy.zie> <45ED70A2.7000006@mharris.ca> Message-ID: <1173195105.9948.25.camel@localhost.localdomain> On Tue, 2007-03-06 at 08:46 -0500, Mike A. Harris wrote: > Tomasz K?oczko wrote: > > Before refresh: > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 3253 root 16 0 1480m 845m 8148 S 12 42.0 787:18.00 Xorg > > > > After five time ctrl-r: > > 3253 root 15 0 1480m 864m 8148 R 8 42.9 787:30.59 > > Xorg > > > > RES groves ~19MB. This png file have 1000x1000 pixels and X display > > depth is 24bpp. 1000x1000x3 = ~3MB .. so looks like buffer for keep this > > previous version of this files was not released. > > > > Can you check this on your system using above scenario ? > > Try to open gif/png file which will take big amount of memory in > > uncompressed form (1MB or more). > > And when you close the web browser what happens? Chances are that the > web browser is leaking pixmaps. That's something not uncommon. What he said. Check firefox's resource usage in xrestop as you do this. It's probably growing at about the same rate. X is a server process, it can only do what its clients ask of it. If the client says "hey, here's a 30M pixmap, hold onto it for me", well, that's what it'll do. - ajax From selinux at gmail.com Tue Mar 6 15:56:17 2007 From: selinux at gmail.com (Tom London) Date: Tue, 6 Mar 2007 07:56:17 -0800 Subject: rawhide report: 20070306 changes In-Reply-To: <200703061138.l26Bcrj2012027@hs20-bc2-6.build.redhat.com> References: <200703061138.l26Bcrj2012027@hs20-bc2-6.build.redhat.com> Message-ID: <4c4ba1530703060756v7855b8dap981346e5b29b6d2@mail.gmail.com> On 3/6/07, buildsys at redhat.com wrote: > > xorg-x11-drv-i810-1.6.5-13.fc7 > ------------------------------ > * Mon Mar 05 2007 Adam Jackson 1.6.5-13 > - Updated modesetting driver to one that will actually work with a 1.3 server. > > xorg-x11-server-1.2.99.901-1.fc7 > -------------------------------- > * Mon Mar 05 2007 Adam Jackson 1.2.99.901-1 > - xserver 1.3 RC1. RANDR 1.2 hotness in the hizzouse. > - xserver-1.2.0-honor-displaysize.patch: Honor the DisplaySize config > directive again (#220248) > - Clean up the post-install cleanup > > * Fri Mar 02 2007 Adam Tkac 1.2.0-10 > - change permissions of files in source package to default from read-only > > * Mon Feb 26 2007 Adam Tkac 1.2.0-9 > - Created new package (xorg-x11-server-source) which is needed to build VNC > server. > gnome-terminal dies immediately with these two updates: (gnome-terminal:4635): Vte-WARNING **: Can not find appropiate font for character U+ac08. (gnome-terminal:4635): Vte-WARNING **: Can not find appropiate font for character U+ac10. The program 'gnome-terminal' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 1135 error_code 8 request_code 72 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Reinstalling older versions makes it work again. drv/server issue? Where to BZ? tom -- Tom London From ajackson at redhat.com Tue Mar 6 15:45:37 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 06 Mar 2007 10:45:37 -0500 Subject: rawhide report: 20070306 changes In-Reply-To: <4c4ba1530703060756v7855b8dap981346e5b29b6d2@mail.gmail.com> References: <200703061138.l26Bcrj2012027@hs20-bc2-6.build.redhat.com> <4c4ba1530703060756v7855b8dap981346e5b29b6d2@mail.gmail.com> Message-ID: <1173195937.9948.31.camel@localhost.localdomain> On Tue, 2007-03-06 at 07:56 -0800, Tom London wrote: > On 3/6/07, buildsys at redhat.com wrote: > > > > xorg-x11-drv-i810-1.6.5-13.fc7 > > ------------------------------ > > * Mon Mar 05 2007 Adam Jackson 1.6.5-13 > > - Updated modesetting driver to one that will actually work with a 1.3 server. > > > > xorg-x11-server-1.2.99.901-1.fc7 > > -------------------------------- > > * Mon Mar 05 2007 Adam Jackson 1.2.99.901-1 > > - xserver 1.3 RC1. RANDR 1.2 hotness in the hizzouse. > > - xserver-1.2.0-honor-displaysize.patch: Honor the DisplaySize config > > directive again (#220248) > > - Clean up the post-install cleanup > > > > * Fri Mar 02 2007 Adam Tkac 1.2.0-10 > > - change permissions of files in source package to default from read-only > > > > * Mon Feb 26 2007 Adam Tkac 1.2.0-9 > > - Created new package (xorg-x11-server-source) which is needed to build VNC > > server. > > > gnome-terminal dies immediately with these two updates: > > (gnome-terminal:4635): Vte-WARNING **: Can not find appropiate font > for character U+ac08. > > > (gnome-terminal:4635): Vte-WARNING **: Can not find appropiate font > for character U+ac10. > > The program 'gnome-terminal' received an X Window System error. > This probably reflects a bug in the program. > The error was 'BadMatch (invalid parameter attributes)'. > (Details: serial 1135 error_code 8 request_code 72 minor_code 0) > (Note to programmers: normally, X errors are reported asynchronously; > that is, you will receive the error a while after causing it. > To debug your program, run it with the --sync command line > option to change this behavior. You can then get a meaningful > backtrace from your debugger if you break on the gdk_x_error() function.) > > Reinstalling older versions makes it work again. drv/server issue? Where to BZ? Server issue at first glance. Fedora bz is fine until we're sure whose fault it is. Does it give you the same BadMatch error if you start g-t with --sync ? - ajax From alexl at redhat.com Tue Mar 6 16:40:26 2007 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 06 Mar 2007 17:40:26 +0100 Subject: VNC development plan - discuss In-Reply-To: <45ED5D45.2000903@redhat.com> References: <45ED356D.7060204@redhat.com> <1173182009.3288.67.camel@blaa> <45ED5D45.2000903@redhat.com> Message-ID: <1173199226.19903.37.camel@greebo> On Tue, 2007-03-06 at 13:23 +0100, Adam Tkac wrote: > Mark McLoughlin napsal(a): > > vino and krfb have different goals and UIs that are designed to be well > > integrated into their respective environments. I don't think merging the > > two makes any more sense than e.g. merging evolution and kmail because > > they both talk the SMTP protocol. > > > I don't think that integrating to specified environment is useful in > this case. In my opinion kde & gnome use same xserver with same policies > so vino and krfb (and x11vnc) is more about xserver than about specific > UIs. This is main argument why could be these programs merged to one. It > is very easy write simple GUI with two buttons - "start remote desktop" > and "stop remote desktop" - which could works under gnome and kde and > other window managers. How is it not important that they are properly integrated into the desktop? Your proposal sounds very simple and ugly compared to the slick integration of e.g. vino. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a world-famous moralistic stage actor haunted by an iconic dead American confidante She's a ditzy psychic detective from Mars. They fight crime! From atkac at redhat.com Tue Mar 6 16:58:45 2007 From: atkac at redhat.com (Adam Tkac) Date: Tue, 06 Mar 2007 17:58:45 +0100 Subject: VNC development plan - discuss In-Reply-To: <1173199226.19903.37.camel@greebo> References: <45ED356D.7060204@redhat.com> <1173182009.3288.67.camel@blaa> <45ED5D45.2000903@redhat.com> <1173199226.19903.37.camel@greebo> Message-ID: <45ED9DC5.7000001@redhat.com> Alexander Larsson napsal(a): > On Tue, 2007-03-06 at 13:23 +0100, Adam Tkac wrote: > >> Mark McLoughlin napsal(a): >> >>> vino and krfb have different goals and UIs that are designed to be well >>> integrated into their respective environments. I don't think merging the >>> two makes any more sense than e.g. merging evolution and kmail because >>> they both talk the SMTP protocol. >>> >>> >> I don't think that integrating to specified environment is useful in >> this case. In my opinion kde & gnome use same xserver with same policies >> so vino and krfb (and x11vnc) is more about xserver than about specific >> UIs. This is main argument why could be these programs merged to one. It >> is very easy write simple GUI with two buttons - "start remote desktop" >> and "stop remote desktop" - which could works under gnome and kde and >> other window managers. >> > > How is it not important that they are properly integrated into the > desktop? Your proposal sounds very simple and ugly compared to the slick > integration of e.g. vino. > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alla at lysator.liu.se > He's a world-famous moralistic stage actor haunted by an iconic dead American > confidante She's a ditzy psychic detective from Mars. They fight crime! > > I don't said that integration is unimportant. I said that both of krfb and vino is much more about xserver than about window manager. Only one think could be integrated with specified window manager - button "start remote desktop" and "stop remote desktop". All other is really wm independent. Regards, Adam From markmc at redhat.com Tue Mar 6 17:10:44 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 06 Mar 2007 17:10:44 +0000 Subject: VNC development plan - discuss In-Reply-To: <45ED9DC5.7000001@redhat.com> References: <45ED356D.7060204@redhat.com> <1173182009.3288.67.camel@blaa> <45ED5D45.2000903@redhat.com> <1173199226.19903.37.camel@greebo> <45ED9DC5.7000001@redhat.com> Message-ID: <1173201044.3288.211.camel@blaa> On Tue, 2007-03-06 at 17:58 +0100, Adam Tkac wrote: > I don't said that integration is unimportant. I said that both of krfb > and vino is much more about xserver than about window manager. Only one > think could be integrated with specified window manager - button "start > remote desktop" and "stop remote desktop". All other is really wm > independent. You should try doing some research. Integration points: - Preferences dialog in menus, follows GNOME UI guidelines - Preferences storage (i.e. in GConf) - Server launching at login based on "enabled" preference (code in gnome-session) - Confirmation dialog follows GNOME UI guidelines - A status icon showing when users are logged in, again following GNOME UI guidelines Cheers, Mark. From jspaleta at gmail.com Tue Mar 6 18:42:14 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 6 Mar 2007 09:42:14 -0900 Subject: VNC development plan - discuss In-Reply-To: <1173201044.3288.211.camel@blaa> References: <45ED356D.7060204@redhat.com> <1173182009.3288.67.camel@blaa> <45ED5D45.2000903@redhat.com> <1173199226.19903.37.camel@greebo> <45ED9DC5.7000001@redhat.com> <1173201044.3288.211.camel@blaa> Message-ID: <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> On 3/6/07, Mark McLoughlin wrote: > You should try doing some research. Speaking of vino, when you have vino active and you are logged in remotely, the local console display is also active, at least through fc6. Is this a designed feature, or is this a current codebase limitation? I have situations where I would very much like to login on a local display set some things up, lock the screen, and then log back in remotely to it over vnc without the local display becoming active and accepting keyboard/mouse inputs. Right now on fc6, vino doesn't provide this sort of experience as an option, and I'm falling back to using a standard Xvnc controlled desktop, dealing with the hardware specific permissions issues which result as needed. Using vino, I've experieced real problems with people who when walking by my office or using the phone in my office have seen the display active, thought it was some sort of virus and started interacting with the local input in an effort to 'help me.' Resulting in real data-loss. They do it primarily because they are use to the behavior of rdp sessions which active the local screensaver when the remote session is connected. I realize there are other usage cases for a vino based remote service. I'm sure some cases you want active remote collaborators who you can interact, but in my own experience I need to remote in while keeping the local display locked far more than I need to have a remote/local tug of war over the mouse and keyboard. -jef From kwade at redhat.com Tue Mar 6 18:43:44 2007 From: kwade at redhat.com (Karsten Wade) Date: Tue, 06 Mar 2007 10:43:44 -0800 Subject: What applications do people use? In-Reply-To: <1173194411.2565.105.camel@localhost.localdomain> References: <1173139585.2565.89.camel@localhost.localdomain> <1173164217.3035.0.camel@sb-home.lan> <1173194411.2565.105.camel@localhost.localdomain> Message-ID: <1173206625.2865.318.camel@erato.phig.org> On Tue, 2007-03-06 at 10:20 -0500, Owen Taylor wrote: > There is also some possibility of some sort of single sign-on between > Mugshot and the Fedora services like the wiki or the account system, > possibly using OpenID. +1 OpenID seems to be the convergence point. We have other online stuff that need to integrate with Fedora, Mugshot, etc., and OpenID gives us a path to make a great user experience. - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at camperquake.de Tue Mar 6 18:56:22 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 6 Mar 2007 19:56:22 +0100 Subject: VNC development plan - discuss In-Reply-To: <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> References: <45ED356D.7060204@redhat.com> <1173182009.3288.67.camel@blaa> <45ED5D45.2000903@redhat.com> <1173199226.19903.37.camel@greebo> <45ED9DC5.7000001@redhat.com> <1173201044.3288.211.camel@blaa> <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> Message-ID: <20070306195622.4828b1f9@lain.camperquake.de> Hi. On Tue, 6 Mar 2007 09:42:14 -0900, Jeff Spaleta wrote > I have situations where I would very much like to login on a local > display set some things up, lock the screen, and then log back in > remotely to it over vnc without the local display becoming active and > accepting keyboard/mouse inputs. Right now on fc6, vino doesn't > provide this sort of experience as an option, and I'm falling back to > using a standard Xvnc controlled desktop, dealing with the hardware > specific permissions issues which result as needed. Sounds like you want terminal services, which is different from what VNC was designed to provide. From fche at redhat.com Tue Mar 6 19:25:54 2007 From: fche at redhat.com (Frank Ch. Eigler) Date: 06 Mar 2007 14:25:54 -0500 Subject: X server memory leak ? (Re: Announcing Fedora 7 Test 2 (6.91)) In-Reply-To: <1173195105.9948.25.camel@localhost.localdomain> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> <1172771344.22136.118.camel@localhost.localdomain> <1172773609.25356.9.camel@kloczek01.pracownicy.zie> <1172775669.32357.27.camel@localhost.localdomain> <1172777571.32335.11.camel@kloczek01.pracownicy.zie> <1172777460.22136.134.camel@localhost.localdomain> <1172779164.32335.20.camel@kloczek01.pracownicy.zie> <1173056320.18771.24.camel@localhost.localdomain> <1173086019.21501.28.camel@kloczek01.pracownicy.zie> <45ED70A2.7000006@mharris.ca> <1173195105.9948.25.camel@localhost.localdomain> Message-ID: Adam Jackson writes: > [...] > What he said. Check firefox's resource usage in xrestop as you do this. > It's probably growing at about the same rate. > [...] Indeed, mozilla/firefox is infamous for this. See for example this: , opened in 2004. - FChE From jspaleta at gmail.com Tue Mar 6 19:41:22 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 6 Mar 2007 10:41:22 -0900 Subject: VNC development plan - discuss In-Reply-To: <20070306195622.4828b1f9@lain.camperquake.de> References: <45ED356D.7060204@redhat.com> <1173182009.3288.67.camel@blaa> <45ED5D45.2000903@redhat.com> <1173199226.19903.37.camel@greebo> <45ED9DC5.7000001@redhat.com> <1173201044.3288.211.camel@blaa> <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> <20070306195622.4828b1f9@lain.camperquake.de> Message-ID: <604aa7910703061141m2d55b7a0p3a022b1b143d3fe6@mail.gmail.com> On 3/6/07, Ralf Ertzinger wrote: > Sounds like you want terminal services, which is different from what > VNC was designed to provide. I don't think any in the history of software development, has ever been 'designed' to provide the functionality I find I need. :-> -jef From opensource at till.name Tue Mar 6 19:47:06 2007 From: opensource at till.name (Till Maas) Date: Tue, 06 Mar 2007 20:47:06 +0100 Subject: VNC development plan - discuss In-Reply-To: <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> References: <45ED356D.7060204@redhat.com> <1173201044.3288.211.camel@blaa> <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> Message-ID: <200703062047.14563.opensource@till.name> On Dienstag 06 M?rz 2007, Jeff Spaleta wrote: > I have situations where I would very much like to login on a local > display set some things up, lock the screen, and then log back in > remotely to it over vnc without the local display becoming active and > accepting keyboard/mouse inputs. Right now on fc6, vino doesn't Maybe you can use nomachine (nx) for this. But I do not know which components of this are freely available right now. 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 darrellpf at gmail.com Tue Mar 6 20:41:20 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Tue, 6 Mar 2007 12:41:20 -0800 Subject: rawhide report: 20070306 changes In-Reply-To: <4c4ba1530703060756v7855b8dap981346e5b29b6d2@mail.gmail.com> References: <200703061138.l26Bcrj2012027@hs20-bc2-6.build.redhat.com> <4c4ba1530703060756v7855b8dap981346e5b29b6d2@mail.gmail.com> Message-ID: On 3/6/07, Tom London wrote: > On 3/6/07, buildsys at redhat.com wrote: > > > > xorg-x11-drv-i810-1.6.5-13.fc7 > > ------------------------------ > > * Mon Mar 05 2007 Adam Jackson 1.6.5-13 > > - Updated modesetting driver to one that will actually work with a 1.3 server. > > > > xorg-x11-server-1.2.99.901-1.fc7 > > -------------------------------- > > * Mon Mar 05 2007 Adam Jackson 1.2.99.901-1 > > - xserver 1.3 RC1. RANDR 1.2 hotness in the hizzouse. > > - xserver-1.2.0-honor-displaysize.patch: Honor the DisplaySize config > > directive again (#220248) > > - Clean up the post-install cleanup > > > > * Fri Mar 02 2007 Adam Tkac 1.2.0-10 > > - change permissions of files in source package to default from read-only > > > > * Mon Feb 26 2007 Adam Tkac 1.2.0-9 > > - Created new package (xorg-x11-server-source) which is needed to build VNC > > server. > > > gnome-terminal dies immediately with these two updates: > > (gnome-terminal:4635): Vte-WARNING **: Can not find appropiate font > for character U+ac08. > > > (gnome-terminal:4635): Vte-WARNING **: Can not find appropiate font > for character U+ac10. > > The program 'gnome-terminal' received an X Window System error. > This probably reflects a bug in the program. > The error was 'BadMatch (invalid parameter attributes)'. > (Details: serial 1135 error_code 8 request_code 72 minor_code 0) > (Note to programmers: normally, X errors are reported asynchronously; > that is, you will receive the error a while after causing it. > To debug your program, run it with the --sync command line > option to change this behavior. You can then get a meaningful > backtrace from your debugger if you break on the gdk_x_error() function.) > > Reinstalling older versions makes it work again. drv/server issue? Where to BZ? > > tom > -- > Tom London > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I've had the font character warnings for several days. In my case gnome terminal continues to work with today's update, so the x server problem might not be directly related. darrell From mike.cohler at gmail.com Tue Mar 6 20:46:24 2007 From: mike.cohler at gmail.com (Mike Cohler) Date: Tue, 6 Mar 2007 20:46:24 +0000 (UTC) Subject: VNC development plan - discuss References: <45ED356D.7060204@redhat.com> Message-ID: Adam Tkac redhat.com> writes: > features than actual "real desktop" servers. So two programs could be > removed and one added => cost of maintaining and bugfixing could be > lower. In next stage we could discuss about standardized RFB protocol > library which could be used by all vnc servers in distro. In the end we > could have one rfb library which will be used by all servers (and > viewers), one real server, one virtual server and X module. What do you > think about this idea? > > Regards, Adam Hi Adam I was unclear about what is envisaged here but whatever solution is ultimately adopted I hope that there will still be the option to access a remote machine running a vnc server as a module which will allow access to the remote desktop via an ssh tunnel before any user logs in - for some remote maintenance and help this facility is really important. You have done an excellent job maintaining vnc till now. Mike From berrange at redhat.com Tue Mar 6 21:20:23 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 6 Mar 2007 21:20:23 +0000 Subject: VNC development plan - discuss In-Reply-To: References: <45ED356D.7060204@redhat.com> Message-ID: <20070306212022.GN29872@redhat.com> On Tue, Mar 06, 2007 at 08:46:24PM +0000, Mike Cohler wrote: > Adam Tkac redhat.com> writes: > > > features than actual "real desktop" servers. So two programs could be > > removed and one added => cost of maintaining and bugfixing could be > > lower. In next stage we could discuss about standardized RFB protocol > > library which could be used by all vnc servers in distro. In the end we > > could have one rfb library which will be used by all servers (and > > viewers), one real server, one virtual server and X module. What do you > > think about this idea? Since we're on the subject of VNC servers, its a good time to bring up the question of virtualization. With Xen in the mix there are actually 2 further VNC server implementations in Fedora... - Xen para-virtualized guest console server - QEMU / KVM / Xen fully-virtualized guest console server The former is currently based on libvncserver which turned out to be an really bad mistake. The code is horribly complicated / obtuse and has completely unsafe use of pthreads synchronization primitives. The QEMU VNC server is a from sratch impl of the RFB protocol which is directly part of the QEMU codebase. It is my intention that the current Xen paravirt VNC server will be re-written to use more-or-less the same code as the current QEMU impl, which will bring it down from ~20,000 lines of C, to ~2,000. Now this isn't directly relevant, since the code isn't really suitable for turning into a standalone VNC server. I just wanted to point out that you should be wary of picking libvncserver as the basis of a shared RFB impl in its current form, since the codebase isn't all that nice to work with. The whole discussion of merging VNC servers though misses out the most critical shortcoming in VNC - it has a non-existant security model. All traffic is clear-text on the wire, and the authentication is trivially brute-forced. Tunnelling it over SSH is really just a band-aid, because even with it restricted to listen on 127.0.0.1 any local user can still trivially compromise any other user's session For the virtualization arena, tunnelling over SSH is out of the quesiton because integrity of the host system is too important. You don't want to have to give out login accounts to the host just so that a user can access the guest virtual console. So for Xen / QEMU I am currently working on implementing native SSL support in their respective VNC server impls, based on the protocol defined by VeNCrypt. I expect this work to arrive some time in the Fedora 8 dev cycle, which is when we hope to have full-remote management capabilities for Xen / QEMU / KVM. The caveat is that AFAIK, Fedora doesn't have any VNC viewer program that supports encryption aside from SSH tunnelling - not a huge problem since virt-manager has an embedded GTK VNC widget which can do the job, but it would be nice to have a standalone viewer for virtual machine consoles. So if we're thinking of long term Fedora VNC development plans, we should make sure encryption / authentication is on the list for both client & server. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From dimitris at glezos.com Tue Mar 6 22:02:24 2007 From: dimitris at glezos.com (Dimitris Glezos) Date: Tue, 06 Mar 2007 22:02:24 +0000 Subject: Translations: String freezes, CVS converging, Packaging Message-ID: <45EDE4F0.4050500@glezos.com> Hi all. The L10n project has been discussing for a while now (also at FOSDEM with mspevack) about ways to improve our translation processes. We estimate that more than 1 out of 3 users uses a non-English desktop. First of all, let's clarify here that for the time being, we are referring only to applications that Fedora is upstream (anaconda, system-config-*, and basically most of the non-deprecated stuff that appears on [1]). [1]:http://i18n.redhat.com/cgi-bin/i18n-status?page=status&locale=es&branch=HEAD&essential=0 The plan in mind includes three actions. ## String freezes For F7, the RelEng team has introduced string freezes in the schedule [2]. This means that application strings for F7 should be complete *by 19/3*. Translations made after this date (and before the freeze) should be guaranteed to be included in the release. [2]: http://fedoraproject.org/wiki/Core/Schedule To do this we need to try not to add new strings after the freeze and let the L10n folks know if they need to do so. Also, maintainers should repackage before each release (and after the translation freeze) without a bug needing to be opened. ## CVS convergence Right now translations are done on `i18n.redhat.com`. This requires contributors to have one account on the Fedora Account System (FAS) and a different one for translations. With the merge of Core and Extras, now is a good point to get rid of this distinction. The plan is to move all PO files on Fedora infrastructure under a new CVS group (cvsl10n) [3]. An email will be sent to all translators to create a FAS account if they don't have one and join the cvs group. Members of the L10n team and ambassadors will help with this process. [3]: http://fedoraproject.org/wiki/L10N/Projects/CVSInfrastructure At this point we could discuss the idea for Fedora to act as upstream for the translations of outside-hosted projects such as yum, smolt, and pungi. The proposal is to host and maintain those project's translations with the existing Fedora L10n community. ## Packaging translations One final plan (and probably the one that needs most discussion) is about changing the way we package translations. Right now PO files live inside the application and are packaged there (GNOME-style). The plan is to move the PO files in to their own directory and distinct package [4] (KDE-style langpacks). [4]: http://fedoraproject.org/wiki/L10N/Projects/TranslationsPackage Cons: L10n team should maintain a package (or many) and packages should be altered to accomodate the different locations of PO files. Pros (many): increased modularity and maintenance (L10n repackages at will). App packages will be smaller in size -- we could provide one langpack or different ones per language. Comments, suggestions? -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From jspaleta at gmail.com Tue Mar 6 22:07:14 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 6 Mar 2007 13:07:14 -0900 Subject: VNC development plan - discuss In-Reply-To: <200703062047.14563.opensource@till.name> References: <45ED356D.7060204@redhat.com> <1173201044.3288.211.camel@blaa> <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> <200703062047.14563.opensource@till.name> Message-ID: <604aa7910703061407w5a9426f0y717894f47c9caf50@mail.gmail.com> On 3/6/07, Till Maas wrote: > Maybe you can use nomachine (nx) for this. But I do not know which components > of this are freely available right now. In the context of a discussion in this list... I can't... because its a technology that does not exist yet in the Fedora project's repository space afaik. And even if it did, the question remains... is what I am currently seeing in vino a design decision or just a limitation of the current codebase which could be resolved at the expense of paying for the Cortisone shot to alleviate the symptoms of tendinitis caused coding up the bits for vino. Let's be clear, I don't care what the underlying protocal is. I'm interested in making sure whatever the default well-integrated desktop solution which bills itself as THE remote desktop solution is operating intuitively and provides looked-for functionality that less technical users expect to see in a remote desktop technology. This is primarily my attempt at politely asking the people who want to champion vino as deeply UI integrated default solution for remote desktop... to review the intuitiveness of an aspect of its functionality. I have a specifc usage case, I want to use the deeply UI integrated solution that I have identified from the available default information that seems to fit best, but it doesn't work like the average non-geek users in my workplace expect it to work. This is not a fantasy thought-experiment. This is a real problem that I have encountered with co-workers, grounded in the expectations borne from previously nearly exclusive use of remote desktop communications on Windows XP systems. Is there another comparably integrated UI solution for the default Gnome desktop inside Fedora right now that does what I have described in terms of keeping the local display screen locked that I am not aware of? Or is this a usage case that vino can work towards? Or is this usage case outside the bounds of the remote desktop concepts that vino is suppose to be targetting? Because if I'm told it's out of bounds for the functionality that vino is suppose to be providing, I'm going to be forced to have a public discussion contrasting how vino operates when compared to a certain non-vnc based protocal that is native on a different operating system. I do not want to have that discussion. -jef"...I'd threaten to leave Fedora if this isn't fixed like I want it,, but my wife is making me a hand knitted fedora-logo'd hat...and she'd pretty much kill me for wasting her time by refusing to wear it."spaleta From mmcgrath at redhat.com Tue Mar 6 22:15:36 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 16:15:36 -0600 Subject: Extras pushes Message-ID: <45EDE808.80508@redhat.com> Extras pushes are on hold for the moment while we re-order the push process. It should be transparent to both the users and the pushers when its back online. We're expecting it to be back up and running later tonight or early tomorrow. -Mike From pmr at pajato.com Tue Mar 6 22:46:34 2007 From: pmr at pajato.com (Paul Michael Reilly) Date: Tue, 06 Mar 2007 17:46:34 -0500 Subject: VNC development plan - discuss In-Reply-To: <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> References: <45ED356D.7060204@redhat.com> <1173182009.3288.67.camel@blaa> <45ED5D45.2000903@redhat.com> <1173199226.19903.37.camel@greebo> <45ED9DC5.7000001@redhat.com> <1173201044.3288.211.camel@blaa> <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> Message-ID: <45EDEF4A.4090409@pajato.com> Jeff Spaleta wrote: ... > I have situations where I would very much like to login on a local > display set some things up, lock the screen, and then log back in > remotely to it over vnc without the local display becoming active and > accepting keyboard/mouse inputs. Right now on fc6, vino doesn't > provide this sort of experience as an option, and I'm falling back to > using a standard Xvnc controlled desktop, dealing with the hardware > specific permissions issues which result as needed. I do this as a matter of course every day. I set up a VNC session on the server such that it securely tunnels to a few machines that I will likely connect from, including the local machine. Then I use terminal server client to connect to the VNC session from the various client systems. It is really sweet. With FUSA it even gets better. I set up VNC sessions to multiple machines using different accounts and switch between them very quickly with FUSA. As the only user on client systems, I turn off session locking entirely so switching between (remote) sessions is a sub-second operation. Perfect. -pmr From michel.salim at gmail.com Tue Mar 6 22:47:16 2007 From: michel.salim at gmail.com (Michel Salim) Date: Tue, 6 Mar 2007 17:47:16 -0500 Subject: Regression in importing Word document In-Reply-To: <45EBF8F6.6060801@nobugconsulting.ro> References: <883cfe6d0703031636u4adff1e7o8b74bc943c596d50@mail.gmail.com> <883cfe6d0703041628u6a01a60agc824038e0f861c01@mail.gmail.com> <45EBF8F6.6060801@nobugconsulting.ro> Message-ID: <883cfe6d0703061447i5a0a2228v793250b4fe7b2e1a@mail.gmail.com> 2007/3/5, Manuel Wolfshant : > Michel Salim wrote: > > 2007/3/4, Hikaru Amano : > >> On 3/3/07, Michel Salim wrote: > >> > This following Word document: > >> http://hircus.org/fedora/word-bug/CDF-Flyer.doc > >> > reliably crashes Abiword and OpenOffice in Rawhide on my x86_64 > >> > machine. Could someone take a look and see if it crashes on > >> > Rawhide/i386 and FC6/any ? > >> > >> Opens fine on rawhide > >> > > So it's probably x86_64 specific (I've modified the bug to be > > x86_64-only). OO.o didn't have a x86_64 release until version 2.1, I > > think, so there's probably some bugs still. > > > > Thanks, > > > Works fine for me in FC6/openoffice.org-core-2.0.4-5.5.10.x86_64 > The bug disappeared with 2.2.0-9.2.x86_64, actually, but thanks! -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From ajackson at redhat.com Tue Mar 6 22:36:11 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 06 Mar 2007 17:36:11 -0500 Subject: RANDR 1.2 heads up In-Reply-To: <1173142302.4742.20.camel@pluto.jrcormier.com> References: <1173136781.9948.22.camel@localhost.localdomain> <1173142302.4742.20.camel@pluto.jrcormier.com> Message-ID: <1173220571.9948.37.camel@localhost.localdomain> On Mon, 2007-03-05 at 20:51 -0400, Jean-Rene Cormier wrote: > On Mon, 2007-03-05 at 18:19 -0500, Adam Jackson wrote: > > - Gnome randr applet crashes. Like, instantly. > > - Old school xrandr options sometimes do nonintuitive things, > > particularly for rotation. > > - DPI is only loosely related to reality. > > - panel sometimes gets very confused about positioning. > > - i865 and below probably don't work. > > What exactly won't work with i865 and below? I have manually rebuilt > Xorg and quite a few other packages on my FC6 installation to get RANDR > 1.2 and it works for some things on my i855. I can turn monitors on and > off, change the resolution (sometimes). Though sometimes the laptop > froze after bootup or while the screensaver was on. LVDS panels in particular, which usually means laptops. The rumor is something like they'll occasionally program the right timing values just by luck. - ajax From mike at miketc.com Tue Mar 6 22:51:53 2007 From: mike at miketc.com (Mike Chambers) Date: Tue, 06 Mar 2007 16:51:53 -0600 Subject: Core + Extras directory structure Message-ID: <1173221513.2301.8.camel@scrappy.miketc.com> I don't know if this has been discussed or not, and I may have missed it. But will the current dir tree for core & extras change once merged? As in for example.. Core - /pub/fedora/linux/core/ Extras - /pub/fedora/linux/extras Merged - /pub/fedora/linux/new-dir-structure-here-that-maybe-only-contains-fc-release-versions with extras packages/rpms located within the core/rpm area? In other words, both sets of packages built as if its one release (whatever is spun off that release is a different question) and all of them located together in one dir or one dir under a release (fc7/fc8)? Or will they keep the current layout but be maintained on same build system/server? Am I asking this correct? haha -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless your not getting any!" From mattdm at mattdm.org Tue Mar 6 23:09:11 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Mar 2007 18:09:11 -0500 Subject: Core + Extras directory structure In-Reply-To: <1173221513.2301.8.camel@scrappy.miketc.com> References: <1173221513.2301.8.camel@scrappy.miketc.com> Message-ID: <20070306230911.GA9647@jadzia.bu.edu> On Tue, Mar 06, 2007 at 04:51:53PM -0600, Mike Chambers wrote: > I don't know if this has been discussed or not, and I may have missed > it. But will the current dir tree for core & extras change once merged? Yes. They will be, in fact, merged. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From kevin.verma at gmail.com Tue Mar 6 23:41:51 2007 From: kevin.verma at gmail.com (Anuj Verma (Kevin)) Date: Tue, 6 Mar 2007 23:41:51 +0000 (UTC) Subject: Jabber, JIngle, VoIP, telepathy - howto ? Message-ID: Hello, I am sorry to post this to devel list, but I guess this should better get some initial insight & help from developers for now. I will like to know how to get VoIP working on Fedora using Jabber clients supported by libjingle & telepathy ? Please provide some pointers to help me get started. Kevin From wtogami at redhat.com Tue Mar 6 23:47:34 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 06 Mar 2007 18:47:34 -0500 Subject: OFF-TOPIC Re: Jabber, JIngle, VoIP, telepathy - howto ? In-Reply-To: References: Message-ID: <45EDFD96.8070708@redhat.com> Anuj Verma (Kevin) wrote: > Hello, > > I am sorry to post this to devel list, but I guess this should better get > some initial insight & help from developers for now. > > I will like to know how to get VoIP working on Fedora using Jabber > clients supported by libjingle & telepathy ? > > Please provide some pointers to help me get started. > > Kevin > Please do not take this personally. The only way we will be able to improve the signal to noise ratio on this list is by enforcing the the rules. This is very clearly not development discussion. Warren Togami wtogami at redhat.com From michael.wiktowy at gmail.com Tue Mar 6 23:49:23 2007 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Tue, 6 Mar 2007 18:49:23 -0500 Subject: Jabber, JIngle, VoIP, telepathy - howto ? In-Reply-To: References: Message-ID: <3e4ec4600703061549q298e2b9o60666a8e3332f775@mail.gmail.com> On 3/6/07, Anuj Verma (Kevin) wrote: > Hello, > > I am sorry to post this to devel list, but I guess this should better get > some initial insight & help from developers for now. > > I will like to know how to get VoIP working on Fedora using Jabber > clients supported by libjingle & telepathy ? > > Please provide some pointers to help me get started. You can start here: http://tapioca-voip.sourceforge.net/wiki/index.php/Tapioca I did get Tapiocaui installed on my FC6 system at one point way back wehn but it wasn't working well so I removed it. I think client development on Tapiocaui has switched over to Landell: http://tapioca-voip.sourceforge.net/wiki/index.php/Landell and Tapioca remains the name for the lower level libraries. Not sure if anyone is bundling up a yummable rpm for any of this though. /Mike From jspaleta at gmail.com Wed Mar 7 00:29:43 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 6 Mar 2007 15:29:43 -0900 Subject: VNC development plan - discuss In-Reply-To: <45EDEF4A.4090409@pajato.com> References: <45ED356D.7060204@redhat.com> <1173182009.3288.67.camel@blaa> <45ED5D45.2000903@redhat.com> <1173199226.19903.37.camel@greebo> <45ED9DC5.7000001@redhat.com> <1173201044.3288.211.camel@blaa> <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> <45EDEF4A.4090409@pajato.com> Message-ID: <604aa7910703061629t65a7ad04l78cee04a7464c5e0@mail.gmail.com> On 3/6/07, Paul Michael Reilly wrote: > I set up VNC sessions to multiple machines using different accounts and switch > between them very quickly with FUSA. Speaking of FUSA, has anyone tested how FUSA and an active vino controlled remote desktop session interact? -jef"really really needs to get test2 installed...like yesterday"spaleta From axel.azerty at laposte.net Wed Mar 7 00:41:30 2007 From: axel.azerty at laposte.net (Axel) Date: Wed, 07 Mar 2007 01:41:30 +0100 Subject: Missing P-ATA CDROM support in Fedora 7 Test 2 ? Message-ID: <45EE0A3A.5060202@laposte.net> Hello I just tried to install Fedora 7 with "cdrom" as packages support, but no drives seems to be detected. I use a P-ATA drive on a Nforce4-4x powered motherboard (Asus K8N4-E Deluxe) and didn't found any suitable driver in the list (maybe I missed it ?). Anyway, I will try network install, I just post this message for information. Regards. From poelstra at redhat.com Wed Mar 7 00:54:31 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 06 Mar 2007 16:54:31 -0800 Subject: Frozen feature list for FC7 Message-ID: <45EE0D47.7000201@redhat.com> Hi, I was looking at the schedule and features listed here: http://fedoraproject.org/wiki/Releases/7 According to the schedule, features must be done by FC7T2 (which has been released) or they risk being dropped from the release. Is this still the case? Looking through many of the features listed on the wiki it is hard to tell if they are done or not. Should I be looking somewhere else? John p.s. unrelated... there is some weirdness with the wiki whereby clicking on a particular feature takes you to the fedoraproject front page. From wtogami at redhat.com Wed Mar 7 01:08:28 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 06 Mar 2007 20:08:28 -0500 Subject: Frozen feature list for FC7 In-Reply-To: <45EE0D47.7000201@redhat.com> References: <45EE0D47.7000201@redhat.com> Message-ID: <45EE108C.2000508@redhat.com> John Poelstra wrote: > Hi, > > I was looking at the schedule and features listed here: > http://fedoraproject.org/wiki/Releases/7 > > According to the schedule, features must be done by FC7T2 (which has > been released) or they risk being dropped from the release. Is this > still the case? Good catch. The feature freeze was moved to Test3 and a Test4 was since added. Strangely though, I can't seem to figure out how to edit the page to make a seemingly simple correction. It might just be the oxygen deprivation to my brain... > > Looking through many of the features listed on the wiki it is hard to > tell if they are done or not. Should I be looking somewhere else? > Features have not historically been tracked formally in Fedora. Features just would sort of land if they were completed before freeze dates. I suppose we could improve this in the future, but is the Wiki really the best way to represent this? Warren Togami wtogami at redhat.com From ericm24x7 at gmail.com Wed Mar 7 01:16:23 2007 From: ericm24x7 at gmail.com (eric) Date: Tue, 06 Mar 2007 20:16:23 -0500 Subject: VNC development plan - discuss In-Reply-To: <20070306212022.GN29872@redhat.com> References: <45ED356D.7060204@redhat.com> <20070306212022.GN29872@redhat.com> Message-ID: <45EE1267.8070201@gmail.com> Daniel P. Berrange wrote: > Since we're on the subject of VNC servers, its a good time to bring up the > question of virtualization. With Xen in the mix there are actually 2 further > VNC server implementations in Fedora... > > - Xen para-virtualized guest console server > - QEMU / KVM / Xen fully-virtualized guest console server > > ..... > > The caveat is that AFAIK, Fedora doesn't have any VNC viewer program that > supports encryption aside from SSH tunnelling - not a huge problem since > virt-manager has an embedded GTK VNC widget which can do the job, but it > would be nice to have a standalone viewer for virtual machine consoles. > > So if we're thinking of long term Fedora VNC development plans, we should > make sure encryption / authentication is on the list for both client & > server. > > Regards, > Dan. > Here is an actual command line I use regularly to properly bring up a remote VNC viewer securely through VNC: ssh -p 6603 -f -L 7763:localhost:6063 adm3 at 192.168.3.203 ' vncserver -kill :164 ; vncserver :164 -localhost -name v40 ; sleep 5 ' ; sleep 5 ; vncviewer localhost::7763 An average joe six pack user will probably never be able to grasp, let alone remember and type such a command, just to bring up a remote viewer. I'm sure simplification/integration of some sort would be welcome by many users. eric From jkeating at redhat.com Wed Mar 7 01:29:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 6 Mar 2007 20:29:41 -0500 Subject: Frozen feature list for FC7 In-Reply-To: <45EE108C.2000508@redhat.com> References: <45EE0D47.7000201@redhat.com> <45EE108C.2000508@redhat.com> Message-ID: <200703062029.44428.jkeating@redhat.com> On Tuesday 06 March 2007 20:08:28 Warren Togami wrote: > Features have not historically been tracked formally in Fedora. > Features just would sort of land if they were completed before freeze > dates. ?I suppose we could improve this in the future, but is the Wiki > really the best way to represent this? For lack of a better method, I think the wiki works fine. It's up to those driving the features to keep their feature page updated. We should prod those people on a regular bases (near test releases) to update their pages with status. -- 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 peter at thecodergeek.com Wed Mar 7 01:43:33 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 06 Mar 2007 17:43:33 -0800 Subject: Frozen feature list for FC7 In-Reply-To: <45EE108C.2000508@redhat.com> References: <45EE0D47.7000201@redhat.com> <45EE108C.2000508@redhat.com> Message-ID: <1173231813.3333.4.camel@tuxhugs> On Tue, 2007-03-06 at 20:08 -0500, Warren Togami wrote: > Features have not historically been tracked formally in Fedora. > Features just would sort of land if they were completed before freeze > dates. I suppose we could improve this in the future, but is the Wiki > really the best way to represent this? Hence the 'fedora_requires_release_note' Bugzilla flag? :) Is there a formal policy for that like there is for the fedora-cvs one? If not, then we could simply request that flag ('?') and add a note to the package's review request (or another resolved RFE bug) stating the cool new significant feature that has been added/changes. Then perhaps this can go to the fedora-docs list and someone can approve ('+') the flag when this is added or deny it ('-') with a brief explanation as to the reasoning for its denial. Also, the Docs/Beats on the wiki are writable to all Fedora Account holders, right? Could setting the flag in Bugzilla automagically add that note the wiki if the flag requester has a Fedora account/is in the EditGroup? Just some random thoughts here; my two cents... -- Peter Gordon (codergeek42) / FSF Associate Member #5015 GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 jreiser at BitWagon.com Wed Mar 7 03:15:35 2007 From: jreiser at BitWagon.com (John Reiser) Date: Tue, 06 Mar 2007 19:15:35 -0800 Subject: Missing P-ATA CDROM support in Fedora 7 Test 2 ? In-Reply-To: <45EE0A3A.5060202@laposte.net> References: <45EE0A3A.5060202@laposte.net> Message-ID: <45EE2E57.9010306@BitWagon.com> > I just tried to install Fedora 7 with "cdrom" as packages support, but > no drives seems to be detected. I use a P-ATA drive on a Nforce4-4x > powered motherboard (Asus K8N4-E Deluxe) and didn't found any suitable > driver in the list (maybe I missed it ?). On my machine it is called pata_amd , which is wonderfully consistent with with the Serial ATA driver sata_nv for the same chip, which is detected and loaded automatically. -- From seg at haxxed.com Wed Mar 7 04:42:21 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 06 Mar 2007 22:42:21 -0600 Subject: X server memory leak ? (Re: Announcing Fedora 7 Test 2 (6.91)) In-Reply-To: <1173086019.21501.28.camel@kloczek01.pracownicy.zie> References: <200703011112.12348.jkeating@redhat.com> <1172771738.25356.2.camel@kloczek01.pracownicy.zie> <1172771344.22136.118.camel@localhost.localdomain> <1172773609.25356.9.camel@kloczek01.pracownicy.zie> <1172775669.32357.27.camel@localhost.localdomain> <1172777571.32335.11.camel@kloczek01.pracownicy.zie> <1172777460.22136.134.camel@localhost.localdomain> <1172779164.32335.20.camel@kloczek01.pracownicy.zie> <1173056320.18771.24.camel@localhost.localdomain> <1173086019.21501.28.camel@kloczek01.pracownicy.zie> Message-ID: <1173242541.3665.25.camel@max.booze> On Mon, 2007-03-05 at 10:13 +0100, Tomasz K?oczko wrote: > Can you check this on your system using above scenario ? > Try to open gif/png file which will take big amount of memory in > uncompressed form (1MB or more). I do this fairly often. Yes, it will make Galeon (and the X server) eat up RAM like no tomorrow, and it never gets returned. -------------- 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 Mar 7 05:26:27 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 06 Mar 2007 23:26:27 -0600 Subject: Fedora safe/recovery mode In-Reply-To: <1173101664.8128.8.camel@wombat.dlib.indiana.edu> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> <87slcl6rdm.fsf@kosh.bigo.ensc.de> <20070304144522.GR3334@angus.ind.WPI.EDU> <20070304150103.GS3334@angus.ind.WPI.EDU> <1173101664.8128.8.camel@wombat.dlib.indiana.edu> Message-ID: <1173245187.3665.39.camel@max.booze> On Mon, 2007-03-05 at 08:34 -0500, Brian Wheeler wrote: > The idea (elsewhere in this thread) of having a recovery root (which > would probably be a busybox based system) on /boot is a good one, but it > shouldn't have a password either, just a really "stern" warning not to > do something stupid like, say, remove shared libraries. My idea was to just take the rescue CD, and install it unmodified in to /boot. Haven't got around to doing a proof of concept, its low on my currently somewhat long todo list.. Anaconda may need a patch to make it look for stage2 on /boot for this to work cleanly. How hard is it to just build the rescue CD image by itself so it can be packaged? -------------- 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 redhat.com Wed Mar 7 04:21:23 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 06 Mar 2007 22:21:23 -0600 Subject: Hal and device identification Message-ID: <45EE3DC3.30409@redhat.com> I've got a usb disk, hal finds it and identifies it as a JUMPDRIVE ELITE. This value is not in /usr/share/hwdata/usb.ids. My question is where did hal get this info, and how can I retrieve it given only the vendor id and device id (5dc:a400) ------------------------------------------------------------ udi = '/org/freedesktop/Hal/devices/usb_device_5dc_a400_00000000000000000001' info.udi = '/org/freedesktop/Hal/devices/usb_device_5dc_a400_00000000000000000001' (string) linux.subsystem = 'usb' (string) linux.hotplug_type = 1 (0x1) (int) usb_device.bus_number = 5 (0x5) (int) usb_device.can_wake_up = false (bool) usb_device.is_self_powered = false (bool) usb_device.version_bcd = 512 (0x200) (int) usb_device.speed_bcd = 294912 (0x48000) (int) usb_device.serial = '00000000000000000001' (string) usb_device.linux.device_number = 9 (0x9) (int) usb_device.num_ports = 0 (0x0) (int) usb_device.max_power = 100 (0x64) (int) usb_device.device_revision_bcd = 256 (0x100) (int) info.product = 'JUMPDRIVE ELITE' (string) usb_device.product = 'JUMPDRIVE ELITE' (string) info.vendor = 'Lexar Media, Inc.' (string) usb_device.vendor = 'Lexar Media, Inc.' (string) usb_device.product_id = 41984 (0xa400) (int) usb_device.vendor_id = 1500 (0x5dc) (int) usb_device.device_protocol = 0 (0x0) (int) usb_device.device_subclass = 0 (0x0) (int) usb_device.device_class = 0 (0x0) (int) usb_device.num_interfaces = 1 (0x1) (int) usb_device.num_configurations = 1 (0x1) (int) usb_device.configuration_value = 1 (0x1) (int) usb_device.linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.7/usb5/5-4' (string) info.linux.driver = 'usb' (string) info.bus = 'usb_device' (string) info.parent = '/org/freedesktop/Hal/devices/usb_device_0_0_0000_00_1d_7' (string) linux.sysfs_path_device = '/sys/devices/pci0000:00/0000:00:1d.7/usb5/5-4' (string) -Mike From seg at haxxed.com Wed Mar 7 05:37:01 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 06 Mar 2007 23:37:01 -0600 Subject: (no subject) In-Reply-To: <4104a9490702271051h4077d57ej8eaca673d2b8878@mail.gmail.com> References: <4104a9490702271051h4077d57ej8eaca673d2b8878@mail.gmail.com> Message-ID: <1173245821.3665.48.camel@max.booze> On Tue, 2007-02-27 at 19:51 +0100, Artur Bartek wrote: > Hello, > lately I found nice stuff > http://www.gnomefiles.org/app.php/Mac_Menubar_for_GNOME_and_Xfce , but > I can't compile gtk2 with patch need for macmenu and I can't compile > macmenu too;/ I think it's very good thing for the people who migrate > from macosx to fedora ;] Maybe somebody will make a two little > packages for fedora community ?:> Awesome, I've been hoping someone would write a patch for this. IMHO this UI paradigm has some major advantages. Like making "preloading" of applications possible without it being a special case. (Which seems to have some popularity on Windows...) Though for best results we need something like the dock, as well as apps would probably be patched to stay open if all its windows are closed if this mode is in use.... -------------- 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 Mar 7 04:49:02 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 06 Mar 2007 23:49:02 -0500 Subject: How does new F7 schedule affect Firefox In-Reply-To: <1172522352.11406.8.camel@shrek.rexursive.com> References: <1172522352.11406.8.camel@shrek.rexursive.com> Message-ID: <45EE443E.10700@redhat.com> Bojan Smojver wrote: > Now that the planned release date for F7 is 24 May 2007 (a month after > EOL for FF 1.5) Apologies for the delayed response, I was on vacation. EOL is misleading here. The Mozilla Corporation will be transferring maintainership away from themselves simply because they do not have the resources to continue pushing out builds for it. If Firefox were closed-source, it truly would be EOL when the entity controlling it decides it is. Since it isn't, then the nature of open source takes over. When Mozilla.org stops supporting it, others in the Mozilla community will. I've already announced that Red Hat will take on this responsibility at least until 3.0 is released. Prior to Robert O'Callahan leaving Novell, he also mentioned he would assist with that. Whether or not this is still the case, I cannot say, but Red Hat's commitment is still intact. Red Hat has already successfully demonstrated this with past Mozilla branches, such as Mozilla 1.4. From davej at redhat.com Wed Mar 7 05:29:32 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 7 Mar 2007 00:29:32 -0500 Subject: Hal and device identification In-Reply-To: <45EE3DC3.30409@redhat.com> References: <45EE3DC3.30409@redhat.com> Message-ID: <20070307052932.GB30278@redhat.com> On Tue, Mar 06, 2007 at 10:21:23PM -0600, Mike McGrath wrote: > I've got a usb disk, hal finds it and identifies it as a JUMPDRIVE > ELITE. This value is not in /usr/share/hwdata/usb.ids. My question is > where did hal get this info, and how can I retrieve it given only the > vendor id and device id (5dc:a400) It's the 'label' of the disk. man mlabel for more info. Dave -- http://www.codemonkey.org.uk From seg at haxxed.com Wed Mar 7 07:50:24 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 07 Mar 2007 01:50:24 -0600 Subject: VNC development plan - discuss In-Reply-To: <45ED356D.7060204@redhat.com> References: <45ED356D.7060204@redhat.com> Message-ID: <1173253824.3665.108.camel@max.booze> How about a usage case: I have a desktop machine. It runs multihead, 1400x1050 on a 19in CRT and 1280x960 on a 17in CRT. That's 2680x1050. I have a laptop. It has a 1024x768 LCD. Sometimes I want to access my desktop's existing X session from the laptop. Problem: The vast difference in resolution. As well as the difference in font size. I use a font size that is comfortable on the desktop but looks huge on the laptop. Scrolling around a massive area staring at huge fonts is painful. Its like trying to use my desktop looking through a straw. Possible solution: randr the desktop machine down to 1024x768 and scale the font size down when connected. This can be awkwardly done manually through the gnome preferences panel through vino. The server side libvnc.so module does not understand randr at all. Score: vino 1, libvnc.so 0 Possible solution: Scale the whole screen down server side. Neither vino or libvnc.so support this. Score: vino 1, libvnc.so 0 Possible solution: Scale the whole screen down client side. vncviewer does not support this. No VNC client that I know of supports this on Linux. TightVNC and some others support this on Windows. Score: vncviewer 0, TightVNC on Windows 1, TightVNC on Linux 0 Possible solution: Implement a vnc server as a compositing manager, that internally re-composites all windows to a virtual 1024x768 screen, with window positions independent of the real desktop. Status: Just some crackrock idea I had. So, sounds like vino wins? Except: Vino's performance is complete and total ass. vino 0, libvnc.so 1 Vino spews an enormous amount of shit over the network, when nothing is even happening. What, I don't know and I don't care enough to find out because of the previous point. vino -1, libvnc.so 1 Vino isn't available when not logged in. vino -1, libvnc.so 2 Cursor modification doesn't seem to work in vino. vino -2, libvnc.so 2 In Vino, ctrl-click in Galeon to open a link in a new tab doesn't work for some reason. vino -3, libvnc.so 2 After being rock solid for many years, recently libvnc.so has started randomly crashing the X server when I connect to it. I initially assumed it was fglrx, but no, it happens with nv, nvidia, and radeon drivers as well. Final score: vino -3, libvnc.so 0 So, yeah. I guess I should file some bugs or something if no one else has already. -------------- 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 atkac at redhat.com Wed Mar 7 07:10:44 2007 From: atkac at redhat.com (Adam Tkac) Date: Wed, 07 Mar 2007 08:10:44 +0100 Subject: VNC development plan - discuss In-Reply-To: <1173253824.3665.108.camel@max.booze> References: <45ED356D.7060204@redhat.com> <1173253824.3665.108.camel@max.booze> Message-ID: <45EE6574.9030109@redhat.com> Callum Lerwick napsal(a): > How about a usage case: > > I have a desktop machine. It runs multihead, 1400x1050 on a 19in CRT and > 1280x960 on a 17in CRT. That's 2680x1050. > > I have a laptop. It has a 1024x768 LCD. > > Sometimes I want to access my desktop's existing X session from the > laptop. > > Problem: The vast difference in resolution. As well as the difference in > font size. I use a font size that is comfortable on the desktop but > looks huge on the laptop. Scrolling around a massive area staring at > huge fonts is painful. Its like trying to use my desktop looking through > a straw. > > Possible solution: randr the desktop machine down to 1024x768 and scale > the font size down when connected. This can be awkwardly done manually > through the gnome preferences panel through vino. The server side > libvnc.so module does not understand randr at all. Score: vino 1, > libvnc.so 0 > You have trully right. libvnc has some gnats whose are very annoying. Bug exists (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167827) > Possible solution: Scale the whole screen down server side. Neither vino > or libvnc.so support this. Score: vino 1, libvnc.so 0 > > Possible solution: Scale the whole screen down client side. vncviewer > does not support this. No VNC client that I know of supports this on > Linux. TightVNC and some others support this on Windows. Score: > vncviewer 0, TightVNC on Windows 1, TightVNC on Linux 0 > > Possible solution: Implement a vnc server as a compositing manager, that > internally re-composites all windows to a virtual 1024x768 screen, with > window positions independent of the real desktop. Status: Just some > crackrock idea I had. > > So, sounds like vino wins? Except: > > Vino's performance is complete and total ass. vino 0, libvnc.so 1 > > Vino spews an enormous amount of shit over the network, when nothing is > even happening. What, I don't know and I don't care enough to find out > because of the previous point. vino -1, libvnc.so 1 > > Vino isn't available when not logged in. vino -1, libvnc.so 2 > > Cursor modification doesn't seem to work in vino. vino -2, libvnc.so 2 > > In Vino, ctrl-click in Galeon to open a link in a new tab doesn't work > for some reason. vino -3, libvnc.so 2 > > After being rock solid for many years, recently libvnc.so has started > randomly crashing the X server when I connect to it. I initially assumed > it was fglrx, but no, it happens with nv, nvidia, and radeon drivers as > well. > Main problem is that original libvnc.so is designed to working with monolitic server (XFree86). In early releases of modular X it doesn't matter but when next and next version of modular incomes module becomes more unstable. Badly broken module isn't my work :) I'm doing investigations what could be wrong but I don't have any ideas yet :( > Final score: vino -3, libvnc.so 0 > > So, yeah. I guess I should file some bugs or something if no one else > has already. > Overall vnc is primary designed to have Xserver on headless machines and module is for users who wants good performance but don't want special features (be patient, this is on my task list...). Regards, Adam From david at fubar.dk Wed Mar 7 07:36:58 2007 From: david at fubar.dk (David Zeuthen) Date: Wed, 07 Mar 2007 02:36:58 -0500 Subject: Hal and device identification In-Reply-To: <45EE3DC3.30409@redhat.com> References: <45EE3DC3.30409@redhat.com> Message-ID: <1173253018.2631.14.camel@zelda.fubar.dk> On Tue, 2007-03-06 at 22:21 -0600, Mike McGrath wrote: > I've got a usb disk, hal finds it and identifies it as a JUMPDRIVE > ELITE. This value is not in /usr/share/hwdata/usb.ids. My question is > where did hal get this info, and how can I retrieve it given only the > vendor id and device id (5dc:a400) The kernel may exports vendor/product names in sysfs (the files are called 'manufacturer' and 'product') that is retrieved as part of the probing (see section 9.6.1 of the USB 2.0 spec). If these files are not available, HAL consults the usb.ids file. Btw, in the future it's better to ask such questions on hal at lists.freedesktop.org David From atkac at redhat.com Wed Mar 7 07:38:51 2007 From: atkac at redhat.com (Adam Tkac) Date: Wed, 07 Mar 2007 08:38:51 +0100 Subject: VNC development plan - discuss In-Reply-To: <20070306212022.GN29872@redhat.com> References: <45ED356D.7060204@redhat.com> <20070306212022.GN29872@redhat.com> Message-ID: <45EE6C0B.3030904@redhat.com> Daniel P. Berrange napsal(a): > On Tue, Mar 06, 2007 at 08:46:24PM +0000, Mike Cohler wrote: > >> Adam Tkac redhat.com> writes: >> >> >>> features than actual "real desktop" servers. So two programs could be >>> removed and one added => cost of maintaining and bugfixing could be >>> lower. In next stage we could discuss about standardized RFB protocol >>> library which could be used by all vnc servers in distro. In the end we >>> could have one rfb library which will be used by all servers (and >>> viewers), one real server, one virtual server and X module. What do you >>> think about this idea? >>> > > Since we're on the subject of VNC servers, its a good time to bring up the > question of virtualization. With Xen in the mix there are actually 2 further > VNC server implementations in Fedora... > > - Xen para-virtualized guest console server > - QEMU / KVM / Xen fully-virtualized guest console server > > The former is currently based on libvncserver which turned out to be an > really bad mistake. The code is horribly complicated / obtuse and has > completely unsafe use of pthreads synchronization primitives. The QEMU VNC > server is a from sratch impl of the RFB protocol which is directly part of > the QEMU codebase. It is my intention that the current Xen paravirt VNC > server will be re-written to use more-or-less the same code as the current > QEMU impl, which will bring it down from ~20,000 lines of C, to ~2,000. > Now this isn't directly relevant, since the code isn't really suitable for > turning into a standalone VNC server. I just wanted to point out that > you should be wary of picking libvncserver as the basis of a shared RFB > impl in its current form, since the codebase isn't all that nice to work > with. > Don't tell me about xen's virtual console. I have dreams about nasty mouse tracking (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221360) every night. If you're going to do major changes on vnc bits in xen, I'm ready to help you with this development. If you're really looking for good RFB Protocol implementation I think that RealVNC's implementation is best (stable, robust, c++ implementation for server and viewer side). Recently I've created package named vnc-libs (in rawhide) which contains this implementation. You could write me mail if this solution sounds good for you ;) > The whole discussion of merging VNC servers though misses out the most > critical shortcoming in VNC - it has a non-existant security model. All > traffic is clear-text on the wire, and the authentication is trivially > brute-forced. Tunnelling it over SSH is really just a band-aid, because > even with it restricted to listen on 127.0.0.1 any local user can still > trivially compromise any other user's session > > For the virtualization arena, tunnelling over SSH is out of the quesiton > because integrity of the host system is too important. You don't want to > have to give out login accounts to the host just so that a user can access > the guest virtual console. So for Xen / QEMU I am currently working on > implementing native SSL support in their respective VNC server impls, based > on the protocol defined by VeNCrypt. I expect this work to arrive some > time in the Fedora 8 dev cycle, which is when we hope to have full-remote > management capabilities for Xen / QEMU / KVM. > > The caveat is that AFAIK, Fedora doesn't have any VNC viewer program that > supports encryption aside from SSH tunnelling - not a huge problem since > virt-manager has an embedded GTK VNC widget which can do the job, but it > would be nice to have a standalone viewer for virtual machine consoles. > > So if we're thinking of long term Fedora VNC development plans, we should > make sure encryption / authentication is on the list for both client & > server. > You're right. Current VNC security model was good in 80s but nowadays is complete unusable. I want make vnc secure but protocol is protocol... (http://www.realvnc.com/docs/rfbproto.pdf). We can't make RedHat's vnc which will have perfect security policies but which is incompatible with other vnc implementations. Btw VeNCrypt looks fine. I could do investigations what could be ported to our vnc to improve security. > Regards, > Dan. > Regards, Adam From david at fubar.dk Wed Mar 7 07:40:21 2007 From: david at fubar.dk (David Zeuthen) Date: Wed, 07 Mar 2007 02:40:21 -0500 Subject: Hal and device identification In-Reply-To: <20070307052932.GB30278@redhat.com> References: <45EE3DC3.30409@redhat.com> <20070307052932.GB30278@redhat.com> Message-ID: <1173253221.2631.18.camel@zelda.fubar.dk> On Wed, 2007-03-07 at 00:29 -0500, Dave Jones wrote: > On Tue, Mar 06, 2007 at 10:21:23PM -0600, Mike McGrath wrote: > > I've got a usb disk, hal finds it and identifies it as a JUMPDRIVE > > ELITE. This value is not in /usr/share/hwdata/usb.ids. My question is > > where did hal get this info, and how can I retrieve it given only the > > vendor id and device id (5dc:a400) > > It's the 'label' of the disk. Actually, for that snippet it's not - what's shown is the properties for the USB device... the block device, for which we do probe for the file system, is much lower in the stack on the "other" side of the SCSI glue. > man mlabel for more info. /lib/udev/vol_id forever! David From atkac at redhat.com Wed Mar 7 07:54:10 2007 From: atkac at redhat.com (Adam Tkac) Date: Wed, 07 Mar 2007 08:54:10 +0100 Subject: VNC development plan - discuss In-Reply-To: <45ED356D.7060204@redhat.com> References: <45ED356D.7060204@redhat.com> Message-ID: <45EE6FA2.205@redhat.com> Adam Tkac napsal(a): > Hi all, > > I did thinking about next development on vnc bits. Fedora 7 has three > vnc servers - GNOME's vino, KDE's krfb and headless Xvnc with module > to X. I'm not sure that we really need three different vnc servers in > distribution. krfb and vino are very simillar. Both of these export > real display. I think we could try substitute this two servers by one > - for example x11vnc (http://www.karlrunge.com/x11vnc/). x11vnc has > more features than actual "real desktop" servers. So two programs > could be removed and one added => cost of maintaining and bugfixing > could be lower. In next stage we could discuss about standardized RFB > protocol library which could be used by all vnc servers in distro. In > the end we could have one rfb library which will be used by all > servers (and viewers), one real server, one virtual server and X > module. What do you think about this idea? > > Regards, Adam > Btw it exists project on sourceforge (http://sourceforge.net/projects/xrfb) which is in planning stage. It will be complete linux vnc implementation(server + viewer) which will bring best things+ideas from all exists vncs. Everyone who is interested in development on this project or have some good ideas could write me mail -A- From enrico.scholz at informatik.tu-chemnitz.de Wed Mar 7 07:50:05 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 07 Mar 2007 08:50:05 +0100 Subject: Fedora safe/recovery mode In-Reply-To: <1173245187.3665.39.camel@max.booze> (Callum Lerwick's message of "Tue, 06 Mar 2007 23:26:27 -0600") References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> <87slcl6rdm.fsf@kosh.bigo.ensc.de> <20070304144522.GR3334@angus.ind.WPI.EDU> <20070304150103.GS3334@angus.ind.WPI.EDU> <1173101664.8128.8.camel@wombat.dlib.indiana.edu> <1173245187.3665.39.camel@max.booze> Message-ID: <878xe9ebma.fsf@kosh.bigo.ensc.de> Callum Lerwick writes: >> The idea (elsewhere in this thread) of having a recovery root (which >> would probably be a busybox based system) on /boot is a good one, but >> it shouldn't have a password either, just a really "stern" warning >> not to do something stupid like, say, remove shared libraries. > > My idea was to just take the rescue CD, and install it unmodified in > to /boot. Ok with me. But please do not make this mandatory. My 32 MiB sized /boot will not have enough space for the rescue CD image. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From markmc at redhat.com Wed Mar 7 08:13:19 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 07 Mar 2007 08:13:19 +0000 Subject: VNC development plan - discuss In-Reply-To: <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> References: <45ED356D.7060204@redhat.com> <1173182009.3288.67.camel@blaa> <45ED5D45.2000903@redhat.com> <1173199226.19903.37.camel@greebo> <45ED9DC5.7000001@redhat.com> <1173201044.3288.211.camel@blaa> <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> Message-ID: <1173255199.3280.19.camel@blaa> Hi Jeff, On Tue, 2007-03-06 at 09:42 -0900, Jeff Spaleta wrote: > > Speaking of vino, > when you have vino active and you are logged in remotely, the local > console display is also active, at least through fc6. Is this a > designed feature, or is this a current codebase limitation? It's purely a current limitation, for sure. http://bugzilla.gnome.org/show_bug.cgi?id=311780 Basically, the problem is that Vino just scrapes the contents of the root window and exports that. So, if the screensaver is rendering to the root window, then there's not much Vino can do. Cheers, Mark. From tagoh at redhat.com Wed Mar 7 09:42:41 2007 From: tagoh at redhat.com (Akira TAGOH) Date: Wed, 07 Mar 2007 18:42:41 +0900 (JST) Subject: how to manage the package specific accounts Message-ID: <20070307.184241.957833582.tagoh@redhat.com> Hi, Some packages are creating the system account for their programs/deamons in the scriptlet with the specific user id. So how does it actually prevent the duplicate user id between the packages? I just wanted to know if there are any policy/guildeline or the management system in Fedora for the user id. -- Akira TAGOH -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From axel.azerty at laposte.net Wed Mar 7 09:21:00 2007 From: axel.azerty at laposte.net (Axel) Date: Wed, 07 Mar 2007 10:21:00 +0100 Subject: freeze during install Message-ID: <45EE83FC.4000501@laposte.net> I downloaded boot iso from ftp.crihan.fr mirror and tried to make a fresh install of FC7. Boot goes well and installation wizard starts without problem. After the dependancies computation and the / & swap format the install stop. No "lock", GUI can be use but the install waits with a progress bar which doesn'nt progress anymore. In one of the tty I see the message "No handler could be found for yum.Yumbase" or something like that. Is that a known problem for test 2 or maybe I forgot something ? Regards Axel From bojan at rexursive.com Wed Mar 7 10:26:18 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 7 Mar 2007 10:26:18 +0000 (UTC) Subject: How does new F7 schedule affect Firefox References: <1172522352.11406.8.camel@shrek.rexursive.com> <45EE443E.10700@redhat.com> Message-ID: Christopher Aillon redhat.com> writes: > Red Hat's commitment is still intact. No worries. -- Bojan From sundaram at fedoraproject.org Wed Mar 7 11:01:29 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 07 Mar 2007 16:31:29 +0530 Subject: How does new F7 schedule affect Firefox In-Reply-To: <45EE443E.10700@redhat.com> References: <1172522352.11406.8.camel@shrek.rexursive.com> <45EE443E.10700@redhat.com> Message-ID: <45EE9B89.4030107@fedoraproject.org> Christopher Aillon wrote: > Bojan Smojver wrote: >> Now that the planned release date for F7 is 24 May 2007 (a month after >> EOL for FF 1.5) > > Apologies for the delayed response, I was on vacation. > > EOL is misleading here. The Mozilla Corporation will be transferring > maintainership away from themselves simply because they do not have the > resources to continue pushing out builds for it. > > > > If Firefox were closed-source, it truly would be EOL when the entity > controlling it decides it is. Since it isn't, then the nature of open > source takes over. When Mozilla.org stops supporting it, others in the > Mozilla community will. I've already announced that Red Hat will take > on this responsibility at least until 3.0 is released. When Mozilla.org stops supporting it, are they willing to let Red Hat add patches and release new versions under the Firefox name? Rahul From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Mar 7 12:01:58 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 7 Mar 2007 13:01:58 +0100 Subject: Missing P-ATA CDROM support in Fedora 7 Test 2 ? In-Reply-To: <45EE2E57.9010306@BitWagon.com> References: <45EE0A3A.5060202@laposte.net> <45EE2E57.9010306@BitWagon.com> Message-ID: <20070307130158.146f9da5@python3.es.egwn.lan> John Reiser wrote : > > I just tried to install Fedora 7 with "cdrom" as packages support, but > > no drives seems to be detected. I use a P-ATA drive on a Nforce4-4x > > powered motherboard (Asus K8N4-E Deluxe) and didn't found any suitable > > driver in the list (maybe I missed it ?). > > On my machine it is called pata_amd , which is wonderfully > consistent with with the Serial ATA driver sata_nv > for the same chip, which is detected and loaded automatically. Same here. I got somewhat confused when the installer prompted me to try a driver or use a driver disk... at first I thought it was my SATA (sata_nv here too) which wasn't recognized, but then I found out that I needed to select the pata_amd module, because it was the DVD which wasn't being found. Does anyone know if this bug has already been filed? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 0.35 0.71 1.31 From seg at haxxed.com Wed Mar 7 13:32:02 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 07 Mar 2007 07:32:02 -0600 Subject: Fedora safe/recovery mode In-Reply-To: <878xe9ebma.fsf@kosh.bigo.ensc.de> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> <87slcl6rdm.fsf@kosh.bigo.ensc.de> <20070304144522.GR3334@angus.ind.WPI.EDU> <20070304150103.GS3334@angus.ind.WPI.EDU> <1173101664.8128.8.camel@wombat.dlib.indiana.edu> <1173245187.3665.39.camel@max.booze> <878xe9ebma.fsf@kosh.bigo.ensc.de> Message-ID: <1173274322.3617.1.camel@max.booze> On Wed, 2007-03-07 at 08:50 +0100, Enrico Scholz wrote: > Callum Lerwick writes: > > My idea was to just take the rescue CD, and install it unmodified in > > to /boot. > > Ok with me. But please do not make this mandatory. My 32 MiB sized /boot > will not have enough space for the rescue CD image. Last I checked, anaconda insisted on at least a 256mb /boot. So that's kind of Your Problem(TM). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at camperquake.de Wed Mar 7 12:22:29 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 7 Mar 2007 13:22:29 +0100 Subject: Fedora safe/recovery mode In-Reply-To: <1173274322.3617.1.camel@max.booze> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> <87slcl6rdm.fsf@kosh.bigo.ensc.de> <20070304144522.GR3334@angus.ind.WPI.EDU> <20070304150103.GS3334@angus.ind.WPI.EDU> <1173101664.8128.8.camel@wombat.dlib.indiana.edu> <1173245187.3665.39.camel@max.booze> <878xe9ebma.fsf@kosh.bigo.ensc.de> <1173274322.3617.1.camel@max.booze> Message-ID: <20070307132229.78ce2817@banea.int.addix.net> Hi. On Wed, 07 Mar 2007 07:32:02 -0600, Callum Lerwick wrote: > Last I checked, anaconda insisted on at least a 256mb /boot. So that's > kind of Your Problem(TM). Huh? I have always (last with FC6) used 100MB /boot. Anaconda even created those, I think. From seg at haxxed.com Wed Mar 7 13:49:52 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 07 Mar 2007 07:49:52 -0600 Subject: announce: readahead-1.4 In-Reply-To: <883cfe6d0703051442v2d74ebe8w6ef1764cd659cbd5@mail.gmail.com> References: <20070301105026.GF4449@petra.dvoda.cz> <883cfe6d0703051442v2d74ebe8w6ef1764cd659cbd5@mail.gmail.com> Message-ID: <1173275392.3617.6.camel@max.booze> On Mon, 2007-03-05 at 17:42 -0500, Michel Salim wrote: > This is more of a planning-for-the-future request, but with Intel > bundling Flash memory into their motherboards starting with the Santa > Rosa platform to be released this May, would readahead support the use > of cache devices? Seems like this newfangled flash crap is better used for journaling. Flash disks are generally slower than a sequential hard disk access. They're definitely slow for writing. I dunno WTF microsoft is thinking. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at camperquake.de Wed Mar 7 12:52:06 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 7 Mar 2007 13:52:06 +0100 Subject: announce: readahead-1.4 In-Reply-To: <1173275392.3617.6.camel@max.booze> References: <20070301105026.GF4449@petra.dvoda.cz> <883cfe6d0703051442v2d74ebe8w6ef1764cd659cbd5@mail.gmail.com> <1173275392.3617.6.camel@max.booze> Message-ID: <20070307135206.08f1cb6e@banea.int.addix.net> Hi. On Wed, 07 Mar 2007 07:49:52 -0600, Callum Lerwick wrote: > Seems like this newfangled flash crap is better used for journaling. > > Flash disks are generally slower than a sequential hard disk access. > They're definitely slow for writing. I dunno WTF microsoft is > thinking. Flash does not have seek times, which is a big plus for speeding up the boot process. From seg at haxxed.com Wed Mar 7 14:09:36 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 07 Mar 2007 08:09:36 -0600 Subject: Fedora safe/recovery mode In-Reply-To: <20070307132229.78ce2817@banea.int.addix.net> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> <87slcl6rdm.fsf@kosh.bigo.ensc.de> <20070304144522.GR3334@angus.ind.WPI.EDU> <20070304150103.GS3334@angus.ind.WPI.EDU> <1173101664.8128.8.camel@wombat.dlib.indiana.edu> <1173245187.3665.39.camel@max.booze> <878xe9ebma.fsf@kosh.bigo.ensc.de> <1173274322.3617.1.camel@max.booze> <20070307132229.78ce2817@banea.int.addix.net> Message-ID: <1173276576.3617.10.camel@max.booze> On Wed, 2007-03-07 at 13:22 +0100, Ralf Ertzinger wrote: > Huh? I have always (last with FC6) used 100MB /boot. Anaconda even created > those, I think. Hmm, I could have sworn it was ~200mb. If not, that makes the rescue disk a rather tight squeeze... -------------- 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 thomas.canniot at laposte.net Wed Mar 7 12:21:46 2007 From: thomas.canniot at laposte.net (Thomas Canniot) Date: Wed, 07 Mar 2007 13:21:46 +0100 Subject: Translations: String freezes, CVS converging, Packaging In-Reply-To: <45EDE4F0.4050500@glezos.com> References: <45EDE4F0.4050500@glezos.com> Message-ID: <1173270106.3488.19.camel@localhost.localdomain> Le mardi 06 mars 2007 ? 22:02 +0000, Dimitris Glezos a ?crit : > Hi all. > > The L10n project has been discussing for a while now (also at FOSDEM with > mspevack) about ways to improve our translation processes. We estimate that more > than 1 out of 3 users uses a non-English desktop. > > First of all, let's clarify here that for the time being, we are referring only > to applications that Fedora is upstream (anaconda, system-config-*, and > basically most of the non-deprecated stuff that appears on [1]). > > [1]:http://i18n.redhat.com/cgi-bin/i18n-status?page=status&locale=es&branch=HEAD&essential=0 > > The plan in mind includes three actions. > > > ## String freezes > > For F7, the RelEng team has introduced string freezes in the schedule [2]. This > means that application strings for F7 should be complete *by 19/3*. Translations > made after this date (and before the freeze) should be guaranteed to be included > in the release. > > [2]: http://fedoraproject.org/wiki/Core/Schedule > > To do this we need to try not to add new strings after the freeze and let the > L10n folks know if they need to do so. Also, maintainers should repackage before > each release (and after the translation freeze) without a bug needing to be > opened. Indeed, this would definitely help translators to have a translation-polished release. What do developers think about this ? > > > ## CVS convergence > > Right now translations are done on `i18n.redhat.com`. This requires contributors > to have one account on the Fedora Account System (FAS) and a different > one for translations. With the merge of Core and Extras, now is a good > point to get rid of this distinction. > > The plan is to move all PO files on Fedora infrastructure under a new > CVS group (cvsl10n) [3]. An email will be sent to all translators to create a > FAS account if they don't have one and join the cvs group. Members of the L10n > team and ambassadors will help with this process. > > [3]: http://fedoraproject.org/wiki/L10N/Projects/CVSInfrastructure This is a good idea as well. Even if both projects may look different, they are closely tight : at least, by the infrastructure. Translators also help a lot improving and correcting Docs during their translations. > > At this point we could discuss the idea for Fedora to act as upstream for > the translations of outside-hosted projects such as yum, smolt, and > pungi. The proposal is to host and maintain those project's > translations with the existing Fedora L10n community. I agree as well and I have been waiting YUM translation for a while, without having be heard it seems. I would add that yum translation project seems to be stopped for a unknown reason. > > > ## Packaging translations > > One final plan (and probably the one that needs most discussion) is about > changing the way we package translations. Right now PO files live inside the > application and are packaged there (GNOME-style). The plan is to move the PO > files in to their own directory and distinct package [4] (KDE-style langpacks). > > [4]: http://fedoraproject.org/wiki/L10N/Projects/TranslationsPackage > > Cons: L10n team should maintain a package (or many) and packages should be > altered to accomodate the different locations of PO files. > > Pros (many): increased modularity and maintenance (L10n repackages at > will). App packages will be smaller in size -- we could provide > one langpack or different ones per language. > > This is definitely a good idea as well and would give translators the possibilities to be more independent and would avoid them always being asking maintainers to update their translations. Thanks Dimitri :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From radekvokal at gmail.com Wed Mar 7 13:30:28 2007 From: radekvokal at gmail.com (=?UTF-8?B?UmFkZWsgVm9rw6Fs?=) Date: Wed, 07 Mar 2007 14:30:28 +0100 Subject: spamassassin in rawhide buid problem In-Reply-To: <45EB8DEA.8030106@ioa.s.u-tokyo.ac.jp> References: <45EB88F1.1050906@redhat.com> <45EB8DEA.8030106@ioa.s.u-tokyo.ac.jp> Message-ID: <45EEBE74.3030908@gmail.com> Mamoru Tasaka wrote: > Warren Togami wrote: >> Checking if your kit is complete... >> Looks good >> Writing Makefile for Mail::SpamAssassin >> Makefile written by ExtUtils::MakeMaker 6.30 >> + /usr/bin/make 'SSLCFLAGS=-DSPAMC_SSL -I/usr/kerberos/include' >> 'OPTIMIZE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' >> make: *** No rule to make target >> `/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/config.h', >> needed by `Makefile'. Stop. >> error: Bad exit status from /var/tmp/rpm-tmp.48771 (%build) > > This is due to the recent change in perl > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226276 > > Perhaps adding perl-devel as BR should solve your issue, > > Mamoru > Shouldn't be both perl and perl-devel part of buildroot anyway? Radek From axel.azerty at laposte.net Wed Mar 7 13:34:53 2007 From: axel.azerty at laposte.net (Axel) Date: Wed, 07 Mar 2007 14:34:53 +0100 Subject: Missing P-ATA CDROM support in Fedora 7 Test 2 ? In-Reply-To: <20070307130158.146f9da5@python3.es.egwn.lan> References: <45EE0A3A.5060202@laposte.net> <45EE2E57.9010306@BitWagon.com> <20070307130158.146f9da5@python3.es.egwn.lan> Message-ID: <45EEBF7D.5070805@laposte.net> Matthias Saou a ?crit : > John Reiser wrote : > > >>> I just tried to install Fedora 7 with "cdrom" as packages support, but >>> no drives seems to be detected. I use a P-ATA drive on a Nforce4-4x >>> powered motherboard (Asus K8N4-E Deluxe) and didn't found any suitable >>> driver in the list (maybe I missed it ?). >>> >> On my machine it is called pata_amd , which is wonderfully >> consistent with with the Serial ATA driver sata_nv >> for the same chip, which is detected and loaded automatically. >> > > Same here. I got somewhat confused when the installer prompted me to > try a driver or use a driver disk... at first I thought it was my SATA > (sata_nv here too) which wasn't recognized, but then I found out that I > needed to select the pata_amd module, because it was the DVD which > wasn't being found. > > Does anyone know if this bug has already been filed? > > Matthias > > Thanks for your answers, I 'll try with that pata_amd driver. Regards From paul at city-fan.org Wed Mar 7 13:43:50 2007 From: paul at city-fan.org (Paul Howarth) Date: Wed, 07 Mar 2007 13:43:50 +0000 Subject: spamassassin in rawhide buid problem In-Reply-To: <45EEBE74.3030908@gmail.com> References: <45EB88F1.1050906@redhat.com> <45EB8DEA.8030106@ioa.s.u-tokyo.ac.jp> <45EEBE74.3030908@gmail.com> Message-ID: <45EEC196.9090704@city-fan.org> Radek Vok?l wrote: > Mamoru Tasaka wrote: >> Warren Togami wrote: >>> Checking if your kit is complete... >>> Looks good >>> Writing Makefile for Mail::SpamAssassin >>> Makefile written by ExtUtils::MakeMaker 6.30 >>> + /usr/bin/make 'SSLCFLAGS=-DSPAMC_SSL -I/usr/kerberos/include' >>> 'OPTIMIZE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >>> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' >>> make: *** No rule to make target >>> `/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/config.h', >>> needed by `Makefile'. Stop. >>> error: Bad exit status from /var/tmp/rpm-tmp.48771 (%build) >> >> This is due to the recent change in perl >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226276 >> >> Perhaps adding perl-devel as BR should solve your issue, >> >> Mamoru >> > > Shouldn't be both perl and perl-devel part of buildroot anyway? perl is only there as a dep of rpm-build. There's no reason (other than as a temporary workaround) why perl-devel should be in there, just as for instance python-devel isn't in there. Paul. From alan at redhat.com Wed Mar 7 13:49:07 2007 From: alan at redhat.com (Alan Cox) Date: Wed, 7 Mar 2007 08:49:07 -0500 Subject: Missing P-ATA CDROM support in Fedora 7 Test 2 ? In-Reply-To: <45EE2E57.9010306@BitWagon.com> References: <45EE0A3A.5060202@laposte.net> <45EE2E57.9010306@BitWagon.com> Message-ID: <20070307134907.GA14476@devserv.devel.redhat.com> On Tue, Mar 06, 2007 at 07:15:35PM -0800, John Reiser wrote: > On my machine it is called pata_amd , which is wonderfully > consistent with with the Serial ATA driver sata_nv > for the same chip, which is detected and loaded automatically. The PATA port on the Nvidia chipsets is the same as the AMD one, hence the naming.. From wolfy at nobugconsulting.ro Wed Mar 7 13:52:24 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 07 Mar 2007 15:52:24 +0200 Subject: spamassassin in rawhide buid problem In-Reply-To: <45EEC196.9090704@city-fan.org> References: <45EB88F1.1050906@redhat.com> <45EB8DEA.8030106@ioa.s.u-tokyo.ac.jp> <45EEBE74.3030908@gmail.com> <45EEC196.9090704@city-fan.org> Message-ID: <45EEC398.8080508@nobugconsulting.ro> Paul Howarth wrote: > Radek Vok?l wrote: >> Mamoru Tasaka wrote: >>> Warren Togami wrote: >>>> Checking if your kit is complete... >>>> Looks good >>>> Writing Makefile for Mail::SpamAssassin >>>> Makefile written by ExtUtils::MakeMaker 6.30 >>>> + /usr/bin/make 'SSLCFLAGS=-DSPAMC_SSL -I/usr/kerberos/include' >>>> 'OPTIMIZE=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions >>>> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' >>>> make: *** No rule to make target >>>> `/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/config.h', >>>> needed by `Makefile'. Stop. >>>> error: Bad exit status from /var/tmp/rpm-tmp.48771 (%build) >>> >>> This is due to the recent change in perl >>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226276 >>> >>> Perhaps adding perl-devel as BR should solve your issue, >>> >>> Mamoru >>> >> >> Shouldn't be both perl and perl-devel part of buildroot anyway? > > perl is only there as a dep of rpm-build. There's no reason (other > than as a temporary workaround) why perl-devel should be in there, > just as for instance python-devel isn't in there. > > Paul. > FWIW: according to http://fedoraproject.org/wiki/Extras/FullExceptionList perl should be in the buildroot From berrange at redhat.com Wed Mar 7 14:55:45 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 7 Mar 2007 14:55:45 +0000 Subject: VNC development plan - discuss In-Reply-To: <45EE6C0B.3030904@redhat.com> References: <45ED356D.7060204@redhat.com> <20070306212022.GN29872@redhat.com> <45EE6C0B.3030904@redhat.com> Message-ID: <20070307145545.GB6302@redhat.com> On Wed, Mar 07, 2007 at 08:38:51AM +0100, Adam Tkac wrote: > Daniel P. Berrange napsal(a): > >Since we're on the subject of VNC servers, its a good time to bring up the > >question of virtualization. With Xen in the mix there are actually 2 > >further > >VNC server implementations in Fedora... > > > > - Xen para-virtualized guest console server > > - QEMU / KVM / Xen fully-virtualized guest console server > > > >The former is currently based on libvncserver which turned out to be an > >really bad mistake. The code is horribly complicated / obtuse and has > >completely unsafe use of pthreads synchronization primitives. The QEMU VNC > >server is a from sratch impl of the RFB protocol which is directly part of > >the QEMU codebase. It is my intention that the current Xen paravirt VNC > >server will be re-written to use more-or-less the same code as the current > >QEMU impl, which will bring it down from ~20,000 lines of C, to ~2,000. > >Now this isn't directly relevant, since the code isn't really suitable for > >turning into a standalone VNC server. I just wanted to point out that > >you should be wary of picking libvncserver as the basis of a shared RFB > >impl in its current form, since the codebase isn't all that nice to work > >with. > > > > Don't tell me about xen's virtual console. I have dreams about nasty > mouse tracking > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=221360) every I know, I know - its awful. In the virt-manager which is in rawhide this is worked around by doing a pointer grab & hiding the local cursor. Not ideal but a hell of alot better than current. The root problem is not really VNC's fault though - we get absolute mouse coords in the local GTK widget, these are passed over VNC as absolute coords to Xen, then passes them upto the guest OS as absolute coords, and finally the guest X server translates them to relative coords and applies mouse acceleration again :-( I've figured out a Xorg config stting to make it use absolute coords in the guest, so now its just a case of making X auto-configure this out-of-the-box. > night. If you're going to do major changes on vnc bits in xen, I'm ready > to help you with this development. If you're really looking for good RFB > Protocol implementation I think that RealVNC's implementation is best > (stable, robust, c++ implementation for server and viewer side). > Recently I've created package named vnc-libs (in rawhide) which contains > this implementation. You could write me mail if this solution sounds > good for you ;) I'll investigate vnc-libs to see how easy it'd be to use. I've also got to take in account upstream Xen development though - current thoughts are that the Xen paravirt VNC server should use same VNC code as the existing QEMU server so that Xen folks only have a single impl to maintain. I'll let you know if I've any Q's > >The caveat is that AFAIK, Fedora doesn't have any VNC viewer program that > >supports encryption aside from SSH tunnelling - not a huge problem since > >virt-manager has an embedded GTK VNC widget which can do the job, but it > >would be nice to have a standalone viewer for virtual machine consoles. > > > >So if we're thinking of long term Fedora VNC development plans, we should > >make sure encryption / authentication is on the list for both client & > >server. > > > > You're right. Current VNC security model was good in 80s but nowadays is > complete unusable. I want make vnc secure but protocol is protocol... > (http://www.realvnc.com/docs/rfbproto.pdf). We can't make RedHat's vnc > which will have perfect security policies but which is incompatible with > other vnc implementations. Btw VeNCrypt looks fine. I could do > investigations what could be ported to our vnc to improve security. Yes, I choose VeNCrypt becasue there is a formal RFB authentication protocol allocated to it in the VNC spec now. I certainly don't want anything to be Red Hat specific about it, because this is be targetted for upstream QEMU and Xen codebases. BTW, I asked the VeNCrypt developers for a spec for their protocol extension, and here's the info they gave back... http://lists.gnu.org/archive/html/qemu-devel/2007-03/msg00006.html NB, they're basically tracking RealVNC releases for their implementation. The implementation they have though is not as complete as it needs to be, in particular they've not done any x509 certificate validation on client or server yet. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From fedora at camperquake.de Wed Mar 7 15:10:33 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 7 Mar 2007 16:10:33 +0100 Subject: VNC development plan - discuss In-Reply-To: <20070307145545.GB6302@redhat.com> References: <45ED356D.7060204@redhat.com> <20070306212022.GN29872@redhat.com> <45EE6C0B.3030904@redhat.com> <20070307145545.GB6302@redhat.com> Message-ID: <20070307161033.17672e12@banea.int.addix.net> Hi. On Wed, 7 Mar 2007 14:55:45 +0000, Daniel P. Berrange wrote: > I know, I know - its awful. In the virt-manager which is in rawhide > this is worked around by doing a pointer grab & hiding the local > cursor. Not ideal but a hell of alot better than current. The root > problem is not really VNC's fault though - we get absolute mouse > coords in the local GTK widget, these are passed over VNC as absolute > coords to Xen, then passes them upto the guest OS as absolute coords, > and finally the guest X server translates them to relative coords and > applies mouse acceleration again :-( I've figured out a Xorg config > stting to make it use absolute coords in the guest, so now its just a > case of making X auto-configure this out-of-the-box. Kill me for being stupid, but... Wouldn't it make sense to treat the virtual input device as a tablet (which deliver absolute coordinates by nature, no?) instead of a mouse (which deliver relative coordinates)? From sundaram at fedoraproject.org Wed Mar 7 15:34:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 07 Mar 2007 21:04:16 +0530 Subject: KDE-Live-Spin In-Reply-To: <200702280012.37970.lightsolphoenix@gmail.com> References: <20070227174339.50469e76@localhost.localdomain> <200702280012.37970.lightsolphoenix@gmail.com> Message-ID: <45EEDB78.1060803@fedoraproject.org> Kelly wrote: > I'm a Fedora KDE user, and I'm willing to help out with the Fedora KDE spin if > anything needs to be done. Just let me know. > The things to be done: 1) Review, package KDE components 2) Help on selecting packages, configuration, branding on the KDE spin and Live CD 3) Documentation 4) Testing 5) Promotion Rahul From berrange at redhat.com Wed Mar 7 15:39:50 2007 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 7 Mar 2007 15:39:50 +0000 Subject: VNC development plan - discuss In-Reply-To: <20070307161033.17672e12@banea.int.addix.net> References: <45ED356D.7060204@redhat.com> <20070306212022.GN29872@redhat.com> <45EE6C0B.3030904@redhat.com> <20070307145545.GB6302@redhat.com> <20070307161033.17672e12@banea.int.addix.net> Message-ID: <20070307153950.GD6302@redhat.com> On Wed, Mar 07, 2007 at 04:10:33PM +0100, Ralf Ertzinger wrote: > Hi. > > On Wed, 7 Mar 2007 14:55:45 +0000, Daniel P. Berrange wrote: > > > I know, I know - its awful. In the virt-manager which is in rawhide > > this is worked around by doing a pointer grab & hiding the local > > cursor. Not ideal but a hell of alot better than current. The root > > problem is not really VNC's fault though - we get absolute mouse > > coords in the local GTK widget, these are passed over VNC as absolute > > coords to Xen, then passes them upto the guest OS as absolute coords, > > and finally the guest X server translates them to relative coords and > > applies mouse acceleration again :-( I've figured out a Xorg config > > stting to make it use absolute coords in the guest, so now its just a > > case of making X auto-configure this out-of-the-box. > > Kill me for being stupid, but... Wouldn't it make sense to treat the > virtual input device as a tablet (which deliver absolute coordinates > by nature, no?) instead of a mouse (which deliver relative coordinates)? In the perfect world, yes. But sadly this isn't a perfect world and so if you want a pointer device that is guarenteed to work out-of-the-box with all known OS, then it has to be a mouse. Even OS which do support tablets don't typically support them in the installer. That all said, we are also planning to make it possible to configure the pointer as a tablet for those OS which support it. Things are complicated by the different between full and paravirt though - fullvirt uses QEMU for its device model which does various mice & tablets, none of the tablets are supported by in-tree Xorg drivers though :-( So the tablet config for QEMU is only suitable for Windows guests at this time. Paravirt is not technically exposing any particular kind of hardware at all. It is injecting pointer events directly into the Linux input event device layer - this knows nothing of the difference between mice & pointers - its is merely an event stream which can handle abs or rel events. The Xorg 'evdev' driver is capable of consuming such absolute coords, so its merely neccessary to config X to use /dev/input/eventN instead of /dev/input/mice, and it will handle absolute coords correctly. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| From katzj at redhat.com Wed Mar 7 16:06:18 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 07 Mar 2007 11:06:18 -0500 Subject: Translations: String freezes, CVS converging, Packaging In-Reply-To: <45EDE4F0.4050500@glezos.com> References: <45EDE4F0.4050500@glezos.com> Message-ID: <1173283579.25055.19.camel@erebor.boston.redhat.com> On Tue, 2007-03-06 at 22:02 +0000, Dimitris Glezos wrote: > ## String freezes > > For F7, the RelEng team has introduced string freezes in the schedule [2]. This > means that application strings for F7 should be complete *by 19/3*. Translations > made after this date (and before the freeze) should be guaranteed to be included > in the release. > > [2]: http://fedoraproject.org/wiki/Core/Schedule Yep -- this should hopefully help a lot, although I expect it will take a release or two to fully institutionalize itself. We should probably have a procedure to be followed for cases where strings need to be changed. Here's a shot in the dark: String Freeze Policy. As of the string freeze date, translatable strings should not change to help ensure high quality translations for the Fedora 7 release. If you have a case where you need to change a string after this date, please send notification to fedora-trans-list. Alternately, we could make it a "get approval from the release team and then send notification", but I'm not sure if we want to go to that level for the first time through. Another important part is that if translators notice string changes after the string freeze, mail should be sent to the maintainer of the package and probably fedora-devel-list as well make sure they realize the problem. > To do this we need to try not to add new strings after the freeze and let the > L10n folks know if they need to do so. Also, maintainers should repackage before > each release (and after the translation freeze) without a bug needing to be > opened. Yep > ## CVS convergence > > Right now translations are done on `i18n.redhat.com`. This requires contributors > to have one account on the Fedora Account System (FAS) and a different > one for translations. With the merge of Core and Extras, now is a good > point to get rid of this distinction. > > The plan is to move all PO files on Fedora infrastructure under a new > CVS group (cvsl10n) [3]. An email will be sent to all translators to create a > FAS account if they don't have one and join the cvs group. Members of the L10n > team and ambassadors will help with this process. > > [3]: http://fedoraproject.org/wiki/L10N/Projects/CVSInfrastructure Does this also include moving the actual source that's hosted on elvis/i18n? If not, then I have very strong concerns... separating the source code from the translations has a lot of downsides as it requires a manual sync between the two. And these never work well :( > At this point we could discuss the idea for Fedora to act as upstream for > the translations of outside-hosted projects such as yum, smolt, and > pungi. The proposal is to host and maintain those project's > translations with the existing Fedora L10n community. See above :-) Although there's definitely a need for some problem solving here, as there is plenty of desire to have projects hosted in non-CVS SCMs as well. > ## Packaging translations > > One final plan (and probably the one that needs most discussion) is about > changing the way we package translations. Right now PO files live inside the > application and are packaged there (GNOME-style). The plan is to move the PO > files in to their own directory and distinct package [4] (KDE-style langpacks). > > [4]: http://fedoraproject.org/wiki/L10N/Projects/TranslationsPackage I'm very very very very strongly opposed to doing this. It's a nitemare from an installation point of view and also from a space point of view. The packages which do translations like this require absolutely horrible hacks within our software management stack to even have a *chance* of people getting the translations installed for their apps. Contrast to the apps which include the translations in the package... install the package and voila!, you have the translations for it. > Cons: L10n team should maintain a package (or many) and packages should be > altered to accomodate the different locations of PO files. Con: makes the source COMPLETELY divorced from the translations. So if I update an app and you don't update the translation package, all new strings aren't translated. Unless you push a new (massive) translation package. This does not scale. > Pros (many): increased modularity and maintenance (L10n repackages at > will). App packages will be smaller in size -- we could provide > one langpack or different ones per language. The size difference for most of the app packages are going to be negligible. But now, to push a new pirut with new strings, I also have to coordinate the pushing of n langpack packages. Which are each significantly larger than the amount you save on the app packages. Jeremy From kwade at redhat.com Wed Mar 7 16:58:33 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 07 Mar 2007 08:58:33 -0800 Subject: Translations: String freezes, CVS converging, Packaging In-Reply-To: <1173283579.25055.19.camel@erebor.boston.redhat.com> References: <45EDE4F0.4050500@glezos.com> <1173283579.25055.19.camel@erebor.boston.redhat.com> Message-ID: <1173286713.21816.23.camel@erato.phig.org> On Wed, 2007-03-07 at 11:06 -0500, Jeremy Katz wrote: > String Freeze Policy. As of the string freeze date, translatable > strings should not change to help ensure high quality translations for > the Fedora 7 release. If you have a case where you need to change a > string after this date, please send notification to fedora-trans-list. +1 Over the years, I've often heard that just receiving the notification of a string change is a miracle. If we can institutionalize this bit, it sounds like it will go far toward helping translators. Once it is in our processes, we might want to look at some automation of notification. At the least, when the CVS commit is made, we could add a *l10n* keyword (cf. *docs*) that sends the commit log to fedora-trans-list. If a string needs to be changed, then the change and notification of the L10n team happens in one move. > Alternately, we could make it a "get approval from the release team and > then send notification", but I'm not sure if we want to go to that level > for the first time through. Another important part is that if > translators notice string changes after the string freeze, mail should > be sent to the maintainer of the package and probably fedora-devel-list > as well make sure they realize the problem. +1 > > To do this we need to try not to add new strings after the freeze and let the > > L10n folks know if they need to do so. Also, maintainers should repackage before > > each release (and after the translation freeze) without a bug needing to be > > opened. > > Yep Can we look into automating this in some fashion? Not for F7, but for releases following? Or is that not necessary? > > ## CVS convergence > > > > Right now translations are done on `i18n.redhat.com`. This requires contributors > > to have one account on the Fedora Account System (FAS) and a different > > one for translations. With the merge of Core and Extras, now is a good > > point to get rid of this distinction. > > > > The plan is to move all PO files on Fedora infrastructure under a new > > CVS group (cvsl10n) [3]. An email will be sent to all translators to create a > > FAS account if they don't have one and join the cvs group. Members of the L10n > > team and ambassadors will help with this process. > > > > [3]: http://fedoraproject.org/wiki/L10N/Projects/CVSInfrastructure > > Does this also include moving the actual source that's hosted on > elvis/i18n? If not, then I have very strong concerns... separating the > source code from the translations has a lot of downsides as it requires > a manual sync between the two. And these never work well :( Sorry for my ignorance, but which source? The PO files? Or something more? The goal here is to stop using elvis.rh.c for the Fedora Translation project. If Red Hat's l10n team needs elvis for their work, then they need to work out how to sync back from cvs.fedoraproject.org. To state it more clearly, we are trying to move the PO files to the source code (in cvs.fedoraproject.org). Your comment makes it sound like the PO is already with the source? thx - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Wed Mar 7 17:20:32 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 7 Mar 2007 08:20:32 -0900 Subject: VNC development plan - discuss In-Reply-To: <1173255199.3280.19.camel@blaa> References: <45ED356D.7060204@redhat.com> <1173182009.3288.67.camel@blaa> <45ED5D45.2000903@redhat.com> <1173199226.19903.37.camel@greebo> <45ED9DC5.7000001@redhat.com> <1173201044.3288.211.camel@blaa> <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> <1173255199.3280.19.camel@blaa> Message-ID: <604aa7910703070920w21b1c77fx7d0f3b07d270fd4e@mail.gmail.com> On 3/6/07, Mark McLoughlin wrote: > Basically, the problem is that Vino just scrapes the contents of the > root window and exports that. So, if the screensaver is rendering to the > root window, then there's not much Vino can do. How does vino behave when fast user switching is on. Say I log into computer as user foo from local display, turn on vino, then walk away to a remote computer and activate the vnc session. User bar comes along and does a fast user switch to login to their account while local display is active, and user foo is still connected on it remotely via vino but inactive. What happens to user foo's vino session? Does it now display user bar's desktop? I'm sort of concerned. -jef"I really really really need to find the time to install a test2 instance and poke"spaleta From jkeating at redhat.com Wed Mar 7 17:22:45 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 7 Mar 2007 12:22:45 -0500 Subject: Translations: String freezes, CVS converging, Packaging In-Reply-To: <1173286713.21816.23.camel@erato.phig.org> References: <45EDE4F0.4050500@glezos.com> <1173283579.25055.19.camel@erebor.boston.redhat.com> <1173286713.21816.23.camel@erato.phig.org> Message-ID: <200703071222.45367.jkeating@redhat.com> On Wednesday 07 March 2007 11:58:33 Karsten Wade wrote: > Can we look into automating this in some fashion? ?Not for F7, but for > releases following? ?Or is that not necessary? I'm usually against any sort of automated non interactive package builds, especially for something that will land in the collection for release. Notifications can be sent out and there could be tracking of build status, but the actual build should be done by the maintainer or co-maintainer. > > > ## CVS convergence > > > > > > Right now translations are done on `i18n.redhat.com`. This requires > > > contributors to have one account on the Fedora Account System (FAS) and > > > a different one for translations. With the merge of Core and Extras, > > > now is a good point to get rid of this distinction. > > > > > > The plan is to move all PO files on Fedora infrastructure under a new > > > CVS group (cvsl10n) [3]. An email will be sent to all translators to > > > create a FAS account if they don't have one and join the cvs group. > > > Members of the L10n team and ambassadors will help with this process. > > > > > > ? [3]: http://fedoraproject.org/wiki/L10N/Projects/CVSInfrastructure > > > > Does this also include moving the actual source that's hosted on > > elvis/i18n? ?If not, then I have very strong concerns... ?separating the > > source code from the translations has a lot of downsides as it requires > > a manual sync between the two. ?And these never work well :( > > Sorry for my ignorance, but which source? ?The PO files? ?Or something > more? The source for the application that the PO files go with. > The goal here is to stop using elvis.rh.c for the Fedora Translation > project. ?If Red Hat's l10n team needs elvis for their work, then they > need to work out how to sync back from cvs.fedoraproject.org. > > To state it more clearly, we are trying to move the PO files to the > source code (in cvs.fedoraproject.org). ?Your comment makes it sound > like the PO is already with the source? There are many projects that use elvis as their entire upstream. anaconda, system-config-*, etc.. The source for the app and the translations are in the same place, and this is a very good and useful thing. Any strategy around making translations better needs to have a goal of keeping the translation source and the application source in the same SCM. -- 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 mclasen at redhat.com Wed Mar 7 17:30:59 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 07 Mar 2007 12:30:59 -0500 Subject: VNC development plan - discuss In-Reply-To: <604aa7910703070920w21b1c77fx7d0f3b07d270fd4e@mail.gmail.com> References: <45ED356D.7060204@redhat.com> <1173182009.3288.67.camel@blaa> <45ED5D45.2000903@redhat.com> <1173199226.19903.37.camel@greebo> <45ED9DC5.7000001@redhat.com> <1173201044.3288.211.camel@blaa> <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> <1173255199.3280.19.camel@blaa> <604aa7910703070920w21b1c77fx7d0f3b07d270fd4e@mail.gmail.com> Message-ID: <1173288659.3442.8.camel@localhost.localdomain> On Wed, 2007-03-07 at 08:20 -0900, Jeff Spaleta wrote: > On 3/6/07, Mark McLoughlin wrote: > > Basically, the problem is that Vino just scrapes the contents of the > > root window and exports that. So, if the screensaver is rendering to the > > root window, then there's not much Vino can do. > > How does vino behave when fast user switching is on. > Say I log into computer as user foo from local display, turn on vino, > then walk away > to a remote computer and activate the vnc session. > > User bar comes along and does a fast user switch to login to their > account while local display is active, and user foo is still connected > on it remotely via vino but inactive. > > What happens to user foo's vino session? Does it now display user > bar's desktop? I'm sort of concerned. > How should it ? The two sessions are not even using the same X server... From debarshi.ray at gmail.com Wed Mar 7 17:28:07 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Wed, 7 Mar 2007 22:58:07 +0530 Subject: A few ideas. Message-ID: <3170f42f0703070928v17afe1bfhff32e015b7d84e6c@mail.gmail.com> I have been using YUM (and Pirut) on various versions of Fedora Core for the past two or three years, and have some ideas to improve certain aspects of it. I apologise for the cross-posting, but I figure that this might be relevant to both the lists. 1. Enabling users to make 'yumpacks': This is inspired by https://wiki.ubuntu.com/OfflineUpdateSpec to enable users of YUM (and Pirut) to be able to install/update from packages downloaded on a different machine on a standalone offline machine or one with very harsh bandwidth constraints. Users having more than one machine, which are not on a LAN, can also be benefitted since they need not download the same things everywhere. It is true that the samething can be done using: a. yum deplist b. wget c. createrepo d. yum localinstall e. yum localupdate However for those who are not conversant with the working of YUM, Pirut, RPMs, dependencies, repositories, etc. will find it quite difficult to do it. With the growing popularity of GNU/Linux on the dektop, this is no longer a trivial issue. Some use cases can be: a. Manu has two machines-- one at work and one at home. The former is blessed with a nice Internet connection, while the other one is a standalone machine. Manu has just installed Fedora Core 6 on both his machines but does not really know much beyond 'yum install' and 'yum update', and his heavily dependant on the GUI since he is not a geek. He loves the system, and wants to install his favourite media player on his home machine. He has it on his office box, but the lack of Internet connectivity at home is a problem. He has read some material about making YUM repositories, but what he would love is a simple interface to do the whole thing. eg., "yum makepack " or a click and go feature in Pirut. Once the pack is made and saved in the desired location he can care it home on his pen-drive and enjoy the latest movie with his wife and kids. b. Rakesh has five different machines and they are not on the same LAN. Although both are connected to the Internet, the bandwidth is not of the best quality. Downloading the same updates and packages on both machines is quite a pain. He wants a simple facility by which he can create a 'yumpack' everytime he installs or updates something on one machine, so that he can use the same 'yumpack' to repeat the installation or update on his other boxes. c. My grandmother is fascinated by the talk of Free Software. She wants to try out Fedora. She does not know much about computers, and it is not possible to teach her about YUM caches, repositories, dependencies, etc.. She also finds it difficult to figure out what package to install using YUM and Pirut. I want to give her a 'yumpack' on a CD containing the packages she wants to have on her desktop, so that all she has to do is ask YUM or Pirut to install whatever is there in the pack. She just has to remember one command-- something like: "yum usepack ", and not "yum install ", "yum checkupdate", "yum -y update", etc.. 2. I recently learned that it is possible to download deltas of RPMs instead of the whole package. Exploiting this feature in YUM (and Pirut) can be extremely beneficial in conserving bandwidth and cache size. Making 'yumpacks' (see point 1) can will also become quicker and result in smaller packs being made, since one would not need to download and put the entire RPM in the pack if the currently installed version of the package is known. I have heard deltarpm does something like this, but have not come across something in YUM or Pirut which makes use of this. Some use cases: a. Arjun has a very slow connection to the Internet which is not available 24x7. Everytime he does "yum -y update", the slow network ensures that he has to keep his machine on for hours. Even then he experiences time-outs while downloading large packages (say >2M) and because the Internet is not available 24x7 this makes things more difficult for him. Arjun badly wants to circrumvent this problem. He wants to upgrade package 'foobar' and the RPM is 20M. However the only change as compared to the one he already has is a small, but critical segmentation fault problem. So it would be really good if he can somehow download a small diff and patch his installation using YUM (and Pirut). b. Ranjeet wants to give his brother all the latest RPMs in the updates repository. However they take up too much space to fit on a CD. Ranjeet does not have a DVD-RW drive so he has to use multiple CDs. Since his brother regularly updates his box, all that is needed are the diffs and not the entire packages. Ranjeet can make smaller repositories (or 'yumpacks') for his brother if he and his brother can use the diffs in YUM (and Pirut). 3. A "apt-get update" and "apt-get upgrade" combination for YUM and a 'refresh package information' for Pirut, so that the package information is updated only when explicitly stated by the user. However I do not know whether this is already available in YUM (and Pirut) or not. What I have learned is that the 'metadata_expire" value in yum.conf is used to decide when the meta-data is marked stale. The usual default setting of 1800s is too low and effectively every time someone starts YUM (or Pirut) it starts downloading the full package information from the remote servers. With the exception of extremely quick networks, this causes YUM to take a long time to actually start doing something. Pirut gives the impression of having hung or crashed. The more repositories you have enabled, the more enhanced is the problem, making these aplications (especially Pirut) almost unusable. Increasing the 'metadata_expire' value to something like 24*10*3600 can work, but for novices this is difficult to figure out and in my opinion is not an elegant solution. A use case: a. Vivek has just shifted to Fedora from Ubuntu/Debian. He tries out Pirut and is apalled by the amount of time it took to display the packages list. He badly misses the feature in Synaptic which enabled him to update his package information only when he desired to. Same applies for YUM too. Phew! That was long, but did I make any sense? Comments? I know Python and would love to help out in developing any of these features if you find them useful. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From markmc at redhat.com Wed Mar 7 17:48:44 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 07 Mar 2007 17:48:44 +0000 Subject: VNC development plan - discuss In-Reply-To: <604aa7910703070920w21b1c77fx7d0f3b07d270fd4e@mail.gmail.com> References: <45ED356D.7060204@redhat.com> <1173182009.3288.67.camel@blaa> <45ED5D45.2000903@redhat.com> <1173199226.19903.37.camel@greebo> <45ED9DC5.7000001@redhat.com> <1173201044.3288.211.camel@blaa> <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> <1173255199.3280.19.camel@blaa> <604aa7910703070920w21b1c77fx7d0f3b07d270fd4e@mail.gmail.com> Message-ID: <1173289724.21911.14.camel@blaa> On Wed, 2007-03-07 at 08:20 -0900, Jeff Spaleta wrote: > On 3/6/07, Mark McLoughlin wrote: > > Basically, the problem is that Vino just scrapes the contents of the > > root window and exports that. So, if the screensaver is rendering to the > > root window, then there's not much Vino can do. > > How does vino behave when fast user switching is on. > Say I log into computer as user foo from local display, turn on vino, > then walk away > to a remote computer and activate the vnc session. > > User bar comes along and does a fast user switch to login to their > account while local display is active, and user foo is still connected > on it remotely via vino but inactive. > > What happens to user foo's vino session? Does it now display user > bar's desktop? I'm sort of concerned. I dunno, I haven't looked at user switching lately. davidz might know ... I'm guessing user bar gets a new Xserver, and the screensaver runs on user foo's Xserver ... so someone connected to user foo's session over vino might see the screensaver. Not really sure, since the screensaver probably locks the display, you might just see the last thing on the screen before the screensaver ran. But then again, AFAIR Vino makes itself impervious to X display locking, so you might see the screensaver. Or maybe not. You could install test2 and give it a poke ... > -jef"I really really really need to find the time to install a test2 > instance and poke"spaleta Oh ... :-) Cheers, Mark. From tonynelson at georgeanelson.com Wed Mar 7 17:56:45 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Wed, 7 Mar 2007 12:56:45 -0500 Subject: Fedora safe/recovery mode In-Reply-To: <1173274322.3617.1.camel@max.booze> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> <87slcl6rdm.fsf@kosh.bigo.ensc.de> <20070304144522.GR3334@angus.ind.WPI.EDU> <20070304150103.GS3334@angus.ind.WPI.EDU> <1173101664.8128.8.camel@wombat.dlib.indiana.edu> <1173245187.3665.39.camel@max.booze> <878xe9ebma.fsf@kosh.bigo.ensc.de> <1173274322.3617.1.camel@max.booze> Message-ID: At 7:32 AM -0600 3/7/07, Callum Lerwick wrote: >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; > boundary="=-p0aK8RASXwZocxL5aiR+" > >On Wed, 2007-03-07 at 08:50 +0100, Enrico Scholz wrote: >> Callum Lerwick writes: >> > My idea was to just take the rescue CD, and install it unmodified in >> > to /boot. >> >> Ok with me. But please do not make this mandatory. My 32 MiB sized /boot >> will not have enough space for the rescue CD image. > >Last I checked, anaconda insisted on at least a 256mb /boot. So that's >kind of Your Problem(TM). In Anaconda partitions.py Partitions.sanityCheckAllRequests() I see that /boot must be at least 75 MB. -- ____________________________________________________________________ TonyN.:' ' From tonynelson at georgeanelson.com Wed Mar 7 17:55:35 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Wed, 7 Mar 2007 12:55:35 -0500 Subject: announce: readahead-1.4 In-Reply-To: <20070307135206.08f1cb6e@banea.int.addix.net> References: <20070301105026.GF4449@petra.dvoda.cz> <883cfe6d0703051442v2d74ebe8w6ef1764cd659cbd5@mail.gmail.com> <1173275392.3617.6.camel@max.booze> <20070307135206.08f1cb6e@banea.int.addix.net> Message-ID: At 1:52 PM +0100 3/7/07, Ralf Ertzinger wrote: >Hi. > >On Wed, 07 Mar 2007 07:49:52 -0600, Callum Lerwick wrote: > >> Seems like this newfangled flash crap is better used for journaling. >> >> Flash disks are generally slower than a sequential hard disk access. >> They're definitely slow for writing. I dunno WTF microsoft is >> thinking. > >Flash does not have seek times, which is a big plus for speeding >up the boot process. Microsoft already addressed that issue in WinXP, which has fancy hooks to the disk defragmenter so that there isn't much seeking when booting WinXP (it does take several days until the defrag happens). So I agree with Callum, and also dunno WTR MS is thinking. Probably readahead adopting what MS did in WinXP would be most effective but would also violate the most MS patents, as well as requiring hooking into the filesystem rather more than is wanted. Something like UnionFS might work without patent issues, if it could use a file instead of a hard partition. -- ____________________________________________________________________ TonyN.:' ' From katzj at redhat.com Wed Mar 7 18:02:47 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 07 Mar 2007 13:02:47 -0500 Subject: Translations: String freezes, CVS converging, Packaging In-Reply-To: <1173286713.21816.23.camel@erato.phig.org> References: <45EDE4F0.4050500@glezos.com> <1173283579.25055.19.camel@erebor.boston.redhat.com> <1173286713.21816.23.camel@erato.phig.org> Message-ID: <1173290567.25055.51.camel@erebor.boston.redhat.com> On Wed, 2007-03-07 at 08:58 -0800, Karsten Wade wrote: > On Wed, 2007-03-07 at 11:06 -0500, Jeremy Katz wrote: > > > To do this we need to try not to add new strings after the freeze and let the > > > L10n folks know if they need to do so. Also, maintainers should repackage before > > > each release (and after the translation freeze) without a bug needing to be > > > opened. > > > > Yep > > Can we look into automating this in some fashion? Not for F7, but for > releases following? Or is that not necessary? The problem is that you have to do a release bump (which is different for every package) as well as a run through the buildsystem. Doing these automatically is difficult at best. Plus, it can be a good excuse to go through the open bugs and hit any simple stupid low hanging fruit. > > > ## CVS convergence > > > > > > Right now translations are done on `i18n.redhat.com`. This requires contributors > > > to have one account on the Fedora Account System (FAS) and a different > > > one for translations. With the merge of Core and Extras, now is a good > > > point to get rid of this distinction. > > > > > > The plan is to move all PO files on Fedora infrastructure under a new > > > CVS group (cvsl10n) [3]. An email will be sent to all translators to create a > > > FAS account if they don't have one and join the cvs group. Members of the L10n > > > team and ambassadors will help with this process. > > > > > > [3]: http://fedoraproject.org/wiki/L10N/Projects/CVSInfrastructure > > > > Does this also include moving the actual source that's hosted on > > elvis/i18n? If not, then I have very strong concerns... separating the > > source code from the translations has a lot of downsides as it requires > > a manual sync between the two. And these never work well :( > > Sorry for my ignorance, but which source? The PO files? Or something > more? More. All of the source for anaconda, pirut and all[1] of the apps being translated here are on elvis.redhat.com also. In the exact same source repository. cvs -d:pserver:anonymous at elvis.redhat.com:/usr/local/CVS co anaconda Look in the po dir. Then, check out the translate directory. Hey, all the po files of all the modules on elvis in all the languages. This is purely done through a (ugly as sin) CVSROOT/modules file. > The goal here is to stop using elvis.rh.c for the Fedora Translation > project. If Red Hat's l10n team needs elvis for their work, then they > need to work out how to sync back from cvs.fedoraproject.org. If we stop using elvis for Fedora Translations, then how are we intending to actually provide the translations to the sources on elvis? > To state it more clearly, we are trying to move the PO files to the > source code (in cvs.fedoraproject.org). Your comment makes it sound > like the PO is already with the source? It *IS* for the majority of stuff on elvis Jeremy [1] With the exception of some things like up2date and a few other weird RHEL-isms. From jspaleta at gmail.com Wed Mar 7 18:09:08 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 7 Mar 2007 09:09:08 -0900 Subject: VNC development plan - discuss In-Reply-To: <1173288659.3442.8.camel@localhost.localdomain> References: <45ED356D.7060204@redhat.com> <1173182009.3288.67.camel@blaa> <45ED5D45.2000903@redhat.com> <1173199226.19903.37.camel@greebo> <45ED9DC5.7000001@redhat.com> <1173201044.3288.211.camel@blaa> <604aa7910703061042q7fac1fb7u1b1fd4ae4bccef49@mail.gmail.com> <1173255199.3280.19.camel@blaa> <604aa7910703070920w21b1c77fx7d0f3b07d270fd4e@mail.gmail.com> <1173288659.3442.8.camel@localhost.localdomain> Message-ID: <604aa7910703071009l3e979314r33579bd1596d13e@mail.gmail.com> On 3/7/07, Matthias Clasen wrote: > How should it ? The two sessions are not even using the same X server... Right sorry, I really need to get my own test install up and running to avoid asking questions I can answer for myself.. because my next question is. But since I'm lazy.. and I'm already thinking about it... the next question is: If fast user switching enables the screen lock on foo's Xserver when bar's Xserver starts up, does that automatically lock the screen for foo's vino session as well even if its being actively used remotely. -jef"and more importantly... how do you dogtail this test :->"spaleta From poelstra at redhat.com Wed Mar 7 18:25:45 2007 From: poelstra at redhat.com (John Poelstra) Date: Wed, 07 Mar 2007 10:25:45 -0800 Subject: freeze during install In-Reply-To: <45EE83FC.4000501@laposte.net> References: <45EE83FC.4000501@laposte.net> Message-ID: <45EF03A9.6030904@redhat.com> Axel said the following on 03/07/2007 01:21 AM Pacific Time: > I downloaded boot iso from ftp.crihan.fr mirror and tried to make a > fresh install of FC7. Boot goes well and installation wizard starts > without problem. > After the dependancies computation and the / & swap format the install > stop. No "lock", GUI can be use but the install waits with a progress > bar which doesn'nt progress anymore. > > In one of the tty I see the message "No handler could be found for > yum.Yumbase" or something like that. > > Is that a known problem for test 2 or maybe I forgot something ? > https://www.redhat.com/archives/fedora-announce-list/2007-March/msg00000.html updates-f7t2.img fixed the problem for me. John From kwade at redhat.com Wed Mar 7 17:36:49 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 07 Mar 2007 09:36:49 -0800 Subject: Translations: String freezes, CVS converging, Packaging In-Reply-To: <200703071222.45367.jkeating@redhat.com> References: <45EDE4F0.4050500@glezos.com> <1173283579.25055.19.camel@erebor.boston.redhat.com> <1173286713.21816.23.camel@erato.phig.org> <200703071222.45367.jkeating@redhat.com> Message-ID: <1173289009.21816.32.camel@erato.phig.org> On Wed, 2007-03-07 at 12:22 -0500, Jesse Keating wrote: > On Wednesday 07 March 2007 11:58:33 Karsten Wade wrote: > > Can we look into automating this in some fashion? Not for F7, but for > > releases following? Or is that not necessary? > > I'm usually against any sort of automated non interactive package builds, > especially for something that will land in the collection for release. > Notifications can be sent out and there could be tracking of build status, > but the actual build should be done by the maintainer or co-maintainer. OK, thanks. > There are many projects that use elvis as their entire upstream. anaconda, > system-config-*, etc.. The source for the app and the translations are in > the same place, and this is a very good and useful thing. Any strategy > around making translations better needs to have a goal of keeping the > translation source and the application source in the same SCM. OK, this was the part I didn't understand; I thought elvis CVS only held translation files. Our plan was to start by moving over documentation PO files to go with the source in cvs.fedoraproject.org. Then follow that with whatever else we can. What is the plan with moving these projects SCM to fedoraproject.org? Not going to happen until after F7? - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- 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 kwade at redhat.com Wed Mar 7 18:53:45 2007 From: kwade at redhat.com (Karsten Wade) Date: Wed, 07 Mar 2007 10:53:45 -0800 Subject: Translations: String freezes, CVS converging, Packaging In-Reply-To: <1173290567.25055.51.camel@erebor.boston.redhat.com> References: <45EDE4F0.4050500@glezos.com> <1173283579.25055.19.camel@erebor.boston.redhat.com> <1173286713.21816.23.camel@erato.phig.org> <1173290567.25055.51.camel@erebor.boston.redhat.com> Message-ID: <1173293625.21816.37.camel@erato.phig.org> On Wed, 2007-03-07 at 13:02 -0500, Jeremy Katz wrote: > On Wed, 2007-03-07 at 08:58 -0800, Karsten Wade wrote: > > The goal here is to stop using elvis.rh.c for the Fedora Translation > > project. If Red Hat's l10n team needs elvis for their work, then they > > need to work out how to sync back from cvs.fedoraproject.org. > > If we stop using elvis for Fedora Translations, then how are we > intending to actually provide the translations to the sources on elvis? > > > To state it more clearly, we are trying to move the PO files to the > > source code (in cvs.fedoraproject.org). Your comment makes it sound > > like the PO is already with the source? > > It *IS* for the majority of stuff on elvis OK, I finally get this now. Long discussion on #fedora-admin helped, too. Therefore, I think we are adding to the proposal the moving of all software projects off elvis. There has been endless talk about this for ... uh, 36 months? Is there a reason we cannot do this now? - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- 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 thomas.canniot at laposte.net Wed Mar 7 17:31:24 2007 From: thomas.canniot at laposte.net (Thomas Canniot) Date: Wed, 07 Mar 2007 18:31:24 +0100 Subject: Translations: String freezes, CVS converging, Packaging In-Reply-To: <1173283579.25055.19.camel@erebor.boston.redhat.com> References: <45EDE4F0.4050500@glezos.com> <1173283579.25055.19.camel@erebor.boston.redhat.com> Message-ID: <1173288684.3524.6.camel@localhost.localdomain> Le mercredi 07 mars 2007 ? 11:06 -0500, Jeremy Katz a ?crit : [snip] > > > ## Packaging translations > > > > One final plan (and probably the one that needs most discussion) is about > > changing the way we package translations. Right now PO files live inside the > > application and are packaged there (GNOME-style). The plan is to move the PO > > files in to their own directory and distinct package [4] (KDE-style langpacks). > > > > [4]: http://fedoraproject.org/wiki/L10N/Projects/TranslationsPackage > > I'm very very very very strongly opposed to doing this. It's a nitemare > from an installation point of view and also from a space point of view. > The packages which do translations like this require absolutely horrible > hacks within our software management stack to even have a *chance* of > people getting the translations installed for their apps. Contrast to > the apps which include the translations in the package... install the > package and voila!, you have the translations for it. > [snip] Ok it may be a nightmare but it tries to solve the following problem: when a translation is made too late after the creation of the new package before an update (let's say during the life cycle of the distro), it has very little chance to be included before the next release of fedora. Generally, the answer is "Thanks, I push your translation in the NEXT rebuild" (in other words, "Too late guy, wait some more weeks or months). Fedora upstream software are not being repackaged every day and pushed as updates. By maintaining our own langpack, translators can translate whenever they want and especially whenever they can. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From katzj at redhat.com Wed Mar 7 19:10:00 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 07 Mar 2007 14:10:00 -0500 Subject: Translations: String freezes, CVS converging, Packaging In-Reply-To: <1173288684.3524.6.camel@localhost.localdomain> References: <45EDE4F0.4050500@glezos.com> <1173283579.25055.19.camel@erebor.boston.redhat.com> <1173288684.3524.6.camel@localhost.localdomain> Message-ID: <1173294600.25055.93.camel@erebor.boston.redhat.com> On Wed, 2007-03-07 at 18:31 +0100, Thomas Canniot wrote: > Le mercredi 07 mars 2007 ? 11:06 -0500, Jeremy Katz a ?crit : > [snip] > > > ## Packaging translations > > > > > > One final plan (and probably the one that needs most discussion) is about > > > changing the way we package translations. Right now PO files live inside the > > > application and are packaged there (GNOME-style). The plan is to move the PO > > > files in to their own directory and distinct package [4] (KDE-style langpacks). > > > > > > [4]: http://fedoraproject.org/wiki/L10N/Projects/TranslationsPackage > > > > I'm very very very very strongly opposed to doing this. It's a nitemare > > from an installation point of view and also from a space point of view. > > The packages which do translations like this require absolutely horrible > > hacks within our software management stack to even have a *chance* of > > people getting the translations installed for their apps. Contrast to > > the apps which include the translations in the package... install the > > package and voila!, you have the translations for it. > > [snip] > > Ok it may be a nightmare but it tries to solve the following problem: > when a translation is made too late after the creation of the new > package before an update (let's say during the life cycle of the > distro), it has very little chance to be included before the next > release of fedora. Generally, the answer is "Thanks, I push your > translation in the NEXT rebuild" (in other words, "Too late guy, wait > some more weeks or months). Fedora upstream software are not being > repackaged every day and pushed as updates. By maintaining our own > langpack, translators can translate whenever they want and especially > whenever they can. By the same argument, I should get to change strings whenever I want/whenever I can and not stick to a freeze schedule. We have to get to where we do a better job of sticking to our schedules -- both for freezes to strings so that translators can have adequate time for translating the software and hitting a "translations completed, do a rebuild" milestone. It's a growing pain but I don't see how we sanely scale things otherwise. The third part is probably coming up with a good way of coordinating rebuilds of things which we host, maintain and are the upstream for so that translation updates can go out in a more timely fashion. Jeremy From mattdm at mattdm.org Wed Mar 7 19:18:20 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 7 Mar 2007 14:18:20 -0500 Subject: speaking of time zones -- syslogd 1.4.1 timezone behavior odd.... Message-ID: <20070307191820.GA1342@jadzia.bu.edu> The frenzy of people auditing their systems for timezone-change compliance has brought this to my attention. One deficiency of the syslog format is that it doesn't record the timezone (particularly annoying around the DST change). But to compound this, the datestamp recorded from local syslog calls is apparently based on whatever the calling client has their timezone set as. Thus, you can do: TZ="UTC+23:56" logger "Look! I'm logging from yesterday!" if you want. Apparently, there's a patch for this behavior in the perennially not released sysklogd 1.4.2 (what's up with that?). I think we should consider backporting this to Fedora. Comments? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mandreiana.lists at gmail.com Wed Mar 7 21:17:06 2007 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Wed, 07 Mar 2007 23:17:06 +0200 Subject: VNC development plan - discuss In-Reply-To: <45ED9DC5.7000001@redhat.com> References: <45ED356D.7060204@redhat.com> <1173182009.3288.67.camel@blaa> <45ED5D45.2000903@redhat.com> <1173199226.19903.37.camel@greebo> <45ED9DC5.7000001@redhat.com> Message-ID: <1173302227.2157.8.camel@localhost.localdomain> On Tue, 2007-03-06 at 17:58 +0100, Adam Tkac wrote: > Alexander Larsson napsal(a): > > On Tue, 2007-03-06 at 13:23 +0100, Adam Tkac wrote: > > > >> Mark McLoughlin napsal(a): > >> > >>> vino and krfb have different goals and UIs that are designed to be well > >>> integrated into their respective environments. I don't think merging the > >>> two makes any more sense than e.g. merging evolution and kmail because > >>> they both talk the SMTP protocol. > >>> > >>> > >> I don't think that integrating to specified environment is useful in > >> this case. In my opinion kde & gnome use same xserver with same policies > >> so vino and krfb (and x11vnc) is more about xserver than about specific > >> UIs. This is main argument why could be these programs merged to one. It > >> is very easy write simple GUI with two buttons - "start remote desktop" > >> and "stop remote desktop" - which could works under gnome and kde and > >> other window managers. > >> > > > > How is it not important that they are properly integrated into the > > desktop? Your proposal sounds very simple and ugly compared to the slick > > integration of e.g. vino. > > > > > I don't said that integration is unimportant. I said that both of krfb > and vino is much more about xserver than about window manager. Only one > think could be integrated with specified window manager - button "start > remote desktop" and "stop remote desktop". That's not good enough. Vino is not only a vnc server, but also tightly integrated with the desktop. I can tell somebody over the phone 'Go to Preferences - Remote Desktop, enable it, enter a password, show notifications, allow shared control etc' rather than 'Alt+F2, gnome- -terminal, edit some files to setup your password then open an application to click start remote desktop.' My non-tech sister was able to handle the 1st option. As Mark and others said, a common library between vino and krfb on freedesktop.org is the way if you want to reduce the code qty. Maybe it can also be used by clients like tsclient. -- Marius Andreiana http://marius.andreiana.googlepages.com From seg at haxxed.com Wed Mar 7 22:38:56 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 07 Mar 2007 16:38:56 -0600 Subject: Fedora safe/recovery mode In-Reply-To: References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87tzx2rygs.fsf@kosh.bigo.ensc.de> <87slcl6rdm.fsf@kosh.bigo.ensc.de> <20070304144522.GR3334@angus.ind.WPI.EDU> <20070304150103.GS3334@angus.ind.WPI.EDU> <1173101664.8128.8.camel@wombat.dlib.indiana.edu> <1173245187.3665.39.camel@max.booze> <878xe9ebma.fsf@kosh.bigo.ensc.de> <1173274322.3617.1.camel@max.booze> Message-ID: <1173307136.3617.55.camel@max.booze> On Wed, 2007-03-07 at 12:56 -0500, Tony Nelson wrote: > In Anaconda partitions.py Partitions.sanityCheckAllRequests() I see that > /boot must be at least 75 MB. arghrragrhrahrhrhrahrhgrh I'm apparently smoking crack Any chance of slimming the rescue disk down? Its currently ~85mb. ;P And if this honestly is a Good Idea, perhaps anaconda should start demanding a ~200mb /boot in FC7 so at least new installs will have space in the future. Dealing with old installs will be... somewhat problematic. Personally I want SystemRescueCd in my /boot too, that's 121mb. 121+85 = 206. 256mb should 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 pemboa at gmail.com Wed Mar 7 21:28:31 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 7 Mar 2007 15:28:31 -0600 Subject: Fedora safe/recovery mode In-Reply-To: <1173307136.3617.55.camel@max.booze> References: <16de708d0703012104i3b9e887pd7aa351b9cb5ff4d@mail.gmail.com> <87slcl6rdm.fsf@kosh.bigo.ensc.de> <20070304144522.GR3334@angus.ind.WPI.EDU> <20070304150103.GS3334@angus.ind.WPI.EDU> <1173101664.8128.8.camel@wombat.dlib.indiana.edu> <1173245187.3665.39.camel@max.booze> <878xe9ebma.fsf@kosh.bigo.ensc.de> <1173274322.3617.1.camel@max.booze> <1173307136.3617.55.camel@max.booze> Message-ID: <16de708d0703071328h107acdc1w530b219a7681307f@mail.gmail.com> On 3/7/07, Callum Lerwick wrote: > On Wed, 2007-03-07 at 12:56 -0500, Tony Nelson wrote: > > In Anaconda partitions.py Partitions.sanityCheckAllRequests() I see that > > /boot must be at least 75 MB. > > arghrragrhrahrhrhrahrhgrh I'm apparently smoking crack > > Any chance of slimming the rescue disk down? Its currently ~85mb. ;P > > And if this honestly is a Good Idea, perhaps anaconda should start > demanding a ~200mb /boot in FC7 so at least new installs will have space > in the future. Dealing with old installs will be... somewhat > problematic. > > Personally I want SystemRescueCd in my /boot too, that's 121mb. > 121+85 = 206. 256mb should do... > Seems like this should be at least an option when installing: "Do you want to install a failsafe mode? yes|no" -- Fedora Core 6 and proud From mmcgrath at redhat.com Wed Mar 7 21:33:06 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 07 Mar 2007 15:33:06 -0600 Subject: Extras pushes In-Reply-To: <45EDE808.80508@redhat.com> References: <45EDE808.80508@redhat.com> Message-ID: <45EF2F92.3030609@redhat.com> Everything seems to be working now. The RH Mirror now gets signed packages directly from the build master. Let someone in the infrastructure team know if anything is amiss. -Mike Mike McGrath wrote: > Extras pushes are on hold for the moment while we re-order the push > process. It should be transparent to both the users and the pushers > when its back online. We're expecting it to be back up and running > later tonight or early tomorrow. > > -Mike > From buildsys at redhat.com Wed Mar 7 21:53:17 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 7 Mar 2007 16:53:17 -0500 Subject: rawhide report: 20070307 changes Message-ID: <200703072153.l27LrHoF020096@hs20-bc2-6.build.redhat.com> Updated Packages: anaconda-11.2.0.31-1 -------------------- * Tue Mar 06 2007 David Cantrell - 11.2.0.31-1 - Smaller required height for main window for livecd installs (katzj) - Move utility functions around in isys - Init loopback in stage 1 using ioctl() rather than netlink (#229670) - Handle netlink messages for RTM_GETLINK that are larger than 4K (#230525) * Mon Mar 05 2007 Jeremy Katz - 11.2.0.30-1 - ext2 is a module now - add a basic boot drive selector to the graphical autopartitioning screen bind-31:9.4.0-1.fc7 ------------------- * Tue Mar 06 2007 Adam Tkac 31:9.4.0-1.fc7 - updated to 9.4.0 - bind-chroot-admin now sets EAs correctly (#213926) - throw away next_server_on_referral and no_servfail_stops patches (fixed in 9.4.0) cairo-1.4.0-1.fc7 ----------------- * Tue Mar 06 2007 Carl Worth 1.4.0-1 - Update to 1.4.0 * Wed Feb 14 2007 Carl Worth 1.3.14-1 - Update to 1.3.14 * Sat Jan 20 2007 Carl Worth 1.3.12-1 - Update to 1.3.12 diffstat-1.43-3.fc7 ------------------- * Tue Mar 06 2007 Tim Waugh 1.43-3 - Fixed source0 (bug #225695). - Added COPYING file, taken from diffstat.c. * Tue Mar 06 2007 Tim Waugh 1.43-2 - Fixed buildroot (bug #225695). - Build should not require gzip or bzip2 as these are exceptions (bug #225695). - Added SMP make flags (bug #225695). - Avoid makeinstall macro (bug #225695). - Better defattr (bug #225695). - Fixed summary (bug #225695). - Avoid macros in changelog (bug #225695). emacs-22.0.95-1.fc7 ------------------- * Tue Mar 06 2007 Chip Coldwell - 22.0.95-1 - new pretest tarball from FSF * Mon Feb 26 2007 Chip Coldwell - 22.0.94-1 - new pretest tarball obsoletes loaddefs.el dependencies patch esc-1.0.1-1.fc7 --------------- * Mon Mar 05 2007 Jack Magne - 1.0.0-1 - Stability fixes evolution-data-server-1.9.92-2.fc7 ---------------------------------- * Tue Mar 06 2007 Matthew Barnes - 1.9.92-2.fc7 - Add patch for GNOME bug #301363 (update timezones). gdm-1:2.17.8-2.fc7 ------------------ * Tue Mar 06 2007 Ray Strode - 1:2.17.8-2 - turn off pam sanity check because it conflicts with audit gnome-panel-2.17.92-2.fc7 ------------------------- * Tue Mar 06 2007 Alexander Larsson - 2.17.92-1 - Add xdg-user-dirs patch gnome-user-share-0.11-1.fc7 --------------------------- * Tue Mar 06 2007 Alexander Larsson - 0.11-1 - Update to 0.11 with xdg-user-dirs support htdig-3:3.2.0b6-11.fc7 ---------------------- * Wed Mar 07 2007 Adam Tkac 3:3.2.0b6-11.fc7 - added upstream's segfault patch - added ?_smp_mflags macro to make kdebase-6:3.5.6-3.fc7 --------------------- * Tue Mar 06 2007 Than Ngo - 6:3.5.6-3.fc7 - cleanup specfile * Wed Feb 14 2007 Than Ngo - 6:3.5.6-2.fc7 - make konsole binary sgid utempter #213369 kdeedu-3.5.6-2.fc7 ------------------ * Tue Mar 06 2007 Than Ngo - 3.5.6-2.fc7 - cleanup kdegames-6:3.5.6-2.fc7 ---------------------- * Tue Mar 06 2007 Than Ngo - 6:3.5.6-2.fc7 - cleanup kdelibs-6:3.5.6-2.fc7 --------------------- * Tue Feb 27 2007 Than Ngo - 6:3.5.5-2.fc7 - cleanup specfile kernel-2.6.20-1.2967.fc7 ------------------------ kexec-tools-1.101-62.fc7 ------------------------ * Tue Mar 06 2007 Neil Horman - 1.101-62.fc7 - Updating makedumpfile to version 1.1.1 (bz 2223743) * Thu Feb 22 2007 Neil Horman - 1.101-61.fc7 - Adding multilanguage infrastructure to firstboot_kdump (bz 223175) libXdamage-1.1-1.fc7 -------------------- * Mon Mar 05 2007 Adam Jackson 1.1-1 - libXdamage 1.1 libgconf-java-2.12.4-7.fc7 -------------------------- * Mon Mar 05 2007 Stepan Kasal - 2.12.4-7 - Add patch for gcjh -> gjavah; touch aclocal.m4, configure, Makefile.in after applying it. - Force -fPIC and avoid -Wall with gcj/ecj. * Wed Feb 21 2007 Andrew Overholt 2.12.4-6 - Rebuild for new gcj. libglade-java-2.12.5-6.fc7 -------------------------- * Mon Mar 05 2007 Stepan Kasal - 2.12.5-6 - Add patch for gcjh -> gjavah; touch aclocal.m4, configure, Makefile.in after applying it. - Force -fPIC and avoid -Wall with gcj/ecj. * Wed Feb 21 2007 Andrew Overholt 2.12.5-5 - Rebuild for new gcj. libgnome-java-2.12.4-6.fc7 -------------------------- * Mon Mar 05 2007 Stepan Kasal - 2.12.4-6 - Add patch for gcjh -> gjavah; touch aclocal.m4, configure, Makefile.in after applying it. - Force -fPIC and avoid -Wall with gcj/ecj. * Wed Feb 21 2007 Andrew Overholt 2.12.4-5 - Rebuild for new gcj. libvte-java-0.12.1-7.fc7 ------------------------ * Mon Mar 05 2007 Stepan Kasal - 0.12.1-7 - Add patch for gcjh -> gjavah; touch aclocal.m4, configure, Makefile.in after applying it. - Force -fPIC and avoid -Wall with gcj/ecj. * Wed Feb 21 2007 Andrew Overholt 0.12.1-6 - Rebuild for new gcj. nautilus-2.17.92-3.fc7 ---------------------- * Tue Mar 06 2007 Alexander Larsson - 2.17.92-3 - Update xdg-user-dirs patch, now handle renaming desktop dir nfs-utils-1:1.0.12-1.fc7 ------------------------ * Tue Mar 06 2007 Steve Dickson 1.0.12-1 - Upgraded to 1.0.12 * Thu Mar 01 2007 Karel Zak 1.0.11-2 - Fixed mount.nfs -f (fake) option (bz 227988) * Thu Feb 22 2007 Steve Dickson 1.0.11-1 - Upgraded to 1.0.11 php-pear-1:1.5.0-3 ------------------ * Tue Mar 06 2007 Joe Orton 1:1.5.0-3 - add redundant build section (#226295) - BR php-cli not php (#226295) spamassassin-3.2.0-0.2.pre2.fc7 ------------------------------- * Tue Mar 06 2007 Warren Togami 3.2.0-0.2.pre2 - Conditional to require perl-devel during build for FC7+ (#226276) * Fri Mar 02 2007 Warren Togami 3.2.0-0.1.pre2 - 3.2.0-pre2 sysreport-1.4.3-10 ------------------ * Tue Mar 06 2007 Than Ngo - 1.4.3-10 - Getting information about printcap ttcp-1.12-15.fc7 ---------------- * Tue Mar 06 2007 Marcela Maslanova - 1.12-15 - merge review - rhbz#226505 xfsprogs-2.8.18-3.fc7 --------------------- * Tue Mar 06 2007 Miroslav Lichvar 2.8.18-3 - Remove libtermcap-devel from BuildRequires Broken deps for i386 ---------------------------------------------------------- frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.i386 requires xdg-utils Broken deps for x86_64 ---------------------------------------------------------- frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.x86_64 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.x86_64 requires xdg-utils Broken deps for ia64 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ia64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ia64 requires xdg-utils net-snmp-devel - 1:5.4-10.fc7.ia64 requires lm_sensors-devel Broken deps for ppc64 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ppc64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ppc64 requires xdg-utils net-snmp-devel - 1:5.4-10.fc7.ppc64 requires lm_sensors-devel Broken deps for s390 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390 requires xdg-utils net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel 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 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ppc requires libofx.so.3 gnucash - 2.0.5-1.fc6.ppc requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.ppc requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ppc requires xdg-utils net-snmp-devel - 1:5.4-10.fc7.ppc requires lm_sensors-devel Broken deps for s390x ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.s390x requires libofx.so.3()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.s390x requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390x requires xdg-utils net-snmp-devel - 1:5.4-10.fc7.s390x requires lm_sensors-devel net-snmp-devel - 1:5.4-10.fc7.s390 requires lm_sensors-devel From notting at redhat.com Wed Mar 7 22:07:41 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Mar 2007 17:07:41 -0500 Subject: umask in rpm scriptlets - yes or no? In-Reply-To: References: <20070304133421.94f858e1.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070307220741.GD25018@nostromo.devel.redhat.com> Rex Dieter (rdieter at math.unl.edu) said: > > Does anybody know whether anything has been decided on setting an > > explicit "umask 022" at the beginning of scriptlets? > > Looks like it's not a bad idea. I would strongly suggest that this is something that is best enforced in rpm itself rather than in every scriplet. Bill From rdieter at math.unl.edu Wed Mar 7 22:35:51 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 07 Mar 2007 16:35:51 -0600 Subject: umask in rpm scriptlets - yes or no? In-Reply-To: <20070307220741.GD25018@nostromo.devel.redhat.com> References: <20070304133421.94f858e1.mschwendt.tmp0701.nospam@arcor.de> <20070307220741.GD25018@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > Rex Dieter (rdieter at math.unl.edu) said: >>> Does anybody know whether anything has been decided on setting an >>> explicit "umask 022" at the beginning of scriptlets? >> Looks like it's not a bad idea. > I would strongly suggest that this is something that is best enforced > in rpm itself rather than in every scriplet. Even better, sure. -- Rex From bart.vanbrabant at zoeloelip.be Wed Mar 7 22:19:12 2007 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Wed, 07 Mar 2007 23:19:12 +0100 Subject: rawhide report: 20070306 changes In-Reply-To: <200703061138.l26Bcrj2012027@hs20-bc2-6.build.redhat.com> References: <200703061138.l26Bcrj2012027@hs20-bc2-6.build.redhat.com> Message-ID: <45EF3A60.7070806@zoeloelip.be> > xorg-x11-server-1.2.99.901-1.fc7 > -------------------------------- > * Mon Mar 05 2007 Adam Jackson 1.2.99.901-1 > - xserver 1.3 RC1. RANDR 1.2 hotness in the hizzouse. > - xserver-1.2.0-honor-displaysize.patch: Honor the DisplaySize config > directive again (#220248) > - Clean up the post-install cleanup > > * Fri Mar 02 2007 Adam Tkac 1.2.0-10 > - change permissions of files in source package to default from read-only > > * Mon Feb 26 2007 Adam Tkac 1.2.0-9 > - Created new package (xorg-x11-server-source) which is needed to build VNC > server. This update killed the nouveau driver. Any chance it will be updated to the xrandr-1.2 branch? 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 seg at haxxed.com Wed Mar 7 23:38:29 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 07 Mar 2007 17:38:29 -0600 Subject: announce: readahead-1.4 In-Reply-To: References: <20070301105026.GF4449@petra.dvoda.cz> <883cfe6d0703051442v2d74ebe8w6ef1764cd659cbd5@mail.gmail.com> <1173275392.3617.6.camel@max.booze> <20070307135206.08f1cb6e@banea.int.addix.net> Message-ID: <1173310709.3617.84.camel@max.booze> On Wed, 2007-03-07 at 12:55 -0500, Tony Nelson wrote: > Microsoft already addressed that issue in WinXP, which has fancy hooks to > the disk defragmenter so that there isn't much seeking when booting WinXP > (it does take several days until the defrag happens). So I agree with > Callum, and also dunno WTR MS is thinking. > > Probably readahead adopting what MS did in WinXP would be most effective > but would also violate the most MS patents, as well as requiring hooking > into the filesystem rather more than is wanted. Something like UnionFS > might work without patent issues, if it could use a file instead of a hard > partition. I don't see how they could patent defragging a disk. Lets not get crazy here. ext3 does a decent job of not fragmenting files unnecessarily, can we really gain much more than the current readahead solution? Instead of reaching for more and more convoluted hacks, lets do it right. Seems to me the only real gain to be found is in having performance critical files clustered together in the start of the partition, where the disk is typically faster. Food for thought, check out Apple's HotFile implementation: http://developer.apple.com/technotes/tn/tn1150.html#HotFile Doing something like this on ext3 should be possible. We could designate the first ext3 block group (actually should make the number configurable) as the "hot" area. Patch the kernel so it avoids doing any allocations in the "hot" group(s) except as a last resort. Then write a tool to move files into the "hot" area somehow, possibly with help from the kernel. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Wed Mar 7 22:41:17 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Mar 2007 17:41:17 -0500 Subject: Frozen feature list for FC7 In-Reply-To: <45EE108C.2000508@redhat.com> References: <45EE0D47.7000201@redhat.com> <45EE108C.2000508@redhat.com> Message-ID: <20070307224117.GG25018@nostromo.devel.redhat.com> > Good catch. The feature freeze was moved to Test3 and a Test4 was since > added. Strangely though, I can't seem to figure out how to edit the > page to make a seemingly simple correction. It might just be the oxygen > deprivation to my brain... Fixed. Bill From david at fubar.dk Wed Mar 7 22:46:32 2007 From: david at fubar.dk (David Zeuthen) Date: Wed, 07 Mar 2007 17:46:32 -0500 Subject: announce: readahead-1.4 In-Reply-To: <1173310709.3617.84.camel@max.booze> References: <20070301105026.GF4449@petra.dvoda.cz> <883cfe6d0703051442v2d74ebe8w6ef1764cd659cbd5@mail.gmail.com> <1173275392.3617.6.camel@max.booze> <20070307135206.08f1cb6e@banea.int.addix.net> <1173310709.3617.84.camel@max.booze> Message-ID: <1173307592.2631.80.camel@zelda.fubar.dk> On Wed, 2007-03-07 at 17:38 -0600, Callum Lerwick wrote: > Lets not get crazy > here. ext3 does a decent job of not fragmenting files unnecessarily, can > we really gain much more than the current readahead solution? Yes we can. See point 8. of http://www.redhat.com/archives/fedora-devel-list/2004-November/msg01374.html > We could designate the first ext3 block group (actually should make the > number configurable) as the "hot" area. Patch the kernel so it avoids > doing any allocations in the "hot" group(s) except as a last resort. > Then write a tool to move files into the "hot" area somehow, possibly > with help from the kernel. It's been two and half years ago since I showed that even a poor hack of "defragging" the file system makes booting around 15-20 seconds faster and I'd be surprised if the same isn't true today. It would be useful if some of the ext3 developers actually read fedora-devel-list and commented on this. David From notting at redhat.com Wed Mar 7 22:50:23 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Mar 2007 17:50:23 -0500 Subject: Translations: String freezes, CVS converging, Packaging In-Reply-To: <45EDE4F0.4050500@glezos.com> References: <45EDE4F0.4050500@glezos.com> Message-ID: <20070307225023.GB22202@nostromo.devel.redhat.com> Dimitris Glezos (dimitris at glezos.com) said: > We have two options: one, to have a big `fedora-langpack.rpm` and the other to > split it in different languages (`fedora-langpack-de.rpm` etc). (if you're on fedora-trans, you've already seen this) As an application author and user, I find this to be a remarkably bad idea. 1) It divorces the translation from the application, making string changes => .po file non-automatic. 2) It ties all the translated applications together as a whole, making it impossible for single applications to be logically extracted for other people to pull from, whether it's another distribution or another project. 3) It wastes space for anyone that wants to install a subset of the package space. 4) It ties all the translated applications together as a whole when they have disaprate development and update cycles - some tools get new upstream versions pushed for earlier releases, and some do not. Attempting to track this is going to be more work for the translation team. 5) For every language that's added, it requires modification to the comps file t add the appropriate metadata so that the right thing happens. In short, I think it would be a tremendous mistake to go to this model for Fedora. Bill From notting at redhat.com Wed Mar 7 22:54:50 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Mar 2007 17:54:50 -0500 Subject: Translations: String freezes, CVS converging, Packaging In-Reply-To: <1173288684.3524.6.camel@localhost.localdomain> References: <45EDE4F0.4050500@glezos.com> <1173283579.25055.19.camel@erebor.boston.redhat.com> <1173288684.3524.6.camel@localhost.localdomain> Message-ID: <20070307225450.GC22202@nostromo.devel.redhat.com> Thomas Canniot (thomas.canniot at laposte.net) said: > Ok it may be a nightmare but it tries to solve the following problem: > when a translation is made too late after the creation of the new > package before an update (let's say during the life cycle of the > distro), it has very little chance to be included before the next > release of fedora. Generally, the answer is "Thanks, I push your > translation in the NEXT rebuild" (in other words, "Too late guy, wait > some more weeks or months). Fedora upstream software are not being > repackaged every day and pushed as updates. Yes, they are. 11 different system-config packages have been pushed as FC6 updates, as has pirut, initscripts and other things. If you go to separate .po files, then, for *every* package that's pushed post release you'll need to add a special new patch to that releases' version of the master file, get it translated, and push out a specific update for that release. You can't just unilaterly move from the head, because other things that *aren't* pushed for FC6 (or whatever) have moved on, and you'll get translations you don't want. If you work directly in the upstream source for these things, as happen now, you avoid these problems. What's needed is better tools for making sure translators are notified on changes, better enforcement of freezes, etc. Splitting the translations off into separate packages just makes the synchronization process worse. Bill From Michael_E_Brown at dell.com Wed Mar 7 23:40:04 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Wed, 7 Mar 2007 17:40:04 -0600 Subject: announce: readahead-1.4 In-Reply-To: <1173310709.3617.84.camel@max.booze> References: <20070301105026.GF4449@petra.dvoda.cz> <883cfe6d0703051442v2d74ebe8w6ef1764cd659cbd5@mail.gmail.com> <1173275392.3617.6.camel@max.booze> <20070307135206.08f1cb6e@banea.int.addix.net> <1173310709.3617.84.camel@max.booze> Message-ID: <20070307234004.GB18368@humbolt.us.dell.com> On Wed, Mar 07, 2007 at 05:38:29PM -0600, Callum Lerwick wrote: > We could designate the first ext3 block group (actually should make the > number configurable) as the "hot" area. Patch the kernel so it avoids > doing any allocations in the "hot" group(s) except as a last resort. > Then write a tool to move files into the "hot" area somehow, possibly > with help from the kernel. There is already work going on for online defrag. Google turns up several hits. You wouldnt really need to patch the kernel to avoid allocations to the 'hot' area if you always have the hot area packed with hot files. -- Michael From jspaleta at gmail.com Thu Mar 8 00:21:57 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 7 Mar 2007 15:21:57 -0900 Subject: A few ideas. In-Reply-To: <3170f42f0703070928v17afe1bfhff32e015b7d84e6c@mail.gmail.com> References: <3170f42f0703070928v17afe1bfhff32e015b7d84e6c@mail.gmail.com> Message-ID: <604aa7910703071621m8cb372cq256c8ab8b53cef7a@mail.gmail.com> On 3/7/07, Debarshi 'Rishi' Ray wrote: > 3. A "apt-get update" and "apt-get upgrade" combination for YUM and a > 'refresh package information' for Pirut, so that the package > information is updated only when explicitly stated by the user. > However I do not know whether this is already available in YUM (and > Pirut) or not. yum makecache doesn't do what you want? -jef From tonynelson at georgeanelson.com Thu Mar 8 02:05:42 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Wed, 7 Mar 2007 21:05:42 -0500 Subject: announce: readahead-1.4 In-Reply-To: <1173310709.3617.84.camel@max.booze> References: <20070301105026.GF4449@petra.dvoda.cz> <883cfe6d0703051442v2d74ebe8w6ef1764cd659cbd5@mail.gmail.com> <1173275392.3617.6.camel@max.booze> <20070307135206.08f1cb6e@banea.int.addix.net> <1173310709.3617.84.camel@max.booze> Message-ID: At 5:38 PM -0600 3/7/07, Callum Lerwick wrote: >Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; > boundary="=-NBtm2jjVAXM9+NXgmKWn" > >On Wed, 2007-03-07 at 12:55 -0500, Tony Nelson wrote: >> Microsoft already addressed that issue in WinXP, which has fancy hooks to >> the disk defragmenter so that there isn't much seeking when booting WinXP >> (it does take several days until the defrag happens). So I agree with >> Callum, and also dunno WTR MS is thinking. >> >> Probably readahead adopting what MS did in WinXP would be most effective >> but would also violate the most MS patents, as well as requiring hooking >> into the filesystem rather more than is wanted. Something like UnionFS >> might work without patent issues, if it could use a file instead of a hard >> partition. > >I don't see how they could patent defragging a disk. Lets not get crazy >here. ext3 does a decent job of not fragmenting files unnecessarily, can >we really gain much more than the current readahead solution? ... You don't understand the brilliance of what they did. They "refragment" the disk so that all disk I/O during boot is sequential, no matter what file is being read or what part of that file. This Microsoft paper seems relevent: _Fast System Startup for PCs Running Windows_. Look at the section "Prefetching": AIUI, WinXP doesn't prefetch whole files, but only the parts that would have been fetched anyway. Note that reading this paper won't increase Fedora / Redhat patent exposure, as it dosen't explicitly say which things are patented, though I expect that all of them are, so using any of them would be risky even without reading the paper. -- ____________________________________________________________________ TonyN.:' ' From Matt_Domsch at dell.com Thu Mar 8 03:41:12 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 7 Mar 2007 21:41:12 -0600 Subject: Core x86_64 rawhide rebuild in mock status 2007-03-07 Message-ID: <20070307214112.A26083@humbolt.us.dell.com> Core Rawhide-in-Mock Build Results for x86_64 Wed Mar 7 20:24:33 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 1153 Number failed to build: 69 Number expected to fail due to ExclusiveArch or ExcludeArch: 0 Leaving: 69 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 69 ---------------------------------- alacarte-0.11.3-2.fc7 anaconda-11.2.0.28-1.src.rpm apmd-3.2.2-5 boost-1.33.1-10.fc7 castor-0.9.5-1jpp.7 compat-gcc-296-2.96-138 compat-gcc-32-3.2.3-61 compat-gcc-34-3.4.6-7 freeradius-1.1.3-3 g-wrap-1.9.6-7.1 gnome-media-2.17.91-1.fc7 gnome-sharp-2.16.0-1.fc6 gnu-efi-3.0c-1.1 gnucash-2.0.5-1.fc6 gpart-0.1h-5.fc7 grub-0.97-13 iprutils-2.1.5-1 jgroups-2.2.9.2-3jpp.2 kdeaddons-3.5.6-2.fc7 kdnssd-avahi-0.1.3-0.1.20060713svn.fc6 kernel-2.6.20-1.2962.fc7.src.rpm libevent-1.2a-1 libgssapi-0.10-1 librtas-1.2.4-2 libunwind-0.98.5-3 linux-atm-2.5.0-1.20050118cvs memtest86+-1.70-1.fc7 mikmod-3.1.6-39.fc7 mkinitrd-6.0.8-1 mutt-1.5.14-1.fc7 mysqlclient10-3.23.58-9.2.1 mysqlclient14-4.1.14-4.2.1 net-snmp-5.4-10.fc7 nfs-utils-lib-1.0.8-8.fc7 openoffice.org-2.2.0-9.2.src.rpm openssh-4.5p1-4.fc7 orca-2.17.92-1.fc7 perl-5.8.8-14.fc7 ppc64-utils-0.11-1.fc7 prctl-1.5-2 prelink-0.3.10-1 privoxy-3.0.6-5.fc7.src.rpm readahead-1.3-7.fc6 s390utils-1.5.4-4.fc7 salinfo-0.5-1.14.1.fc6 scim-anthy-1.2.2-1.fc7 setroubleshoot-1.9.2-1.fc7.src.rpm sgml-common-0.6.3-19 squirrelmail-1.4.8-4.fc6 struts-1.2.9-4jpp.2 syslinux-3.36-1.fc7 systemtap-0.5.10-1.fc7 tetex-3.0-36.fc7 tomcat5-5.5.17-6jpp.2 valgrind-3.2.3-2 velocity-1.4-6jpp.1 vim-7.0.201-1.fc7 vixie-cron-4.1-75.fc7.src.rpm vnc-4.1.2-14.fc7.src.rpm xen-3.0.4-7.fc7 xferstats-2.16-14.1 xorg-x11-drv-amd-0.0-8.20061016git.fc7 xorg-x11-drv-cyrix-1.1.0-4 xorg-x11-drv-i810-1.6.5-12.fc7.src.rpm xorg-x11-drv-neomagic-1.1.1-2.1 xorg-x11-drv-nsc-2.8.1-3.fc7 xorg-x11-server-1.2.0-10.fc7.src.rpm yaboot-1.3.13-4.fc7 zsh-4.2.6-5.fc7.src.rpm With bugs filed: 0 ---------------------------------- -- 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 Matt_Domsch at dell.com Thu Mar 8 03:41:16 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 7 Mar 2007 21:41:16 -0600 Subject: Core i386 rawhide rebuild in mock status 2007-03-07 Message-ID: <20070307214116.A26102@humbolt.us.dell.com> Core Rawhide-in-Mock Build Results for i386 Wed Mar 7 20:27:21 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 1154 Number failed to build: 56 Number expected to fail due to ExclusiveArch or ExcludeArch: 0 Leaving: 56 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 56 ---------------------------------- anaconda-11.2.0.28-1.src.rpm castor-0.9.5-1jpp.7 elilo-3.6-2 freeradius-1.1.3-3 g-wrap-1.9.6-7.1 gnome-media-2.17.91-1.fc7 gnome-sharp-2.16.0-1.fc6 gnucash-2.0.5-1.fc6 grub-0.97-13 iprutils-2.1.5-1 jgroups-2.2.9.2-3jpp.2 kdeaddons-3.5.6-2.fc7 kdnssd-avahi-0.1.3-0.1.20060713svn.fc6 kernel-2.6.20-1.2962.fc7.src.rpm libevent-1.2a-1 libgssapi-0.10-1 librtas-1.2.4-2 libunwind-0.98.5-3 linux-atm-2.5.0-1.20050118cvs mcelog-0.7-1.22.fc6 mikmod-3.1.6-39.fc7 mkinitrd-6.0.8-1 mutt-1.5.14-1.fc7 mysqlclient10-3.23.58-9.2.1 mysqlclient14-4.1.14-4.2.1 net-snmp-5.4-10.fc7 nfs-utils-lib-1.0.8-8.fc7 openoffice.org-2.2.0-9.2.src.rpm openssh-4.5p1-4.fc7 orca-2.17.92-1.fc7 perl-5.8.8-14.fc7 php-pear-1.5.0-2 ppc64-utils-0.11-1.fc7 prctl-1.5-2 prelink-0.3.10-1 privoxy-3.0.6-5.fc7.src.rpm readahead-1.3-7.fc6 s390utils-1.5.4-4.fc7 salinfo-0.5-1.14.1.fc6 scim-anthy-1.2.2-1.fc7 setroubleshoot-1.9.2-1.fc7.src.rpm sgml-common-0.6.3-19 squirrelmail-1.4.8-4.fc6 struts-1.2.9-4jpp.2 systemtap-0.5.10-1.fc7 tetex-3.0-36.fc7 tomcat5-5.5.17-6jpp.2 velocity-1.4-6jpp.1 vim-7.0.201-1.fc7 vixie-cron-4.1-75.fc7.src.rpm vnc-4.1.2-14.fc7.src.rpm xferstats-2.16-14.1 xorg-x11-drv-i810-1.6.5-12.fc7.src.rpm xorg-x11-server-1.2.0-10.fc7.src.rpm yaboot-1.3.13-4.fc7 zsh-4.2.6-5.fc7.src.rpm With bugs filed: 0 ---------------------------------- -- 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 Matt_Domsch at dell.com Thu Mar 8 03:41:38 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 7 Mar 2007 21:41:38 -0600 Subject: Extras x86_64 rawhide rebuild in mock status 2007-03-07 Message-ID: <20070307214138.A26115@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Wed Mar 7 20:35:34 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2663 Number failed to build: 62 Number expected to fail due to ExclusiveArch or ExcludeArch: 0 Leaving: 62 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 61 ---------------------------------- HelixPlayer-1.0.7-5.fc7 gauret at free.fr R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de apmud-1.0.0-6.fc6 dwmw2 at redhat.com athcool-0.3.11-5.fc6 gajownik at gmail.com atitvout-0.4-6 andreas.bierfert at lowlatency.de banshee-0.11.5-1.fc7 caillon at redhat.com cmucl-19d-3.fc7 rdieter at math.unl.edu compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch conexusmm-0.4.0-5.fc6 rvinyard at cs.nmsu.edu crm114-0-0.2.20060704.fc6 rpm at greysector.net csound-5.03.0-9.fc7 dcbw at redhat.com,paul at all-the-johnsons.co.uk em8300-kmod-0.16.1-6.2.6.20_1.2962.fc7 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net flumotion-0.2.1-3.fc6 thomas at apestaart.org freenx-0.5.0-5.fc6 zipsonic at gmail.com gambas-1.0.17-7.fc7 tcallawa at redhat.com gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gnome-sudoku-0.5.0-1.fc6 stickster at gmail.com grepmail-5.3032-5.fc7 paul at city-fan.org gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk hyperestraier-1.4.9-2.fc7 mtasaka at ioa.s.u-tokyo.ac.jp i8kutils-1.25-11.fc6 matthias at rpmforge.net jogl-1.0.0-5.7.beta5.fc6 green at redhat.com koffice-1.6.2-3.fc7 andreas.bierfert at lowlatency.de kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libpaper-1.1.20-5.fc6 tcallawa at redhat.com libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de libreadline-java-0.8.0-13.fc6 ifoox at redhat.com lightning-1.2-4.fc6 Jochen at herr-schmitt.de lrmi-0.10-2.fc6 kevin at tummy.com magic-7.4.33-6.fc7 cgoorah at yahoo.com.au mlton-20061107-2.fc7 adam at spicenitz.org monodevelop-0.13-1.fc7 paul at all-the-johnsons.co.uk mosml-2.01-9.fc7 gemi at bluewin.ch muine-0.8.7-2.fc7 foolish at guezz.net nagios-plugins-1.4.6-1.fc7 mmcgrath at redhat.com nomadsync-0.4.2-13.fc6 triad at df.lth.se nx-2.1.0-1.fc6 zipsonic at gmail.com oorexx-3.1.1-1.fc7 gemi at bluewin.ch orpie-1.4.3-5.fc6 lists at forevermore.net paraview-2.4.4-3.fc6 orion at cora.nwra.com php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org prewikka-0.9.8-1.fc7 tscherf at redhat.com python-amara-1.1.9-7.fc7 jamatos at fc.up.pt python-reportlab-2.0-2.fc7 bdpepple at ameritech.net q-7.6-2.fc7 gemi at bluewin.ch qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com s3switch-0.0-9.20020912.fc6 paul at xelerance.com spicctrl-1.9-5.fc7 michel.salim at gmail.com steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de toped-0.8.2-2.fc6 cgoorah at yahoo.com.au warzone2100-2.0.5-3.fc7 karlikt at gmail.com wine-0.9.31-1.fc7 andreas.bierfert at lowlatency.de xca-0.5.1-6.fc6 enrico.scholz at informatik.tu-chemnitz.de xeuphoric-0.18.2-6.fc6 paul at all-the-johnsons.co.uk xmldiff-0.6.7-12.fc6 stickster at gmail.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com z88dk-1.6-10.fc6 paul at all-the-johnsons.co.uk zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- 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 Matt_Domsch at dell.com Thu Mar 8 03:41:56 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 7 Mar 2007 21:41:56 -0600 Subject: Extras i386 rawhide rebuild in mock status 2007-03-07 Message-ID: <20070307214156.A26135@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Wed Mar 7 20:41:38 CST 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2667 Number failed to build: 41 Number expected to fail due to ExclusiveArch or ExcludeArch: 0 Leaving: 41 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 40 ---------------------------------- R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de apmud-1.0.0-6.fc6 dwmw2 at redhat.com banshee-0.11.5-1.fc7 caillon at redhat.com compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch conexusmm-0.4.0-5.fc6 rvinyard at cs.nmsu.edu csound-5.03.0-9.fc7 dcbw at redhat.com,paul at all-the-johnsons.co.uk em8300-kmod-0.16.1-6.2.6.20_1.2962.fc7 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net firefox-32-0.0.1-5.fc7 wtogami at redhat.com flumotion-0.2.1-3.fc6 thomas at apestaart.org gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gnome-sudoku-0.5.0-1.fc6 stickster at gmail.com grepmail-5.3032-5.fc7 paul at city-fan.org gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk hyperestraier-1.4.9-2.fc7 mtasaka at ioa.s.u-tokyo.ac.jp jogl-1.0.0-5.7.beta5.fc6 green at redhat.com kdeartwork-extras-3.5.6-2.fc7 rdieter at math.unl.edu kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libpaper-1.1.20-5.fc6 tcallawa at redhat.com libreadline-java-0.8.0-13.fc6 ifoox at redhat.com monodevelop-0.13-1.fc7 paul at all-the-johnsons.co.uk monotone-0.33-1.fc7 roland at redhat.com muine-0.8.7-2.fc7 foolish at guezz.net nagios-plugins-1.4.6-1.fc7 mmcgrath at redhat.com nomadsync-0.4.2-13.fc6 triad at df.lth.se openpbx-1.2-3.rc3.svn2540.fc7 dwmw2 at redhat.com orpie-1.4.3-5.fc6 lists at forevermore.net otrs-2.1.5-1.fc7 mmcgrath at redhat.com paraview-2.4.4-3.fc6 orion at cora.nwra.com php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de sysprof-kmod-1.0.8-1.2.6.20_1.2932.fc7 giallu at gmail.com toped-0.8.2-2.fc6 cgoorah at yahoo.com.au xca-0.5.1-6.fc6 enrico.scholz at informatik.tu-chemnitz.de xmldiff-0.6.7-12.fc6 stickster at gmail.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- 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 faucamp at csir.co.za Thu Mar 8 06:52:02 2007 From: faucamp at csir.co.za (Francois Aucamp) Date: Thu, 08 Mar 2007 08:52:02 +0200 Subject: KDE-Live-Spin In-Reply-To: <45EFCEB20200006A00011A8B@cs-emo.csir.co.za> References: <45EEF7AE020000C50000776F@cs-emo.csir.co.za> <45EFCEB20200006A00011A8B@cs-emo.csir.co.za> Message-ID: <45EFCEB20200006A00011A8B@cs-emo.csir.co.za> What would be the best way to contribute to documentation? Adding missing "KDE Help Center" manuals, or manpages? Or adding howto's, etc, to the wiki? (Obviously both would be nice, but what has the highest priority?) Cheers, -Francois On Wed, 2007-03-07 at 21:04 +0530, Rahul Sundaram wrote: > Kelly wrote: > > I'm a Fedora KDE user, and I'm willing to help out with the Fedora KDE spin if > > anything needs to be done. Just let me know. > > > > The things to be done: > > 1) Review, package KDE components > 2) Help on selecting packages, configuration, branding on the KDE spin > and Live CD > 3) Documentation > 4) Testing > 5) Promotion > > Rahul > -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to CallCentre at csir.co.za. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From seg at haxxed.com Thu Mar 8 06:55:50 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 08 Mar 2007 00:55:50 -0600 Subject: announce: readahead-1.4 In-Reply-To: References: <20070301105026.GF4449@petra.dvoda.cz> <883cfe6d0703051442v2d74ebe8w6ef1764cd659cbd5@mail.gmail.com> <1173275392.3617.6.camel@max.booze> <20070307135206.08f1cb6e@banea.int.addix.net> <1173310709.3617.84.camel@max.booze> Message-ID: <1173336950.18771.45.camel@localhost.localdomain> On Wed, 2007-03-07 at 21:05 -0500, Tony Nelson wrote: > You don't understand the brilliance of what they did. They "refragment" > the disk so that all disk I/O during boot is sequential, no matter what > file is being read or what part of that file. Yes I do, and its not that brilliant. This all falls squarely in the realm of "Obvious to anyone having ordinary skill in the art" if you ask me. > Note that reading this paper won't increase Fedora / Redhat patent > exposure, as it dosen't explicitly say which things are patented, though I > expect that all of them are, so using any of them would be risky even > without reading the paper. -------------- 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 mschwendt.tmp0701.nospam at arcor.de Thu Mar 8 07:06:11 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 8 Mar 2007 08:06:11 +0100 Subject: umask in rpm scriptlets - yes or no? In-Reply-To: References: <20070304133421.94f858e1.mschwendt.tmp0701.nospam@arcor.de> <20070307220741.GD25018@nostromo.devel.redhat.com> Message-ID: <20070308080611.406df0ad.mschwendt.tmp0701.nospam@arcor.de> On Wed, 07 Mar 2007 16:35:51 -0600, Rex Dieter wrote: > Bill Nottingham wrote: > > Rex Dieter said: > >>> Does anybody know whether anything has been decided on setting an > >>> explicit "umask 022" at the beginning of scriptlets? > >> Looks like it's not a bad idea. > > I would strongly suggest that this is something that is best enforced > > in rpm itself rather than in every scriplet. > > Even better, sure. Better? Yes. Becoming reality in the short-term? Probably not. Becoming reality for FC-6 and FC-5? Less likely. From debarshi.ray at gmail.com Thu Mar 8 07:12:48 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 8 Mar 2007 12:42:48 +0530 Subject: A few ideas. In-Reply-To: <604aa7910703071621m8cb372cq256c8ab8b53cef7a@mail.gmail.com> References: <3170f42f0703070928v17afe1bfhff32e015b7d84e6c@mail.gmail.com> <604aa7910703071621m8cb372cq256c8ab8b53cef7a@mail.gmail.com> Message-ID: <3170f42f0703072312k599db563v59fae48a4277f450@mail.gmail.com> > > 3. A "apt-get update" and "apt-get upgrade" combination for YUM and a > > 'refresh package information' for Pirut, so that the package > > information is updated only when explicitly stated by the user. > > However I do not know whether this is already available in YUM (and > > Pirut) or not. > yum makecache doesn't do what you want? Thanks for the attention. The YUM 3.0.3 manual page in Fedora Core 6 merely mentions 'makecache' and does not document it. A combinaton of 'yum makecache' and 'yum -C' does do the job. Even then: a. Why is this not the default behaviour? Is it not natural enough for people to maintain a cache locally, that -C should be the default behaviour? b. After creating the local cache using 'yum makecache', I still find Pirut takes a while to show the package list. It first opened up the 'browse' tab (first from left), which had no package list, and on clicking the 'view' tab (third from left), it again took a while (almost 30 seconds) to display them. Funnily everytime I switch tabs and come back to 'view' it again takes a while. Once it even got stuck, ie. the HDD became idle and for almost 1 minute I had the message box saying "reading package information", after which I killed it. Am I missing something here? Synaptic would just display the packages in a jiffy, even with APT-RPM on a Fedora Core 2. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From debarshi.ray at gmail.com Thu Mar 8 07:20:23 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 8 Mar 2007 12:50:23 +0530 Subject: A few ideas. In-Reply-To: <604aa7910703071621m8cb372cq256c8ab8b53cef7a@mail.gmail.com> References: <3170f42f0703070928v17afe1bfhff32e015b7d84e6c@mail.gmail.com> <604aa7910703071621m8cb372cq256c8ab8b53cef7a@mail.gmail.com> Message-ID: <3170f42f0703072320me444e62l614bd3a3b79ebbce@mail.gmail.com> > yum makecache doesn't do what you want? https://www.redhat.com/archives/fedora-devel-list/2004-December/msg01061.html tells me that, "you can also run yum makecache to force yum to cache all the xml files from a repository's metadata and then use yum -C to run queries or get listing information. Clever people even script yum makecache to run periodically to keep the local cache synced. yum -C removes all network activity and uses only the local cache so unless you cache the packages locally as well.. you cant easily use yum -C to do installs or updates.. its very useful for check-update, list, search, and provides functionality." The last paragraph intrigues me. May be that is why we do not have 'yum -C ...' as the default behaviour. However is it not possible to cache all the metadata, and just retrieve the packages as needed? This coupled with the 'deltaRPM' thingie can greatly economise the bandwidth usage. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From faucamp at csir.co.za Thu Mar 8 08:04:24 2007 From: faucamp at csir.co.za (Francois Aucamp) Date: Thu, 08 Mar 2007 10:04:24 +0200 Subject: A few ideas. In-Reply-To: <45EFDFA80200006A00011ACF@cs-emo.csir.co.za> References: <45EFD3BE02000018001F5574@cs-emo.csir.co.za> <45EFDFA80200006A00011ACF@cs-emo.csir.co.za> Message-ID: <45EFDFA80200006A00011ACF@cs-emo.csir.co.za> On Thu, 2007-03-08 at 12:42 +0530, Debarshi 'Rishi' Ray wrote: > Even then: > > a. Why is this not the default behaviour? Is it not natural enough for > people to maintain a cache locally, that -C should be the default > behaviour? This is natural assuming you have prior experience with apt-get. From personal experience I can say that a _lot_ of people do not fully understand/like the "apt-get update && apt-get upgrade" dance. They just want one command, and everything should be done for them. The standard yum update fulfills this need. Even on some of the Debian systems, some people seem to forget to run apt-get update, and then complain about apt-get install not working properly... Personally, I'm inclined to agree with you, but I've seen the opposite way too much to believe it should be implemented. Cheers, -Francois -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to CallCentre at csir.co.za. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From fedora at camperquake.de Thu Mar 8 08:27:17 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 8 Mar 2007 09:27:17 +0100 Subject: RANDR 1.2 heads up In-Reply-To: <1173136781.9948.22.camel@localhost.localdomain> References: <1173136781.9948.22.camel@localhost.localdomain> Message-ID: <20070308092717.6dd893d2@banea.int.addix.net> Hi. On Mon, 05 Mar 2007 18:19:41 -0500, Adam Jackson wrote: > - Gnome randr applet crashes. Like, instantly. > - Old school xrandr options sometimes do nonintuitive things, > particularly for rotation. > - DPI is only loosely related to reality. > - panel sometimes gets very confused about positioning. > - i865 and below probably don't work. > > But on the plus side, you can enable and disable monitors at runtime > now. It's like living in the future. How does one actually do this? Do I have to configure the monitors in xorg.conf, or are they autodetected? What program do I use to tell xorg to turn the monitors on and off? From caolanm at redhat.com Thu Mar 8 08:34:37 2007 From: caolanm at redhat.com (Caolan McNamara) Date: Thu, 08 Mar 2007 08:34:37 +0000 Subject: Core i386 rawhide rebuild in mock status 2007-03-07 In-Reply-To: <20070307214116.A26102@humbolt.us.dell.com> References: <20070307214116.A26102@humbolt.us.dell.com> Message-ID: <1173342877.7701.74.camel@soulcrusher.caolan.org> On Wed, 2007-03-07 at 21:41 -0600, Matt Domsch wrote: > Core Rawhide-in-Mock Build Results for i386 Wed Mar 7 20:27:21 CST 2007 > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > Total packages: 1154 > Number failed to build: 56 > Number expected to fail due to ExclusiveArch or ExcludeArch: 0 > Leaving: 56 > (there may be some duplicates if rawhide has 2 versions of a package) > openoffice.org-2.2.0-9.2.src.rpm I don't see any log to explain the build failure for OOo from this list http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/openoffice.org-2.2.0-9.2.src.rpm/ and http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/x86_64/openoffice.org-2.2.0-9.2.src.rpm/ seem to be effectively empty ? C. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Mar 8 10:22:29 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 8 Mar 2007 11:22:29 +0100 Subject: Extras x86_64 rawhide rebuild in mock status 2007-03-07 In-Reply-To: <20070307214138.A26115@humbolt.us.dell.com> References: <20070307214138.A26115@humbolt.us.dell.com> Message-ID: <20070308112229.7af74424@python3.es.egwn.lan> Matt Domsch wrote : > Extras Rawhide-in-Mock Build Results for x86_64 Wed Mar 7 20:35:34 CST 2007 > [...] > Number failed to build: 62 > Number expected to fail due to ExclusiveArch or ExcludeArch: 0 > Leaving: 62 [...] > i8kutils-1.25-11.fc6 matthias at rpmforge.net It looks like something might have broke in the script, since i8kutils has a line with "ExclusiveArch: i386" and the x86_64 build.log reports : error: Architecture is not included: x86_64 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2895.fc6 Load : 1.32 1.27 1.06 From Axel.Thimm at ATrpms.net Thu Mar 8 11:18:15 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 12:18:15 +0100 Subject: glibc help needed with fakeroot: changes in chown? Message-ID: <20070308111815.GB13355@neu.nirvana> Hi, fakeroot preloads its lib overriding file access and identity commands to fake the impression of being root. A couple of weeks ago fakeroot's chown stopped to work. This happens even on an FC6 kernel (and a rawhide chroot), so it looks like something changed in glibc that makes fakeroot break on chown. All other overridden calls seems to work fine. Can anyone please help with what has changed and suggest how to adjust fakeroot? Thanks! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davehoz at gmail.com Thu Mar 8 11:20:30 2007 From: davehoz at gmail.com (David Hunter) Date: Thu, 8 Mar 2007 22:20:30 +1100 Subject: AMSN update problem. Message-ID: <6bb886180703080320w14b3361dg5ce517c996e866e0@mail.gmail.com> When I try to update AMSN to amsn - 0.96-6.fc7.i386 from amsn - 0.96-5.fc7.i386, software updater reports the following: ('file /usr/lib/tcl8.4 from install of amsn-0.96-6.fc7 conflicts with file from package tcl-8.4.13-12.fc7', (7, '/usr/lib/tcl8.4', 0L))] How do I rectify the problem? -- David Hunter -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at erwinrol.com Thu Mar 8 11:26:35 2007 From: mailinglists at erwinrol.com (Erwin Rol) Date: Thu, 08 Mar 2007 12:26:35 +0100 Subject: glibc help needed with fakeroot: changes in chown? In-Reply-To: <20070308111815.GB13355@neu.nirvana> References: <20070308111815.GB13355@neu.nirvana> Message-ID: <1173353195.6467.31.camel@lat.home.erwinrol.com> Hey Axel, > fakeroot preloads its lib overriding file access and identity commands > to fake the impression of being root. > > A couple of weeks ago fakeroot's chown stopped to work. This happens > even on an FC6 kernel (and a rawhide chroot), so it looks like > something changed in glibc that makes fakeroot break on chown. All > other overridden calls seems to work fine. > > Can anyone please help with what has changed and suggest how to adjust > fakeroot? > we ran into the same problem for PTXdist. The problem is not the chown but the chownat system calls. Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402688 has a patch http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402688;msg=10;filename=froot_1_5_10-atfuncs.patch;att=1 that works for fakeroot 2.5.10. - Erwin From buildsys at redhat.com Thu Mar 8 12:12:07 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 8 Mar 2007 07:12:07 -0500 Subject: rawhide report: 20070308 changes Message-ID: <200703081212.l28CC7tX009909@hs20-bc2-6.build.redhat.com> Updated Packages: autofs-1:5.0.1-4 ---------------- * Thu Mar 08 2007 Ian Kent - 5.0.1-4 - fixed numeric export match (bz 231188). beagle-0.2.16.2-2.fc7 --------------------- * Wed Mar 07 2007 Alexander Larsson - 0.2.16.2-2 - Add manual requires for gsf-sharp and evolution-sharp (#230212) - Make beagle-evolution require beagle, not beagle-gui dejagnu-1:1.4.4-7 ----------------- * Wed Mar 07 2007 Petr Machata - 1:1.4.4-7 - Remove mention of dejagnu.info from manpage, per comments in doc/Makefile. - Resolves: #230652 * Wed Feb 07 2007 Petr Machata - 1:1.4.4-6 - Tidy up the specfile per rpmlint comments echo-icon-theme-0.2-1.20070206wiki.fc7 -------------------------------------- * Tue Feb 06 2007 Matthias Clasen - 0.2-1.20070206wiki - New snapshot * Mon Feb 05 2007 Matthias Clasen - 0.1-7 - Neuter macros in %changelog * Thu Oct 26 2006 David Zeuthen - 0.1-6 - Make this package own %{_datadir}/icons/Echo - Preserve timestamps - Keep %build around to document it's intentionally left empty - Use %{buildroot} instead of $RPM_BUILD_ROOT f-spot-0.3.5-1.fc7 ------------------ * Wed Mar 07 2007 Christopher Aillon - 0.3.5-1 - Update to 0.3.5 gamin-0.1.8-4.fc7 ----------------- * Wed Mar 07 2007 Alexander Larsson - 0.1.8-4 - Add patch to fix #204906 glib2-2.12.10-1.fc7 ------------------- * Wed Mar 07 2007 Matthias Clasen - 2.12.10-1 - Update to 2.12.10 gnome-vfs2-2.17.91-2.fc7 ------------------------ * Wed Mar 07 2007 Alexander Larsson - 2.17.91-2 - Handle ipv6 link-local addresses better in network:/// (#212565) iso-codes-1.0-1.fc7 ------------------- * Wed Mar 07 2007 Christopher Aillon 1.0-1 - Update to 1.0 kdbg-1:2.0.5-1.fc7 ------------------ * Wed Mar 07 2007 Than Ngo - 1:2.0.5-1.fc7 - 2.0.5 kdeaddons-3.5.6-3.fc7 --------------------- * Wed Mar 07 2007 Than Ngo - 3.5.6-3.fc7 - %doc COPYING-DOCS - Requires(post,postun): xdg-utils kernel-2.6.20-1.2975.fc7 ------------------------ * Wed Mar 07 2007 Dave Jones - Add modules.* to %files * Wed Mar 07 2007 Dave Jones - Remove last vestiges of the ppc64iseries specific kernel * Wed Mar 07 2007 Dave Jones - 2.6.21rc3 man-pages-de-0.5-1.fc7 ---------------------- * Wed Mar 07 2007 Marcela Maslanova 0.5-1 - merge review, update on new version - rhbz#226123 net-snmp-1:5.4-11.fc7 --------------------- * Thu Mar 01 2007 Radek Vok??l - 5.4-11 - fix lm_sensors-devel Requires (#229109) nspr-4.6.6-1 ------------ * Wed Mar 07 2007 Kai Engert - 4.6.6-1 - Update to 4.6.6 - Adjust IPv6 patch to latest upstream version ntp-4.2.4p0-1.fc7 ----------------- * Wed Mar 07 2007 Miroslav Lichvar 4.2.4p0-1 - update to 4.2.4p0 - fix init script - don't add second -g to ntpd options (#228424) - update getopts - skip all refclocks when parsing ntp.conf - spec cleanup paps-0.6.6-18.fc7 ----------------- * Wed Mar 07 2007 Akira TAGOH - 0.6.6-18 - default to lpi=6 and cpi=10 if paps is bringing up as cups filter. (#223862) * Tue Jan 23 2007 Akira TAGOH - Better the encoding guess by looking at current locale. (#212154) pykickstart-0.99-1.fc7 ---------------------- * Wed Mar 07 2007 Chris Lumens - 0.99-1 - The timezone command didn't recognize --isUtc before FC6 (#231189). - Recognize %ksappend lines in ksvalidator. - Don't set default values in some command __init__ methods. - Added an updates command. - Add support for RAID10. smartmontools-1:5.37-2.fc7 -------------------------- * Wed Mar 07 2007 Vitezslav Crhonek - 1:5.37-2 - re-add cloexec patch - re-add one erased changelog entry - compile with -fpie (instead of -fpic) tclx-8.4.0-6.fc7 ---------------- * Wed Mar 07 2007 Marcela Maslanova - 8.4.0-6 - rebuild for merge review udev-106-1.fc7 -------------- * Wed Mar 07 2007 Harald Hoyer - 106-1.fc7 - version 106 - specfile cleanup - removed pilot rule - removed dasd_id and dasd_id rule - provide static versions in a subpackage vixie-cron-4:4.1-78.fc7 ----------------------- * Wed Mar 07 2007 Marcela Maslanova - 4:4.1-78 - merge review xen-3.0.4-8.fc7 --------------- * Tue Mar 06 2007 Daniel P. Berrange - 3.0.4-8.fc7 - Close QEMU file handles when running network script * Fri Mar 02 2007 Daniel P. Berrange - 3.0.4-7.fc7 - Fix interaction of bootloader with blktap (bz 230702) - Ensure PVFB daemon terminates if domain doesn't startup (bz 230634) * Thu Feb 08 2007 Daniel P. Berrange - 3.0.4-6.fc7 - Setup readonly loop devices for readonly disks - Extended error reporting for hotplug scripts - Pass all 8 mouse buttons from VNC through to kernel yum-3.1.4-1.fc7 --------------- * Wed Mar 07 2007 Jeremy Katz - 3.1.4-1 - update to 3.1.4 Broken deps for ppc64 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ppc64 requires xdg-utils kdeaddons - 3.5.6-3.fc7.ppc64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ppc64 requires xdg-utils net-snmp-devel - 1:5.4-11.fc7.ppc64 requires lm_sensors-devel Broken deps for x86_64 ---------------------------------------------------------- frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.x86_64 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeaddons - 3.5.6-3.fc7.x86_64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.x86_64 requires xdg-utils Broken deps for i386 ---------------------------------------------------------- frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeaddons - 3.5.6-3.fc7.i386 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.i386 requires xdg-utils Broken deps for ia64 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ia64 requires xdg-utils kdeaddons - 3.5.6-3.fc7.ia64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ia64 requires xdg-utils net-snmp-devel - 1:5.4-11.fc7.ia64 requires lm_sensors-devel Broken deps for ppc ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ppc requires libofx.so.3 gnucash - 2.0.5-1.fc6.ppc requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.ppc requires xdg-utils kdeaddons - 3.5.6-3.fc7.ppc requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ppc requires xdg-utils net-snmp-devel - 1:5.4-11.fc7.ppc requires lm_sensors-devel Broken deps for s390 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeaddons - 3.5.6-3.fc7.s390 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390 requires xdg-utils net-snmp-devel - 1:5.4-11.fc7.s390 requires lm_sensors-devel 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 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.s390x requires libofx.so.3()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.s390x requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeaddons - 3.5.6-3.fc7.s390x requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390x requires xdg-utils net-snmp-devel - 1:5.4-11.fc7.s390x requires lm_sensors-devel net-snmp-devel - 1:5.4-11.fc7.s390 requires lm_sensors-devel From mmaslano at redhat.com Thu Mar 8 12:38:14 2007 From: mmaslano at redhat.com (Marcela Maslanova) Date: Thu, 08 Mar 2007 13:38:14 +0100 Subject: AMSN update problem. In-Reply-To: <6bb886180703080320w14b3361dg5ce517c996e866e0@mail.gmail.com> References: <6bb886180703080320w14b3361dg5ce517c996e866e0@mail.gmail.com> Message-ID: <45F003B6.5010501@redhat.com> Maybe could be fixed by changing Requires in amsn spec file. For example tk should be tk >= 1:8.4. Marcela David Hunter wrote: > When I try to update AMSN to amsn - 0.96-6.fc7.i386 from amsn - > 0.96-5.fc7.i386, software updater reports the following: > > ('file /usr/lib/tcl8.4 from install of amsn-0.96-6.fc7 conflicts with > file from package tcl-8.4.13-12.fc7 ', (7, '/usr/lib/tcl8.4', 0L))] > > How do I rectify the problem? > > -- > David Hunter From tjanouse at redhat.com Thu Mar 8 13:16:35 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Thu, 8 Mar 2007 14:16:35 +0100 Subject: RANDR 1.2 heads up In-Reply-To: <20070308092717.6dd893d2@banea.int.addix.net> References: <1173136781.9948.22.camel@localhost.localdomain> <20070308092717.6dd893d2@banea.int.addix.net> Message-ID: <20070308131635.GA18472@redhat.com> Hi, On Thu, Mar 08, 2007 at 09:27:17AM +0100, Ralf Ertzinger wrote: > How does one actually do this? Do I have to configure the monitors > in xorg.conf, or are they autodetected? What program do I use to > tell xorg to turn the monitors on and off? Using the xrandr command. For example, a command xrandr --output VGA --mode 1024x768 --pos 0x800 will add the external monitor below my laptop panel. But you may have to configure a separate Monitor section for the external monitor to be able to use modes other than those from the LVDS, which is done by a line in the Device section: Option "Monitor-VGA" "name of the monitor" -- TJ., BaseOS, Brno, CZ From Matt_Domsch at dell.com Thu Mar 8 13:28:52 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 8 Mar 2007 07:28:52 -0600 Subject: Extras x86_64 rawhide rebuild in mock status 2007-03-07 In-Reply-To: <20070308112229.7af74424@python3.es.egwn.lan> References: <20070307214138.A26115@humbolt.us.dell.com> <20070308112229.7af74424@python3.es.egwn.lan> Message-ID: <20070308132852.GA655@lists.us.dell.com> On Thu, Mar 08, 2007 at 11:22:29AM +0100, Matthias Saou wrote: > Matt Domsch wrote : > > > Extras Rawhide-in-Mock Build Results for x86_64 Wed Mar 7 20:35:34 CST 2007 > > > [...] > > Number failed to build: 62 > > Number expected to fail due to ExclusiveArch or ExcludeArch: 0 > > Leaving: 62 > [...] > > i8kutils-1.25-11.fc6 matthias at rpmforge.net > > It looks like something might have broke in the script, since i8kutils > has a line with "ExclusiveArch: i386" and the x86_64 build.log reports : > > error: Architecture is not included: x86_64 Indeed, good catch. For the first time, we have so many RPMs that you can't glob them with a line like: egrep "Architecture is (not included|excluded)" */result/build.log so I tried to do the same thing in a loop, but apparently it needs more work. Thanks, Matt -- 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 Matt_Domsch at dell.com Thu Mar 8 13:30:48 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 8 Mar 2007 07:30:48 -0600 Subject: Core i386 rawhide rebuild in mock status 2007-03-07 In-Reply-To: <1173342877.7701.74.camel@soulcrusher.caolan.org> References: <20070307214116.A26102@humbolt.us.dell.com> <1173342877.7701.74.camel@soulcrusher.caolan.org> Message-ID: <20070308133048.GB655@lists.us.dell.com> On Thu, Mar 08, 2007 at 08:34:37AM +0000, Caolan McNamara wrote: > On Wed, 2007-03-07 at 21:41 -0600, Matt Domsch wrote: > > Core Rawhide-in-Mock Build Results for i386 Wed Mar 7 20:27:21 CST 2007 > > > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > > > Total packages: 1154 > > Number failed to build: 56 > > Number expected to fail due to ExclusiveArch or ExcludeArch: 0 > > Leaving: 56 > > (there may be some duplicates if rawhide has 2 versions of a package) > > > openoffice.org-2.2.0-9.2.src.rpm > > I don't see any log to explain the build failure for OOo from this list > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/openoffice.org-2.2.0-9.2.src.rpm/ > and > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/x86_64/openoffice.org-2.2.0-9.2.src.rpm/ > seem to be effectively empty ? I think that's another mistake of my globs, as I'm specifically excluding building openoffice right now - it just takes too long to build. (for reference, I'm excluding kernel, openoffice, emacs, and gcc right now). Yea for too many packages to glob! -- 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 mattdm at mattdm.org Thu Mar 8 13:33:21 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 8 Mar 2007 08:33:21 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2007-03-07 In-Reply-To: <20070308132852.GA655@lists.us.dell.com> References: <20070307214138.A26115@humbolt.us.dell.com> <20070308112229.7af74424@python3.es.egwn.lan> <20070308132852.GA655@lists.us.dell.com> Message-ID: <20070308133321.GA15978@jadzia.bu.edu> On Thu, Mar 08, 2007 at 07:28:52AM -0600, Matt Domsch wrote: > > It looks like something might have broke in the script, since i8kutils > > has a line with "ExclusiveArch: i386" and the x86_64 build.log reports : > > error: Architecture is not included: x86_64 > Indeed, good catch. For the first time, we have so many RPMs that you > can't glob them with a line like: > egrep "Architecture is (not included|excluded)" */result/build.log > so I tried to do the same thing in a loop, but apparently it > needs more work. Sounds like what it needs is xargs. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sundaram at fedoraproject.org Thu Mar 8 14:46:18 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 08 Mar 2007 20:16:18 +0530 Subject: KDE-Live-Spin In-Reply-To: <45EFCEB20200006A00011A8B@cs-emo.csir.co.za> References: <45EEF7AE020000C50000776F@cs-emo.csir.co.za> <45EFCEB20200006A00011A8B@cs-emo.csir.co.za> <45EFCEB20200006A00011A8B@cs-emo.csir.co.za> Message-ID: <45F021BA.2070000@fedoraproject.org> Francois Aucamp wrote: > What would be the best way to contribute to documentation? Adding > missing "KDE Help Center" manuals, or manpages? This would be something you can do through the upstream KDE documentation project. > Or adding howto's, etc, to the wiki? (Obviously both would be nice, but > what has the highest priority?) There are many areas. One of the high priority ones would be to have a KDE equivalent to http://fedoraproject.org/wiki/Docs/DesktopUserGuide. For joining the documentation project refer to http://fedoraproject.org/wiki/DocsProject. The current guide assumes the default GNOME setup for Fedora Core 6. For Fedora 7 since we are going to have a KDE specific spin and Live CD, we would need good documentation to go along with it. For advanced users, more information about producing custom KDE based Fedora spins would be useful. Nearing release time, smaller promotional style documents would be good to have too. Rahul From tonynelson at georgeanelson.com Thu Mar 8 15:17:11 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Thu, 8 Mar 2007 10:17:11 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2007-03-07 In-Reply-To: <20070308132852.GA655@lists.us.dell.com> References: <20070307214138.A26115@humbolt.us.dell.com> <20070308112229.7af74424@python3.es.egwn.lan> <20070308132852.GA655@lists.us.dell.com> Message-ID: At 7:28 AM -0600 3/8/07, Matt Domsch wrote: >On Thu, Mar 08, 2007 at 11:22:29AM +0100, Matthias Saou wrote: >> Matt Domsch wrote : >> >> > Extras Rawhide-in-Mock Build Results for x86_64 Wed Mar 7 20:35:34 CST 2007 >> > >> [...] >> > Number failed to build: 62 >> > Number expected to fail due to ExclusiveArch or ExcludeArch: 0 >> > Leaving: 62 >> [...] >> > i8kutils-1.25-11.fc6 matthias at rpmforge.net >> >> It looks like something might have broke in the script, since i8kutils >> has a line with "ExclusiveArch: i386" and the x86_64 build.log reports : >> >> error: Architecture is not included: x86_64 > >Indeed, good catch. For the first time, we have so many RPMs that you >can't glob them with a line like: > >egrep "Architecture is (not included|excluded)" */result/build.log I think this will do it: find . -wholename './*/result/build.log' -print | xargs egrep "Architecture is (not included|excluded)" -- ____________________________________________________________________ TonyN.:' ' From ajackson at redhat.com Thu Mar 8 15:06:49 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 08 Mar 2007 10:06:49 -0500 Subject: rawhide report: 20070306 changes In-Reply-To: <45EF3A60.7070806@zoeloelip.be> References: <200703061138.l26Bcrj2012027@hs20-bc2-6.build.redhat.com> <45EF3A60.7070806@zoeloelip.be> Message-ID: <1173366409.20896.0.camel@localhost.localdomain> On Wed, 2007-03-07 at 23:19 +0100, Bart Vanbrabant wrote: > > xorg-x11-server-1.2.99.901-1.fc7 > > -------------------------------- > > * Mon Mar 05 2007 Adam Jackson 1.2.99.901-1 > > - xserver 1.3 RC1. RANDR 1.2 hotness in the hizzouse. > > - xserver-1.2.0-honor-displaysize.patch: Honor the DisplaySize config > > directive again (#220248) > > - Clean up the post-install cleanup > > > > * Fri Mar 02 2007 Adam Tkac 1.2.0-10 > > - change permissions of files in source package to default from read-only > > > > * Mon Feb 26 2007 Adam Tkac 1.2.0-9 > > - Created new package (xorg-x11-server-source) which is needed to build VNC > > server. > > This update killed the nouveau driver. Any chance it will be updated to > the xrandr-1.2 branch? I think that's the first report I've had of it actually working! I'm not sure yet whether the randr12 branch or mainline is more stable. Guess I'll have to find out. - ajax From ajackson at redhat.com Thu Mar 8 15:13:16 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 08 Mar 2007 10:13:16 -0500 Subject: Core x86_64 rawhide rebuild in mock status 2007-03-07 In-Reply-To: <20070307214112.A26083@humbolt.us.dell.com> References: <20070307214112.A26083@humbolt.us.dell.com> Message-ID: <1173366796.20896.4.camel@localhost.localdomain> On Wed, 2007-03-07 at 21:41 -0600, Matt Domsch wrote: > xorg-x11-drv-amd-0.0-8.20061016git.fc7 > xorg-x11-drv-cyrix-1.1.0-4 > xorg-x11-drv-i810-1.6.5-12.fc7.src.rpm > xorg-x11-drv-neomagic-1.1.1-2.1 > xorg-x11-drv-nsc-2.8.1-3.fc7 > xorg-x11-server-1.2.0-10.fc7.src.rpm amd, cyrix, and nsc are now ExclusiveArched away from amd64, since it's not meaningful to build them for that arch (they're on-die with x86 chips only, atm). Same for neomagic, although it's just on-northbridge unstead of on-die. You might want to refresh the arches list. No idea why i810 and xserver are failing. They both show a failure in time.log and nothing else. Any idea? - ajax From alan at redhat.com Thu Mar 8 15:40:30 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 8 Mar 2007 10:40:30 -0500 Subject: Core x86_64 rawhide rebuild in mock status 2007-03-07 In-Reply-To: <1173366796.20896.4.camel@localhost.localdomain> References: <20070307214112.A26083@humbolt.us.dell.com> <1173366796.20896.4.camel@localhost.localdomain> Message-ID: <20070308154030.GA1613@devserv.devel.redhat.com> On Thu, Mar 08, 2007 at 10:13:16AM -0500, Adam Jackson wrote: > amd, cyrix, and nsc are now ExclusiveArched away from amd64, since it's > not meaningful to build them for that arch (they're on-die with x86 > chips only, atm). Same for neomagic, although it's just on-northbridge The cyrix, AMD and NSC drivers cover a variety of support chips for the Cyrix/NSC/AMD Geode range, but they are all 32bit only glue chips. Alan From fedora at camperquake.de Thu Mar 8 16:01:20 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 8 Mar 2007 17:01:20 +0100 Subject: rawhide report: 20070306 changes In-Reply-To: <1173366409.20896.0.camel@localhost.localdomain> References: <200703061138.l26Bcrj2012027@hs20-bc2-6.build.redhat.com> <45EF3A60.7070806@zoeloelip.be> <1173366409.20896.0.camel@localhost.localdomain> Message-ID: <20070308170120.7924dabb@banea.int.addix.net> Hi. On Thu, 08 Mar 2007 10:06:49 -0500, Adam Jackson wrote: > I think that's the first report I've had of it actually working! The nouveau driver or randr12? nouveau works on my home box (nv11 chip), not better or worse than nv from all that I can tell. the randr12 tree runs on my laptop (with the intel driver), and so far that also works. From phillip.lougher at gmail.com Thu Mar 8 16:32:24 2007 From: phillip.lougher at gmail.com (Phillip Lougher) Date: Thu, 8 Mar 2007 16:32:24 +0000 (UTC) Subject: Kernel 2.6.19 squashfs problem and bugzilla References: <20070302153703.GA7038@dspnet.fr.eu.org> <20070302211758.GB20893@redhat.com> <20070306034724.GA14486@redhat.com> Message-ID: Dave Jones redhat.com> writes: > > Thanks for the info. No problem. >I'll look at moving our trees from 3.2-alpha > to 3.2 final tomorrow. Any signs of this heading upstream any time soon? > I'm working on the patches now. There are still a couple of outstanding issues from when I last submitted, which I have to fix. Unfortunately, since joining Ubuntu, I seem to have even less time to work on it. Phillip From michel.salim at gmail.com Thu Mar 8 16:36:45 2007 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 8 Mar 2007 11:36:45 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2007-03-07 In-Reply-To: <20070307214138.A26115@humbolt.us.dell.com> References: <20070307214138.A26115@humbolt.us.dell.com> Message-ID: <883cfe6d0703080836n53118da3jc6ece1d61c1f5e72@mail.gmail.com> 2007/3/7, Matt Domsch : > Extras Rawhide-in-Mock Build Results for x86_64 Wed Mar 7 20:35:34 CST 2007 > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > Total packages: 2663 > Number failed to build: 62 > Number expected to fail due to ExclusiveArch or ExcludeArch: 0 > Leaving: 62 > (there may be some duplicates if rawhide has 2 versions of a package) > > Of those expected to have worked... > Without a bug filed: 61 > ---------------------------------- > HelixPlayer-1.0.7-5.fc7 gauret at free.fr HelixPlayer has ExcludeArch for x86_64 set. -- Michel Salim http://hircus.wordpress.com/ From michel.salim at gmail.com Thu Mar 8 16:39:47 2007 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 8 Mar 2007 11:39:47 -0500 Subject: How does new F7 schedule affect Firefox In-Reply-To: <1172522352.11406.8.camel@shrek.rexursive.com> References: <1172522352.11406.8.camel@shrek.rexursive.com> Message-ID: <883cfe6d0703080839o2d9ee06bo591a444acd9afbb0@mail.gmail.com> 2007/2/26, Bojan Smojver : > Now that the planned release date for F7 is 24 May 2007 (a month after > EOL for FF 1.5) and keeping in mind that FC6 will be supported until > F8T2 (so, say until about September 2007 or so), isn't that going to > cause the need for backporting of fixes to FF 1.5 for about 4 to 5 > months? Wouldn't it be better (i.e. less effort) to bite the bullet now > and just upgrade the whole FC6 to FF 2.0? > Note that since RHEL4 is still supported and has FF 1.5, Red Hat will still have to maintain it anyway. -- Michel Salim http://hircus.wordpress.com/ From dimitris at glezos.com Thu Mar 8 16:45:39 2007 From: dimitris at glezos.com (Dimitris Glezos) Date: Thu, 08 Mar 2007 16:45:39 +0000 Subject: Translations: String freezes, CVS converging, Packaging In-Reply-To: <1173283579.25055.19.camel@erebor.boston.redhat.com> References: <45EDE4F0.4050500@glezos.com> <1173283579.25055.19.camel@erebor.boston.redhat.com> Message-ID: <45F03DB3.2030800@glezos.com> O/H Jeremy Katz ??????: > On Tue, 2007-03-06 at 22:02 +0000, Dimitris Glezos wrote: >> ## String freezes >> >> For F7, the RelEng team has introduced string freezes in the schedule [2]. This >> means that application strings for F7 should be complete *by 19/3*. Translations >> made after this date (and before the freeze) should be guaranteed to be included >> in the release. >> >> [2]: http://fedoraproject.org/wiki/Core/Schedule > > Yep -- this should hopefully help a lot, although I expect it will take > a release or two to fully institutionalize itself. We should probably > have a procedure to be followed for cases where strings need to be > changed. Here's a shot in the dark: > > String Freeze Policy. As of the string freeze date, translatable > strings should not change to help ensure high quality translations for > the Fedora 7 release. If you have a case where you need to change a > string after this date, please send notification to fedora-trans-list. Sounds good. >> ## CVS convergence >> >> [...] >> The plan is to move all PO files on Fedora infrastructure under a new >> CVS group (cvsl10n) [3]. An email will be sent to all translators to create a >> FAS account if they don't have one and join the cvs group. Members of the L10n >> team and ambassadors will help with this process. >> >> [3]: http://fedoraproject.org/wiki/L10N/Projects/CVSInfrastructure > > Does this also include moving the actual source that's hosted on > elvis/i18n? If not, then I have very strong concerns... separating the > source code from the translations has a lot of downsides as it requires > a manual sync between the two. And these never work well :( Discussion on '#fedora-admin' gave us a lot of insight. Thanks for the explanations. For those who weren't there, hosting the PO files on a different SCM from the source is not a no-brainer and both Jeremy and Jesse don't recommend it. So instead of moving the PO files off elvis, it's better to move everything. We can do it right after F7 is out; give people the time they'd like to settle on 'cvs.fedoraproject.org'. Actually, our Docs code is currently hosted there and does requires translations, so we can go ahead and start translations; settle the ground for the rest of the apps. We've created a 'cvsl10n' CVS group which will be given permissions on the 'po/' dir and see how things roll. >> At this point we could discuss the idea for Fedora to act as upstream for >> the translations of outside-hosted projects such as yum, smolt, and >> pungi. The proposal is to host and maintain those project's >> translations with the existing Fedora L10n community. > > See above :-) Although there's definitely a need for some problem > solving here, as there is plenty of desire to have projects hosted in > non-CVS SCMs as well. As said yesterday, ideally, the Fedora L10n community could act as "upstream" for the PO files of any application, even externally hosted ones. The L10n project would like, for example, to have easy-access to applications, either they are technically hosted on 'cvs.fp.org', or on 'hosted.fp.org' or on remote repositories. The above, of course, needs further discussion to find a nice technical way to establish it that does not require translators working with 5 different tools (cvs, hg, web UI etc). >> ## Packaging translations >> >> One final plan (and probably the one that needs most discussion) is about >> changing the way we package translations. Right now PO files live inside the >> application and are packaged there (GNOME-style). The plan is to move the PO >> files in to their own directory and distinct package [4] (KDE-style langpacks). >> >> [4]: http://fedoraproject.org/wiki/L10N/Projects/TranslationsPackage > > I'm very very very very strongly opposed to doing this. It's a nitemare > from an installation point of view and also from a space point of view. > The packages which do translations like this require absolutely horrible > hacks within our software management stack to even have a *chance* of > people getting the translations installed for their apps. Contrast to > the apps which include the translations in the package... install the > package and voila!, you have the translations for it. > >> Cons: L10n team should maintain a package (or many) and packages should be >> altered to accomodate the different locations of PO files. > > Con: makes the source COMPLETELY divorced from the translations. So if > I update an app and you don't update the translation package, all new > strings aren't translated. Unless you push a new (massive) translation > package. This does not scale. OK, I see we'll be having big problems with this and it's pretty obvious it is not feasible. Basically, the L10n problem is that of requesting a package update/repackaging (of an app that Fedora is upstream) because of important new translations. The drill is almost always the same: we want repackaging for *all* packages which have new translations: 1. Before *every* release 2. Some time after a release (say, 1 and 3 months) The first point should always happen, even for only few new translations. Language coordinators could control the second point by judging if enough new (or important) translations were made on a package between the latest update and $now. -d -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From Matt_Domsch at dell.com Thu Mar 8 17:17:16 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 8 Mar 2007 11:17:16 -0600 Subject: Extras x86_64 rawhide rebuild in mock status 2007-03-07 In-Reply-To: <883cfe6d0703080836n53118da3jc6ece1d61c1f5e72@mail.gmail.com> References: <20070307214138.A26115@humbolt.us.dell.com> <883cfe6d0703080836n53118da3jc6ece1d61c1f5e72@mail.gmail.com> Message-ID: <20070308171716.GA15946@lists.us.dell.com> On Thu, Mar 08, 2007 at 11:36:45AM -0500, Michel Salim wrote: > HelixPlayer has ExcludeArch for x86_64 set. Yes, my stats scripts broke on all the ExclusiveArch/ExcludeArch stuff. My apologies for the noise, I'm fixing now. -- 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 sander at hoentjen.eu Thu Mar 8 17:33:22 2007 From: sander at hoentjen.eu (Sander Hoentjen) Date: Thu, 08 Mar 2007 18:33:22 +0100 Subject: AMSN update problem. In-Reply-To: <6bb886180703080320w14b3361dg5ce517c996e866e0@mail.gmail.com> References: <6bb886180703080320w14b3361dg5ce517c996e866e0@mail.gmail.com> Message-ID: <1173375203.5980.5.camel@peecee.hoentjen.eu> On Thu, 2007-03-08 at 22:20 +1100, David Hunter wrote: > When I try to update AMSN to amsn - 0.96-6.fc7.i386 from amsn - > 0.96-5.fc7.i386, software updater reports the following: > > ('file /usr/lib/tcl8.4 from install of amsn-0.96-6.fc7 conflicts with > file from package tcl-8.4.13-12.fc7 ', (7, '/usr/lib/tcl8.4', 0L))] > > How do I rectify the problem? Whoops, my bad. I will fix it tomorrow. Sander From bart.vanbrabant at zoeloelip.be Thu Mar 8 18:00:38 2007 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Thu, 08 Mar 2007 19:00:38 +0100 Subject: rawhide report: 20070306 changes In-Reply-To: <1173366409.20896.0.camel@localhost.localdomain> References: <200703061138.l26Bcrj2012027@hs20-bc2-6.build.redhat.com> <45EF3A60.7070806@zoeloelip.be> <1173366409.20896.0.camel@localhost.localdomain> Message-ID: <45F04F46.5050206@zoeloelip.be> > > I think that's the first report I've had of it actually working! > > I'm not sure yet whether the randr12 branch or mainline is more stable. > Guess I'll have to find out. > > - ajax > I've only reported back to the nouveau irc channels that it worked. I had to switch back to the nvidia driver, the nouveau already seems to be faster then the nv driver for 2D. 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 Axel.Thimm at ATrpms.net Thu Mar 8 18:39:31 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 8 Mar 2007 19:39:31 +0100 Subject: glibc help needed with fakeroot: changes in chown? In-Reply-To: <1173353195.6467.31.camel@lat.home.erwinrol.com> References: <20070308111815.GB13355@neu.nirvana> <1173353195.6467.31.camel@lat.home.erwinrol.com> Message-ID: <20070308183931.GA10906@neu.nirvana> Hi Erwin, On Thu, Mar 08, 2007 at 12:26:35PM +0100, Erwin Rol wrote: > > fakeroot preloads its lib overriding file access and identity commands > > to fake the impression of being root. > > > > A couple of weeks ago fakeroot's chown stopped to work. This happens > > even on an FC6 kernel (and a rawhide chroot), so it looks like > > something changed in glibc that makes fakeroot break on chown. All > > other overridden calls seems to work fine. > > > > Can anyone please help with what has changed and suggest how to adjust > > fakeroot? > > > > we ran into the same problem for PTXdist. The problem is not the chown > but the chownat system calls. > > Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402688 has a > patch > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402688;msg=10;filename=froot_1_5_10-atfuncs.patch;att=1 that works for fakeroot 2.5.10. Thanks a ton, that was the solution! -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajackson at redhat.com Thu Mar 8 18:39:13 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 08 Mar 2007 13:39:13 -0500 Subject: rawhide report: 20070306 changes In-Reply-To: <20070308170120.7924dabb@banea.int.addix.net> References: <200703061138.l26Bcrj2012027@hs20-bc2-6.build.redhat.com> <45EF3A60.7070806@zoeloelip.be> <1173366409.20896.0.camel@localhost.localdomain> <20070308170120.7924dabb@banea.int.addix.net> Message-ID: <1173379153.20896.8.camel@localhost.localdomain> On Thu, 2007-03-08 at 17:01 +0100, Ralf Ertzinger wrote: > Hi. > > On Thu, 08 Mar 2007 10:06:49 -0500, Adam Jackson wrote: > > > I think that's the first report I've had of it actually working! > > The nouveau driver or randr12? nouveau. I got a few bug reports from it and assumed no one else had even tried it. - ajax From hughsient at gmail.com Thu Mar 8 19:05:07 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 8 Mar 2007 19:05:07 +0000 Subject: rawhide report: 20070306 changes In-Reply-To: <1173379153.20896.8.camel@localhost.localdomain> References: <200703061138.l26Bcrj2012027@hs20-bc2-6.build.redhat.com> <45EF3A60.7070806@zoeloelip.be> <1173366409.20896.0.camel@localhost.localdomain> <20070308170120.7924dabb@banea.int.addix.net> <1173379153.20896.8.camel@localhost.localdomain> Message-ID: <15e53e180703081105p66eafe60se996ce1f90f21bf0@mail.gmail.com> On 08/03/07, Adam Jackson wrote: > On Thu, 2007-03-08 at 17:01 +0100, Ralf Ertzinger wrote: > > Hi. > > > > On Thu, 08 Mar 2007 10:06:49 -0500, Adam Jackson wrote: > > > > > I think that's the first report I've had of it actually working! > > > > The nouveau driver or randr12? > > nouveau. I got a few bug reports from it and assumed no one else had > even tried it. It breaks horribly on "Nvidia Geforce 7800 Go" chipsets as found in the new Lenovo laptops due to some pretty major FIFO corruption. Most of the other cards work as good as the nv driver, or even a little better in my limited experience. Richard. From lsof at nodata.co.uk Thu Mar 8 20:50:27 2007 From: lsof at nodata.co.uk (nodata) Date: Thu, 08 Mar 2007 21:50:27 +0100 Subject: pup: boon or curse? quicker updates or slower updates? Message-ID: <1173387027.3038.6.camel@sb-home.lan> Quick question - since you started using pup, do you generally apply security updates: 1) Quicker 2) Slower 3) About the same. Perhaps worryingly, I'm noticing that it's 2) Slower, for me. Why? Because I wait until a red security update pops up, blues get ignored. From davehoz at gmail.com Thu Mar 8 21:27:05 2007 From: davehoz at gmail.com (David Hunter) Date: Fri, 9 Mar 2007 08:27:05 +1100 Subject: AMSN update problem. In-Reply-To: <1173375203.5980.5.camel@peecee.hoentjen.eu> References: <6bb886180703080320w14b3361dg5ce517c996e866e0@mail.gmail.com> <1173375203.5980.5.camel@peecee.hoentjen.eu> Message-ID: <6bb886180703081327i5a2c6635p72c9d5bac258a446@mail.gmail.com> Thanks. On 09/03/07, Sander Hoentjen wrote: > > On Thu, 2007-03-08 at 22:20 +1100, David Hunter wrote: > > When I try to update AMSN to amsn - 0.96-6.fc7.i386 from amsn - > > 0.96-5.fc7.i386, software updater reports the following: > > > > ('file /usr/lib/tcl8.4 from install of amsn-0.96-6.fc7 conflicts with > > file from package tcl-8.4.13-12.fc7 ', (7, '/usr/lib/tcl8.4', 0L))] > > > > How do I rectify the problem? > > Whoops, my bad. I will fix it tomorrow. > > Sander > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- David Hunter -------------- next part -------------- An HTML attachment was scrubbed... URL: From lmacken at redhat.com Thu Mar 8 23:30:36 2007 From: lmacken at redhat.com (Luke Macken) Date: Thu, 8 Mar 2007 18:30:36 -0500 Subject: Slightly OT: bad rap for Fedora, and realistic effects In-Reply-To: <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> References: <16de708d0702221431o218bc98clb4ce14dd4c9a2bdd@mail.gmail.com> <604aa7910702221540r413b8489n97073ecf12e98ee2@mail.gmail.com> <20070223133517.bcbf50c9.mschwendt.tmp0701.nospam@arcor.de> <20070223102339.299b8741@ningauble.scrye.com> <20070223190524.e54bf2f4.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070308233036.GA16553@tomservo.rh.rit.edu> On Fri, Feb 23, 2007 at 07:05:24PM +0100, Michael Schwendt wrote: > > - Updates system - No idea where that is... it is still not finished > > from what I know. Perhaps someone else could fill this in? > > I know where it is, I am subscribed to the Wiki page, too, but there is > some secret relationship between it and what is used at Red Hat. Smells a > bit like another fork/semi-rewrite of an existing code base, which creates > a situation like "aha, somebody is working on transfering more and more > existant code piece by piece, so it's just matter of time before all of it > is published". This "secret" relationship is essentially over, as I'm porting/rewriting the last bits of it (the dependency closure checking) now. It was only secret because the old code was a nasty blob of mod_python that was hardcoded with passwords and such. The code has been rewritten and has been public for quite some time now. https://hosted.fedoraproject.org/projects/bodhi luke From dwmw2 at infradead.org Fri Mar 9 00:15:05 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 09 Mar 2007 00:15:05 +0000 Subject: pup: boon or curse? quicker updates or slower updates? In-Reply-To: <1173387027.3038.6.camel@sb-home.lan> References: <1173387027.3038.6.camel@sb-home.lan> Message-ID: <1173399305.3461.538.camel@pmac.infradead.org> On Thu, 2007-03-08 at 21:50 +0100, nodata wrote: > Quick question - since you started using pup, do you generally apply > security updates: > > 1) Quicker > 2) Slower > 3) About the same. > > Perhaps worryingly, I'm noticing that it's 2) Slower, for me. > Why? Because I wait until a red security update pops up, blues get > ignored. On the machines where pup is still running, slower. Because when I run 'yum update' it fails and I'm told that a copy of yum is already running. On most machines, I just removed pup and yum-updatesd. Go figure. -- dwmw2 From petersen at redhat.com Fri Mar 9 00:20:44 2007 From: petersen at redhat.com (Jens Petersen) Date: Fri, 09 Mar 2007 10:20:44 +1000 Subject: naming scheme for fonts packages? In-Reply-To: <63347.192.54.193.51.1172657012.squirrel@rousalka.dyndns.org> References: <45E54A39.7030104@redhat.com> <63347.192.54.193.51.1172657012.squirrel@rousalka.dyndns.org> Message-ID: <45F0A85C.5000504@redhat.com> Nicolas Mailhot wrote: > IMHO (which if worth what it's worth) you're not packaging generic fonts > for tibetan but a specific font project, and it deserves name recognition > just like any other upstream. So upstreamname-fonts seems more respectful > for me. Then a followup question: if there is only 1 (truetype) font in a font package should the package name be "upstreamname-fonts" or "upstreamname-font"? :) The latter seems semantically more logical, the former more syntactically consistent. It is easy to search for /most/ fonts packages now with "rpm -qa '*fonts*'", but on the other hand it is a bit strange to call something *-fonts if it only contains a single font? So which gives? :) Any comments on this? Thanks, Jens ps I guess another aspect is one can never be sure that a project with one font now, in the future will not have more than one, or vice versa even. (Debian uses package names like "ttf-name" for truetype fonts.) From david at lovesunix.net Fri Mar 9 00:35:49 2007 From: david at lovesunix.net (David Nielsen) Date: Fri, 09 Mar 2007 01:35:49 +0100 Subject: pup: boon or curse? quicker updates or slower updates? In-Reply-To: <1173387027.3038.6.camel@sb-home.lan> References: <1173387027.3038.6.camel@sb-home.lan> Message-ID: <1173400550.26475.17.camel@dawkins> tor, 08 03 2007 kl. 21:50 +0100, skrev nodata: > Quick question - since you started using pup, do you generally apply > security updates: > > 1) Quicker > 2) Slower > 3) About the same. > > Perhaps worryingly, I'm noticing that it's 2) Slower, for me. > Why? Because I wait until a red security update pops up, blues get > ignored. It's a considerably better user experience than forcing the user to manually check for updates. However pup tends to lock yum and the fact that it doesn't update the GUI and as such looks like it crashed is the single thing I get the most complaints about with Fedora from the users I talk to. Theres definitely room for improvement in pup but having an easy update manager that informs the user is not an option we should go without. - 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 mkearey at redhat.com Fri Mar 9 01:00:03 2007 From: mkearey at redhat.com (Mike Kearey) Date: Fri, 09 Mar 2007 11:00:03 +1000 Subject: Thread Hijack - Our package management GUI tools need improvement In-Reply-To: <1173387027.3038.6.camel@sb-home.lan> References: <1173387027.3038.6.camel@sb-home.lan> Message-ID: <45F0B193.2000704@redhat.com> In general our single, most commonly criticized feature is package management. I do think we need bigger efforts in this area: - Make the GUI tools _just work_ For example, have one graphical tool. It should manage both on and offline package management. Make it such that it can manage package installs from CD as well as from mirrors. In the situation where the system has been updated, and the user is attempting to install a package from CD - If the package has deps that have been updated Tell the User. Explain that the specific package has been obsoleted. Offer the user the choice to go to updates mirrors on Internet to get the package or to cancel. - Integrate the GUI tools with the yum-updatesd - If there is a conflict when yum-updatesd is running, Tell The User. Explain why this is happening. Perhaps integrate the GUI tool in such a way that it starts, informs the user that yum-updatesd is running, and shows the status of yum-updatesd - plus the opportunity to control it. - Make yum at least equal in speed to the alternative tools like apt-get I constantly see people criticizing yum for it's apparent slowness. This has been going on for years now. We need to do real side by side comparisons to identify where the problems are. I am guilty of ignoring the slowness as it 'just works' for me and I am a happy sys admin for it. For many newer users, speed is essential. For many new users, installing packages, and exploring the system is the central activity. So package management GUIs should not be under-estimated in their importance. Cheers, Michael From tonynelson at georgeanelson.com Fri Mar 9 04:08:19 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Thu, 8 Mar 2007 23:08:19 -0500 Subject: pup: boon or curse? quicker updates or slower updates? In-Reply-To: <1173387027.3038.6.camel@sb-home.lan> References: <1173387027.3038.6.camel@sb-home.lan> Message-ID: At 9:50 PM +0100 3/8/07, nodata wrote: >Quick question - since you started using pup, do you generally apply >security updates: > >1) Quicker >2) Slower >3) About the same. > >Perhaps worryingly, I'm noticing that it's 2) Slower, for me. >Why? Because I wait until a red security update pops up, blues get >ignored. I used Pup a couple of times and abandoned it. I kept yum-updatesd and puplet for several months, but when I noticed that yum-updatesd used 30 MB of memory ( which I needed) all the time, I shut them down. When I had them running, I would update whenever puplet popped up. Now I update about once a day. So, "1) Quicker". -- ____________________________________________________________________ TonyN.:' ' From bojan at rexursive.com Fri Mar 9 04:14:22 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Fri, 9 Mar 2007 04:14:22 +0000 (UTC) Subject: How does new F7 schedule affect Firefox References: <1172522352.11406.8.camel@shrek.rexursive.com> <883cfe6d0703080839o2d9ee06bo591a444acd9afbb0@mail.gmail.com> Message-ID: Michel Salim gmail.com> writes: > Note that since RHEL4 is still supported and has FF 1.5, Red Hat will > still have to maintain it anyway. Not necessarily true. RHEL4 started with FF 1.0.x and then switched to 1.5.x later. So, it may go to FF 2.x or even 3.x in the future. That's kind of my point - why maintain old stuff and waste effort on that when even the super stable RHEL is getting latest and greatest anyway. And, by going with current "mainstream" FF we also get the latest stuff (let's face it - we all want features :-). Two birds with one stone and all that... But, since it's not going to be my time going into any of this, I'm cool with any decision package maintainer(s) make. -- Bojan From debarshi.ray at gmail.com Fri Mar 9 07:27:44 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 9 Mar 2007 12:57:44 +0530 Subject: pup: boon or curse? quicker updates or slower updates? In-Reply-To: <1173399305.3461.538.camel@pmac.infradead.org> References: <1173387027.3038.6.camel@sb-home.lan> <1173399305.3461.538.camel@pmac.infradead.org> Message-ID: <3170f42f0703082327md9af697t9f9c8f9177da5307@mail.gmail.com> > On most machines, I just removed pup and yum-updatesd. Go figure. +1. I do not use pup, and switched off yum-updatesd. On slow networks, yum-updatesd takes a whole lot of time, and the fact that it locks up yum is an added problem. Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From fedora at leemhuis.info Fri Mar 9 07:59:53 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 09 Mar 2007 08:59:53 +0100 Subject: pup: boon or curse? quicker updates or slower updates? In-Reply-To: <3170f42f0703082327md9af697t9f9c8f9177da5307@mail.gmail.com> References: <1173387027.3038.6.camel@sb-home.lan> <1173399305.3461.538.camel@pmac.infradead.org> <3170f42f0703082327md9af697t9f9c8f9177da5307@mail.gmail.com> Message-ID: <45F113F9.2020009@leemhuis.info> On 09.03.2007 08:27, Debarshi 'Rishi' Ray wrote: >> On most machines, I just removed pup and yum-updatesd. Go figure. > +1. > I do not use pup, and switched off yum-updatesd. So do/did I -- one reason was the slow start up of yum-updatesd (#220614), that slowed down the boot-process on my laptop quite a lot. > [...] and the fact that it locks up yum is an added problem. A really annoying one if you ask me -- would it be possible that command line yum simply talks to yum-updatesd via d-bus and says "hey, yum-updatesd background task, the users wants to do something interactively now which is way more important then your business -- so quickly go sleeping for a while! (read: f... off)"? Just for completeness: I'd use yum-updatesd if both problems mentioned above would get fixed. That way I'd get notified via pup about pending updates. I'd probably still would not use pup itself, as it always asks for the root password -- it's way easier for me to call "sudo yum update"(?). And, BTW, if we're doing pup/yum-updatesd bashing here then lets do it for real (sorry jeremy (?)): I'm one of those 56 people in the CC list of https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=212507 as I hit that bug on one of my machines, too. That bug is quite annoying and harmful. Jeremy, can I as a ordinary users without much programming skills help you somehow to get it resolved? CU thl (?) -- there is a way to configure consolehelper to not ask me for the root password (aka sudo like functionality), but I never found time to figure it out. Is that stuff documented/described somewhere properly in a step-by-step-guide-for-dummies-like-thl somewhere? (?) -- as I mentioned already on fedora-advisory-list: jeremy does a great job, but we could need some more jeremy's afaics. Yes, other rh and community developers do a great job, too, but a lot of (read: to much) serious stuff in fedora-land afaics depends on jeremy -- but his days afaics also have only 24 hours and he needs a chance for a real life, too ;-) From rc040203 at freenet.de Fri Mar 9 08:40:08 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 Mar 2007 09:40:08 +0100 Subject: pup: boon or curse? quicker updates or slower updates? In-Reply-To: <45F113F9.2020009@leemhuis.info> References: <1173387027.3038.6.camel@sb-home.lan> <1173399305.3461.538.camel@pmac.infradead.org> <3170f42f0703082327md9af697t9f9c8f9177da5307@mail.gmail.com> <45F113F9.2020009@leemhuis.info> Message-ID: <1173429608.25839.427.camel@mccallum.corsepiu.local> On Fri, 2007-03-09 at 08:59 +0100, Thorsten Leemhuis wrote: > On 09.03.2007 08:27, Debarshi 'Rishi' Ray wrote: > >> On most machines, I just removed pup and yum-updatesd. Go figure. > > +1. > > I do not use pup, and switched off yum-updatesd. > > So do/did I -- one reason was the slow start up of yum-updatesd > (#220614), that slowed down the boot-process on my laptop quite a lot. And so did I. Primary reason was yum-updatesd not working reliably (lockups, (lack of) mirror synchronicity/stability, package updates killing services in use, broken repos) > > [...] and the fact that it locks up yum is an added problem. > Just for completeness: I'd use yum-updatesd if both problems > mentioned above would get fixed. I'd not. IMO, yum and Fedora's packaging are not in a shape to allow unattended package updates. Ralf From pertusus at free.fr Fri Mar 9 08:54:19 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 09:54:19 +0100 Subject: gnash mock build and buildsys build differents? Message-ID: <20070309085419.GA2866@free.fr> Hello, I have a puzzling bug report for gnash: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217020 Seems that the gnash built by the buildsystem isn't the same than a gnash build locally using mock?? The one built locally doesn't crash. Do you have any idea what could cause this strange difference? What can I do to debug further? -- Pat From tla at rasmil.dk Fri Mar 9 09:38:28 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Fri, 09 Mar 2007 10:38:28 +0100 Subject: Thread Hijack - Our package management GUI tools need improvement In-Reply-To: <45F0B193.2000704@redhat.com> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> Message-ID: <45F12B14.9060409@rasmil.dk> Mike Kearey wrote: > In general our single, most commonly criticized feature is package > management. > > I do think we need bigger efforts in this area: > > - Make the GUI tools _just work_ > For example, have one graphical tool. It should manage both on and > offline package management. Make it such that it can manage package > installs from CD as well as from mirrors. In the situation where the > system has been updated, and the user is attempting to install a package > from CD - If the package has deps that have been updated Tell the User. > Explain that the specific package has been obsoleted. Offer the user the > choice to go to updates mirrors on Internet to get the package or to cancel. > The been changes in yum lately, there removes the need for downloading header, this is necessary to have media support in yum and the tools using the yum API (pup, pirut, yumex etc.). So media support is work in progress. > - Integrate the GUI tools with the yum-updatesd - If there is a conflict > when yum-updatesd is running, Tell The User. Explain why this is > happening. Perhaps integrate the GUI tool in such a way that it starts, > informs the user that yum-updatesd is running, and shows the status of > yum-updatesd - plus the opportunity to control it. > > It's imported to know how the different tools works before taking this discussion. yum-api : The yum backed python classes there does all the real action. yum-cli: The yum command line tool. yum-updatesd: The system deamon there checks for updates, controlled by DBus commands. puplet: The update applet, there shows notification when updates are availible, it controls the yum-updatesd by DBus commands. pup: A Gui for installing yum updates. pirut: A Gui for installing and removing packages. system-config-packages: A gui for installing af single local package. yumex: Another gui for updating,installing and removing packages. yum-utils: A collection of command line tools to do different actions using the yum-api. The yum-cli, yum-updatesd, pup, pirut, yumex, system-config-packages,yum-util is using the yum-api to do the real action and only one tool can work at the time, so they use a locking system build into yum, all the tools will bail out if the yum-api is locked, the don't know what application is locking the yum-api. Only the the 'puplet' is aware of 'yum-updates', so if it runs in the background, you will get an error if you run one of the other tools. Maybe if the applet was showing some kind of animated icon when it was working, the user would know why they cant run one of the other tools. > - Make yum at least equal in speed to the alternative tools like apt-get > > The problem with comparing yum and apt-get, is that people forget that it is not fair to compare the speed of 'apt-get update' and 'yum update', because the are not doing the same job. apt-get update only work on a local cache, while yum checks if the local cache is warm, and reload it, if it has not been updates recently. some you have to compare a 'apt-get dist-upgrade; apt-get update' with 'yum update' > I constantly see people criticizing yum for it's apparent slowness. This > has been going on for years now. We need to do real side by side > comparisons to identify where the problems are. I am guilty of ignoring > the slowness as it 'just works' for me and I am a happy sys admin for > it. For many newer users, speed is essential. For many new users, > installing packages, and exploring the system is the central activity. > Then talking about speed you have to look at the step in a 'yum update' transaction. 1. initialization (reading config files, repo files etc.) 2. for each repo do: get a list of urls (load mirrorlist or use baseurls in repofile). get the the repomd.xml from the remote site. get the basic metadata primary.xml.gz (or primary.sqlite.bz) parse the metadata and insert it into the local sqlite db. 3. load the data in the local rpm db. 4. Match the local rpm db with the remote packages available in the repos to detected if something needs to be updated. 5. Depsolve the updates found in 4, to see if all dependencies is solved. (Extra metadata and rpm headers are downloaded (yum < 3.1.x)) 6. Download needed packages. 7. Update/Install the packages in the transaction. Looking at the speed of different steps. 1. fast. 2. The time depends of the number of repos and the size of the metadata and network bandwidth and speed of the mirror used. The speeds is fast if the metadata has been loaded recently, because then yum will use the cached files. 3. fast. 4. The time depends on the number of installed & availible packages. 5. The time depends on the number of installed and the number of packages in the transaction, big transaction can take long time. The current yum 3.1.x release is slower than yum 3.0.x, because it has been totally redesigned, and it most importent that it is working right, before starting to optimize the speed. 6. Depends on the size of the packages to be downloaded, network bandwidth and the how fast the mirrors are. 7. Depends on the number of packages, the size and scripts include in the rpms. (RPM) The only step 2 (the metadata parse) ,4 ,5 can be optimized in yum all the others are controlled by outside parameters. In the daily use of yum on a stable version of Fedora, I don't think there are any speed issues. Off cause if you are running a 500 Mhz, PII, with a 56 Kbits modem connecting, a OpenOffice update > 100Mb sucks big time, But that is not something you can bame on yum. > So package management GUIs should not be under-estimated in their > importance. > > package management GUIs are importent, this is why i have created yumex :-) . Tim From tla at rasmil.dk Fri Mar 9 09:50:29 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Fri, 09 Mar 2007 10:50:29 +0100 Subject: pup: boon or curse? quicker updates or slower updates? In-Reply-To: <45F113F9.2020009@leemhuis.info> References: <1173387027.3038.6.camel@sb-home.lan> <1173399305.3461.538.camel@pmac.infradead.org> <3170f42f0703082327md9af697t9f9c8f9177da5307@mail.gmail.com> <45F113F9.2020009@leemhuis.info> Message-ID: <45F12DE5.2010609@rasmil.dk> Thorsten Leemhuis wrote: > > A really annoying one if you ask me -- would it be possible that > command line yum simply talks to yum-updatesd via d-bus and says "hey, > yum-updatesd background task, the users wants to do something > interactively now which is way more important then your business -- so > quickly go sleeping for a while! (read: f... off)"? This don't sounds sane to me. Ex. yum-updatesd are in the process of installing some updates. The user are running 'yum install foo' and then 'yum-updatesd' should just f... off, in the middle of the RPM transaction. It think the best way to handle this issue is to make the applet show it have started some work in the background. Tim From fedora at leemhuis.info Fri Mar 9 10:03:24 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 09 Mar 2007 11:03:24 +0100 Subject: pup: boon or curse? quicker updates or slower updates? In-Reply-To: <45F12DE5.2010609@rasmil.dk> References: <1173387027.3038.6.camel@sb-home.lan> <1173399305.3461.538.camel@pmac.infradead.org> <3170f42f0703082327md9af697t9f9c8f9177da5307@mail.gmail.com> <45F113F9.2020009@leemhuis.info> <45F12DE5.2010609@rasmil.dk> Message-ID: <45F130EC.3050102@leemhuis.info> On 09.03.2007 10:50, Tim Lauridsen wrote: > Thorsten Leemhuis wrote: >> A really annoying one if you ask me -- would it be possible that >> command line yum simply talks to yum-updatesd via d-bus and says "hey, >> yum-updatesd background task, the users wants to do something >> interactively now which is way more important then your business -- so >> quickly go sleeping for a while! (read: f... off)"? > This don't sounds sane to me. > > Ex. > yum-updatesd are in the process of installing some updates. > The user are running 'yum install foo' and then 'yum-updatesd' should > just f... off, in the middle of the RPM transaction. *Of course* yum-updatesd should not be aborted if it is in the process of installing some updates (or similar things that shouldn't be aborted) -- taht would be just sutpid. I was more interested in the default configuration of yum-updatesd, where the only thing it (iirc) normally does in the background is to check for updates. CU thl From bart.vanbrabant at zoeloelip.be Fri Mar 9 10:23:03 2007 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Fri, 09 Mar 2007 11:23:03 +0100 Subject: Selinux and hal Message-ID: <45F13587.5020007@zoeloelip.be> Hello, I'm using a fully updated rawhide installation. Today I got some updates from extras. I think the problem started when the update of gutenprint was installed. I keep getting this message from sealert: Summary SELinux is preventing /usr/sbin/hald (hald_t) "read" access to inotify (inotifyfs_t). Detailed Description SELinux denied access requested by /usr/sbin/hald. It is not expected that this access is required by /usr/sbin/hald and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Allowing Access Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for inotify, restorecon -v inotify. There is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 - or you can disable SELinux protection entirely for the application. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Changing the "hald_disable_trans" boolean to true will disable SELinux protection this application: "setsebool -P hald_disable_trans=1." The following command will allow this access: setsebool -P hald_disable_trans=1 Additional Information Source Context system_u:system_r:hald_t Target Context system_u:object_r:inotifyfs_t Target Objects inotify [ dir ] Affected RPM Packages Policy RPM Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.disable_trans Host Name duvel Platform Linux duvel 2.6.20-1.2967.fc7PAE #1 SMP Tue Mar 6 14:49:37 EST 2007 i686 athlon Alert Count 261 First Seen Fri Mar 9 11:10:56 2007 Last Seen Fri Mar 9 11:10:58 2007 Local ID 0057c30e-29d5-4a43-a1c7-1b382f49f813 Line Numbers Raw Audit Messages avc: denied { read } for comm="hald" dev=inotifyfs egid=68 euid=68 exe="/usr/sbin/hald" exit=-13 fsgid=68 fsuid=68 gid=68 items=0 name="inotify" path="inotify" pid=2255 scontext=system_u:system_r:hald_t:s0 sgid=68 subj=system_u:system_r:hald_t:s0 suid=68 tclass=dir tcontext=system_u:object_r:inotifyfs_t:s0 tty=(none) uid=68 I've already gotten more than 260 of those messages in 5 minutes. I had to kill auditd when it used 58% of my 1GB ram. For a daemon that has to do some logging this is quite extreme. Has anyone else seen this problem? Should I file bugreports somewhere? thanks, 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 Fri Mar 9 10:46:06 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Fri, 9 Mar 2007 05:46:06 -0500 Subject: rawhide report: 20070309 changes Message-ID: <200703091046.l29Ak6Ei003410@hs20-bc2-6.build.redhat.com> Updated Packages: a2ps-4.13b-62.fc7 ----------------- * Thu Mar 08 2007 Tim Waugh 4.13b-62 - Build requires bison. - Use sed instead of perl for string replacement (bug #225235). - Better install-info scriptlets (bug #225235). - Added BuildRequires and Requires for more packages (bug #225235). - a2ps.cfg needn't be %config (bug #225235). - No need to gzip the info files (bug #225235). - Use external libtool and don't run the autotools (bug #225235). alsa-lib-1.0.14-0.3.rc3.fc7 --------------------------- * Thu Mar 08 2007 Martin Stransky 1.0.14-0.3.rc3 - new upstream amtu-1.0.5-1.fc7 ---------------- * Thu Mar 08 2007 Steve Grubb 1.0.5-1 - new upstream version anaconda-11.2.0.34-1 -------------------- * Thu Mar 08 2007 David Cantrell - 11.2.0.34-1 - Remove duplicate Activate On Boot checkbox in iw netconfig - Set DHCPv6_DISABLE flag for auto neighbor discovery (#230941, #230949) - Set loaderData->ip appropriately in STEP_IP (#231290) - Replace hyphens in BOOTIF= parameter with colons (#209284) - In strcount() in libisys, return 0 if tmp is NULL (#231290) - Subclass Raid class in kickstart.py from F7_Raid (clumens) - Make sure ext2 filesystem module is loaded early (clumens, #230946) * Thu Mar 08 2007 Chris Lumens - 11.2.0.33-1 - Fix translations to build correctly. - Fix traceback on upgrade due to yum API change. * Wed Mar 07 2007 Jeremy Katz - 11.2.0.32-1 - Various buildinstall and splittree fixes to make things work better without an RPMS dir (Jesse Keating) - Minor package progress API changes - Minor backend fixes (Elliot Peele) - Minor translation related fixes anthy-8706-1.fc7 ---------------- * Fri Mar 09 2007 Akira TAGOH - 8706-1 - New upstream release. at-spi-1.17.2-2.fc7 ------------------- * Thu Mar 08 2007 Ray Strode - 1.17.2-2 - add a patch that might fix some deadlock issues (bug 329454) cups-1:1.2.8-4.fc7 ------------------ * Thu Mar 08 2007 Tim Waugh 1:1.2.8-4 - Implemented SCM_CREDENTIALS authentication for UNIX domain sockets (bug #230613). desktop-file-utils-0.12-4.fc7 ----------------------------- * Thu Mar 08 2007 Florian La Roche - 0.12-4 - remove empty post/preun scripts completely glib2-2.12.11-1.fc7 ------------------- * Fri Mar 09 2007 Matthias Clasen - 2.12.11-1 - Update to 2.12.11 gnome-power-manager-2.17.92-2.fc7 --------------------------------- * Thu Mar 08 2007 Adam Jackson 2.17.92-2 - gnome-power-manager-2.17.92-dpms-query-less.patch: DPMSCapable() can never change for a given display, so cache the result and cut our wakeups in half. gstreamer-0.10.12-1.fc7 ----------------------- * Thu Mar 08 2007 - Bastien Nocera - 0.10.12-1 - Update to 0.10.12 * Tue Feb 13 2007 - Bastien Nocera - 0.10.11-2 - Remove Requires on packages that BuildRequire us jakarta-commons-pool-0:1.3-9jpp.1.fc7 ------------------------------------- * Wed Mar 07 2007 Matt Wringe 0:1.3-9jpp.1 - Merge with updated jpp version - Updated commons-build, no longer need patchs to get around local building. * Fri Feb 23 2007 Jason Corley 1:1.3-8jpp - update copyright to contain current year - rebuild on RHEL4 to avoid broken jar repack script in FC6 * Fri Jan 26 2007 Matt Wringe 1:1.3-7jpp - Fix bug in pool-tomcat5-build.xml kernel-2.6.20-1.2981.fc7 ------------------------ * Thu Mar 08 2007 Dave Jones - update to squashfs 3.2-r2 * Thu Mar 08 2007 Dave Jones - update to latest utrace. * Thu Mar 08 2007 John W. Linville - update git-wireless-dev.patch (current as of 2007-03-06) libchewing-0.3.0-6.fc7 ---------------------- * Fri Mar 09 2007 Caius Chance - 0.3.0-6.devel - Fixed bz231568: [chewing] Look up table is showing candidates of previous look-up. libselinux-2.0.5-2.fc7 ---------------------- * Thu Mar 08 2007 Dan Walsh - 2.0.5-2 - Do not fail on permission denied in getsebool logwatch-7.3.4-2.fc7 -------------------- * Thu Mar 08 2007 Ivana Varekova 7.3.4-2 - add pam_unix service patch lvm2-2.02.23-1.fc7 ------------------ * Thu Mar 08 2007 Alasdair Kergon - 2.02.23-1 - Fix vgrename active LV check to ignore differing vgids. - Fix two more segfaults if an empty config file section encountered. - Fix a leak in a reporting error path. - Add devices/cache_dir & devices/cache_file_prefix, deprecating devices/cache. * Tue Feb 27 2007 Alasdair Kergon - 2.02.22-3 - Move .cache file to /etc/lvm/cache. mtr-2:0.72-1 ------------ * Thu Feb 22 2007 Marcela Maslanova - 2:0.72-1 - review - rhbz#226164 ncurses-5.6-6.20070303.fc7 -------------------------- * Thu Mar 08 2007 Miroslav Lichvar 5.6-6.20070303 - update to patch 20070303 - use one libtinfo for both libncurses and libncursesw - shorten -devel description openoffice.org-1:2.2.0-11.1 --------------------------- * Wed Mar 07 2007 Caolan McNamara - 1:2.2.0-11.1 - yet another release candidate * Wed Mar 07 2007 Caolan McNamara - 1:2.2.0-10.2 - rhbz#206268/ooo#75167 session restore back to the right workspace - -fno-threadsafe-statics seeing as we're already double locked http://people.redhat.com/caolanm/speed/threadsafe-statics.ods - drop openoffice.org-2.2.0.oooXXXXX.atkthreads.atexit.patch, atk fixed - add openoffice.org-2.2.0.ooo75190.shell.newrecentlyused.patch, the ~/.recently-used location and format changed python-virtinst-0.101.0-4.fc7 ----------------------------- * Thu Mar 08 2007 Daniel P. Berrange - 0.101.0-4.fc7 - Fixed install of paravirt Xen guests scim-1.4.5-9.fc7 ---------------- * Fri Mar 09 2007 Jens Petersen - 1.4.5-9 - add scim-1.4.5-no-rpath-libdir.patch to remove rpaths to libdir - rpmlint cleanup (#226395) tcp_wrappers-7.6-42.1.fc7 ------------------------- * Thu Mar 08 2007 Tomas Janousek - 7.6-42.1 - moved libwrap.so* to /lib - removed the static library libwrap.a usermode-1.89-1 --------------- * Fri Mar 09 2007 Miloslav Trmac - 1.89-1 - Preserve application exit code in consolehelper Resolves: #178991, #210893 - Drop the historical build6x spec file variable - Fix some rpmlint warnings * Mon Dec 11 2006 Martin Bacovsky - 1.88-3.el5 - Updated translations - Resolves: #216622 * Fri Dec 01 2006 Martin Bacovsky - 1.88-2.el5 - Updated translations - Resolves: #216622 xmlrpc-0:2.0.1-3jpp.2 --------------------- * Thu Mar 08 2007 Deepak Bhole 2.0.1-3jpp.2 - Add javax.net.ssl support to build org.apache.xmlrpc.secure.* - Minor spec file cleanup Broken deps for ia64 ---------------------------------------------------------- a2ps - 4.13b-62.fc7.ia64 requires liba2ps.so.1()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ia64 requires xdg-utils kdeaddons - 3.5.6-3.fc7.ia64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ia64 requires xdg-utils net-snmp-devel - 1:5.4-11.fc7.ia64 requires lm_sensors-devel Broken deps for i386 ---------------------------------------------------------- a2ps - 4.13b-62.fc7.i386 requires liba2ps.so.1 frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeaddons - 3.5.6-3.fc7.i386 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.i386 requires xdg-utils Broken deps for s390x ---------------------------------------------------------- a2ps - 4.13b-62.fc7.s390x requires liba2ps.so.1()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libofx.so.3()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.s390x requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeaddons - 3.5.6-3.fc7.s390x requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390x requires xdg-utils net-snmp-devel - 1:5.4-11.fc7.s390x requires lm_sensors-devel net-snmp-devel - 1:5.4-11.fc7.s390 requires lm_sensors-devel Broken deps for x86_64 ---------------------------------------------------------- a2ps - 4.13b-62.fc7.x86_64 requires liba2ps.so.1()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.x86_64 requires xdg-utils kdeaddons - 3.5.6-3.fc7.x86_64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.x86_64 requires xdg-utils Broken deps for ppc64 ---------------------------------------------------------- a2ps - 4.13b-62.fc7.ppc64 requires liba2ps.so.1()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ppc64 requires xdg-utils kdeaddons - 3.5.6-3.fc7.ppc64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ppc64 requires xdg-utils net-snmp-devel - 1:5.4-11.fc7.ppc64 requires lm_sensors-devel Broken deps for s390 ---------------------------------------------------------- a2ps - 4.13b-62.fc7.s390 requires liba2ps.so.1 gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeaddons - 3.5.6-3.fc7.s390 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390 requires xdg-utils net-snmp-devel - 1:5.4-11.fc7.s390 requires lm_sensors-devel 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 ---------------------------------------------------------- a2ps - 4.13b-62.fc7.ppc requires liba2ps.so.1 gnucash - 2.0.5-1.fc6.ppc requires libofx.so.3 gnucash - 2.0.5-1.fc6.ppc requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.ppc requires xdg-utils kdeaddons - 3.5.6-3.fc7.ppc requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ppc requires xdg-utils net-snmp-devel - 1:5.4-11.fc7.ppc requires lm_sensors-devel From opensource at till.name Fri Mar 9 11:18:14 2007 From: opensource at till.name (Till Maas) Date: Fri, 09 Mar 2007 12:18:14 +0100 Subject: gnash mock build and buildsys build differents? In-Reply-To: <20070309085419.GA2866@free.fr> References: <20070309085419.GA2866@free.fr> Message-ID: <200703091218.37969.opensource@till.name> On Fr M?rz 9 2007, Patrice Dumas wrote: > Do you have any idea what could cause this strange difference? What > can I do to debug further? Did you compare the build/root.log files from the buildsys and the mock build? 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 dwmw2 at infradead.org Fri Mar 9 11:32:19 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 09 Mar 2007 11:32:19 +0000 Subject: gnash mock build and buildsys build differents? In-Reply-To: <20070309085419.GA2866@free.fr> References: <20070309085419.GA2866@free.fr> Message-ID: <1173439940.3461.589.camel@pmac.infradead.org> On Fri, 2007-03-09 at 09:54 +0100, Patrice Dumas wrote: > I have a puzzling bug report for gnash: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217020 > > Seems that the gnash built by the buildsystem isn't the same than a > gnash build locally using mock?? The one built locally doesn't crash. > > Do you have any idea what could cause this strange difference? What > can I do to debug further? It's probably using autocrap, thus introducing arbitrary changes in behaviour dependent on the host system. Throw it away and write proper makefiles instead. :) -- dwmw2 From debarshi.ray at gmail.com Fri Mar 9 12:36:55 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 9 Mar 2007 18:06:55 +0530 Subject: pup: boon or curse? quicker updates or slower updates? In-Reply-To: <45F130EC.3050102@leemhuis.info> References: <1173387027.3038.6.camel@sb-home.lan> <1173399305.3461.538.camel@pmac.infradead.org> <3170f42f0703082327md9af697t9f9c8f9177da5307@mail.gmail.com> <45F113F9.2020009@leemhuis.info> <45F12DE5.2010609@rasmil.dk> <45F130EC.3050102@leemhuis.info> Message-ID: <3170f42f0703090436u7abdae98ucce13bc51db8eb0@mail.gmail.com> I would not quote anyone since the same point is being discussed simultaneously on three different threads. One argument that I constantly hear is that the packages in the Fedora repositories are so frequently updated that it is not advisable to keep a high value for 'metadata_expire' to ensure that Yum does not miss out on any recently available packages/updates. Although this sounds nice, but there is an inherent flaw in this argument, which becomes underlined when one uses it on slow networks. In places like India, Bangladesh, and maybe Africa too, not too many people are blessed with an Internet connection that can allow them to download the whole package list everytimebefore doing anything worthwhile with Yum (and Pirut). The fact is that _just_ installing a package is much more important than installing the _latest_ version of it. eg., my father does not really care if he uses version 2.2.3 of package Foo or version 2.2.5 of Foo. If he needs Bar, and can not do 'yum install bar' quickly enough simply because Yum needs to download the whole list of available updates, and find out whether Foo 2.2.5 is available or not, before starting to actually download and install Bar, then I am sure he would not like it. One more thing I heard is that people do not understand the 'apt-get update' and 'apt-get upgrade' dance. First of all someone who is using the command line interface and not the GUI, even when the GUI is available, is not a complete newbie. If he has the acumen to remember the 'cd', 'clear', 'ls', 'sudo yum', etc. dance then why can not he/she remember the 'apt-get update' and 'apt-get upgrade' dance? Even if it is still a problem, then consider that we have yum-updatesd downloading update information automatically in the background, and Yum itself engineered in such a way that it will download update information after 'metadata_expires' is reached. No matter how high the value of 'metadata_expires' is, this is simply not needed. If I am a newbie, and can not handle the 'apt-get update' and 'apt-get upgrade' dance, I will simply ask yum-updatesd to do the job for me. Provided, ofcourse, I have the bandwidth to do it efficiently. Otherwise, if I know my way around or have bandwidth issues, then I shall simply switch of yum-updatesd and resort to the apt-get update' and 'apt-get upgrade' dance. Secondly, since most newbies are prone to use GUI tools, if Pirut has a nice icon (like Synaptic) that prominently announces: "look for updates", then I do not think people have to remember any dance sequence at all. As far as I have seen, Ubuntu users (mostly newbies not knowing what 'ls' and 'clear' are) are so happy with their distribution simply because Synaptic precisely does this. I have not seen a single Pirut user who is even marginally content. If such a feature was removed to help any newbie, then it has surely failed to do so. Before finishing let me give my own example. The only repositories that I use are Fedora's Core, Updates and Extras; and ATRPMs. All these are mirrored locally on my LAN, and I do not use the upstream repositories ever, except for keeping the local ones updated. I do not run yum-updatesd too. On such a set-up when I start Pirut, it takes 15 seconds to show the initial window, which is the 'browse' (leftmost) tab. Funnily it has no package or category listed. When I click the 'list' (rightmost) tab it takes a further 60 seconds to show the package list. Everytime I change tabs and come back to 'list' it takes the same amount of time as before. Since I do not use a US English desktop the tabs might not be named exactly 'browse' and 'list', but that is what they look like from the local language traslation. I am basically an end-use when it comes to Yum and/or Pirut, but I know Python and do some programming and would like to help out regarding this if required. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From mlichvar at redhat.com Fri Mar 9 13:04:27 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Fri, 9 Mar 2007 14:04:27 +0100 Subject: RPATH status Message-ID: <20070309130427.GC23863@localhost> I've noticed that there are still many binaries in /usr/bin that have RPATH hardcoded in them. On a x86_64 full installation there are 470 binaries with /usr/lib64 in RPATH. That looks like a lot of work to have this fixed and maintained. Maybe a chrpath script could be used in the build process, and remove automatically the obvious cases like /usr/lib64, /usr/local/lib and @RPATH@ ? 470 /usr/lib64 47 /usr/lib64/lam 39 //usr/local/lib 20 /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE 13 /usr/lib64/mysql 12 /usr/lib64/htdig:/usr/lib64/htdig_db 7 @RPATH@ 7 /usr/lib64/openmpi 7 /usr/lib64/kde3 5 /usr/lib64:/usr/lib 4 /usr/lib64:/usr/lib64 4 /usr/lib64/fedora-ds 3 /usr/lib64/firefox-2.0.0.2 2 /usr/lib64/qt-3.3/lib:/usr/lib64:/usr/lib/kde3 2 /usr/lib64/evolution/2.10 1 /usr/lib64:/usr/lib64/qt-3.3/lib 1 /usr/lib64:/usr/lib64/firefox-2.0.0.2 1 /usr/lib64:/usr/lib/gcj-4.1.2 1 /usr/lib64:/lib64 1 /usr/lib64/xfce4/modules 1 /usr/lib64/quagga 1 /usr/lib64/qt-3.3/lib:/usr/lib64/kde3 1 /usr/lib64/octave-2.9.9 1 /usr/lib64/kazehakase:/usr/lib64/firefox-2.0.0.2 1 /usr/lib64/gthumb 1 /usr/lib64/graphviz 1 /usr/lib64/gnucash 1 /usr/lib64/gnome-commander 1 /usr/lib64/ecl 1 /usr/lib64/dia 1 /usr/lib64/brltty -- Miroslav Lichvar From faucamp at csir.co.za Fri Mar 9 13:42:37 2007 From: faucamp at csir.co.za (Francois Aucamp) Date: Fri, 09 Mar 2007 15:42:37 +0200 Subject: pup: boon or curse? quicker updates or slower updates? In-Reply-To: <45F1806D0200006A00011D23@cs-emo.csir.co.za> References: <45F1713D020000FA000070AC@cs-emo.csir.co.za> <45F1806D0200006A00011D23@cs-emo.csir.co.za> Message-ID: <45F1806D0200006A00011D23@cs-emo.csir.co.za> On Fri, 2007-03-09 at 18:06 +0530, Debarshi 'Rishi' Ray wrote: > First of all someone who is using the command line interface and not > the GUI, even when the GUI is available, is not a complete newbie. If > he has the acumen to remember the 'cd', 'clear', 'ls', 'sudo yum', > etc. dance then why can not he/she remember the 'apt-get update' and > 'apt-get upgrade' dance? > I suppose this is a fair enough assumption. But, unlike 'cd', 'ls', etc which perform _immediately-required_ actions, 'apt-get update' (from a semi-newbie point of view) does nothing tangible. (Think: "It's updating the repository information? What's that? Why is this needed? Why can't I just install the program?") So unlike the basic commandline commands, the "apt-get update" command gives no immediately obvious results to someone coming from, say, That Other OS. Explaining to them what "apt-get update" does is usually pointless, as they do not always understand and definitely don't care. They _just want it to work_. Oh, and you'd be surprised at how many "newbies" use/want to use the command line (see comments about the yum gui below)... > Even if it is still a problem, then consider that we have yum-updatesd > downloading update information automatically in the background, and > Yum itself engineered in such a way that it will download update > information after 'metadata_expires' is reached. No matter how high > the value of 'metadata_expires' is, this is simply not needed. If I am > a newbie, and can not handle the 'apt-get update' and 'apt-get > upgrade' dance, I will simply ask yum-updatesd to do the job for me. > Provided, ofcourse, I have the bandwidth to do it efficiently. > Otherwise, if I know my way around or have bandwidth issues, then I > shall simply switch of yum-updatesd and resort to the apt-get update' > and 'apt-get upgrade' dance. > Fair enough, but if you know what you're doing, then why not simply use something like "yum -C update"? This does the same as "apt-get upgrade", i.e. it runs from the local metadata cache. > Secondly, since most newbies are prone to use GUI tools, if Pirut has > a nice icon (like Synaptic) that prominently announces: "look for > updates", then I do not think people have to remember any dance > sequence at all. As far as I have seen, Ubuntu users (mostly newbies > not knowing what 'ls' and 'clear' are) are so happy with their > distribution simply because Synaptic precisely does this. I have not > seen a single Pirut user who is even marginally content. If such a > feature was removed to help any newbie, then it has surely failed to > do so. > > Before finishing let me give my own example. The only repositories > that I use are Fedora's Core, Updates and Extras; and ATRPMs. All > these are mirrored locally on my LAN, and I do not use the upstream > repositories ever, except for keeping the local ones updated. I do not > run yum-updatesd too. On such a set-up when I start Pirut, it takes 15 > seconds to show the initial window, which is the 'browse' (leftmost) > tab. Funnily it has no package or category listed. When I click the > 'list' (rightmost) tab it takes a further 60 seconds to show the > package list. Everytime I change tabs and come back to 'list' it takes > the same amount of time as before. Since I do not use a US English > desktop the tabs might not be named exactly 'browse' and 'list', but > that is what they look like from the local language traslation. I agree, Pirut's "lag time" is a pain, and as a whole the GUI isn't as streamlined as Ubuntu's GUI update manager (synaptic with a "friendlier" starting point). It's "list-page slowness" has some more problems than just a "yum update"-induced issue, however; imho this needs _desperately_ needs to be looked at. Some of our newbie users actually prefer the yum-cli because of this. I submitted a "concept" patch a while back that allows "off-line" and "non-root" usage of Pirut (amongst some other things) - this same technique could be used to lessen the metadata-update requirements of the GUI, at least. Interestingly enough, we are running a very similar setup. I, however, use a managed mix of core, updates, extras, livna, rpmforge, kde-redhat, freshrpms and dribble, and all our local machines update from a centralized cache. As you can guess, this cache serves a fairly large amount of machines. Explaining basic repository management (read: apt-get update; apt-get upgrade or apt-get update, apt-get install X) to _all_ of the people becomes a bit of a drag when a single "yum update" or "yum install" command is enough. This is the same with Synaptic; the package metadata gets old eventually (however it does prompt the user when this happens, which is nice). > I am basically an end-use when it comes to Yum and/or Pirut, but I > know Python and do some programming and would like to help out > regarding this if required. > Me too. Is there some (clear) way that the community can get more involved in Pirut/yum's development (outside of only writing yum plugins)? To summarise: I agree with almost everything you are saying (especially the GUI-related stuff), I just feel that yum's _default_ behaviour should not necessarily be similar to apt's. :-) Cheers, -Francois -- This message is subject to the CSIR's copyright, terms and conditions and e-mail legal notice. Views expressed herein do not necessarily represent the views of the CSIR. CSIR E-mail Legal Notice http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html CSIR Copyright, Terms and Conditions http://mail.csir.co.za/CSIR_Copyright.html For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR Legal Notice send a blank message with REQUEST LEGAL in the subject line to CallCentre at csir.co.za. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From fedora at camperquake.de Fri Mar 9 13:43:40 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 9 Mar 2007 14:43:40 +0100 Subject: RPATH status In-Reply-To: <20070309130427.GC23863@localhost> References: <20070309130427.GC23863@localhost> Message-ID: <20070309144340.4528c728@banea.int.addix.net> Hi. On Fri, 9 Mar 2007 14:04:27 +0100, Miroslav Lichvar wrote: > On a x86_64 full installation there are 470 binaries with /usr/lib64 > in RPATH. That looks like a lot of work to have this fixed and > maintained. Maybe a chrpath script could be used in the build process, > and remove automatically the obvious cases like /usr/lib64, > /usr/local/lib and @RPATH@ ? The right way would be to file bugs against the packages, I think. From skvidal at linux.duke.edu Fri Mar 9 13:49:22 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 09 Mar 2007 08:49:22 -0500 Subject: pup: boon or curse? quicker updates or slower updates? In-Reply-To: <45F1806D0200006A00011D23@cs-emo.csir.co.za> References: <45F1713D020000FA000070AC@cs-emo.csir.co.za> <45F1806D0200006A00011D23@cs-emo.csir.co.za> <45F1806D0200006A00011D23@cs-emo.csir.co.za> Message-ID: <1173448162.20206.170.camel@cutter> On Fri, 2007-03-09 at 15:42 +0200, Francois Aucamp wrote: > > I am basically an end-use when it comes to Yum and/or Pirut, but I > > know Python and do some programming and would like to help out > > regarding this if required. > > > > Me too. Is there some (clear) way that the community can get more > involved in Pirut/yum's development (outside of only writing yum > plugins)? there is a yum-devel list: https://lists.dulug.duke.edu/mailman/listinfo/yum-devel and to be clear, giant emails explaining what we should be working on aren't really all that helpful, we have more than enough of those. If you want to work on pieces of yum then the code is there, work on it and send patches. That's how everyone else has gotten involved. But don't work on the version in FC6 - make sure you're working on the latest cvs. thanks! -sv From benny+usenet at amorsen.dk Fri Mar 9 13:48:45 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 09 Mar 2007 14:48:45 +0100 Subject: announce: readahead-1.4 References: <20070301105026.GF4449@petra.dvoda.cz> <883cfe6d0703051442v2d74ebe8w6ef1764cd659cbd5@mail.gmail.com> <1173275392.3617.6.camel@max.booze> <20070307135206.08f1cb6e@banea.int.addix.net> <1173310709.3617.84.camel@max.booze> Message-ID: >>>>> "CL" == Callum Lerwick writes: CL> I don't see how they could patent defragging a disk. Lets not get CL> crazy here. ext3 does a decent job of not fragmenting files CL> unnecessarily, can we really gain much more than the current CL> readahead solution? I think the operative word here is "unnecessarily". Desktop hard drives stay full once they fill up. Very few people clear off more than 20% once they've run out of disk space. Linux is better than most at avoiding fragmentation, but no (non-repacking) algorithm works well when only 5-20% disk space remains. I really wish ext3 had a defrag utility which worked. /Benny From fedora at leemhuis.info Fri Mar 9 14:14:58 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 09 Mar 2007 15:14:58 +0100 Subject: RPATH status In-Reply-To: <20070309144340.4528c728@banea.int.addix.net> References: <20070309130427.GC23863@localhost> <20070309144340.4528c728@banea.int.addix.net> Message-ID: <45F16BE2.9010806@leemhuis.info> On 09.03.2007 14:43, Ralf Ertzinger wrote: > On Fri, 9 Mar 2007 14:04:27 +0100, Miroslav Lichvar wrote: > >> On a x86_64 full installation there are 470 binaries with /usr/lib64 >> in RPATH. That looks like a lot of work to have this fixed and >> maintained. Maybe a chrpath script could be used in the build process, >> and remove automatically the obvious cases like /usr/lib64, >> /usr/local/lib and @RPATH@ ? > The right way would be to file bugs against the packages, I think. The right way IMHO would be to enable the rpath checks on the buildsys, so the build fails if rpath show up that are not whitelisted in the spec file. Then way people notice the rpath and in most cases fix them; new rpath further get noticed immediately, and we all save time as we don#t have to file bugs :-) . The checks are *iirc* enabled for the Extras builders. We should make sure they get enabled for the new Fedora builders, too. CU thl From linux_4ever at yahoo.com Fri Mar 9 14:15:15 2007 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 9 Mar 2007 06:15:15 -0800 (PST) Subject: Selinux and hal In-Reply-To: <45F13587.5020007@zoeloelip.be> Message-ID: <184461.29654.qm@web51515.mail.yahoo.com> >I had to kill auditd when it used 58% of my 1GB ram. For a daemon that has to >do some logging this is quite extreme. I'd agree. What version are you using? >Has anyone else seen this problem? You discuss 2 problems. I'd say you should file 2 bugs. One for policy and one for auditd memory consumption. -Steve ____________________________________________________________________________________ Get your own web address. Have a HUGE year through Yahoo! Small Business. http://smallbusiness.yahoo.com/domains/?p=BESTDEAL From j.w.r.degoede at hhs.nl Fri Mar 9 14:18:36 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 09 Mar 2007 15:18:36 +0100 Subject: RPATH status In-Reply-To: <45F16BE2.9010806@leemhuis.info> References: <20070309130427.GC23863@localhost> <20070309144340.4528c728@banea.int.addix.net> <45F16BE2.9010806@leemhuis.info> Message-ID: <45F16CBC.2020007@hhs.nl> Thorsten Leemhuis wrote: > On 09.03.2007 14:43, Ralf Ertzinger wrote: >> On Fri, 9 Mar 2007 14:04:27 +0100, Miroslav Lichvar wrote: >> >>> On a x86_64 full installation there are 470 binaries with /usr/lib64 >>> in RPATH. That looks like a lot of work to have this fixed and >>> maintained. Maybe a chrpath script could be used in the build process, >>> and remove automatically the obvious cases like /usr/lib64, >>> /usr/local/lib and @RPATH@ ? >> The right way would be to file bugs against the packages, I think. > > The right way IMHO would be to enable the rpath checks on the buildsys, > so the build fails if rpath show up that are not whitelisted in the spec > file. Then way people notice the rpath and in most cases fix them; new > rpath further get noticed immediately, and we all save time as we don#t > have to file bugs :-) . > > The checks are *iirc* enabled for the Extras builders. We should make > sure they get enabled for the new Fedora builders, too. > rpmlint catches this, I'm sitll in favor of running rpmlint after a build, check the output against a whitelist of allowed output and if there is any output not in the whitelist, fail the build. We would need to integrate the same use of rpmlint in make from makefile.common then (or maybe first). Regards, Hans From fedora at camperquake.de Fri Mar 9 14:21:01 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 9 Mar 2007 15:21:01 +0100 Subject: RPATH status In-Reply-To: <45F16CBC.2020007@hhs.nl> References: <20070309130427.GC23863@localhost> <20070309144340.4528c728@banea.int.addix.net> <45F16BE2.9010806@leemhuis.info> <45F16CBC.2020007@hhs.nl> Message-ID: <20070309152101.5e31837e@banea.int.addix.net> Hi. On Fri, 09 Mar 2007 15:18:36 +0100, Hans de Goede wrote: > rpmlint catches this, I'm sitll in favor of running rpmlint after a > build, check the output against a whitelist of allowed output and if > there is any output not in the whitelist, fail the build. We would > need to integrate the same use of rpmlint in make from > makefile.common then (or maybe first). Livna does this already. Fine with me. From linux_4ever at yahoo.com Fri Mar 9 14:27:57 2007 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 9 Mar 2007 06:27:57 -0800 (PST) Subject: announce: readahead-1.4 In-Reply-To: Message-ID: <183479.55792.qm@web51509.mail.yahoo.com> >Desktop hard drives stay full once they fill up. Very few people clear off >more than 20% once they've run out of disk space. I wonder if there's a way to clear out non-SE Linux xattrs? I wonder how much diskspace tools like beagle consume by putting stuff in xattrs. If you uninstall it, how do you get that space back? -Steve ____________________________________________________________________________________ No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail From selinux at gmail.com Fri Mar 9 14:33:05 2007 From: selinux at gmail.com (Tom London) Date: Fri, 9 Mar 2007 06:33:05 -0800 Subject: rawhide report: 20070309 changes In-Reply-To: <200703091046.l29Ak6Ei003410@hs20-bc2-6.build.redhat.com> References: <200703091046.l29Ak6Ei003410@hs20-bc2-6.build.redhat.com> Message-ID: <4c4ba1530703090633s1c760057g48745ee1f1963c77@mail.gmail.com> On 3/9/07, buildsys at redhat.com wrote: > kernel-2.6.20-1.2981.fc7 > ------------------------ > * Thu Mar 08 2007 Dave Jones > - update to squashfs 3.2-r2 > > * Thu Mar 08 2007 Dave Jones > - update to latest utrace. > > * Thu Mar 08 2007 John W. Linville > - update git-wireless-dev.patch (current as of 2007-03-06) > Every kernel after .2925 (up to .2975) has produced either NMIs or hard lockups on my Thinkpad X60 if I enable/use the e1000 interface. The system appears rock solid if I disconnect the e1000 and use the ipw3945 interface, or if I revert back to .2925. I've BZ'ed this here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 Anyone else seeing this? Any known issues with the 2.6.21 line that could be causing this? How to BZ better? tom -- Tom London From fedora at camperquake.de Fri Mar 9 14:42:07 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 9 Mar 2007 15:42:07 +0100 Subject: rawhide report: 20070309 changes In-Reply-To: <4c4ba1530703090633s1c760057g48745ee1f1963c77@mail.gmail.com> References: <200703091046.l29Ak6Ei003410@hs20-bc2-6.build.redhat.com> <4c4ba1530703090633s1c760057g48745ee1f1963c77@mail.gmail.com> Message-ID: <20070309154207.2601031f@banea.int.addix.net> Hi. On Fri, 9 Mar 2007 06:33:05 -0800, Tom London wrote: > Every kernel after .2925 (up to .2975) has produced either NMIs or > hard lockups on my Thinkpad X60 if I enable/use the e1000 interface. Hah! So I am not the only one. Thanks for that. So my hardware is probably sound. > The system appears rock solid if I disconnect the e1000 and use the > ipw3945 interface, or if I revert back to .2925. > > I've BZ'ed this here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 > > Anyone else seeing this? It _seems_ to go away if I lock the CPU to a fixed speed instead of letting ondemand switch the frequencies around. From debarshi.ray at gmail.com Fri Mar 9 14:42:32 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Fri, 9 Mar 2007 20:12:32 +0530 Subject: pup: boon or curse? quicker updates or slower updates? In-Reply-To: <45F1806D0200006A00011D23@cs-emo.csir.co.za> References: <45F1713D020000FA000070AC@cs-emo.csir.co.za> <45F1806D0200006A00011D23@cs-emo.csir.co.za> <45F1806D0200006A00011D23@cs-emo.csir.co.za> Message-ID: <3170f42f0703090642o592712c2me0370bde48da360@mail.gmail.com> > I suppose this is a fair enough assumption. But, unlike 'cd', 'ls', etc > which perform _immediately-required_ actions, 'apt-get update' (from a > semi-newbie point of view) does nothing tangible. (Think: "It's updating > the repository information? What's that? Why is this needed? Why can't I > just install the program?") So unlike the basic commandline commands, > the "apt-get update" command gives no immediately obvious results to > someone coming from, say, That Other OS. Explaining to them what > "apt-get update" does is usually pointless, as they do not always > understand and definitely don't care. They _just want it to work_. Such people should be using the GUI, and not the CLI. If the GUI prompts that the metadata has gone stale then it can prompt the user nicely. Maybe Puplet can do something like this. At the same time you do not realise how painful it is to explain to people why Yum is so slow in starting to do something than apt or Synaptic. Forget about Windoze users, even existing GNU/Linux (read Ubuntu) users are not convinced about Yum. > Oh, and you'd be surprised at how many "newbies" use/want to use the > command line (see comments about the yum gui below)... Then the GUI needs to be fixed. :-) No use asking the CLI to cover up for that. > Fair enough, but if you know what you're doing, then why not simply use > something like "yum -C update"? This does the same as "apt-get upgrade", > i.e. it runs from the local metadata cache. I was just informed by Jeff Spaleta on a private mail that the introduction of metadata_expire has almost obsoleted the use of 'yum -C...'. Moreover I read that 'yum -C...' needs the packages to be present in the cache too. Thus it is only useful for 'yum list', 'yum search', etc.. Regards, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From selinux at gmail.com Fri Mar 9 14:55:19 2007 From: selinux at gmail.com (Tom London) Date: Fri, 9 Mar 2007 06:55:19 -0800 Subject: rawhide report: 20070309 changes In-Reply-To: <20070309154207.2601031f@banea.int.addix.net> References: <200703091046.l29Ak6Ei003410@hs20-bc2-6.build.redhat.com> <4c4ba1530703090633s1c760057g48745ee1f1963c77@mail.gmail.com> <20070309154207.2601031f@banea.int.addix.net> Message-ID: <4c4ba1530703090655sf93cf61o846d53e60f42acb2@mail.gmail.com> On 3/9/07, Ralf Ertzinger wrote: > Hi. > > On Fri, 9 Mar 2007 06:33:05 -0800, Tom London wrote: > > > Every kernel after .2925 (up to .2975) has produced either NMIs or > > hard lockups on my Thinkpad X60 if I enable/use the e1000 interface. > > Hah! So I am not the only one. Thanks for that. So my hardware is > probably sound. > I'm not the only one too!! I was already trying to figure out how to replace the NIC (not really easy, it turns out). > > The system appears rock solid if I disconnect the e1000 and use the > > ipw3945 interface, or if I revert back to .2925. > > > > I've BZ'ed this here: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 > > > > Anyone else seeing this? > > It _seems_ to go away if I lock the CPU to a fixed speed instead of letting > ondemand switch the frequencies around. > I'll try nailing down ondemand. Thanks for this....I've been running off the wireless for a while...... tom -- Tom London From pknirsch at redhat.com Fri Mar 9 15:48:01 2007 From: pknirsch at redhat.com (Phil Knirsch) Date: Fri, 09 Mar 2007 16:48:01 +0100 Subject: Installation order of basesystem, filesystem and setup. In-Reply-To: <20070302171539.GC9050@nostromo.devel.redhat.com> References: <45E843BF.4080201@redhat.com> <200703021042.44445.jkeating@redhat.com> <20070302160627.GA12143@suse.de> <200703021135.46733.jkeating@redhat.com> <45E856F7.4040502@redhat.com> <20070302171539.GC9050@nostromo.devel.redhat.com> Message-ID: <45F181B1.9060109@redhat.com> Bill Nottingham wrote: > Phil Knirsch (pknirsch at redhat.com) said: >> Final option ofc would be to just change the description ofc (doh!) and >> be done with it. >> >> Like: >> >> Basesystem defines the components of a basic Fedora system (for >> example, the package installation order to use during bootstrapping). >> Basesystem should be in every installation of a system, and it >> should never be removed. >> >> How's that? > > I like that solution. Don't touch the seven deadly packages! > > Bill > Done :) Read ya, Phil /me wonders what the other 6 deadly packages are and is afraid. very afraid. :) -- Philipp Knirsch | Tel.: +49-711-96437-470 Development | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.de/ D-70178 Stuttgart Motd: You're only jealous cos the little penguins are talking to me. From fedora at leemhuis.info Fri Mar 9 16:06:53 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 09 Mar 2007 17:06:53 +0100 Subject: RPATH status In-Reply-To: <45F16CBC.2020007@hhs.nl> References: <20070309130427.GC23863@localhost> <20070309144340.4528c728@banea.int.addix.net> <45F16BE2.9010806@leemhuis.info> <45F16CBC.2020007@hhs.nl> Message-ID: <45F1861D.4020604@leemhuis.info> Hans de Goede schrieb: > Thorsten Leemhuis wrote: >> On 09.03.2007 14:43, Ralf Ertzinger wrote: >>> On Fri, 9 Mar 2007 14:04:27 +0100, Miroslav Lichvar wrote: >>>> On a x86_64 full installation there are 470 binaries with /usr/lib64 >>>> in RPATH. That looks like a lot of work to have this fixed and >>>> maintained. Maybe a chrpath script could be used in the build process, >>>> and remove automatically the obvious cases like /usr/lib64, >>>> /usr/local/lib and @RPATH@ ? >>> The right way would be to file bugs against the packages, I think. >> The right way IMHO would be to enable the rpath checks on the buildsys, >> so the build fails if rpath show up that are not whitelisted in the spec >> file. Then way people notice the rpath and in most cases fix them; new >> rpath further get noticed immediately, and we all save time as we don#t >> have to file bugs :-) . >> The checks are *iirc* enabled for the Extras builders. We should make >> sure they get enabled for the new Fedora builders, too. > rpmlint catches this, I'm sitll in favor of running rpmlint after a build, > check the output against a whitelist of allowed output and if there is any > output not in the whitelist, fail the build. We would need to integrate the > same use of rpmlint in make from makefile.common then (or maybe first). Sounds fine, too. Cu thl From pertusus at free.fr Fri Mar 9 16:39:44 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 17:39:44 +0100 Subject: gnash mock build and buildsys build differents? In-Reply-To: <1173439940.3461.589.camel@pmac.infradead.org> References: <20070309085419.GA2866@free.fr> <1173439940.3461.589.camel@pmac.infradead.org> Message-ID: <20070309163944.GA25722@free.fr> On Fri, Mar 09, 2007 at 11:32:19AM +0000, David Woodhouse wrote: > > It's probably using autocrap, thus introducing arbitrary changes in > behaviour dependent on the host system. Throw it away and write proper > makefiles instead. :) gnash has lots of dependencies and is quite big, using autotools is quite helpful in that case. However, detection of some libs is done by poking in the filesystem, maybe it is the cause of this issue. -- Pat From caillon at redhat.com Fri Mar 9 16:58:57 2007 From: caillon at redhat.com (Christopher Aillon) Date: Fri, 09 Mar 2007 11:58:57 -0500 Subject: RPATH status In-Reply-To: <20070309130427.GC23863@localhost> References: <20070309130427.GC23863@localhost> Message-ID: <45F19251.5060706@redhat.com> Miroslav Lichvar wrote: > I've noticed that there are still many binaries in /usr/bin that have > RPATH hardcoded in them. > 3 /usr/lib64/firefox-2.0.0.2 Some of them are intentional, such as the above. It's either rpath or munging LD_LIBRARY_PATH at startup if you want a working firefox. From jonathan.underwood at gmail.com Fri Mar 9 17:01:00 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Fri, 9 Mar 2007 17:01:00 +0000 Subject: RPATH status In-Reply-To: <45F16CBC.2020007@hhs.nl> References: <20070309130427.GC23863@localhost> <20070309144340.4528c728@banea.int.addix.net> <45F16BE2.9010806@leemhuis.info> <45F16CBC.2020007@hhs.nl> Message-ID: <645d17210703090901w1e886572l6f20968548fe4cd8@mail.gmail.com> On 09/03/07, Hans de Goede wrote: > rpmlint catches this, I'm sitll in favor of running rpmlint after a build, > check the output against a whitelist of allowed output and if there is any > output not in the whitelist, fail the build. We would need to integrate the > same use of rpmlint in make from makefile.common then (or maybe first). Fantastic proposal. An added benefit would be that would be one step closer to having part of the new package review process automated. If there was a build machine where new package SRPMS could be pushed to (perhaps even via a web interface) which would then try to build the package inside mock, run rpmlint on resulting packages, and make avilable all logs and output (also perhaps via a web page), then package review pace would greatly increase, I suspect. From pertusus at free.fr Fri Mar 9 16:59:40 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 17:59:40 +0100 Subject: accessing old build logs Message-ID: <20070309165940.GC25722@free.fr> Hello, I would like to access the build logs of gnash. I remember that I found a place where all the build logs were kept (if I recall well) but I couldn't find a place where it is documented in the wiki. Thoughts? -- Pat From a.badger at gmail.com Fri Mar 9 17:25:27 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 09 Mar 2007 09:25:27 -0800 Subject: accessing old build logs In-Reply-To: <20070309165940.GC25722@free.fr> References: <20070309165940.GC25722@free.fr> Message-ID: <1173461127.3329.178.camel@localhost.localdomain> On Fri, 2007-03-09 at 17:59 +0100, Patrice Dumas wrote: > Hello, > > I would like to access the build logs of gnash. I remember that I found > a place where all the build logs were kept (if I recall well) but I > couldn't find a place where it is documented in the wiki. > http://buildsys.fedoraproject.org/plague-results/ If you'd care to document that on the wiki where you think it makes sense, that would be appreciated. * Note that logs are currently deleted after a period of time. I don't know how long or where koji (the new buildsystem) will store logs. -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 wtogami at redhat.com Fri Mar 9 17:35:32 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 09 Mar 2007 12:35:32 -0500 Subject: Thread Hijack - Our package management GUI tools need improvement In-Reply-To: <45F12B14.9060409@rasmil.dk> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> Message-ID: <45F19AE4.3030001@redhat.com> Tim Lauridsen wrote: > 6. Download needed packages. > 6. Depends on the size of the packages to be downloaded, network > bandwidth and the how fast the mirrors are. Two things could improve package downloading... 1) apt-get can download packages in parallel from multiple mirrors. This doesn't help everyone, but it does help in many cases where your personal bandwidth is much larger than the limited rate from a single mirror. Could this be implemented as a yum plugin? I dunno. 2) Ahmed Kamal has been working on a potentially sane implementation of deltarpm for Fedora's yum. Theoretically, it would work as an optional yum plugin. If the deltarpm is substantially smaller than an RPM update, then the deltarpm is provided on a mirror. If the deltarpm is not provided, then yum downloads the original RPM instead. If it downloaded a deltarpm, it reconstructs the original RPM and uses GPG to verify integrity just like yum would verify plain RPM downloads. Ahmed probably could use some developer and testing help. I've been encouraging him to be more communicative about his project in order to get more help, but I haven't seen any further outreach lately. Warren Togami wtogami at redhat.com From pertusus at free.fr Fri Mar 9 17:34:07 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 18:34:07 +0100 Subject: accessing old build logs In-Reply-To: <1173461127.3329.178.camel@localhost.localdomain> References: <20070309165940.GC25722@free.fr> <1173461127.3329.178.camel@localhost.localdomain> Message-ID: <20070309173407.GF25722@free.fr> On Fri, Mar 09, 2007 at 09:25:27AM -0800, Toshio Kuratomi wrote: > On Fri, 2007-03-09 at 17:59 +0100, Patrice Dumas wrote: > > Hello, > > > > I would like to access the build logs of gnash. I remember that I found > > a place where all the build logs were kept (if I recall well) but I > > couldn't find a place where it is documented in the wiki. > > > http://buildsys.fedoraproject.org/plague-results/ > > If you'd care to document that on the wiki where you think it makes > sense, that would be appreciated. I have added it at the end of http://fedoraproject.org/wiki/Extras/BuildSystemClientSetup > * Note that logs are currently deleted after a period of time. I don't > know how long or where koji (the new buildsystem) will store logs. The build logs kept today are not kept for a long time since there is nothing older than 06-Mar-2007. I guess I'll have to do a rebuild just to have the logs... -- Pat From vonbrand at inf.utfsm.cl Fri Mar 9 17:47:51 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Fri, 09 Mar 2007 14:47:51 -0300 Subject: rawhide report: 20070309 changes In-Reply-To: <4c4ba1530703090633s1c760057g48745ee1f1963c77@mail.gmail.com> References: <200703091046.l29Ak6Ei003410@hs20-bc2-6.build.redhat.com> <4c4ba1530703090633s1c760057g48745ee1f1963c77@mail.gmail.com> Message-ID: <18482.1173462471@laptop13.inf.utfsm.cl> Tom London wrote: > On 3/9/07, buildsys at redhat.com wrote: > > kernel-2.6.20-1.2981.fc7 > > ------------------------ > > * Thu Mar 08 2007 Dave Jones > > - update to squashfs 3.2-r2 > > > > * Thu Mar 08 2007 Dave Jones > > - update to latest utrace. > > > > * Thu Mar 08 2007 John W. Linville > > - update git-wireless-dev.patch (current as of 2007-03-06) > Every kernel after .2925 (up to .2975) has produced either NMIs or > hard lockups on my Thinkpad X60 if I enable/use the e1000 interface. Here I've got a Toshiba with the same network card. No problems at all. (currently running kernel-2.6.20-1.2975.fc7) -- 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 mschwendt.tmp0701.nospam at arcor.de Fri Mar 9 18:02:30 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 9 Mar 2007 19:02:30 +0100 Subject: accessing old build logs In-Reply-To: <20070309165940.GC25722@free.fr> References: <20070309165940.GC25722@free.fr> Message-ID: <20070309190230.9e1c46db.mschwendt.tmp0701.nospam@arcor.de> On Fri, 9 Mar 2007 17:59:40 +0100, Patrice Dumas wrote: > Hello, > > I would like to access the build logs of gnash. I remember that I found > a place where all the build logs were kept (if I recall well) but I > couldn't find a place where it is documented in the wiki. > > Thoughts? http://buildsys.fedoraproject.org/logs/ With the warning that empty directories are not removed automatically. I have a script for that, but haven't found the time to examine plague on where to add it. From mlichvar at redhat.com Fri Mar 9 18:04:18 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Fri, 9 Mar 2007 19:04:18 +0100 Subject: RPATH status In-Reply-To: <45F19251.5060706@redhat.com> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> Message-ID: <20070309180418.GA26749@localhost> On Fri, Mar 09, 2007 at 11:58:57AM -0500, Christopher Aillon wrote: > Miroslav Lichvar wrote: > >I've noticed that there are still many binaries in /usr/bin that have > >RPATH hardcoded in them. > > > > 3 /usr/lib64/firefox-2.0.0.2 > > Some of them are intentional, such as the above. It's either rpath or > munging LD_LIBRARY_PATH at startup if you want a working firefox. BTW, the current packaging guidelines don't permit rpath at all and suggest to put a config in /etc/ld.so.conf.d/, but that doesn't look right in this case. I guess rpath for plugins/modules should be allowed. -- Miroslav Lichvar From pertusus at free.fr Fri Mar 9 18:08:08 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Mar 2007 19:08:08 +0100 Subject: accessing old build logs In-Reply-To: <20070309190230.9e1c46db.mschwendt.tmp0701.nospam@arcor.de> References: <20070309165940.GC25722@free.fr> <20070309190230.9e1c46db.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070309180808.GI25722@free.fr> On Fri, Mar 09, 2007 at 07:02:30PM +0100, Michael Schwendt wrote: > On Fri, 9 Mar 2007 17:59:40 +0100, Patrice Dumas wrote: > > > Hello, > > > > I would like to access the build logs of gnash. I remember that I found > > a place where all the build logs were kept (if I recall well) but I > > couldn't find a place where it is documented in the wiki. > > > > Thoughts? > > http://buildsys.fedoraproject.org/logs/ Thanks. I will update the wiki. Seems like builds date back to january. Still too short for my build. -- Pat From jdieter at gmail.com Fri Mar 9 18:17:52 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Fri, 09 Mar 2007 20:17:52 +0200 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <45F19AE4.3030001@redhat.com> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> Message-ID: <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> On Fri, 2007-03-09 at 12:35 -0500, Warren Togami wrote: > 2) Ahmed Kamal has been working on a potentially sane implementation of > deltarpm for Fedora's yum. Theoretically, it would work as an optional > yum plugin. If the deltarpm is substantially smaller than an RPM > update, then the deltarpm is provided on a mirror. If the deltarpm is > not provided, then yum downloads the original RPM instead. If it > downloaded a deltarpm, it reconstructs the original RPM and uses GPG to > verify integrity just like yum would verify plain RPM downloads. > > Ahmed probably could use some developer and testing help. I've been > encouraging him to be more communicative about his project in order to > get more help, but I haven't seen any further outreach lately. > > Warren Togami > wtogami at redhat.com > I've been working with Ahmed and Michael Schroeder (the upstream maintainer of deltarpm) to track down some long-standing bugs in deltarpm, especially as it relates to prelinked binaries. These bugs were causing very odd problems while working with the yum-deltarpm plugin. We *think* we've found them all (the patches are in the latest Rawhide version of deltarpm in Extras), so I think we're at the point where what we really need is someone who would be willing to create drpms of all new packages in Core and Extras (there's a modified version of prunerepo that does all the work for you), and host them for us. To give you an idea of the savings we're looking at: * kdebase-3.5.5-0.4.fc6 => kdebase-3.5.6-0.1.fc6 = 3.5MB vs. 30.2MB * kdegames-3.5.5-0.1.fc6 => kdegames-3.5.6-0.1.fc6 = 740KB vs. 11.1MB * OO.o-core-2.0.4-5.5.3 => OO.o-core-2.0.4-5.5.10 = 8.7MB vs. 92.4 MB There won't be that kind of savings for all the packages, but a general rule of the thumb is that the bigger the package, the better the chance that we'll get a good compression ratio on the drpm. Ahmed, do you have anything to add? -------------- 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 email.ahmedkamal at googlemail.com Fri Mar 9 19:18:46 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Fri, 9 Mar 2007 21:18:46 +0200 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> Message-ID: <3da3b5b40703091118p71d0b075gb80095eccdca5449@mail.gmail.com> Since Warren blew up my cover, please find more details at the project's hosted page :) https://hosted.fedoraproject.org/projects/presto As mentioned presto tries to be a sane implementation of a delta rpm update mechanism The "GuideLines" part, describes replies to common failures in previous implementations, and why people thought presto was a bad idea A delta rpm update mechanism also enables fedora to issue faster/smaller updates consisting of mainly translation/documentation updates as has been recently requested. Progress has been a bit slow, mostly because my boss is keeping me busy, but as Jonathan mentioned, testing is what's mostly needed now! Basically, I'm thinking instead of just calling for testers, we can setup some sort of a regression which would setup a FC6 machine with out-dated packages. Run prelink on that machine (This has been causing us some pain). Then use yum-drpm to update the machine, and record any failures ... if it seems well, go ahead with public testing. What do you guys think? And since this is the yum bitching thread, when I switched from ubuntu to fedora, I thought yum was molasses! Now, I've mostly forgot how fast apt-get was! On 3/9/07, Jonathan Dieter wrote: > > On Fri, 2007-03-09 at 12:35 -0500, Warren Togami wrote: > > 2) Ahmed Kamal has been working on a potentially sane implementation of > > deltarpm for Fedora's yum. Theoretically, it would work as an optional > > yum plugin. If the deltarpm is substantially smaller than an RPM > > update, then the deltarpm is provided on a mirror. If the deltarpm is > > not provided, then yum downloads the original RPM instead. If it > > downloaded a deltarpm, it reconstructs the original RPM and uses GPG to > > verify integrity just like yum would verify plain RPM downloads. > > > > Ahmed probably could use some developer and testing help. I've been > > encouraging him to be more communicative about his project in order to > > get more help, but I haven't seen any further outreach lately. > > > > Warren Togami > > wtogami at redhat.com > > > I've been working with Ahmed and Michael Schroeder (the upstream > maintainer of deltarpm) to track down some long-standing bugs in > deltarpm, especially as it relates to prelinked binaries. These bugs > were causing very odd problems while working with the yum-deltarpm > plugin. > > We *think* we've found them all (the patches are in the latest Rawhide > version of deltarpm in Extras), so I think we're at the point where what > we really need is someone who would be willing to create drpms of all > new packages in Core and Extras (there's a modified version of prunerepo > that does all the work for you), and host them for us. > > To give you an idea of the savings we're looking at: > * kdebase-3.5.5-0.4.fc6 => kdebase-3.5.6-0.1.fc6 = 3.5MB vs. 30.2MB > * kdegames-3.5.5-0.1.fc6 => kdegames-3.5.6-0.1.fc6 = 740KB vs. 11.1MB > * OO.o-core-2.0.4-5.5.3 => OO.o-core-2.0.4-5.5.10 = 8.7MB vs. 92.4 MB > There won't be that kind of savings for all the packages, but a general > rule of the thumb is that the bigger the package, the better the chance > that we'll get a good compression ratio on the drpm. > > Ahmed, do you have anything to add? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From selinux at gmail.com Fri Mar 9 19:20:13 2007 From: selinux at gmail.com (Tom London) Date: Fri, 9 Mar 2007 11:20:13 -0800 Subject: rawhide report: 20070309 changes In-Reply-To: <20070309154207.2601031f@banea.int.addix.net> References: <200703091046.l29Ak6Ei003410@hs20-bc2-6.build.redhat.com> <4c4ba1530703090633s1c760057g48745ee1f1963c77@mail.gmail.com> <20070309154207.2601031f@banea.int.addix.net> Message-ID: <4c4ba1530703091120w60b90aablb8a0733832dab82d@mail.gmail.com> On 3/9/07, Ralf Ertzinger wrote: > Hi. > > On Fri, 9 Mar 2007 06:33:05 -0800, Tom London wrote: > > > Every kernel after .2925 (up to .2975) has produced either NMIs or > > hard lockups on my Thinkpad X60 if I enable/use the e1000 interface. > > Hah! So I am not the only one. Thanks for that. So my hardware is > probably sound. > > > The system appears rock solid if I disconnect the e1000 and use the > > ipw3945 interface, or if I revert back to .2925. > > > > I've BZ'ed this here: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 > > > > Anyone else seeing this? > > It _seems_ to go away if I lock the CPU to a fixed speed instead of letting > ondemand switch the frequencies around. > Got a freeze with system locked at 1.33GHz. Trying now @1GHz. tom -- Tom London From rnorwood at redhat.com Fri Mar 9 19:44:14 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Fri, 09 Mar 2007 14:44:14 -0500 Subject: perl, perl-devel, and missing config.h In-Reply-To: (Robin Norwood's message of "Mon, 05 Mar 2007 12:18:11 -0500") References: Message-ID: Robin Norwood writes: [...] > Spot, Jesse Keating, and I have discussed the issue via email and on > fedora-perl-devel-list[3] - the three of us think this solution is the > right way to go, but several people on the list disagree. So we're > going to hash things out there and decide what to do. If you want to > follow the discussion, see fedora-perl-devel-list. Otherwise, stay > tuned, and we'll keep you posted. An update: it looks like we'll be able to go with the perl-devel split. I've just built perl-5.8.8-15, which continues the work to split perl/perl-devel. Right now 'perl' requires 'perl-devel', but we hope to fix that soon. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From poelstra at redhat.com Fri Mar 9 20:01:20 2007 From: poelstra at redhat.com (John Poelstra) Date: Fri, 09 Mar 2007 12:01:20 -0800 Subject: Announcing Fedora 7 Test 2 (6.91) -- updates-f7t2.img In-Reply-To: <200703011112.12348.jkeating@redhat.com> References: <200703011112.12348.jkeating@redhat.com> Message-ID: <45F1BD10.5060007@redhat.com> Jesse Keating said the following on 03/01/2007 08:12 AM Pacific Time: > This test release has an rpm ordering issue that seems to affect some people > with regard to mkinitrd being installed correctly. If your install seems to > stall at installing the kernel and never continues, please try the updates > image http://people.redhat.com/~katzj/updates-f7t2.img. Refer to > http://fedoraproject.org/wiki/Anaconda/Updates for more information on using > updates images. What are correct steps to view or access exactly what is in the updates-f7t2.img file ? # file updates-f7t2.img updates-f7t2.img: gzip compressed data, from Unix, last modified: Tue Feb 27 11:02:28 2007, max compression gunzip isn't doing the trick for me. Coming up empty on google and the last part of this pages implies that it is a simple image that can be mounted loopback: http://fedoraproject.org/wiki/Anaconda/Updates Thanks, John From tjb at unh.edu Fri Mar 9 20:08:07 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Fri, 09 Mar 2007 15:08:07 -0500 Subject: RANDR 1.2 heads up In-Reply-To: <20070308131635.GA18472@redhat.com> References: <1173136781.9948.22.camel@localhost.localdomain> <20070308092717.6dd893d2@banea.int.addix.net> <20070308131635.GA18472@redhat.com> Message-ID: <1173470887.5437.7.camel@raptor.sr.unh.edu> On Thu, 2007-03-08 at 14:16 +0100, Tomas Janousek wrote: > Hi, > > On Thu, Mar 08, 2007 at 09:27:17AM +0100, Ralf Ertzinger wrote: > > How does one actually do this? Do I have to configure the monitors > > in xorg.conf, or are they autodetected? What program do I use to > > tell xorg to turn the monitors on and off? > > Using the xrandr command. For example, a command > xrandr --output VGA --mode 1024x768 --pos 0x800 > will add the external monitor below my laptop panel. > > But you may have to configure a separate Monitor section for the external > monitor to be able to use modes other than those from the LVDS, which is done > by a line in the Device section: > Option "Monitor-VGA" "name of the monitor" > > -- > TJ., BaseOS, Brno, CZ > Which version of xrandr do you have installed? Those don't seem to even options in the FC7 one I have: continuity> xrandr --help usage: xrandr [options] where options are: -display or -d -help -o or --orientation -q or --query -s /x or --size /x -r or --rate -v or --version -x (reflect in x) -y (reflect in y) --screen --verbose continuity> I've got a laptop with I945 video and I tried several variations and it doesn't seem like my laptop even see the other monitor when I connect it. The most telling is this error: continuity> xrandr --verbose --screen 1 --size 1920x1200 --orientation right Invalid screen number 1 (display has 1) continuity> Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From wtogami at redhat.com Fri Mar 9 20:13:58 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 09 Mar 2007 15:13:58 -0500 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <3da3b5b40703091118p71d0b075gb80095eccdca5449@mail.gmail.com> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <3da3b5b40703091118p71d0b075gb80095eccdca5449@mail.gmail.com> Message-ID: <45F1C006.3080506@redhat.com> Ahmed Kamal wrote: > > A delta rpm update mechanism also enables fedora to issue faster/smaller > updates consisting of mainly translation/documentation updates as has > been recently requested. Please leave this part out. This is a controversial, technically unsound and rejected request made by docs teams. We simply cannot frequently have RPM updates purely for documentation and translation updates (although it is fine to include such updates if an update happens for typical reasons). I have told them an alternative way to do this that enables the ability for unlimited docs updates and faster turnaround, but they have not listened. Warren Togami wtogami at redhat.com From mschwendt.tmp0701.nospam at arcor.de Fri Mar 9 17:17:01 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 9 Mar 2007 18:17:01 +0100 Subject: repoview in our repositories Message-ID: <20070309181701.feaff257.mschwendt.tmp0701.nospam@arcor.de> I believe the repoview pages in the Extras repository still cause some mirrors to choke on mirroring many hundreds to thousands of regenerated html files all few days: extras-tree$ find . -name \*.html|wc -l 61450 That's how many html pages are in Extras 5+6+devel presently! The reason is that although repoview doesn't need to create all its web pages from scratch, it changes many of them too often due to the many package versions in them, which point to adjacent packages. For example: http://wftp.tu-chemnitz.de/pub/linux/fedora-core-extras/development/i386/repodata/repoview/yap-devel-0-5.1.1-3.fc7.html The navigation bar at the left contains links to 20 packages, which come before and after "yap-devel" in the alphabetically sorted list of package names. It links to web page file names, which contain not only the package name, but also version and release. Changing any of the 20 packages changes the web pages for all its neighbours. Plus, the navigation bar lists not only the latest package release, but all releases (which is by design) found in the repo metadata, although it hides the version-release and causes confusion. The more often packages in the neighbourhood of one package are changed, added or removed, the more web pages are updated due to the heavy use of package versions in them. Even deleting an old package release triggers such a rebuild of a chain of web pages. IMO, we would do better in the short-term if we modified repoview to simplify the web page file names to just "%{name}.html". Then a package page would only be updated if the package changed actually or if the list of its 19 neighbours changed. What is the estimated popularity of the repoview pages on our master download site and on the mirrors? Perhaps there are even plans on making a public interface to the package database obsolete repoview? Comments? From stickster at gmail.com Fri Mar 9 20:40:13 2007 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 09 Mar 2007 15:40:13 -0500 Subject: Announcing Fedora 7 Test 2 (6.91) -- updates-f7t2.img In-Reply-To: <45F1BD10.5060007@redhat.com> References: <200703011112.12348.jkeating@redhat.com> <45F1BD10.5060007@redhat.com> Message-ID: <1173472813.7346.1.camel@localhost.localdomain> On Fri, 2007-03-09 at 12:01 -0800, John Poelstra wrote: > Jesse Keating said the following on 03/01/2007 08:12 AM Pacific Time: > > This test release has an rpm ordering issue that seems to affect some people > > with regard to mkinitrd being installed correctly. If your install seems to > > stall at installing the kernel and never continues, please try the updates > > image http://people.redhat.com/~katzj/updates-f7t2.img. Refer to > > http://fedoraproject.org/wiki/Anaconda/Updates for more information on using > > updates images. > > What are correct steps to view or access exactly what is in the updates-f7t2.img file ? > > # file updates-f7t2.img > updates-f7t2.img: gzip compressed data, from Unix, last modified: Tue Feb 27 11:02:28 2007, max compression > > gunzip isn't doing the trick for me. > > Coming up empty on google and the last part of this pages implies that it is a simple image that can be mounted loopback: http://fedoraproject.org/wiki/Anaconda/Updates Hmm, $ gunzip -c updates-f7t2.img | file - /dev/stdin: ASCII cpio archive (SVR4 with CRC) -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 j.w.r.degoede at hhs.nl Fri Mar 9 21:05:42 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 09 Mar 2007 22:05:42 +0100 Subject: RPATH status In-Reply-To: <645d17210703090901w1e886572l6f20968548fe4cd8@mail.gmail.com> References: <20070309130427.GC23863@localhost> <20070309144340.4528c728@banea.int.addix.net> <45F16BE2.9010806@leemhuis.info> <45F16CBC.2020007@hhs.nl> <645d17210703090901w1e886572l6f20968548fe4cd8@mail.gmail.com> Message-ID: <45F1CC26.1020004@hhs.nl> Jonathan Underwood wrote: > On 09/03/07, Hans de Goede wrote: >> rpmlint catches this, I'm sitll in favor of running rpmlint after a >> build, >> check the output against a whitelist of allowed output and if there is >> any >> output not in the whitelist, fail the build. We would need to >> integrate the >> same use of rpmlint in make from makefile.common then (or maybe >> first). > > Fantastic proposal. An added benefit would be that would be one step > closer to having part of the new package review process automated. If > there was a build machine where new package SRPMS could be pushed to > (perhaps even via a web interface) which would then try to build the > package inside mock, run rpmlint on resulting packages, and make > avilable all logs and output (also perhaps via a web page), then > package review pace would greatly increase, I suspect. > Okay, I've taken a quick look at hacking this into Makefile.common, but I think I'm not the right person todo this (I'm a C-programmer not a script language one). Someone (Ville?) once wrote something about some special way to feed a whitelist to rpmlint. Can anyone reproduce that crucial piece of info? Regards, Hans From limb at jcomserv.net Fri Mar 9 20:46:58 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 9 Mar 2007 14:46:58 -0600 (CST) Subject: repoview in our repositories In-Reply-To: <20070309181701.feaff257.mschwendt.tmp0701.nospam@arcor.de> References: <20070309181701.feaff257.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <6792.65.192.24.190.1173473218.squirrel@mail.jcomserv.net> That would actually be great, having %{name}.html, so you could link to it and not have it be supplanted by a new version. Maybe make this new functionality an option and have the old behaviour available. I don't care which is the default, but that's a great idea. Disclaimer: I run a local private yum repo, and I have a 144k sync IDSL connection. Do the math. I would totally love this. :))))) > I believe the repoview pages in the Extras repository still cause some > mirrors to choke on mirroring many hundreds to thousands of regenerated > html files all few days: > > extras-tree$ find . -name \*.html|wc -l > 61450 > > That's how many html pages are in Extras 5+6+devel presently! > > The reason is that although repoview doesn't need to create all its web > pages from scratch, it changes many of them too often due to the many > package versions in them, which point to adjacent packages. > > For example: > > http://wftp.tu-chemnitz.de/pub/linux/fedora-core-extras/development/i386/repodata/repoview/yap-devel-0-5.1.1-3.fc7.html > > The navigation bar at the left contains links to 20 packages, which come > before and after "yap-devel" in the alphabetically sorted list of package > names. It links to web page file names, which contain not only the package > name, but also version and release. Changing any of the 20 packages > changes the web pages for all its neighbours. Plus, the navigation bar > lists not only the latest package release, but all releases (which is by > design) found in the repo metadata, although it hides the version-release > and causes confusion. > > The more often packages in the neighbourhood of one package are changed, > added or removed, the more web pages are updated due to the heavy use of > package versions in them. Even deleting an old package release triggers > such a rebuild of a chain of web pages. > > IMO, we would do better in the short-term if we modified repoview to > simplify the web page file names to just "%{name}.html". Then a package > page would only be updated if the package changed actually or if > the list of its 19 neighbours changed. > > What is the estimated popularity of the repoview pages on our master > download site and on the mirrors? Perhaps there are even plans on > making a public interface to the package database obsolete repoview? > > Comments? > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From kmaraas at broadpark.no Fri Mar 9 20:53:26 2007 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Fri, 09 Mar 2007 21:53:26 +0100 Subject: rawhide report: 20070309 changes In-Reply-To: <18482.1173462471@laptop13.inf.utfsm.cl> References: <200703091046.l29Ak6Ei003410@hs20-bc2-6.build.redhat.com> <4c4ba1530703090633s1c760057g48745ee1f1963c77@mail.gmail.com> <18482.1173462471@laptop13.inf.utfsm.cl> Message-ID: <1173473606.2661.4.camel@rivendell> fre, 09.03.2007 kl. 14.47 -0300, skrev Horst H. von Brand: > Tom London wrote: > > On 3/9/07, buildsys at redhat.com wrote: > > > kernel-2.6.20-1.2981.fc7 > > > ------------------------ > > > * Thu Mar 08 2007 Dave Jones > > > - update to squashfs 3.2-r2 > > > > > > * Thu Mar 08 2007 Dave Jones > > > - update to latest utrace. > > > > > > * Thu Mar 08 2007 John W. Linville > > > - update git-wireless-dev.patch (current as of 2007-03-06) > > > Every kernel after .2925 (up to .2975) has produced either NMIs or > > hard lockups on my Thinkpad X60 if I enable/use the e1000 interface. > > Here I've got a Toshiba with the same network card. No problems at all. > (currently running kernel-2.6.20-1.2975.fc7) Just a FYI that today's kernel is the first one for some time to work with madwifi and keys with indexes without panicing. Seems that the wireless update fixed that. Hoping that the next one will fix the simplex DMA issue I'm seeing when suspending. Cheers Kjartan From drepper at redhat.com Fri Mar 9 21:13:54 2007 From: drepper at redhat.com (Ulrich Drepper) Date: Fri, 09 Mar 2007 13:13:54 -0800 Subject: RPATH status In-Reply-To: <45F19251.5060706@redhat.com> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> Message-ID: <45F1CE12.1000708@redhat.com> Christopher Aillon wrote: >> 3 /usr/lib64/firefox-2.0.0.2 > > Some of them are intentional, such as the above. It's either rpath or > munging LD_LIBRARY_PATH at startup if you want a working firefox. RPATH is perfectly fine for these purposes. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From drepper at redhat.com Fri Mar 9 21:17:20 2007 From: drepper at redhat.com (Ulrich Drepper) Date: Fri, 09 Mar 2007 13:17:20 -0800 Subject: RPATH status In-Reply-To: <45F1CE12.1000708@redhat.com> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> Message-ID: <45F1CEE0.8020504@redhat.com> Ulrich Drepper wrote: > Christopher Aillon wrote: >>> 3 /usr/lib64/firefox-2.0.0.2 >> Some of them are intentional, such as the above. It's either rpath or >> munging LD_LIBRARY_PATH at startup if you want a working firefox. > > RPATH is perfectly fine for these purposes. [Dang it! why did it send the mail already?] I meant to add: If you want a relocatable package you can use $ORIGIN though. So, if the binary is in /usr/bin (e.g., devhelp), you make the RPATH $ORIGIN/../lib64/firefix-2.0.0.2 Then the package is relocatable (at least wrt to this binary). -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From wtogami at redhat.com Fri Mar 9 21:17:29 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 09 Mar 2007 16:17:29 -0500 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> Message-ID: <45F1CEE9.7000408@redhat.com> Have you folks considered using some kind of optional metadata to let the client know about the existence of drpm files, so clients don't need t blindly grab and use 404 to decide to skip it? Warren Togami wtogami at redhat.com From wtogami at redhat.com Fri Mar 9 21:19:53 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 09 Mar 2007 16:19:53 -0500 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> Message-ID: <45F1CF79.5040905@redhat.com> Jonathan Dieter wrote: > On Fri, 2007-03-09 at 12:35 -0500, Warren Togami wrote: >> 2) Ahmed Kamal has been working on a potentially sane implementation of >> deltarpm for Fedora's yum. Theoretically, it would work as an optional >> yum plugin. If the deltarpm is substantially smaller than an RPM >> update, then the deltarpm is provided on a mirror. If the deltarpm is >> not provided, then yum downloads the original RPM instead. If it >> downloaded a deltarpm, it reconstructs the original RPM and uses GPG to >> verify integrity just like yum would verify plain RPM downloads. >> >> Ahmed probably could use some developer and testing help. I've been >> encouraging him to be more communicative about his project in order to >> get more help, but I haven't seen any further outreach lately. >> >> Warren Togami >> wtogami at redhat.com >> > I've been working with Ahmed and Michael Schroeder (the upstream > maintainer of deltarpm) to track down some long-standing bugs in > deltarpm, especially as it relates to prelinked binaries. These bugs > were causing very odd problems while working with the yum-deltarpm > plugin. Interesting! I had not considered prelinking. I'm glad you found this problem. Does it check the integrity of all other files (except %config) before deciding to attempt to download the deltarpm? (If some other file is modified, abort and download the regular RPM?) > > We *think* we've found them all (the patches are in the latest Rawhide > version of deltarpm in Extras), so I think we're at the point where what > we really need is someone who would be willing to create drpms of all > new packages in Core and Extras (there's a modified version of prunerepo > that does all the work for you), and host them for us. > > To give you an idea of the savings we're looking at: > * kdebase-3.5.5-0.4.fc6 => kdebase-3.5.6-0.1.fc6 = 3.5MB vs. 30.2MB > * kdegames-3.5.5-0.1.fc6 => kdegames-3.5.6-0.1.fc6 = 740KB vs. 11.1MB > * OO.o-core-2.0.4-5.5.3 => OO.o-core-2.0.4-5.5.10 = 8.7MB vs. 92.4 MB > There won't be that kind of savings for all the packages, but a general > rule of the thumb is that the bigger the package, the better the chance > that we'll get a good compression ratio on the drpm. Generated drpms are only to be kept on mirrors if the download savings are substantial. Some threshold level has to be decided. For example (actual numbers can be decided later): Only push a drpm to mirrors if the download savings are greater than 40% total size, and greater than 5MB. Warren Togami wtogami at redhat.com From email.ahmedkamal at googlemail.com Fri Mar 9 21:44:35 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Fri, 9 Mar 2007 23:44:35 +0200 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <45F1CF79.5040905@redhat.com> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> Message-ID: <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> The idea of using metadata to conclude whether/not drpm reconstruction will be successful, is possible. This metadata is called a sequence number "SEQ" for some reason. However, at this time, I have not integrated code for that. The current code blindly tries downloading and fails with a 404. Integrating metadata is listed on the TODO on presto page, and it shouldn't be too difficult anyway. However, since drpms are usually too small compared to their comparative rpm, and since in almost all cases on disk files are not going to be corrupt, I did not see much value in using this kind of metadata. The drpm generator script does keep drpms on the server only if they are worth keeping. The worthfulness numbers, of course can be tuned later. I even think it might be a good idea to make worthfulness depend linearly on the new rpm size. i.e. keep drpms for large rpms, even if savings are not that great. We are however getting very good savings on large packages anyway My main focus now is on testing and making sure the "base" system is working as it should. Any ideas about that regression system? Do you think it's a good idea? I'm not primarily into coding, so I'll need help making sound decisions. I'm thinking of having a full FC6 install, then using drpms to upgrade that into *-testing, that should give us some nice reports for how many upgrades/reconstructions are failing. We'll probably need some server to host the drpms on, plus the test client. On 3/9/07, Warren Togami wrote: > > Jonathan Dieter wrote: > > On Fri, 2007-03-09 at 12:35 -0500, Warren Togami wrote: > >> 2) Ahmed Kamal has been working on a potentially sane implementation of > >> deltarpm for Fedora's yum. Theoretically, it would work as an optional > >> yum plugin. If the deltarpm is substantially smaller than an RPM > >> update, then the deltarpm is provided on a mirror. If the deltarpm is > >> not provided, then yum downloads the original RPM instead. If it > >> downloaded a deltarpm, it reconstructs the original RPM and uses GPG to > >> verify integrity just like yum would verify plain RPM downloads. > >> > >> Ahmed probably could use some developer and testing help. I've been > >> encouraging him to be more communicative about his project in order to > >> get more help, but I haven't seen any further outreach lately. > >> > >> Warren Togami > >> wtogami at redhat.com > >> > > I've been working with Ahmed and Michael Schroeder (the upstream > > maintainer of deltarpm) to track down some long-standing bugs in > > deltarpm, especially as it relates to prelinked binaries. These bugs > > were causing very odd problems while working with the yum-deltarpm > > plugin. > > Interesting! I had not considered prelinking. I'm glad you found this > problem. > > Does it check the integrity of all other files (except %config) before > deciding to attempt to download the deltarpm? (If some other file is > modified, abort and download the regular RPM?) > > > > > We *think* we've found them all (the patches are in the latest Rawhide > > version of deltarpm in Extras), so I think we're at the point where what > > we really need is someone who would be willing to create drpms of all > > new packages in Core and Extras (there's a modified version of prunerepo > > that does all the work for you), and host them for us. > > > > To give you an idea of the savings we're looking at: > > * kdebase-3.5.5-0.4.fc6 => kdebase-3.5.6-0.1.fc6 = 3.5MB vs. 30.2MB > > * kdegames-3.5.5-0.1.fc6 => kdegames-3.5.6-0.1.fc6 = 740KB vs. 11.1MB > > * OO.o-core-2.0.4-5.5.3 => OO.o-core-2.0.4-5.5.10 = 8.7MB vs. 92.4 MB > > There won't be that kind of savings for all the packages, but a general > > rule of the thumb is that the bigger the package, the better the chance > > that we'll get a good compression ratio on the drpm. > > Generated drpms are only to be kept on mirrors if the download savings > are substantial. Some threshold level has to be decided. > > For example (actual numbers can be decided later): > Only push a drpm to mirrors if the download savings are greater than 40% > total size, and greater than 5MB. > > Warren Togami > wtogami at redhat.com > > -- > 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 davej at redhat.com Fri Mar 9 21:55:55 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 9 Mar 2007 16:55:55 -0500 Subject: rawhide report: 20070309 changes In-Reply-To: <4c4ba1530703090633s1c760057g48745ee1f1963c77@mail.gmail.com> References: <200703091046.l29Ak6Ei003410@hs20-bc2-6.build.redhat.com> <4c4ba1530703090633s1c760057g48745ee1f1963c77@mail.gmail.com> Message-ID: <20070309215555.GB15731@redhat.com> [adding some Intel E1000 maintainers to Cc] On Fri, Mar 09, 2007 at 06:33:05AM -0800, Tom London wrote: > On 3/9/07, buildsys at redhat.com wrote: > > kernel-2.6.20-1.2981.fc7 > > ------------------------ > > * Thu Mar 08 2007 Dave Jones > > - update to squashfs 3.2-r2 > > > > * Thu Mar 08 2007 Dave Jones > > - update to latest utrace. > > > > * Thu Mar 08 2007 John W. Linville > > - update git-wireless-dev.patch (current as of 2007-03-06) > > > Every kernel after .2925 (up to .2975) has produced either NMIs or > hard lockups on my Thinkpad X60 if I enable/use the e1000 interface. > > The system appears rock solid if I disconnect the e1000 and use the > ipw3945 interface, or if I revert back to .2925. > > I've BZ'ed this here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229603 > > Anyone else seeing this? > > Any known issues with the 2.6.21 line that could be causing this? For the benefit of the folks I just Cc'd, this is a regression added since 2.6.20, which is affecting right up to todays 2.6.21-rc3-git tree. any ideas? Dave -- http://www.codemonkey.org.uk From kwade at redhat.com Fri Mar 9 22:03:41 2007 From: kwade at redhat.com (Karsten Wade) Date: Fri, 09 Mar 2007 14:03:41 -0800 Subject: Frozen feature list for FC7 In-Reply-To: <1173231813.3333.4.camel@tuxhugs> References: <45EE0D47.7000201@redhat.com> <45EE108C.2000508@redhat.com> <1173231813.3333.4.camel@tuxhugs> Message-ID: <1173477821.3935.263.camel@erato.phig.org> On Tue, 2007-03-06 at 17:43 -0800, Peter Gordon wrote: > On Tue, 2007-03-06 at 20:08 -0500, Warren Togami wrote: > > Features have not historically been tracked formally in Fedora. > > Features just would sort of land if they were completed before freeze > > dates. I suppose we could improve this in the future, but is the Wiki > > really the best way to represent this? > > Hence the 'fedora_requires_release_note' Bugzilla flag? :) > > Is there a formal policy for that like there is for the fedora-cvs one? > If not, then we could simply request that flag ('?') and add a note to > the package's review request (or another resolved RFE bug) stating the > cool new significant feature that has been added/changes. Then perhaps > this can go to the fedora-docs list and someone can approve ('+') the > flag when this is added or deny it ('-') with a brief explanation as to > the reasoning for its denial. I think you have to set the flag to '+' to trigger it, right? At that point, we can ACK it in a comment and point to where the content went. Not including the content should definitely get a '-'. Added now at: http://fedoraproject.org/wiki/DocsProject/ReleaseNotes/Process#BugzillaFlag Note that all of these methods of filing a release note are piped into relnotes at fedoraproject.org. That is then fed into a mailman list (fedora-relnotes-content) that is the "firehose of raw release content". > Also, the Docs/Beats on the wiki are writable to all Fedora Account > holders, right? Could setting the flag in Bugzilla automagically add > that note the wiki if the flag requester has a Fedora account/is in the > EditGroup? That is an interesting idea. We'd have to have a way of identifying which beat should receive the content; it seems doable. Best thing to do with this idea is to file an RFE in bugzilla against the release notes. thx - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- 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 davej at redhat.com Fri Mar 9 22:04:36 2007 From: davej at redhat.com (Dave Jones) Date: Fri, 9 Mar 2007 17:04:36 -0500 Subject: rawhide report: 20070309 changes In-Reply-To: References: <20070309215555.GB15731@redhat.com> Message-ID: <20070309220436.GA32089@redhat.com> On Fri, Mar 09, 2007 at 01:57:49PM -0800, Ronciak, John wrote: > Does our latest driver form e1000.sf.net have the same problem? (I'd forgotten how much I hated sourceforge's download mechanism..) ugh, the diff between 7.3.20-k2 and 7.4.27 is enormous.. 35 files changed, 22564 insertions(+), 13187 deletions(-) I take it that won't be getting merged into .21 :-) One of the follow-ups in the thread before I cc'd you mentioned that the problem goes away when ondemand CPU scaling was disabled, which is.. curious. Dave -- http://www.codemonkey.org.uk From ajackson at redhat.com Fri Mar 9 22:00:58 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 09 Mar 2007 17:00:58 -0500 Subject: RANDR 1.2 heads up In-Reply-To: <1173470887.5437.7.camel@raptor.sr.unh.edu> References: <1173136781.9948.22.camel@localhost.localdomain> <20070308092717.6dd893d2@banea.int.addix.net> <20070308131635.GA18472@redhat.com> <1173470887.5437.7.camel@raptor.sr.unh.edu> Message-ID: <1173477658.14998.0.camel@localhost.localdomain> On Fri, 2007-03-09 at 15:08 -0500, Thomas J. Baker wrote: > On Thu, 2007-03-08 at 14:16 +0100, Tomas Janousek wrote: > > Hi, > > > > On Thu, Mar 08, 2007 at 09:27:17AM +0100, Ralf Ertzinger wrote: > > > How does one actually do this? Do I have to configure the monitors > > > in xorg.conf, or are they autodetected? What program do I use to > > > tell xorg to turn the monitors on and off? > > > > Using the xrandr command. For example, a command > > xrandr --output VGA --mode 1024x768 --pos 0x800 > > will add the external monitor below my laptop panel. > > > > But you may have to configure a separate Monitor section for the external > > monitor to be able to use modes other than those from the LVDS, which is done > > by a line in the Device section: > > Option "Monitor-VGA" "name of the monitor" > > > > -- > > TJ., BaseOS, Brno, CZ > > > > Which version of xrandr do you have installed? Those don't seem to even > options in the FC7 one I have: Yeah, entirely my fault, the package never got off my hard drive. Should be available tomorrow. - ajax From wtogami at redhat.com Fri Mar 9 22:24:29 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 09 Mar 2007 17:24:29 -0500 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> Message-ID: <45F1DE9D.6050002@redhat.com> Ahmed Kamal wrote: > > The drpm generator script does keep drpms on the server only if they are > worth keeping. The worthfulness numbers, of course can be tuned later. I > even think it might be a good idea to make worthfulness depend linearly > on the new rpm size. i.e. keep drpms for large rpms, even if savings are > not that great. We are however getting very good savings on large > packages anyway I meant metadata for the purpose of telling the client which drpms are available and which are not because of worthfulness threshold. This might allow us to avoid depending on 404, which would speed up the client. (But yes, this is not important yet. This can be implemented later.) > > My main focus now is on testing and making sure the "base" system is > working as it should. Any ideas about that regression system? Do you > think it's a good idea? I'm not primarily into coding, so I'll need help > making sound decisions. I'm thinking of having a full FC6 install, then > using drpms to upgrade that into *-testing, that should give us some > nice reports for how many upgrades/reconstructions are failing. We'll > probably need some server to host the drpms on, plus the test client. I might be missing something here. Can't rpm know prior to downloading the drpm whether it will be successful or not in reconstructing the original RPM? It can tell by using rpm -V to see if the required local data is intact. For example: 1) rpm -V firefox 2) Uh oh, /usr/lib/firefox-1.5.x.x/foo which is not marked as %config was modified. 3) Don't attempt to download the drpm. The reconstruction doesn't require the local files marked %config to be the original file right? Any other local files it explicitly doesn't rely upon? Warren Togami wtogami at redhat.com From drago01 at gmail.com Fri Mar 9 22:36:32 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 09 Mar 2007 23:36:32 +0100 Subject: FC6 kernel rebase to 2.6.20.2 ? Message-ID: <45F1E170.50307@gmail.com> Hello, It was planned to rebase the FC6 kernel to 2.6.20 but it was hold up due to bugs. Now 2.6.20.2 is out with many bugfixes. Is it ready for FC6 now? From email.ahmedkamal at googlemail.com Fri Mar 9 22:38:17 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 10 Mar 2007 00:38:17 +0200 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <45F1DE9D.6050002@redhat.com> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> Message-ID: <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> > > > I meant metadata for the purpose of telling the client which drpms are > available and which are not because of worthfulness threshold. This > might allow us to avoid depending on 404, which would speed up the client. oops, ok I mis-understood > Can't rpm know prior to downloading the drpm whether it will be > successful or not in reconstructing the original RPM? It can tell by > using rpm -V to see if the required local data is intact. Well it can know using this "SEQ" number I talked about. Not sure if using rpm -V would be equivalent, or why upstream chose this approach. Integrating SEQ numbers is doable, but not done yet. This list of SEQ numbers can also be used to avoid the 404s, so definitly this is something we will want to add The reconstruction doesn't require the local files marked %config to be > the original file right? Any other local files it explicitly doesn't > rely upon? Um, not sure. But it does have to reconstruct the new rpm, and that rpm would have to pass md5/sha1/gpg checks! Doesn't that mean even %config files have to be untouched?! I need to double check how this is handled However, when I was talking about a regression test, and getting a list of failed reconstructions. I mainly meant due to bugs in deltarpm, or the de-prelinking code as we've seen, not because of changed files. Warren Togami > wtogami at redhat.com > > -- > 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 selinux at gmail.com Fri Mar 9 23:05:33 2007 From: selinux at gmail.com (Tom London) Date: Fri, 9 Mar 2007 15:05:33 -0800 Subject: rawhide report: 20070309 changes In-Reply-To: <20070309220436.GA32089@redhat.com> References: <20070309215555.GB15731@redhat.com> <20070309220436.GA32089@redhat.com> Message-ID: <4c4ba1530703091505sce96eande8c6190acf6452@mail.gmail.com> On 3/9/07, Dave Jones wrote: > On Fri, Mar 09, 2007 at 01:57:49PM -0800, Ronciak, John wrote: > > Does our latest driver form e1000.sf.net have the same problem? > > (I'd forgotten how much I hated sourceforge's download mechanism..) > > ugh, the diff between 7.3.20-k2 and 7.4.27 is enormous.. > > 35 files changed, 22564 insertions(+), 13187 deletions(-) > > I take it that won't be getting merged into .21 :-) > One of the follow-ups in the thread before I cc'd you mentioned that > the problem goes away when ondemand CPU scaling was disabled, > which is.. curious. > > Dave > Not certain this is the case. I've gotten failures (either hard freezes or NMI crashes) with all the GUI available ondemand settings: 1.0, 1.3, 1.83 GHz. Seems to take longer with the lower fixed settings, but that may just be sampling error. tom -- Tom London From wtogami at redhat.com Sat Mar 10 01:01:46 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 09 Mar 2007 20:01:46 -0500 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> Message-ID: <45F2037A.2010603@redhat.com> Ahmed Kamal wrote: > > The reconstruction doesn't require the local files marked %config to be > the original file right? Any other local files it explicitly doesn't > rely upon? > > > > Um, not sure. But it does have to reconstruct the new rpm, and that rpm > would have to pass md5/sha1/gpg checks! Doesn't that mean even %config > files have to be untouched?! I need to double check how this is handled 1) Client wants to upgrade from foo-3.2-1 to foo-3.2-2 (Transition X) 2) Client metadata sees that Transition X has a drpm available (from metadata or something). 3) Client checks using rpm -V (or more likely the rpm API equivalent) to see if the local files are intact. This step is a little time consuming, but it is worthwhile because we know that a drpm is available above the defined efficiency threshold. 4) All files are intact, except some files in /etc marked %config are changed. This is OK. 5) drpm contains %config file data even if they did not change in Transition X. This allows reconstruction of the original foo-3.2-2 RPM even if the local %config files are modified. deltarpm needs to put data within the drpm that is likely to change on the local systems. This includes %config, but possibly other things like /var. We can craft this predefined list to whatever our research finds is necessary. Warren Togami wtogami at redhat.com From jspaleta at gmail.com Sat Mar 10 02:38:05 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 9 Mar 2007 17:38:05 -0900 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> Message-ID: <604aa7910703091838v77959a28j7aa121acb6a91a8d@mail.gmail.com> On 3/9/07, Ahmed Kamal wrote: > My main focus now is on testing and making sure the "base" system is working > as it should. Do you need, real world testers yet? I'm willing to brutalize one of my systems (or a virtual one) in an effort to see if this is going to work as an implementation. Have you talked to the Fedora Unity people to see if they can host a test server instance to hold a drpm test tree? They might be interested if they have the infrastructure to host you. -jef From notting at redhat.com Sat Mar 10 03:28:54 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 9 Mar 2007 22:28:54 -0500 Subject: RPATH status In-Reply-To: <45F16CBC.2020007@hhs.nl> References: <20070309130427.GC23863@localhost> <20070309144340.4528c728@banea.int.addix.net> <45F16BE2.9010806@leemhuis.info> <45F16CBC.2020007@hhs.nl> Message-ID: <20070310032854.GA23633@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > rpmlint catches this, I'm sitll in favor of running rpmlint after a build, > check the output against a whitelist of allowed output and if there is any > output not in the whitelist, fail the build. We would need to integrate the > same use of rpmlint in make from makefile.common then (or maybe > first). Do we really want to hold up builds on the rpmlint maintainer fixing things in rpmlint? Bill From a.badger at gmail.com Sat Mar 10 04:01:14 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 09 Mar 2007 20:01:14 -0800 Subject: RPATH status In-Reply-To: <20070310032854.GA23633@nostromo.devel.redhat.com> References: <20070309130427.GC23863@localhost> <20070309144340.4528c728@banea.int.addix.net> <45F16BE2.9010806@leemhuis.info> <45F16CBC.2020007@hhs.nl> <20070310032854.GA23633@nostromo.devel.redhat.com> Message-ID: <1173499274.3329.237.camel@localhost.localdomain> On Fri, 2007-03-09 at 22:28 -0500, Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: > > rpmlint catches this, I'm sitll in favor of running rpmlint after a build, > > check the output against a whitelist of allowed output and if there is any > > output not in the whitelist, fail the build. We would need to integrate the > > same use of rpmlint in make from makefile.common then (or maybe > > first). > > Do we really want to hold up builds on the rpmlint maintainer fixing > things in rpmlint? > If this is the same thought as past discussions, the whitelist is per package. I make a build. The rpms are run through rpmlint. The issues reported are compared against the previous build's rpmlint. If there are problems not previously whitelisted, the rpm is not pushed to the repo until the maintainer somehow adds the warnings to the whitelist or updates the spec so it no longer causes the error. (Maybe it's filling in a reason and submitting it to the packageDB. Maybe it's a specially formatted comment in the spec file. I don't know how people would want to implement the feature.) So there's no waiting on the rpmlint maintainer. This could also be interesting as it would let the rpmlint maintainer/author see which of the rpmlint tests are causing the most false positives. -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 jdieter at gmail.com Sat Mar 10 06:41:31 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Sat, 10 Mar 2007 08:41:31 +0200 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <45F2037A.2010603@redhat.com> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> Message-ID: <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> On Fri, 2007-03-09 at 20:01 -0500, Warren Togami wrote: > 1) Client wants to upgrade from foo-3.2-1 to foo-3.2-2 (Transition X) > 2) Client metadata sees that Transition X has a drpm available (from > metadata or something). At the moment, it checks to see if a drpm is available from your deltarpm url that matches a filename. If the file doesn't exist, then there is no drpm for this particular update. I could code in a way of using metadata rather than filename checking, if that's what's preferred. Are we talking a yum-style xml file? > 3) Client checks using rpm -V (or more likely the rpm API equivalent) to > see if the local files are intact. This step is a little time > consuming, but it is worthwhile because we know that a drpm is available > above the defined efficiency threshold. Should be easy to implement, and, yes, would be very important. FYI, the current efficiency threshold is 50%. It is very easy to adjust this level. > 4) All files are intact, except some files in /etc marked %config are > changed. This is OK. Yes. Deltarpm stores %config files in the drpm no matter whether they've changed or not. > 5) drpm contains %config file data even if they did not change in > Transition X. This allows reconstruction of the original foo-3.2-2 RPM > even if the local %config files are modified. > > deltarpm needs to put data within the drpm that is likely to change on > the local systems. This includes %config, but possibly other things > like /var. We can craft this predefined list to whatever our research > finds is necessary. As far as I know, deltarpm doesn't have a way for the user to choose which files *must* get stored in the drpm. > > Warren Togami > wtogami at redhat.com > Jonathan -------------- 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 david at lovesunix.net Sat Mar 10 06:55:05 2007 From: david at lovesunix.net (David Nielsen) Date: Sat, 10 Mar 2007 07:55:05 +0100 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> Message-ID: <1173509705.26934.12.camel@dawkins> l?r, 10 03 2007 kl. 08:41 +0200, skrev Jonathan Dieter: > Should be easy to implement, and, yes, would be very important. FYI, > the current efficiency threshold is 50%. It is very easy to adjust this > level. Do we know how many packages on average that would apply to, it seems to me that unless this actually saves us bandwidth in general cases rather than just OpenOffice.org (which is big and hideous by nature) then it might not be worth it for anything but cool value. Has this been tried on something like the FC6 updates? Additionally what are the impacts client side of doing this, I assume a certain overhead in stitching the packages together is present. Aside that the idea sounds really neat and once it's ready for testing I'd love to give it a go. - 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 davehoz at gmail.com Sat Mar 10 08:07:56 2007 From: davehoz at gmail.com (David Hunter) Date: Sat, 10 Mar 2007 19:07:56 +1100 Subject: a2ps update problem Message-ID: <6bb886180703100007m617dade3rc35ccfe6812749d8@mail.gmail.com> I have the package a2ps version a2ps-4.13b-61.fc7 but the latest version as detected by yum is a2ps-4.13b-62.fc7. However, when I try to update it, yum comes up with the error: Error: Missing Dependency: liba2ps.so.1 is needed by package a2p Is there something wrong with the spec file or what? -- David Hunter -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.w.r.degoede at hhs.nl Sat Mar 10 08:45:39 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sat, 10 Mar 2007 09:45:39 +0100 Subject: RPATH status In-Reply-To: <1173499274.3329.237.camel@localhost.localdomain> References: <20070309130427.GC23863@localhost> <20070309144340.4528c728@banea.int.addix.net> <45F16BE2.9010806@leemhuis.info> <45F16CBC.2020007@hhs.nl> <20070310032854.GA23633@nostromo.devel.redhat.com> <1173499274.3329.237.camel@localhost.localdomain> Message-ID: <45F27033.6000503@hhs.nl> Toshio Kuratomi wrote: > On Fri, 2007-03-09 at 22:28 -0500, Bill Nottingham wrote: >> Hans de Goede (j.w.r.degoede at hhs.nl) said: >>> rpmlint catches this, I'm sitll in favor of running rpmlint after a build, >>> check the output against a whitelist of allowed output and if there is any >>> output not in the whitelist, fail the build. We would need to integrate the >>> same use of rpmlint in make from makefile.common then (or maybe >>> first). >> Do we really want to hold up builds on the rpmlint maintainer fixing >> things in rpmlint? >> > If this is the same thought as past discussions, the whitelist is per > package. I make a build. The rpms are run through rpmlint. The issues > reported are compared against the previous build's rpmlint. If there > are problems not previously whitelisted, the rpm is not pushed to the > repo until the maintainer somehow adds the warnings to the whitelist or > updates the spec so it no longer causes the error. (Maybe it's filling > in a reason and submitting it to the packageDB. Maybe it's a specially > formatted comment in the spec file. I don't know how people would want > to implement the feature.) > My idea was to have a special file in CVS, which also gets tagged per release just like the sources file. Also notice that make should be patched first todo the same thing, so that when a maintainer does a testbuild rpmlint is already run and thus there are no surprises when rpmlint gets run on the buildsys. I've been thinking about this for quite a while now actually as I very regulary encounter packages with packaging errors which are caught by rpmlint. And sometimes upstream causes packaging regressions like introducing rpath in a new release. Automated QA is simply good, as long as it doesn't get in the way and the whitelist makes sure it doesn't. The whitelist should probably handle wildcards or regex, so maintainers who really don't want this can simply put .* in the whitelist. Regards, Hans From pertusus at free.fr Sat Mar 10 08:42:45 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 10 Mar 2007 09:42:45 +0100 Subject: a2ps update problem In-Reply-To: <6bb886180703100007m617dade3rc35ccfe6812749d8@mail.gmail.com> References: <6bb886180703100007m617dade3rc35ccfe6812749d8@mail.gmail.com> Message-ID: <20070310084245.GC3153@free.fr> On Sat, Mar 10, 2007 at 07:07:56PM +1100, David Hunter wrote: > I have the package a2ps version a2ps-4.13b-61.fc7 but the latest version as > detected by yum is a2ps-4.13b-62.fc7. However, when I try to update it, yum > comes up with the error: > > Error: Missing Dependency: liba2ps.so.1 is needed by package a2p > > Is there something wrong with the spec file or what? It is already fixed in cvs. It should be corrected by the next push. -- Pat From jdieter at gmail.com Sat Mar 10 08:56:50 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Sat, 10 Mar 2007 10:56:50 +0200 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <1173509705.26934.12.camel@dawkins> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> <1173509705.26934.12.camel@dawkins> Message-ID: <1173517010.6838.71.camel@jndwidescreen.lesbg.loc> On Sat, 2007-03-10 at 07:55 +0100, David Nielsen wrote: > Do we know how many packages on average that would apply to, it seems to > me that unless this actually saves us bandwidth in general cases rather > than just OpenOffice.org (which is big and hideous by nature) then it > might not be worth it for anything but cool value. > > Has this been tried on something like the FC6 updates? Additionally what > are the impacts client side of doing this, I assume a certain overhead > in stitching the packages together is present. > > Aside that the idea sounds really neat and once it's ready for testing > I'd love to give it a go. > > - David Nielsen > I have a local repository with all of Core + some Extras + some Livna + some FreshRPMS in it. If someone had installed everything from my repository when I first created it, and then had do an update to the latest version of everything, they would have to download ~1.5 GB of updates. If that same person had the yum-deltarpm plugin enabled, they would only have to download 638 MB. That is *including* all the updates that don't have drpms because the savings isn't enough. That means that we're looking at a savings of roughly 60%. As for the rpm rebuild time, it's not that bad. Most of the time seems to be reading the data from the hard drive. Hope that answers your questions. Jonathan -------------- 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 david at lovesunix.net Sat Mar 10 09:11:17 2007 From: david at lovesunix.net (David Nielsen) Date: Sat, 10 Mar 2007 10:11:17 +0100 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <1173517010.6838.71.camel@jndwidescreen.lesbg.loc> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> <1173509705.26934.12.camel@dawkins> <1173517010.6838.71.camel@jndwidescreen.lesbg.loc> Message-ID: <1173517877.3076.2.camel@dawkins> l?r, 10 03 2007 kl. 10:56 +0200, skrev Jonathan Dieter: > On Sat, 2007-03-10 at 07:55 +0100, David Nielsen wrote: > > Do we know how many packages on average that would apply to, it seems to > > me that unless this actually saves us bandwidth in general cases rather > > than just OpenOffice.org (which is big and hideous by nature) then it > > might not be worth it for anything but cool value. > > > > Has this been tried on something like the FC6 updates? Additionally what > > are the impacts client side of doing this, I assume a certain overhead > > in stitching the packages together is present. > > > > Aside that the idea sounds really neat and once it's ready for testing > > I'd love to give it a go. > > > > - David Nielsen > > > I have a local repository with all of Core + some Extras + some Livna + > some FreshRPMS in it. > > If someone had installed everything from my repository when I first > created it, and then had do an update to the latest version of > everything, they would have to download ~1.5 GB of updates. > > If that same person had the yum-deltarpm plugin enabled, they would only > have to download 638 MB. That is *including* all the updates that don't > have drpms because the savings isn't enough. > > That means that we're looking at a savings of roughly 60%. > > As for the rpm rebuild time, it's not that bad. Most of the time seems > to be reading the data from the hard drive. > > Hope that answers your questions. Thank you and might I add over the top on sexiness. - 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 enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 10:46:39 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 11:46:39 +0100 Subject: RPATH status In-Reply-To: <45F1CEE0.8020504@redhat.com> (Ulrich Drepper's message of "Fri, 09 Mar 2007 13:17:20 -0800") References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <45F1CEE0.8020504@redhat.com> Message-ID: <87abylfka8.fsf@kosh.bigo.ensc.de> Ulrich Drepper writes: > If you want a relocatable package you can use $ORIGIN though. So, if > the binary is in /usr/bin (e.g., devhelp), you make the RPATH > > $ORIGIN/../lib64/firefix-2.0.0.2 Back references (/..) should be avoided there because they will break when binary is in a symlinked path. E.g. with | /usr/bin -> /vol1/usr/bin | /usr/lib64 -> /vol2/usr/lib64 the RPATH above would be resolved to /vol1/usr/lib64/... Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From seg at haxxed.com Sat Mar 10 12:02:11 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 10 Mar 2007 06:02:11 -0600 Subject: RPATH status In-Reply-To: <1173499274.3329.237.camel@localhost.localdomain> References: <20070309130427.GC23863@localhost> <20070309144340.4528c728@banea.int.addix.net> <45F16BE2.9010806@leemhuis.info> <45F16CBC.2020007@hhs.nl> <20070310032854.GA23633@nostromo.devel.redhat.com> <1173499274.3329.237.camel@localhost.localdomain> Message-ID: <1173528131.6955.1.camel@max.booze> On Fri, 2007-03-09 at 20:01 -0800, Toshio Kuratomi wrote: > If this is the same thought as past discussions, the whitelist is per > package. I make a build. The rpms are run through rpmlint. The issues > reported are compared against the previous build's rpmlint. If there > are problems not previously whitelisted, the rpm is not pushed to the > repo until the maintainer somehow adds the warnings to the whitelist or > updates the spec so it no longer causes the error. (Maybe it's filling > in a reason and submitting it to the packageDB. Maybe it's a specially > formatted comment in the spec file. I don't know how people would want > to implement the feature.) I thought there's already a whitelist. There's (W)arnings and (E)rrors. Just like a C compiler. -------------- 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 tjanouse at redhat.com Sat Mar 10 12:12:49 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Sat, 10 Mar 2007 13:12:49 +0100 Subject: RANDR 1.2 heads up In-Reply-To: <1173470887.5437.7.camel@raptor.sr.unh.edu> References: <1173136781.9948.22.camel@localhost.localdomain> <20070308092717.6dd893d2@banea.int.addix.net> <20070308131635.GA18472@redhat.com> <1173470887.5437.7.camel@raptor.sr.unh.edu> Message-ID: <20070310121249.GA21075@redhat.com> Hi, On Fri, Mar 09, 2007 at 03:08:07PM -0500, Thomas J. Baker wrote: > Which version of xrandr do you have installed? Those don't seem to even > options in the FC7 one I have: The one from xbase-clients 1:7.2.ds2-1 from debian experimental, but that won't help you. Ajax's answer is much better :) -- TJ., BaseOS, Brno, CZ From shams at orcon.net.nz Sat Mar 10 13:27:52 2007 From: shams at orcon.net.nz (Shams) Date: Sun, 11 Mar 2007 02:27:52 +1300 Subject: Fedora 6 a bit more automated install Message-ID: Hi, Once I have started installing Fedora 6 it works out the packages/dependencies and then waits for me to press the "Next" button before it starts the actual installtion. Maybe it should just go ahead and do it without waiting for the user to press the "Next" button. Is it possible to automate this already, if not then I think this will be a good feature to have? Thanks Shams From abo at kth.se Sat Mar 10 13:52:50 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sat, 10 Mar 2007 14:52:50 +0100 Subject: RPATH status In-Reply-To: <87abylfka8.fsf@kosh.bigo.ensc.de> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <45F1CEE0.8020504@redhat.com> <87abylfka8.fsf@kosh.bigo.ensc.de> Message-ID: <1173534770.3816.13.camel@home.alexander.bostrom.net> l?r 2007-03-10 klockan 11:46 +0100 skrev Enrico Scholz: > E.g. with > > | /usr/bin -> /vol1/usr/bin > | /usr/lib64 -> /vol2/usr/lib64 > > the RPATH above would be resolved to /vol1/usr/lib64/... Perhaps a bind mount would be better in situations like that? /Alexander From pmr at pajato.com Sat Mar 10 13:56:24 2007 From: pmr at pajato.com (Paul Michael Reilly) Date: Sat, 10 Mar 2007 08:56:24 -0500 Subject: When to expect support for 3945 Wireless in Rawhide Message-ID: <45F2B908.8050309@pajato.com> I've seen snippets discussing ipw3945 (sp?) wireless support in an upcoming kernel which I thought to be the kernels supplied on Rawhide yum updates but I do not see any trace of 3945 support in /var/log/messages. So the question is: if my laptop has the 3945 chip and it is not seen by the most recent Rawhide kernels is that a bug? If not, at what point will Rawhide have a kernel such that the 3945 chip should be seen? -pmr From linville at redhat.com Sat Mar 10 13:59:17 2007 From: linville at redhat.com (John W. Linville) Date: Sat, 10 Mar 2007 08:59:17 -0500 Subject: When to expect support for 3945 Wireless in Rawhide In-Reply-To: <45F2B908.8050309@pajato.com> References: <45F2B908.8050309@pajato.com> Message-ID: <20070310135917.GA11811@redhat.com> On Sat, Mar 10, 2007 at 08:56:24AM -0500, Paul Michael Reilly wrote: > I've seen snippets discussing ipw3945 (sp?) wireless support in an > upcoming kernel which I thought to be the kernels supplied on Rawhide > yum updates but I do not see any trace of 3945 support in > /var/log/messages. So the question is: if my laptop has the 3945 chip > and it is not seen by the most recent Rawhide kernels is that a bug? If > not, at what point will Rawhide have a kernel such that the 3945 chip > should be seen? Shortly after Intel actual posts a patch for inclusion of the iwlwifi driver in the wireless-dev kernel tree. For now, you may wish to try my test kernels: http://people.redhat.com/linville/kernels/fc7/ Thanks, John -- John W. Linville linville at redhat.com From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 14:20:31 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 15:20:31 +0100 Subject: RPATH status In-Reply-To: <1173534770.3816.13.camel@home.alexander.bostrom.net> (Alexander =?iso-8859-1?Q?Bostr=F6m's?= message of "Sat, 10 Mar 2007 14:52:50 +0100") References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <45F1CEE0.8020504@redhat.com> <87abylfka8.fsf@kosh.bigo.ensc.de> <1173534770.3816.13.camel@home.alexander.bostrom.net> Message-ID: <877itpdvtc.fsf@kosh.bigo.ensc.de> Alexander Bostr?m writes: >> | /usr/bin -> /vol1/usr/bin >> | /usr/lib64 -> /vol2/usr/lib64 >> >> the RPATH above would be resolved to /vol1/usr/lib64/... > > Perhaps a bind mount would be better in situations like that? Perhaps; but there is nothing which forbids the symlink layout. In practice, I saw this with '/afs/.../bin -> ...' links; bind mounts might be more complicated in such a setup. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From buildsys at redhat.com Sat Mar 10 15:02:20 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 10 Mar 2007 10:02:20 -0500 Subject: rawhide report: 20070310 changes Message-ID: <200703101502.l2AF2K8R015100@hs20-bc2-6.build.redhat.com> Updated Packages: a2ps-4.13b-63.fc7 ----------------- * Fri Mar 09 2007 Tim Waugh 4.13b-63 - Removed bad files (bug #225235). - Add sysconfdir/a2ps to search path (bug #225235). - Build does not require gperf after all (bug #225235). - Don't remove needed library (bug #225235). anaconda-11.2.0.35-1 -------------------- * Fri Mar 09 2007 David Cantrell - 11.2.0.35-1 - Fix SIGSEGV for HTTP installs (#231576) - Some spec file cleanups to adhere to Fedora packaging guidelines * Thu Mar 08 2007 David Cantrell - 11.2.0.34-1 - Remove duplicate Activate On Boot checkbox in iw netconfig - Set DHCPv6_DISABLE flag for auto neighbor discovery (#230941, #230949) - Set loaderData->ip appropriately in STEP_IP (#231290) - Replace hyphens in BOOTIF= parameter with colons (#209284) - In strcount() in libisys, return 0 if tmp is NULL (#231290) - Subclass Raid class in kickstart.py from F7_Raid (clumens) - Make sure ext2 filesystem module is loaded early (clumens, #230946) * Thu Mar 08 2007 Chris Lumens - 11.2.0.33-1 - Fix translations to build correctly. - Fix traceback on upgrade due to yum API change. basesystem-8.1-1 ---------------- * Fri Mar 02 2007 Phil Knirsch - 8.1-1 - Cleanup per package review (#225608) cups-1:1.2.8-5.fc7 ------------------ * Fri Mar 09 2007 Tim Waugh 1:1.2.8-5 - Better UNIX domain sockets authentication patch after feedback from Uli (bug #230613). evolution-data-server-1.9.92-4.fc7 ---------------------------------- * Fri Mar 09 2007 Matthew Barnes - 1.9.92-4.fc7 - Add patch for GNOME bug #415922 (support MS ISA Server 2004). - Patch by Kenny Root. * Thu Mar 08 2007 Matthew Barnes - 1.9.92-3.fc7 - Add patch for GNOME bug #415891 (introduce EFlag API). - Add patch for GNOME bug #376991 (refactor password handling). freeradius-1.1.5-1 ------------------ * Fri Mar 09 2007 Thomas Woerner 1.1.5-1 - new version 1.1.5 - no /etc/raddb/otppasswd.sample anymore - build is pie by default, dropped pie patch - fixed build requirement for perl (perl-devel) freetype-2.3.2-1.fc7 -------------------- * Fri Mar 09 2007 Behdad Esfahbod 2.3.2-1 - Update to 2.3.2. gdm-1:2.17.8-3.fc7 ------------------ * Fri Mar 09 2007 Ray Strode - 1:2.17.8-3 - hide langauges that aren't displayable from the list (bug 206048) gnome-bluetooth-0.8.0-3.fc7 --------------------------- * Tue Feb 27 2007 Harald Hoyer - 0.8.0-3.fc7 - corrected BuildRoot - smp flags added - specfile cleanup - fixed desktop file gstreamer-plugins-base-0.10.12-2.fc7 ------------------------------------ * Thu Mar 08 2007 - Bastien Nocera - 0.10.12-2 - Remove the patch to disable docs, install the docs by hand instead Add libgstpbutils to the files * Thu Mar 08 2007 - Bastien Nocera - 0.10.12-1 - Update to 0.10.12 * Wed Jan 24 2007 Adam Jackson - Minor spec cleanups (#186550) hplip-1.7.2-1.fc7 ----------------- * Thu Mar 01 2007 Tim Waugh 1.7.2-1 - 1.7.2. kernel-2.6.20-1.2982.fc7 ------------------------ * Fri Mar 09 2007 Dave Jones - 2.6.21-rc3-git5 libevent-1.3b-1.fc7 ------------------- * Fri Mar 09 2007 Steve Dickson 1.3b-1 - Updated to latest upstream version 1.3b - Incorporated Merge Review comments (bz 226002) - Increased the polling timeout (bz 204990) * Tue Feb 20 2007 Steve Dickson 1.2a-1 - Updated to latest upstream version 1.2a * Wed Jul 12 2006 Jesse Keating - rebuild libgssapi-0.10-2.fc7 -------------------- * Fri Mar 09 2007 Steve Dickson - 0.10-2 - Fixed file confliction with the i386 and x86 devel packages (bz 192708) minicom-2.2-1.fc7 ----------------- * Fri Mar 09 2007 Miroslav Lichvar 2.2-1 - update to 2.2 - handle filenames with spaces (#98655) - add requires for lrzsz - spec cleanup net-snmp-1:5.4-12.fc7 --------------------- * Fri Mar 09 2007 Radek Vok??l - 5.4-12 - lm_sensors-devel only where avaliable perl-4:5.8.8-15.fc7 ------------------- * Fri Mar 09 2007 Robin Norwood - 4:5.8.8-15 - Incorporate fixes from spot and others on fedora-perl-devel - The main perl package will temporarily Require perl-devel - move ExtUtils::MakeMaker, ExtUtils::Embed, CPAN, Test::Harness into devel - also move perlcc, perlivp, h2xs, libnetcfg to devel * Tue Feb 27 2007 Robin Norwood - 4:5.8.8-14 - Add a description for most of the patches, to reflect Spot's work to report said patches upstream. * Sat Feb 03 2007 Tom "spot" Callaway - 4:5.8.8-13 - massive cleanups perl-Archive-Tar-1.30-4.fc7 --------------------------- * Mon Mar 05 2007 Robin Norwood - 1.30-4 - Fix changelog pilot-link-2:0.12.1-5.fc7 ------------------------- * Fri Mar 09 2007 Ivana Varekova - 2:0.12.1-5 - incorporate the package review feedback tcp_wrappers-7.6-43.fc7 ----------------------- * Fri Mar 09 2007 Tomas Janousek - 7.6-43 - resolve hostnames in hosts.{allow,deny}, should fix a bunch of issues with IPv4/6 totem-2.18.0-1.fc7 ------------------ * Fri Mar 09 2007 - Bastien Nocera - 2.18.0-1 - Update to 2.18.0 - Update GStreamer base plugins requirements to get some "codec-buddy" support xorg-x11-drv-nv-1.99.1-1.fc7 ---------------------------- * Fri Mar 09 2007 Adam Jackson 1.99.1-1 - Update to nv 1.99.1, adds G80 support (wooooo!) - nv.xinf: Add the G80 PCI IDs. xorg-x11-server-utils-7.2-1.fc7 ------------------------------- * Wed Feb 28 2007 Adam Jackson 7.2-1 - Superstition bump to 7.2 - xrandr 1.2.0 zlib-1.2.3-9.fc7 ---------------- * Fri Mar 09 2007 Ivana Varekova -1.2.3-9 - incorporate package review feedback Broken deps for s390 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeaddons - 3.5.6-3.fc7.s390 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.s390 requires libevent-1.2a.so.1 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 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ia64 requires xdg-utils kdeaddons - 3.5.6-3.fc7.ia64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ia64 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.ia64 requires libevent-1.2a.so.1()(64bit) Broken deps for ppc64 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ppc64 requires xdg-utils kdeaddons - 3.5.6-3.fc7.ppc64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ppc64 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.ppc64 requires libevent-1.2a.so.1()(64bit) Broken deps for i386 ---------------------------------------------------------- frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeaddons - 3.5.6-3.fc7.i386 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.i386 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.i386 requires libevent-1.2a.so.1 Broken deps for x86_64 ---------------------------------------------------------- frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libofx.so.3()(64bit) gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.x86_64 requires xdg-utils kdeaddons - 3.5.6-3.fc7.i386 requires xdg-utils kdeaddons - 3.5.6-3.fc7.x86_64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.x86_64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.i386 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.i386 requires libevent-1.2a.so.1 nfs-utils - 1:1.0.12-1.fc7.x86_64 requires libevent-1.2a.so.1()(64bit) python-pyblock - 0.27-3.i386 requires libdmraid.so.1.0.0.rc14 python-pyblock - 0.27-3.i386 requires libdmraid.so.1.0.0.rc14(Base) Broken deps for ppc ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ppc requires libofx.so.3 gnucash - 2.0.5-1.fc6.ppc requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.ppc requires xdg-utils kdeaddons - 3.5.6-3.fc7.ppc requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ppc requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.ppc requires libevent-1.2a.so.1 Broken deps for s390x ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.s390x requires libofx.so.3()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.s390x requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeaddons - 3.5.6-3.fc7.s390 requires xdg-utils kdeaddons - 3.5.6-3.fc7.s390x requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390x requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.s390 requires libevent-1.2a.so.1 nfs-utils - 1:1.0.12-1.fc7.s390x requires libevent-1.2a.so.1()(64bit) python-pyblock - 0.27-3.s390 requires libdmraid.so.1.0.0.rc14(Base) python-pyblock - 0.27-3.s390 requires libdmraid.so.1.0.0.rc14 From mike at miketc.com Sat Mar 10 15:01:36 2007 From: mike at miketc.com (Mike Chambers) Date: Sat, 10 Mar 2007 09:01:36 -0600 Subject: Merge in effect? Message-ID: <1173538896.6787.8.camel@scrappy.miketc.com> Is indeed the merge now happening as of today? It looks like a lot of stuff from extras was removed and now rawhide is taking on a lot of extra (pun/no pun? haha) packages. Will everything (provided no problems of course) get merged over today, guess depending on the build working? -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless your not getting any!" From dennis at ausil.us Sat Mar 10 15:48:05 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Sat, 10 Mar 2007 09:48:05 -0600 Subject: When to expect support for 3945 Wireless in Rawhide In-Reply-To: <20070310135917.GA11811@redhat.com> References: <45F2B908.8050309@pajato.com> <20070310135917.GA11811@redhat.com> Message-ID: <200703100948.06145.dennis@ausil.us> Once upon a time Saturday 10 March 2007, John W. Linville wrote: > On Sat, Mar 10, 2007 at 08:56:24AM -0500, Paul Michael Reilly wrote: > > I've seen snippets discussing ipw3945 (sp?) wireless support in an > > upcoming kernel which I thought to be the kernels supplied on Rawhide > > yum updates but I do not see any trace of 3945 support in > > /var/log/messages. So the question is: if my laptop has the 3945 chip > > and it is not seen by the most recent Rawhide kernels is that a bug? If > > not, at what point will Rawhide have a kernel such that the 3945 chip > > should be seen? > > Shortly after Intel actual posts a patch for inclusion of the iwlwifi > driver in the wireless-dev kernel tree. > > For now, you may wish to try my test kernels: > > http://people.redhat.com/linville/kernels/fc7/ > I think someone needs to send the intel team an email. I sent them an email asking them to send it upstream. The response i got back was to use your test kernels for now and that it will be in Fedora 7. It seems there is a lack of something thre. Dennis From lamont at gurulabs.com Sat Mar 10 16:15:40 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Sat, 10 Mar 2007 09:15:40 -0700 Subject: Detecting version in a SPEC file In-Reply-To: <200702190813.19348.jkeating@redhat.com> References: <200702181948.22568.lamont@gurulabs.com> <20070219135703.A2971@xos037.xos.nl> <200702190813.19348.jkeating@redhat.com> Message-ID: <200703100915.45444.lamont@gurulabs.com> On Monday 19 February 2007 06:13am, Jesse Keating wrote: > On Monday 19 February 2007 07:57, Jos Vos wrote: > > I don't know about Fedora, but on RHEL nothing on the system predefines > > the %rhel macro, that's purely an internal define in the RH build system. > > Correct, both Fedora and RHEL (5+)'s buildsystem defines %fedora for fedora > and %rhel for RHEL, as part of the definition of %{?dist} to .el5 for > RHEL, .fc5 for Fedora Core 5, .fc6 for Fedora Core 6, and .fc7 for Fedora > 7. All it requires is a macro file on the system building the packages for > you that defines these macros. Because of that, this technique really doesn't work for this package. For this RPM, I want to conditionally select which patch to apply based on the version of he installed gnupg package on the system it is building on. rpmbuild already has this information somewhere internally as it can compare versions for BuildRequires: lines. I'm looking for "something_that_gets_version" to use something like this: %define gnupg_version "%something_that_gets_version gnupg" %if "%gnupg_version" = "1.2" Patch1: GnuPG-Interface-0.33.test-results-1.2.patch BuildRequires: gpg = 1.2 %else Patch1: GnuPG-Interface-0.33.test-results-1.4.patch BuildRequires: gpg >= %{gnupg_version} %endif I need it to work for all sorts of distros, not just RHEL, FC and not just within buildsystems. Is there such a mechanism available for use in the SPEC file or do I need to execure an external rpm command to query for that on my own? -- 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 peter at thecodergeek.com Sat Mar 10 16:43:25 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 10 Mar 2007 08:43:25 -0800 Subject: Detecting version in a SPEC file In-Reply-To: <200703100915.45444.lamont@gurulabs.com> References: <200702181948.22568.lamont@gurulabs.com> <20070219135703.A2971@xos037.xos.nl> <200702190813.19348.jkeating@redhat.com> <200703100915.45444.lamont@gurulabs.com> Message-ID: <1173545005.6169.4.camel@tuxhugs> On Sat, 2007-03-10 at 09:15 -0700, Lamont Peterson wrote: > I'm looking for "something_that_gets_version" to use something like this: > > %define gnupg_version "%something_that_gets_version gnupg" > %if "%gnupg_version" = "1.2" > Patch1: GnuPG-Interface-0.33.test-results-1.2.patch > BuildRequires: gpg = 1.2 > %else > Patch1: GnuPG-Interface-0.33.test-results-1.4.patch > BuildRequires: gpg >= %{gnupg_version} > %endif > > I need it to work for all sorts of distros, not just RHEL, FC and not just > within buildsystems. > > Is there such a mechanism available for use in the SPEC file or do I need to > execure an external rpm command to query for that on my own? You could execute an `rpm -q` version query manually: %define gnupg_ver_major_minor %(rpm -q gnupg --qf '%{version}' 2>/dev/null | cut -d '.' -f 1,2) (That should all be on one line, in case it gets wrapped by your mailer.) In fact, if your patches are named accordingly, you might be able to use that directly in the patch names: Patch1: GnuPG-Interface-0.33.test-results.%{gnupg_ver_major_minor}.patch Hope that helps. -- Peter Gordon (codergeek42) / FSF Associate Member #5015 GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 mschwendt.tmp0701.nospam at arcor.de Sat Mar 10 17:10:06 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 10 Mar 2007 18:10:06 +0100 Subject: Merge in effect? In-Reply-To: <1173538896.6787.8.camel@scrappy.miketc.com> References: <1173538896.6787.8.camel@scrappy.miketc.com> Message-ID: <20070310181006.6997ec78.mschwendt.tmp0701.nospam@arcor.de> On Sat, 10 Mar 2007 09:01:36 -0600, Mike Chambers wrote: > Is indeed the merge now happening as of today? It looks like a lot of > stuff from extras was removed and now rawhide is taking on a lot of > extra (pun/no pun? haha) packages. For example? From drepper at redhat.com Sat Mar 10 17:35:27 2007 From: drepper at redhat.com (Ulrich Drepper) Date: Sat, 10 Mar 2007 09:35:27 -0800 Subject: RPATH status In-Reply-To: <87abylfka8.fsf@kosh.bigo.ensc.de> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <45F1CEE0.8020504@redhat.com> <87abylfka8.fsf@kosh.bigo.ensc.de> Message-ID: <45F2EC5F.5080607@redhat.com> Enrico Scholz wrote: > Back references (/..) should be avoided there because they will break > when binary is in a symlinked path. E.g. with > > | /usr/bin -> /vol1/usr/bin > | /usr/lib64 -> /vol2/usr/lib64 > > the RPATH above would be resolved to /vol1/usr/lib64/... If you create such situations it's your own fault. $ORIGIN is meant to be used with back references so stop spreading nonsense like this. There are certain things, like keeping bin and lib{,64}, which not only make sense but really are the only solution which makes sense. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From enrico.scholz at informatik.tu-chemnitz.de Sat Mar 10 18:18:05 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sat, 10 Mar 2007 19:18:05 +0100 Subject: RPATH status In-Reply-To: <45F2EC5F.5080607@redhat.com> (Ulrich Drepper's message of "Sat, 10 Mar 2007 09:35:27 -0800") References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <45F1CEE0.8020504@redhat.com> <87abylfka8.fsf@kosh.bigo.ensc.de> <45F2EC5F.5080607@redhat.com> Message-ID: <87zm6laroi.fsf@kosh.bigo.ensc.de> Ulrich Drepper writes: >> Back references (/..) should be avoided there because they will break >> when binary is in a symlinked path. E.g. with >> >> | /usr/bin -> /vol1/usr/bin >> | /usr/lib64 -> /vol2/usr/lib64 >> >> the RPATH above would be resolved to /vol1/usr/lib64/... > > If you create such situations it's your own fault. No; then the package is just broken because binaries can not find required libraries. > $ORIGIN is meant to be used with back references I do not think so; more common case is plain $ORIGIN or $ORIGIN/lib, and there it makes sense. Nobody can guarantee where /.. really points to. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From lamont at gurulabs.com Sat Mar 10 18:21:35 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Sat, 10 Mar 2007 11:21:35 -0700 Subject: Detecting version in a SPEC file In-Reply-To: <1173545005.6169.4.camel@tuxhugs> References: <200702181948.22568.lamont@gurulabs.com> <200703100915.45444.lamont@gurulabs.com> <1173545005.6169.4.camel@tuxhugs> Message-ID: <200703101121.35380.lamont@gurulabs.com> On Saturday 10 March 2007 09:43am, Peter Gordon wrote: > On Sat, 2007-03-10 at 09:15 -0700, Lamont Peterson wrote: > > I'm looking for "something_that_gets_version" to use something like this: > > > > %define gnupg_version "%something_that_gets_version gnupg" > > %if "%gnupg_version" = "1.2" > > Patch1: GnuPG-Interface-0.33.test-results-1.2.patch > > BuildRequires: gpg = 1.2 > > %else > > Patch1: GnuPG-Interface-0.33.test-results-1.4.patch > > BuildRequires: gpg >= %{gnupg_version} > > %endif > > > > I need it to work for all sorts of distros, not just RHEL, FC and not > > just within buildsystems. > > > > Is there such a mechanism available for use in the SPEC file or do I need > > to execure an external rpm command to query for that on my own? > > You could execute an `rpm -q` version query manually: Yeah, that's basically what I'm trying now (still working on getting one of the patches built correctly too). I was just hoping there was a way internal to rpmbuild so I wouldn't have to run an external command, thinking that would probably be cleaner. > %define gnupg_ver_major_minor %(rpm -q gnupg --qf '%{version}' 2>/dev/null > | cut -d '.' -f 1,2) Right now, I'm doing: %define gnupg_version %(rpm -q --queryformat '%{version}' gnupg 2>/dev/null | cut -d. -f 1,2) > (That should all be on one line, in case it gets wrapped by your > mailer.) Yup. > In fact, if your patches are named accordingly, you might be able to use > that directly in the patch names: > > Patch1: GnuPG-Interface-0.33.test-results.%{gnupg_ver_major_minor}.patch I like that idea, but in this case, the latest version doesn't need a patch. If/when a future release of gnupg changes the output again that make this patch necessary, then I'll create another set of entries to deal with the current set of files for version 1.4.x, etc. > Hope that helps. It does. However, I'm getting an error trying to run rpmbuild against the spec file: $ rpmbuild -ba perl-GnuPG-Interface.spec error: syntax error while parsing == error: /home/lamontp/rpmbuild/SPECS/perl-GnuPG-Interface.spec:15: parseExpressionBoolean returns -1 error: Package has no %description: perl-GnuPG-Interface There is a %description (which works fine without this conditional stuff). Lines 15 is: %if "%gnupg_version" = "1.2" I've double checked the exact command being used to define %gnupg_version and that is working correctly. This makes me think that I've got a syntax error on line 15, but it's such a simple line that I don't see what it could be. If I take out line 15 (and corresponding elements), it works just fine, so it really seems to be something wrong with the %if. Any ideas? BTW: I've already spoken with the package maintainer for this package (in extras) and will be giving him the results of this for EPEL to be able to build this package, too. -- 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 mike at miketc.com Sat Mar 10 18:45:04 2007 From: mike at miketc.com (Mike Chambers) Date: Sat, 10 Mar 2007 12:45:04 -0600 Subject: Merge in effect? In-Reply-To: <20070310181006.6997ec78.mschwendt.tmp0701.nospam@arcor.de> References: <1173538896.6787.8.camel@scrappy.miketc.com> <20070310181006.6997ec78.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1173552304.7972.2.camel@scrappy.miketc.com> On Sat, 2007-03-10 at 18:10 +0100, Michael Schwendt wrote: > On Sat, 10 Mar 2007 09:01:36 -0600, Mike Chambers wrote: > > > Is indeed the merge now happening as of today? It looks like a lot of > > stuff from extras was removed and now rawhide is taking on a lot of > > extra (pun/no pun? haha) packages. > > For example? Well, I don't have any examples, as I have not compared what packages. I guess it *looks* that way (if it is indeed not merging yet) due to I mirror both extras and rawhide (every 4 hours) and saw where lots of packages were deleted from extras and lots were added to rawhide. That and the rawhide/os/Fedora/RPMS dir was deleted and the packages reproproated into rawhide/os/Fedora instead. -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless your not getting any!" From mschwendt.tmp0701.nospam at arcor.de Sat Mar 10 19:25:44 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 10 Mar 2007 20:25:44 +0100 Subject: Merge in effect? In-Reply-To: <1173552304.7972.2.camel@scrappy.miketc.com> References: <1173538896.6787.8.camel@scrappy.miketc.com> <20070310181006.6997ec78.mschwendt.tmp0701.nospam@arcor.de> <1173552304.7972.2.camel@scrappy.miketc.com> Message-ID: <20070310202544.bbe6e802.mschwendt.tmp0701.nospam@arcor.de> On Sat, 10 Mar 2007 12:45:04 -0600, Mike Chambers wrote: > On Sat, 2007-03-10 at 18:10 +0100, Michael Schwendt wrote: > > On Sat, 10 Mar 2007 09:01:36 -0600, Mike Chambers wrote: > > > > > Is indeed the merge now happening as of today? It looks like a lot of > > > stuff from extras was removed and now rawhide is taking on a lot of > > > extra (pun/no pun? haha) packages. > > > > For example? > > Well, I don't have any examples, as I have not compared what packages. > I guess it *looks* that way (if it is indeed not merging yet) due to I > mirror both extras and rawhide (every 4 hours) and saw where lots of > packages were deleted from extras and lots were added to rawhide. That > and the rawhide/os/Fedora/RPMS dir was deleted and the packages > reproproated into rawhide/os/Fedora instead. That's coincidence. From pmr at pajato.com Sat Mar 10 19:58:31 2007 From: pmr at pajato.com (Paul Michael Reilly) Date: Sat, 10 Mar 2007 14:58:31 -0500 Subject: When to expect support for 3945 Wireless in Rawhide In-Reply-To: <20070310135917.GA11811@redhat.com> References: <45F2B908.8050309@pajato.com> <20070310135917.GA11811@redhat.com> Message-ID: <45F30DE7.40302@pajato.com> John W. Linville wrote: > On Sat, Mar 10, 2007 at 08:56:24AM -0500, Paul Michael Reilly wrote: >> I've seen snippets discussing ipw3945 (sp?) wireless support in an >> upcoming kernel which I thought to be the kernels supplied on Rawhide >> yum updates but I do not see any trace of 3945 support in >> /var/log/messages. So the question is: if my laptop has the 3945 chip >> and it is not seen by the most recent Rawhide kernels is that a bug? If >> not, at what point will Rawhide have a kernel such that the 3945 chip >> should be seen? > > Shortly after Intel actual posts a patch for inclusion of the iwlwifi > driver in the wireless-dev kernel tree. > > For now, you may wish to try my test kernels: > > http://people.redhat.com/linville/kernels/fc7/ I'm guessing you are the maintainer who is responsible for this piece of code in particular. If correct you have my endless appreciation for what you do. If I'm wrong then I would dearly love to hear from the maintainer. I assume you are in contact with the development mail list for the team that will supply the patch. From what Dennis Gilmore has to say it would appear that there is a chance there is some confusion about how ipw3945 is supposed to get into Fedora 7. It would be very good if the maintainer could confirm who is waiting on what such that F7 does not ship without first class ipw3945 support. I ran your kernel and the chip was detected on my HP nw9440 laptop so I considered that one hurdle overcome. But I forgot to download the firmware. Now why is that a separate process? How is this going to work with F7? Surely the firmware will be included in some rpm. Correct? If so can you supply both that rpm and the kernel rpm and I will perform a more realistic test. Thanks, -pmr From michael.vanderheeren at gmail.com Sat Mar 10 21:35:17 2007 From: michael.vanderheeren at gmail.com (=?iso-8859-1?Q?Micha=EBl_Vanderheeren?=) Date: Sat, 10 Mar 2007 22:35:17 +0100 Subject: When to expect support for 3945 Wireless in Rawhide In-Reply-To: <45F30DE7.40302@pajato.com> References: <45F2B908.8050309@pajato.com> <20070310135917.GA11811@redhat.com> <45F30DE7.40302@pajato.com> Message-ID: <45f32497.3d8dc211.1430.0051@mx.google.com> Correct me if I'm wrong, but I think there are drivers for the Intel wireless 3945, as there are also drivers for the 2200. If we just include DKMS and those driver rpm's, called ipw3945 and ipw2200, everything should be fine I think... If we start the NetworkManager on boot... Micha?l V. -----Oorspronkelijk bericht----- Van: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-bounces at redhat.com] Namens Paul Michael Reilly Verzonden: zaterdag 10 maart 2007 20:59 Aan: Development discussions related to Fedora Core Onderwerp: Re: When to expect support for 3945 Wireless in Rawhide John W. Linville wrote: > On Sat, Mar 10, 2007 at 08:56:24AM -0500, Paul Michael Reilly wrote: >> I've seen snippets discussing ipw3945 (sp?) wireless support in an >> upcoming kernel which I thought to be the kernels supplied on Rawhide >> yum updates but I do not see any trace of 3945 support in >> /var/log/messages. So the question is: if my laptop has the 3945 chip >> and it is not seen by the most recent Rawhide kernels is that a bug? If >> not, at what point will Rawhide have a kernel such that the 3945 chip >> should be seen? > > Shortly after Intel actual posts a patch for inclusion of the iwlwifi > driver in the wireless-dev kernel tree. > > For now, you may wish to try my test kernels: > > http://people.redhat.com/linville/kernels/fc7/ I'm guessing you are the maintainer who is responsible for this piece of code in particular. If correct you have my endless appreciation for what you do. If I'm wrong then I would dearly love to hear from the maintainer. I assume you are in contact with the development mail list for the team that will supply the patch. From what Dennis Gilmore has to say it would appear that there is a chance there is some confusion about how ipw3945 is supposed to get into Fedora 7. It would be very good if the maintainer could confirm who is waiting on what such that F7 does not ship without first class ipw3945 support. I ran your kernel and the chip was detected on my HP nw9440 laptop so I considered that one hurdle overcome. But I forgot to download the firmware. Now why is that a separate process? How is this going to work with F7? Surely the firmware will be included in some rpm. Correct? If so can you supply both that rpm and the kernel rpm and I will perform a more realistic test. Thanks, -pmr -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list From seg at haxxed.com Sat Mar 10 22:24:36 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 10 Mar 2007 16:24:36 -0600 Subject: Problems with ordering multiple sound cards with ALSA Message-ID: <1173565476.18771.84.camel@localhost.localdomain> I'm having some obnoxious problems with using multiple ALSA devices, and their ordering. I am trying to set up a music workstation. I have the motherboard onboard sound (snd-intel8x0), a Behringer USB audio interface (snd_usb_audio), and an M-Audio Oxygen 49 MIDI keyboard (also snd_usb_audio). What I want to do, is have the onboard sound be the ALSA default, so all the various bleeps, blips, IM sounds, Doom 3, flash crap and so on go to my cheapo cheezy thundery-mini-subwoofer disco-smile Altec Lansing PC speakers. I want the USB device dedicated to jack, which goes to some semi-decent subwooferless flat-ish response Sony speakers. What happens is USB devices always get detected and loaded first. Amusingly/annoyingly, if I only have the Oxygen MIDI keyboard plugged in upon booting, it is assigned ALSA slot 0 even being a purely MIDI device, and all apps try and use it for audio output and fail spectacularly. The onboard sound gets loaded last and ends up slot 1 or 2 if I have the USB audio interface plugged in too. Now, the latest system-config-soundcard seems to have grown the ability to handle multiple soundcards at some point, and allow me to quickly and easily fix the ordering. Its exactly what I need. Except... the changes don't seem to be permanent. It reverts on reboot. It doesn't modify modprobe.conf like it/kudzu used to do. I can't find any sign of it saving any configuration anywhere. What's up with that? Is this supposed to work? Am I missing something? This *is* FC6, not devel I'm using. Oh well, I guess I get to hand-modify modprobe.conf by hand for now, based on what's still in some of my older systems... alias snd-card-0 snd-intel8x0 options snd-card-0 index=0 options snd-intel8x0 index=0 remove snd-intel8x0 { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-intel8x0 etc... -------------- 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 Mar 10 22:54:13 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 10 Mar 2007 16:54:13 -0600 Subject: announce: readahead-1.4 In-Reply-To: References: <20070301105026.GF4449@petra.dvoda.cz> <883cfe6d0703051442v2d74ebe8w6ef1764cd659cbd5@mail.gmail.com> <1173275392.3617.6.camel@max.booze> <20070307135206.08f1cb6e@banea.int.addix.net> <1173310709.3617.84.camel@max.booze> Message-ID: <1173567253.18771.106.camel@localhost.localdomain> On Fri, 2007-03-09 at 14:48 +0100, Benny Amorsen wrote: > >>>>> "CL" == Callum Lerwick writes: > > CL> I don't see how they could patent defragging a disk. Lets not get > CL> crazy here. ext3 does a decent job of not fragmenting files > CL> unnecessarily, can we really gain much more than the current > CL> readahead solution? > > I think the operative word here is "unnecessarily". Desktop hard > drives stay full once they fill up. Very few people clear off more > than 20% once they've run out of disk space. Linux is better than most > at avoiding fragmentation, but no (non-repacking) algorithm works well > when only 5-20% disk space remains. > > I really wish ext3 had a defrag utility which worked. Yes, what it all comes down to, is we need a low level tool that can safely move data blocks around on an ext3 filesystem, preferably while mounted. On top of this we can build a whole filesystem defragger, implement hot files, whatever. Mainly what I'm trying to say is this flash crap Microsoft is hyping as "cache" in Vista is a total farce. Flash is SLOW. I can't even think of a good treacherous reason MS would push this bullshit on the industry. So that Intel and Maxtor can sell more hardware once the flash wears out? Does it enable Treacherous Computing in some way? I have yet to stumble upon any conspiracy theories. Maybe I can be the one to start some. Now, journaling and hibernation, flash might have some use there. But don't use it for cache. Go buy more RAM and defrag your disk, its cheaper and orders of magnitude faster. -------------- 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 abartlet at samba.org Sun Mar 11 00:14:43 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Sun, 11 Mar 2007 11:14:43 +1100 Subject: RPATH status In-Reply-To: <45F1CE12.1000708@redhat.com> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> Message-ID: <1173572083.3506.111.camel@localhost.localdomain> On Fri, 2007-03-09 at 13:13 -0800, Ulrich Drepper wrote: > Christopher Aillon wrote: > >> 3 /usr/lib64/firefox-2.0.0.2 > > > > Some of them are intentional, such as the above. It's either rpath or > > munging LD_LIBRARY_PATH at startup if you want a working firefox. > > RPATH is perfectly fine for these purposes. Do we have a preference against wrapper scripts for munging LD_LIBRARY_PATH (I think we should)? The reason I ask is that I've been looking at the Fedora DS situation (now a package in extras), where every binary is wrapped in a shell script to munge the LD_LIBRARY_PATH, which just seems wrong to me. Likewise, where should a package place 'internal only' libraries, such as libslapd for Fedora DS, and some similar libraries in an eventual Samba4 package (to avoid bloat by static linking shared internal functionality)? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.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 drepper at redhat.com Sun Mar 11 00:26:13 2007 From: drepper at redhat.com (Ulrich Drepper) Date: Sat, 10 Mar 2007 16:26:13 -0800 Subject: RPATH status In-Reply-To: <87zm6laroi.fsf@kosh.bigo.ensc.de> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <45F1CEE0.8020504@redhat.com> <87abylfka8.fsf@kosh.bigo.ensc.de> <45F2EC5F.5080607@redhat.com> <87zm6laroi.fsf@kosh.bigo.ensc.de> Message-ID: <45F34CA5.7070406@redhat.com> Enrico Scholz wrote: >> $ORIGIN is meant to be used with back references > > I do not think so What are you talking about? You must have implemented all this stuff and know about it, right? Wait... it was I who did that. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From shams at orcon.net.nz Sun Mar 11 02:09:31 2007 From: shams at orcon.net.nz (Shams) Date: Sun, 11 Mar 2007 15:09:31 +1300 Subject: Fedora 6 and Disk Druid Overall Disk Space Message-ID: Hi, Here is the scenario, lets say I have a 60gb hard disk. When installing Fedora via gui I noticed that Disk Druid does not give you the option of specifying the overall disk space to allocate to Fedora. In this case I want to allocate 20gb to Fedora and Disk Druid should allow me to do that, then I can carry on with installation as usual. Can this feature be implemented, please. Thanks Shams From hhoffman at ip-solutions.net Sun Mar 11 02:30:58 2007 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Sat, 10 Mar 2007 21:30:58 -0500 (EST) Subject: Fedora 6 and Disk Druid Overall Disk Space In-Reply-To: References: Message-ID: It certainly does... you just have to use the "Create a custom layout" instead of the default which will use the whole disk. On Sun, 11 Mar 2007, Shams wrote: > Hi, > > Here is the scenario, lets say I have a 60gb hard disk. > > When installing Fedora via gui I noticed that Disk Druid does not give > you the option of specifying the overall disk space to allocate > to Fedora. > > In this case I want to allocate 20gb to Fedora and Disk Druid should > allow me to do that, then I can carry on with installation as usual. > > Can this feature be implemented, please. > > Thanks > Shams > > > > From shams at orcon.net.nz Sun Mar 11 02:38:40 2007 From: shams at orcon.net.nz (Shams) Date: Sun, 11 Mar 2007 15:38:40 +1300 Subject: Fedora 6 and Disk Druid Overall Disk Space References: Message-ID: Thanks for the info. With custom layout you have to create/adjust the partitions and lvm's yourself where as with the default layout disk druid creates the partitions and lvm's as it deems fit which I am normally happy with BUT it ends up taking the entire leftover space to achieve this. However when I want to create the custom layout then I should be able to specify that ONLY 20gb should be allocated and then the partitions and lvms should be created as disk druid seems fit just like default layout does BUT working within those 20gb. Thanks Shams -- "Harry Hoffman" wrote in message news:Pine.LNX.4.64.0703102130190.29020 at pony.ip-solutions.net... > It certainly does... you just have to use the "Create a custom layout" > instead of the default which will use the whole disk. > > > On Sun, 11 Mar 2007, Shams wrote: > >> Hi, >> >> Here is the scenario, lets say I have a 60gb hard disk. >> >> When installing Fedora via gui I noticed that Disk Druid does not give >> you the option of specifying the overall disk space to allocate >> to Fedora. >> >> In this case I want to allocate 20gb to Fedora and Disk Druid should >> allow me to do that, then I can carry on with installation as usual. >> >> Can this feature be implemented, please. >> >> Thanks >> Shams >> >> >> >> > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From lamont at gurulabs.com Sun Mar 11 03:45:47 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Sat, 10 Mar 2007 20:45:47 -0700 Subject: Fedora 6 and Disk Druid Overall Disk Space In-Reply-To: References: Message-ID: <200703102045.52039.lamont@gurulabs.com> On Saturday 10 March 2007 07:38pm, Shams wrote: > Thanks for the info. > > With custom layout you have to create/adjust the partitions and lvm's > yourself > where as with the default layout disk druid creates the partitions and > lvm's as it > deems fit which I am normally happy with BUT it ends up taking the entire > leftover > space to achieve this. > > However when I want to create the custom layout then I should be able to > specify > that ONLY 20gb should be allocated and then the partitions and lvms should > be > created as disk druid seems fit just like default layout does BUT working > within > those 20gb. I thought there was some kind of "base the layout on the default" or something like that which would let you do the whole disk druid thing but give you something to start with. -- 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 shams at orcon.net.nz Sun Mar 11 04:59:48 2007 From: shams at orcon.net.nz (Shams) Date: Sun, 11 Mar 2007 17:59:48 +1300 Subject: Fedora 6 and Disk Druid Overall Disk Space References: <200703102045.52039.lamont@gurulabs.com> Message-ID: Yes thats what I want but I want to be able to say at the same time that Disk Druid is only allowed to use 20gb for this default layout and thats it which currently does not exist yet. Thanks Shams -- "Lamont Peterson" wrote in message news:200703102045.52039.lamont at gurulabs.com... > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From seg at haxxed.com Sun Mar 11 07:26:22 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 11 Mar 2007 01:26:22 -0600 Subject: A few ideas. In-Reply-To: <3170f42f0703072320me444e62l614bd3a3b79ebbce@mail.gmail.com> References: <3170f42f0703070928v17afe1bfhff32e015b7d84e6c@mail.gmail.com> <604aa7910703071621m8cb372cq256c8ab8b53cef7a@mail.gmail.com> <3170f42f0703072320me444e62l614bd3a3b79ebbce@mail.gmail.com> Message-ID: <1173597982.18771.110.camel@localhost.localdomain> On Thu, 2007-03-08 at 12:50 +0530, Debarshi 'Rishi' Ray wrote: > yum -C removes all network activity and uses only the local cache so > unless you cache the packages locally as well.. you cant easily use > yum -C to do installs or updates.. its very useful for check-update, > list, search, and provides functionality." > > The last paragraph intrigues me. May be that is why we do not have > 'yum -C ...' as the default behaviour. Yes, this behavior makes the -C option mostly useless. -------------- 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 jonesc at hep.phy.cam.ac.uk Sun Mar 11 09:35:28 2007 From: jonesc at hep.phy.cam.ac.uk (Chris Jones) Date: Sun, 11 Mar 2007 09:35:28 +0000 Subject: Problem with /sbin/weak-modules Message-ID: <200703110935.29639.jonesc@hep.phy.cam.ac.uk> Hi, I originally sent this email to the main fedora list, but got no response there so thought I would try my luck here. Hope its not OT. - I have been investigating a problem with some kernel modules (evil word I know) from livna. see https://bugzilla.livna.org/show_bug.cgi?id=1436 the assertion is that there is a problem with /sbin/weak-modules (module-init-tools) generating invalid sym-links for the latest FC6 kernel 2.6.19-1.2911.6.5.fc6 - I'm wondering if it has anything to do with the extra numbers the latest kernels seem to have gained - .6.5 - compared to normal. The suggestion is to file a bug, but I know really know enough about this component to do this, so thought I would fire off an email to this list first ? cheers Chris From abo at kth.se Sun Mar 11 09:56:43 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Sun, 11 Mar 2007 10:56:43 +0100 Subject: RPATH status In-Reply-To: <1173572083.3506.111.camel@localhost.localdomain> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <1173572083.3506.111.camel@localhost.localdomain> Message-ID: <1173607004.3816.18.camel@home.alexander.bostrom.net> s?n 2007-03-11 klockan 11:14 +1100 skrev Andrew Bartlett: > The reason I ask is that I've been looking at the Fedora DS situation > (now a package in extras), where every binary is wrapped in a shell > script to munge the LD_LIBRARY_PATH, which just seems wrong to me. Yeah, it would be better to use RPATH. If a process needs LD_LIBRARY_PATH set, but spawns other processes that do not need it, it's asking for trouble. (For example, a web browser that starts a PDF reader.) /abo From buildsys at redhat.com Sun Mar 11 10:33:25 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sun, 11 Mar 2007 06:33:25 -0400 Subject: rawhide report: 20070311 changes Message-ID: <200703111033.l2BAXPEl007715@hs20-bc2-6.build.redhat.com> Updated Packages: (none) Broken deps for x86_64 ---------------------------------------------------------- frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.x86_64 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeaddons - 3.5.6-3.fc7.i386 requires xdg-utils kdeaddons - 3.5.6-3.fc7.x86_64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.x86_64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.i386 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.i386 requires libevent-1.2a.so.1 nfs-utils - 1:1.0.12-1.fc7.x86_64 requires libevent-1.2a.so.1()(64bit) python-pyblock - 0.27-3.i386 requires libdmraid.so.1.0.0.rc14 python-pyblock - 0.27-3.i386 requires libdmraid.so.1.0.0.rc14(Base) Broken deps for ia64 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ia64 requires xdg-utils kdeaddons - 3.5.6-3.fc7.ia64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ia64 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.ia64 requires libevent-1.2a.so.1()(64bit) Broken deps for s390x ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.s390x requires libofx.so.3()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.s390x requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeaddons - 3.5.6-3.fc7.s390x requires xdg-utils kdeaddons - 3.5.6-3.fc7.s390 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390x requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.s390 requires libevent-1.2a.so.1 nfs-utils - 1:1.0.12-1.fc7.s390x requires libevent-1.2a.so.1()(64bit) python-pyblock - 0.27-3.s390 requires libdmraid.so.1.0.0.rc14(Base) python-pyblock - 0.27-3.s390 requires libdmraid.so.1.0.0.rc14 Broken deps for s390 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeaddons - 3.5.6-3.fc7.s390 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.s390 requires libevent-1.2a.so.1 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 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ppc64 requires xdg-utils kdeaddons - 3.5.6-3.fc7.ppc64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ppc64 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.ppc64 requires libevent-1.2a.so.1()(64bit) Broken deps for i386 ---------------------------------------------------------- frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeaddons - 3.5.6-3.fc7.i386 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.i386 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.i386 requires libevent-1.2a.so.1 Broken deps for ppc ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ppc requires libofx.so.3 gnucash - 2.0.5-1.fc6.ppc requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.ppc requires xdg-utils kdeaddons - 3.5.6-3.fc7.ppc requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ppc requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.ppc requires libevent-1.2a.so.1 From enrico.scholz at informatik.tu-chemnitz.de Sun Mar 11 10:50:03 2007 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 11 Mar 2007 11:50:03 +0100 Subject: RPATH status In-Reply-To: <45F34CA5.7070406@redhat.com> (Ulrich Drepper's message of "Sat, 10 Mar 2007 16:26:13 -0800") References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <45F1CEE0.8020504@redhat.com> <87abylfka8.fsf@kosh.bigo.ensc.de> <45F2EC5F.5080607@redhat.com> <87zm6laroi.fsf@kosh.bigo.ensc.de> <45F34CA5.7070406@redhat.com> Message-ID: <87tzwsawbo.fsf@kosh.bigo.ensc.de> Ulrich Drepper writes: >>> $ORIGIN is meant to be used with back references >> >> I do not think so > > What are you talking about? You must have implemented all this stuff > and know about it, right? Sorry, when $ORIGIN was really designed to allow things like '$ORIGIN/..', then the design of $ORIGIN is flawed. Enrico -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From benny+usenet at amorsen.dk Sun Mar 11 12:25:18 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 11 Mar 2007 13:25:18 +0100 Subject: announce: readahead-1.4 References: <20070301105026.GF4449@petra.dvoda.cz> <883cfe6d0703051442v2d74ebe8w6ef1764cd659cbd5@mail.gmail.com> <1173275392.3617.6.camel@max.booze> <20070307135206.08f1cb6e@banea.int.addix.net> <1173310709.3617.84.camel@max.booze> <1173567253.18771.106.camel@localhost.localdomain> Message-ID: >>>>> "CL" == Callum Lerwick writes: CL> Mainly what I'm trying to say is this flash crap Microsoft is CL> hyping as "cache" in Vista is a total farce. Flash is SLOW. Each flash cell is slow. You can read and write in parallel to almost as many as you want. The 32GB drive you can buy today reportedly does better than 50MB/s in both directions. I bet that beats out almost every other notebook drive for almost all non-benchmark workloads. As soon as Linux gets decent support for it, I'm going to put an 8GB (or better) SD card in my laptops card reader and move as much as possible there. Right now the options are either: put root on the SD card, which means I probably need to boot off of it, or put the ext3 journal on the card -- how well does ext3 handle an 8GB journal with data=journal? /Benny From dominik at greysector.net Sun Mar 11 12:04:09 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 11 Mar 2007 13:04:09 +0100 Subject: Extras x86_64 rawhide rebuild in mock status 2007-03-07 In-Reply-To: <20070307214138.A26115@humbolt.us.dell.com> References: <20070307214138.A26115@humbolt.us.dell.com> Message-ID: <20070311120409.GA17330@ryvius.pekin.waw.pl> On Thursday, 08 March 2007 at 04:41, Matt Domsch wrote: > Extras Rawhide-in-Mock Build Results for x86_64 Wed Mar 7 20:35:34 CST 2007 > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > Total packages: 2663 > Number failed to build: 62 > Number expected to fail due to ExclusiveArch or ExcludeArch: 0 > Leaving: 62 > (there may be some duplicates if rawhide has 2 versions of a package) > > Of those expected to have worked... > Without a bug filed: 61 > ---------------------------------- [...] > crm114-0-0.2.20060704.fc6 rpm at greysector.net Something is wrong here. This one has both ExcludeArch and a bug filled (albeit for fc6, not devel). 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 baris at teamforce.name.tr Sun Mar 11 16:08:12 2007 From: baris at teamforce.name.tr (Baris Cicek) Date: Sun, 11 Mar 2007 18:08:12 +0200 Subject: Fedora 6 a bit more automated install In-Reply-To: References: Message-ID: <1173629292.3208.16.camel@localhost.localdomain> After that point installation start writing to disk. Before that everything is happening without any change on the hdd. It's a good pointer for user that after that moment s/he is starting to change his partitions. AFAIK, after this point anaconda do formatting of the partitions. One last click won't annoy user much, but losing whole partitions might. However, I think this page should point this fact more explicitly. Stating that (if user chose to format any partitions) "After this part your data on 'blah blah' partitions will be cleared". On Sun, 2007-03-11 at 02:27 +1300, Shams wrote: > Hi, > > Once I have started installing Fedora 6 it works out the > packages/dependencies and then waits > for me to press the "Next" button before it starts the actual installtion. > > Maybe it should just go ahead and do it without waiting for > the user to press the "Next" button. > > Is it possible to automate this already, if not then I think this will be a > good feature to have? > > Thanks > Shams > > > From jcm at redhat.com Sun Mar 11 16:40:17 2007 From: jcm at redhat.com (Jon Masters) Date: Sun, 11 Mar 2007 12:40:17 -0400 Subject: Problem with /sbin/weak-modules In-Reply-To: <200703110935.29639.jonesc@hep.phy.cam.ac.uk> References: <200703110935.29639.jonesc@hep.phy.cam.ac.uk> Message-ID: <45F430F1.6050406@redhat.com> Chris Jones wrote: > The suggestion is to file a bug, but I know really know enough about this > component to do this, so thought I would fire off an email to this list > first ? I'm responsible for that script in Fedora, so feel free to send me email describing what exactly is going right/wrong and I'll help diagnose. Cheers, Jon. From jcm at redhat.com Sun Mar 11 16:45:58 2007 From: jcm at redhat.com (Jon Masters) Date: Sun, 11 Mar 2007 12:45:58 -0400 Subject: Problem with /sbin/weak-modules In-Reply-To: <45F430F1.6050406@redhat.com> References: <200703110935.29639.jonesc@hep.phy.cam.ac.uk> <45F430F1.6050406@redhat.com> Message-ID: <45F43246.2090503@redhat.com> Jon Masters wrote: > Chris Jones wrote: > >> The suggestion is to file a bug, but I know really know enough about >> this component to do this, so thought I would fire off an email to >> this list first ? > > I'm responsible for that script in Fedora, so feel free to send me email > describing what exactly is going right/wrong and I'll help diagnose. Oh, I see what's happening: * You didn't upgrade to a newer kernel module, but expected weak-modules to make a symlink. * weak-modules logic has broken with the change in kernel numbering. Correct? If this is all that's at fault, it's probably a simple logic problem that I can fix tomorrow when I get a chance to look at it - but if you think I should know anything else, drop me a line. FWIW, weak-modules will go away in a future Fedora. The plan is to replace it with a much more comprehensive online driver update tool that will do a lot more than just create symlinks - more information when I have an example to share... :-) Jon. From wtogami at redhat.com Sun Mar 11 16:56:09 2007 From: wtogami at redhat.com (Warren Togami) Date: Sun, 11 Mar 2007 12:56:09 -0400 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> Message-ID: <45F434A9.8060504@redhat.com> Jonathan Dieter wrote: > On Fri, 2007-03-09 at 20:01 -0500, Warren Togami wrote: >> 1) Client wants to upgrade from foo-3.2-1 to foo-3.2-2 (Transition X) >> 2) Client metadata sees that Transition X has a drpm available (from >> metadata or something). > At the moment, it checks to see if a drpm is available from your > deltarpm url that matches a filename. If the file doesn't exist, then > there is no drpm for this particular update. I could code in a way of > using metadata rather than filename checking, if that's what's > preferred. Are we talking a yum-style xml file? Yes. But this is only an optimization for later. Checking for existence of the file and using 404 is a bit slow, so metadata would speed this up a bit. >> 3) Client checks using rpm -V (or more likely the rpm API equivalent) to >> see if the local files are intact. This step is a little time >> consuming, but it is worthwhile because we know that a drpm is available >> above the defined efficiency threshold. > Should be easy to implement, and, yes, would be very important. FYI, > the current efficiency threshold is 50%. It is very easy to adjust this > level. Could the efficiency threshold be > 50% and drpm is larger than a certain size? This is because it is pointless to have drpms of tiny packages. What exact threshold size however I don't know. >> 4) All files are intact, except some files in /etc marked %config are >> changed. This is OK. > Yes. Deltarpm stores %config files in the drpm no matter whether > they've changed or not. >> 5) drpm contains %config file data even if they did not change in >> Transition X. This allows reconstruction of the original foo-3.2-2 RPM >> even if the local %config files are modified. >> >> deltarpm needs to put data within the drpm that is likely to change on >> the local systems. This includes %config, but possibly other things >> like /var. We can craft this predefined list to whatever our research >> finds is necessary. > As far as I know, deltarpm doesn't have a way for the user to choose > which files *must* get stored in the drpm. Not asking for users to choose which files must be stored in drpm. Just indicating that it might be important for other non-%config files to be stored. I might be wrong. We'll see in testing. Warren Togami wtogami at redhat.com From gauret at free.fr Sun Mar 11 17:05:46 2007 From: gauret at free.fr (Aurelien Bompard) Date: Sun, 11 Mar 2007 18:05:46 +0100 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files Message-ID: Dear Fedoreans, Having followed the debate over whether to flag init scripts as %config files, I thought that there's a feature of another package manager that I liked: when a config file has changed, it asks you if you want to keep your local copy or if you want to install the package's version. RPM is non-interactive, so it's not supposed to do this. But I thought this could be implemented in a yum plugin. I've written a plugin which does just this: http://gauret.free.fr/fichiers/rpms/fedora/yum-merge-conf/merge-conf.py http://gauret.free.fr/fichiers/rpms/fedora/yum-merge-conf/yum-merge-conf-1.0-1.noarch.rpm Add the --merge-conf command line option to your yum update, and it will ask you what to do with those .rpm{save,new} files as the packages are installed. You'll be able to diff the files, choose your version, or spawn a shell to check further. If you think you could be interested in this feature, please have a look. If you think it's a useful plugin and it's decently written (it's my first yum plugin), I'll submit it to the yum list. Cheers, Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr A Black Hole is where God divided by zero. From naheemzaffar at gmail.com Sun Mar 11 17:12:57 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sun, 11 Mar 2007 17:12:57 +0000 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <45F434A9.8060504@redhat.com> References: <1173387027.3038.6.camel@sb-home.lan> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> <45F434A9.8060504@redhat.com> Message-ID: <3adc77210703111012q7b697c66t2285e51a40408238@mail.gmail.com> On 3/11/07, Warren Togami wrote: > Could the efficiency threshold be > 50% and drpm is larger than a > certain size? This is because it is pointless to have drpms of tiny > packages. What exact threshold size however I don't know. > Woud that not cause problems? If say the original rpm is 50 MB, the drpm say 0.1MB because only a few small files were changed, having a minimum size may force the download of the full rpm. If you had efficiency threashold at >50% and size of ORIGINAL rpm larger than a certain size (say 1 meg? 10 megs? that would be up to whoever is doing the work and not me, a lurker), it could work. From lsof at nodata.co.uk Sun Mar 11 17:56:20 2007 From: lsof at nodata.co.uk (nodata) Date: Sun, 11 Mar 2007 18:56:20 +0100 Subject: Fedora 6 a bit more automated install In-Reply-To: <1173629292.3208.16.camel@localhost.localdomain> References: <1173629292.3208.16.camel@localhost.localdomain> Message-ID: <1173635780.3034.0.camel@sb-home.lan> Am Sonntag, den 11.03.2007, 18:08 +0200 schrieb Baris Cicek: > After that point installation start writing to disk. Before that > everything is happening without any change on the hdd. > > It's a good pointer for user that after that moment s/he is starting to > change his partitions. AFAIK, after this point anaconda do formatting of > the partitions. One last click won't annoy user much, but losing whole > partitions might. > > However, I think this page should point this fact more explicitly. > Stating that (if user chose to format any partitions) "After this part > your data on 'blah blah' partitions will be cleared". You already get a warning before partitions are changed. From seg at haxxed.com Sun Mar 11 17:58:10 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 11 Mar 2007 12:58:10 -0500 Subject: RPATH status In-Reply-To: <87tzwsawbo.fsf@kosh.bigo.ensc.de> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <45F1CEE0.8020504@redhat.com> <87abylfka8.fsf@kosh.bigo.ensc.de> <45F2EC5F.5080607@redhat.com> <87zm6laroi.fsf@kosh.bigo.ensc.de> <45F34CA5.7070406@redhat.com> <87tzwsawbo.fsf@kosh.bigo.ensc.de> Message-ID: <1173635890.18771.111.camel@localhost.localdomain> On Sun, 2007-03-11 at 11:50 +0100, Enrico Scholz wrote: > Sorry, when $ORIGIN was really designed to allow things like '$ORIGIN/..', > then the design of $ORIGIN is flawed. Nothing is perfect. Get over it. -------------- 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 a.badger at gmail.com Sun Mar 11 18:01:14 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sun, 11 Mar 2007 11:01:14 -0700 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <3adc77210703111012q7b697c66t2285e51a40408238@mail.gmail.com> References: <1173387027.3038.6.camel@sb-home.lan> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> <45F434A9.8060504@redhat.com> <3adc77210703111012q7b697c66t2285e51a40408238@mail.gmail.com> Message-ID: <1173636074.3329.278.camel@localhost.localdomain> On Sun, 2007-03-11 at 17:12 +0000, Naheem Zaffar wrote: > On 3/11/07, Warren Togami wrote: > > > Could the efficiency threshold be > 50% and drpm is larger than a > > certain size? This is because it is pointless to have drpms of tiny > > packages. What exact threshold size however I don't know. > > > > Woud that not cause problems? If say the original rpm is 50 MB, the > drpm say 0.1MB because only a few small files were changed, having a > minimum size may force the download of the full rpm. > > If you had efficiency threashold at >50% and size of ORIGINAL rpm > larger than a certain size (say 1 meg? 10 megs? that would be up to > whoever is doing the work and not me, a lurker), it could work. > Another metric could simply be absolute size of the difference. If a major openoffice.org-core update was only a 25% savings, that would still be about 25MB of data. I suppose some of this depends on whether you're tuning this to be better for bandwith or diskspace. End users will be very happy to download 25MB less data. Mirrors would have to host an extra 75MB of data on their disks. -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 wtogami at redhat.com Sun Mar 11 18:07:21 2007 From: wtogami at redhat.com (Warren Togami) Date: Sun, 11 Mar 2007 14:07:21 -0400 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <1173636074.3329.278.camel@localhost.localdomain> References: <1173387027.3038.6.camel@sb-home.lan> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> <45F434A9.8060504@redhat.com> <3adc77210703111012q7b697c66t2285e51a40408238@mail.gmail.com> <1173636074.3329.278.camel@localhost.localdomain> Message-ID: <45F44559.3060506@redhat.com> Toshio Kuratomi wrote: >> If you had efficiency threashold at >50% and size of ORIGINAL rpm >> larger than a certain size (say 1 meg? 10 megs? that would be up to >> whoever is doing the work and not me, a lurker), it could work. >> > Another metric could simply be absolute size of the difference. If a > major openoffice.org-core update was only a 25% savings, that would > still be about 25MB of data. > Err, yes, this is what I meant. =) Warren Togami wtogami at redhat.com From giallu at gmail.com Sun Mar 11 18:20:40 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 11 Mar 2007 19:20:40 +0100 Subject: Fedora 6 a bit more automated install In-Reply-To: <1173629292.3208.16.camel@localhost.localdomain> References: <1173629292.3208.16.camel@localhost.localdomain> Message-ID: On 3/11/07, Baris Cicek wrote: > After that point installation start writing to disk. Before that > everything is happening without any change on the hdd. > > It's a good pointer for user that after that moment s/he is starting to > change his partitions. AFAIK, after this point anaconda do formatting of > the partitions. One last click won't annoy user much, but losing whole > partitions might. It would not annoy the user _IF_ the depsolving step was faster. I think this is the reason why I saw mails in the past with the same request: a fairly long step (depsolving) followed by another long step (actual installation) sounds naturally like they should be merged. IIRC the reason for this is that the depsolving phase could fail depending on the package selection and the selected repos; I still fail to see whay the last "Next" could not be skipped automatically when no such problem arise though... From email.ahmedkamal at googlemail.com Sun Mar 11 18:33:27 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sun, 11 Mar 2007 20:33:27 +0200 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <45F44559.3060506@redhat.com> References: <1173387027.3038.6.camel@sb-home.lan> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> <45F434A9.8060504@redhat.com> <3adc77210703111012q7b697c66t2285e51a40408238@mail.gmail.com> <1173636074.3329.278.camel@localhost.localdomain> <45F44559.3060506@redhat.com> Message-ID: <3da3b5b40703111133r5c7dd299u5e392dc701fe3e56@mail.gmail.com> What I currently have implemented is something like: If newRpmSize < 1M ==> drpm is not worth it if drpmsize > 50% of new rpm size ==> drpm is not worth it The actual values can be tuned of course, but I guess the idea of a lower bound, coupled with a percentage saving is generally acceptable. Also, preliminary size tests shows big savings for huge packages, so we only need to consider smaller ones carefully. On 3/11/07, Warren Togami wrote: > > Toshio Kuratomi wrote: > >> If you had efficiency threashold at >50% and size of ORIGINAL rpm > >> larger than a certain size (say 1 meg? 10 megs? that would be up to > >> whoever is doing the work and not me, a lurker), it could work. > >> > > Another metric could simply be absolute size of the difference. If a > > major openoffice.org-core update was only a 25% savings, that would > > still be about 25MB of data. > > > > Err, yes, this is what I meant. =) > > Warren Togami > wtogami at redhat.com > > -- > 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 lamont at gurulabs.com Sun Mar 11 19:20:09 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Sun, 11 Mar 2007 12:20:09 -0700 Subject: Fedora 6 a bit more automated install In-Reply-To: References: Message-ID: <200703111320.10069.lamont@gurulabs.com> On Saturday 10 March 2007 06:27am, Shams wrote: > Hi, > > Once I have started installing Fedora 6 it works out the > packages/dependencies and then waits > for me to press the "Next" button before it starts the actual installtion. > > Maybe it should just go ahead and do it without waiting for > the user to press the "Next" button. > > Is it possible to automate this already, I haven't tried this, but you could create a kickstart file with just one line that reads "install" and see if anaconda will take it. The "install" command is the one that tells anaconda to automatically say yes to that question. If a kickstart file doesn't have all the answers, it asks just the questions it needs to. Say, for example, that you have a kickstart file without timezone information; anaconda will use the answers that are present for everything else, asking only the one question about timezone configuration. > if not then I think this will be a > good feature to have? Perhaps, perhaps not. -- 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 Sun Mar 11 19:15:18 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Sun, 11 Mar 2007 12:15:18 -0700 Subject: Fedora 6 a bit more automated install In-Reply-To: References: <1173629292.3208.16.camel@localhost.localdomain> Message-ID: <200703111315.25651.lamont@gurulabs.com> On Sunday 11 March 2007 12:20pm, Gianluca Sforna wrote: > On 3/11/07, Baris Cicek wrote: > > After that point installation start writing to disk. Before that > > everything is happening without any change on the hdd. > > > > It's a good pointer for user that after that moment s/he is starting to > > change his partitions. AFAIK, after this point anaconda do formatting of > > the partitions. One last click won't annoy user much, but losing whole > > partitions might. > > It would not annoy the user _IF_ the depsolving step was faster. > > I think this is the reason why I saw mails in the past with the same > request: a fairly long step (depsolving) followed by another long step > (actual installation) sounds naturally like they should be merged. > > IIRC the reason for this is that the depsolving phase could fail > depending on the package selection and the selected repos; I still > fail to see whay the last "Next" could not be skipped automatically > when no such problem arise though... In that case, the "After clicking 'Next' your partitions will be altered" thing will need to be mentioned before depsolving. If depsolve fails, then bounce back to the package select screen with a (hopefully) useful error message. In other words, if this is going to be change, simply move depsolving to after the last confirm screen and right before partitioning, placing the final confirm question between package selection and depsolving. It certainly was logical to put package selection and depsolving together in the past, but perhaps this would be better. Of course, if my suggestion of how to implement this change were adopted, then when depsolving does fail, experienced users/admins might be frustrated that they walked away thinking there wasn't going to be any more interaction and it should have installed when they come back and see an error message. Then again, that's always true. -- 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 lsof at nodata.co.uk Sun Mar 11 19:48:11 2007 From: lsof at nodata.co.uk (nodata) Date: Sun, 11 Mar 2007 20:48:11 +0100 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <45F44559.3060506@redhat.com> References: <1173387027.3038.6.camel@sb-home.lan> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> <45F434A9.8060504@redhat.com> <3adc77210703111012q7b697c66t2285e51a40408238@mail.gmail.com> <1173636074.3329.278.camel@localhost.localdomain> <45F44559.3060506@redhat.com> Message-ID: <1173642491.3826.2.camel@sb-home.lan> Am Sonntag, den 11.03.2007, 14:07 -0400 schrieb Warren Togami: > Toshio Kuratomi wrote: > >> If you had efficiency threashold at >50% and size of ORIGINAL rpm > >> larger than a certain size (say 1 meg? 10 megs? that would be up to > >> whoever is doing the work and not me, a lurker), it could work. > >> > > Another metric could simply be absolute size of the difference. If a > > major openoffice.org-core update was only a 25% savings, that would > > still be about 25MB of data. > > > > Err, yes, this is what I meant. =) > > Warren Togami > wtogami at redhat.com > Is this delta rpm work separate from what Mandrake or Suse (I forget which) have been using for quite some time now? From email.ahmedkamal at googlemail.com Sun Mar 11 19:57:49 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sun, 11 Mar 2007 21:57:49 +0200 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <1173642491.3826.2.camel@sb-home.lan> References: <1173387027.3038.6.camel@sb-home.lan> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> <45F434A9.8060504@redhat.com> <3adc77210703111012q7b697c66t2285e51a40408238@mail.gmail.com> <1173636074.3329.278.camel@localhost.localdomain> <45F44559.3060506@redhat.com> <1173642491.3826.2.camel@sb-home.lan> Message-ID: <3da3b5b40703111257s4157b605va5cf2e0344161980@mail.gmail.com> This work is based on the "deltarpm" tool which is written by Michael Schroeder at suse, and is the tool used by suse. Not sure if Mandrake is using the same tool though! On 3/11/07, nodata wrote: > > Am Sonntag, den 11.03.2007, 14:07 -0400 schrieb Warren Togami: > > Toshio Kuratomi wrote: > > >> If you had efficiency threashold at >50% and size of ORIGINAL rpm > > >> larger than a certain size (say 1 meg? 10 megs? that would be up to > > >> whoever is doing the work and not me, a lurker), it could work. > > >> > > > Another metric could simply be absolute size of the difference. If a > > > major openoffice.org-core update was only a 25% savings, that would > > > still be about 25MB of data. > > > > > > > Err, yes, this is what I meant. =) > > > > Warren Togami > > wtogami at redhat.com > > > > Is this delta rpm work separate from what Mandrake or Suse (I forget > which) have been using for quite some time now? > > -- > 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 giallu at gmail.com Sun Mar 11 21:41:44 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Sun, 11 Mar 2007 22:41:44 +0100 Subject: Fedora 6 a bit more automated install In-Reply-To: <200703111315.25651.lamont@gurulabs.com> References: <1173629292.3208.16.camel@localhost.localdomain> <200703111315.25651.lamont@gurulabs.com> Message-ID: On 3/11/07, Lamont Peterson wrote: > On Sunday 11 March 2007 12:20pm, Gianluca Sforna wrote: > > On 3/11/07, Baris Cicek wrote: > > > After that point installation start writing to disk. Before that > > > everything is happening without any change on the hdd. > > > > > > It's a good pointer for user that after that moment s/he is starting to > > > change his partitions. AFAIK, after this point anaconda do formatting of > > > the partitions. One last click won't annoy user much, but losing whole > > > partitions might. > > > > It would not annoy the user _IF_ the depsolving step was faster. > > > > I think this is the reason why I saw mails in the past with the same > > request: a fairly long step (depsolving) followed by another long step > > (actual installation) sounds naturally like they should be merged. > > > > IIRC the reason for this is that the depsolving phase could fail > > depending on the package selection and the selected repos; I still > > fail to see whay the last "Next" could not be skipped automatically > > when no such problem arise though... > > In that case, the "After clicking 'Next' your partitions will be altered" > thing will need to be mentioned before depsolving. If depsolve fails, then > bounce back to the package select screen with a (hopefully) useful error > message. > +1 > Of course, if my suggestion of how to implement this change were adopted, then > when depsolving does fail, experienced users/admins might be frustrated that > they walked away thinking there wasn't going to be any more interaction and > it should have installed when they come back and see an error message. Then > again, that's always true. If there is an error in the depsolving phase I don't see any difference from the current situation: you should go back and fix what went wrong. The only difference is when no problems arise from depsolving, that is, no more interactions are needed From robert at fedoraproject.org Sun Mar 11 21:55:08 2007 From: robert at fedoraproject.org (Robert Scheck) Date: Sun, 11 Mar 2007 22:55:08 +0100 Subject: download.fedora.redhat.com gone? In-Reply-To: <16de708d0703111049o1c64becbwb80d7468409ab9e1@mail.gmail.com> References: <45F3F3FC.4000407@timj.co.uk> <20070311140112.GN507@neu.nirvana> <16de708d0703111049o1c64becbwb80d7468409ab9e1@mail.gmail.com> Message-ID: <20070311215508.GA6830@hurricane.linuxnetz.de> Hello, On Sun, 11 Mar 2007, Arthur Pemberton wrote: > Last night http://download.fedora.redhat.com slowed to a stop while I > was trying to find a file for someone. yes, because http://redhat.download.fedoraproject.org/ seems to be the replacement for it. Thanks to Andreas Thienemann for pointing me at IRC to this. > It seems to be working ok now. Maybe somebody re-added the A records to redhat.com in the meantime now again... Greetings, Robert From shams at orcon.net.nz Sun Mar 11 22:10:21 2007 From: shams at orcon.net.nz (Shams) Date: Mon, 12 Mar 2007 11:10:21 +1300 Subject: Fedora 6 a bit more automated install References: <200703111320.10069.lamont@gurulabs.com> Message-ID: Yes I looked into it but want to be able to do it thru the gui: Thanks Shams -- "Lamont Peterson" wrote in message news:200703111320.10069.lamont at gurulabs.com... > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From shams at orcon.net.nz Sun Mar 11 22:16:06 2007 From: shams at orcon.net.nz (Shams) Date: Mon, 12 Mar 2007 11:16:06 +1300 Subject: Fedora 6 a bit more automated install References: <1173629292.3208.16.camel@localhost.localdomain> Message-ID: Hi, Yes it is the depsolve that takes a long time, annoying really. One way I think it could be solved is before depsolve have a checkbox, possibly intergrated into one of the existing screens: "Start installing to disk automatically after solving dependecies after 60 (editable?) seconds? which is checked OFF by default but since I know what I am doing I can check it on and hence in this case when the timeout happens the user does not have to click the "Next" button and install to disk happens automatically BUT is still able to cancel within the timeout period. In the case depsolve fails then the usual error handling happens. Thanks Shams -- "Gianluca Sforna" wrote in message news:d5ad21470703111120s4e8d7d1ew99ad84984e0fcff3 at mail.gmail.com... > On 3/11/07, Baris Cicek wrote: >> After that point installation start writing to disk. Before that >> everything is happening without any change on the hdd. >> >> It's a good pointer for user that after that moment s/he is starting to >> change his partitions. AFAIK, after this point anaconda do formatting of >> the partitions. One last click won't annoy user much, but losing whole >> partitions might. > > It would not annoy the user _IF_ the depsolving step was faster. > > I think this is the reason why I saw mails in the past with the same > request: a fairly long step (depsolving) followed by another long step > (actual installation) sounds naturally like they should be merged. > > IIRC the reason for this is that the depsolving phase could fail > depending on the package selection and the selected repos; I still > fail to see whay the last "Next" could not be skipped automatically > when no such problem arise though... > > -- > 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 Sun Mar 11 22:33:45 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 12 Mar 2007 04:03:45 +0530 Subject: yum 3.1.4 and repository medata handling Message-ID: <45F483C9.5000008@fedoraproject.org> Hi The latest version of yum (3.1.4) in rawhide seems to be behaving rather inconsistently when it comes to dealing with repository metadata. I am cleaning the cache and metadata and rerunning different commands like yum info and yum update to verify. On some instances it downloads the compressed sqlite database directly. In other instances it downloads and parses the compressed xml file. Sometimes it downloads and parses the compressed xml file and then proceeds to download the compressed sqlite database too. It seems to be occurring randomly. Is there any explanation why. I cant see any reason for yum to redundantly download the exact same metadata is the form of both xml file and sqlite database. Downloading the sqlite database has the advantage that the commands are much more faster (since it skips the "reading metadata" part) but the sqlite database (around 2 MB) also seems to be over the double the size of xml files (800 kb). I ran some basic benchmarks with time and Yum 3.1.4 in rawhide is much faster than yum 3.0.3 in FC6 except for the dependency resolving portion. Rahul From skvidal at linux.duke.edu Sun Mar 11 22:40:24 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 11 Mar 2007 18:40:24 -0400 Subject: yum 3.1.4 and repository medata handling In-Reply-To: <45F483C9.5000008@fedoraproject.org> References: <45F483C9.5000008@fedoraproject.org> Message-ID: <1173652824.15934.34.camel@cutter> On Mon, 2007-03-12 at 04:03 +0530, Rahul Sundaram wrote: > Hi > > The latest version of yum (3.1.4) in rawhide seems to be behaving rather > inconsistently when it comes to dealing with repository metadata. I am > cleaning the cache and metadata and rerunning different commands like > yum info and yum update to verify. > > On some instances it downloads the compressed sqlite database directly. > In other instances it downloads and parses the compressed xml file. > Sometimes it downloads and parses the compressed xml file and then > proceeds to download the compressed sqlite database too. It seems to be > occurring randomly. Is there any explanation why. I cant see any reason > for yum to redundantly download the exact same metadata is the form of > both xml file and sqlite database. are you using a mirror list? It'll download what it can find based on what mirror list it has. > > Downloading the sqlite database has the advantage that the commands are > much more faster (since it skips the "reading metadata" part) but the > sqlite database (around 2 MB) also seems to be over the double the size > of xml files (800 kb). not by my measurements. Here is fc6: -rw-rw-r-- 1 skvidal skvidal 2.4M Feb 20 23:32 filelists.sqlite.bz2 -rw-rw-r-- 1 skvidal skvidal 2.4M Feb 20 23:31 filelists.xml.gz -rw-rw-r-- 1 skvidal skvidal 5.8M Feb 20 23:32 other.sqlite.bz2 -rw-rw-r-- 1 skvidal skvidal 6.2M Feb 20 23:31 other.xml.gz -rw-rw-r-- 1 skvidal skvidal 1.1M Feb 20 23:32 primary.sqlite.bz2 -rw-rw-r-- 1 skvidal skvidal 810K Feb 20 23:31 primary.xml.gz here is FE6: -rw-rw-r-- 1 skvidal skvidal 4.9M Feb 26 15:35 filelists.sqlite.bz2 -rw-rw-r-- 1 skvidal skvidal 4.8M Feb 26 15:35 filelists.xml.gz -rw-rw-r-- 1 skvidal skvidal 3.8M Feb 26 15:35 other.sqlite.bz2 -rw-rw-r-- 1 skvidal skvidal 4.0M Feb 26 15:35 other.xml.gz -rw-rw-r-- 1 skvidal skvidal 2.9M Feb 26 15:36 primary.sqlite.bz2 -rw-rw-r-- 1 skvidal skvidal 2.2M Feb 26 15:35 primary.xml.gz here are fedora updates for fc6: -rw-rw-r-- 1 skvidal skvidal 3.0M Feb 26 15:39 filelists.sqlite.bz2 -rw-rw-r-- 1 skvidal skvidal 3.2M Feb 26 15:38 filelists.xml.gz -rw-rw-r-- 1 skvidal skvidal 6.4M Feb 26 15:39 other.sqlite.bz2 -rw-rw-r-- 1 skvidal skvidal 7.1M Feb 26 15:38 other.xml.gz -rw-rw-r-- 1 skvidal skvidal 889K Feb 26 15:39 primary.sqlite.bz2 -rw-rw-r-- 1 skvidal skvidal 653K Feb 26 15:38 primary.xml.gz not 2x at all. > I ran some basic benchmarks with time and Yum > 3.1.4 in rawhide is much faster than yum 3.0.3 in FC6 except for the > dependency resolving portion. There are a fair number of other optimizations outside of not parsing the xml, too. -sv From sundaram at fedoraproject.org Sun Mar 11 22:48:51 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 12 Mar 2007 04:18:51 +0530 Subject: yum 3.1.4 and repository medata handling In-Reply-To: <1173652824.15934.34.camel@cutter> References: <45F483C9.5000008@fedoraproject.org> <1173652824.15934.34.camel@cutter> Message-ID: <45F48753.9030700@fedoraproject.org> seth vidal wrote: > On Mon, 2007-03-12 at 04:03 +0530, Rahul Sundaram wrote: >> Hi >> >> The latest version of yum (3.1.4) in rawhide seems to be behaving rather >> inconsistently when it comes to dealing with repository metadata. I am >> cleaning the cache and metadata and rerunning different commands like >> yum info and yum update to verify. >> >> On some instances it downloads the compressed sqlite database directly. >> In other instances it downloads and parses the compressed xml file. >> Sometimes it downloads and parses the compressed xml file and then >> proceeds to download the compressed sqlite database too. It seems to be >> occurring randomly. Is there any explanation why. I cant see any reason >> for yum to redundantly download the exact same metadata is the form of >> both xml file and sqlite database. > > are you using a mirror list? It'll download what it can find based on > what mirror list it has. Yes. I am using the default configuration from a F7 test 2 live CD installation + the latest updates. I understand getting xml or sqlite based on what is available on the mirror but I dont quite understand why it would download both files. It seems logical to just download the sqlite database if it is available and skip the xml file completely in that instance. > not by my measurements. Guess i misread something then. Rahul From skvidal at linux.duke.edu Sun Mar 11 23:07:15 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 11 Mar 2007 19:07:15 -0400 Subject: yum 3.1.4 and repository medata handling In-Reply-To: <45F48753.9030700@fedoraproject.org> References: <45F483C9.5000008@fedoraproject.org> <1173652824.15934.34.camel@cutter> <45F48753.9030700@fedoraproject.org> Message-ID: <1173654435.15934.36.camel@cutter> On Mon, 2007-03-12 at 04:18 +0530, Rahul Sundaram wrote: > seth vidal wrote: > > On Mon, 2007-03-12 at 04:03 +0530, Rahul Sundaram wrote: > >> Hi > >> > >> The latest version of yum (3.1.4) in rawhide seems to be behaving rather > >> inconsistently when it comes to dealing with repository metadata. I am > >> cleaning the cache and metadata and rerunning different commands like > >> yum info and yum update to verify. > >> > >> On some instances it downloads the compressed sqlite database directly. > >> In other instances it downloads and parses the compressed xml file. > >> Sometimes it downloads and parses the compressed xml file and then > >> proceeds to download the compressed sqlite database too. It seems to be > >> occurring randomly. Is there any explanation why. I cant see any reason > >> for yum to redundantly download the exact same metadata is the form of > >> both xml file and sqlite database. > > > > are you using a mirror list? It'll download what it can find based on > > what mirror list it has. > > Yes. I am using the default configuration from a F7 test 2 live CD > installation + the latest updates. I understand getting xml or sqlite > based on what is available on the mirror but I dont quite understand why > it would download both files. It seems logical to just download the > sqlite database if it is available and skip the xml file completely in > that instance. please collect the output from a case where this is happening. I've not been able to duplicate this claim so I need to see it to find out how to fix it. -sv From sundaram at fedoraproject.org Sun Mar 11 23:13:03 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 12 Mar 2007 04:43:03 +0530 Subject: yum 3.1.4 and repository medata handling In-Reply-To: <1173654435.15934.36.camel@cutter> References: <45F483C9.5000008@fedoraproject.org> <1173652824.15934.34.camel@cutter> <45F48753.9030700@fedoraproject.org> <1173654435.15934.36.camel@cutter> Message-ID: <45F48CFF.7080904@fedoraproject.org> seth vidal wrote: > > please collect the output from a case where this is happening. > I've not been able to duplicate this claim so I need to see it to find > out how to fix it. I am able to reproduce this. Note near end of the output. Do you require more details? # yum update Loading "installonlyn" plugin Setting up Update Process primary.xml.gz 100% |=========================| 815 kB 00:02 http://mirror.hiwaay.net/redhat/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. primary.xml.gz 100% |=========================| 815 kB 00:11 http://ftp.dulug.duke.edu/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. primary.xml.gz 100% |=========================| 815 kB 00:12 http://mirror.linux.duke.edu/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. primary.xml.gz 100% |=========================| 815 kB 00:03 http://mirrors.kernel.org/fedora/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. primary.xml.gz 100% |=========================| 815 kB 00:04 http://ftp-stud.fht-esslingen.de/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. primary.xml.gz 815 kB 00:31 ftp://ftp.funet.fi/pub/mirrors/ftp.redhat.com/pub/fedora/linux/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. primary.xml.gz 100% |=========================| 815 kB 00:03 ftp://alviss.et.tudelft.nl/pub/fedora/core/development/i386/os/repodata/primary.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. primary.xml.gz 100% |=========================| 815 kB 00:04 developmen: ################################################## 2295/2295 primary.sqlite.bz2 100% |=========================| 2.0 MB 00:07 No Packages marked for Update/Obsoletion Rahul From vonbrand at inf.utfsm.cl Sun Mar 11 23:11:05 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 11 Mar 2007 19:11:05 -0400 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <1173517010.6838.71.camel@jndwidescreen.lesbg.loc> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> <1173509705.26934.12.camel@dawkins> <1173517010.6838.71.camel@jndwidescreen.lesbg.loc> Message-ID: <6673.1173654665@laptop13.inf.utfsm.cl> Jonathan Dieter wrote: > On Sat, 2007-03-10 at 07:55 +0100, David Nielsen wrote: > > Do we know how many packages on average that would apply to, it seems to > > me that unless this actually saves us bandwidth in general cases rather > > than just OpenOffice.org (which is big and hideous by nature) then it > > might not be worth it for anything but cool value. > > > > Has this been tried on something like the FC6 updates? Additionally what > > are the impacts client side of doing this, I assume a certain overhead > > in stitching the packages together is present. > > > > Aside that the idea sounds really neat and once it's ready for testing > > I'd love to give it a go. > > > > - David Nielsen > > > I have a local repository with all of Core + some Extras + some Livna + > some FreshRPMS in it. > > If someone had installed everything from my repository when I first > created it, and then had do an update to the latest version of > everything, they would have to download ~1.5 GB of updates. > > If that same person had the yum-deltarpm plugin enabled, they would only > have to download 638 MB. That is *including* all the updates that don't > have drpms because the savings isn't enough. What about people who decide to install OOo and want the latest version later on? -- 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 kwade at redhat.com Sun Mar 11 23:30:08 2007 From: kwade at redhat.com (Karsten Wade) Date: Sun, 11 Mar 2007 15:30:08 -0800 Subject: Fedora 6 and Disk Druid Overall Disk Space In-Reply-To: References: Message-ID: <1173655809.3935.368.camel@erato.phig.org> On Sun, 2007-03-11 at 15:09 +1300, Shams wrote: > Hi, > > Here is the scenario, lets say I have a 60gb hard disk. > > When installing Fedora via gui I noticed that Disk Druid does not give > you the option of specifying the overall disk space to allocate > to Fedora. > > In this case I want to allocate 20gb to Fedora and Disk Druid should > allow me to do that, then I can carry on with installation as usual. > > Can this feature be implemented, please. You can file a report, making the request for enhancement (RFE) against the anaconda component: https://bugzilla.redhat.com/bugzilla/enter_bug.cgi?product=Fedora%20Core ... unless "Requests" is the right tab; sorry, not sure if this is visible to you: https://bugzilla.redhat.com/bugzilla/request.cgi You'll have better luck getting feedback from the developers who work on the software if you make a formal request instead of counting on them reading your email on a busy mailing list. - Karsten -- Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -------------- 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 jkeating at redhat.com Mon Mar 12 00:00:10 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 11 Mar 2007 19:00:10 -0500 Subject: Fedora 6 a bit more automated install In-Reply-To: References: <200703111320.10069.lamont@gurulabs.com> Message-ID: <200703112000.10145.jkeating@redhat.com> On Sunday 11 March 2007 18:10:21 Shams wrote: > Yes I looked into it but want to be able to do it thru the gui: Kickstart != text mode. You can do kickstarts or interactive kickstarts through the GUI. -- 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 Mon Mar 12 00:07:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 11 Mar 2007 19:07:19 -0500 Subject: yum 3.1.4 and repository medata handling In-Reply-To: <45F48CFF.7080904@fedoraproject.org> References: <45F483C9.5000008@fedoraproject.org> <1173654435.15934.36.camel@cutter> <45F48CFF.7080904@fedoraproject.org> Message-ID: <200703112007.19994.jkeating@redhat.com> On Sunday 11 March 2007 19:13:03 Rahul Sundaram wrote: > I am able to reproduce this. ?Note near end of the output. Do you > require more details? Rahul, sqlite metadata is still not used for the Core development repos. We tried turning it on and ran into an issue with creating the sqlite blob across NFS, and unfortunately our internal structure is very NFS based right now. Seth and the createrepo folks were discussing ways of detecting this scenario and making it work for all createrepo users, rather than me doing a one-off hack for our environment. So for now you will see sqlite blobs from Extras and raw .xml.gz files from Core. This is probably what you're considering inconsistency. -- 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 skvidal at linux.duke.edu Mon Mar 12 00:31:27 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Sun, 11 Mar 2007 20:31:27 -0400 Subject: yum 3.1.4 and repository medata handling In-Reply-To: <45F48CFF.7080904@fedoraproject.org> References: <45F483C9.5000008@fedoraproject.org> <1173652824.15934.34.camel@cutter> <45F48753.9030700@fedoraproject.org> <1173654435.15934.36.camel@cutter> <45F48CFF.7080904@fedoraproject.org> Message-ID: <1173659487.15934.40.camel@cutter> On Mon, 2007-03-12 at 04:43 +0530, Rahul Sundaram wrote: > seth vidal wrote: > > > > > please collect the output from a case where this is happening. > > I've not been able to duplicate this claim so I need to see it to find > > out how to fix it. > > I am able to reproduce this. Note near end of the output. Do you > require more details? > yes, turn up the debug level and report the issue in a bug b/c I think what the output is and what is happening are not the same thing. Thanks, -sv -sv From mkearey at redhat.com Mon Mar 12 01:34:16 2007 From: mkearey at redhat.com (Mike Kearey) Date: Mon, 12 Mar 2007 11:34:16 +1000 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <6673.1173654665@laptop13.inf.utfsm.cl> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> <1173509705.26934.12.camel@dawkins> <1173517010.6838.71.camel@jndwidescreen.lesbg.loc> <6673.1173654665@laptop13.inf.utfsm.cl> Message-ID: <45F4AE18.4060300@redhat.com> Horst H. von Brand wrote: >> I have a local repository with all of Core + some Extras + some Livna + >> some FreshRPMS in it. >> >> If someone had installed everything from my repository when I first >> created it, and then had do an update to the latest version of >> everything, they would have to download ~1.5 GB of updates. >> >> If that same person had the yum-deltarpm plugin enabled, they would only >> have to download 638 MB. That is *including* all the updates that don't >> have drpms because the savings isn't enough. > > What about people who decide to install OOo and want the latest version > later on? Do you mean what happens when user installs Fedora, including the version of OOo on ISO some time later in the life cycle of the Fedora release ? This has made me wonder about the drpm system in general.. The fedoraproject page has an explanation: http://fedoraproject.org/wiki/YumDeltaRPM So, if a user updates a package really late in the life cycle of the release, and several deltas have been generated over the period, then there will be some point at which it will be better to pull down the entire new package and not the deltas. I assume that the deltas will be cumulative? ie OOo.0.rpm is in initial release, it is 25MB in size and updates eventually find their way to the mirror: - First update OOo.1.rpm = 25MB plus OOo.0-1.drpm = 3MB - Second update OOo.2.rpm = 25MB plus OOo.1-2.drpm = 10MB - Third update OOo.3.rpm = 25MB plus OOo.2-3.drpm = 10MB - Fourth update OOo.4.rpm plus = 25MB OOo.3-4.drpm = 5MB If someone installs fresh at a time when the mirrors are in such a state, an update for OOo.1.rpm to OOo.4.rpm will clearly be better to pull down the full RPM package ( OOo.4.rpm 25M ) and not the cumulative deltas ( total 28MB ). Am I correct with my assumptions here ? In the above scenario, loyal early adopters that regularly update win big time. Slackers and late adopters don't ;) In general the mirror win big time too as their bandwidth usage is reduced. Cheers, Michael From wtogami at redhat.com Mon Mar 12 01:34:51 2007 From: wtogami at redhat.com (Warren Togami) Date: Sun, 11 Mar 2007 21:34:51 -0400 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <6673.1173654665@laptop13.inf.utfsm.cl> References: <1173387027.3038.6.camel@sb-home.lan> <45F0B193.2000704@redhat.com> <45F12B14.9060409@rasmil.dk> <45F19AE4.3030001@redhat.com> <1173464272.6838.47.camel@jndwidescreen.lesbg.loc> <45F1CF79.5040905@redhat.com> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> <1173509705.26934.12.camel@dawkins> <1173517010.6838.71.camel@jndwidescreen.lesbg.loc> <6673.1173654665@laptop13.inf.utfsm.cl> Message-ID: <45F4AE3B.1000608@redhat.com> Horst H. von Brand wrote: >> If that same person had the yum-deltarpm plugin enabled, they would only >> have to download 638 MB. That is *including* all the updates that don't >> have drpms because the savings isn't enough. > > What about people who decide to install OOo and want the latest version > later on? The existing full RPM on mirrors would not change. yum-deltarpm allows more rapid acquisition a desired RPM, if the specific transition you want is available as a drpm file. The common cases would be provided in drpm. If you are doing something uncommon, then you likely will just download the full RPMS like you would today. Warren Togami wtogami at redhat.com From jcm at redhat.com Mon Mar 12 05:18:00 2007 From: jcm at redhat.com (Jon Masters) Date: Mon, 12 Mar 2007 01:18:00 -0400 Subject: net-tools status? Message-ID: <45F4E288.4000305@redhat.com> Yo, I'm *probably* missing something, but it looks like net-tools hasn't been updated upstream and we have a bazillion patches in the Fedora package at this point - is this about the situation? :-) Asking because I'm wondering if someone should find out the upstream situation. I've been working on some networking hacks for an April Fool's joke and so happened to be trawling this over the weekend. Jon. From buildsys at redhat.com Mon Mar 12 09:51:40 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 12 Mar 2007 05:51:40 -0400 Subject: rawhide report: 20070312 changes Message-ID: <200703120951.l2C9pe6a012282@hs20-bc2-6.build.redhat.com> Updated Packages: nautilus-sendto-0.10-1.fc7 -------------------------- * Sun Mar 11 2007 - Bastien Nocera - 0.10-1 - Update to 0.10, as 0.9 didn't compile * Fri Mar 09 2007 - Bastien Nocera - 0.9-1 - Update to 0.9 - Remove the bluetooth subpackage, it only depends on gbus-glib now scim-1.4.5-10.fc7 ----------------- * Mon Mar 12 2007 Jens Petersen - 1.4.5-10 - make only scim-libs own lib directories used by both scim and scim-libs since scim requires scim-libs (#226395) - update desktop file to remove deprecated X-Fedora and Applications categories with scim-setup-desktop-file.patch (#226395) * Fri Mar 09 2007 Jens Petersen - 1.4.5-9 - add scim-1.4.5-no-rpath-libdir.patch to remove rpaths to libdir - rpmlint cleanup (#226395) * Mon Feb 12 2007 Jens Petersen - 1.4.5-8 - separate gtk immodule out to a separate subpackage - update icons with improvements by Andy Fitzsimon - add functions to xinput script to test for presence of immodules Broken deps for s390 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeaddons - 3.5.6-3.fc7.s390 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.s390 requires libevent-1.2a.so.1 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 ---------------------------------------------------------- frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeaddons - 3.5.6-3.fc7.i386 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.i386 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.i386 requires libevent-1.2a.so.1 Broken deps for x86_64 ---------------------------------------------------------- frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.i386 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.x86_64 requires xdg-utils kdeaddons - 3.5.6-3.fc7.x86_64 requires xdg-utils kdeaddons - 3.5.6-3.fc7.i386 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.x86_64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.i386 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.i386 requires libevent-1.2a.so.1 nfs-utils - 1:1.0.12-1.fc7.x86_64 requires libevent-1.2a.so.1()(64bit) python-pyblock - 0.27-3.i386 requires libdmraid.so.1.0.0.rc14 python-pyblock - 0.27-3.i386 requires libdmraid.so.1.0.0.rc14(Base) Broken deps for s390x ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.s390x requires libofx.so.3()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.s390 requires xdg-utils kdeaccessibility - 1:3.5.6-2.fc7.s390x requires xdg-utils kdeaddons - 3.5.6-3.fc7.s390x requires xdg-utils kdeaddons - 3.5.6-3.fc7.s390 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390x requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.s390 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.s390x requires libevent-1.2a.so.1()(64bit) nfs-utils - 1:1.0.12-1.fc7.s390 requires libevent-1.2a.so.1 python-pyblock - 0.27-3.s390 requires libdmraid.so.1.0.0.rc14(Base) python-pyblock - 0.27-3.s390 requires libdmraid.so.1.0.0.rc14 Broken deps for ppc64 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ppc64 requires xdg-utils kdeaddons - 3.5.6-3.fc7.ppc64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ppc64 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.ppc64 requires libevent-1.2a.so.1()(64bit) Broken deps for ia64 ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libofx.so.3()(64bit) kdeaccessibility - 1:3.5.6-2.fc7.ia64 requires xdg-utils kdeaddons - 3.5.6-3.fc7.ia64 requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ia64 requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.ia64 requires libevent-1.2a.so.1()(64bit) Broken deps for ppc ---------------------------------------------------------- gnucash - 2.0.5-1.fc6.ppc requires libofx.so.3 gnucash - 2.0.5-1.fc6.ppc requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15 kdeaccessibility - 1:3.5.6-2.fc7.ppc requires xdg-utils kdeaddons - 3.5.6-3.fc7.ppc requires xdg-utils kdeadmin - 7:3.5.6-2.fc7.ppc requires xdg-utils nfs-utils - 1:1.0.12-1.fc7.ppc requires libevent-1.2a.so.1 From naoki at valuecommerce.com Mon Mar 12 10:05:21 2007 From: naoki at valuecommerce.com (Naoki) Date: Mon, 12 Mar 2007 19:05:21 +0900 Subject: Merge in effect? In-Reply-To: <1173538896.6787.8.camel@scrappy.miketc.com> References: <1173538896.6787.8.camel@scrappy.miketc.com> Message-ID: <1173693921.12420.6.camel@localhost.localdomain> On Sat, 2007-03-10 at 09:01 -0600, Mike Chambers wrote: > Is indeed the merge now happening as of today? It looks like a lot of > stuff from extras was removed and now rawhide is taking on a lot of > extra (pun/no pun? haha) packages. > > Will everything (provided no problems of course) get merged over today, > guess depending on the build working? I am seeing the same thing. RPMS are "missing". Error Downloading Packages: netpbm-progs - 10.35-11.fc7.x86_64: failure: Fedora/RPMS/netpbm-progs-10.35-11.fc7.x86_64.rpm from development: [Errno 256] No more mirrors to try. texinfo-tex - 4.8-15.x86_64: failure: Fedora/RPMS/texinfo-tex-4.8-15.x86_64.rpm from development: [Errno 256] No more mirrors to try. tetex - 3.0-36.fc7.x86_64: failure: Fedora/RPMS/tetex-3.0-36.fc7.x86_64.rpm from development: [Errno 256] No more mirrors to try. texinfo - 4.8-15.x86_64: failure: Fedora/RPMS/texinfo-4.8-15.x86_64.rpm from development: [Errno 256] No more mirrors to try. dialog - 1.1-1.20070227svn.fc7.x86_64: failure: Fedora/RPMS/dialog-1.1-1.20070227svn.fc7.x86_64.rpm from development: [Errno 256] No more mirrors to try. tetex-fonts - 3.0-36.fc7.x86_64: failure: Fedora/RPMS/tetex-fonts-3.0-36.fc7.x86_64.rpm from development: [Errno 256] No more mirrors to try. groff-perl - 1.18.1.4-2.x86_64: failure: Fedora/RPMS/groff-perl-1.18.1.4-2.x86_64.rpm from development: [Errno 256] No more mirrors to try. tetex-dvips - 3.0-36.fc7.x86_64: failure: Fedora/RPMS/tetex-dvips-3.0-36.fc7.x86_64.rpm from development: [Errno 256] No more mirrors to try. tetex-latex - 3.0-36.fc7.x86_64: failure: Fedora/RPMS/tetex-latex-3.0-36.fc7.x86_64.rpm from development: [Errno 256] No more mirrors to try. From radekvokal at gmail.com Mon Mar 12 11:10:44 2007 From: radekvokal at gmail.com (=?UTF-8?B?UmFkZWsgVm9rw6Fs?=) Date: Mon, 12 Mar 2007 12:10:44 +0100 Subject: net-tools status? In-Reply-To: <45F4E288.4000305@redhat.com> References: <45F4E288.4000305@redhat.com> Message-ID: <45F53534.2000303@gmail.com> Jon Masters wrote: > Yo, > > I'm *probably* missing something, but it looks like net-tools hasn't > been updated upstream and we have a bazillion patches in the Fedora > package at this point - is this about the situation? :-) > I wonder what upstream are you talking about. There was a try to create a new upstream group on berlios to merge all patches in net-tools. Not only Fedora has several patches but net-tools upstream since 1.60 is dead. > Asking because I'm wondering if someone should find out the upstream > situation. I've been working on some networking hacks for an April > Fool's joke and so happened to be trawling this over the weekend. > > Jon. > From aportal at univ-montp2.fr Mon Mar 12 12:19:19 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Mon, 12 Mar 2007 13:19:19 +0100 Subject: net-tools status? In-Reply-To: <45F4E288.4000305@redhat.com> References: <45F4E288.4000305@redhat.com> Message-ID: <200703121319.19471.aportal@univ-montp2.fr> Le Monday 12 March 2007 06:18:00 Jon Masters, vous avez ?crit?: > I'm *probably* missing something, but it looks like net-tools hasn't > been updated upstream and we have a bazillion patches in the Fedora > package at this point - is this about the situation? :-) > > Asking because I'm wondering if someone should find out the upstream > situation. I've been working on some networking hacks for an April > Fool's joke and so happened to be trawling this over the weekend. Project seems to be here. https://developer.berlios.de/projects/net-tools/ But don't seems very active... Alain -- 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 linville at redhat.com Mon Mar 12 13:10:54 2007 From: linville at redhat.com (John W. Linville) Date: Mon, 12 Mar 2007 09:10:54 -0400 Subject: When to expect support for 3945 Wireless in Rawhide In-Reply-To: <45F30DE7.40302@pajato.com> References: <45F2B908.8050309@pajato.com> <20070310135917.GA11811@redhat.com> <45F30DE7.40302@pajato.com> Message-ID: <20070312131054.GA11002@redhat.com> On Sat, Mar 10, 2007 at 02:58:31PM -0500, Paul Michael Reilly wrote: > John W. Linville wrote: > >Shortly after Intel actual posts a patch for inclusion of the iwlwifi > >driver in the wireless-dev kernel tree. > > > >For now, you may wish to try my test kernels: > > > > http://people.redhat.com/linville/kernels/fc7/ > > I'm guessing you are the maintainer who is responsible for this piece of > code in particular. If correct you have my endless appreciation for > what you do. If I'm wrong then I would dearly love to hear from the > maintainer. I'm the primary gatekeeper for what wireless networking changes go into the upstream and/or Fedora kernels. There are other paths, but most of those people would rather I take care of it. :-) > I assume you are in contact with the development mail list for the team > that will supply the patch. From what Dennis Gilmore has to say it > would appear that there is a chance there is some confusion about how > ipw3945 is supposed to get into Fedora 7. It would be very good if the > maintainer could confirm who is waiting on what such that F7 does not > ship without first class ipw3945 support. I have been in contact with them. They feel that their development pace is still too brisk to provide the stability which they feel is implied by being in the upstream kernels. I hope they will have a patch upstream within the next couple of weeks. If not then at some point we might consider getting a snapshot of their driver from their website into Fedora. > I ran your kernel and the chip was detected on my HP nw9440 laptop so I > considered that one hurdle overcome. But I forgot to download the > firmware. Now why is that a separate process? How is this going to Is this an honest inquiry into why some devices have separate firmware files? Or is it a veiled complaint about something which I really cannot control? In case it is the former, reasons include releasing the firmware under a different license than the kernel and being able to change the firmware without having to rebuild the kernel. > work with F7? Surely the firmware will be included in some rpm. > Correct? If so can you supply both that rpm and the kernel rpm and I > will perform a more realistic test. I have no such RPM. The firmware is downloadable from the iwlwifi project site: http://intellinuxwireless.org I believe there is an effort to get freely redistributable firmware packaged and available in the main Fedora repositories. But, that work is being done primarily by someone other than me. You may want to look here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230096 Hth! John -- John W. Linville linville at redhat.com From drago01 at gmail.com Mon Mar 12 13:25:27 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 12 Mar 2007 14:25:27 +0100 Subject: speed of yum depsolver In-Reply-To: <45F483C9.5000008@fedoraproject.org> References: <45F483C9.5000008@fedoraproject.org> Message-ID: <45F554C7.3060302@gmail.com> Rahul Sundaram wrote: > I ran some basic benchmarks with time and Yum 3.1.4 in rawhide is much > faster than yum 3.0.3 in FC6 except for the dependency resolving portion. > yum now uses its own depsolver instead of rpmlib which is slower. I know that its planned to make it working first befor starting to optimize it. my question is: Will this optimzations make it in yum/anaconda before the feature freeze? If not users will complain about update process took to long due to the new depsolver. From email.ahmedkamal at googlemail.com Mon Mar 12 13:31:53 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Mon, 12 Mar 2007 09:31:53 -0400 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <45F4AE3B.1000608@redhat.com> References: <1173387027.3038.6.camel@sb-home.lan> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> <1173509705.26934.12.camel@dawkins> <1173517010.6838.71.camel@jndwidescreen.lesbg.loc> <6673.1173654665@laptop13.inf.utfsm.cl> <45F4AE3B.1000608@redhat.com> Message-ID: <3da3b5b40703120631x6d975663r31af1d5ada7fb611@mail.gmail.com> The idea is NOT to provide incremental updates. i.e. drpms will always upgrade some version to latest. You should never need to install several drpms to reach "latest" state. I am thinking it would be best to provide at least 2 drpms n-1 => n (previous to latest) and General Availability (FC6 isos) => latest If this gets popular, we might provide n-2 => n drpms for slow updaters On 3/11/07, Warren Togami wrote: > > Horst H. von Brand wrote: > >> If that same person had the yum-deltarpm plugin enabled, they would > only > >> have to download 638 MB. That is *including* all the updates that > don't > >> have drpms because the savings isn't enough. > > > > What about people who decide to install OOo and want the latest version > > later on? > > The existing full RPM on mirrors would not change. > > yum-deltarpm allows more rapid acquisition a desired RPM, if the > specific transition you want is available as a drpm file. The common > cases would be provided in drpm. If you are doing something uncommon, > then you likely will just download the full RPMS like you would today. > > Warren Togami > wtogami at redhat.com > > -- > 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 skvidal at linux.duke.edu Mon Mar 12 13:34:44 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Mar 2007 09:34:44 -0400 Subject: speed of yum depsolver In-Reply-To: <45F554C7.3060302@gmail.com> References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> Message-ID: <1173706484.20424.14.camel@cutter> On Mon, 2007-03-12 at 14:25 +0100, dragoran wrote: > Rahul Sundaram wrote: > > I ran some basic benchmarks with time and Yum 3.1.4 in rawhide is much > > faster than yum 3.0.3 in FC6 except for the dependency resolving portion. > > > yum now uses its own depsolver instead of rpmlib which is slower. I know > that its planned to make it working first befor starting to optimize it. > my question is: > Will this optimzations make it in yum/anaconda before the feature freeze? > If not users will complain about update process took to long due to the > new depsolver. yes. -sv From sundaram at fedoraproject.org Mon Mar 12 13:38:25 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 12 Mar 2007 19:08:25 +0530 Subject: yum 3.1.4 and repository medata handling In-Reply-To: <1173659487.15934.40.camel@cutter> References: <45F483C9.5000008@fedoraproject.org> <1173652824.15934.34.camel@cutter> <45F48753.9030700@fedoraproject.org> <1173654435.15934.36.camel@cutter> <45F48CFF.7080904@fedoraproject.org> <1173659487.15934.40.camel@cutter> Message-ID: <45F557D1.3070006@fedoraproject.org> seth vidal wrote: > On Mon, 2007-03-12 at 04:43 +0530, Rahul Sundaram wrote: >> seth vidal wrote: >> >>> please collect the output from a case where this is happening. >>> I've not been able to duplicate this claim so I need to see it to find >>> out how to fix it. >> I am able to reproduce this. Note near end of the output. Do you >> require more details? >> > > yes, turn up the debug level and report the issue in a bug b/c I think > what the output is and what is happening are not the same thing. > > Thanks, > -sv Done. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231833. Thanks Seth. Rahul From bruno at wolff.to Mon Mar 12 14:03:27 2007 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 12 Mar 2007 09:03:27 -0500 Subject: Fedora 6 a bit more automated install In-Reply-To: References: Message-ID: <20070312140327.GB12655@wolff.to> On Mon, Mar 12, 2007 at 11:16:06 +1300, Shams wrote: > > Yes it is the depsolve that takes a long time, annoying really. Has anyone looked into why it runs that slowly? Is it all of the disk seeks, doing the transitive closure or what? Is there enough information cached in comps.xml to compute the transitive closure without having to read all of the rpm files? Is the algorithm used to compute the transitive closure poor? From jdieter at gmail.com Mon Mar 12 13:58:50 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 12 Mar 2007 15:58:50 +0200 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <3da3b5b40703120631x6d975663r31af1d5ada7fb611@mail.gmail.com> References: <1173387027.3038.6.camel@sb-home.lan> <3da3b5b40703091344u2816ea27h88ef46adfbe1166@mail.gmail.com> <45F1DE9D.6050002@redhat.com> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> <1173509705.26934.12.camel@dawkins> <1173517010.6838.71.camel@jndwidescreen.lesbg.loc> <6673.1173654665@laptop13.inf.utfsm.cl> <45F4AE3B.1000608@redhat.com> <3da3b5b40703120631x6d975663r31af1d5ada7fb611@mail.gmail.com> Message-ID: <1173707930.3709.10.camel@jndwidescreen.lesbg.loc> On Mon, 2007-03-12 at 09:31 -0400, Ahmed Kamal wrote: > The idea is NOT to provide incremental updates. i.e. drpms will always > upgrade some version to latest. You should never need to install > several drpms to reach "latest" state. > I am thinking it would be best to provide at least 2 drpms > n-1 => n (previous to latest) > and > General Availability (FC6 isos) => latest > > If this gets popular, we might provide n-2 => n drpms for slow > updaters > There's a neat little utility included with deltarpm called combinedeltarpm that will combine two drpms into one (i.e. abiword-2.0-2.1.drpm + abiword-2.1-2.2.drpm = abiword-2.0-2.2.drpm) which would provide the n-2 drpm quite easily. We really just need to get it up and running first, though. ;) Jonathan -------------- 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 email.ahmedkamal at googlemail.com Mon Mar 12 14:14:41 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Mon, 12 Mar 2007 10:14:41 -0400 Subject: yum-deltarpm (Was Thread Hijack - Our package management GUI tools need improvement) In-Reply-To: <1173707930.3709.10.camel@jndwidescreen.lesbg.loc> References: <1173387027.3038.6.camel@sb-home.lan> <3da3b5b40703091438v61a47b64i848ce9a6f2c8dc4d@mail.gmail.com> <45F2037A.2010603@redhat.com> <1173508891.6838.56.camel@jndwidescreen.lesbg.loc> <1173509705.26934.12.camel@dawkins> <1173517010.6838.71.camel@jndwidescreen.lesbg.loc> <6673.1173654665@laptop13.inf.utfsm.cl> <45F4AE3B.1000608@redhat.com> <3da3b5b40703120631x6d975663r31af1d5ada7fb611@mail.gmail.com> <1173707930.3709.10.camel@jndwidescreen.lesbg.loc> Message-ID: <3da3b5b40703120714i71f4b7cdyf57903c81c21e4a8@mail.gmail.com> yep, at this step, I wanna hammer it down with testing, before we add all sorts of nice utilities around managing the drpms we'll get. Ideally, we should have some server hosting core/extras/updates drpms, and test upgrading from that as much as possible. Whether, automatically, or with the aid of brave individuals. All we have to say is "Hey it can eat your kittens" :) On 3/12/07, Jonathan Dieter wrote: > > On Mon, 2007-03-12 at 09:31 -0400, Ahmed Kamal wrote: > > The idea is NOT to provide incremental updates. i.e. drpms will always > > upgrade some version to latest. You should never need to install > > several drpms to reach "latest" state. > > I am thinking it would be best to provide at least 2 drpms > > n-1 => n (previous to latest) > > and > > General Availability (FC6 isos) => latest > > > > If this gets popular, we might provide n-2 => n drpms for slow > > updaters > > > There's a neat little utility included with deltarpm called > combinedeltarpm that will combine two drpms into one (i.e. > abiword-2.0-2.1.drpm + abiword-2.1-2.2.drpm = abiword-2.0-2.2.drpm) > which would provide the n-2 drpm quite easily. > > We really just need to get it up and running first, though. ;) > > Jonathan > > > -- > 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 jkeating at redhat.com Mon Mar 12 15:01:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Mar 2007 11:01:06 -0400 Subject: Merge in effect? In-Reply-To: <1173693921.12420.6.camel@localhost.localdomain> References: <1173538896.6787.8.camel@scrappy.miketc.com> <1173693921.12420.6.camel@localhost.localdomain> Message-ID: <200703121101.06895.jkeating@redhat.com> On Monday 12 March 2007 06:05:21 Naoki wrote: > I am seeing the same thing. ?RPMS are "missing". yum clear all. The RPMS/ dir was removed, content moved back up a directory to just be under Fedora/. You're cached information doesn't seem to cope with that. -- 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 tjb at unh.edu Mon Mar 12 15:13:58 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Mon, 12 Mar 2007 11:13:58 -0400 Subject: RANDR 1.2 heads up In-Reply-To: <1173477658.14998.0.camel@localhost.localdomain> References: <1173136781.9948.22.camel@localhost.localdomain> <20070308092717.6dd893d2@banea.int.addix.net> <20070308131635.GA18472@redhat.com> <1173470887.5437.7.camel@raptor.sr.unh.edu> <1173477658.14998.0.camel@localhost.localdomain> Message-ID: <1173712438.4963.4.camel@continuity> On Fri, 2007-03-09 at 17:00 -0500, Adam Jackson wrote: > On Fri, 2007-03-09 at 15:08 -0500, Thomas J. Baker wrote: > > On Thu, 2007-03-08 at 14:16 +0100, Tomas Janousek wrote: > > > Hi, > > > > > > On Thu, Mar 08, 2007 at 09:27:17AM +0100, Ralf Ertzinger wrote: > > > > How does one actually do this? Do I have to configure the monitors > > > > in xorg.conf, or are they autodetected? What program do I use to > > > > tell xorg to turn the monitors on and off? > > > > > > Using the xrandr command. For example, a command > > > xrandr --output VGA --mode 1024x768 --pos 0x800 > > > will add the external monitor below my laptop panel. > > > > > > But you may have to configure a separate Monitor section for the external > > > monitor to be able to use modes other than those from the LVDS, which is done > > > by a line in the Device section: > > > Option "Monitor-VGA" "name of the monitor" > > > > > > -- > > > TJ., BaseOS, Brno, CZ > > > > > > > Which version of xrandr do you have installed? Those don't seem to even > > options in the FC7 one I have: > > Yeah, entirely my fault, the package never got off my hard drive. > Should be available tomorrow. > > - ajax > I have a laptop with i945 graphics. Any reason why the screen would be limited like it seems to be: continuity> xrandr Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280 VGA connected (normal left inverted right) 1280x1024 75.0 59.9 1152x864 74.8 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1 LVDS connected 1280x800+0+0 (normal left inverted right) 261mm x 163mm 1280x800 60.0*+ 60.0 1280x768 60.0 1280x720 60.0 1024x768 60.0 800x600 60.3 640x480 59.9 TV disconnected (normal left inverted right) continuity> xrandr --output VGA --mode 1280x1024 --pos 1281x0 xrandr: screen cannot be larger than 1280x1280 (desired size 2561x1024) continuity> xrandr --output VGA --mode 1024x768 --pos 1281x0 xrandr: screen cannot be larger than 1280x1280 (desired size 2305x800) continuity> xrandr --output LDVS --mode 1280x800 --output VGA --mode 1024x768 --pos 1281x0 xrandr: screen cannot be larger than 1280x1280 (desired size 2305x800) continuity> I connect up a Dell 2407 LCD display which doesn't seem to be correctly detected (1920x1200 native resolution) and then my max resolution doesn't seem to allow for much expansion. I thought the driver would borrow system memory as needed (so that this is not a memory problem)? Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From ajackson at redhat.com Mon Mar 12 15:09:34 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 12 Mar 2007 11:09:34 -0400 Subject: RANDR 1.2 heads up In-Reply-To: <1173712438.4963.4.camel@continuity> References: <1173136781.9948.22.camel@localhost.localdomain> <20070308092717.6dd893d2@banea.int.addix.net> <20070308131635.GA18472@redhat.com> <1173470887.5437.7.camel@raptor.sr.unh.edu> <1173477658.14998.0.camel@localhost.localdomain> <1173712438.4963.4.camel@continuity> Message-ID: <1173712174.1242.7.camel@localhost.localdomain> On Mon, 2007-03-12 at 11:13 -0400, Thomas J. Baker wrote: > I have a laptop with i945 graphics. Any reason why the screen would be > limited like it seems to be: > > continuity> xrandr > Screen 0: minimum 320 x 200, current 1280 x 800, maximum 1280 x 1280 > VGA connected (normal left inverted right) > 1280x1024 75.0 59.9 > 1152x864 74.8 > 1024x768 75.1 60.0 > 800x600 75.0 60.3 > 640x480 75.0 60.0 > 720x400 70.1 > LVDS connected 1280x800+0+0 (normal left inverted right) 261mm x 163mm > 1280x800 60.0*+ 60.0 > 1280x768 60.0 > 1280x720 60.0 > 1024x768 60.0 > 800x600 60.3 > 640x480 59.9 > TV disconnected (normal left inverted right) > continuity> xrandr --output VGA --mode 1280x1024 --pos 1281x0 > xrandr: screen cannot be larger than 1280x1280 (desired size 2561x1024) > continuity> xrandr --output VGA --mode 1024x768 --pos 1281x0 > xrandr: screen cannot be larger than 1280x1280 (desired size 2305x800) > continuity> xrandr --output LDVS --mode 1280x800 --output VGA --mode 1024x768 --pos 1281x0 > xrandr: screen cannot be larger than 1280x1280 (desired size 2305x800) > continuity> The display size is limited at server startup, because XAA's memory allocator is spectacularly bad. I don't know if there's a good workaround for this. Try setting a Virtual size in the Screen section of xorg.conf? - ajax From tjanouse at redhat.com Mon Mar 12 15:35:00 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Mon, 12 Mar 2007 16:35:00 +0100 Subject: RANDR 1.2 heads up In-Reply-To: <1173712174.1242.7.camel@localhost.localdomain> References: <1173136781.9948.22.camel@localhost.localdomain> <20070308092717.6dd893d2@banea.int.addix.net> <20070308131635.GA18472@redhat.com> <1173470887.5437.7.camel@raptor.sr.unh.edu> <1173477658.14998.0.camel@localhost.localdomain> <1173712438.4963.4.camel@continuity> <1173712174.1242.7.camel@localhost.localdomain> Message-ID: <20070312153500.GA10302@redhat.com> Hi, On Mon, Mar 12, 2007 at 11:09:34AM -0400, Adam Jackson wrote: > The display size is limited at server startup, because XAA's memory > allocator is spectacularly bad. I don't know if there's a good > workaround for this. Try setting a Virtual size in the Screen section > of xorg.conf? Yeah, you have to use Virtual to specify the maximum size. It may not be possible to specify more than 2048xSomething though, because some chips are limited (at least I read this on some xorg maillist). I just ended up aligning the screens vertically, but it may not be comfortable. Regarding the 1920x1200 resolution, did you specify that Monitor-VGA option in the device section? -- TJ., BaseOS, Brno, CZ From tjanouse at redhat.com Mon Mar 12 16:13:10 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Mon, 12 Mar 2007 17:13:10 +0100 Subject: speed of yum depsolver In-Reply-To: <45F554C7.3060302@gmail.com> References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> Message-ID: <20070312161310.GA27101@redhat.com> Hi, On Mon, Mar 12, 2007 at 02:25:27PM +0100, dragoran wrote: > yum now uses its own depsolver instead of rpmlib which is slower. I know > that its planned to make it working first befor starting to optimize it. Is it possible to turn it off and use the old one? It just cancelled it after it had been running for four hours, hoping I'll be able to use the old one, because this is just ridiculous. I wonder how apt-get does it, it's able to give me the list of updated/installed/whatever packages in less than a minute on a 32MB RAM Celeron 233MHz box and yum needs more than 4 hours on 256MB RAM vmware on dualcore Pentium on 3Ghz? -- TJ., BaseOS, Brno, CZ From skvidal at linux.duke.edu Mon Mar 12 16:19:00 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Mar 2007 12:19:00 -0400 Subject: speed of yum depsolver In-Reply-To: <20070312161310.GA27101@redhat.com> References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> <20070312161310.GA27101@redhat.com> Message-ID: <1173716340.20424.31.camel@cutter> On Mon, 2007-03-12 at 17:13 +0100, Tomas Janousek wrote: > Hi, > > On Mon, Mar 12, 2007 at 02:25:27PM +0100, dragoran wrote: > > yum now uses its own depsolver instead of rpmlib which is slower. I know > > that its planned to make it working first befor starting to optimize it. > > Is it possible to turn it off and use the old one? It just cancelled it after > it had been running for four hours, hoping I'll be able to use the old one, > because this is just ridiculous. I wonder how apt-get does it, it's able to > give me the list of updated/installed/whatever packages in less than a minute > on a 32MB RAM Celeron 233MHz box and yum needs more than 4 hours on 256MB RAM > vmware on dualcore Pentium on 3Ghz? > I'm getting a little annoyed at this conversation. Apparently it is not acceptable for things to be not-working or less-good in rawhide. Apparently, we have to go from one working state to another perfectly working state w/o passing through any situation in which it is not as functional. We told everyone up front that what is going on right now is slower and larger while we work on getting it right and yet that doesn't seem to stop the useless bitching and moaning w/o any offers of help at all. -sv From nicolas.mailhot at laposte.net Mon Mar 12 16:25:40 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 Mar 2007 17:25:40 +0100 (CET) Subject: speed of yum depsolver In-Reply-To: <1173716340.20424.31.camel@cutter> References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> <20070312161310.GA27101@redhat.com> <1173716340.20424.31.camel@cutter> Message-ID: <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> Le Lun 12 mars 2007 17:19, seth vidal a ?crit : > I'm getting a little annoyed at this conversation. > > Apparently it is not acceptable for things to be not-working or > less-good in rawhide. Apparently, we have to go from one working state > to another perfectly working state w/o passing through any situation in > which it is not as functional. Seith, There are enough unintentionnal failures in rawhide without piling up intentionnal ones on them (plus we've passed F7T2 now). And developper/tester respect goes both ways. -- Nicolas Mailhot From mattdm at mattdm.org Mon Mar 12 16:39:21 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 12 Mar 2007 12:39:21 -0400 Subject: speed of yum depsolver [FIX attached] In-Reply-To: <1173716340.20424.31.camel@cutter> References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> <20070312161310.GA27101@redhat.com> <1173716340.20424.31.camel@cutter> Message-ID: <20070312163921.GA30150@jadzia.bu.edu> On Mon, Mar 12, 2007 at 12:19:00PM -0400, seth vidal wrote: > Apparently it is not acceptable for things to be not-working or > less-good in rawhide. Apparently, we have to go from one working state > to another perfectly working state w/o passing through any situation in > which it is not as functional. > We told everyone up front that what is going on right now is slower and > larger while we work on getting it right and yet that doesn't seem to > stop the useless bitching and moaning w/o any offers of help at all. I have a solution! # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU Library General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # # by Matthew Miller ''' expectations-management.py This plugin makes Yum work properly on Rawhide. ''' from yum.plugins import TYPE_INTERACTIVE requires_api_version = '2.4' plugin_type = (TYPE_INTERACTIVE) def init_hook(conduit): f=open('/etc/fedora-release') if f.read().find("Rawhide") > 0: conduit.info(1, '********************************************************') conduit.info(1, 'You are using Fedora Rawhide. Now I will EAT YOUR BRANE.') conduit.info(1, '********************************************************') f.close() -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From limb at jcomserv.net Mon Mar 12 16:40:21 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 12 Mar 2007 11:40:21 -0500 (CDT) Subject: speed of yum depsolver [FIX attached] In-Reply-To: <20070312163921.GA30150@jadzia.bu.edu> References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> <20070312161310.GA27101@redhat.com> <1173716340.20424.31.camel@cutter> <20070312163921.GA30150@jadzia.bu.edu> Message-ID: <64775.65.192.24.190.1173717621.squirrel@mail.jcomserv.net> You owe me a new monitor and keyboard. And a new coffee. :) > On Mon, Mar 12, 2007 at 12:19:00PM -0400, seth vidal wrote: >> Apparently it is not acceptable for things to be not-working or >> less-good in rawhide. Apparently, we have to go from one working state >> to another perfectly working state w/o passing through any situation in >> which it is not as functional. >> We told everyone up front that what is going on right now is slower and >> larger while we work on getting it right and yet that doesn't seem to >> stop the useless bitching and moaning w/o any offers of help at all. > > > I have a solution! > > > # This program is free software; you can redistribute it and/or modify > # it under the terms of the GNU General Public License as published by > # the Free Software Foundation; either version 2 of the License, or > # (at your option) any later version. > # > # This program is distributed in the hope that it will be useful, > # but WITHOUT ANY WARRANTY; without even the implied warranty of > # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > # GNU Library General Public License for more details. > # > # You should have received a copy of the GNU General Public License > # along with this program; if not, write to the Free Software > # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, > USA. > # > # by Matthew Miller > > ''' > expectations-management.py > This plugin makes Yum work properly on Rawhide. > ''' > > from yum.plugins import TYPE_INTERACTIVE > > requires_api_version = '2.4' > plugin_type = (TYPE_INTERACTIVE) > > def init_hook(conduit): > > f=open('/etc/fedora-release') > if f.read().find("Rawhide") > 0: > conduit.info(1, > '********************************************************') > conduit.info(1, 'You are using Fedora Rawhide. Now I will EAT YOUR > BRANE.') > conduit.info(1, > '********************************************************') > f.close() > > > > > > > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From notting at redhat.com Mon Mar 12 16:42:56 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 Mar 2007 12:42:56 -0400 Subject: RPATH status In-Reply-To: <1173528131.6955.1.camel@max.booze> References: <20070309130427.GC23863@localhost> <20070309144340.4528c728@banea.int.addix.net> <45F16BE2.9010806@leemhuis.info> <45F16CBC.2020007@hhs.nl> <20070310032854.GA23633@nostromo.devel.redhat.com> <1173499274.3329.237.camel@localhost.localdomain> <1173528131.6955.1.camel@max.booze> Message-ID: <20070312164256.GA21768@nostromo.devel.redhat.com> Callum Lerwick (seg at haxxed.com) said: > I thought there's already a whitelist. There's (W)arnings and (E)rrors. > Just like a C compiler. You need per-package whitelists; i.e., it's OK for this package to have this directory as 2775, this binary as 4755, etc. Trying to maintain those all in rpmlint itself is doomed to fail. Bill From jkeating at redhat.com Mon Mar 12 17:05:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Mar 2007 13:05:36 -0400 Subject: speed of yum depsolver In-Reply-To: <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> References: <45F483C9.5000008@fedoraproject.org> <1173716340.20424.31.camel@cutter> <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> Message-ID: <200703121305.36545.jkeating@redhat.com> On Monday 12 March 2007 12:25:40 Nicolas Mailhot wrote: > Seith, > > There are enough unintentionnal failures in rawhide without piling up > intentionnal ones on them (plus we've passed F7T2 now). And Test 2 is not the feature freeze for this release. Test 3 is, and there is a Test 4. Using yum to depsolve correctly is a feature, should be done correctly by Test3 for testing. Speeding it up after it is correct can happen after the feature freeze as the feature is in and not changing. > developper/tester respect goes both ways. The yum team has been very vocal about whats going on in yum land, how is this not being respectful to the testing community? -- 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 ihok at hotmail.com Mon Mar 12 17:21:06 2007 From: ihok at hotmail.com (Jack Tanner) Date: Mon, 12 Mar 2007 17:21:06 +0000 (UTC) Subject: flaky usb conn to bluetooth dongle Message-ID: I just got a cheapo Bluetooth dongle, as generic and non-branded as can be. Naturally, it's not always happy; log below. I'm not a USB or Bluetooth expert. What can I do to file a useful bug report? Mar 12 12:39:57 luserpc kernel: usb 3-2: new full speed USB device using uhci_hcd and address 2 Mar 12 12:39:57 luserpc kernel: usb 3-2: device descriptor read/64, error -71 Mar 12 12:39:57 luserpc kernel: usb 3-2: device descriptor read/64, error -71 Mar 12 12:39:57 luserpc kernel: usb 3-2: new full speed USB device using uhci_hcd and address 3 Mar 12 12:39:58 luserpc kernel: usb 3-2: configuration #1 chosen from 1 choice Mar 12 12:39:58 luserpc kernel: Bluetooth: Core ver 2.11 Mar 12 12:39:58 luserpc kernel: NET: Registered protocol family 31 Mar 12 12:39:58 luserpc kernel: Bluetooth: HCI device and connection manager init ialized Mar 12 12:39:58 luserpc kernel: Bluetooth: HCI socket layer initialized Mar 12 12:39:58 luserpc kernel: Bluetooth: HCI USB driver ver 2.9 Mar 12 12:39:58 luserpc kernel: usbcore: registered new interface driver hci_usb Mar 12 12:40:33 luserpc kernel: usb 3-2: USB disconnect, address 3 Mar 12 12:43:25 luserpc kernel: usb 3-1: new full speed USB device using uhci_hcd and address 4 Mar 12 12:43:25 luserpc kernel: usb 3-1: device descriptor read/64, error -71 Mar 12 12:43:26 luserpc kernel: usb 3-1: configuration #1 chosen from 1 choice Mar 12 12:57:35 luserpc kernel: usb 3-1: USB disconnect, address 4 Mar 12 12:58:01 luserpc kernel: usb 1-1: new full speed USB device using uhci_hcd and address 2 Mar 12 12:58:01 luserpc kernel: usb 1-1: device descriptor read/64, error -71 Mar 12 12:58:02 luserpc kernel: usb 1-1: configuration #1 chosen from 1 choice Mar 12 12:58:14 luserpc kernel: usb 1-1: USB disconnect, address 2 From nicolas.mailhot at laposte.net Mon Mar 12 17:27:40 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 Mar 2007 18:27:40 +0100 Subject: speed of yum depsolver In-Reply-To: <200703121305.36545.jkeating@redhat.com> References: <45F483C9.5000008@fedoraproject.org> <1173716340.20424.31.camel@cutter> <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> <200703121305.36545.jkeating@redhat.com> Message-ID: <1173720460.1633.2.camel@rousalka.dyndns.org> Le lundi 12 mars 2007 ? 13:05 -0400, Jesse Keating a ?crit : > On Monday 12 March 2007 12:25:40 Nicolas Mailhot wrote: > > developper/tester respect goes both ways. > > The yum team has been very vocal about whats going on in yum land, how is this > not being respectful to the testing community? Complaining testers expect rawhide to work is not respectful. Testers are doing their testers work, and that includes bugging developers to fix their stuff. Reporting problems is un-fun enough without getting this kind of response. There's one thing worse than grumpy testers it's having to do your testing yourself. -- Nicolas Mailhot From smooge at gmail.com Mon Mar 12 17:35:21 2007 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 12 Mar 2007 11:35:21 -0600 Subject: speed of yum depsolver In-Reply-To: <1173720460.1633.2.camel@rousalka.dyndns.org> References: <45F483C9.5000008@fedoraproject.org> <1173716340.20424.31.camel@cutter> <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> <200703121305.36545.jkeating@redhat.com> <1173720460.1633.2.camel@rousalka.dyndns.org> Message-ID: <80d7e4090703121035k798680bfh9627b364a2705ee2@mail.gmail.com> On 3/12/07, Nicolas Mailhot wrote: > Le lundi 12 mars 2007 ? 13:05 -0400, Jesse Keating a ?crit : > > On Monday 12 March 2007 12:25:40 Nicolas Mailhot wrote: > > > > developper/tester respect goes both ways. > > > > The yum team has been very vocal about whats going on in yum land, how is this > > not being respectful to the testing community? > > Complaining testers expect rawhide to work is not respectful. Testers > are doing their testers work, and that includes bugging developers to > fix their stuff. > > Reporting problems is un-fun enough without getting this kind of > response. There's one thing worse than grumpy testers it's having to do > your testing yourself. > There are multiple ways to report problems.. some work better than others: 1) I noticed a slow down in yum recently? I looked through bugzilla and did not see this, and I didn't find any mention on (xyz-list) that there would be known regressions. Could anyone else confirm they are seeing this.. just in case its my system testing? 2) This is complete Bull. I try to test your $^%# software, and yum just takes forever. Fix your software or I walk. [which while not the exact words, seems to be the tone taken in some of this discussion.] -- 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 drago01 at gmail.com Mon Mar 12 17:43:09 2007 From: drago01 at gmail.com (dragoran) Date: Mon, 12 Mar 2007 18:43:09 +0100 Subject: speed of yum depsolver In-Reply-To: <80d7e4090703121035k798680bfh9627b364a2705ee2@mail.gmail.com> References: <45F483C9.5000008@fedoraproject.org> <1173716340.20424.31.camel@cutter> <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> <200703121305.36545.jkeating@redhat.com> <1173720460.1633.2.camel@rousalka.dyndns.org> <80d7e4090703121035k798680bfh9627b364a2705ee2@mail.gmail.com> Message-ID: <45F5912D.9050006@gmail.com> Stephen John Smoogen wrote: > On 3/12/07, Nicolas Mailhot wrote: >> Le lundi 12 mars 2007 ? 13:05 -0400, Jesse Keating a ?crit : >> > On Monday 12 March 2007 12:25:40 Nicolas Mailhot wrote: >> >> > > developper/tester respect goes both ways. >> > >> > The yum team has been very vocal about whats going on in yum land, >> how is this >> > not being respectful to the testing community? >> >> Complaining testers expect rawhide to work is not respectful. Testers >> are doing their testers work, and that includes bugging developers to >> fix their stuff. >> >> Reporting problems is un-fun enough without getting this kind of >> response. There's one thing worse than grumpy testers it's having to do >> your testing yourself. >> > > There are multiple ways to report problems.. some work better than > others: > > 1) I noticed a slow down in yum recently? I looked through bugzilla > and did not see this, and I didn't find any mention on (xyz-list) that > there would be known regressions. Could anyone else confirm they are > seeing this.. just in case its my system testing? > > 2) This is complete Bull. I try to test your $^%# software, and yum > just takes forever. Fix your software or I walk. [which while not the > exact words, seems to be the tone taken in some of this discussion.] > > I only started this discussion because I wanted to know if the optimization work will be started before the feature freeze. seth answerd with a simple yes. no need for such a discussion at all. From skvidal at linux.duke.edu Mon Mar 12 17:58:19 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Mar 2007 13:58:19 -0400 Subject: speed of yum depsolver In-Reply-To: <45F5912D.9050006@gmail.com> References: <45F483C9.5000008@fedoraproject.org> <1173716340.20424.31.camel@cutter> <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> <200703121305.36545.jkeating@redhat.com> <1173720460.1633.2.camel@rousalka.dyndns.org> <80d7e4090703121035k798680bfh9627b364a2705ee2@mail.gmail.com> <45F5912D.9050006@gmail.com> Message-ID: <1173722299.20424.35.camel@cutter> On Mon, 2007-03-12 at 18:43 +0100, dragoran wrote: > Stephen John Smoogen wrote: > > On 3/12/07, Nicolas Mailhot wrote: > >> Le lundi 12 mars 2007 ? 13:05 -0400, Jesse Keating a ?crit : > >> > On Monday 12 March 2007 12:25:40 Nicolas Mailhot wrote: > >> > >> > > developper/tester respect goes both ways. > >> > > >> > The yum team has been very vocal about whats going on in yum land, > >> how is this > >> > not being respectful to the testing community? > >> > >> Complaining testers expect rawhide to work is not respectful. Testers > >> are doing their testers work, and that includes bugging developers to > >> fix their stuff. > >> > >> Reporting problems is un-fun enough without getting this kind of > >> response. There's one thing worse than grumpy testers it's having to do > >> your testing yourself. > >> > > > > There are multiple ways to report problems.. some work better than > > others: > > > > 1) I noticed a slow down in yum recently? I looked through bugzilla > > and did not see this, and I didn't find any mention on (xyz-list) that > > there would be known regressions. Could anyone else confirm they are > > seeing this.. just in case its my system testing? > > > > 2) This is complete Bull. I try to test your $^%# software, and yum > > just takes forever. Fix your software or I walk. [which while not the > > exact words, seems to be the tone taken in some of this discussion.] > > > > > I only started this discussion because I wanted to know if the > optimization work will be started before the feature freeze. seth > answerd with a simple yes. > no need for such a discussion at all. Dragoran, Yes, your question was apropos and while my answer was terse it was not intended as rude. This last week my life has been spent dealing with checking systems for DST-compliance and looking for a new place to live. :) So, I've not had much time to spend on yum depsolver work. We WILL have it functional before the release or we WILL fallback. There isn't an option, imo. -sv From jacliburn at bellsouth.net Mon Mar 12 17:53:39 2007 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Mon, 12 Mar 2007 12:53:39 -0500 Subject: speed of yum depsolver In-Reply-To: <1173716340.20424.31.camel@cutter> References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> <20070312161310.GA27101@redhat.com> <1173716340.20424.31.camel@cutter> Message-ID: <45F593A3.20904@bellsouth.net> seth vidal wrote: > On Mon, 2007-03-12 at 17:13 +0100, Tomas Janousek wrote: >> Hi, >> >> On Mon, Mar 12, 2007 at 02:25:27PM +0100, dragoran wrote: >>> yum now uses its own depsolver instead of rpmlib which is slower. I know >>> that its planned to make it working first befor starting to optimize it. >> Is it possible to turn it off and use the old one? It just cancelled it after >> it had been running for four hours, hoping I'll be able to use the old one, >> because this is just ridiculous. I wonder how apt-get does it, it's able to >> give me the list of updated/installed/whatever packages in less than a minute >> on a 32MB RAM Celeron 233MHz box and yum needs more than 4 hours on 256MB RAM >> vmware on dualcore Pentium on 3Ghz? >> > > I'm getting a little annoyed at this conversation. > > Apparently it is not acceptable for things to be not-working or > less-good in rawhide. Apparently, we have to go from one working state > to another perfectly working state w/o passing through any situation in > which it is not as functional. > > We told everyone up front that what is going on right now is slower and > larger while we work on getting it right and yet that doesn't seem to > stop the useless bitching and moaning w/o any offers of help at all. IMHO, this discussion brings into sharp relief just how good Rawhide really is. It's so good that I've become accustomed to near release quality software at any and all points in the Rawhide life cycle. Occasionally something breaks -- spectacularly, even -- but it often gets fixed within a few days. This yum-in-transition performance issue is just another bump in an otherwise pretty darned smooth road, all things considered, and I'd argue that if Rawhide were more unstable, the instant yum issue wouldn't seem nearly so contemptible. I like running the latest stuff. I like Rawhide. I like Fedora. You guys are doing a great job. An alternate voice from a satisfied Rawhide user/tester, Jay From tjanouse at redhat.com Mon Mar 12 18:39:22 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Mon, 12 Mar 2007 19:39:22 +0100 Subject: speed of yum depsolver In-Reply-To: <1173720460.1633.2.camel@rousalka.dyndns.org> References: <45F483C9.5000008@fedoraproject.org> <1173716340.20424.31.camel@cutter> <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> <200703121305.36545.jkeating@redhat.com> <1173720460.1633.2.camel@rousalka.dyndns.org> Message-ID: <20070312183922.GA5518@redhat.com> Hi, On Mon, Mar 12, 2007 at 06:27:40PM +0100, Nicolas Mailhot wrote: > Complaining testers expect rawhide to work is not respectful. Testers > are doing their testers work, and that includes bugging developers to > fix their stuff. And I'm not a tester at all. But well, if yum creators say that things can wait, it must be true -- they are the ultimate masters of waiting, aren't they? Hell, I just wanted a simple workaround to get my box updated once :/ -- TJ., BaseOS, Brno, CZ From jkeating at redhat.com Mon Mar 12 18:47:57 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Mar 2007 14:47:57 -0400 Subject: speed of yum depsolver In-Reply-To: <20070312183922.GA5518@redhat.com> References: <45F483C9.5000008@fedoraproject.org> <1173720460.1633.2.camel@rousalka.dyndns.org> <20070312183922.GA5518@redhat.com> Message-ID: <200703121447.58427.jkeating@redhat.com> On Monday 12 March 2007 14:39:22 Tomas Janousek wrote: > And I'm not a tester at all. Then why are you using rawhide, other than to have a reason to complain? > Hell, I just wanted a simple workaround to get my box updated once :/ You probably shouldn't be using rawhide then. -- 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 nicolas.mailhot at laposte.net Mon Mar 12 18:47:11 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 12 Mar 2007 19:47:11 +0100 Subject: speed of yum depsolver In-Reply-To: <1173722299.20424.35.camel@cutter> References: <45F483C9.5000008@fedoraproject.org> <1173716340.20424.31.camel@cutter> <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> <200703121305.36545.jkeating@redhat.com> <1173720460.1633.2.camel@rousalka.dyndns.org> <80d7e4090703121035k798680bfh9627b364a2705ee2@mail.gmail.com> <45F5912D.9050006@gmail.com> <1173722299.20424.35.camel@cutter> Message-ID: <1173725231.2488.1.camel@rousalka.dyndns.org> Le lundi 12 mars 2007 ? 13:58 -0400, seth vidal a ?crit : > Yes, your question was apropos and while my answer was terse it was not > intended as rude. This last week my life has been spent dealing with > checking systems for DST-compliance and looking for a new place to > live. :) So, I've not had much time to spend on yum depsolver work. We > WILL have it functional before the release or we WILL fallback. There > isn't an option, imo. We all need to emulate mharris joking about evil overlordship the days xfree86 crashed in rawhide and everyone was complaining -- Nicolas Mailhot From skvidal at linux.duke.edu Mon Mar 12 18:49:43 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Mar 2007 14:49:43 -0400 Subject: speed of yum depsolver In-Reply-To: <20070312183922.GA5518@redhat.com> References: <45F483C9.5000008@fedoraproject.org> <1173716340.20424.31.camel@cutter> <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> <200703121305.36545.jkeating@redhat.com> <1173720460.1633.2.camel@rousalka.dyndns.org> <20070312183922.GA5518@redhat.com> Message-ID: <1173725383.20424.38.camel@cutter> On Mon, 2007-03-12 at 19:39 +0100, Tomas Janousek wrote: > Hi, > > On Mon, Mar 12, 2007 at 06:27:40PM +0100, Nicolas Mailhot wrote: > > Complaining testers expect rawhide to work is not respectful. Testers > > are doing their testers work, and that includes bugging developers to > > fix their stuff. > > And I'm not a tester at all. But well, if yum creators say that things can > wait, it must be true -- they are the ultimate masters of waiting, aren't > they? > > Hell, I just wanted a simple workaround to get my box updated once :/ > then an easy one for what you want is: 1. downgrade to yum 3.0.3 from fc6 2. put an exclude in for yum in your yum.conf presto -sv From zaitcev at redhat.com Mon Mar 12 18:55:30 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Mon, 12 Mar 2007 11:55:30 -0700 Subject: flaky usb conn to bluetooth dongle In-Reply-To: References: Message-ID: <20070312115530.29ae02ef.zaitcev@redhat.com> On Mon, 12 Mar 2007 17:21:06 +0000 (UTC), Jack Tanner wrote: > I just got a cheapo Bluetooth dongle, as generic and non-branded as can be. > Naturally, it's not always happy; log below. > > I'm not a USB or Bluetooth expert. What can I do to file a useful bug report? Any evidence that a bug is involved would be good. So far I don't see any. > Mar 12 12:39:57 luserpc kernel: usb 3-2: device descriptor read/64, error -71 Yep, that's a duff device all right. We may be able to accomodate it somehow if someone figures out what it wants. But we'll need you to do all of it: run Snoopy on Windows, formulate a patch. -- Pete From tjanouse at redhat.com Mon Mar 12 19:02:19 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Mon, 12 Mar 2007 20:02:19 +0100 Subject: speed of yum depsolver In-Reply-To: <200703121447.58427.jkeating@redhat.com> References: <45F483C9.5000008@fedoraproject.org> <1173720460.1633.2.camel@rousalka.dyndns.org> <20070312183922.GA5518@redhat.com> <200703121447.58427.jkeating@redhat.com> Message-ID: <20070312190219.GA6628@redhat.com> Hi, On Mon, Mar 12, 2007 at 02:47:57PM -0400, Jesse Keating wrote: > Then why are you using rawhide, other than to have a reason to complain? Almost exclusively for local test builds. It seems more comfortable than mock, when it works. Believe me or not, I do not use it to have a reason to complain. I just asked for a workaround and didn't want any flame. Seems I shouldn't have sent that comparison between yum and apt-get. -- TJ., BaseOS, Brno, CZ From tjanouse at redhat.com Mon Mar 12 19:05:15 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Mon, 12 Mar 2007 20:05:15 +0100 Subject: speed of yum depsolver In-Reply-To: <1173725383.20424.38.camel@cutter> References: <45F483C9.5000008@fedoraproject.org> <1173716340.20424.31.camel@cutter> <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> <200703121305.36545.jkeating@redhat.com> <1173720460.1633.2.camel@rousalka.dyndns.org> <20070312183922.GA5518@redhat.com> <1173725383.20424.38.camel@cutter> Message-ID: <20070312190515.GB6628@redhat.com> Hi, On Mon, Mar 12, 2007 at 02:49:43PM -0400, seth vidal wrote: > then an easy one for what you want is: > > 1. downgrade to yum 3.0.3 from fc6 > 2. put an exclude in for yum in your yum.conf Thank you very much, this is almost exactly what I expected as an answer. I had expected an option that would switch to the old depsolver without the downgrade, but if there is no, no problem. I feel sorry for the flame. -- TJ., BaseOS, Brno, CZ From lmacken at redhat.com Mon Mar 12 19:07:13 2007 From: lmacken at redhat.com (Luke Macken) Date: Mon, 12 Mar 2007 15:07:13 -0400 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files In-Reply-To: References: Message-ID: <20070312190713.GI2527@tomservo.rh.rit.edu> On Sun, Mar 11, 2007 at 06:05:46PM +0100, Aurelien Bompard wrote: > Dear Fedoreans, > > Having followed the debate over whether to flag init scripts as %config > files, I thought that there's a feature of another package manager that I > liked: when a config file has changed, it asks you if you want to keep your > local copy or if you want to install the package's version. > RPM is non-interactive, so it's not supposed to do this. But I thought this > could be implemented in a yum plugin. > > I've written a plugin which does just this: > http://gauret.free.fr/fichiers/rpms/fedora/yum-merge-conf/merge-conf.py > http://gauret.free.fr/fichiers/rpms/fedora/yum-merge-conf/yum-merge-conf-1.0-1.noarch.rpm > > Add the --merge-conf command line option to your yum update, and it will ask > you what to do with those .rpm{save,new} files as the packages are > installed. You'll be able to diff the files, choose your version, or spawn > a shell to check further. > > If you think you could be interested in this feature, please have a look. If > you think it's a useful plugin and it's decently written (it's my first yum > plugin), I'll submit it to the yum list. Nice work, Aur?lien. I had been toying around with the idea of throwing together something similar. I haven't had time to look into it further, but With this plugin enabled, `yum update` ends with a 'Package Header Not Available' message: Running Transaction Updating : python-sqlalchemy ######################### [1/2] Cleanup : python-sqlalchemy ######################### [2/2] Package Header Not Available luke From gauret at free.fr Mon Mar 12 19:26:56 2007 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 12 Mar 2007 20:26:56 +0100 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files References: <20070312190713.GI2527@tomservo.rh.rit.edu> Message-ID: Luke Macken wrote: > Nice work, Aur?lien. I had been toying around with the idea of throwing > together something similar. Thanks :) Hope some people will find it useful > I haven't had time to look into it further, but With this plugin enabled, > `yum update` ends with a 'Package Header Not Available' message It this RawHide ? I did not try it on a rawhide system, I hear yum can do without the rpm headers there ? That would explain the error. I have a RawHide machine at work, I'll have a look tomorrow. Thanks for your feedback ! Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr There are only 10 types of people in the world : those who understand binary and those who don't. From skvidal at linux.duke.edu Mon Mar 12 19:31:14 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Mar 2007 15:31:14 -0400 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files In-Reply-To: References: <20070312190713.GI2527@tomservo.rh.rit.edu> Message-ID: <1173727874.20424.40.camel@cutter> On Mon, 2007-03-12 at 20:26 +0100, Aurelien Bompard wrote: > Luke Macken wrote: > > Nice work, Aur?lien. I had been toying around with the idea of throwing > > together something similar. > > Thanks :) Hope some people will find it useful > > > I haven't had time to look into it further, but With this plugin enabled, > > `yum update` ends with a 'Package Header Not Available' message > > It this RawHide ? I did not try it on a rawhide system, I hear yum can do > without the rpm headers there ? That would explain the error. > > I have a RawHide machine at work, I'll have a look tomorrow. > > Thanks for your feedback ! > yum 3.1.4 will run just fine on fc6. -sv From ihok at hotmail.com Mon Mar 12 19:31:48 2007 From: ihok at hotmail.com (Jack Tanner) Date: Mon, 12 Mar 2007 15:31:48 -0400 Subject: flaky usb conn to bluetooth dongle In-Reply-To: <20070312115530.29ae02ef.zaitcev@redhat.com> References: <20070312115530.29ae02ef.zaitcev@redhat.com> Message-ID: Pete Zaitcev wrote: > On Mon, 12 Mar 2007 17:21:06 +0000 (UTC), Jack Tanner wrote: > >> I just got a cheapo Bluetooth dongle, as generic and non-branded as can be. >> Naturally, it's not always happy; log below. >> >> I'm not a USB or Bluetooth expert. What can I do to file a useful bug report? > > Any evidence that a bug is involved would be good. So far I don't > see any. Is it evidence enough that sometimes it works and sometimes it doesn't (on the same FC6 box, with no reboots in between), and that it always works on two other Windows boxes? I don't dispute that the device may be crappy and that Windows may be working around its bugs. Still, the user experience seems less than ideal. >> Mar 12 12:39:57 luserpc kernel: usb 3-2: device descriptor read/64, error -71 > > Yep, that's a duff device all right. > > We may be able to accomodate it somehow if someone figures out > what it wants. But we'll need you to do all of it: run Snoopy on > Windows, formulate a patch. Er, running a logger on Windows I can do. I snooped on the web, and there are lots of Snoopies. Is this the right one? http://benoit.papillault.free.fr/usbsnoop/ The formulate the patch part is going to be difficult. I don't suppose I could get away with just sending you some log files? :) From mschwendt.tmp0701.nospam at arcor.de Mon Mar 12 14:49:43 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 12 Mar 2007 15:49:43 +0100 Subject: yum 3.1.4 and repository medata handling In-Reply-To: <45F557D1.3070006@fedoraproject.org> References: <45F483C9.5000008@fedoraproject.org> <1173652824.15934.34.camel@cutter> <45F48753.9030700@fedoraproject.org> <1173654435.15934.36.camel@cutter> <45F48CFF.7080904@fedoraproject.org> <1173659487.15934.40.camel@cutter> <45F557D1.3070006@fedoraproject.org> Message-ID: <20070312154943.c65e85d7.mschwendt.tmp0701.nospam@arcor.de> On Mon, 12 Mar 2007 19:08:25 +0530, Rahul Sundaram wrote: > seth vidal wrote: > > On Mon, 2007-03-12 at 04:43 +0530, Rahul Sundaram wrote: > >> seth vidal wrote: > >> > >>> please collect the output from a case where this is happening. > >>> I've not been able to duplicate this claim so I need to see it to find > >>> out how to fix it. > >> I am able to reproduce this. Note near end of the output. Do you > >> require more details? > >> > > > > yes, turn up the debug level and report the issue in a bug b/c I think > > what the output is and what is happening are not the same thing. > > > > Thanks, > > -sv > > Done. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231833. > Thanks Seth. In that report, yum downloads primary.xml.gz for Rawhide and primary.sqlite.bz2 for Extras Development. From michel.salim at gmail.com Mon Mar 12 19:39:34 2007 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 12 Mar 2007 15:39:34 -0400 Subject: Yum repository indices broken by reorganization Message-ID: <883cfe6d0703121239w7f1a782fxe8d4cbe76cfc7028@mail.gmail.com> I've been unable to successfully update my system since yesterday; a cursory check shows that files on the mirrors have been moved from Fedora/RPMS/ to Fedora/ . Presumably this will be fixed with the next update of Rawhide? -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From jkeating at redhat.com Mon Mar 12 19:52:21 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Mar 2007 15:52:21 -0400 Subject: Yum repository indices broken by reorganization In-Reply-To: <883cfe6d0703121239w7f1a782fxe8d4cbe76cfc7028@mail.gmail.com> References: <883cfe6d0703121239w7f1a782fxe8d4cbe76cfc7028@mail.gmail.com> Message-ID: <200703121552.21573.jkeating@redhat.com> On Monday 12 March 2007 15:39:34 Michel Salim wrote: > I've been unable to successfully update my system since yesterday; a > cursory check shows that files on the mirrors have been moved from > Fedora/RPMS/ to Fedora/ . > > Presumably this will be fixed with the next update of Rawhide? yum clean all; try again. -- 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 tmus at tmus.dk Mon Mar 12 19:59:23 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 12 Mar 2007 20:59:23 +0100 Subject: speed of yum depsolver In-Reply-To: <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> <20070312161310.GA27101@redhat.com> <1173716340.20424.31.camel@cutter> <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > Le Lun 12 mars 2007 17:19, seth vidal a ?crit : > >> I'm getting a little annoyed at this conversation. >> >> Apparently it is not acceptable for things to be not-working or >> less-good in rawhide. Apparently, we have to go from one working state >> to another perfectly working state w/o passing through any situation in >> which it is not as functional. > > Seith, > > There are enough unintentionnal failures in rawhide without piling up > intentionnal ones on them (plus we've passed F7T2 now). And > developper/tester respect goes both ways. > This is a *development* forum and we're talking about the *development* version of yum... For software to get better, sometimes new features have to be implemented, making it worse for a while, that the way it goes. And this is exactly why the development goes on in a separate tree. Nothing fishy about that at all. Just my two cents. /Thomas From zaitcev at redhat.com Mon Mar 12 21:11:22 2007 From: zaitcev at redhat.com (Pete Zaitcev) Date: Mon, 12 Mar 2007 14:11:22 -0700 Subject: flaky usb conn to bluetooth dongle In-Reply-To: References: <20070312115530.29ae02ef.zaitcev@redhat.com> Message-ID: <20070312141122.8354afda.zaitcev@redhat.com> On Mon, 12 Mar 2007 15:31:48 -0400, Jack Tanner wrote: > Is it evidence enough that sometimes it works and sometimes it doesn't > (on the same FC6 box, with no reboots in between), and that it always > works on two other Windows boxes? Close, but not there yet. It would be nice if you tried it on other systems with Linux, because -71 is a pretty good indicator of something broken physically. It means that low level bus tokens get lost, or a frame corruption is detected by CRCs. But sometimes devices cause it by becoming temporarily deaf if they process some command or other. The workaround is to identify the conditions under which it happens and find a way to avoid poking the device for a few milliseconds. Again, that is only if we rule out poor signal quality on your motherboard. > Er, running a logger on Windows I can do. I snooped on the web, and > there are lots of Snoopies. Is this the right one? > http://benoit.papillault.free.fr/usbsnoop/ I don't remember the exact URL, but probably. I usually start with that Swiss page at linux-usb.org and follow links. Most people use something called Snoopy Pro. There's a free as in beer verision. > The formulate the patch part is going to be difficult. I don't suppose I > could get away with just sending you some log files? :) The problem is, it's time-consuming, which is why I tried to off-load all the work on you. If I take on it, it's going to take like forever. I think you better take it to linux-usb-devel at lists.sourceforge.net at this time. -- Pete From skvidal at linux.duke.edu Mon Mar 12 21:21:21 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 12 Mar 2007 17:21:21 -0400 Subject: perl, perl-devel, and missing config.h In-Reply-To: References: Message-ID: <1173734481.20424.47.camel@cutter> On Fri, 2007-03-09 at 14:44 -0500, Robin Norwood wrote: > Robin Norwood writes: > > [...] > > > Spot, Jesse Keating, and I have discussed the issue via email and on > > fedora-perl-devel-list[3] - the three of us think this solution is the > > right way to go, but several people on the list disagree. So we're > > going to hash things out there and decide what to do. If you want to > > follow the discussion, see fedora-perl-devel-list. Otherwise, stay > > tuned, and we'll keep you posted. > > An update: it looks like we'll be able to go with the perl-devel split. > I've just built perl-5.8.8-15, which continues the work to split > perl/perl-devel. Right now 'perl' requires 'perl-devel', but we hope to > fix that soon. > I added a patch to the bug you opened. Anyone who can check it, please do so. I think it's the right path toward being fixed. thanks, -sv From mschwendt.tmp0701.nospam at arcor.de Mon Mar 12 21:26:10 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 12 Mar 2007 22:26:10 +0100 Subject: Yum repository indices broken by reorganization In-Reply-To: <200703121552.21573.jkeating@redhat.com> References: <883cfe6d0703121239w7f1a782fxe8d4cbe76cfc7028@mail.gmail.com> <200703121552.21573.jkeating@redhat.com> Message-ID: <20070312222610.d0143a8b.mschwendt.tmp0701.nospam@arcor.de> On Mon, 12 Mar 2007 15:52:21 -0400, Jesse Keating wrote: > On Monday 12 March 2007 15:39:34 Michel Salim wrote: > > I've been unable to successfully update my system since yesterday; a > > cursory check shows that files on the mirrors have been moved from > > Fedora/RPMS/ to Fedora/ . > > > > Presumably this will be fixed with the next update of Rawhide? > > yum clean all; try again. Doubtful, because "all" includes "packages". At least on FC-6. And you don't want to kill the cached packages, but just headers and metadata, so cleaning "headers", "metadata" and "dbcache" looks promising. But with updated repository metadata this should not be necessary at all. What is wrong? From michel.salim at gmail.com Mon Mar 12 21:09:20 2007 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 12 Mar 2007 17:09:20 -0400 Subject: Yum repository indices broken by reorganization In-Reply-To: <200703121552.21573.jkeating@redhat.com> References: <883cfe6d0703121239w7f1a782fxe8d4cbe76cfc7028@mail.gmail.com> <200703121552.21573.jkeating@redhat.com> Message-ID: <883cfe6d0703121409w26988313pca5ae399da803ad3@mail.gmail.com> 2007/3/12, Jesse Keating : > On Monday 12 March 2007 15:39:34 Michel Salim wrote: > > I've been unable to successfully update my system since yesterday; a > > cursory check shows that files on the mirrors have been moved from > > Fedora/RPMS/ to Fedora/ . > > > > Presumably this will be fixed with the next update of Rawhide? > > yum clean all; try again. > Ah yes, that works. Any reason why this is necessary? -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From jkeating at redhat.com Mon Mar 12 21:43:07 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 12 Mar 2007 17:43:07 -0400 Subject: Yum repository indices broken by reorganization In-Reply-To: <883cfe6d0703121409w26988313pca5ae399da803ad3@mail.gmail.com> References: <883cfe6d0703121239w7f1a782fxe8d4cbe76cfc7028@mail.gmail.com> <200703121552.21573.jkeating@redhat.com> <883cfe6d0703121409w26988313pca5ae399da803ad3@mail.gmail.com> Message-ID: <200703121743.08293.jkeating@redhat.com> On Monday 12 March 2007 17:09:20 Michel Salim wrote: > Ah yes, that works. Any reason why this is necessary? Content moved from Fedora/RPMS/ to just Fedora/ and the cached information didn't cope with that. Seth, what might we be able to do in the future with things like this? Not that I expect to move content again, but ya never know... -- 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 sundaram at fedoraproject.org Mon Mar 12 22:02:53 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 13 Mar 2007 03:32:53 +0530 Subject: yum 3.1.4 and repository medata handling In-Reply-To: <200703112007.19994.jkeating@redhat.com> References: <45F483C9.5000008@fedoraproject.org> <1173654435.15934.36.camel@cutter> <45F48CFF.7080904@fedoraproject.org> <200703112007.19994.jkeating@redhat.com> Message-ID: <45F5CE0D.2070306@fedoraproject.org> Jesse Keating wrote: > On Sunday 11 March 2007 19:13:03 Rahul Sundaram wrote: >> I am able to reproduce this. Note near end of the output. Do you >> require more details? > > Rahul, sqlite metadata is still not used for the Core development repos. We > tried turning it on and ran into an issue with creating the sqlite blob > across NFS, and unfortunately our internal structure is very NFS based right > now. Seth and the createrepo folks were discussing ways of detecting this > scenario and making it work for all createrepo users, rather than me doing a > one-off hack for our environment. > > So for now you will see sqlite blobs from Extras and raw .xml.gz files from > Core. This is probably what you're considering inconsistency. Yes. That explains it. Thanks. Rahul From ndbecker2 at gmail.com Tue Mar 13 00:13:53 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 12 Mar 2007 20:13:53 -0400 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files References: Message-ID: Aurelien Bompard wrote: > Dear Fedoreans, > > Having followed the debate over whether to flag init scripts as %config > files, I thought that there's a feature of another package manager that I > liked: when a config file has changed, it asks you if you want to keep > your local copy or if you want to install the package's version. > RPM is non-interactive, so it's not supposed to do this. But I thought > this could be implemented in a yum plugin. > > I've written a plugin which does just this: > http://gauret.free.fr/fichiers/rpms/fedora/yum-merge-conf/merge-conf.py > http://gauret.free.fr/fichiers/rpms/fedora/yum-merge-conf/yum-merge-conf-1.0-1.noarch.rpm > > Add the --merge-conf command line option to your yum update, and it will > ask you what to do with those .rpm{save,new} files as the packages are > installed. You'll be able to diff the files, choose your version, or spawn > a shell to check further. > > If you think you could be interested in this feature, please have a look. > If you think it's a useful plugin and it's decently written (it's my first > yum plugin), I'll submit it to the yum list. > This sounds great! I haven't looked at the code yet. Will it also ignore cases when the new config hasn't actually changed, and silently remove the redundant copy? That would be really great. From lmacken at redhat.com Tue Mar 13 01:18:23 2007 From: lmacken at redhat.com (Luke Macken) Date: Mon, 12 Mar 2007 21:18:23 -0400 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files In-Reply-To: References: <20070312190713.GI2527@tomservo.rh.rit.edu> Message-ID: <20070313011822.GL2527@tomservo.rh.rit.edu> On Mon, Mar 12, 2007 at 08:26:56PM +0100, Aurelien Bompard wrote: > Luke Macken wrote: > > Nice work, Aur?lien. I had been toying around with the idea of throwing > > together something similar. > > Thanks :) Hope some people will find it useful > > > I haven't had time to look into it further, but With this plugin enabled, > > `yum update` ends with a 'Package Header Not Available' message > > It this RawHide ? I did not try it on a rawhide system, I hear yum can do > without the rpm headers there ? That would explain the error. > > I have a RawHide machine at work, I'll have a look tomorrow. > > Thanks for your feedback ! Nope, this is FC6 running yum-3.0.4-1.fc6 luke From lmth at deakin.edu.au Tue Mar 13 03:43:08 2007 From: lmth at deakin.edu.au (lmth at deakin.edu.au) Date: Tue, 13 Mar 2007 14:43:08 +1100 Subject: A request for your input. Message-ID: <20070313144308.3a814k68nmww4ggg@mail.deakin.edu.au> Hello My name is Lara Thynne and I am a PhD candidate at Deakin University Australia. I am currently researching the boundary between work and leisure activities directly related to the open source community and open source program development. As part of this I am running a survey at the following address. https://dcarf.deakin.edu.au/surveys/oss/ The survey is completely confidential and looks at your views and motivations to use Open Source software and to participate in the community. It will only take a five to ten minutes to complete and your contact details will not be recorded. You can withdraw your participation at any stage. I sincerely apologize for the spammish nature of this e-mail - I don't mean to abuse this list. I am trying to collect responses from as many open source developers and users as possible and a mailing list like can be the only way to reach many developers. Thanks again Lara P.S The program that I am using is open source, of course (www.phpsurveyor.org)! From abartlet at samba.org Tue Mar 13 04:17:09 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 13 Mar 2007 15:17:09 +1100 Subject: [Fedora-directory-devel] Re: RPATH status In-Reply-To: <45F547FA.4050602@redhat.com> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <1173572083.3506.111.camel@localhost.localdomain> <45F3641A.9030501@boreham.org> <45F547FA.4050602@redhat.com> Message-ID: <1173759429.28440.5.camel@localhost.localdomain> On Mon, 2007-03-12 at 06:30 -0600, Richard Megginson wrote: > David Boreham wrote: > > > > Some more info on this: > > > > FDS was designed to install at an arbitrary subdirectory in the > > filesystem. > > rpath only supports absolute paths and paths relative to the current > > working > > directory, not the location of the binary (some platforms have some > > support > > for rpath relative to the main binary location but at the time this > > was last > > looked at seriously, that support was spotty and incomplete). > > And so we have wrappers. They allow a user to add one directory > > to their path and run any FDS command without regard to setting > > LD_LIBRARY_PATH. > > > > To remove the wrappers you'd need to give up something : > > install at a fixed location (and use absolute rpaths); don't give > > users the convenience of running commands without setting > > LD_LIBRARY_PATH themselves; only run on platforms > > that have support for relative-to-binary rpath. > We're using the first option on Fedora. We install all of the libraries > in system locations, so there is no need to set rpath or have wrapper > scripts for the command line programs. The only one in question is > libslapd.so, and we could put that in the system $_libdir, or some other > directory that is "approved" by the FHS. Yeah, that seems very out of place in $_libdir > We were planning to get rid of > the wrapper scripts sooner or later on Fedora. Does this have to be > sooner? Are the wrapper scripts causing some problem (other than an > aesthetic one)? Not in particular, but an interesting point was made on the fedora-devel list: If the 'wrapped' binary forks a child, then that unrelated child also inherits the environment, which may not be desired. > We require the use of wrapper scripts on almost every other platform, > including RHEL4 - and, AFAIK, on other linux distros that put the NSPR > and NSS bundled with the Mozilla clients in the system _libdir. Fedora > solved this problem by making NSPR and NSS independent of Mozilla. In Samba4, we 'solved' the similar problems (on a smaller scale) by including the code statically. I can't claim that's a Superior solution... Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.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 skvidal at linux.duke.edu Tue Mar 13 04:57:28 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 13 Mar 2007 00:57:28 -0400 Subject: Yum repository indices broken by reorganization In-Reply-To: <200703121743.08293.jkeating@redhat.com> References: <883cfe6d0703121239w7f1a782fxe8d4cbe76cfc7028@mail.gmail.com> <200703121552.21573.jkeating@redhat.com> <883cfe6d0703121409w26988313pca5ae399da803ad3@mail.gmail.com> <200703121743.08293.jkeating@redhat.com> Message-ID: <1173761848.20424.53.camel@cutter> On Mon, 2007-03-12 at 17:43 -0400, Jesse Keating wrote: > On Monday 12 March 2007 17:09:20 Michel Salim wrote: > > Ah yes, that works. Any reason why this is necessary? > > Content moved from Fedora/RPMS/ to just Fedora/ and the cached information > didn't cope with that. > > Seth, what might we be able to do in the future with things like this? Not > that I expect to move content again, but ya never know... I'm confused as to what happened. you made a path like: foo/bar/RPMS then you moved the packages from foo/bar/RPMS to foo/bar/ and you wonder why the metadata made for the pkgs in foo/bar/RPMS doesn't work? or is there something else going on here that I've missed? -sv From bbbush.yuan at gmail.com Tue Mar 13 05:45:18 2007 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Tue, 13 Mar 2007 13:45:18 +0800 Subject: speed of yum depsolver In-Reply-To: References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> <20070312161310.GA27101@redhat.com> <1173716340.20424.31.camel@cutter> <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> Message-ID: <76e72f800703122245g27c445ddg1b57a9020ae5efa5@mail.gmail.com> I noticed that when yum find deps for package A, not only A but also B, C, .... all packages will be checked for deps again, including(?) system installed ones. It is very slow to run "yum update" on which ~300 packages have updates. This slow only happens with "yum update", while "yum install" a specific package is very fast. This is strange, has it been fixed? Thanks! -- bbbush ^_^ From gauret at free.fr Tue Mar 13 06:52:42 2007 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 13 Mar 2007 07:52:42 +0100 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files References: Message-ID: Neal Becker wrote: > This sounds great! I haven't looked at the code yet. It's pretty trivial, you'll see > Will it also ignore cases when the new config hasn't actually changed, and > silently remove the redundant copy? That would be really great. If RPM created a copy, it means something has changed. The plugin just looks for .rpmsave/.rpmnew files (depending if it's a %config or a %config(noreplace)) Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr It is by caffeine alone that I set my mind in motion. It is by the beans of java that the thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone that I set my mind in motion. From Lam at Lam.pl Tue Mar 13 07:00:58 2007 From: Lam at Lam.pl (Leszek Matok) Date: Tue, 13 Mar 2007 08:00:58 +0100 Subject: speed of yum depsolver In-Reply-To: References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> <20070312161310.GA27101@redhat.com> <1173716340.20424.31.camel@cutter> <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> Message-ID: <1173769258.4382.7.camel@pensja.lam.pl> Dnia 12-03-2007, pon o godzinie 20:59 +0100, Thomas M Steenholdt napisa?(a): > This is a *development* forum and we're talking about the *development* > version of yum... For software to get better, sometimes new features > have to be implemented, making it worse for a while, that the way it > goes. On the other hand, we're talking about development of whole Fedora. Without yum working, how are users going to test other components? The question of how to make it work is important for other package developers/maintainers, because they need testing of newest versions of their packages, too. No need to become offended (without anyone wanting to offend Seth) if you develop a program so important for the whole Fedora and users ask questions about it. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From tmus at tmus.dk Tue Mar 13 07:17:46 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 13 Mar 2007 08:17:46 +0100 Subject: Yum repository indices broken by reorganization In-Reply-To: <200703121743.08293.jkeating@redhat.com> References: <883cfe6d0703121239w7f1a782fxe8d4cbe76cfc7028@mail.gmail.com> <200703121552.21573.jkeating@redhat.com> <883cfe6d0703121409w26988313pca5ae399da803ad3@mail.gmail.com> <200703121743.08293.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Monday 12 March 2007 17:09:20 Michel Salim wrote: >> Ah yes, that works. Any reason why this is necessary? > > Content moved from Fedora/RPMS/ to just Fedora/ and the cached information > didn't cope with that. > > Seth, what might we be able to do in the future with things like this? Not > that I expect to move content again, but ya never know... > > If we really *need* to handle this kind of thing (ie. announcements on mailinglists etc is not enough) it would probably be possible to add a flag to repomd.xml to discard the various caches, but then we'd need a local flag to make sure we only discard those caches once... IMO, this is not too hard a task to accomplish, but effort is probably better spent elsewhere. Especially now. /Thomas From pmr at pajato.com Tue Mar 13 08:50:51 2007 From: pmr at pajato.com (Paul Michael Reilly) Date: Tue, 13 Mar 2007 04:50:51 -0400 Subject: When to expect support for 3945 Wireless in Rawhide In-Reply-To: <20070312131054.GA11002@redhat.com> References: <45F2B908.8050309@pajato.com> <20070310135917.GA11811@redhat.com> <45F30DE7.40302@pajato.com> <20070312131054.GA11002@redhat.com> Message-ID: <45F665EB.1070104@pajato.com> John W. Linville wrote: > On Sat, Mar 10, 2007 at 02:58:31PM -0500, Paul Michael Reilly wrote: ... >> I ran your kernel and the chip was detected on my HP nw9440 laptop so I >> considered that one hurdle overcome. But I forgot to download the >> firmware. Now why is that a separate process? How is this going to > > Is this an honest inquiry into why some devices have separate > firmware files? Or is it a veiled complaint about something which > I really cannot control? In case it is the former, reasons include > releasing the firmware under a different license than the kernel and > being able to change the firmware without having to rebuild the kernel. I am simply taking the viewpoint that using a device in a modern OS should be a seamless operation from the User perspective, assuming for Fedora that the device has freely available firmware (when relevant) and drivers. In this case my understanding is that Fedora is choosing to support the 3945 wireless chip via direct kernel support rather than via an ipw3945 (or some such) rpm package. And since the kernel appears to look for the firmware in a particular location (it complains when it cannot find it) the natural question, "how should the firmware file get put in place?" occurred. And it seems to me that the answer should be that the firmware was put in place by the distro, as part of an install process. So I am trying to understand how Fedora 7 is going to resolve this issue and I asked you hoping you would know. >> work with F7? Surely the firmware will be included in some rpm. >> Correct? If so can you supply both that rpm and the kernel rpm and I >> will perform a more realistic test. > > I have no such RPM. The firmware is downloadable from the iwlwifi > project site: > > http://intellinuxwireless.org > > I believe there is an effort to get freely redistributable firmware > packaged and available in the main Fedora repositories. But, that > work is being done primarily by someone other than me. You may want > to look here: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230096 This is helpful. It says to me that anaconda or kudzu (whichever one is responsible for dealing with hardware setup) should check for the existence of a chip which requires the firmware and then should install the file via the rpm so that the kernel will find it on reboot. Is this what you would expect? Thanks, -pmr From mlichvar at redhat.com Tue Mar 13 09:38:42 2007 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Tue, 13 Mar 2007 10:38:42 +0100 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files In-Reply-To: References: Message-ID: <20070313093842.GA21675@localhost> On Tue, Mar 13, 2007 at 07:52:42AM +0100, Aurelien Bompard wrote: > > Will it also ignore cases when the new config hasn't actually changed, and > > silently remove the redundant copy? That would be really great. > > If RPM created a copy, it means something has changed. The plugin just looks > for .rpmsave/.rpmnew files (depending if it's a %config or > a %config(noreplace)) Unfortunately rpm creates on multiarch .rpmnew files for configs which differ only in modification time (see #128622). It would be nice to have an additional check implemented in the plugin to workaround the bug. -- Miroslav Lichvar From buildsys at redhat.com Tue Mar 13 10:36:24 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 13 Mar 2007 06:36:24 -0400 Subject: rawhide report: 20070313 changes Message-ID: <200703131036.l2DAaO3E017949@hs20-bc2-6.build.redhat.com> Updated Packages: GConf2-2.18.0.1-1.fc7 --------------------- * Tue Mar 13 2007 Matthias Clasen - 2.18.0.1-1 - Update to 2.18.0.1 a2ps-4.13b-64.fc7 ----------------- * Mon Mar 12 2007 Tim Waugh 4.13b-64 - Renamed tarball generation script (bug #225235). bind-31:9.4.0-2.fc7 ------------------- * Mon Mar 12 2007 Adam Tkac 31:9.4.0-2.fc7 - added experimental SQLite support (written by John Boyd ) - moved bind-chroot-admin script to chroot package - bind-9.3.2-redhat_doc.patch is always applied (#231738) bsh-0:1.3.0-9jpp.2 ------------------ * Mon Mar 12 2007 Karsten Hopp 1.3.0-9jpp.2 - add buildrequirement ant-trax for documentation bug-buddy-1:2.18.0-1.fc7 ------------------------ * Tue Mar 13 2007 Matthias Clasen - 1:2.18.0-1 - Update to 2.18.0 compat-slang-1.4.9-28.fc7 ------------------------- * Mon Mar 12 2007 Miroslav Lichvar - 1.4.9-28 - spec cleanup cpuspeed-1:1.2.1-1.57.fc7 ------------------------- * Mon Mar 12 2007 Jarod Wilson - Try loading acpi-cpufreq even on machines that don't report est flag (#231783, #216702) - Tighten up formatting in initscript cracklib-2.8.9-10 ----------------- * Mon Mar 12 2007 Nalin Dahyabhai - 2.8.9-10 - explicitly include required headers from (#228698) - attempt to provide doc strings in the python module diffstat-1.43-4.fc7 ------------------- * Mon Mar 12 2007 Tim Waugh 1.43-4 - Removed unnecessary comment (bug #225695). - Fixed license tag (bug #225695). eel2-2.18.0.1-1.fc7 ------------------- * Mon Mar 12 2007 Alexander Larsson - 2.18.0.1-1 - update to 2.18.0.1 * Mon Mar 12 2007 Alexander Larsson - 2.18.0-1 - update to 2.18.0 ekiga-2.0.7-2.fc7 ----------------- * Mon Mar 12 2007 Daniel Veillard - 2.0.7-1 - Upgrade to ekiga-2.0.7 eog-2.18.0.1-1.fc7 ------------------ * Tue Mar 13 2007 Matthias Clasen - 2.18.0.1-1 - Update to 2.18.0.1 evince-0.8.0-1.fc7 ------------------ * Tue Mar 13 2007 Matthias Clasen - 0.8.0-1 - Update to 0.8.0 - Use desktop-file-install evolution-2.10.0-1.fc7 ---------------------- * Mon Mar 12 2007 Matthew Barnes - 2.10.0-1.fc7 - Update to 2.10.0. - Add patch for GNOME bug #376991 (refactor password handling). * Mon Feb 26 2007 Matthew Barnes - 2.9.92-1.fc7 - Update to 2.9.92. - Require gtkhtml3 >= 3.13.92. - Add missing libgnomeprintui22 requirements. - Remove patch for GNOME bug #350253 (fixed upstream). - Remove patch for GNOME bug #356177 (fixed upstream). - Remove patch for GNOME bug #360946 (fixed upstream). - Remove evolution-2.5.4-move-autosave-file.patch (fixed upstream). - Add minimum version to intltool requirement (currently >= 0.35.5). * Thu Feb 15 2007 Matthew Barnes - 2.9.91-3.fc7 - Revise patch for GNOME bug #362638 to fix RH bug #220714 (certificate prompt causes crash). evolution-connector-2.10.0-1.fc7 -------------------------------- * Mon Mar 12 2007 Matthew Barnes - 2.10.0-1.fc7 - Update to 2.10.0 evolution-data-server-1.10.0-1.fc7 ---------------------------------- * Mon Mar 12 2007 Matthew Barnes - 1.10.0-1.fc7 - Update to 1.10.0 - Remove patch for GNOME bug #301363 (fixed upstream). file-4.20-1.fc7 --------------- * Wed Mar 07 2007 Martin Bacovsky - 4.20-1 - upgrade to new upstream 4.20 * Tue Feb 20 2007 Martin Bacovsky - 4.19-4 - rpath in file removal * Mon Feb 19 2007 Martin Bacovsky - 4.19-3 - Resolves: #225750 - Merge Review: file file-roller-2.18.0-1.fc7 ------------------------ * Tue Mar 13 2007 Matthias Clasen - 2.18.0-1 - Update to 2.18.0 firefox-2.0.0.2-2.fc7 --------------------- * Mon Mar 12 2007 Christopher Aillon 2.0.0.2-2 - Oops, define the variables I expect to use. gcalctool-5.9.14-1.fc7 ---------------------- * Tue Mar 13 2007 Matthias Clasen - 5.9.14-1 - Update to 5.9.14 gconf-editor-2.18.0-1.fc7 ------------------------- * Tue Mar 13 2007 Matthias Clasen - 2.18.0-1 - Update to 2.18.0 gdb-6.6-5.fc7 ------------- * Mon Mar 12 2007 Jan Kratochvil - 6.6-5 - Temporary support for shared libraries >2GB on 64bit hosts. (BZ 231832) * Sun Feb 25 2007 Jan Kratochvil - 6.6-4 - Backport + testcase for PPC Power6/DFP instructions disassembly (BZ 230000). * Mon Feb 05 2007 Jan Kratochvil - 6.6-3 - Fix a race during attaching to dying threads; backport (BZ 209445). - Testcase of unwinding has now marked its unsolvable cases (for BZ 140532). gnome-desktop-2.18.0-1.fc7 -------------------------- * Tue Mar 13 2007 Matthias Clasen - 2.18.0-1 - Update to 2.18.0 gnome-doc-utils-0.10.1-1.fc7 ---------------------------- * Mon Mar 12 2007 Matthew Barnes - 0.10.1-1.fc7 - Update to 0.10.1 gnome-games-1:2.18.0-1.fc7 -------------------------- * Tue Mar 13 2007 Matthias Clasen - 1:2.18.0-1 - Update to 2.18.0 gnome-icon-theme-2.18.0-1.fc7 ----------------------------- * Tue Mar 13 2007 Matthias Clasen - 2.18.0-1 - Update to 2.18.0 gnome-keyring-manager-2.18.0-1.fc7 ---------------------------------- * Tue Mar 13 2007 Matthias Clasen - 2.18.0-1 - Update to 2.18.0 - Use desktop-file-install gnome-nettool-2.18.0-1.fc7 -------------------------- * Tue Mar 13 2007 Matthias Clasen - 2.18.0-1 - Update to 2.18.0 gnome-python2-2.18.0-1.fc7 -------------------------- * Mon Mar 12 2007 Matthew Barnes - 2.18.0-1.fc7 - Update to 2.18.0 * Mon Feb 26 2007 Matthew Barnes - 2.17.92-2.fc7 - Rebuild * Sun Feb 25 2007 Matthew Barnes - 2.17.92-1.fc7 - Update to 2.17.92 gnome-python2-desktop-2.18.0-1.fc7 ---------------------------------- * Mon Mar 12 2007 Matthew Barnes - 2.18.0-1.fc7 - Update to 2.18.0 gnome-session-2.18.0-1.fc7 -------------------------- * Tue Mar 13 2007 Matthias Clasen - 2.18.0-1 - Update to 2.18.0 gnome-terminal-2.18.0-1.fc7 --------------------------- * Tue Mar 13 2007 Matthias Clasen - 2.18.0-1 - Update to 2.18.0 gnome-themes-2.18.0-1.fc7 ------------------------- * Tue Mar 13 2007 Matthias Clasen - 2.18.0-1 - Update to 2.18.0 gnome-vfs2-2.18.0-1.fc7 ----------------------- * Mon Mar 12 2007 Alexander Larsson - 2.18.0-1 - update to 2.18.0 gnupg-1.4.7-6 ------------- * Fri Mar 09 2007 Nalin Dahyabhai - 1.4.7-6 - require autoconf >= 2.60, noting that we need it to define $localedir, to avoid cases where using older versions causes gnupg to not be able to find locale data (#231595) gtkhtml3-3.14.0-1.fc7 --------------------- * Mon Mar 12 2007 Matthew Barnes - 3.14.0-1.fc7 - Update to 3.14.0 - Bump gtkhtml_major to 3.14. gucharmap-1.10.0-1.fc7 ---------------------- * Tue Mar 13 2007 Matthias Clasen - 1.10.0-1 - Update to 1.10.0 httpd-2.2.4-2 ------------- * Mon Mar 12 2007 Joe Orton 2.2.4-2 - update to 2.2.4 - drop the migration guide (#223605) jakarta-commons-collections-0:3.1-9jpp.1.fc7 -------------------------------------------- * Mon Mar 12 2007 Matt Wringe - 0:3.1-9jpp.1 - Merge with jpp version - Fix rpmlint issues * Fri Feb 23 2007 Jason Corley 0:3.1-9jpp - update copyright to contain current year - rebuild on RHEL4 to avoid broken jar repack script in FC6 * Fri Jan 26 2007 Matt Wringe - 0:3.1-8jpp - Fix bug in collections-tomcat5-build.xml kdbg-1:2.0.5-2.fc7 ------------------ * Mon Mar 12 2007 Than Ngo - 1:2.0.5-2.fc7 - cleanup specfile kdeaccessibility-1:3.5.6-3.fc7 ------------------------------ * Mon Mar 12 2007 Than Ngo 1:3.5.6-3.fc7 - fix broken dependencies kdeaddons-3.5.6-4.fc7 --------------------- * Mon Mar 12 2007 Than Ngo - 3.5.6-4.fc7 - fix broken dependencies kdeadmin-7:3.5.6-4.fc7 ---------------------- * Mon Mar 12 2007 Than Ngo - 7:3.5.6-4.fc7 - fix broken dependencies * Mon Mar 12 2007 Than Ngo 7:3.5.6-3.fc7 - fix broken dependencies kdemultimedia-6:3.5.6-3.fc7 --------------------------- * Mon Mar 12 2007 Than Ngo - 6:3.5.6-3.fc7 - cleanup specfile kernel-2.6.20-1.2985.fc7 ------------------------ * Mon Mar 12 2007 Dave Jones - 2.6.21-rc3-git7 * Mon Mar 12 2007 Adam Jackson - linux-2.6-i82875-edac-pci-setup.patch: Fix PCI registration of i82875 EDAC, so /proc/bus/pci/devices will be correct and X will start. (#231484) * Sun Mar 11 2007 David Woodhouse - Re-enable bcm43xx fix libselinux-2.0.7-1.fc7 ---------------------- * Mon Mar 12 2007 Dan Walsh - 2.0.7-1 * Merged patch to drop support for CACHETRANS=0 config option from Steve Grubb. * Merged patch to drop support for old /etc/sysconfig/selinux and /etc/security policy file layout from Steve Grubb. libsemanage-2.0.1-1.fc7 ----------------------- * Mon Mar 12 2007 Dan Walsh - 2.0.1-1 * Merged dbase_file_flush patch from Dan Walsh. This removes any mention of specific tools (e.g. semanage) from the comment header of the auto-generated files, since there are multiple front-end tools. libwnck-2.18.0-1.fc7 -------------------- * Tue Mar 13 2007 Matthias Clasen - 2.18.0-1 - Update to 2.18.0 man-1.6e-3.fc7 -------------- * Mon Mar 12 2007 Ivana Varekova - 1.6e-3 - incorporate the package review feedback * Tue Jan 09 2007 Ivana Varekova - 1.6e-2 - Resolves: 221868 man use incorrect groff option - spec file cleanup * Mon Dec 11 2006 Ivana Varekova - 1.6e-1 - update to 1.6e man-pages-2.43-10.fc7 --------------------- * Mon Mar 12 2007 Ivana Varekova 2.43-10 - change the default buildroot * Mon Mar 12 2007 Ivana Varekova 2.43-9 - add lang macro * Tue Feb 27 2007 Ivana Varekova 2.43-8 - fix 229870 - bug in fadvise(2) - fix 229204 - bug in passwd(5) metacity-2.18.0-1.fc7 --------------------- * Tue Mar 13 2007 Matthias Clasen - 2.18.0-1 - Update to 2.18.0 mysql-5.0.37-1.fc7 ------------------ * Mon Mar 12 2007 Tom Lane 5.0.37-1 - Update to MySQL 5.0.37 Resolves: #231838 - Put client library into a separate mysql-libs RPM to reduce dependencies Resolves: #205630 nautilus-2.18.0.1-1.fc7 ----------------------- * Mon Mar 12 2007 Alexander Larsson - 2.18.0.1-1 - Update to 2.18.0.1 * Tue Mar 06 2007 Alexander Larsson - 2.17.92-3 - Update xdg-user-dirs patch, now handle renaming desktop dir * Thu Mar 01 2007 Alexander Larsson - 2.17.92-2 - Add xdg-user-dirs patch nautilus-cd-burner-2.18.0-1.fc7 ------------------------------- * Tue Mar 13 2007 Matthias Clasen - 2.18.0-1 - Update to 2.18.0 - Use desktop-file-install net-snmp-1:5.4-13.fc7 --------------------- * Mon Mar 12 2007 Radek Vok??l - 1:5.4-13 - fix overly verbose log message (#221911) - few minor tweaks for review - still not perfect - fix linking with lcrypto (#231805) nfs-utils-1:1.0.12-3.fc7 ------------------------ * Mon Mar 12 2007 Steve Dickson 1.0.12-3 - Incorporated Merge Review comments (bz 226198) * Fri Mar 09 2007 Steve Dickson 1.0.12-2 - Added condstop to all the initscripts (bz 196934) - Made no_subtree_check a default export option (bz 212218) * Tue Mar 06 2007 Steve Dickson 1.0.12-1 - Upgraded to 1.0.12 - Fixed typo in Summary. opal-2.2.6-1.fc7 ---------------- * Mon Mar 12 2007 Daniel Veillard - 2.2.6-1 - upstream release of 2.2.6 openoffice.org-1:2.2.0-11.2 --------------------------- * Mon Mar 12 2007 Caolan McNamara - 1:2.2.0-11.2 - add openoffice.org-2.2.0.oooXXXXX.svtools.eventmismatch.patch pam_pkcs11-0.5.3-24 ------------------- * Thu Mar 08 2007 Florian La Roche - 0.5.3-24 - remove empty rpm scripts * Fri Oct 13 2006 Jesse Keating - 0.5.3-23 - turn OCSP off by default pango-1.16.1-1.fc7 ------------------ * Tue Mar 13 2007 Matthias Clasen - 1.16.1-1 - Update to 1.16.1 policycoreutils-2.0.7-2.fc7 --------------------------- * Mon Mar 12 2007 Dan Walsh 2.0.7-2 - Fix gui psgml-1.2.5-6.fc7 ----------------- * Mon Mar 12 2007 Florian La Roche 1.2.5-6.fc7 - rebuild pwlib-1.10.5-1.fc7 ------------------ * Mon Mar 12 2007 Daniel Veillard - 1.10.5-1 - Update to 1.10.5 pyxf86config-0.3.33-1.fc7 ------------------------- * Mon Mar 12 2007 Adam Jackson 0.3.33-1 - Add some more modes to the default set (#165325) scim-1.4.5-11.fc7 ----------------- * Tue Mar 13 2007 Jens Petersen - 1.4.5-11 - improve sourceforge url to main tarball (#226395) - preserve timestamps under make install (#226395) * Mon Mar 12 2007 Jens Petersen - 1.4.5-10 - make only scim-libs own lib directories used by both scim and scim-libs since scim requires scim-libs (#226395) - update desktop file to remove deprecated X-Fedora and Applications categories with scim-setup-desktop-file.patch (#226395) * Fri Mar 09 2007 Jens Petersen - 1.4.5-9 - add scim-1.4.5-no-rpath-libdir.patch to remove rpaths to libdir - rpmlint cleanup (#226395) scim-anthy-1.2.2-2.fc7 ---------------------- * Mon Mar 12 2007 Akira TAGOH - 1.2.2-2 - clean up a spec file. (#226390) selinux-policy-2.5.8-2.fc7 -------------------------- * Mon Mar 12 2007 Dan Walsh 2.5.8-2 - Fix handling of unlabled_t packets * Thu Mar 08 2007 Dan Walsh 2.5.8-1 - More of my patches from upstream * Thu Mar 01 2007 Dan Walsh 2.5.7-1 - Update to latest from upstream - Add fail2ban policy setup-2.6.3-1.fc7 ----------------- * Mon Mar 12 2007 Phil Knirsch 2.6.3-1 - Changed winbind_auth to wbpriv by request of the samba maintainer * 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 sysklogd-1.4.2-2.fc7 -------------------- * Mon Mar 12 2007 Peter Vrabec 1.4.2-2 - log in syslog own timezone (#231326) vte-0.16.0-1.fc7 ---------------- * Mon Mar 12 2007 Behdad Esfahbod 0.16.0-1 - Update to 0.16.0 xorg-x11-drv-nv-1.99.1-2.fc7 ---------------------------- * Mon Mar 12 2007 Adam Jackson 1.99.1-2 - nv.xinf: Various G73 PCI IDs. xorg-x11-proto-devel-7.2-6.fc7 ------------------------------ * Mon Mar 12 2007 Adam Jackson 7.2-6 - Fix doc macros as per package review (#226641) yelp-2.18.0-1.fc7 ----------------- * Tue Mar 13 2007 Matthew Barnes - 2.18.0-1 - Update to 2.18.0 zenity-2.18.0-1.fc7 ------------------- * Tue Mar 13 2007 Matthias Clasen - 2.18.0-1 - Update to 2.18.0 Broken deps for s390 ---------------------------------------------------------- gnome-applets - 1:2.17.90-1.fc7.s390 requires libgucharmap.so.5 gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 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 ---------------------------------------------------------- frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnome-applets - 1:2.17.90-1.fc7.i386 requires libgucharmap.so.5 gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 Broken deps for ppc64 ---------------------------------------------------------- gnome-applets - 1:2.17.90-1.fc7.ppc64 requires libgucharmap.so.5()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ppc64 requires libofx.so.3()(64bit) Broken deps for ia64 ---------------------------------------------------------- gnome-applets - 1:2.17.90-1.fc7.ia64 requires libgucharmap.so.5()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.ia64 requires libofx.so.3()(64bit) Broken deps for ppc ---------------------------------------------------------- gnome-applets - 1:2.17.90-1.fc7.ppc requires libgucharmap.so.5 gnucash - 2.0.5-1.fc6.ppc requires libofx.so.3 gnucash - 2.0.5-1.fc6.ppc requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.ppc requires libgtkhtml-3.8.so.15 Broken deps for s390x ---------------------------------------------------------- gnome-applets - 1:2.17.90-1.fc7.s390x requires libgucharmap.so.5()(64bit) gnome-applets - 1:2.17.90-1.fc7.s390 requires libgucharmap.so.5 gnucash - 2.0.5-1.fc6.s390 requires libofx.so.3 gnucash - 2.0.5-1.fc6.s390 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.s390 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.s390x requires libofx.so.3()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.s390x requires libgtkhtml-3.8.so.15()(64bit) python-pyblock - 0.27-3.s390 requires libdmraid.so.1.0.0.rc14(Base) python-pyblock - 0.27-3.s390 requires libdmraid.so.1.0.0.rc14 Broken deps for x86_64 ---------------------------------------------------------- frysk - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-devel - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.x86_64 requires libgcj.so.7rh()(64bit) frysk-gnome - 0.0.1.2007.02.07.rh1-1.fc7.i686 requires libgcj.so.7rh gnome-applets - 1:2.17.90-1.fc7.x86_64 requires libgucharmap.so.5()(64bit) gnome-applets - 1:2.17.90-1.fc7.i386 requires libgucharmap.so.5 gnucash - 2.0.5-1.fc6.x86_64 requires libgtkhtml-3.8.so.15()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libaqbanking.so.16()(64bit) gnucash - 2.0.5-1.fc6.x86_64 requires libofx.so.3()(64bit) gnucash - 2.0.5-1.fc6.i386 requires libaqbanking.so.16 gnucash - 2.0.5-1.fc6.i386 requires libgtkhtml-3.8.so.15 gnucash - 2.0.5-1.fc6.i386 requires libofx.so.3 python-pyblock - 0.27-3.i386 requires libdmraid.so.1.0.0.rc14 python-pyblock - 0.27-3.i386 requires libdmraid.so.1.0.0.rc14(Base) From giallu at gmail.com Tue Mar 13 10:45:07 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 13 Mar 2007 11:45:07 +0100 Subject: When to expect support for 3945 Wireless in Rawhide In-Reply-To: <45F665EB.1070104@pajato.com> References: <45F2B908.8050309@pajato.com> <20070310135917.GA11811@redhat.com> <45F30DE7.40302@pajato.com> <20070312131054.GA11002@redhat.com> <45F665EB.1070104@pajato.com> Message-ID: On 3/13/07, Paul Michael Reilly wrote: > I am simply taking the viewpoint that using a device in a modern OS > should be a seamless operation from the User perspective, assuming for > Fedora that the device has freely available firmware (when relevant) and > drivers. Until recently, the freely available drivers were not in the "free" shape needed for inclusion in Fedora, since they relied on a binary only daemon for working. > In this case my understanding is that Fedora is choosing to > support the 3945 wireless chip via direct kernel support rather than via > an ipw3945 (or some such) rpm package. That apply to basically every kernel driver, so ipw3945 is by no means special. kmod rpms are discouraged as the natural place for kernel drivers is IN the kernel sources. > And since the kernel appears to > look for the firmware in a particular location (it complains when it > cannot find it) the natural question, "how should the firmware file get > put in place?" occurred. And it seems to me that the answer should be > that the firmware was put in place by the distro, as part of an install > process. So I am trying to understand how Fedora 7 is going to resolve > this issue and I asked you hoping you would know. I believe it will do that in the exactly same way as everything else: installing an RPM with the firmware files. There are already a lot under review for various wifi chipsets (including ipw3945) so they will be probably show up (soon?) in the main repository. To speed up the process, you may wish to help with the reviews From mattdm at mattdm.org Tue Mar 13 11:25:45 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 13 Mar 2007 07:25:45 -0400 Subject: speed of yum depsolver In-Reply-To: <1173769258.4382.7.camel@pensja.lam.pl> References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> <20070312161310.GA27101@redhat.com> <1173716340.20424.31.camel@cutter> <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> <1173769258.4382.7.camel@pensja.lam.pl> Message-ID: <20070313112545.GA28320@jadzia.bu.edu> On Tue, Mar 13, 2007 at 08:00:58AM +0100, Leszek Matok wrote: > Without yum working, how are users going to test other components? The Like we did before yum existed. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ndbecker2 at gmail.com Tue Mar 13 10:58:44 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 13 Mar 2007 06:58:44 -0400 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files References: <20070313093842.GA21675@localhost> Message-ID: Miroslav Lichvar wrote: > On Tue, Mar 13, 2007 at 07:52:42AM +0100, Aurelien Bompard wrote: >> > Will it also ignore cases when the new config hasn't actually changed, >> > and >> > silently remove the redundant copy? That would be really great. >> >> If RPM created a copy, it means something has changed. The plugin just >> looks for .rpmsave/.rpmnew files (depending if it's a %config or >> a %config(noreplace)) > > Unfortunately rpm creates on multiarch .rpmnew files for configs which > differ only in modification time (see #128622). > > It would be nice to have an additional check implemented in the > plugin to workaround the bug. > Yes, that's what I meant. Please, please. From jkeating at redhat.com Tue Mar 13 14:35:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 13 Mar 2007 10:35:28 -0400 Subject: Yum repository indices broken by reorganization In-Reply-To: <1173761848.20424.53.camel@cutter> References: <883cfe6d0703121239w7f1a782fxe8d4cbe76cfc7028@mail.gmail.com> <200703121743.08293.jkeating@redhat.com> <1173761848.20424.53.camel@cutter> Message-ID: <200703131035.28875.jkeating@redhat.com> On Tuesday 13 March 2007 00:57:28 seth vidal wrote: > I'm confused as to what happened. > > you made a path like: > > foo/bar/RPMS > > then you moved the packages from > foo/bar/RPMS > to foo/bar/ > > and you wonder why the metadata made for the pkgs in foo/bar/RPMS > doesn't work? > > or is there something else going on here that I've missed? As discussed on IRC there is slightly more to this. A bunch of packages exist in foo/bar/RPMS, and repodata gets created at the foo/ level. This repodata is cached by many clients during regular operations. Then, some new packages are added, some removed, and content is moved from foo/bar/RPMS/ to just foo/bar/ and repodata is recreated at the foo/ level. My best guess here is that since many of the package checksums did not change, only their location, yum is using the cached information about those packages when it comes time to retrieve them. Something like "I'm reading in new metadata to cache, oh I already know about this package move on to the next" and the new url to the file is never added to the cache. Of course, this is purely speculation and I could be completely off base (: -- 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 skvidal at linux.duke.edu Tue Mar 13 14:39:52 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 13 Mar 2007 10:39:52 -0400 Subject: Yum repository indices broken by reorganization In-Reply-To: <200703131035.28875.jkeating@redhat.com> References: <883cfe6d0703121239w7f1a782fxe8d4cbe76cfc7028@mail.gmail.com> <200703121743.08293.jkeating@redhat.com> <1173761848.20424.53.camel@cutter> <200703131035.28875.jkeating@redhat.com> Message-ID: <1173796792.20424.80.camel@cutter> On Tue, 2007-03-13 at 10:35 -0400, Jesse Keating wrote: > On Tuesday 13 March 2007 00:57:28 seth vidal wrote: > > I'm confused as to what happened. > > > > you made a path like: > > > > foo/bar/RPMS > > > > then you moved the packages from > > foo/bar/RPMS > > to foo/bar/ > > > > and you wonder why the metadata made for the pkgs in foo/bar/RPMS > > doesn't work? > > > > or is there something else going on here that I've missed? > > As discussed on IRC there is slightly more to this. > > A bunch of packages exist in foo/bar/RPMS, and repodata gets created at the > foo/ level. This repodata is cached by many clients during regular > operations. > > Then, some new packages are added, some removed, and content is moved from > foo/bar/RPMS/ to just foo/bar/ and repodata is recreated at the foo/ level. > > My best guess here is that since many of the package checksums did not change, > only their location, yum is using the cached information about those packages > when it comes time to retrieve them. Something like "I'm reading in new > metadata to cache, oh I already know about this package move on to the next" > and the new url to the file is never added to the cache. Of course, this is > purely speculation and I could be completely off base (: hmm. Now that could be happening, yes. I'll have to check what the metadata-parser is doing to see if it needs to update the entry in the db. good call. -sv From aph at redhat.com Tue Mar 13 14:49:44 2007 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Mar 2007 14:49:44 +0000 Subject: Yum repository indices broken by reorganization In-Reply-To: <200703131035.28875.jkeating@redhat.com> References: <883cfe6d0703121239w7f1a782fxe8d4cbe76cfc7028@mail.gmail.com> <200703121743.08293.jkeating@redhat.com> <1173761848.20424.53.camel@cutter> <200703131035.28875.jkeating@redhat.com> Message-ID: <17910.47624.264604.359153@zebedee.pink> I'm sorry, I haven't been following all the detail. Is it now safe to do a rawhide update? Thanks, Andrew. From sundaram at fedoraproject.org Tue Mar 13 15:06:49 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 13 Mar 2007 20:36:49 +0530 Subject: Yum repository indices broken by reorganization In-Reply-To: <17910.47624.264604.359153@zebedee.pink> References: <883cfe6d0703121239w7f1a782fxe8d4cbe76cfc7028@mail.gmail.com> <200703121743.08293.jkeating@redhat.com> <1173761848.20424.53.camel@cutter> <200703131035.28875.jkeating@redhat.com> <17910.47624.264604.359153@zebedee.pink> Message-ID: <45F6BE09.8040308@fedoraproject.org> Andrew Haley wrote: > I'm sorry, I haven't been following all the detail. > > Is it now safe to do a rawhide update? As safe as it has ever been. Rahul From jkeating at redhat.com Tue Mar 13 15:14:13 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 13 Mar 2007 11:14:13 -0400 Subject: Yum repository indices broken by reorganization In-Reply-To: <17910.47624.264604.359153@zebedee.pink> References: <883cfe6d0703121239w7f1a782fxe8d4cbe76cfc7028@mail.gmail.com> <200703131035.28875.jkeating@redhat.com> <17910.47624.264604.359153@zebedee.pink> Message-ID: <200703131114.13184.jkeating@redhat.com> On Tuesday 13 March 2007 10:49:44 Andrew Haley wrote: > I'm sorry, I haven't been following all the detail. > > Is it now safe to do a rawhide update? sure, after a yum clean metadata or yum clean all. -- 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 skvidal at linux.duke.edu Tue Mar 13 15:16:09 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 13 Mar 2007 11:16:09 -0400 Subject: Yum repository indices broken by reorganization In-Reply-To: <200703131114.13184.jkeating@redhat.com> References: <883cfe6d0703121239w7f1a782fxe8d4cbe76cfc7028@mail.gmail.com> <200703131035.28875.jkeating@redhat.com> <17910.47624.264604.359153@zebedee.pink> <200703131114.13184.jkeating@redhat.com> Message-ID: <1173798969.20424.82.camel@cutter> On Tue, 2007-03-13 at 11:14 -0400, Jesse Keating wrote: > On Tuesday 13 March 2007 10:49:44 Andrew Haley wrote: > > I'm sorry, I haven't been following all the detail. > > > > Is it now safe to do a rawhide update? > > sure, after a yum clean metadata or yum clean all. > yum clean dbcache should nuke just the db's. which is all that needs to be done afaict. -sv From tonynelson at georgeanelson.com Tue Mar 13 15:31:47 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 13 Mar 2007 11:31:47 -0400 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files In-Reply-To: References: Message-ID: At 7:52 AM +0100 3/13/07, Aurelien Bompard wrote: >Neal Becker wrote: >> This sounds great! I haven't looked at the code yet. > >It's pretty trivial, you'll see > >> Will it also ignore cases when the new config hasn't actually changed, and >> silently remove the redundant copy? That would be really great. > >If RPM created a copy, it means something has changed. One would think so, but no, not always. Vim's rpm is one offender (retyped): # ls /etc/vimrc* /etc/vimrc /etc/vimrc.rpmnew # diff /etc/vimrc* # >The plugin just looks >for .rpmsave/.rpmnew files (depending if it's a %config or >a %config(noreplace)) Hopefully it will be able to detect and merge such files. They're certainly the easiest and safest to merge. ;-) -- ____________________________________________________________________ TonyN.:' ' From rdieter at math.unl.edu Tue Mar 13 15:57:34 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 13 Mar 2007 10:57:34 -0500 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files References: Message-ID: Tony Nelson wrote: > At 7:52 AM +0100 3/13/07, Aurelien Bompard wrote: >>Neal Becker wrote: >>> This sounds great! I haven't looked at the code yet. >> >>It's pretty trivial, you'll see >> >>> Will it also ignore cases when the new config hasn't actually changed, >>> and >>> silently remove the redundant copy? That would be really great. >> >>If RPM created a copy, it means something has changed. > > One would think so, but no, not always. Vim's rpm is one offender > (retyped): > > # ls /etc/vimrc* > /etc/vimrc /etc/vimrc.rpmnew > # diff /etc/vimrc* timestamp, owner, permissions? -- Rex From tonynelson at georgeanelson.com Tue Mar 13 16:31:12 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Tue, 13 Mar 2007 12:31:12 -0400 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files In-Reply-To: References: Message-ID: At 10:57 AM -0500 3/13/07, Rex Dieter wrote: >Tony Nelson wrote: > >> At 7:52 AM +0100 3/13/07, Aurelien Bompard wrote: >>>Neal Becker wrote: >>>> This sounds great! I haven't looked at the code yet. >>> >>>It's pretty trivial, you'll see >>> >>>> Will it also ignore cases when the new config hasn't actually changed, >>>> and >>>> silently remove the redundant copy? That would be really great. >>> >>>If RPM created a copy, it means something has changed. >> >> One would think so, but no, not always. Vim's rpm is one offender >> (retyped): >> >> # ls /etc/vimrc* >> /etc/vimrc /etc/vimrc.rpmnew >> # diff /etc/vimrc* > >timestamp, owner, permissions? (retyped): # ll /etc/vimrc* -rw-r--r-- 1 root root 1473 Nov 15 21:59 /etc/vimrc -rw-r--r-- 1 root root 1473 Mar 9 2006 /etc/vimrc.rpmnew # OK, so maybe it's not still doing it there. But this one looks more promising (I hope): # ll /etc/profile.d/krb* -rwxr-xr-x 1 root root 218 Jan 9 15:03 /etc/profile.d/krb5.csh -rwxr-xr-x 1 root root 218 Jan 9 15:03 /etc/profile.d/krb5.csh.rpmnew -rwxr-xr-x 1 root root 229 Jan 9 15:03 /etc/profile.d/krb5.sh -rwxr-xr-x 1 root root 229 Jan 9 15:03 /etc/profile.d/krb5.sh.rpmnew # diff /etc/profile.d/krb*.csh* # diff /etc/profile.d/krb*.sh* # -- ____________________________________________________________________ TonyN.:' ' From poelstra at redhat.com Tue Mar 13 17:12:20 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 13 Mar 2007 10:12:20 -0700 Subject: Fedora scheduling made easy Message-ID: <45F6DB74.7070808@redhat.com> In this post https://www.redhat.com/archives/fedora-devel-list/2007-March/msg00341.html Jeremy makes a good point about being able to scale and holding to our schedules. I believe the Fedora project can scale successfully with detailed schedules and more information about what happens in each step. I've created a new framework (contrasted with the existing schedule) and taken a few liberties at guessing at a few additional milestones that might be useful: https://poelcat.108.redhat.com/nonav/fedora/schedules/fc7/fc7-sched.png. Additional steps can easily be added. As I went through the Fedora schedule here: http://fedoraproject.org/wiki/Releases/7 I found a general outline of what is supposed to happen, but not a lot of explanation about what each step means or what is required for a particular milestone to be considered finished... in other words, "what exactly does String Freeze mean?" I would like to volunteer to help by maintaining a more detailed schedule and adding some additional wiki pages which define our terms :) The benefits of having the Fedora schedules in a project planning tool is that it is easier to manage unforeseen delays, plan alternate scenarios, and have a clearer sense of how we are doing at a particular point in time towards meeting the published schedule on time. We could also combine the docs schedule with the main Fedora schedule in a modular/manageable way. A detailed schedule would also help our project be more transparent and let others in on how many different steps go into making a release happen. Right now I have the source and generated output in my own hosting space, but can easily move it to a Fedora name space if someone can suggest the best place. I was thinking it could either be part of "infrastructure" or "Fedora board?" A sample of the scheduling reports are here: https://poelcat.108.redhat.com/nonav/fedora/schedules/fc7/tasks-overview.html Others can be created for different time periods and varying levels of detail. Any objections to moving forward with this? John From jwboyer at jdub.homelinux.org Tue Mar 13 17:26:48 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 13 Mar 2007 12:26:48 -0500 Subject: Fedora scheduling made easy In-Reply-To: <45F6DB74.7070808@redhat.com> References: <45F6DB74.7070808@redhat.com> Message-ID: <1173806808.3953.21.camel@zod.rchland.ibm.com> On Tue, 2007-03-13 at 10:12 -0700, John Poelstra wrote: > https://poelcat.108.redhat.com/nonav/fedora/schedules/fc7/fc7-sched.png. What application did you use to generate that? josh From notting at redhat.com Tue Mar 13 17:27:46 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 13 Mar 2007 13:27:46 -0400 Subject: Fedora scheduling made easy In-Reply-To: <45F6DB74.7070808@redhat.com> References: <45F6DB74.7070808@redhat.com> Message-ID: <20070313172746.GC5926@nostromo.devel.redhat.com> John Poelstra (poelstra at redhat.com) said: > As I went through the Fedora schedule here: > http://fedoraproject.org/wiki/Releases/7 I found a general outline of what > is supposed to happen, but not a lot of explanation about what each step > means or what is required for a particular milestone to be considered > finished... in other words, "what exactly does String Freeze mean?" > > I would like to volunteer to help by maintaining a more detailed schedule > and adding some additional wiki pages which define our terms :) Sure. FWIW, I find most of the taskjuggler reports to be illegible, but others opinions may vary. Bill From notting at redhat.com Tue Mar 13 17:43:01 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 13 Mar 2007 13:43:01 -0400 Subject: Fedora scheduling made easy In-Reply-To: <45F6DB74.7070808@redhat.com> References: <45F6DB74.7070808@redhat.com> Message-ID: <20070313174301.GA8235@nostromo.devel.redhat.com> A slightly longer reply... John Poelstra (poelstra at redhat.com) said: > schedules. I believe the Fedora project can scale successfully with > detailed schedules and more information about what happens in each step. Where are we failing to scale now? Is it (to use string freezes as an example): 1) people don't know about dates like string freezes (a schedule distribution issue) 2) people don't know what string freezes are (a terminology issue) 3) people don't care about string freezes (a management issue) 1) can be solved with more communication, and potentially with tools 2) can be solved with better documentation. 3) can't be solved with tools without going to extremely draconian measures that I don't feel are truly worth it. > As I went through the Fedora schedule here: > http://fedoraproject.org/wiki/Releases/7 I found a general outline of what > is supposed to happen, but not a lot of explanation about what each step > means or what is required for a particular milestone to be considered > finished... in other words, "what exactly does String Freeze mean?" This is the sort of doucmentation we should have for newer developers; for those that have been around long enough, this is sort of assumed knowledge. For example: - "Development freeze" The package set is frozen. Only packages that fix significant issues found in testing are added to the tree. - "Release" Availability for download. - "Feature freeze" All features must be complete in a testable state. Anything that's not will either be dropped or reverted. - "String freeze" Translatable Fedora-specific strings and user-interfaces should be frozen, to give the translators time to finish their work. - "Translation freeze" This is the last point for translations to be contributed and be guaranteed to get in the release. Any translations after this need to be officially requested to get pulled in. > The benefits of having the Fedora schedules in a project planning tool is > that it is easier to manage unforeseen delays, plan alternate scenarios, > and have a clearer sense of how we are doing at a particular point in time > towards meeting the published schedule on time. How does this do this in the absence of information? The majority of features haven't had any updates since they've been initially entered. (I know I'm pretty guilty in this regard). I don't see how a project tool by itself can solve this - it's still garbage in/garbage out. Bill From florin at andrei.myip.org Tue Mar 13 17:47:33 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 13 Mar 2007 10:47:33 -0700 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files In-Reply-To: <20070313093842.GA21675@localhost> References: <20070313093842.GA21675@localhost> Message-ID: <45F6E3B5.5040802@andrei.myip.org> Miroslav Lichvar wrote: > > It would be nice to have an additional check implemented in the > plugin to workaround the bug. Like a checksum? That would be nice. -- Florin Andrei http://florin.myip.org/ From sundaram at fedoraproject.org Tue Mar 13 17:53:29 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 13 Mar 2007 23:23:29 +0530 Subject: Fedora scheduling made easy In-Reply-To: <1173806808.3953.21.camel@zod.rchland.ibm.com> References: <45F6DB74.7070808@redhat.com> <1173806808.3953.21.camel@zod.rchland.ibm.com> Message-ID: <45F6E519.3050605@fedoraproject.org> Josh Boyer wrote: > On Tue, 2007-03-13 at 10:12 -0700, John Poelstra wrote: > >> https://poelcat.108.redhat.com/nonav/fedora/schedules/fc7/fc7-sched.png. > > What application did you use to generate that? Looks like Task Juggler Rahul From rnorwood at redhat.com Tue Mar 13 19:22:05 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 13 Mar 2007 15:22:05 -0400 Subject: perl, perl-devel, and missing config.h In-Reply-To: <1173734481.20424.47.camel@cutter> (seth vidal's message of "Mon, 12 Mar 2007 17:21:21 -0400") References: <1173734481.20424.47.camel@cutter> Message-ID: seth vidal writes: > On Fri, 2007-03-09 at 14:44 -0500, Robin Norwood wrote: >> Robin Norwood writes: >> >> [...] >> >> > Spot, Jesse Keating, and I have discussed the issue via email and on >> > fedora-perl-devel-list[3] - the three of us think this solution is the >> > right way to go, but several people on the list disagree. So we're >> > going to hash things out there and decide what to do. If you want to >> > follow the discussion, see fedora-perl-devel-list. Otherwise, stay >> > tuned, and we'll keep you posted. >> >> An update: it looks like we'll be able to go with the perl-devel split. >> I've just built perl-5.8.8-15, which continues the work to split >> perl/perl-devel. Right now 'perl' requires 'perl-devel', but we hope to >> fix that soon. >> > > I added a patch to the bug you opened. Anyone who can check it, please > do so. I think it's the right path toward being fixed. Thanks, Seth! The patch works fine for me, as we discussed - here's the bug, for those playing at home: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231549 -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From poelstra at redhat.com Tue Mar 13 19:22:31 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 13 Mar 2007 12:22:31 -0700 Subject: Fedora scheduling made easy In-Reply-To: <1173806808.3953.21.camel@zod.rchland.ibm.com> References: <45F6DB74.7070808@redhat.com> <1173806808.3953.21.camel@zod.rchland.ibm.com> Message-ID: <45F6F9F7.8010600@redhat.com> Josh Boyer said the following on 03/13/2007 10:26 AM Pacific Time: > On Tue, 2007-03-13 at 10:12 -0700, John Poelstra wrote: > >> https://poelcat.108.redhat.com/nonav/fedora/schedules/fc7/fc7-sched.png. > > What application did you use to generate that? > > josh > TaskJuggler. Source is here: https://poelcat.108.redhat.com/source/browse/poelcat/trunk/fedora/schedules/?rev=51#dirlist TaskJuggler is an unusual application in that the UI is really just a viewer of the underlying data. To change a task, etc. adjustments are made to the source file. The real value provided by TaskJuggler is the ability to track tasks, time and resources. There are other apps that make prettier reports, but don't give you as much power when it comes to scheduling and tracking a project. John From poelstra at redhat.com Tue Mar 13 19:25:24 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 13 Mar 2007 12:25:24 -0700 Subject: Fedora scheduling made easy In-Reply-To: <20070313174301.GA8235@nostromo.devel.redhat.com> References: <45F6DB74.7070808@redhat.com> <20070313174301.GA8235@nostromo.devel.redhat.com> Message-ID: <45F6FAA4.1060604@redhat.com> Bill Nottingham said the following on 03/13/2007 10:43 AM Pacific Time: >> The benefits of having the Fedora schedules in a project planning tool is >> that it is easier to manage unforeseen delays, plan alternate scenarios, >> and have a clearer sense of how we are doing at a particular point in time >> towards meeting the published schedule on time. > > How does this do this in the absence of information? The majority of features > haven't had any updates since they've been initially entered. (I know I'm > pretty guilty in this regard). I don't see how a project tool by itself > can solve this - it's still garbage in/garbage out. > > Bill > You make a good point :) I believe it is a combination of a project tool with detailed tasks and milestones AND a person that chases them all down and follows them to completion. A project manager eliminates the "garbage in garbage out" problem by evaluating the data going in and out and taking action when necessary to coordinate resolution. I am willing to be that person. John From sundaram at fedoraproject.org Tue Mar 13 19:33:52 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 14 Mar 2007 01:03:52 +0530 Subject: Fedora scheduling made easy In-Reply-To: <45F6DB74.7070808@redhat.com> References: <45F6DB74.7070808@redhat.com> Message-ID: <45F6FCA0.7080207@fedoraproject.org> John Poelstra wrote: > > In this post > https://www.redhat.com/archives/fedora-devel-list/2007-March/msg00341.html > Jeremy makes a good point about being able to scale and holding to our > schedules. I believe the Fedora project can scale successfully with > detailed schedules and more information about what happens in each > step. I've created a new framework (contrasted with the existing > schedule) and taken a few liberties at guessing at a few additional > milestones that might be useful: > https://poelcat.108.redhat.com/nonav/fedora/schedules/fc7/fc7-sched.png. > Additional steps can easily be added. > > As I went through the Fedora schedule here: > http://fedoraproject.org/wiki/Releases/7 I found a general outline of > what is supposed to happen, but not a lot of explanation about what each > step means or what is required for a particular milestone to be > considered finished... in other words, "what exactly does String Freeze > mean?" This shouldnt be part of a schedule. The schedule assumes that everyone involved knows what a string freeze means. If that requires explanation the schedule can link to the developers guide. http://fedora.redhat.com/docs/developers-guide/ The developer's guide needs to be updated to take into account current practices. I would like to volunteer to help by maintaining a more detailed > schedule and adding some additional wiki pages which define our terms :) I think this should be part of the guide referenced above. > The benefits of having the Fedora schedules in a project planning tool > is that it is easier to manage unforeseen delays, plan alternate > scenarios, and have a clearer sense of how we are doing at a particular > point in time towards meeting the published schedule on time. We could > also combine the docs schedule with the main Fedora schedule in a > modular/manageable way. A detailed schedule would also help our project > be more transparent and let others in on how many different steps go > into making a release happen. Right now I have the source and generated > output in my own hosting space, but can easily move it to a Fedora name > space if someone can suggest the best place. I was thinking it could > either be part of "infrastructure" or "Fedora board?" Fedora Infrastructure. I assume you are willing to be the owner leading this effort. > A sample of the scheduling reports are here: > https://poelcat.108.redhat.com/nonav/fedora/schedules/fc7/tasks-overview.html > Others can be created for different time periods and varying levels of > detail. > > Any objections to moving forward with this? I am not familiar with with all the graphs, notations and colors mean as compared to the specifications in the wiki which are quite easy to understand. I have no problem with you moving forward but I want to make sure I and others can understand what is being described in these documents. Would you care to explain that a bit? Rahul From gauret at free.fr Tue Mar 13 22:15:53 2007 From: gauret at free.fr (Aurelien Bompard) Date: Tue, 13 Mar 2007 23:15:53 +0100 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files References: <20070313093842.GA21675@localhost> Message-ID: Neal Becker wrote: >> It would be nice to have an additional check implemented in the >> plugin to workaround the bug. >> > Yes, that's what I meant. Please, please. That's trivial to do, I've added it. I also made a few fixes, the plugin should now work on FC6's yum and RawHide's yum too. I've updated the plugin itself only, the RPM is not updated. Just copy it to /usr/lib/yum-plugins http://gauret.free.fr/fichiers/rpms/fedora/yum-merge-conf/merge-conf.py Please tell me what you think of it, what I should change, and what I should add. Thanks for your feedback Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr L'exp?rience est quelquechose que l'on acquiert juste apr?s en avoir eu besoin. From redhat at olen.net Tue Mar 13 22:47:26 2007 From: redhat at olen.net (Ola Thoresen) Date: Tue, 13 Mar 2007 23:47:26 +0100 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files In-Reply-To: References: <20070313093842.GA21675@localhost> Message-ID: <45F729FE.1080508@olen.net> Aurelien Bompard wrote: > Neal Becker wrote: >>> It would be nice to have an additional check implemented in the >>> plugin to workaround the bug. >>> >> Yes, that's what I meant. Please, please. > > That's trivial to do, I've added it. > I also made a few fixes, the plugin should now work on FC6's yum and > RawHide's yum too. I've updated the plugin itself only, the RPM is not > updated. Just copy it to /usr/lib/yum-plugins > http://gauret.free.fr/fichiers/rpms/fedora/yum-merge-conf/merge-conf.py > Please tell me what you think of it, what I should change, and what I should > add. Now, I don't speak python fluently, but as far as I can tell, the script will simply continue after the "diff" is run? Would it be more intuitive if it would ask again if it should keep or replace after the diff is shown? Rgds. Ola Thoresen -- _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' Ola Thoresen .'--'. _.' {`'-;_ .-.>.' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From ml at deadbabylon.de Wed Mar 14 00:10:00 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 14 Mar 2007 01:10:00 +0100 Subject: KDE-Live-CD: basic cd layout and localizations Message-ID: <20070314011000.5b0cbcb8@localhost.localdomain> Hi. I've created a new basic layout for the cd: http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/KDELiveCD The size on todays rawhide is about 667 MB. Please tell me which package should be added or removed. On todays KDE-SIG-Meeting Rex Dieter and Kevin Kofler suggested to give the local communities the ability to create their own localized cds easily. To do this there should be an extra configuration file for each language which adds the needed packages and do some configurations. And also the additional language must fit on one cd. A second option for localized versions could (or should?) be a live-dvd with all available language packages. livecd-creator in git seems to be able to do this (but I haven't checked this yet). [1] I've created a first draft for an configuration for the german language. This adds kde-i18n-de and koffice-langpack-de to the cd. Also the standard keyboard layout, the local timezone and the locale is changed. To change the keyboard layout inside kde I've used an ugly workaround.[2] If anybody knows a better way, please tell me. :) Compared to the version above this one needs ~675 MB. To create the configuration files for different languages I need some informations from one person that uses the language: 1. /etc/sysconfig/i18n 2. /etc/sysconfig/keyboard 3. /etc/sysconfig/clock 4. keybordtype from "system-config-keyboard --help" 5. needed additional packages (eg. scim-* or fonts-*) And of course all are invited to discuss this. :) Sebastian [1] http://git.fedoraproject.org/?p=hosted/livecd [2] http://www.deadbabylon.de/fedora/livecd/source/50-fedora-livecd-kde-german.conf ######### How to create the live cd: Install livecd-tools: wget "http://people.redhat.com/~katzj/live/f7test2/livecd-tools-001-3.fc7.i386.rpm" rpm -ivh livecd-tools-001-3.fc7.i386.rpm Create the spin: livecd-creator \ --repo=c7,http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/ \ --repo=e7,http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ \ --repo=lcd7,http://www.deadbabylon.de/fedora/livecd/i386/ \ --package=fedora-livecd-kde \ --fslabel=Fedora-7-Test2-KDE To create the german version: livecd-creator \ --repo=c7,http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/ \ --repo=e7,http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ \ --repo=lcd7,http://www.deadbabylon.de/fedora/livecd/i386/ \ --package=fedora-livecd-kde-german \ --fslabel=Fedora-7-Test2-KDE-German -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bpepple at fedoraproject.org Wed Mar 14 02:17:38 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 13 Mar 2007 22:17:38 -0400 Subject: FESCo Meeting Summary for 2007-03-08 Message-ID: <1173838658.17867.4.camel@Chuck> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Christian Iseli (ch4chris) * Rex Dieter (rdieter) * Toshio Kuratomi (abadger1999) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Jesse Keating (f13) * Warren Togami (warren) * Tom Callaway (spot) === Absent === * Josh Boyer (jwb) * Bill Nottingham (notting) * Jeremy Katz (jeremy) == Summary == Closing fedora-extras mailing list * FESCo approved the closing of the f-e-l. thl will will work on this. Sponsor Nominations * Jarod Wilson was nominated and accepted as new sponsors. Packaging Committee Report * FESCo approved the Packaging Committee's guidelines regarding: * Firmware packaging guidelines: https://www.redhat.com/archives/fedora-packaging/2007-February/msg00292.html * http://fedoraproject.org/wiki/PackagingDrafts/UsrConfigs fedora-usermgmt * FESCo had a long discussion on this. RedHat BaseOS folks need to be involved. It is to late to have a solution for this by Fedora 7, will target Fedora 8. Tracker Bugs * The main blockers FE-NEW, FE-REVIEW, FE-ACCEPTED will be changed to flags. For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070308 Thanks, /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 dimitris at glezos.com Wed Mar 14 04:17:06 2007 From: dimitris at glezos.com (Dimitris Glezos) Date: Wed, 14 Mar 2007 04:17:06 +0000 Subject: Fedora scheduling made easy (Reminder: 5 days until string freeze!) In-Reply-To: <45F6FCA0.7080207@fedoraproject.org> References: <45F6DB74.7070808@redhat.com> <45F6FCA0.7080207@fedoraproject.org> Message-ID: <45F77742.4010706@glezos.com> O/H Rahul Sundaram ??????: > John Poelstra wrote: >> As I went through the Fedora schedule here: >> http://fedoraproject.org/wiki/Releases/7 I found a general outline of >> what is supposed to happen, but not a lot of explanation about what >> each step means or what is required for a particular milestone to be >> considered finished... in other words, "what exactly does String >> Freeze mean?" Since we're at it, let me remind all developers of Fedora software: ### String freeze is 5 days away! (19/3) ### * Please add any translatable strings in your apps until then. * Make sure everything that should be translated is marked so (eg. gettext'ed). > This shouldnt be part of a schedule. The schedule assumes that everyone > involved knows what a string freeze means. If that requires explanation > the schedule can link to the developers guide. > > http://fedora.redhat.com/docs/developers-guide/ If we need to *also* put it on the Schedule for developers to know about it, then we should do that. Especially since this is the first time we are introducing some strange vocabulary that marks important dates. I've stepped forward and added Bill's definitions (slightly changed) on the schedule page. Please correct anything if needed. > The developer's guide needs to be updated to take into account current > practices. +1 on this. -d -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- From skvidal at linux.duke.edu Wed Mar 14 04:36:24 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 14 Mar 2007 00:36:24 -0400 Subject: perl, perl-devel, and missing config.h In-Reply-To: References: <1173734481.20424.47.camel@cutter> Message-ID: <1173846984.20424.121.camel@cutter> On Tue, 2007-03-13 at 15:22 -0400, Robin Norwood wrote: > seth vidal writes: > > > On Fri, 2007-03-09 at 14:44 -0500, Robin Norwood wrote: > >> Robin Norwood writes: > >> > >> [...] > >> > >> > Spot, Jesse Keating, and I have discussed the issue via email and on > >> > fedora-perl-devel-list[3] - the three of us think this solution is the > >> > right way to go, but several people on the list disagree. So we're > >> > going to hash things out there and decide what to do. If you want to > >> > follow the discussion, see fedora-perl-devel-list. Otherwise, stay > >> > tuned, and we'll keep you posted. > >> > >> An update: it looks like we'll be able to go with the perl-devel split. > >> I've just built perl-5.8.8-15, which continues the work to split > >> perl/perl-devel. Right now 'perl' requires 'perl-devel', but we hope to > >> fix that soon. > >> > > > > I added a patch to the bug you opened. Anyone who can check it, please > > do so. I think it's the right path toward being fixed. > > Thanks, Seth! > > The patch works fine for me, as we discussed - here's the bug, for those > playing at home: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231549 > okay, good, it's checked in and I'm going to release 3.0.5 very shortly, I'll close the bug. thanks, -sv From michel.salim at gmail.com Wed Mar 14 04:42:03 2007 From: michel.salim at gmail.com (Michel Salim) Date: Wed, 14 Mar 2007 00:42:03 -0400 Subject: speed of yum depsolver In-Reply-To: <76e72f800703122245g27c445ddg1b57a9020ae5efa5@mail.gmail.com> References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> <20070312161310.GA27101@redhat.com> <1173716340.20424.31.camel@cutter> <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> <76e72f800703122245g27c445ddg1b57a9020ae5efa5@mail.gmail.com> Message-ID: <883cfe6d0703132142s49b0be4dvc090f6e3246fba26@mail.gmail.com> 2007/3/13, Yuan Yijun : > I noticed that when yum find deps for package A, not only A but also > B, C, .... all packages will be checked for deps again, including(?) > system installed ones. It is very slow to run "yum update" on which > ~300 packages have updates. This slow only happens with "yum update", > while "yum install" a specific package is very fast. This is strange, > has it been fixed? > A workaround is to split the update run: yum update a\* yum update b\* ... until the depsolver is improved. -- Michel Salim http://hircus.wordpress.com/ From poelstra at redhat.com Wed Mar 14 05:24:37 2007 From: poelstra at redhat.com (John Poelstra) Date: Tue, 13 Mar 2007 22:24:37 -0700 Subject: Fedora scheduling made easy In-Reply-To: <45F6FCA0.7080207@fedoraproject.org> References: <45F6DB74.7070808@redhat.com> <45F6FCA0.7080207@fedoraproject.org> Message-ID: <45F78715.5060500@redhat.com> Rahul Sundaram wrote: > John Poelstra wrote: >> >> In this post >> https://www.redhat.com/archives/fedora-devel-list/2007-March/msg00341.html >> >> Jeremy makes a good point about being able to scale and holding to our >> schedules. I believe the Fedora project can scale successfully with >> detailed schedules and more information about what happens in each >> step. I've created a new framework (contrasted with the existing >> schedule) and taken a few liberties at guessing at a few additional >> milestones that might be useful: >> https://poelcat.108.redhat.com/nonav/fedora/schedules/fc7/fc7-sched.png. >> Additional steps can easily be added. >> >> As I went through the Fedora schedule here: >> http://fedoraproject.org/wiki/Releases/7 I found a general outline of >> what is supposed to happen, but not a lot of explanation about what >> each step means or what is required for a particular milestone to be >> considered finished... in other words, "what exactly does String >> Freeze mean?" > > This shouldnt be part of a schedule. The schedule assumes that everyone > involved knows what a string freeze means. If that requires explanation > the schedule can link to the developers guide. This is where we fall short if we hope to scale and bring new people in. We have to focus on making it easier for those that do not include "everyone involved" to learn so they can be more involved. The schedule should "assume" nothing. If we use a term we should provide a direct reference to what it means. In the previous thread on what must happen at string freeze "everyone involved" was not in agreement. Part of having a more detailed schedule helps not "everyone involved" to have a better idea of what steps go into getting a distribution ready for release and how much work it is. I'm curious myself... reading the current schedule: 1) what happens between 3-may-07 and 24-may-07 and why do we have to wait so long ;-)? 2) if certain things take a fixed amount of time (e.g. syncing the mirrors, composing the ISOs, etc.) what is the impact if they are delayed by a preceding step? Maybe that motivates me to start testing earlier or helps me to understand when the release overall is delayed. John From gauret at free.fr Wed Mar 14 06:50:48 2007 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 14 Mar 2007 07:50:48 +0100 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files References: <20070313093842.GA21675@localhost> <45F729FE.1080508@olen.net> Message-ID: Ola Thoresen wrote: > Now, I don't speak python fluently, but as far as I can tell, the script > will simply continue after the "diff" is run? > Would it be more intuitive if it would ask again if it should keep or > replace after the diff is shown? That's what it's supposed to do. Just try it, you'll see. I've updated the packages too, so just install http://gauret.free.fr/fichiers/rpms/fedora/yum-merge-conf/yum-merge-conf-1.0-1.noarch.rpm Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr A: Because we read from top to bottom, left to right. Q: Why should i start my reply below the quoted text ? From buildsys at fedoraproject.org Wed Mar 14 08:22:51 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 14 Mar 2007 04:22:51 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-14 Message-ID: <20070314082251.81724152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 52 Inventor-2.1.5-26.fc7 Pound-2.2.7-1.fc7 NEW SILLY-0.1.0-2.fc7 bit-0.4.1-1.fc7 bitgtkmm-0.4.0-2.fc7 NEW checkstyle-4.1-4jpp.1.fc7 conexus-0.5.3-1.fc7 conexusmm-0.5.0-3.fc7 dbmail-2.2.4-1.fc7 eggdrop-1.6.18-7.fc7 NEW gdal-1.4.0-10.fc7 git-1.5.0.3-1.fc7 gnomesword-2.2.2.1-5.fc7 gnu-smalltalk-2.3.3-4.fc7 NEW gnucash-2.0.5-3.fc7 NEW gnucash-docs-2.0.1-2.fc7 NEW gtkhtml38-3.12.3-3.fc7 incron-0.5.5-1.fc7 iverilog-0.9.20070227-1.fc7 jd-1.8.8-0.1.cvs070313.fc7 NEW jline-0.9.9-1jpp.1.fc7 libsmbios-0.13.4-1.fc7 NEW maven-doxia-1.0-0.1.a7.3jpp.1.fc7 NEW maven-jxr-1.0-2jpp.1.fc7 NEW maven-surefire-1.5.3-2jpp.1.fc7 mod_security-2.1.0-1.fc7 nfswatch-4.99.8-1.fc7 NEW perl-Devel-Caller-0.11-1.fc7 perl-Kwiki-0.39-1.fc7 NEW perl-Module-Compile-0.20-1.fc7 NEW php-pear-Crypt-CHAP-1.0.0-2.fc7 php-pear-Image-Graph-0.7.2-2.fc7 php-pear-MDB2-2.4.0-1.fc7 php-pear-MDB2-Driver-mysql-1.4.0-1.fc7 php-pear-Structures-DataGrid-0.8.2-1.fc7 php-pear-Structures-DataGrid-DataSource-MDB2-0.1.8-1.fc7 NEW plexus-ant-factory-1.0-0.1.a1.2jpp.1.fc7 NEW plexus-appserver-1.0-0.1.a5.3jpp.1.fc7 NEW plexus-bsh-factory-1.0-0.1.a7s.2jpp.1.fc7 NEW plexus-interactivity-1.0-0.1.a5.2jpp.2.fc7 NEW plexus-xmlrpc-1.0-0.1.b4.3jpp.3.fc7 NEW python-daap-0.7-2.fc7 python-sqlite2-2.3.3-1.fc7 NEW rhino-1.6-0.1.r5.1jpp.1.fc7 sabayon-2.18.0-1.fc7 sqlgrey-1.7.5-1.fc7 srecord-1.29-1.fc7 svrcore-4.0.4-1.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.2985.fc7 NEW tibetan-machine-uni-fonts-1.0-1.fc7 torque-2.1.8-1.fc7 NEW xml-commons-apis12-1.2.04-0jpp.2.fc7 Packages built and released for Fedora Extras 6: 29 NEW SILLY-0.1.0-2.fc6 bit-0.4.1-1.fc6 bitgtkmm-0.4.0-2.fc6 conexus-0.5.3-1.fc6 conexusmm-0.5.0-3.fc6 dbmail-2.2.4-1.fc6 digikamimageplugins-0.9.1-1.fc6 eggdrop-1.6.18-7.fc6 git-1.5.0.3-1.fc6 gnu-smalltalk-2.3.3-4.fc6 incron-0.5.5-1.fc6 iverilog-0.9.20070227-1.fc6 kmymoney2-0.8.6-1.fc6 NEW libsmbios-0.13.4-1.fc6 nfswatch-4.99.8-1.fc6 NEW perl-Devel-Caller-0.11-1.fc6 NEW perl-Module-Compile-0.20-1.fc6 NEW php-pear-Crypt-CHAP-1.0.0-2.fc6 php-pear-Image-Graph-0.7.2-2.fc6 php-pear-MDB2-2.4.0-1.fc6 php-pear-MDB2-Driver-mysql-1.4.0-1.fc6 php-pear-Structures-DataGrid-0.8.2-1.fc6 php-pear-Structures-DataGrid-DataSource-MDB2-0.1.8-1.fc6 NEW python-daap-0.7-2.fc6 python-sqlite2-2.3.3-1.fc6 srecord-1.29-1.fc6 svrcore-4.0.4-1.fc6 NEW tibetan-machine-uni-fonts-1.0-1.fc6 torque-2.1.8-1.fc6 Packages built and released for Fedora Extras 5: 22 NEW SILLY-0.1.0-2.fc5 dbmail-2.2.4-1.fc5 digikamimageplugins-0.9.1-1.fc5 eggdrop-1.6.18-7.fc5 git-1.5.0.3-1.fc5 gnu-smalltalk-2.3.3-4.fc5 incron-0.5.5-1.fc5 iverilog-0.9.20070227-1.fc5 kmymoney2-0.8.6-1.fc5 nfswatch-4.99.8-1.fc5 NEW perl-Devel-Caller-0.11-1.fc5 NEW perl-Module-Compile-0.20-1.fc5 NEW php-pear-Crypt-CHAP-1.0.0-2.fc5 php-pear-Image-Graph-0.7.2-2.fc5 php-pear-MDB2-2.4.0-1.fc5 php-pear-MDB2-Driver-mysql-1.4.0-1.fc5 php-pear-Structures-DataGrid-0.8.2-1.fc5 php-pear-Structures-DataGrid-DataSource-MDB2-0.1.8-1.fc5 python-sqlite2-2.3.3-1.fc5 srecord-1.29-1.fc5 svrcore-4.0.4-1.fc5 NEW tibetan-machine-uni-fonts-1.0-1.fc5 bit-0.4.1-1.fc7 --------------- * Tue Mar 13 2007 Rick L Vinyard Jr - 0.4.1-1 - New release bitgtkmm-0.4.0-2.fc7 -------------------- * Tue Mar 13 2007 Rick L Vinyard Jr - 0.4.0-2 - Rebuild against bit 0.4.1 checkstyle-4.1-4jpp.1.fc7 ------------------------- * Sat Feb 24 2007 Deepak Bhole - 0:4.1-4jpp.1 - Update per Fedora spec - Removed emma and excalibur-avalon-logkit dependencies conexus-0.5.3-1.fc7 ------------------- * Tue Mar 13 2007 Rick L Vinyard Jr - 0.5.3-1 - New release conexusmm-0.5.0-3.fc7 --------------------- * Tue Mar 13 2007 Rick L Vinyard Jr - 0.5.0-3 - Bump release... didn't make new-sources * Tue Mar 13 2007 Rick L Vinyard Jr - 0.5.0-2 - Rebuild against conexus 0.5.3 dbmail-2.2.4-1.fc7 ------------------ * Tue Mar 13 2007 Bernard Johnson 2.2.4-1 - v. 2.2.4 - remove umask patch as it's included upstream now * Wed Feb 28 2007 Bernard Johnson 2.2.3-1 - v. 2.2.3 - tab removal in dbmail.conf no longer required - libsqlite.so in not built anymore unless specified, remove fix - libauth-ldap.so wasn't be built properly, fixed - rework umask patch, still want a stronger umask on log files eggdrop-1.6.18-7.fc7 -------------------- * Tue Mar 13 2007 Robert Scheck 1.6.18-7 - Rebuild for bind 9.4.0 gdal-1.4.0-10.fc7 ----------------- * Thu Mar 01 2007 Balint Cristian 1.4.0-10 - fix mock build - require perl-devel * Tue Feb 27 2007 Balint Cristian 1.4.0-9 - repack tarball for fedora, explain changes in PROVENANCE-fedora, license should be clean now according to PROVENANCE-* files - require ogdi since is aviable now - drop nogeotiff patch, in -fedora tarball geotiff is removed - man page triage over subpackages - exclude python byte compiled objects - fix some source C file exec bits * Sat Feb 24 2007 Balint Cristian 1.4.0-8 - fix more things in spec - include more docs * Wed Feb 21 2007 Balint Cristian 1.4.0-7 - libtool in requirement list for build * Wed Feb 21 2007 Balint Cristian 1.4.0-6 - use external libtool to avoid rpath usage - include more docs * Mon Feb 12 2007 Balint Cristian 1.4.0-5 - use rm -rf for removal of dirs. - fix require lists * Mon Feb 12 2007 Balint Cristian 1.4.0-4 - fix doxygen buildreq - make sure r-path is fine. git-1.5.0.3-1.fc7 ----------------- * Tue Mar 13 2007 Chris Wright 1.5.0.3-1 - git-1.5.0.3 gnomesword-2.2.2.1-5.fc7 ------------------------ * Tue Mar 13 2007 Deji Akingunola - 2.2.2.1-5 - Tweak configure script to allow building with newer gtkhml3 * Tue Mar 13 2007 Deji Akingunola - 2.2.2.1-4 - Another rebuild for gtkhtml * Wed Feb 28 2007 Deji Akingunola - 2.2.2.1-3 - Rebuild for new gtkhtml gnu-smalltalk-2.3.3-4.fc7 ------------------------- * Tue Mar 13 2007 Jochen Schmitt 2.3.3-4 - Fix wrong paths in gst.im gnucash-2.0.5-3.fc7 ------------------- * Tue Mar 13 2007 Bill Nottingham - 2.0.5-3 - require gtkhtml38 include file to pull in the proper gtkhtml version - fix build when libofx and ofx tools are separate * Mon Feb 19 2007 Bill Nottingham - 2.0.5-1 - update to 2.0.5 - fixes: CVE-2007-0007 (#223233) * Tue Feb 13 2007 Bill Nottingham - 2.0.4-5 - split off docs package gnucash-docs-2.0.1-2.fc7 ------------------------ * Tue Feb 13 2007 Bill Nottingham - 2.0.1-2 - move yelp requirement from gnucash to here gtkhtml38-3.12.3-3.fc7 ---------------------- * Mon Mar 12 2007 Bill Nottingham - 3.12.3-3 - remove extraneous rm as noted per review * Tue Feb 27 2007 Bill Nottingham - 3.12.3-2 - repackage as gtkhtml38 incron-0.5.5-1.fc7 ------------------ * Tue Mar 13 2007 0.5.5-1 - Sync with upstream Inventor-2.1.5-26.fc7 --------------------- * Wed Mar 14 2007 Ralf Cors?pius - 2.1.5-26 - Use dejavu-fonts as fonts. - Attempt to fix BZ 232017. iverilog-0.9.20070227-1.fc7 --------------------------- * Tue Feb 27 2007 Balint Cristian 0.9.20070227-1 - new snapshoot release. jd-1.8.8-0.1.cvs070313.fc7 -------------------------- * Tue Mar 13 2007 Mamoru Tasaka - 1.8.8-0.1.cvs070313 - cvs 070313 (23:30 JST) jline-0.9.9-1jpp.1.fc7 ---------------------- * Tue Mar 06 2007 Matt Wringe - 0:0.9.9-1jpp.1 - Add option to build with ant. - Fix various rpmlint issues - Specify proper license libsmbios-0.13.4-1.fc7 ---------------------- * Mon Mar 12 2007 Michael E Brown - 0.13.4-1 - Added dellWirelessCtl binary - Added 'static' makefile target to build static binaries and clean them as well - fix for signed/unsigned bug in probes binary. CPU temp misreported - simplify interface for DELL_CALLING_INTERFACE_SMI, autodetect Port/Magic - document all of the tokens for controlling wireless on dell notebooks - enums for SMI args/res to make code match docs better (cbRES1 = res[0], which was confusing. - helper functions isTokenActive() and activateToken() to simplify token API. - Added missing windows .cpp files to the dist tarball for those who compile windows from dist tarball vs source control - Add support for EFI based machines without backwards compatible smbios table entry point in 0xF0000 block. - Added wirelessSwitchControl() and wirelessRadioControl() API for newer laptops. - fixed bug in TokenDA activate() code where it wasnt properly using SMI (never worked, but apparently wasnt used until now.) maven-doxia-1.0-0.1.a7.3jpp.1.fc7 --------------------------------- * Tue Feb 27 2007 Tania Bento 0:1.0-0.1.a7.3jpp.1 - Fixed %Release. - Fixed %BuildRoot. - Removed %Vendor. - Removed %Distribution. - Removed %post and %postun sections for javadoc. - Fixed instructios on how to generate source drop. - Fixed %Summary. - Added gcj support option. - Marked configuration file as %config(noreplace) in %files section. maven-jxr-1.0-2jpp.1.fc7 ------------------------ * Tue Feb 27 2007 Tania Bento 0:1.0-2jpp.1 - Fixed %Release. - Fixed %BuildRoot. - Removed period from %Summary. - Removed %Vendor. - Removed %Distribution. - Removed %post and %postun sections for javadoc. - Added gcj support option. - Fixed instructions on how to generate source drops. maven-surefire-1.5.3-2jpp.1.fc7 ------------------------------- * Mon Feb 26 2007 Tania Bento 0:1.5.3-2jpp.1 - Fixed %Release. - Fixed %BuildRoot. - Removed %Vendor. - Removed %Distribution. - Removed period at the end of %Summary. - Removed %post and %postun sections for javadoc. - Removed %post and %postun sections for booter-javadoc. - Added gcj support option. - Fixed instructions on how to generate source drop. mod_security-2.1.0-1.fc7 ------------------------ * Tue Mar 13 2007 Michael Fleming 2.1.0-1 - New major release - 2.1.0 - Fix CVE-2007-1359 with a local rule courtesy of Ivan Ristic - Addition of core ruleset - (Build)Requires libxml2 and pcre added. nfswatch-4.99.8-1.fc7 --------------------- * Tue Mar 13 2007 Christian Iseli 4.99.8-1 - new upstream version - Set Source0 according to Packaging/SourceURL perl-Devel-Caller-0.11-1.fc7 ---------------------------- perl-Kwiki-0.39-1.fc7 --------------------- * Tue Mar 13 2007 Steven Pritchard 0.39-1 - Update to 0.39. - Use fixperms macro instead of our own chmod incantation. - BR ExtUtils::MakeMaker. perl-Module-Compile-0.20-1.fc7 ------------------------------ php-pear-Crypt-CHAP-1.0.0-2.fc7 ------------------------------- * Tue Mar 13 2007 Christopher Stone 1.0.0-2 - Apply patch to fix warnings/errors on test scripts (bz #222597) php-pear-Image-Graph-0.7.2-2.fc7 -------------------------------- * Tue Mar 13 2007 Christopher Stone 0.7.2-2 - Make subpackages for optional pear packages php-pear-MDB2-2.4.0-1.fc7 ------------------------- * Tue Mar 13 2007 Christopher Stone 2.4.0-1 - Upstream sync php-pear-MDB2-Driver-mysql-1.4.0-1.fc7 -------------------------------------- * Tue Mar 13 2007 Christopher Stone 1.4.0-1 - Upstream sync php-pear-Structures-DataGrid-0.8.2-1.fc7 ---------------------------------------- * Tue Mar 13 2007 Christopher Stone 0.8.2-1 - Upstream sync - Shorten Summary php-pear-Structures-DataGrid-DataSource-MDB2-0.1.8-1.fc7 -------------------------------------------------------- * Tue Mar 13 2007 Christopher Stone 0.1.8-1 - Upstream sync plexus-ant-factory-1.0-0.1.a1.2jpp.1.fc7 ---------------------------------------- * Fri Feb 23 2007 Tania Bento 0:1.0-0.1.a1.2jpp.1 - Fixed %Release. - Fixed %BuildRoot. - Removed %Vendor. - Removed %Distribution. - Removed %post and %postun sections for javadoc. - Defined _with_gcj_supoprt and _gcj_support. - Changed to use cp -p to preserve timestamps. plexus-appserver-1.0-0.1.a5.3jpp.1.fc7 -------------------------------------- * Tue Feb 20 2007 Tania Bento 0:1.0-0.1.a5.3jpp.1 - Fixed %Release. - Fixed %License. - Fixed instructions on how to generate the source drop. - Fixed %BuildRoot. - Removed %Vendor. - Removed %Distribution. - Removed %post and %postun for javadoc. - Added gcj support option. plexus-bsh-factory-1.0-0.1.a7s.2jpp.1.fc7 ----------------------------------------- * Fri Feb 23 2007 Tania Bento 0:1.0-0.1.a7s.2jpp.1 - Fixed %Release. - Fixed %BuildRoot. - Fixed %Vendor. - Fixed %Distribution. - Fixed instructions on how to generate source drop. - Removed %post and %postun sections for javadoc. - Made sure lines had less than 80 characters. - Changed to use cp -p to preserve timestamps. plexus-interactivity-1.0-0.1.a5.2jpp.2.fc7 ------------------------------------------ * Tue Mar 13 2007 Matt Wringe 1.0-0.1.a5.2jpp.2 - Add missing build requires for ant-nodeps * Fri Feb 16 2007 Andrew Overholt 1.0-0.1.a5.2jpp.1 - Remove javadoc symlinking plexus-xmlrpc-1.0-0.1.b4.3jpp.3.fc7 ----------------------------------- * Tue Mar 13 2007 Deepak Bhole 1.0-0.1.b4.3jpp.3 - rebuild * Tue Mar 13 2007 Deepak Bhole 1.0-0.1.b4.3jpp.2 - Fixing typo in a Requires. * Mon Feb 19 2007 Tania Bento 0:1.0-0.1.b4.3jpp.1 - Fixed %Release. - Fixed %BuildRoot. - Marked LICENSE.txt as %doc. - Removed %Vendor. - Removed %Distribution. - Removed %post and %postun for javadoc. - Added gcj support option. Pound-2.2.7-1.fc7 ----------------- * Mon Mar 12 2007 2.2.7-1 - Sync with upstream python-daap-0.7-2.fc7 --------------------- * Tue Mar 13 2007 Jeffrey C. Ollie - 0.7-2 - Make sure updated spec gets published. - Include PKG-INFO * Mon Mar 12 2007 Jeffrey C. Ollie - 0.7-1 - Update to 0.7 - Use LICENSE file from tarball * Mon Mar 12 2007 Jeffrey C. Ollie - 0.6-1 - Update to 0.6 * Mon Feb 12 2007 Jeffrey C. Ollie - 0.5-2 - Drop "A " from the summary - Use "install -m 0644" instead of "cp". * Mon Feb 12 2007 Jeffrey C. Ollie - 0.5-1 - Update to 0.5 python-sqlite2-2.3.3-1.fc7 -------------------------- * Tue Mar 13 2007 Dawid Gajownik - 1:2.3.3-1 - Update to 2.3.3 (#231848) rhino-1.6-0.1.r5.1jpp.1.fc7 --------------------------- * Wed Mar 07 2007 Deepak Bhole 0:1.6-0.1.r5.1jpp.1 - Upgrade to 1.6r5 - Change release per Fedora guidelines - Disable dependency on xmlbeans (optional component, not in Fedora yet) - Disable building of debugger tool, as it needs confidential code from Sun - Remove post/postuns for javadoc and add the two dirs as %doc sabayon-2.18.0-1.fc7 -------------------- * Tue Mar 13 2007 Alexander Larsson - 2.18.0-1 - Update to 2.18.0 SILLY-0.1.0-2.fc7 ----------------- * Sun Mar 11 2007 Ian Chapman 0.1.0-2.fc7 - Preserve timestamps on install - Changed source URL - Improved sed replacements - Changed encoding of AUTHORS to UTF-8 * Mon Feb 26 2007 Ian Chapman 0.1.0-1.fc7 - Initial Release sqlgrey-1.7.5-1.fc7 ------------------- * Mon Mar 12 2007 Steven Pritchard 1.7.5-1 - Update to 1.7.5 - Drop fedora-usermgmt requirement - Don't remove the sqlgrey user on uninstall srecord-1.29-1.fc7 ------------------ * Tue Mar 13 2007 Jose Pedro Oliveira - 1.29-1 - Update to 1.29. svrcore-4.0.4-1.fc7 ------------------- * Tue Mar 13 2007 Rich Megginson - 4.0.4-1 - Removed some autoconf generated files which were GPL only - all - code needs to be tri-licensed - updated version to 4.0.4 - added empty COPYING file - do not use the one generated by autoreconf - use bz2 for source tarball instead of gz sysprof-kmod-1.0.8-1.2.6.20_1.2985.fc7 -------------------------------------- tibetan-machine-uni-fonts-1.0-1.fc7 ----------------------------------- * Mon Mar 12 2007 Marcin Garski 1.0-1 - Initial specfile torque-2.1.8-1.fc7 ------------------ * Tue Mar 13 2007 Garrick Staples 2.1.8-1 - bump to 2.1.8 - ensure daemons have the correct path to sendmail - don't need rpath configure patch anymore xml-commons-apis12-1.2.04-0jpp.2.fc7 ------------------------------------ * Tue Mar 13 2007 Matt Wringe - 0:1.2.04-0jpp.2 - Enable gcj option * Fri Feb 16 2007 Matt Wringe - 0:1.2.04-0jpp.1 - Initial build. Based heavily on the xml-commons 1.3.03-7jpp spec file. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora at leemhuis.info Wed Mar 14 08:32:05 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 14 Mar 2007 09:32:05 +0100 Subject: FYI: The Fedora Extras Package Build Reports go to fedora-devel now In-Reply-To: <20070314082251.81724152131@buildsys.fedoraproject.org> References: <20070314082251.81724152131@buildsys.fedoraproject.org> Message-ID: <45F7B305.4070305@leemhuis.info> Hi! On 14.03.2007 09:22, buildsys at fedoraproject.org wrote: > Packages built and released for Fedora Extras development: 52 > [...] Just FYI, those reports were send to fedora-extras-list in the past but from now on will get send to fedora-devel as the plan is to close fedora-extras-list soon (see the thread https://www.redhat.com/archives/fedora-extras-list/2007-March/msg00004.html for details). The Reply-to for fedora-extras-commits points to fedora-devel now, too. CU thl From jonesc at hep.phy.cam.ac.uk Wed Mar 14 13:59:00 2007 From: jonesc at hep.phy.cam.ac.uk (Chris Jones) Date: Wed, 14 Mar 2007 13:59:00 +0000 Subject: Problem with /sbin/weak-modules In-Reply-To: <45F43246.2090503@redhat.com> References: <200703110935.29639.jonesc@hep.phy.cam.ac.uk> <45F430F1.6050406@redhat.com> <45F43246.2090503@redhat.com> Message-ID: <200703141359.00670.jonesc@hep.phy.cam.ac.uk> Hi, > Oh, I see what's happening: > > * You didn't upgrade to a newer kernel module, but expected weak-modules > to make a symlink. > > * weak-modules logic has broken with the change in kernel numbering. > > Correct? Not sure what you mean by that first bullet point, but the second seems correct from my experience. The core problem seems to be when /sbin/weak-modules was used in the creation of a kmod package for kernel XXX.6.5, it was for some reason creating in the rpm symlinks to files for kernel XXX.6.4. Presumably on the build machine this was not noticed, as both kernels and kmod packages existed so the sym link was valid, but on my machine it was not so I noticed. > > If this is all that's at fault, it's probably a simple logic problem > that I can fix tomorrow when I get a chance to look at it - but if you > think I should know anything else, drop me a line. No, that seems about it. I took a look at the script and concluded it was probably just some logic going wrong, but I had no how to fix it. cheers Chris From pvrabec at redhat.com Wed Mar 14 14:19:44 2007 From: pvrabec at redhat.com (Peter Vrabec) Date: Wed, 14 Mar 2007 15:19:44 +0100 Subject: with or without fedora-usermgmt Message-ID: <20070314151944.46717aa0@wrabco.brq.redhat.com> Hi folks, Don't you think somebody should make some decision here: http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00124.html - flame, but possible pros and cons can be find there My opinion is not to use fedora-usermgmt. Note there is possible problem we can reach. We can ran out of static UID(0-100), can't we. ---------- # (repoquery --whatrequires shadow-utils; repoquery --whatrequires /usr/sbin/useradd --whatrequires fedora-usermgmt) | sed 's/-[[:digit:]].*//' | sort -u | wc -l 100 ---------- I think most packages should use dynamic UID (range 100 - 499) and there should be some policy for which packages are allowed to have static UID. I have a patch for useradd and groupadd that they start assigning dynamic UID from 499 way down to 0. What is it good for? Maybe for nothing. :-) But if we run out of static UID one day, it would be good to have gap between static and dynamic UID. We will have to change the range of static ones for example to 0-200 and there is a problem(100-200) during upgrade. Less systems affected with this is better, even thou the solution need to be find. And maybe I'm wrong, anyway. From ml at deadbabylon.de Wed Mar 14 14:34:17 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 14 Mar 2007 15:34:17 +0100 Subject: KDE-Live-CD: basic cd layout and localizations In-Reply-To: <20070314011000.5b0cbcb8@localhost.localdomain> References: <20070314011000.5b0cbcb8@localhost.localdomain> Message-ID: <20070314153417.43621026@localhost.localdomain> Am Wed, 14 Mar 2007 01:10:00 +0100 schrieb Sebastian Vahl : > Hi. > > I've created a new basic layout for the cd: > http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/KDELiveCD > The size on todays rawhide is about 667 MB. > Please tell me which package should be added or removed. > > > On todays KDE-SIG-Meeting Rex Dieter and Kevin Kofler suggested to > give the local communities the ability to create their own localized > cds easily. To do this there should be an extra configuration file > for each language which adds the needed packages and do some > configurations. And also the additional language must fit on one cd. > A second option for localized versions could (or should?) be a > live-dvd with all available language packages. livecd-creator in git > seems to be able to do this (but I haven't checked this yet). [1] > > I've created a first draft for an configuration for the german > language. This adds kde-i18n-de and koffice-langpack-de to the cd. > Also the standard keyboard layout, the local timezone and the locale > is changed. To change the keyboard layout inside kde I've used an ugly > workaround.[2] > If anybody knows a better way, please tell me. :) > Compared to the version above this one needs ~675 MB. > > > To create the configuration files for different languages I need some > informations from one person that uses the language: > 1. /etc/sysconfig/i18n > 2. /etc/sysconfig/keyboard > 3. /etc/sysconfig/clock > 4. keybordtype from "system-config-keyboard --help" > 5. needed additional packages (eg. scim-* or fonts-*) > > > And of course all are invited to discuss this. :) > > Sebastian > > > > > [1] http://git.fedoraproject.org/?p=hosted/livecd > [2] > http://www.deadbabylon.de/fedora/livecd/source/50-fedora-livecd-kde-german.conf > > ######### > > How to create the live cd: > > Install livecd-tools: > > wget > "http://people.redhat.com/~katzj/live/f7test2/livecd-tools-001-3.fc7.i386.rpm" > rpm -ivh livecd-tools-001-3.fc7.i386.rpm > > Create the spin: > > livecd-creator \ > --repo=c7,http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/ > \ > --repo=e7,http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ > \ > --repo=lcd7,http://www.deadbabylon.de/fedora/livecd/i386/ \ > --package=fedora-livecd-kde \ > --fslabel=Fedora-7-Test2-KDE > > > To create the german version: > > livecd-creator \ > --repo=c7,http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/ > \ > --repo=e7,http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ > \ > --repo=lcd7,http://www.deadbabylon.de/fedora/livecd/i386/ \ > --package=fedora-livecd-kde-german \ > --fslabel=Fedora-7-Test2-KDE-German It seems it was a little bit late yesterday evening. Some corrections: 1. added system-config-display to 20-fedora-livecd-kde.conf (used to setup X) 2. workaround for keyboardtype in kde works now 3. removed krusader to free some space for localizations (new size of basic layout is about 657 MB). 4. included 30-fedora-livecd-kde-dvd.conf is just a draft and not testet yet. RPMs and wiki are updated. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From oliver at linux-kernel.at Wed Mar 14 15:03:42 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 14 Mar 2007 16:03:42 +0100 Subject: dead packages in cvs, missing dist-tags and copyright tag Message-ID: <45F80ECE.6000402@linux-kernel.at> Hi! Are dead packages in core cvs not marked as dead? Like it is in extras... However, a lot of packages are still missing dist tag and some still use the Copyright tag. I can only guess, that packages with Copyright tag are dead. And another issue, some packages have %{dist} instead of %{?dist}. Simple script to check the packages that miss the (correct) dist tag: for i in */*.spec; do if [ "`grep "^Release:" $i|grep -v "%{?dist}"`" != "" ]; then echo -n `rpm -q --specfile $i --qf "%{name} %{version}-%{release}\n"|head -1` echo " - last cl entry: `rpm -q --specfile $i --changelog|head -1`"; fi done Easily adaptable for the Copyright tag, for course... -of From notting at redhat.com Wed Mar 14 15:42:20 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 14 Mar 2007 11:42:20 -0400 Subject: dead packages in cvs, missing dist-tags and copyright tag In-Reply-To: <45F80ECE.6000402@linux-kernel.at> References: <45F80ECE.6000402@linux-kernel.at> Message-ID: <20070314154220.GB18364@nostromo.devel.redhat.com> Oliver Falk (oliver at linux-kernel.at) said: > Are dead packages in core cvs not marked as dead? Like it is in extras... Right. As we're only migrating the things we're actually currently building, this should sort itself out. Bill From notting at redhat.com Wed Mar 14 15:43:51 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 14 Mar 2007 11:43:51 -0400 Subject: with or without fedora-usermgmt In-Reply-To: <20070314151944.46717aa0@wrabco.brq.redhat.com> References: <20070314151944.46717aa0@wrabco.brq.redhat.com> Message-ID: <20070314154351.GC18364@nostromo.devel.redhat.com> Peter Vrabec (pvrabec at redhat.com) said: > Don't you think somebody should make some decision here: > http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00124.html > - flame, but possible pros and cons can be find there > My opinion is not to use fedora-usermgmt. My proposal is to use 100-499 for static as well, and just do static registrations for everything - it's simpler. It can be combined with making dynamic system IDs go from 499 down as well. Bill From mattdm at mattdm.org Wed Mar 14 17:23:23 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 14 Mar 2007 13:23:23 -0400 Subject: with or without fedora-usermgmt In-Reply-To: <20070314154351.GC18364@nostromo.devel.redhat.com> References: <20070314151944.46717aa0@wrabco.brq.redhat.com> <20070314154351.GC18364@nostromo.devel.redhat.com> Message-ID: <20070314172323.GA9684@jadzia.bu.edu> On Wed, Mar 14, 2007 at 11:43:51AM -0400, Bill Nottingham wrote: > > Don't you think somebody should make some decision here: > > http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00124.html > > - flame, but possible pros and cons can be find there > > My opinion is not to use fedora-usermgmt. > My proposal is to use 100-499 for static as well, and just do static > registrations for everything - it's simpler. It can be combined with > making dynamic system IDs go from 499 down as well. Yes. Further, I think we should exercise a little caution with the < 100 assignments and only fill that space with things that have a proven track record and are likely to be around and useful for a while. Not, say, random games. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jwilson at redhat.com Wed Mar 14 17:26:49 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 14 Mar 2007 13:26:49 -0400 Subject: with or without fedora-usermgmt In-Reply-To: <20070314172323.GA9684@jadzia.bu.edu> References: <20070314151944.46717aa0@wrabco.brq.redhat.com> <20070314154351.GC18364@nostromo.devel.redhat.com> <20070314172323.GA9684@jadzia.bu.edu> Message-ID: <45F83059.4010901@redhat.com> Matthew Miller wrote: > On Wed, Mar 14, 2007 at 11:43:51AM -0400, Bill Nottingham wrote: >>> Don't you think somebody should make some decision here: >>> http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00124.html >>> - flame, but possible pros and cons can be find there >>> My opinion is not to use fedora-usermgmt. >> My proposal is to use 100-499 for static as well, and just do static >> registrations for everything - it's simpler. It can be combined with >> making dynamic system IDs go from 499 down as well. > > Yes. > > Further, I think we should exercise a little caution with the < 100 > assignments and only fill that space with things that have a proven track > record and are likely to be around and useful for a while. Not, say, random > games. +1. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From kevin.kofler at chello.at Wed Mar 14 18:48:25 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 14 Mar 2007 18:48:25 +0000 (UTC) Subject: KDE-Live-CD: basic cd layout and localizations References: <20070314011000.5b0cbcb8@localhost.localdomain> <20070314153417.43621026@localhost.localdomain> Message-ID: Sebastian Vahl deadbabylon.de> writes: > 3. removed krusader to free some space for localizations (new size of > basic layout is about 657 MB). Isn't there enough room already? Pretty much all CD-Rs these days are 700 MB, at least around here (Austria). In fact, there are even ones with 800 MB or more, though these are more expensive and don't comply with the CD-R standard, so relying on these is probably not a good idea, but 700 MB should be fine. As for the keyboard layout for the German LiveCD, why -nodeadkeys? That makes it harder to type foreign (e.g. French) characters, and it is not what that well-known proprietary operating system uses either. Kevin Kofler From ml at deadbabylon.de Wed Mar 14 19:19:33 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 14 Mar 2007 20:19:33 +0100 Subject: KDE-Live-CD: basic cd layout and localizations In-Reply-To: References: <20070314011000.5b0cbcb8@localhost.localdomain> <20070314153417.43621026@localhost.localdomain> Message-ID: <20070314201933.3f557a58@localhost.localdomain> Am Wed, 14 Mar 2007 18:48:25 +0000 (UTC) schrieb Kevin Kofler : > Sebastian Vahl deadbabylon.de> writes: > > 3. removed krusader to free some space for localizations (new size > > of basic layout is about 657 MB). > > Isn't there enough room already? Pretty much all CD-Rs these days are > 700 MB, at least around here (Austria). In fact, there are even ones > with 800 MB or more, though these are more expensive and don't comply > with the CD-R standard, so relying on these is probably not a good > idea, but 700 MB should be fine. That's because every time I create an iso the size is different (see also [1]). The german version was between 672 Mb to 697 MB. And the german version don't need additional font packages (although kde-i18n-German ist one of the biggest). If there would be enough space after testing all languages, krusader (or other packages) could be reincluded. And I've picked krusader because there is already konqueror. I agree with you not using 800 MB CD-Rs. 700 MB should be the limit (for all languages we would support). > As for the keyboard layout for the German LiveCD, why -nodeadkeys? > That makes it harder to type foreign (e.g. French) characters, and it > is not what that well-known proprietary operating system uses either. Just because I use it myself and never had problems with it (not speaking or writing french or others). :) I will change this to de-latin1 in next version. Thanks for pointing me to this. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ml at deadbabylon.de Wed Mar 14 19:21:32 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 14 Mar 2007 20:21:32 +0100 Subject: KDE-Live-CD: basic cd layout and localizations In-Reply-To: <20070314201933.3f557a58@localhost.localdomain> References: <20070314011000.5b0cbcb8@localhost.localdomain> <20070314153417.43621026@localhost.localdomain> <20070314201933.3f557a58@localhost.localdomain> Message-ID: <20070314202132.0dfe2565@localhost.localdomain> Am Wed, 14 Mar 2007 20:19:33 +0100 schrieb Sebastian Vahl : > That's because every time I create an iso the size is different (see > also [1]). The german version was between 672 Mb to 697 MB. And the > german version don't need additional font packages (although > kde-i18n-German ist one of the biggest). If there would be enough > space after testing all languages, krusader (or other packages) could > be reincluded. And I've picked krusader because there is already > konqueror. I agree with you not using 800 MB CD-Rs. 700 MB should be > the limit (for all languages we would support). Missed the link: [1] https://www.redhat.com/archives/fedora-livecd-list/2007-March/msg00112.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gauret at free.fr Wed Mar 14 19:22:55 2007 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 14 Mar 2007 20:22:55 +0100 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files References: <20070313093842.GA21675@localhost> <45F729FE.1080508@olen.net> Message-ID: Darn, wrong link. It's : http://gauret.free.fr/fichiers/rpms/fedora/yum-merge-conf/yum-merge-conf-1.1-1.noarch.rpm for the fixed version. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr Go away or I will replace you with a very small shell script From oliver at linux-kernel.at Wed Mar 14 19:37:40 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 14 Mar 2007 20:37:40 +0100 Subject: rpms/redhat-rpm-config/devel redhat-rpm-config.spec,1.44,1.45 In-Reply-To: <200703141813.l2EIDQ3b014764@cvs.devel.redhat.com> References: <200703141813.l2EIDQ3b014764@cvs.devel.redhat.com> Message-ID: <45F84F04.5010904@linux-kernel.at> fedora-cvs-commits at redhat.com schrieb: > Author: bkonrath > > Update of /cvs/dist/rpms/redhat-rpm-config/devel > In directory cvs.devel.redhat.com:/tmp/cvs-serv14726 > > Modified Files: > redhat-rpm-config.spec > Log Message: > - Fix date problem in %changelog > > > Index: redhat-rpm-config.spec > =================================================================== > RCS file: /cvs/dist/rpms/redhat-rpm-config/devel/redhat-rpm-config.spec,v > retrieving revision 1.44 > retrieving revision 1.45 > diff -u -r1.44 -r1.45 > --- redhat-rpm-config.spec 14 Mar 2007 18:11:59 -0000 1.44 > +++ redhat-rpm-config.spec 14 Mar 2007 18:13:24 -0000 1.45 > @@ -46,7 +46,7 @@ > %{_prefix}/lib/rpm/redhat > > %changelog > -* Tue Mar 13 2006 Ben Konrath 8.0.45-13 > +* Tue Mar 13 2007 Ben Konrath 8.0.45-13 > - Update brp-java-repack-jars to fix issue with tomcat. > > * Wed Oct 18 2006 Jon Masters 8.0.45-12 > > Ben, can you also have a look at this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232101 -of From bkonrath at redhat.com Wed Mar 14 19:59:25 2007 From: bkonrath at redhat.com (Ben Konrath) Date: Wed, 14 Mar 2007 15:59:25 -0400 Subject: rpms/redhat-rpm-config/devel redhat-rpm-config.spec,1.44,1.45 In-Reply-To: <45F84F04.5010904@linux-kernel.at> References: <200703141813.l2EIDQ3b014764@cvs.devel.redhat.com> <45F84F04.5010904@linux-kernel.at> Message-ID: <1173902365.12238.0.camel@plug> On Wed, 2007-03-14 at 20:37 +0100, Oliver Falk wrote: > Ben, can you also have a look at this: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232101 Sorry, I can't. My only involvement with redhat-rpm-config is the brp-java-repack-jars script. Cheers, Ben From oliver at linux-kernel.at Wed Mar 14 20:04:19 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Wed, 14 Mar 2007 21:04:19 +0100 Subject: rpms/redhat-rpm-config/devel redhat-rpm-config.spec,1.44,1.45 In-Reply-To: <1173902365.12238.0.camel@plug> References: <200703141813.l2EIDQ3b014764@cvs.devel.redhat.com> <45F84F04.5010904@linux-kernel.at> <1173902365.12238.0.camel@plug> Message-ID: <45F85543.7050204@linux-kernel.at> Ben Konrath schrieb: > On Wed, 2007-03-14 at 20:37 +0100, Oliver Falk wrote: > >> Ben, can you also have a look at this: >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232101 >> > > Sorry, I can't. My only involvement with redhat-rpm-config is the > brp-java-repack-jars script. > > Cheers, Ben > > k. ack. thx. -of From fedora at camperquake.de Wed Mar 14 20:12:06 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 14 Mar 2007 21:12:06 +0100 Subject: KDE-Live-CD: basic cd layout and localizations In-Reply-To: References: <20070314011000.5b0cbcb8@localhost.localdomain> <20070314153417.43621026@localhost.localdomain> Message-ID: <20070314211206.3c3f9903@lain.camperquake.de> Hi. On Wed, 14 Mar 2007 18:48:25 +0000 (UTC), Kevin Kofler wrote > As for the keyboard layout for the German LiveCD, why -nodeadkeys? > That makes it harder to type foreign (e.g. French) characters, and it > is not what that well-known proprietary operating system uses either. Not using -nodeadkeys makes it harder to type characters which are special to the unix shell :) From kevin.kofler at chello.at Wed Mar 14 22:45:09 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 14 Mar 2007 22:45:09 +0000 (UTC) Subject: KDE-Live-CD: basic cd layout and localizations References: <20070314011000.5b0cbcb8@localhost.localdomain> <20070314153417.43621026@localhost.localdomain> <20070314211206.3c3f9903@lain.camperquake.de> Message-ID: Ralf Ertzinger camperquake.de> writes: > Not using -nodeadkeys makes it harder to type characters which are special > to the unix shell :) That's true (backtick and tilde require pressing that extra space), I just got used to it (writing in French relatively often, I really need working accent keys ;-) ). By the way, I was surprised at the tilde being a dead key at first because the proprietary competition doesn't do that, but it makes sense because it can be a diacritic (? mainly, but also on vowels in some languages). Kevin Kofler From lists at bes.stw-bonn.de Wed Mar 14 23:56:44 2007 From: lists at bes.stw-bonn.de (Andreas Kupfer) Date: Thu, 15 Mar 2007 00:56:44 +0100 Subject: Call for Papers FrOSCon 07 - 25+26.08.07 - St. Augustin/Germany Message-ID: <20070315005644.9b66c695.lists@bes.stw-bonn.de> FrOSCon is a two-day conference on free software and open source, which takes place on 25th and 26th August 2007 at the University of Applied Sciences Bonn-Rhein-Sieg, in St. Augustin near Bonn, Germany. Focus of the conference is a comprehensive range of talks about current topics in free software and open source. Furthermore, space will be provided for developers of free software and open source projects to organize their own developer meetings or even their own program. 2007 will see the second installment of FrOSCon. It is organized by the deparmtent of computer science in collaboration with the Linux/Unix User Group Sankt Augustin, the student body and the FrOSCon e.V. = Topics = We are looking for contributions about current developments from the whole field of Free Software and Open Source., e.g.: * Operating Systems * Development * Administration * Security * Legal Issues * Desktop * Open Hardware We would especially like to see contributions about the following topics: * Web2.0 - Free Software as the building blocks of the web revolution * Virtualization - Basics, comparison and new developments (e.g. VT/Pacifica, Linux 2.6.20, QEMU, Virtualbox etc.) * Open beyond Software - The principles of Free Software applied far from source code Furthermore we are planning a special track (in german) for beginners. We would also like to see proposals for that. = Submitting Contributions = Registration and submission of contributions is via the web-based frontend under http://cfp.froscon.org/. For participating in the Call for Papers, you will have to submit a short abstract, as well as a detailed description. To participate in the conference, you will also need to submit slides for your talk beforehand. == Language == Contributions can be submitted in German as well as English. The choice of language should depend solely on which language is more suitable for presenting the chosen topic. Language of the submitted texts and of the talk should be the same. == Length of the Contributions == The abstract should summarize the planned content of the talk in a precise and succinct way. We do not place a limit on its length. The talks should take no more than 45 minutes, in order to allow some time for questions and for preparing the stage for the following speaker. We can accept longer contributions in special cases; we ask for a justification for the longer extent in this case. == Format == Abstract and Description have to be submitted as plain text via the web frontend. We ask for submission of the slides in PDF; other open document format such as OpenOffice should only be submitted after prior consultation. == Licenses == We will publish abstract, description and slides on a website and include the abstract in the conference program. We demand that you place your contributions under the Creative Commons Attribution-NonCommercial 2.0 Germany (http://creativecommons.org/licenses/by-nc/2.0/de/) license (or a more lenient license.) Unless another license is noted, we will assume that your contribution is under this license. If you want to place your works under a less restrictive license, please note so with your submission. == Selection of Contributions == Contributions are selected based on their content by a program committee. Please understand that we cannot accept all contributions, depending on the number and quality of the submissions. We will favor submissions which fall under one of the aforementioned topics. = Other = == Remuneration == FrOSCon is organized by volunteers and is mostly funded by sponsors. We ask you to understand that we will not be able to reimburse you for your expenses. == Accomodation == The organizers of FrOSCon are looking for suitable accomodation at the moment. Current developments will be published on the web site of the event (http://www.froscon.org). We can also help find a place to sleep. == Social Event == We are planning to hold a social event on the evening of the 25th and kindly invite all speakers to attend. = Important Dates and Contacts = *June 4th, 2007 End of the Call for Papers. All contributions need to be submitted by this date in order to qualify. * June 18th, 2007 Notification of acceptance of all contributions * June 30th, 2007 Final acceptance. We ask all invited speakers to give their final acceptance by this date. *August 1st, 2007 Last date for submitting slides *August 25th, 2007 First day of FrOSCon Further information can be found on the web under http://www.froscon.org. Please send questions about the Call for Papers via email to: program at froscon.org Contact the organizers via email: contact at froscon.org Postal address: FrOSCon e.V. c/o Fachhochschule Bonn-Rhein-Sieg Grantham-Allee 20 53757 Sankt Augustin Germany From tjb at unh.edu Thu Mar 15 00:12:44 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Wed, 14 Mar 2007 20:12:44 -0400 Subject: RANDR 1.2 heads up In-Reply-To: <20070312153500.GA10302@redhat.com> References: <1173136781.9948.22.camel@localhost.localdomain> <20070308092717.6dd893d2@banea.int.addix.net> <20070308131635.GA18472@redhat.com> <1173470887.5437.7.camel@raptor.sr.unh.edu> <1173477658.14998.0.camel@localhost.localdomain> <1173712438.4963.4.camel@continuity> <1173712174.1242.7.camel@localhost.localdomain> <20070312153500.GA10302@redhat.com> Message-ID: <1173917564.3582.15.camel@continuity> On Mon, 2007-03-12 at 16:35 +0100, Tomas Janousek wrote: > Hi, > > On Mon, Mar 12, 2007 at 11:09:34AM -0400, Adam Jackson wrote: > > The display size is limited at server startup, because XAA's memory > > allocator is spectacularly bad. I don't know if there's a good > > workaround for this. Try setting a Virtual size in the Screen section > > of xorg.conf? > > Yeah, you have to use Virtual to specify the maximum size. It may not be > possible to specify more than 2048xSomething though, because some chips are > limited (at least I read this on some xorg maillist). I just ended up aligning > the screens vertically, but it may not be comfortable. > > Regarding the 1920x1200 resolution, did you specify that Monitor-VGA option in > the device section? > > -- > TJ., BaseOS, Brno, CZ > I did have some luck with this after setting a virtual size. I was able to add the external panel on the fly. Unfortunately I lose direct rendering with the virtual size set to 3200x1200: (EE) intel(0): Cannot support DRI with frame buffer width > 2048. In theory, isn't the driver supposed to allocate as much shared memory as it needs? (i945 hardware). Is this something that will get fixed or a limitation of the hardware? As well as X now works, the desktop will need to catch up. After enabling the external monitor set to right of my laptop screen, my panels jump to the external monitor. After disabling the external monitor panels jump back to laptop screen but with no gravity on the panel, my icons get all messed up because the external monitor is much larger. I think I saw somewhere they're talking about adding gravity to the gnome panel in the next version. Regardless, this is exciting stuff.... tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From mattdm at mattdm.org Thu Mar 15 02:30:20 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 14 Mar 2007 22:30:20 -0400 Subject: disabling warn_unused_result attribute with FORTIFY_SOURCE? Message-ID: <20070315023020.GA20627@jadzia.bu.edu> My google-fu is failing me; I can't find any documentation on this. Apparently, building with -Wp,-D_FORTIFY_SOURCE=2 results in the warn_unused_result attribute being added to every (? or maybe just many) fuction. In turn, this makes many perfectly good programs spit out hundreds of warnings. I'm not sure this is necessarily good. Unlike other warnings, though, there doesn't seem to be a way to turn it off. Is there one I'm missing? I'd like to clean up all the real errors and turn on -Werror.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From drepper at redhat.com Thu Mar 15 03:11:52 2007 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 14 Mar 2007 20:11:52 -0700 Subject: disabling warn_unused_result attribute with FORTIFY_SOURCE? In-Reply-To: <20070315023020.GA20627@jadzia.bu.edu> References: <20070315023020.GA20627@jadzia.bu.edu> Message-ID: <45F8B978.4010205@redhat.com> Matthew Miller wrote: > My google-fu is failing me; I can't find any documentation on this. > Apparently, building with -Wp,-D_FORTIFY_SOURCE=2 results in the > warn_unused_result attribute being added to every (? or maybe just many) Only cases without valid cases where ignoring the value might be correct. > fuction. In turn, this makes many perfectly good programs spit out hundreds > of warnings. I'm not sure this is necessarily good. Fix the code. All those warnings are problems. > Unlike other warnings, though, there doesn't seem to be a way to turn it > off. Is there one I'm missing? There is no way. > I'd like to clean up all the real errors and turn on -Werror.... Then you have to fix all those warnings, too. Programs which fail to test return values are unreliable at best. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From drepper at redhat.com Thu Mar 15 03:14:20 2007 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 14 Mar 2007 20:14:20 -0700 Subject: RPATH status In-Reply-To: <87tzwsawbo.fsf@kosh.bigo.ensc.de> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <45F1CEE0.8020504@redhat.com> <87abylfka8.fsf@kosh.bigo.ensc.de> <45F2EC5F.5080607@redhat.com> <87zm6laroi.fsf@kosh.bigo.ensc.de> <45F34CA5.7070406@redhat.com> <87tzwsawbo.fsf@kosh.bigo.ensc.de> Message-ID: <45F8BA0C.6010709@redhat.com> Enrico Scholz wrote: > Sorry, when $ORIGIN was really designed to allow things like '$ORIGIN/..', > then the design of $ORIGIN is flawed. Nonsense. The whole assumption that every single moronic file system setup must be supported is wrong. Not everything that is technically possible is worth it. A ground rule must be that /usr/bin and /usr/lib{,64} mustn't be symlinks. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Thu Mar 15 04:03:03 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Mar 2007 00:03:03 -0400 Subject: disabling warn_unused_result attribute with FORTIFY_SOURCE? In-Reply-To: <45F8B978.4010205@redhat.com> References: <20070315023020.GA20627@jadzia.bu.edu> <45F8B978.4010205@redhat.com> Message-ID: <20070315040303.GA27757@jadzia.bu.edu> On Wed, Mar 14, 2007 at 08:11:52PM -0700, Ulrich Drepper wrote: > > My google-fu is failing me; I can't find any documentation on this. > > Apparently, building with -Wp,-D_FORTIFY_SOURCE=2 results in the > > warn_unused_result attribute being added to every (? or maybe just many) > Only cases without valid cases where ignoring the value might be correct. Okay, good to know. There's *so many* in this program it seemed like it must be a mistake. :) Thanks very much. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mitr at volny.cz Thu Mar 15 04:11:55 2007 From: mitr at volny.cz (Miloslav Trmac) Date: Thu, 15 Mar 2007 05:11:55 +0100 Subject: disabling warn_unused_result attribute with FORTIFY_SOURCE? In-Reply-To: <45F8B978.4010205@redhat.com> References: <20070315023020.GA20627@jadzia.bu.edu> <45F8B978.4010205@redhat.com> Message-ID: <45F8C78B.4040505@volny.cz> Hi, Ulrich Drepper napsal(a): > Matthew Miller wrote: >> My google-fu is failing me; I can't find any documentation on this. >> Apparently, building with -Wp,-D_FORTIFY_SOURCE=2 results in the >> warn_unused_result attribute being added to every (? or maybe just many) > > Only cases without valid cases where ignoring the value might be correct. > >> fuction. In turn, this makes many perfectly good programs spit out hundreds >> of warnings. I'm not sure this is necessarily good. > > Fix the code. All those warnings are problems. How about fwrite ()? What's wrong with just using ferror () before closing the file? Thanks for your time, Mirek From kevin.kofler at chello.at Thu Mar 15 04:16:51 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 15 Mar 2007 04:16:51 +0000 (UTC) Subject: disabling warn_unused_result attribute with FORTIFY_SOURCE? References: <20070315023020.GA20627@jadzia.bu.edu> Message-ID: Matthew Miller mattdm.org> writes: > Unlike other warnings, though, there doesn't seem to be a way to turn it > off. Is there one I'm missing? The _easy_ way to get rid of the warnings is to cast the unused results to void. The _right_ way to get rid of them is to actually _do_ something with the results, except in cases where it _really_ doesn't matter (e.g. because you already errored and are just trying to clean up or output/log error messages before the exit(1)). Kevin Kofler From mtasaka at ioa.s.u-tokyo.ac.jp Thu Mar 15 04:33:29 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 15 Mar 2007 13:33:29 +0900 Subject: disabling warn_unused_result attribute with FORTIFY_SOURCE? In-Reply-To: References: <20070315023020.GA20627@jadzia.bu.edu> Message-ID: <45F8CC99.1000907@ioa.s.u-tokyo.ac.jp> Kevin Kofler wrote: > Matthew Miller mattdm.org> writes: >> Unlike other warnings, though, there doesn't seem to be a way to turn it >> off. Is there one I'm missing? > > The _easy_ way to get rid of the warnings is to cast the unused results to > void. I may be wrong, however, my recognition is that this warning cannot be got rid of by casting to void. ----------------------------------------- [tasaka1 at localhost TEMP]$ cat attri_unused.c int foo1(){ return 2; } int foo1 () __attribute__ ((warn_unused_result)); int main(){ (void) foo1(); return 0; } [tasaka1 at localhost TEMP]$ LANG=C gcc -o attri_unused attri_unused.c -Wp,-D_FORTIFY_SOURCE=2 attri_unused.c: In function 'main': attri_unused.c:9: warning: ignoring return value of 'foo1', declared with attribute warn_unused_result ----------------------------------------- From mtasaka at ioa.s.u-tokyo.ac.jp Thu Mar 15 05:14:32 2007 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 15 Mar 2007 14:14:32 +0900 Subject: rpms/qt4/devel Trolltech.conf, NONE, 1.1 qt4.macros, NONE, 1.1 .cvsignore, 1.13, 1.14 qt4.spec, 1.34, 1.35 sources, 1.11, 1.12 In-Reply-To: <200703141317.l2EDHldL032764@cvs-int.fedora.redhat.com> References: <200703141317.l2EDHldL032764@cvs-int.fedora.redhat.com> Message-ID: <45F8D638.9010207@ioa.s.u-tokyo.ac.jp> Rex Dieter (rdieter) wrote: > Author: rdieter > > Update of /cvs/extras/rpms/qt4/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv32737 > > +%define qt4_sysconfdir %{_sysconfdir} > > @@ -416,59 +429,64 @@ > %defattr(-,root,root,-) > +%if "%{qt4_sysconfdir}" != "%{_sysconfdir}" > +%dir %{qt4_sysconfdir} > +%endif > +%config(noreplace) %{qt4_sysconfdir}/* > > %files devel > %defattr(-,root,root,-) > +%{_sysconfdir}/rpm/macros.* > > > %changelog > +* Tue Mar 13 2007 Rex Dieter 4.2.3-1 > +- qt-4.2.3 > +- multilib: move all arch-specific mkspecs bits to %%qt4_prefix/mkspecs (#223663) > +- +%%_sysconfdir/rpm/macros.qt4 > +- +%%config %%qt4_sysconfdir/Trolltech.conf > + It seems /etc/rpm/macros.qt4 is owned by qt4 and qt4-devel. From fedora at camperquake.de Thu Mar 15 07:24:33 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 15 Mar 2007 08:24:33 +0100 Subject: disabling warn_unused_result attribute with FORTIFY_SOURCE? In-Reply-To: <45F8C78B.4040505@volny.cz> References: <20070315023020.GA20627@jadzia.bu.edu> <45F8B978.4010205@redhat.com> <45F8C78B.4040505@volny.cz> Message-ID: <20070315082433.736922fb@banea.int.addix.net> Hi. On Thu, 15 Mar 2007 05:11:55 +0100, Miloslav Trmac wrote: > > Fix the code. All those warnings are problems. > How about fwrite ()? What's wrong with just using ferror () before > closing the file? All the write functions return the amount of bytes actually written, which may be different from the amount of data you gave it to write. Many programmers ignore this (and in 99.9% of all cases get away with it because write actually writes the whole data), but it only _has_ to write a single byte before returning without error (given blocking IO). From jakub at redhat.com Thu Mar 15 07:38:59 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 15 Mar 2007 02:38:59 -0500 Subject: RPATH status In-Reply-To: <45F8BA0C.6010709@redhat.com> References: <20070309130427.GC23863@localhost> <45F19251.5060706@redhat.com> <45F1CE12.1000708@redhat.com> <45F1CEE0.8020504@redhat.com> <87abylfka8.fsf@kosh.bigo.ensc.de> <45F2EC5F.5080607@redhat.com> <87zm6laroi.fsf@kosh.bigo.ensc.de> <45F34CA5.7070406@redhat.com> <87tzwsawbo.fsf@kosh.bigo.ensc.de> <45F8BA0C.6010709@redhat.com> Message-ID: <20070315073859.GC355@devserv.devel.redhat.com> On Wed, Mar 14, 2007 at 08:14:20PM -0700, Ulrich Drepper wrote: > Enrico Scholz wrote: > > Sorry, when $ORIGIN was really designed to allow things like '$ORIGIN/..', > > then the design of $ORIGIN is flawed. > > Nonsense. The whole assumption that every single moronic file system > setup must be supported is wrong. Not everything that is technically > possible is worth it. A ground rule must be that /usr/bin and > /usr/lib{,64} mustn't be symlinks. Well, they actually can, but they either need to point to sibling directories (say /usr/bin -> /opt/foo/bar/bin, /usr/lib -> /opt/foo/bar/lib, /usr/lib64 -> /opt/foo/bar/lib64) or if for whatever reason they are not, then you need symlinks in both locations (say /usr/bin -> /opt/foo/bar/bin, /usr/lib -> /opt/bar/baz/lib, then you'd need also /opt/foo/bar/lib -> ../../bar/baz/lib and /opt/bar/baz/bin -> ../../foo/bar/bin). This is not just for the sake of $ORIGIN/.., e.g. gcc does a similar search for libraries and other relocatable packages do so as well. Jakub From tjanouse at redhat.com Thu Mar 15 09:33:21 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Thu, 15 Mar 2007 10:33:21 +0100 Subject: RANDR 1.2 heads up In-Reply-To: <1173917564.3582.15.camel@continuity> References: <1173136781.9948.22.camel@localhost.localdomain> <20070308092717.6dd893d2@banea.int.addix.net> <20070308131635.GA18472@redhat.com> <1173470887.5437.7.camel@raptor.sr.unh.edu> <1173477658.14998.0.camel@localhost.localdomain> <1173712438.4963.4.camel@continuity> <1173712174.1242.7.camel@localhost.localdomain> <20070312153500.GA10302@redhat.com> <1173917564.3582.15.camel@continuity> Message-ID: <20070315093321.GA25830@redhat.com> Hi, On Wed, Mar 14, 2007 at 08:12:44PM -0400, Thomas J. Baker wrote: > I did have some luck with this after setting a virtual size. I was able > to add the external panel on the fly. Unfortunately I lose direct > rendering with the virtual size set to 3200x1200: > > (EE) intel(0): Cannot support DRI with frame buffer width > 2048. > > In theory, isn't the driver supposed to allocate as much shared memory > as it needs? (i945 hardware). Is this something that will get fixed or a > limitation of the hardware? Well, it is a limitation of hardware -- it supports stride width of 8192 which is 2048 with a depth of 32 bits. The driver authors will try to workaround it somehow though, according to the traffic in xorg maillist. -- TJ., BaseOS, Brno, CZ From buildsys at redhat.com Thu Mar 15 10:10:48 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 15 Mar 2007 06:10:48 -0400 Subject: rawhide report: 20070315 changes Message-ID: <200703151010.l2FAAmPo008042@hs20-bc2-6.build.redhat.com> Removed package gnucash Updated Packages: a2ps-4.13b-65.fc7 ----------------- * Wed Mar 14 2007 Tim Waugh 4.13b-65 - Fix encoding of encoding.texi (bug #225235). - Make a2ps.cfg %config again, but not noreplace (bug #225235). - Added post/postun ldconfig (bug #225235). binutils-2.17.50.0.12-3 ----------------------- * Wed Mar 14 2007 Jakub Jelinek 2.17.50.0.12-3 - don't require matching ELF_OSABI for target vecs with ELFOSABI_NONE, only prefer specific osabi target vecs over the generic ones (H.J.Lu, #230964, BZ#3826) - build libbfd.so and libopcodes.so with -Bsymbolic-functions createrepo-0.4.8-2.fc7 ---------------------- * Wed Mar 14 2007 Paul Nasrat - 0.4.8-2 - Remove requires (#227680) ed-0.5-1 -------- * Wed Mar 14 2007 Karsten Hopp 0.5-1 - version 0.5, fixes #228329 evolution-2.10.0-2.fc7 ---------------------- * Wed Mar 14 2007 Matthew Barnes - 2.10.0-2.fc7 - Add patch for GNOME bug #417999 (use ESourceComboBox). evolution-data-server-1.10.0-2.fc7 ---------------------------------- * Wed Mar 14 2007 Matthew Barnes - 1.10.0-2.fc7 - Modify patch for GNOME bug #376991 to fix RH bug #231994. - Add patch for GNOME bug #419999 (avoid deprecated GTK+ symbols). - Remove evolution-data-server-1.0.2-workaround-cal-backend-leak.patch. - Remove evolution-data-server-1.2.2-fix_open_calendar_declaration.patch. - Remove evolution-data-server-1.3.8-fix-implicit-function-declarations. firstboot-1.4.32-1.fc7 ---------------------- * Wed Mar 14 2007 Chris Lumens - 1.4.32-1 - Fixes to make the graphics look better (#229837). - Don't wrap back to the first screen at the end of reconfig mode (#214962). ghostscript-8.15.4-1.fc7 ------------------------ * Wed Mar 14 2007 Tim Waugh 8.15.4-1 - 8.15.4. gmp-4.1.4-12.2 -------------- * Wed Mar 14 2007 Karsten Hopp 4.1.4-12.2 - fix typo * Wed Mar 14 2007 Thomas Woerner 4.1.4-12.1 - added alpha support for gmp.h and gmp-mparam.h wrappers gnome-screensaver-2.18.0-1.fc7 ------------------------------ * Wed Mar 14 2007 Ray Strode - 2.18.0-1 - Update to 2.18.0 (Matthias) - rework smart card patch gsl-1.8-3.fc7 ------------- * Wed Mar 14 2007 Ivana Varekova - 1.8-3 - incorporate the package review feedback gtk2-2.10.11-1.fc7 ------------------ * Wed Mar 14 2007 Matthias Clasen - 2.10.11-1 - Update to 2.10.11 - Require libpng-devel in the devel package (#232013) * Mon Mar 12 2007 Matthias Clasen - 2.10.10-1 - Update to 2.10.10 * Fri Feb 09 2007 Stepan Kasal - 2.10.9-4 - Clean up the autotools calls in %prep. hwdata-0.199-1.fc7 ------------------ * Mon Mar 12 2007 Karsten Hopp 0.199-1 - drop %config from data files in /usr iproute-2.6.20-1.fc7 -------------------- * Thu Mar 15 2007 Radek Vok??l - 2.6.20-1 - upgrade to 2.6.20 kernel-2.6.20-1.2987.fc7 ------------------------ * Wed Mar 14 2007 Kristian H??gsberg - Update firewire patch with latest fixes from the kernel.org linux1394 tree. libtool-1.5.22-10.fc7 --------------------- * Wed Mar 14 2007 Karsten Hopp 1.5.22-10 - add disttag (#232204) nc-1.84-12.fc7 -------------- * Wed Mar 14 2007 Radek Vok??l - 1.84-12 - fix manpage for -C option (#203931) * Tue Feb 13 2007 Radek Vok??l - 1.84-11 - few spec file changes * Sun Oct 01 2006 Jesse Keating - 1.84-10 - rebuilt for unwind info generation, broken in gcc-4.1.1-21 policycoreutils-2.0.7-3.fc7 --------------------------- * Mon Mar 12 2007 Dan Walsh 2.0.7-3 - service restorecond status needs to set exit value correctly redhat-rpm-config-8.0.45-13.fc7 ------------------------------- * Tue Mar 13 2007 Ben Konrath 8.0.45-13 - Update brp-java-repack-jars to fix issue with tomcat. selinux-policy-2.5.8-4.fc7 -------------------------- * Tue Mar 13 2007 Dan Walsh 2.5.8-4 - Allow insmod to launch init scripts tomcat5-0:5.5.20-5jpp.1.fc7 --------------------------- * Mon Jan 29 2007 Vivek Lakshmanan 0:5.5.20-5jpp.1.fc7 - Merge with latest from JPP - Replace references to geronimo JTA with a generic one available in Fedora - Use Fedora compliant build root specification - Enabling juli still kills tomcat5 on startup, disabled - Add patch to force -source to 5.0 when 1.5 support enabled since ecj seems to use 1.4 as default still * Sun Jan 14 2007 Jason Corley 0:5.5.20-4jpp - remove jk2 configs as mod_jk2 has been deprecated upstream - s/Jakarta Tomcat/Apache Tomcat/ - replace jars in admin webapps with build-jar-repository links - silence chatty init script by default * Wed Jan 10 2007 Jason Corley 0:5.5.20-3jpp - replace _localstatedir with _var since Mandriva seems to think the former is equal to /var/lib while all the other distros have it as /var - macrofy! - use build-jar-repository for jdtcore instead of ln - comment out reloctomcat5 for eventual removal completely from spec - silence post of common-lib and server-lib subpackages - Fixed bugs: Bug 217: LSB init comments in init script (Frank Schwichtenberg) Bug 242: catalina.out incorrect ownership (Pavel Lisy) Bug 245: insecure permissions for temporary and cache directories (Troels Arvin) Bug 245: no status in initscript (Troels Arvin) xen-3.0.4-9.fc7 --------------- * Wed Mar 14 2007 Daniel P. Berrange - 3.0.4-9.fc7 - Disable access to QEMU monitor over VNC (CVE-2007-0998, bz 230295) 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 Broken deps for x86_64 ---------------------------------------------------------- python-pyblock - 0.27-3.i386 requires libdmraid.so.1.0.0.rc14 python-pyblock - 0.27-3.i386 requires libdmraid.so.1.0.0.rc14(Base) Broken deps for s390x ---------------------------------------------------------- python-pyblock - 0.27-3.s390 requires libdmraid.so.1.0.0.rc14(Base) python-pyblock - 0.27-3.s390 requires libdmraid.so.1.0.0.rc14 From alexl at redhat.com Thu Mar 15 10:13:30 2007 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 15 Mar 2007 11:13:30 +0100 Subject: User directories integration - request for help Message-ID: <1173953610.10024.132.camel@greebo> The basic user directories stuff discussed on fedora-desktop-list has now landed in rawhide (install the xdg-user-dirs and xdg-user-dirs-gtk packages to get it). I've created patches to the core desktop packages that needed it (nautilus, gnome-panel, gnome-user-share) to make it work. However, to fully make use of this we need to patch a bunch of applications to take advantage of this new feature. The directories availible are: DESKTOP: the standard desktop dir DOWNLOAD: default location for downloads TEMPLATES: used by nautilus for templates PUBLICSHARE: This is ~/Public as used by gnome-user-share DOCUMENTS: default location for "documents" MUSIC: default location for music PICTURES: default location for pictures VIDEOS: default location for movies The most common thing these are used for is for the default location of the file selector, or as a default for some setting (like download directory). I'd like to point out that the *best* default location for a file selector is whatever it was last time you opened it, so this should be used for the default default location. The xdg-user-dirs sources contains a file called xdg-user-dir-lookup.c which has a very simple implementation of looking up user directories. It has no dependencies and a liberal license (MIT) and was made to be easily copied into apps for easy patchmaking. I've attached an example patch that i did for gftp to show how adding integration to an application can look. Now I'd like to get some help with integrating this into the rest of our applications from package maintainers and the community in general. Both with patching and ideas of what can be done. Here is an initial list of stuff we should try to do: firefox/epiphany/any browser: default download directory abiword, OOo, other word processors: Default to DOCUMENTS directory (OOo is being worked on atm) bittorrent: default download directory rhythmbox: use MUSIC directory as default in file selector and maybe as the standard library location totem: use VIDEOS as default in file selector eog/gthumb/f-spot: PICTURES as default for file selector Any other ideas? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a jaded alcoholic romance novelist from the 'hood. She's a radical antique-collecting nun from Mars. They fight crime! -------------- next part -------------- A non-text attachment was scrubbed... Name: gftp-2.0.18-user-dirs.patch Type: text/x-patch Size: 3562 bytes Desc: not available URL: From alan at redhat.com Thu Mar 15 10:38:34 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 15 Mar 2007 06:38:34 -0400 Subject: disabling warn_unused_result attribute with FORTIFY_SOURCE? In-Reply-To: <20070315082433.736922fb@banea.int.addix.net> References: <20070315023020.GA20627@jadzia.bu.edu> <45F8B978.4010205@redhat.com> <45F8C78B.4040505@volny.cz> <20070315082433.736922fb@banea.int.addix.net> Message-ID: <20070315103834.GB19361@devserv.devel.redhat.com> On Thu, Mar 15, 2007 at 08:24:33AM +0100, Ralf Ertzinger wrote: > All the write functions return the amount of bytes actually written, > which may be different from the amount of data you gave it to write. They return the amount of data queued to be written. > Many programmers ignore this (and in 99.9% of all cases get away with it > because write actually writes the whole data), but it only _has_ to write > a single byte before returning without error (given blocking IO). close can itself report a write error if the write back to disk on NFS fails, and for disk media you might want to fflush() then fsync() if you are dealing with very precious data. That is normally overkill Alan From nicu_fedora at nicubunu.ro Thu Mar 15 10:48:09 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 15 Mar 2007 12:48:09 +0200 Subject: User directories integration - request for help In-Reply-To: <1173953610.10024.132.camel@greebo> References: <1173953610.10024.132.camel@greebo> Message-ID: <45F92469.3050303@nicubunu.ro> Alexander Larsson wrote: > > Here is an initial list of stuff we should try to do: > > firefox/epiphany/any browser: default download directory > > abiword, OOo, other word processors: Default to DOCUMENTS directory > (OOo is being worked on atm) > > bittorrent: default download directory > > rhythmbox: use MUSIC directory as default in file selector and maybe as > the standard library location > > totem: use VIDEOS as default in file selector > > eog/gthumb/f-spot: PICTURES as default for file selector > > Any other ideas? soundjuicer directory for ripping tracks should default to MUSIC mail clients (evolution, thunderbird) when saving attachments probably DOCUMENTS -- nicu Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From galibert at pobox.com Thu Mar 15 11:05:49 2007 From: galibert at pobox.com (Olivier Galibert) Date: Thu, 15 Mar 2007 12:05:49 +0100 Subject: disabling warn_unused_result attribute with FORTIFY_SOURCE? In-Reply-To: <20070315082433.736922fb@banea.int.addix.net> References: <20070315023020.GA20627@jadzia.bu.edu> <45F8B978.4010205@redhat.com> <45F8C78B.4040505@volny.cz> <20070315082433.736922fb@banea.int.addix.net> Message-ID: <20070315110549.GB43870@dspnet.fr.eu.org> On Thu, Mar 15, 2007 at 08:24:33AM +0100, Ralf Ertzinger wrote: > Hi. > > On Thu, 15 Mar 2007 05:11:55 +0100, Miloslav Trmac wrote: > > > > Fix the code. All those warnings are problems. > > How about fwrite ()? What's wrong with just using ferror () before > > closing the file? > > All the write functions return the amount of bytes actually written, > which may be different from the amount of data you gave it to write. write yes, fwrite no. fwrite is only allowed to return a short write on error. OG. From aalam at redhat.com Thu Mar 15 11:18:55 2007 From: aalam at redhat.com (A S Alam) Date: Thu, 15 Mar 2007 16:48:55 +0530 Subject: User directories integration - request for help In-Reply-To: <1173953610.10024.132.camel@greebo> References: <1173953610.10024.132.camel@greebo> Message-ID: <45F92B9F.5090409@redhat.com> Alexander Larsson ?? ?????: > The basic user directories stuff discussed on fedora-desktop-list has > now landed in rawhide (install the xdg-user-dirs and xdg-user-dirs-gtk > packages to get it). I've created patches to the core desktop packages > that needed it (nautilus, gnome-panel, gnome-user-share) to make it > work. However, to fully make use of this we need to patch a bunch of > applications to take advantage of this new feature. > > The directories availible are: > DESKTOP: the standard desktop dir > DOWNLOAD: default location for downloads > TEMPLATES: used by nautilus for templates > PUBLICSHARE: This is ~/Public as used by gnome-user-share > DOCUMENTS: default location for "documents" > MUSIC: default location for music > PICTURES: default location for pictures > VIDEOS: default location for movies > > The most common thing these are used for is for the default location of > the file selector, or as a default for some setting (like download > directory). I'd like to point out that the *best* default location for a > file selector is whatever it was last time you opened it, so this should > be used for the default default location. > > The xdg-user-dirs sources contains a file called xdg-user-dir-lookup.c > which has a very simple implementation of looking up user directories. > It has no dependencies and a liberal license (MIT) and was made to be > easily copied into apps for easy patchmaking. > > I've attached an example patch that i did for gftp to show how adding > integration to an application can look. > > Now I'd like to get some help with integrating this into the rest of our > applications from package maintainers and the community in general. Both > with patching and ideas of what can be done. > > Here is an initial list of stuff we should try to do: > > firefox/epiphany/any browser: default download directory > > abiword, OOo, other word processors: Default to DOCUMENTS directory > (OOo is being worked on atm) > > bittorrent: default download directory > > rhythmbox: use MUSIC directory as default in file selector and maybe as > the standard library location > > totem: use VIDEOS as default in file selector > > eog/gthumb/f-spot: PICTURES as default for file selector > Any idea about KDE applications? are those usefuly for kde? Thanks A S Alam From buildsys at fedoraproject.org Thu Mar 15 11:36:32 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 15 Mar 2007 07:36:32 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-15 Message-ID: <20070315113632.D32E7152130@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 27 NEW aspell-bn-0.01.1-1.fc7 NEW aspell-gu-0.02-1.fc7 NEW aspell-mr-0.10-1.fc7 NEW aspell-or-0.03-1.fc7 NEW aspell-pa-0.01-1.fc7 NEW aspell-ta-20040424-1.fc7 NEW aspell-te-0.01-1.fc7 deskbar-applet-2.17.93-1.fc7 epiphany-extensions-2.18.0-1 freealut-1.1.0-3.fc7 fwbuilder-2.1.10-1.fc7 gdal-1.4.0-13.fc7 gtkmozembedmm-1.4.2.cvs20060817-9.fc7 horde-3.1.4-1.fc7 imp-4.1.4-1.fc7 NEW jpgalleg-2.5-1.fc7 koan-0.2.7-1.fc7 libfwbuilder-2.1.10-1.fc7 liferea-1.2.8-1.fc7 NEW maven2-common-poms-1.0-4jpp.1.fc7 mozldap-6.0.3-1.fc7 pbzip2-1.0-1.fc7 php-pear-Crypt-CHAP-1.0.1-1.fc7 NEW plexus-compiler-1.5.2-2jpp.1.fc7 qt4-4.2.3-1.fc7 zvbi-0.2.24-1.fc7 zynaddsubfx-2.2.1-14.fc7 Packages built and released for Fedora Extras 6: 12 Inventor-2.1.5-26.fc6 em8300-kmod-0.16.1-2.2.6.20_1.2925.fc6 NEW gdal-1.4.0-13.fc6 horde-3.1.4-1.fc6 NEW jpgalleg-2.5-1.fc6 koan-0.2.7-1.fc6 listen-0.5-12.fc6 mozldap-6.0.3-1.fc6 pbzip2-1.0-1.fc6 php-pear-Crypt-CHAP-1.0.1-1.fc6 sysprof-kmod-1.0.8-1.2.6.20_1.2925.fc6 zvbi-0.2.24-1.fc6 Packages built and released for Fedora Extras 5: 7 em8300-0.16.1-0.fc5 em8300-kmod-0.16.1-0.2.6.20_1.2300.fc5.1 mozldap-6.0.3-1.fc5 pbzip2-1.0-1.fc5 php-pear-Crypt-CHAP-1.0.1-1.fc5 sysprof-kmod-1.0.8-1.2.6.20_1.2300.fc5 zvbi-0.2.24-1.fc5 aspell-bn-0.01.1-1.fc7 ---------------------- * Thu Mar 08 2007 Amanpreet Singh Alam 0.01-1 - Initile Release aspell-gu-0.02-1.fc7 -------------------- * Thu Mar 08 2007 Amanpreet Singh Alam 0.01-1 - Initile Release aspell-mr-0.10-1.fc7 -------------------- * Thu Mar 08 2007 Amanpreet Singh Alam 0.01-1 - Initile Release aspell-or-0.03-1.fc7 -------------------- * Thu Mar 08 2007 Amanpreet Singh Alam 0.01-1 - Initile Release aspell-pa-0.01-1.fc7 -------------------- * Thu Mar 08 2007 Amanpreet Singh Alam 0.01-1 - Initile Release aspell-ta-20040424-1.fc7 ------------------------ * Thu Mar 08 2007 Amanpreet Singh Alam 0.01-1 - Initile Release aspell-te-0.01-1.fc7 -------------------- * Thu Mar 08 2007 Amanpreet Singh Alam 0.01-1 - Initile Release deskbar-applet-2.17.93-1.fc7 ---------------------------- * Wed Mar 14 2007 Luke Macken - 2.17.93-1 - 2.17.93 epiphany-extensions-2.18.0-1 ---------------------------- * Wed Mar 14 2007 Peter Gordon - 2.18.0-1 - Update to new upstream release (2.18.0). - Remove shell syntax error (erroneous "||:") in %preun scriptlet. freealut-1.1.0-3.fc7 -------------------- * Mon Mar 12 2007 Andreas Bierfert 1.1.0-3 - fix #231132 * Fri Sep 15 2006 Andreas Bierfert 1.1.0-2 - FE6 rebuild fwbuilder-2.1.10-1.fc7 ---------------------- * Wed Mar 14 2007 Ralf Ertzinger 2.1.10-1.fc7 - Update to 2.1.10 gdal-1.4.0-13.fc7 ----------------- * Wed Mar 14 2007 Balint Cristian 1.4.0-13 - fix typo in specfile * Wed Mar 14 2007 Balint Cristian 1.4.0-12 - add missing dot from dist string in specfile * Wed Mar 14 2007 Balint Cristian 1.4.0-11 - fix fc6 fc5 builds gtkmozembedmm-1.4.2.cvs20060817-9.fc7 ------------------------------------- * Wed Mar 14 2007 Ha?kel Gu?mar - 1.4.2.cvs20060817-9 - rebuild against Firefox 2.0.0.2 (gecko 1.8.1.2) horde-3.1.4-1.fc7 ----------------- * Wed Dec 27 2006 Brandon Holbrook 3.1.4-1 - Bumped to upstream 3.1.4 - Made jeta 'active' in registry.php since it is no longer beta imp-4.1.4-1.fc7 --------------- * Wed Mar 14 2007 Brandon Holbrook 4.1.4-1 - Bumped to upstream 4.1.4 jpgalleg-2.5-1.fc7 ------------------ koan-0.2.7-1.fc7 ---------------- * Thu Mar 08 2007 - Michael DeHaan - 0.2.7-1 - Upstream changes (see CHANGELOG) * Wed Feb 28 2007 - Michael DeHaan - 0.2.6-2 - BuildRequires python-devel for FC7 * Wed Jan 24 2007 - Michael DeHaan - 0.2.6-1 - Upstream changes (see CHANGELOG) - Lowering python version number requirements libfwbuilder-2.1.10-1.fc7 ------------------------- * Wed Mar 14 2007 Ralf Ertzinger 2.1.10-1.fc7 - Update to 2.1.10 liferea-1.2.8-1.fc7 ------------------- * Wed Mar 14 2007 Brian Pepple - 1.2.8-1 - Update to 1.2.8. maven2-common-poms-1.0-4jpp.1.fc7 --------------------------------- mozldap-6.0.3-1.fc7 ------------------- * Tue Mar 13 2007 Rich Megginson - 6.0.3-1 - bumped version to 6.0.3 - minor build fixes for some platforms pbzip2-1.0-1.fc7 ---------------- * Wed Mar 14 2007 Jeff Gilchrist - 1.0-1 - Release 1.0 php-pear-Crypt-CHAP-1.0.1-1.fc7 ------------------------------- * Wed Mar 14 2007 Christopher Stone 1.0.1-1 - Upstream sync - Remove no longer needed patch plexus-compiler-1.5.2-2jpp.1.fc7 -------------------------------- * Thu Mar 08 2007 Deepak Bhole - 0:1.5.2-2jpp.1 - Fix license - Disable aspectj compiler until we can put that into Fedora - Remove vendor and distribution tags - Removed javadoc post and postuns, with dirs being marked %doc now - Fix buildroot per Fedora spec qt4-4.2.3-1.fc7 --------------- * Tue Mar 13 2007 Rex Dieter 4.2.3-1 - qt-4.2.3 - multilib: move all arch-specific mkspecs bits to %qt4_prefix/mkspecs (#223663) - +%_sysconfdir/rpm/macros.qt4 - +%config %qt4_sysconfdir/Trolltech.conf * Tue Mar 06 2007 Rex Dieter 4.2.2-8 - multilib: qconfig.pri, /etc/profile.d/* (#223663) zvbi-0.2.24-1.fc7 ----------------- * Tue Mar 13 2007 Ian Chapman 0.2.24-1.fc7 - Upgrade to 0.2.24 - Convert README and ChangeLog to UTF-8 - Added patch for x11font to generate more font sizes useful for other applications such as xawtv (courtesy of Dmitry Butskoy) - Fonts sub-rpm now obsoletes and provides xawtv-tv-fonts - Split font generation and font installation into separate sections - Various other minor changes to the spec - Added xfs support for the fonts * Fri Sep 01 2006 Ian Chapman 0.2.22-2.fc7 - Minor spec cleanups zynaddsubfx-2.2.1-14.fc7 ------------------------ * Wed Mar 14 2007 Anthony Green 2.2.1-14 - Rebuild with new ImageMagick for working desktop icons. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From rdieter at math.unl.edu Thu Mar 15 12:25:56 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 15 Mar 2007 07:25:56 -0500 Subject: rpms/qt4/devel Trolltech.conf, NONE, 1.1 qt4.macros, NONE, 1.1 .cvsignore, 1.13, 1.14 qt4.spec, 1.34, 1.35 sources, 1.11, 1.12 References: <200703141317.l2EDHldL032764@cvs-int.fedora.redhat.com> <45F8D638.9010207@ioa.s.u-tokyo.ac.jp> Message-ID: Mamoru Tasaka wrote: >> @@ -416,59 +429,64 @@ >> %defattr(-,root,root,-) >> +%if "%{qt4_sysconfdir}" != "%{_sysconfdir}" >> +%dir %{qt4_sysconfdir} >> +%endif >> +%config(noreplace) %{qt4_sysconfdir}/* >> >> %files devel >> %defattr(-,root,root,-) >> +%{_sysconfdir}/rpm/macros.* > It seems /etc/rpm/macros.qt4 is owned by qt4 and qt4-devel. Thanks, good spot. -- Rex From nicolas.mailhot at laposte.net Thu Mar 15 12:53:58 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 15 Mar 2007 13:53:58 +0100 (CET) Subject: User directories integration - request for help In-Reply-To: <45F92469.3050303@nicubunu.ro> References: <1173953610.10024.132.camel@greebo> <45F92469.3050303@nicubunu.ro> Message-ID: <17321.192.54.193.51.1173963238.squirrel@rousalka.dyndns.org> Le Jeu 15 mars 2007 11:48, Nicu Buculei a ?crit : > mail clients (evolution, thunderbird) when saving attachments probably > DOCUMENTS Or DOWNLOAD -- Nicolas Mailhot From nicu_fedora at nicubunu.ro Thu Mar 15 13:09:11 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 15 Mar 2007 15:09:11 +0200 Subject: User directories integration - request for help In-Reply-To: <17321.192.54.193.51.1173963238.squirrel@rousalka.dyndns.org> References: <1173953610.10024.132.camel@greebo> <45F92469.3050303@nicubunu.ro> <17321.192.54.193.51.1173963238.squirrel@rousalka.dyndns.org> Message-ID: <45F94577.1070905@nicubunu.ro> Nicolas Mailhot wrote: > Le Jeu 15 mars 2007 11:48, Nicu Buculei a ?crit : > >> mail clients (evolution, thunderbird) when saving attachments probably >> DOCUMENTS > > Or DOWNLOAD Yeah, one of those. Considering the small sample of users at my workplace the attachments in emails are: 1) jpeg 2) .doc, .xls, .pps 3) pdf -- nicu Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From baris at teamforce.name.tr Thu Mar 15 13:21:24 2007 From: baris at teamforce.name.tr (Baris Cicek) Date: Thu, 15 Mar 2007 15:21:24 +0200 Subject: User directories integration - request for help In-Reply-To: <1173953610.10024.132.camel@greebo> References: <1173953610.10024.132.camel@greebo> Message-ID: <1173964884.3339.18.camel@localhost.localdomain> > > abiword, OOo, other word processors: Default to DOCUMENTS directory > (OOo is being worked on atm) Don't forget gedit and evince. > > bittorrent: default download directory Should also for xchat. > > rhythmbox: use MUSIC directory as default in file selector and maybe as > the standard library location > > totem: use VIDEOS as default in file selector > > eog/gthumb/f-spot: PICTURES as default for file selector gimp > > Any other ideas? > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alla at lysator.liu.se > He's a jaded alcoholic romance novelist from the 'hood. She's a radical > antique-collecting nun from Mars. They fight crime! > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From nicu_fedora at nicubunu.ro Thu Mar 15 13:46:25 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 15 Mar 2007 15:46:25 +0200 Subject: User directories integration - request for help In-Reply-To: <1173964884.3339.18.camel@localhost.localdomain> References: <1173953610.10024.132.camel@greebo> <1173964884.3339.18.camel@localhost.localdomain> Message-ID: <45F94E31.2080405@nicubunu.ro> Baris Cicek wrote: >> eog/gthumb/f-spot: PICTURES as default for file selector > gimp I don't know, a PNG or JPG to open/save with GIMP may be expected in PICTURES but XCF is more likely to go in DOCUMENTS. And probably the same for Inkscape: SVG is a document and PNG a picture. -- nicu Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From dimi at lattica.com Thu Mar 15 12:57:20 2007 From: dimi at lattica.com (Dimi Paun) Date: Thu, 15 Mar 2007 08:57:20 -0400 (EDT) Subject: User directories integration - request for help In-Reply-To: <45F94E31.2080405@nicubunu.ro> References: <1173953610.10024.132.camel@greebo> <1173964884.3339.18.camel@localhost.localdomain> <45F94E31.2080405@nicubunu.ro> Message-ID: <60599.142.205.241.254.1173963440.squirrel@lattica.com> On Thu, March 15, 2007 09:46, Nicu Buculei wrote: > I don't know, a PNG or JPG to open/save with GIMP may be expected in > PICTURES but XCF is more likely to go in DOCUMENTS. > And probably the same for Inkscape: SVG is a document and PNG a picture. Not necessarily. IMO PICTURES/DOCUMENTS is not to be decided blindly on the extension of the file, that's useless, but rather on the intended use for the file. In other words, it seems to me that PICTURES should really hold things that qualify as photos. That's a lot different than some clip art or diagram. Those should go to DOCUMENTS, regardless of their format. -- Dimi Paun Lattica, Inc. From ssorce at redhat.com Thu Mar 15 14:01:14 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 15 Mar 2007 10:01:14 -0400 Subject: User directories integration - request for help In-Reply-To: <45F94E31.2080405@nicubunu.ro> References: <1173953610.10024.132.camel@greebo> <1173964884.3339.18.camel@localhost.localdomain> <45F94E31.2080405@nicubunu.ro> Message-ID: <1173967274.548.2.camel@willson> On Thu, 2007-03-15 at 15:46 +0200, Nicu Buculei wrote: > Baris Cicek wrote: > >> eog/gthumb/f-spot: PICTURES as default for file selector > > > gimp > > I don't know, a PNG or JPG to open/save with GIMP may be expected in > PICTURES but XCF is more likely to go in DOCUMENTS. > And probably the same for Inkscape: SVG is a document and PNG a picture. May technically be, but I don't think any "normal" user will expect to find them in documents. I would look in pictures first personally. Simo. From nicolas.mailhot at laposte.net Thu Mar 15 14:18:28 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 15 Mar 2007 15:18:28 +0100 (CET) Subject: User directories integration - request for help In-Reply-To: <60599.142.205.241.254.1173963440.squirrel@lattica.com> References: <1173953610.10024.132.camel@greebo> <1173964884.3339.18.camel@localhost.localdomain> <45F94E31.2080405@nicubunu.ro> <60599.142.205.241.254.1173963440.squirrel@lattica.com> Message-ID: <36175.192.54.193.51.1173968308.squirrel@rousalka.dyndns.org> Le Jeu 15 mars 2007 13:57, Dimi Paun a ?crit : > > On Thu, March 15, 2007 09:46, Nicu Buculei wrote: >> I don't know, a PNG or JPG to open/save with GIMP may be expected in >> PICTURES but XCF is more likely to go in DOCUMENTS. >> And probably the same for Inkscape: SVG is a document and PNG a picture. > > Not necessarily. IMO PICTURES/DOCUMENTS is not to be decided blindly > on the extension of the file, that's useless, but rather on the > intended use for the file. > > In other words, it seems to me that PICTURES should really hold things > that qualify as photos. IMHO PICTURES should be PHOTOS period. The file type is less important that the usage pattern: - everything that comes from the outside (mail, internet) -> DOWNLOAD - files I work on -> DOCUMENTS - static media content library -> MUSIC, PHOTOS, VIDEO That means media editors look in DOCUMENTS, media players in MUSIC, PHOTOS, VIDEO, and internet tools in DOWNLOAD -- Nicolas Mailhot From drepper at redhat.com Thu Mar 15 14:29:08 2007 From: drepper at redhat.com (Ulrich Drepper) Date: Thu, 15 Mar 2007 07:29:08 -0700 Subject: disabling warn_unused_result attribute with FORTIFY_SOURCE? In-Reply-To: References: <20070315023020.GA20627@jadzia.bu.edu> Message-ID: <45F95834.7070703@redhat.com> Kevin Kofler wrote: > The _easy_ way to get rid of the warnings is to cast the unused results to > void. No, gcc won't fall for that. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From kevin.kofler at chello.at Thu Mar 15 14:32:44 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 15 Mar 2007 14:32:44 +0000 (UTC) Subject: disabling warn_unused_result attribute with FORTIFY_SOURCE? References: <20070315023020.GA20627@jadzia.bu.edu> <45F8CC99.1000907@ioa.s.u-tokyo.ac.jp> Message-ID: Mamoru Tasaka ioa.s.u-tokyo.ac.jp> writes: > I may be wrong, however, my recognition is that this warning > cannot be got rid of by casting to void. You're right, I didn't know that. That's pretty stupid, (void) has always meant "I intentionally throw away this value and I mean it". :-/ What works is: int dummy=foo1(); (void)dummy; or: static inline __attribute__((always_inline)) int ignore(int x) {return x;} ignore(foo1()); but it's annoying you have to go to such lengths. There are always valid reasons to ignore a return value. (But don't get me wrong, most often it is NOT a good idea to ignore return values. When you're used to programming on calculators, where ignoring an error can mean locking up the entire calculator on the next instruction and having to press that reset combo once again, you quickly learn to always check return values. ;-) You're getting spoiled by high quality computer operating systems like Fedora which catch application errors properly. ;-) ) Kevin Kofler From kevin.kofler at chello.at Thu Mar 15 14:37:53 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 15 Mar 2007 14:37:53 +0000 (UTC) Subject: disabling warn_unused_result attribute with FORTIFY_SOURCE? References: <20070315023020.GA20627@jadzia.bu.edu> <45F95834.7070703@redhat.com> Message-ID: Ulrich Drepper redhat.com> writes: > Kevin Kofler wrote: > > The _easy_ way to get rid of the warnings is to cast the unused results to > > void. > > No, gcc won't fall for that. I wouldn't call it "fall for that", but "be consistent with all the other warnings about ignored values, both GCC's own 'value computed and not used' and those emitted by other compilers for situations exactly like the warn_unused_result one". Kevin Kofler From mschwendt.tmp0701.nospam at arcor.de Thu Mar 15 14:44:23 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 15 Mar 2007 15:44:23 +0100 Subject: repoview in our repositories In-Reply-To: <6792.65.192.24.190.1173473218.squirrel@mail.jcomserv.net> References: <20070309181701.feaff257.mschwendt.tmp0701.nospam@arcor.de> <6792.65.192.24.190.1173473218.squirrel@mail.jcomserv.net> Message-ID: <20070315154423.4b861ee1.mschwendt.tmp0701.nospam@arcor.de> After some modifications in repoview, here's what it could look like: http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/ http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/repoview/pbzip2.html *** Note that the download links to the packages don't work, as above URL is not a full repository. From kevin.kofler at chello.at Thu Mar 15 14:47:15 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 15 Mar 2007 14:47:15 +0000 (UTC) Subject: disabling warn_unused_result attribute with FORTIFY_SOURCE? References: <20070315023020.GA20627@jadzia.bu.edu> <45F8CC99.1000907@ioa.s.u-tokyo.ac.jp> Message-ID: Kevin Kofler chello.at> writes: > You're right, I didn't know that. That's pretty stupid, (void) has always > meant "I intentionally throw away this value and I mean it". :-/ This has actually been filed as a GCC bug (which I agree it is) over a year ago by Dirk Mueller from KDE. Sadly, it has been marked WONTFIX. :-( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509 Kevin Kofler From jkeating at redhat.com Thu Mar 15 14:55:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Mar 2007 10:55:05 -0400 Subject: repoview in our repositories In-Reply-To: <20070315154423.4b861ee1.mschwendt.tmp0701.nospam@arcor.de> References: <20070309181701.feaff257.mschwendt.tmp0701.nospam@arcor.de> <6792.65.192.24.190.1173473218.squirrel@mail.jcomserv.net> <20070315154423.4b861ee1.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200703151055.06123.jkeating@redhat.com> On Thursday 15 March 2007 10:44:23 Michael Schwendt wrote: > After some modifications in repoview, here's what it could look like: > > http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/ > > http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/rep >oview/pbzip2.html > > *** Note that the download links to the packages don't work, as above URL > is not a full repository. That looks pretty nice! -- 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 Mar 15 14:53:37 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Mar 2007 10:53:37 -0400 Subject: User directories integration - request for help In-Reply-To: <1173953610.10024.132.camel@greebo> References: <1173953610.10024.132.camel@greebo> Message-ID: <20070315145337.GA9180@jadzia.bu.edu> On Thu, Mar 15, 2007 at 11:13:30AM +0100, Alexander Larsson wrote: > The directories availible are: > DESKTOP: the standard desktop dir > DOWNLOAD: default location for downloads > TEMPLATES: used by nautilus for templates > PUBLICSHARE: This is ~/Public as used by gnome-user-share > DOCUMENTS: default location for "documents" > MUSIC: default location for music > PICTURES: default location for pictures > VIDEOS: default location for movies What's with the ALL CAPS? I'm having an Apple ][ flashback. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From limb at jcomserv.net Thu Mar 15 14:50:50 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 15 Mar 2007 09:50:50 -0500 (CDT) Subject: repoview in our repositories In-Reply-To: <20070315154423.4b861ee1.mschwendt.tmp0701.nospam@arcor.de> References: <20070309181701.feaff257.mschwendt.tmp0701.nospam@arcor.de> <6792.65.192.24.190.1173473218.squirrel@mail.jcomserv.net> <20070315154423.4b861ee1.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <56948.65.192.24.190.1173970250.squirrel@mail.jcomserv.net> Looks very good. Slightly OT, is there a reason why this http://fedoraproject.org/extras/6/i386/repodata/ isn't thoroughly functional? > After some modifications in repoview, here's what it could look like: > > http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/ > > http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/repoview/pbzip2.html > > *** Note that the download links to the packages don't work, as above URL > is not a full repository. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From baris at teamforce.name.tr Thu Mar 15 14:50:27 2007 From: baris at teamforce.name.tr (Baris Cicek) Date: Thu, 15 Mar 2007 16:50:27 +0200 Subject: User directories integration - request for help In-Reply-To: <45F92B9F.5090409@redhat.com> References: <1173953610.10024.132.camel@greebo> <45F92B9F.5090409@redhat.com> Message-ID: <1173970227.3339.21.camel@localhost.localdomain> > > > > Here is an initial list of stuff we should try to do: > > > > firefox/epiphany/any browser: default download directory Also for gaim (received files). > > From ncorrare at fedoraproject.org Thu Mar 15 15:10:34 2007 From: ncorrare at fedoraproject.org (Nicolas Antonio Corrarello) Date: Thu, 15 Mar 2007 12:10:34 -0300 Subject: Rawhide Dependencies Broken In-Reply-To: <200703151055.06123.jkeating@redhat.com> References: <20070309181701.feaff257.mschwendt.tmp0701.nospam@arcor.de> <6792.65.192.24.190.1173473218.squirrel@mail.jcomserv.net> <20070315154423.4b861ee1.mschwendt.tmp0701.nospam@arcor.de> <200703151055.06123.jkeating@redhat.com> Message-ID: <45F961EA.3010404@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maybe I've missed some mail with instructions, yum update its no working on Fedora 7 Rawhide. Is there any fix already for this - -- - - -- Nicolas A. Corrarello, RHCE c: +54 (911) 6398-5974 Fedora Ambassador Argentina e: ncorrare at fedoraproject.org GPG Key: DFC893EE h: http://www.fedoraproject.org/wiki/NicolasCorrarello GPG Fingerprint: 5C93 42DA 98E1 4EEF B24B 7F8C E145 B2F9 DFC8 93EE Import my key: $ gpg --keyserver pgp.mit.edu --recv-key 0xDFC893EE Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF+WHq4UWy+d/Ik+4RArzEAKCTHxZdcXYLfRA6sxFdWqfT6nIWXgCffRXq Xka2FXOtoqvYIUpdtUDtpsU= =umvB -----END PGP SIGNATURE----- From mattdm at mattdm.org Thu Mar 15 15:14:01 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Mar 2007 11:14:01 -0400 Subject: Rawhide Dependencies Broken In-Reply-To: <45F961EA.3010404@fedoraproject.org> References: <20070309181701.feaff257.mschwendt.tmp0701.nospam@arcor.de> <6792.65.192.24.190.1173473218.squirrel@mail.jcomserv.net> <20070315154423.4b861ee1.mschwendt.tmp0701.nospam@arcor.de> <200703151055.06123.jkeating@redhat.com> <45F961EA.3010404@fedoraproject.org> Message-ID: <20070315151401.GA11577@jadzia.bu.edu> On Thu, Mar 15, 2007 at 12:10:34PM -0300, Nicolas Antonio Corrarello wrote: > Maybe I've missed some mail with instructions, yum update its no working > on Fedora 7 Rawhide. Is there any fix already for this sudo yum clean metadata try again. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mspevack at redhat.com Thu Mar 15 15:20:57 2007 From: mspevack at redhat.com (Max Spevack) Date: Thu, 15 Mar 2007 11:20:57 -0400 (EDT) Subject: Must Have features for Fedora 7 Message-ID: There is a draft page on the wiki in which we are trying to capture as simply as possible the subset of our feature list that is considered crucial for Fedora 7 -- things we can't release without. It's been iterated enough on Fedora Advisory Board list that it's now time to throw it directly to fedora-devel-list. Please review, comment, edit, etc. Goal is to have a version that f-devel-l stands behind by the end of the week, and then message it to the rest of Red Hat next week, in order to make sure that Red Hat engineering management is fully aware also. http://fedoraproject.org/wiki/Releases/7/MustHave --Max -- Max Spevack + http://fedoraproject.org/wiki/MaxSpevack + gpg key -- http://spevack.org/max.asc + fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21 From mschwendt.tmp0701.nospam at arcor.de Thu Mar 15 15:31:50 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 15 Mar 2007 16:31:50 +0100 Subject: repoview in our repositories In-Reply-To: <56948.65.192.24.190.1173970250.squirrel@mail.jcomserv.net> References: <20070309181701.feaff257.mschwendt.tmp0701.nospam@arcor.de> <6792.65.192.24.190.1173473218.squirrel@mail.jcomserv.net> <20070315154423.4b861ee1.mschwendt.tmp0701.nospam@arcor.de> <56948.65.192.24.190.1173970250.squirrel@mail.jcomserv.net> Message-ID: <20070315163150.9691708d.mschwendt.tmp0701.nospam@arcor.de> On Thu, 15 Mar 2007 09:50:50 -0500 (CDT), Jon Ciesla wrote: > Looks very good. > > Slightly OT, is there a reason why this > http://fedoraproject.org/extras/6/i386/repodata/ isn't thoroughly > functional? It's no repository anymore. Core and Extras are here: http://redhat.download.fedoraproject.org/pub/fedora/linux/ -> http://download.fedora.redhat.com/pub/fedora/linux/extras/6/i386/repodata/ From pvrabec at redhat.com Thu Mar 15 15:34:07 2007 From: pvrabec at redhat.com (Peter Vrabec) Date: Thu, 15 Mar 2007 16:34:07 +0100 Subject: with or without fedora-usermgmt In-Reply-To: <20070314154351.GC18364@nostromo.devel.redhat.com> References: <20070314151944.46717aa0@wrabco.brq.redhat.com> <20070314154351.GC18364@nostromo.devel.redhat.com> Message-ID: <45F9676F.3060800@redhat.com> Bill Nottingham wrote: > Peter Vrabec (pvrabec at redhat.com) said: >> Don't you think somebody should make some decision here: >> http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00124.html >> - flame, but possible pros and cons can be find there >> My opinion is not to use fedora-usermgmt. > > My proposal is to use 100-499 for static as well, And what do you plan to do during upgrade if there are some slots already occupied? I suggest to avoid using static UID as much as possible. > and just do static > registrations for everything - it's simpler. It can be combined with > making dynamic system IDs go from 499 down as well. > > Bill > From limb at jcomserv.net Thu Mar 15 15:32:34 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 15 Mar 2007 10:32:34 -0500 (CDT) Subject: repoview in our repositories In-Reply-To: <20070315163150.9691708d.mschwendt.tmp0701.nospam@arcor.de> References: <20070309181701.feaff257.mschwendt.tmp0701.nospam@arcor.de> <6792.65.192.24.190.1173473218.squirrel@mail.jcomserv.net> <20070315154423.4b861ee1.mschwendt.tmp0701.nospam@arcor.de> <56948.65.192.24.190.1173970250.squirrel@mail.jcomserv.net> <20070315163150.9691708d.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <61273.65.192.24.190.1173972754.squirrel@mail.jcomserv.net> Excellent. I must have missed that. Thanks! > On Thu, 15 Mar 2007 09:50:50 -0500 (CDT), Jon Ciesla wrote: > >> Looks very good. >> >> Slightly OT, is there a reason why this >> http://fedoraproject.org/extras/6/i386/repodata/ isn't thoroughly >> functional? > > It's no repository anymore. Core and Extras are here: > > http://redhat.download.fedoraproject.org/pub/fedora/linux/ > -> > http://download.fedora.redhat.com/pub/fedora/linux/extras/6/i386/repodata/ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From mattdm at mattdm.org Thu Mar 15 15:44:28 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Mar 2007 11:44:28 -0400 Subject: with or without fedora-usermgmt In-Reply-To: <45F9676F.3060800@redhat.com> References: <20070314151944.46717aa0@wrabco.brq.redhat.com> <20070314154351.GC18364@nostromo.devel.redhat.com> <45F9676F.3060800@redhat.com> Message-ID: <20070315154428.GA14121@jadzia.bu.edu> On Thu, Mar 15, 2007 at 04:34:07PM +0100, Peter Vrabec wrote: > >> Don't you think somebody should make some decision here: > >> http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00124.html > >> - flame, but possible pros and cons can be find there > >> My opinion is not to use fedora-usermgmt. > > My proposal is to use 100-499 for static as well, > And what do you plan to do during upgrade if there are some slots > already occupied? The suggestion of falling back to a dynamic UID is probably best -- then those systems are no worse than before. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora.lists at burns.me.uk Thu Mar 15 15:47:08 2007 From: fedora.lists at burns.me.uk (Andy Burns) Date: Thu, 15 Mar 2007 15:47:08 +0000 Subject: Rawhide Dependencies Broken In-Reply-To: <20070315151401.GA11577@jadzia.bu.edu> References: <20070309181701.feaff257.mschwendt.tmp0701.nospam@arcor.de> <6792.65.192.24.190.1173473218.squirrel@mail.jcomserv.net> <20070315154423.4b861ee1.mschwendt.tmp0701.nospam@arcor.de> <200703151055.06123.jkeating@redhat.com> <45F961EA.3010404@fedoraproject.org> <20070315151401.GA11577@jadzia.bu.edu> Message-ID: On 15/03/07, Matthew Miller wrote: > On Thu, Mar 15, 2007 at 12:10:34PM -0300, Nicolas Antonio Corrarello wrote: > > Maybe I've missed some mail with instructions, yum update its no working > > on Fedora 7 Rawhide. Is there any fix already for this > > sudo yum clean metadata > > try again. for the last couple of days rawhide hasn't been installable (pxeboot + ks from local mirror) 2 days ago yum crash, yesterday yum file conflicts, anyone know it it's stabilised at all today? 3 machines waiting to get testing on, if only I could install them (F7t2 from DVD has RAID1 issues for me) From ajackson at redhat.com Thu Mar 15 15:45:05 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 15 Mar 2007 11:45:05 -0400 Subject: RANDR 1.2 heads up In-Reply-To: <1173917564.3582.15.camel@continuity> References: <1173136781.9948.22.camel@localhost.localdomain> <20070308092717.6dd893d2@banea.int.addix.net> <20070308131635.GA18472@redhat.com> <1173470887.5437.7.camel@raptor.sr.unh.edu> <1173477658.14998.0.camel@localhost.localdomain> <1173712438.4963.4.camel@continuity> <1173712174.1242.7.camel@localhost.localdomain> <20070312153500.GA10302@redhat.com> <1173917564.3582.15.camel@continuity> Message-ID: <1173973505.10657.50.camel@localhost.localdomain> On Wed, 2007-03-14 at 20:12 -0400, Thomas J. Baker wrote: > On Mon, 2007-03-12 at 16:35 +0100, Tomas Janousek wrote: > > Hi, > > > > On Mon, Mar 12, 2007 at 11:09:34AM -0400, Adam Jackson wrote: > > > The display size is limited at server startup, because XAA's memory > > > allocator is spectacularly bad. I don't know if there's a good > > > workaround for this. Try setting a Virtual size in the Screen section > > > of xorg.conf? > > > > Yeah, you have to use Virtual to specify the maximum size. It may not be > > possible to specify more than 2048xSomething though, because some chips are > > limited (at least I read this on some xorg maillist). I just ended up aligning > > the screens vertically, but it may not be comfortable. > > > > Regarding the 1920x1200 resolution, did you specify that Monitor-VGA option in > > the device section? > > > > -- > > TJ., BaseOS, Brno, CZ > > > > I did have some luck with this after setting a virtual size. I was able > to add the external panel on the fly. Unfortunately I lose direct > rendering with the virtual size set to 3200x1200: > > (EE) intel(0): Cannot support DRI with frame buffer width > 2048. > > In theory, isn't the driver supposed to allocate as much shared memory > as it needs? (i945 hardware). Is this something that will get fixed or a > limitation of the hardware? Hardware limitation. 3D engines only have so many address bits... 965 has a stride limit of 4096, I think, which is quite a bit better. Fixing this for the general case is hard but doable. Imagine the pain involved in submitting all your rendering multiple times in squares of 2048x2048 and you begin to get some idea of the contortions involved. - ajax From notting at redhat.com Thu Mar 15 16:21:04 2007 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Mar 2007 12:21:04 -0400 Subject: with or without fedora-usermgmt In-Reply-To: <45F9676F.3060800@redhat.com> References: <20070314151944.46717aa0@wrabco.brq.redhat.com> <20070314154351.GC18364@nostromo.devel.redhat.com> <45F9676F.3060800@redhat.com> Message-ID: <20070315162104.GA3170@nostromo.devel.redhat.com> Peter Vrabec (pvrabec at redhat.com) said: > And what do you plan to do during upgrade if there are some slots > already occupied? If it's taken, you can fall back to dynamic IDs taken from the top. But it would be best to be as consistent as possible on new installations. Bill From ncorrare at fedoraproject.org Thu Mar 15 17:18:20 2007 From: ncorrare at fedoraproject.org (Nicolas Antonio Corrarello) Date: Thu, 15 Mar 2007 14:18:20 -0300 Subject: The faces of the FedoraProject Message-ID: <45F97FDC.9030407@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think is very important for everyone to put a face on every name, to give a more human approach, as it is discussed on in the MustHave . Even if i got it wrong, it would be nice to see a picture of each one of us in the PersonalPages, so I'd like to encourage everyone to do it. I started with mine http://fedoraproject.org/wiki/NicolasCorrarello , you can e-mail me to say how ugly or goofy I look :D Y.S. - -- - - -- Nicolas A. Corrarello, RHCE c: +54 (911) 6398-5974 Fedora Ambassador Argentina e: ncorrare at fedoraproject.org GPG Key: DFC893EE h: http://www.fedoraproject.org/wiki/NicolasCorrarello GPG Fingerprint: 5C93 42DA 98E1 4EEF B24B 7F8C E145 B2F9 DFC8 93EE Import my key: $ gpg --keyserver pgp.mit.edu --recv-key 0xDFC893EE Learn. Network. Experience open source. Red Hat Summit San Diego | May 9-11, 2007 Learn more: http://www.redhat.com/promo/summit/2007 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF+X/c4UWy+d/Ik+4RAnkoAJ9pkOqHidaRb+2NoTBXQ1pVsOkBlACfdaOL 4tXvJlm+NgJ4Cz2pfgv8lk0= =nNZX -----END PGP SIGNATURE----- From mclasen at redhat.com Thu Mar 15 18:03:22 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 15 Mar 2007 14:03:22 -0400 Subject: User directories integration - request for help In-Reply-To: <1173953610.10024.132.camel@greebo> References: <1173953610.10024.132.camel@greebo> Message-ID: <1173981802.3566.2.camel@localhost.localdomain> On Thu, 2007-03-15 at 11:13 +0100, Alexander Larsson wrote: > > Any other ideas? Might be a good idea to give a quick explanation of what happens, and what people should expect to see if they install the packages. Matthias From lsof at nodata.co.uk Thu Mar 15 19:29:39 2007 From: lsof at nodata.co.uk (nodata) Date: Thu, 15 Mar 2007 20:29:39 +0100 Subject: User directories integration - request for help In-Reply-To: <1173981802.3566.2.camel@localhost.localdomain> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> Message-ID: <1173986979.3051.0.camel@sb-home.lan> Am Donnerstag, den 15.03.2007, 14:03 -0400 schrieb Matthias Clasen: > On Thu, 2007-03-15 at 11:13 +0100, Alexander Larsson wrote: > > > > Any other ideas? > > Might be a good idea to give a quick explanation of what happens, and > what people should expect to see if they install the packages. > > Matthias > >From the looks of it, the directories get continually renamed if you switch languages. Stay away from my home dir, use a dot file if you must! From mclasen at redhat.com Thu Mar 15 20:00:54 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 15 Mar 2007 16:00:54 -0400 Subject: User directories integration - request for help In-Reply-To: <1173986979.3051.0.camel@sb-home.lan> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> Message-ID: <1173988854.3535.0.camel@localhost.localdomain> On Thu, 2007-03-15 at 20:29 +0100, nodata wrote: > Am Donnerstag, den 15.03.2007, 14:03 -0400 schrieb Matthias Clasen: > > On Thu, 2007-03-15 at 11:13 +0100, Alexander Larsson wrote: > > > > > > Any other ideas? > > > > Might be a good idea to give a quick explanation of what happens, and > > what people should expect to see if they install the packages. > > > > Matthias > > > > >From the looks of it, the directories get continually renamed if you > switch languages. Stay away from my home dir, use a dot file if you > must! Any you continually switch languages ?! From lsof at nodata.co.uk Thu Mar 15 20:02:58 2007 From: lsof at nodata.co.uk (nodata) Date: Thu, 15 Mar 2007 21:02:58 +0100 Subject: User directories integration - request for help In-Reply-To: <1173988854.3535.0.camel@localhost.localdomain> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> Message-ID: <1173988978.3051.6.camel@sb-home.lan> Am Donnerstag, den 15.03.2007, 16:00 -0400 schrieb Matthias Clasen: > On Thu, 2007-03-15 at 20:29 +0100, nodata wrote: > > Am Donnerstag, den 15.03.2007, 14:03 -0400 schrieb Matthias Clasen: > > > On Thu, 2007-03-15 at 11:13 +0100, Alexander Larsson wrote: > > > > > > > > Any other ideas? > > > > > > Might be a good idea to give a quick explanation of what happens, and > > > what people should expect to see if they install the packages. > > > > > > Matthias > > > > > > > >From the looks of it, the directories get continually renamed if you > > switch languages. Stay away from my home dir, use a dot file if you > > must! > > Any you continually switch languages ?! > Yes. Renaming a user's directories doesn't seem to be "The UNIX Way" TM From sundaram at fedoraproject.org Thu Mar 15 20:08:00 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 Mar 2007 01:38:00 +0530 Subject: User directories integration - request for help In-Reply-To: <1173988978.3051.6.camel@sb-home.lan> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> Message-ID: <45F9A7A0.3010607@fedoraproject.org> nodata wrote: > Am Donnerstag, den 15.03.2007, 16:00 -0400 schrieb Matthias Clasen: >> Any you continually switch languages ?! >> > > Yes. Why do you continuously switch languages and how does a rename affect you? > Renaming a user's directories doesn't seem to be "The UNIX Way" TM Traditional Unix systems never had to deal with many of the modern desktop requirements so it's high time we stopped citing the "the unix way" as a excuse not to change anything. All modern Linux desktop systems happily automount devices which is distinctly not unixy either. If there are real practical reasons just cite that specifically. Rahul From louisg00 at bellsouth.net Thu Mar 15 17:20:54 2007 From: louisg00 at bellsouth.net (Louis E Garcia II) Date: Thu, 15 Mar 2007 13:20:54 -0400 Subject: rawhide report: 20070315 changes Message-ID: <1173979254.3163.2.camel@sonlaptop> > Removed package gnucash Any reason why this package was removed along with it's dependencies? From jkeating at redhat.com Thu Mar 15 20:30:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Mar 2007 16:30:56 -0400 Subject: rawhide report: 20070315 changes In-Reply-To: <1173979254.3163.2.camel@sonlaptop> References: <1173979254.3163.2.camel@sonlaptop> Message-ID: <200703151630.56906.jkeating@redhat.com> On Thursday 15 March 2007 13:20:54 Louis E Garcia II wrote: > Any reason why this package was removed along with it's dependencies? It should be in Extras now. -- 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 Mar 15 20:37:11 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Mar 2007 16:37:11 -0400 Subject: speed of yum depsolver [FIX attached] In-Reply-To: <20070312163921.GA30150@jadzia.bu.edu> References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> <20070312161310.GA27101@redhat.com> <1173716340.20424.31.camel@cutter> <20070312163921.GA30150@jadzia.bu.edu> Message-ID: <20070315203711.GA7264@jadzia.bu.edu> On Mon, Mar 12, 2007 at 12:39:21PM -0400, Matthew Miller wrote: > conduit.info(1, '********************************************************') > conduit.info(1, 'You are using Fedora Rawhide. Now I will EAT YOUR BRANE.') > conduit.info(1, '********************************************************') I know it's kind of sad to laugh at my own joke, but I've been running with this plugin all week, and I can attest that it actually *has* significantly improved my Rawhide user experience. I think maybe I'll extend it to provide a variety of similar helpful tips at random. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jima at beer.tclug.org Thu Mar 15 20:40:28 2007 From: jima at beer.tclug.org (Jima) Date: Thu, 15 Mar 2007 15:40:28 -0500 (CDT) Subject: speed of yum depsolver [FIX attached] In-Reply-To: <20070315203711.GA7264@jadzia.bu.edu> References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> <20070312161310.GA27101@redhat.com> <1173716340.20424.31.camel@cutter> <20070312163921.GA30150@jadzia.bu.edu> <20070315203711.GA7264@jadzia.bu.edu> Message-ID: On Thu, 15 Mar 2007, Matthew Miller wrote: > On Mon, Mar 12, 2007 at 12:39:21PM -0400, Matthew Miller wrote: >> conduit.info(1, '********************************************************') >> conduit.info(1, 'You are using Fedora Rawhide. Now I will EAT YOUR BRANE.') >> conduit.info(1, '********************************************************') > > I know it's kind of sad to laugh at my own joke, but I've been running with > this plugin all week, and I can attest that it actually *has* significantly > improved my Rawhide user experience. I think maybe I'll extend it to provide > a variety of similar helpful tips at random. Do I sense the potential for a yum-fortune package? ;-) Jima From cmadams at hiwaay.net Thu Mar 15 20:41:40 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 15 Mar 2007 15:41:40 -0500 Subject: speed of yum depsolver [FIX attached] In-Reply-To: References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> <20070312161310.GA27101@redhat.com> <1173716340.20424.31.camel@cutter> <20070312163921.GA30150@jadzia.bu.edu> <20070315203711.GA7264@jadzia.bu.edu> Message-ID: <20070315204140.GB1129297@hiwaay.net> Once upon a time, Jima said: > Do I sense the potential for a yum-fortune package? ;-) Screw that - I want yum-bofh-eotd! -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From nicolas.mailhot at laposte.net Thu Mar 15 21:04:09 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 15 Mar 2007 22:04:09 +0100 Subject: User directories integration - request for help In-Reply-To: <45F9A7A0.3010607@fedoraproject.org> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> Message-ID: <1173992650.5024.9.camel@rousalka.dyndns.org> Le vendredi 16 mars 2007 ? 01:38 +0530, Rahul Sundaram a ?crit : > nodata wrote: > > Am Donnerstag, den 15.03.2007, 16:00 -0400 schrieb Matthias Clasen: > > >> Any you continually switch languages ?! > >> > > > > Yes. > > Why do you continuously switch languages and how does a rename affect you? > > > Renaming a user's directories doesn't seem to be "The UNIX Way" TM > > Traditional Unix systems never had to deal with many of the modern > desktop requirements so it's high time we stopped citing the "the unix > way" as a excuse not to change anything. All modern Linux desktop > systems happily automount devices which is distinctly not unixy either. > If there are real practical reasons just cite that specifically. You need to expose an invariant namespace in addition to the user-chosen one (with hard/sym links one way or the other) Every app, script or process that does not run for a single user within his session will have trouble with user-specific namespaces. (yes every user on a single system won't use the same layout) -- Nicolas Mailhot From mclasen at redhat.com Thu Mar 15 21:19:57 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 15 Mar 2007 17:19:57 -0400 Subject: User directories integration - request for help In-Reply-To: <1173992650.5024.9.camel@rousalka.dyndns.org> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <1173992650.5024.9.camel@rousalka.dyndns.org> Message-ID: <1173993597.3535.3.camel@localhost.localdomain> > > You need to expose an invariant namespace in addition to the user-chosen > one (with hard/sym links one way or the other) > > Every app, script or process that does not run for a single user within > his session will have trouble with user-specific namespaces. (yes every > user on a single system won't use the same layout) > What do you mean ? These directories are in no way special or different from any other directory you may create in your home directory. The only difference is that we create them at login time, and that we make desktop apps know about them. Matthias From mattdm at mattdm.org Thu Mar 15 21:38:46 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Mar 2007 17:38:46 -0400 Subject: what makes a package get i386 on x86_64? Message-ID: <20070315213846.GA13190@jadzia.bu.edu> I vaguely remember it being something about having a -devel package? I'm asking because Festival is currently built for both archs, and there's really no reason. I've made it multiarch compatible (bug #228315), but really, there's no good reason for it to be, since nothing links with it. The only program that requires it, in fact, is gnome-speech, and that communicates via a forked process. It's really meant to be used that way or as a network server. In fact, I'm not sure it's even terribly useful to ship a devel package for this -- it's really not designed for things to be built against it in that way. You can add modules, but the intended process is to build them as part of the main package build. (Arguably the speech-tools libraries could be split off into a completely separate package and then festival built against _those_ devel packages, but the festival build process wants an incestuous sort of availability of the speech-tools source tree, so that's not really an option.) So if ditching the devel package is what it takes.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mschwendt.tmp0701.nospam at arcor.de Thu Mar 15 22:10:57 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 15 Mar 2007 23:10:57 +0100 Subject: what makes a package get i386 on x86_64? In-Reply-To: <20070315213846.GA13190@jadzia.bu.edu> References: <20070315213846.GA13190@jadzia.bu.edu> Message-ID: <20070315231057.2c7f7179.mschwendt.tmp0701.nospam@arcor.de> On Thu, 15 Mar 2007 17:38:46 -0400, Matthew Miller wrote: > I vaguely remember it being something about having a -devel package? Yes. Extras development: All i386 -devel packages (also virtual ones) and their dependency chains are copied into the x86_64 repository unless the -devel package is black-listed. Additionally, white-listed packages and their dep-chains are copied. For Extras <= 6 it's just the "wine" packages. For Core I've heard about a white-list that is updated from time to time and about ongoing work in the multi-lib area. From bart.vanbrabant at zoeloelip.be Thu Mar 15 22:13:41 2007 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Thu, 15 Mar 2007 23:13:41 +0100 Subject: Fedora extras metadata Message-ID: <45F9C515.3060804@zoeloelip.be> Hello, What is going on with fedora extras metadata lately? Every time I run yum I need to download more then 30megs of metadata before yum finds a mirror with a valid checksum. It always happens when yum needs to import the filelists.xml.gz file. It's about 3.2MB in size and it fails most of the times on +/- 10 mirrors, that's 32MB of data that is wasted. Last time I updated the 14th mirror was succesfull. It also takes a lot of time for updates to finish. filelists.xml.gz 100% |=========================| 3.2 MB 00:30 http://sunsite.mff.cuni.cz/pub/fedora-extras/development/i386/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. filelists.xml.gz 100% |=========================| 3.1 MB 00:38 http://mirrors.kernel.org/fedora/extras/development/i386/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. filelists.xml.gz 100% |=========================| 3.2 MB 01:44 http://mirror.hiwaay.net/redhat/fedora/linux/extras/development/i386/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. filelists.xml.gz 100% |=========================| 3.2 MB 00:30 http://ftp-stud.fht-esslingen.de/pub/Mirrors/fedora.redhat.com/linux/extras/development/i386/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. filelists.xml.gz 100% |=========================| 3.2 MB 00:48 http://ftp-stud.fht-esslingen.de/pub/fedora/linux/extras/development/i386/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. filelists.xml.gz 100% |=========================| 3.2 MB 00:36 http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. filelists.xml.gz 100% |=========================| 3.2 MB 00:33 http://fr2.rpmfind.net/linux/fedora/extras/development/i386/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. filelists.xml.gz 100% |=========================| 3.2 MB 00:36 http://ftp.chg.ru/pub/Linux/fedora/linux/extras/development/i386/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. filelists.xml.gz 100% |=========================| 3.2 MB 00:17 http://mirror.switch.ch/ftp/mirror/fedora/linux/extras/development/i386/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. filelists.xml.gz 100% |=========================| 3.2 MB 00:15 ftp://fedora.bu.edu/fedora/extras/development/i386/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. filelists.xml.gz 100% |=========================| 3.2 MB 01:26 http://mirror.linux.duke.edu/pub/fedora/linux/extras/development/i386/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. filelists.xml.gz 100% |=========================| 3.1 MB 00:13 http://ftp.lug.ro/fedora/linux/extras/development/i386/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. filelists.xml.gz 100% |=========================| 3.2 MB 00:21 http://mirror.web-ster.com/fedora/extras/development/i386/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum Trying other mirror. filelists.xml.gz 100% |=========================| 3.0 MB 00:17 extras-dev: ################################################## 4225/4225 greetings, 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 jkeating at redhat.com Thu Mar 15 22:27:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Mar 2007 18:27:06 -0400 Subject: "Core" multilib is broken right now Message-ID: <200703151827.06937.jkeating@redhat.com> It may be due to some of the changes I made to the internal compose tool to do away with the RPMS/ dir, but it seems we're getting all packages as multilib (minus explicit blacklist) rather than the ones that are -devel + deps. I'll be working on fixing this tomorrow. -- 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 casimiro.barreto at gmail.com Thu Mar 15 22:40:12 2007 From: casimiro.barreto at gmail.com (casimiro barreto) Date: Thu, 15 Mar 2007 19:40:12 -0300 Subject: New kernel broke for x86_64 (Intel) Message-ID: <578ed5910703151540u113a5c00y593ee4d1546ebd04@mail.gmail.com> I've had a constant problem of getting a Dell server (dual Intel Pentium 4 Dual Core) locking. Apparently it is an issue related to the kernel 2.6.19-1.2911.6.4 and the newer ones. It is not handling correctly USB IRQs and I have a frozen box. Have someone else experienced the same problem? From mschwendt.tmp0701.nospam at arcor.de Thu Mar 15 22:43:39 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 15 Mar 2007 23:43:39 +0100 Subject: Fedora extras metadata In-Reply-To: <45F9C515.3060804@zoeloelip.be> References: <45F9C515.3060804@zoeloelip.be> Message-ID: <20070315234339.7065f318.mschwendt.tmp0701.nospam@arcor.de> On Thu, 15 Mar 2007 23:13:41 +0100, Bart Vanbrabant wrote: > Hello, > > What is going on with fedora extras metadata lately? Nothing. It's just the mirrors that choke on daily updates and don't sync safely and frequently enough. http://mirrors.kernel.org/fedora/extras/development/i386/repodata/ still contains metadata from March 11th, for instance. The Extras master site is never in an inconsistent state, because normal use of the script(e) we use doesn't allow that. That is, if something goes wrong during createrepo, we get a fatal error, and any incomplete changes are not published automatically. And for tomorrow, there are many updates in the queue again already: $ lspen fedora-development-extras: ccache-2.4-8.fc7 gaim-meanwhile-2.0.0-0.6.beta6.fc7 gconfmm26-2.18.0-1.fc7 gdal-1.4.0-15.fc7 glibmm24-2.12.7-1.fc7 glom-1.4.0-1.fc7 gnome-vfsmm26-2.18.0-1.fc7 gtk-murrine-engine-0.51-2.fc7 gtkmm24-2.10.8-1.fc7 hawknl-1.68-1.fc7 java-1.5.0-gcj-1.5.0.0-1.fc7 jd-1.8.8-0.1.cvs070315.fc7 libfreebob-1.0.3-1.fc7 libgnomemm26-2.18.0-1 libgnomeuimm26-2.18.0-1 linux_logo-4.16-1.fc7 maven-wagon-1.0-0.1.a5.3jpp.1.fc7 opensc-0.11.2-0.2.pre6.fc7 plexus-compiler-1.5.2-2jpp.2.fc7 poker-engine-1.0.24-1.fc7 poker-network-1.0.36-1.fc7 poker2d-1.0.36-1.fc7 qt4-4.2.3-3.fc7 rhino-1.6-0.1.r5.1jpp.2.fc7 scorchwentbonkers-1.1-2.fc7 xine-plugin-1.0-3.fc7 xtide-2.9.1-1.fc7 fedora-6-extras: gdal-1.4.0-15.fc6 gtk-murrine-engine-0.51-2.fc6 hawknl-1.68-1.fc6 linux_logo-4.16-1.fc6 poker-engine-1.0.24-1.fc6 poker-network-1.0.36-1.fc6 poker2d-1.0.36-1.fc6 qt4-4.2.3-3.fc6.1 scorchwentbonkers-1.1-2.fc6 xine-plugin-1.0-3.fc6 xtide-2.9.1-1.fc6 fedora-5-extras: gtk-murrine-engine-0.51-2.fc5 linux_logo-4.16-1.fc5 poker-engine-1.0.24-1.fc5 poker-network-1.0.36-1.fc5 poker2d-1.0.36-1.fc5 qt4-4.2.3-3.fc5 xtide-2.9.1-1.fc5 From alan at redhat.com Thu Mar 15 22:44:46 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 15 Mar 2007 18:44:46 -0400 Subject: User directories integration - request for help In-Reply-To: <1173988854.3535.0.camel@localhost.localdomain> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> Message-ID: <20070315224446.GC31956@devserv.devel.redhat.com> On Thu, Mar 15, 2007 at 04:00:54PM -0400, Matthias Clasen wrote: > > >From the looks of it, the directories get continually renamed if you > > switch languages. Stay away from my home dir, use a dot file if you > > must! > > Any you continually switch languages ?! Lots of people run two languages at once for different apps, and some folks routinely run two screens one per language, the classic example being translators where you don't want confusion but to "think" in one language per display. From alan at redhat.com Thu Mar 15 22:47:09 2007 From: alan at redhat.com (Alan Cox) Date: Thu, 15 Mar 2007 18:47:09 -0400 Subject: User directories integration - request for help In-Reply-To: <1173993597.3535.3.camel@localhost.localdomain> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <1173992650.5024.9.camel@rousalka.dyndns.org> <1173993597.3535.3.camel@localhost.localdomain> Message-ID: <20070315224709.GD31956@devserv.devel.redhat.com> On Thu, Mar 15, 2007 at 05:19:57PM -0400, Matthias Clasen wrote: > What do you mean ? These directories are in no way special or different > from any other directory you may create in your home directory. The only > difference is that we create them at login time, and that we make > desktop apps know about them. Please create them ONCE in the language the user logs in the first time. Having them renamed will break horribly especially if the user is logged in multiple times or running two languages at once Just drop in a dot file so you know you created them. From bart.vanbrabant at zoeloelip.be Thu Mar 15 22:52:39 2007 From: bart.vanbrabant at zoeloelip.be (Bart Vanbrabant) Date: Thu, 15 Mar 2007 23:52:39 +0100 Subject: Fedora extras metadata In-Reply-To: <20070315234339.7065f318.mschwendt.tmp0701.nospam@arcor.de> References: <45F9C515.3060804@zoeloelip.be> <20070315234339.7065f318.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45F9CE37.30806@zoeloelip.be> Michael Schwendt wrote: > On Thu, 15 Mar 2007 23:13:41 +0100, Bart Vanbrabant wrote: > >> Hello, >> >> What is going on with fedora extras metadata lately? > > Nothing. It's just the mirrors that choke on daily updates and don't sync > safely and frequently enough. > > http://mirrors.kernel.org/fedora/extras/development/i386/repodata/ > still contains metadata from March 11th, for instance. Ok, thanks. 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 pertusus at free.fr Thu Mar 15 23:01:08 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 16 Mar 2007 00:01:08 +0100 Subject: User directories integration - request for help In-Reply-To: <45F9A7A0.3010607@fedoraproject.org> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> Message-ID: <20070315230108.GA3261@free.fr> On Fri, Mar 16, 2007 at 01:38:00AM +0530, Rahul Sundaram wrote: > > If there are real practical reasons just cite that specifically. The use home directory shouldn't have non dot files (or directories) used by the applications. (There are allready the Desktop and GNUstep directories, but in my opinion they shouldn't be there). Reason is that the user home directory should be manually managed by the user solely, in order to keep a clear distinction between what is under the responsibility of the user and what may also be touched or used by applications. A user may still do links at will. And apps can go and look within dot files/directories and make directories appear even though they are not at a given filesystem location. -- Pat From mschwendt.tmp0701.nospam at arcor.de Thu Mar 15 23:14:46 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 16 Mar 2007 00:14:46 +0100 Subject: Fedora extras metadata In-Reply-To: <20070315234339.7065f318.mschwendt.tmp0701.nospam@arcor.de> References: <45F9C515.3060804@zoeloelip.be> <20070315234339.7065f318.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070316001446.9042a95d.mschwendt.tmp0701.nospam@arcor.de> But perhaps we should move repoview out of the repodata directory into parent dir. That would get rid of thousands of html files in the repodata tree and reduce the time mirrors spend in that tree. From sundaram at fedoraproject.org Thu Mar 15 23:18:47 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 Mar 2007 04:48:47 +0530 Subject: User directories integration - request for help In-Reply-To: <20070315230108.GA3261@free.fr> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> Message-ID: <45F9D457.5040009@fedoraproject.org> Patrice Dumas wrote: > On Fri, Mar 16, 2007 at 01:38:00AM +0530, Rahul Sundaram wrote: >> If there are real practical reasons just cite that specifically. > > The use home directory shouldn't have non dot files (or directories) > used by the applications. (There are allready the Desktop and GNUstep > directories, but in my opinion they shouldn't be there). What about documents? music? pictures? Applications shouldnt ever touch non hidden directories doesnt seem to be feasible. I understand if you dont want random programs dumping files into your desktop but I dont see the advantage of restricting applications to this extend. Rahul From mclasen at redhat.com Thu Mar 15 23:26:36 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 15 Mar 2007 19:26:36 -0400 Subject: User directories integration - request for help In-Reply-To: <20070315230108.GA3261@free.fr> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> Message-ID: <1174001196.3535.9.camel@localhost.localdomain> On Fri, 2007-03-16 at 00:01 +0100, Patrice Dumas wrote: > On Fri, Mar 16, 2007 at 01:38:00AM +0530, Rahul Sundaram wrote: > > > > If there are real practical reasons just cite that specifically. > > The use home directory shouldn't have non dot files (or directories) > used by the applications. Because we like to leave the user alone with the task of organizing his data, music, documents, etc ? To force them to learn something about filesystem organization and application configuration before they can use their systems ? Matthias From jlb17 at duke.edu Thu Mar 15 23:26:12 2007 From: jlb17 at duke.edu (Joshua Baker-LePain) Date: Thu, 15 Mar 2007 19:26:12 -0400 (EDT) Subject: User directories integration - request for help In-Reply-To: <1174001196.3535.9.camel@localhost.localdomain> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <1174001196.3535.9.camel@localhost.localdomain> Message-ID: On Thu, 15 Mar 2007 at 7:26pm, Matthias Clasen wrote > On Fri, 2007-03-16 at 00:01 +0100, Patrice Dumas wrote: >> On Fri, Mar 16, 2007 at 01:38:00AM +0530, Rahul Sundaram wrote: >>> >>> If there are real practical reasons just cite that specifically. >> >> The use home directory shouldn't have non dot files (or directories) >> used by the applications. > > Because we like to leave the user alone with the task of organizing his > data, music, documents, etc ? To force them to learn something about > filesystem organization and application configuration before they can > use their systems ? +1 -- Joshua "oh, wait, I think you were being sarcastic" Baker-LePain Department of Biomedical Engineering Duke University From pertusus at free.fr Thu Mar 15 23:45:46 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 16 Mar 2007 00:45:46 +0100 Subject: User directories integration - request for help In-Reply-To: <45F9D457.5040009@fedoraproject.org> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> Message-ID: <20070315234546.GB3261@free.fr> On Fri, Mar 16, 2007 at 04:48:47AM +0530, Rahul Sundaram wrote: > Patrice Dumas wrote: > >On Fri, Mar 16, 2007 at 01:38:00AM +0530, Rahul Sundaram wrote: > >>If there are real practical reasons just cite that specifically. > > > >The use home directory shouldn't have non dot files (or directories) > >used by the applications. (There are allready the Desktop and GNUstep > >directories, but in my opinion they shouldn't be there). > > What about documents? music? pictures? Applications shouldnt ever touch > non hidden directories doesnt seem to be feasible. I can select directories for apps to download into, but they shouldn't be created automatically without user interaction. > I understand if you > dont want random programs dumping files into your desktop but I dont see > the advantage of restricting applications to this extend. Indeed apps may use dirs, but only if they were configured. Configuring them the first time they are used seems also right to me if there isn't already a conf. -- Pat From pertusus at free.fr Thu Mar 15 23:48:50 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 16 Mar 2007 00:48:50 +0100 Subject: User directories integration - request for help In-Reply-To: <1174001196.3535.9.camel@localhost.localdomain> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <1174001196.3535.9.camel@localhost.localdomain> Message-ID: <20070315234850.GC3261@free.fr> On Thu, Mar 15, 2007 at 07:26:36PM -0400, Matthias Clasen wrote: > On Fri, 2007-03-16 at 00:01 +0100, Patrice Dumas wrote: > > On Fri, Mar 16, 2007 at 01:38:00AM +0530, Rahul Sundaram wrote: > > > > > > If there are real practical reasons just cite that specifically. > > > > The use home directory shouldn't have non dot files (or directories) > > used by the applications. > > Because we like to leave the user alone with the task of organizing his > data, music, documents, etc ? Not ecessarily, but don't impose an organization. > To force them to learn something about > filesystem organization and application configuration before they can > use their systems ? Not necessarily. The first time a file should be created, ask the user to confirm a directory name he wants to put the files in. For the default directory name, sure use the standardized one, but don't force it. -- Pat From sundaram at fedoraproject.org Fri Mar 16 00:05:17 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 Mar 2007 05:35:17 +0530 Subject: User directories integration - request for help In-Reply-To: <20070315234546.GB3261@free.fr> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> Message-ID: <45F9DF3D.7030305@fedoraproject.org> Patrice Dumas wrote: > On Fri, Mar 16, 2007 at 04:48:47AM +0530, Rahul Sundaram wrote: >> Patrice Dumas wrote: >>> On Fri, Mar 16, 2007 at 01:38:00AM +0530, Rahul Sundaram wrote: >>>> If there are real practical reasons just cite that specifically. >>> The use home directory shouldn't have non dot files (or directories) >>> used by the applications. (There are allready the Desktop and GNUstep >>> directories, but in my opinion they shouldn't be there). >> What about documents? music? pictures? Applications shouldnt ever touch >> non hidden directories doesnt seem to be feasible. > > I can select directories for apps to download into, but they shouldn't > be created automatically without user interaction. Why not? Selecting good defaults for all these is our responsibility. We shouldn't be pushing choices unnecessarily to the end users. Users can always customize it later. Rahul From davehoz at gmail.com Fri Mar 16 00:59:37 2007 From: davehoz at gmail.com (David Hunter) Date: Fri, 16 Mar 2007 11:59:37 +1100 Subject: Just an idea regarding pup/Software updater Message-ID: <6bb886180703151759m252bd500t89d8be4d4ed9b1e8@mail.gmail.com> Just an idea - its been pondering me for a while. I know with yum if you do the following commands: Either yum update yum update yum upgrade yum install It always tells you how many MB it is going to be for the download. Is there any option or configuration in pup to tell the total download for the software to be updated? What are people?s thoughts on the issue? -- David Hunter -------------- next part -------------- An HTML attachment was scrubbed... URL: From fs111 at web.de Fri Mar 16 01:01:42 2007 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9_Kelpe?=) Date: Fri, 16 Mar 2007 02:01:42 +0100 Subject: User directories integration - request for help In-Reply-To: <45F9DF3D.7030305@fedoraproject.org> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> Message-ID: <45F9EC76.2090300@web.de> Rahul Sundaram schrieb: >> >> I can select directories for apps to download into, but they shouldn't >> be created automatically without user interaction. > > Why not? Selecting good defaults for all these is our responsibility. > We shouldn't be pushing choices unnecessarily to the end users. Users > can always customize it later. Because many people hate it, when something automagically clutters up their home. My home is my castle :-)! I decide, not a tool, that thinks it knows better than me... Unix is about choice, not about "make everything, as it is in the other operating system, which has My Documents, My Music, My A**". -- Andr? From Axel.Thimm at ATrpms.net Fri Mar 16 01:08:18 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Mar 2007 02:08:18 +0100 Subject: with or without fedora-usermgmt In-Reply-To: <20070314154351.GC18364@nostromo.devel.redhat.com> References: <20070314151944.46717aa0@wrabco.brq.redhat.com> <20070314154351.GC18364@nostromo.devel.redhat.com> Message-ID: <20070316010818.GA12544@neu.nirvana> On Wed, Mar 14, 2007 at 11:43:51AM -0400, Bill Nottingham wrote: > Peter Vrabec (pvrabec at redhat.com) said: > > Don't you think somebody should make some decision here: > > http://www.redhat.com/archives/fedora-maintainers/2007-March/msg00124.html > > - flame, but possible pros and cons can be find there > > My opinion is not to use fedora-usermgmt. > > My proposal is to use 100-499 for static as well, and just do static > registrations for everything - it's simpler. It can be combined with > making dynamic system IDs go from 499 down as well. I don't think that most packages need static uids. And if there are really some that would benefit we still have 40% of the static uid space *empty*. So there really is no problem that had to be `fixed' in the first place. Extending the static uid range *now* would be wrong, because we would have to introduce "would-like-to have-static-uid-at-101-but-I-still- have-to-deal-with-getting-a-dynamical-random-uid-if-101-has-been-taken" giving us the worst combination: uid ranges labeled as fixed that the application(s) still cannot assume to be really fixed, so there is no gain today in doing so. Instead the patch that Peter wrote to make dynamic uid/gid allocation top-down, e.g. from 499 backwards, will allow us to revisit the issue in a couple of years when the static uids really get scarce (we managed a decade with occupying only 60%), and when the probability of having dynamic uids/gids at the lower end (100 upwards) will be much lower than today. In the meantime we can open a discussion with the LSB about rearranging the uid/gid space in future specs. If that ain't strategic planning ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Fri Mar 16 01:13:13 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 16 Mar 2007 06:43:13 +0530 Subject: User directories integration - request for help In-Reply-To: <45F9EC76.2090300@web.de> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> Message-ID: <45F9EF29.6020901@fedoraproject.org> Andr? Kelpe wrote: > Because many people hate it, when something automagically clutters up > their home. My home is my castle :-)! I decide, not a tool, that thinks > it knows better than me... Desktop is the folder you would seeing on a typical desktop environment. Not home. If are you not using a desktop environment, you wouldn't be using these applications either. So what they do would not affect you at all. Currently applications like Firefox actually save files into your desktop by default. Organizing the data better will result in less clutter. You can always customize it yourself. > Unix is about choice, not about "make everything, as it is in the other > operating system, which has My Documents, My Music, My A**". Again providing defaults for these applications doesn't take away your ability to customize anything. We have continued to adopt several ideas from other operating systems if that makes sense and that is a good thing. Rahul From jwilson at redhat.com Fri Mar 16 01:44:00 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 15 Mar 2007 21:44:00 -0400 Subject: New kernel broke for x86_64 (Intel) In-Reply-To: <578ed5910703151540u113a5c00y593ee4d1546ebd04@mail.gmail.com> References: <578ed5910703151540u113a5c00y593ee4d1546ebd04@mail.gmail.com> Message-ID: <45F9F660.80102@redhat.com> casimiro barreto wrote: > I've had a constant problem of getting a Dell server (dual Intel > Pentium 4 Dual Core) locking. Apparently it is an issue related to the > kernel 2.6.19-1.2911.6.4 and the newer ones. It is not handling > correctly USB IRQs and I have a frozen box. > > Have someone else experienced the same problem? Yep. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225399 -- Jarod Wilson jwilson at redhat.com From mattdm at mattdm.org Fri Mar 16 02:08:59 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Mar 2007 22:08:59 -0400 Subject: what makes a package get i386 on x86_64? In-Reply-To: <20070315231057.2c7f7179.mschwendt.tmp0701.nospam@arcor.de> References: <20070315213846.GA13190@jadzia.bu.edu> <20070315231057.2c7f7179.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070316020859.GA3080@jadzia.bu.edu> On Thu, Mar 15, 2007 at 11:10:57PM +0100, Michael Schwendt wrote: > Extras development: All i386 -devel packages (also virtual ones) and their > dependency chains are copied into the x86_64 repository unless the -devel > package is black-listed. Additionally, white-listed packages and their > dep-chains are copied. How hard is it to get a program added to the blacklist? Festival probably should be. And then I should do: %ifarch x86_64 Obsoletes: festival.i386 < 1.96 %endif yeah? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Fri Mar 16 02:26:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Mar 2007 22:26:09 -0400 Subject: what makes a package get i386 on x86_64? In-Reply-To: <20070316020859.GA3080@jadzia.bu.edu> References: <20070315213846.GA13190@jadzia.bu.edu> <20070315231057.2c7f7179.mschwendt.tmp0701.nospam@arcor.de> <20070316020859.GA3080@jadzia.bu.edu> Message-ID: <200703152226.10050.jkeating@redhat.com> On Thursday 15 March 2007 22:08:59 Matthew Miller wrote: > How hard is it to get a program added to the blacklist? Festival probably > should be. And then I should do: > %ifarch x86_64 > Obsoletes: festival.i386 < 1.96 > %endif First, I don't think you can reference arch like that in a spec. Secondly, why don't you split out the two libs into a festival-libs package, that is required by festival? festival-devel will pick up the library requires out of the -libs package, the libs package will have a generic requires on festival, not an arch specific one. This will leave festival-devel and festival-libs as multiarch, while festival itself is not. This is the solution that many other packages use. -- 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 jmpetre at gmail.com Fri Mar 16 02:38:15 2007 From: jmpetre at gmail.com (Jesse Petre) Date: Thu, 15 Mar 2007 22:38:15 -0400 Subject: New User With A Suggestion Message-ID: Hello Developers, I'm not entirely sure if this is the right place for me to be making this suggestion, but I strongly felt that it needs to be made. I've a very inexperienced linux user, and decided to give Fedora a try. This was three days ago, and only just today can I log into linux. The root of all problems came from the X config being installed with a default bit-depth of 24-bits. My monitor does not support 24-bit color, only 16 and 32, so after installing Fedora, my monitor would simply flash "input not supported". This may sound like a simple problem to you, but to me, a very inexperienced user, I was baffled as to why my monitor would not display the screen. It also was not helpful, at all, to leave out X configuration during the installation. I could have easily reinstalled Fedora, multiple times if necessary, and messed around with display settings to my heart's content. I am familiar with this. I am not familiar with learning how to switch to a virtual console, learn how to find the Xorg configuration file to edit manually (because system-config-display won't work -- it runs in 24-bits), and learn how to use an extremely confusing text editor (vi) from the console. Ultimately, my prime and strong suggestion is to change the default bit-depth installed to 16-bits, or at the least, allow users to configure X during the installation process. If this is the wrong place to be sending a suggestion, please let me know, and thanks for reading :) Jesse -------------- next part -------------- An HTML attachment was scrubbed... URL: From mattdm at mattdm.org Fri Mar 16 02:42:30 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Mar 2007 22:42:30 -0400 Subject: what makes a package get i386 on x86_64? In-Reply-To: <200703152226.10050.jkeating@redhat.com> References: <20070315213846.GA13190@jadzia.bu.edu> <20070315231057.2c7f7179.mschwendt.tmp0701.nospam@arcor.de> <20070316020859.GA3080@jadzia.bu.edu> <200703152226.10050.jkeating@redhat.com> Message-ID: <20070316024230.GA6280@jadzia.bu.edu> On Thu, Mar 15, 2007 at 10:26:09PM -0400, Jesse Keating wrote: > > How hard is it to get a program added to the blacklist? Festival probably > > should be. And then I should do: > > %ifarch x86_64 > > Obsoletes: festival.i386 < 1.96 > > %endif > First, I don't think you can reference arch like that in a spec. My understanding is that you can, as of 4.4.1. > Secondly, why don't you split out the two libs into a festival-libs package, > that is required by festival? festival-devel will pick up the library > requires out of the -libs package, the libs package will have a generic > requires on festival, not an arch specific one. This will leave > festival-devel and festival-libs as multiarch, while festival itself is not. > This is the solution that many other packages use. Hmmmm. Y'know, actually, I've already done that in the updated package. Well then. That's less annoying. :) But, I think I'll still need the above incantation to make upgrades work cleanly, right? Because otherwise, there'll be no upgrade target for the previous festival.i386 package on x86_64 systems. Or am I not thinking straight? It's been a long day. On another front, it turns out that there's a "libFestival.a" which hasn't been packaged for several years which would really need to be included for the devel package to be useful _at all_. Still thinking about what to do about that. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Fri Mar 16 02:45:05 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Mar 2007 22:45:05 -0400 Subject: New User With A Suggestion In-Reply-To: References: Message-ID: <20070316024505.GB6280@jadzia.bu.edu> On Thu, Mar 15, 2007 at 10:38:15PM -0400, Jesse Petre wrote: > Ultimately, my prime and strong suggestion is to change the default > bit-depth installed to 16-bits, or at the least, allow users to configure X > during the installation process. Ugh -- the first suggestion kind of sucks given that probably no one _wants_ 16 bits. And we'd really like to avoid the second. How about this: what's your monitor? File a bug in bugzilla reporting the model and detailed information, and that way, the auto-configuration can just get it right in the future. > If this is the wrong place to be sending a suggestion, please let me know, > and thanks for reading :) Actually, this is a great place for it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Fri Mar 16 02:48:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Mar 2007 22:48:33 -0400 Subject: what makes a package get i386 on x86_64? In-Reply-To: <20070316024230.GA6280@jadzia.bu.edu> References: <20070315213846.GA13190@jadzia.bu.edu> <200703152226.10050.jkeating@redhat.com> <20070316024230.GA6280@jadzia.bu.edu> Message-ID: <200703152248.33585.jkeating@redhat.com> On Thursday 15 March 2007 22:42:30 Matthew Miller wrote: > My understanding is that you can, as of 4.4.1. Hrm, I know you can on the cli, rpm -q foo.i386 rpm -e bar.x86_64, but you couldn't do arch specific things in the spec, like BuildRequires glibc.i386 or some such. -- 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 Fri Mar 16 02:55:36 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Mar 2007 22:55:36 -0400 Subject: what makes a package get i386 on x86_64? In-Reply-To: <200703152248.33585.jkeating@redhat.com> References: <20070315213846.GA13190@jadzia.bu.edu> <200703152226.10050.jkeating@redhat.com> <20070316024230.GA6280@jadzia.bu.edu> <200703152248.33585.jkeating@redhat.com> Message-ID: <20070316025536.GC6280@jadzia.bu.edu> On Thu, Mar 15, 2007 at 10:48:33PM -0400, Jesse Keating wrote: > > My understanding is that you can, as of 4.4.1. > Hrm, I know you can on the cli, rpm -q foo.i386 rpm -e bar.x86_64, but you > couldn't do arch specific things in the spec, like BuildRequires glibc.i386 > or some such. The changes file says "use package color as Obsoletes: color", which I guess may mean that obsoletes now _only_ affect their own arch, not all archs. I suppose I'll test and find out. Otherwise, what's the solution? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jmpetre at gmail.com Fri Mar 16 02:57:44 2007 From: jmpetre at gmail.com (Jesse Petre) Date: Thu, 15 Mar 2007 22:57:44 -0400 Subject: New User With A Suggestion In-Reply-To: <20070316024505.GB6280@jadzia.bu.edu> References: <20070316024505.GB6280@jadzia.bu.edu> Message-ID: Alright, I'll go file the bug. Thanks for writing back :) On 3/15/07, Matthew Miller wrote: > > On Thu, Mar 15, 2007 at 10:38:15PM -0400, Jesse Petre wrote: > > Ultimately, my prime and strong suggestion is to change the default > > bit-depth installed to 16-bits, or at the least, allow users to > configure X > > during the installation process. > > Ugh -- the first suggestion kind of sucks given that probably no one > _wants_ > 16 bits. And we'd really like to avoid the second. > > How about this: what's your monitor? File a bug in bugzilla reporting the > model and detailed information, and that way, the auto-configuration can > just get it right in the future. > > > If this is the wrong place to be sending a suggestion, please let me > know, > > and thanks for reading :) > > Actually, this is a great place for it. > > -- > Matthew Miller mattdm at mattdm.org > Boston University Linux ------> > > -- > 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 jkeating at redhat.com Fri Mar 16 03:05:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Mar 2007 23:05:20 -0400 Subject: what makes a package get i386 on x86_64? In-Reply-To: <20070316025536.GC6280@jadzia.bu.edu> References: <20070315213846.GA13190@jadzia.bu.edu> <200703152248.33585.jkeating@redhat.com> <20070316025536.GC6280@jadzia.bu.edu> Message-ID: <200703152305.20750.jkeating@redhat.com> On Thursday 15 March 2007 22:55:36 Matthew Miller wrote: > Otherwise, what's the solution? I'm not sure :/ -- 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 naheemzaffar at gmail.com Fri Mar 16 03:06:28 2007 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Fri, 16 Mar 2007 03:06:28 +0000 Subject: User directories integration - request for help In-Reply-To: <45F9EF29.6020901@fedoraproject.org> References: <1173953610.10024.132.camel@greebo> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> Message-ID: <3adc77210703152006g20adce56x9f003083454a9da6@mail.gmail.com> This will probably be a totally stupid idea, but I have to mention it. Why not dump everything in the home folder as standard and then use that nautilus search folders thing to organise everything? We can then, for example have a pictures search folder that lists all pictures. A Documents folder that lists documents AND the picture formats we think of as documents? i18n should not be aproblem as only a search folder is renamed (or just translated...), not a real folder. It should clear up alot of messy situations, The only issues I can see are if this idea is a little too gnome centric, and resource usage. From jcm at redhat.com Fri Mar 16 03:12:36 2007 From: jcm at redhat.com (Jon Masters) Date: Thu, 15 Mar 2007 23:12:36 -0400 Subject: User directories integration - request for help In-Reply-To: <3adc77210703152006g20adce56x9f003083454a9da6@mail.gmail.com> References: <1173953610.10024.132.camel@greebo> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> <3adc77210703152006g20adce56x9f003083454a9da6@mail.gmail.com> Message-ID: <45FA0B24.6010302@redhat.com> Naheem Zaffar wrote: > Why not dump everything in the home folder as standard and then use > that nautilus search folders thing to organise everything? Too GNOME-specific/centric, as you had hinted at. Although many of us run GNOME desktops these days - I held out for years, then gave in - personally I'd hate the idea of relying on GNOME for things to make sense. I don't like default folders being made either, but it works. Jon. From mattdm at mattdm.org Fri Mar 16 03:16:25 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 15 Mar 2007 23:16:25 -0400 Subject: what makes a package get i386 on x86_64? In-Reply-To: <200703152305.20750.jkeating@redhat.com> References: <20070315213846.GA13190@jadzia.bu.edu> <200703152248.33585.jkeating@redhat.com> <20070316025536.GC6280@jadzia.bu.edu> <200703152305.20750.jkeating@redhat.com> Message-ID: <20070316031625.GA8972@jadzia.bu.edu> On Thu, Mar 15, 2007 at 11:05:20PM -0400, Jesse Keating wrote: > > Otherwise, what's the solution? > I'm not sure :/ %ifarch i386 %post cat << EOF > /etc/cron.daily/ditch386.sh #!/bin/bash if [ "$( rpm -q festival.i386 --qf 'true')" == "true" ]; then if [ "$( rpm -q festival.x86_64 --qf 'true')" == "true" ]; then rpm -e festival.i386 if [ "$( rpm -q festival.i386 --qf 'true')" != "true" ]; then rm /etc/cron.daily/ditch386.sh fi; fi; fi EOF chmod +x /etc/cron.daily/ditch386.sh %endif Okay, I should go to sleep. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From naoki at valuecommerce.com Fri Mar 16 03:23:23 2007 From: naoki at valuecommerce.com (Naoki) Date: Fri, 16 Mar 2007 12:23:23 +0900 Subject: New kernel broke for x86_64 (Intel) In-Reply-To: <578ed5910703151540u113a5c00y593ee4d1546ebd04@mail.gmail.com> References: <578ed5910703151540u113a5c00y593ee4d1546ebd04@mail.gmail.com> Message-ID: <1174015403.1343.2.camel@localhost.localdomain> If you are seeing "do_IRQ" errors, then it's the IRQ migration bug and is really a pain in the proverbial. I opened this BZ for it : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227961 The workaround is to disable the irqbalance daemon. On Thu, 2007-03-15 at 19:40 -0300, casimiro barreto wrote: > I've had a constant problem of getting a Dell server (dual Intel > Pentium 4 Dual Core) locking. Apparently it is an issue related to the > kernel 2.6.19-1.2911.6.4 and the newer ones. It is not handling > correctly USB IRQs and I have a frozen box. > > Have someone else experienced the same problem? > From mitr at volny.cz Fri Mar 16 04:16:26 2007 From: mitr at volny.cz (Miloslav Trmac) Date: Fri, 16 Mar 2007 05:16:26 +0100 Subject: [RFC] Filesystem-local databases in mlocate Message-ID: <45FA1A1A.9060201@volny.cz> Hi, I'm planning to add filesystem-local database support to mlocate. This allows: - running updatedb on a file server and making the database automatically available to clients without any client-side configuration - using locate on GFS volumes without running updatedb on each host that has the volume mounted (which slows the volumes down due to lock contention) The plan: * the mlocate.db format is extended to support databases without a fixed path prefix, such that all entries in a database in /foo/bar/.mlocate/mlocate.db are implicitly prefixed by /foo/bar. (this allows using /srv/home on the file server, mounting it as /home, and using a single database on both the server and the client). * locate(1)'s default database is not just /var/lib/mlocate/mlocate.db; mlocate also checks each mounted filesystem for a .mlocate/mlocate.db file, owned by root or the invoking user, and not writable by anyone but the owner. Such files are automatically added to the database path. * To allow overriding this check, the LOCATE_PATH variable is changed to override the default database path instead of appending to the database path. *note*: this is an incompatible change * updatedb(8) gets a new option, --single-fs PATH. This option generates a database in PATH/.mlocate/mlocate.db that spans only the subtree of PATH. filesystems mounted in subdirectories of PATH are automatically excluded, PRUNEFS is ignored. PRUNEPATHS is honored, except for PATH itself. * /etc/cron.daily/mlocate reads /etc/sysconfig/mlocate to get a list of single-fs PATHs. For each PATH it checks PATH/.mlocate/mlocate.db is older than 12 hours, creates a lock to prevent a concurrent updatedb, and runs updatedb --single-fs PATH. The standard daily run is performed as well, with all entries of /etc/sysconfig/mlocate added to PRUNEPATHS automatically. Usage for /home on NFS: - NFS is automatically excluded by clients, so updatedb on clients does not walk the filesystem. - On the server: Add /srv/home to /etc/sysconfig/mlocate. If /srv/home is not a separate mount point, add LOCATE_PATH=:/srv/home/.mlocate/mlocate.db to the global environment. Usage for /home on GFS: - GFS is automatically excluded, so no host walks the filesystem by default. - On all hosts: add /home to /etc/sysconfig/mlocate Can anyone see a problem with the plan, or an important feature that the above fails to address? Thanks, Mirek From jkeating at redhat.com Fri Mar 16 04:40:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Mar 2007 00:40:16 -0400 Subject: "Core" multilib is broken right now In-Reply-To: <200703151827.06937.jkeating@redhat.com> References: <200703151827.06937.jkeating@redhat.com> Message-ID: <200703160040.19317.jkeating@redhat.com> On Thursday 15 March 2007 18:27:06 Jesse Keating wrote: > It may be due to some of the changes I made to the internal compose tool to > do away with the RPMS/ dir, but it seems we're getting all packages as > multilib (minus explicit blacklist) rather than the ones that are -devel + > deps. I'll be working on fixing this tomorrow. I do believe I've fixed this. We'll see what happens for tomorrow's rawhide (: -- 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 Fri Mar 16 05:17:46 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 16 Mar 2007 00:17:46 -0500 Subject: New User With A Suggestion In-Reply-To: References: Message-ID: <16de708d0703152217t1cd7d259ke84c15a7e41cf029@mail.gmail.com> On 3/15/07, Jesse Petre wrote: > Hello Developers, > > I'm not entirely sure if this is the right place for me to be making this > suggestion, but I strongly felt that it needs to be made. Well this isn't the developers list, but that's okay. > I've a very inexperienced linux user, and decided to give Fedora a try. Glad to hear that, sorry that your first experience was bad, don't judge Fedora too harshly by that. > This was three days ago, and only just today can I log into linux. In future, head over to irc://freenode/fedora as soon as possible, your problems would have been solved much quicker. > The root of all problems came from the X config being installed with a > default bit-depth of 24-bits. My monitor does not support 24-bit color, > only 16 and 32, so after installing Fedora, my monitor would simply flash > "input not supported". This may sound like a simple problem to you, but to > me, a very inexperienced user, I was baffled as to why my monitor would not > display the screen. It is actually quite a simple problem, but it is however difficult if you haven't had that much experience. > It also was not helpful, at all, to leave out X > configuration during the installation. I could have easily reinstalled > Fedora, multiple times if necessary, and messed around with display settings > to my heart's content. I agree, I am one of those who is very much against not having the graphical setup as part of the fresh installation, it was there in Fedora Core 5. I have had this very problem myself at least 6 times. > I am familiar with this. I am not familiar with > learning how to switch to a virtual console, learn how to find the Xorg > configuration file to edit manually (because system-config-display won't > work -- it runs in 24-bits) Also true. > , and learn how to use an extremely confusing > text editor (vi) from the console. Fedora comes with a much simpler text editor, aimed at newbies, called 'nano' > Ultimately, my prime and strong suggestion is to change the default > bit-depth installed to 16-bits, or at the least, allow users to configure X > during the installation process. I agree with your later suggestion, I have been told that the problem will be fixed by Fedora 7, I am not sure how they intend on fixing it, but I have been assured that the developers are aware of the problem. > If this is the wrong place to be sending a suggestion, please let me know, > and thanks for reading :) You're welcome. > Jesse Peace. -- Fedora Core 6 and proud From mschwendt.tmp0701.nospam at arcor.de Fri Mar 16 07:08:54 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 16 Mar 2007 08:08:54 +0100 Subject: what makes a package get i386 on x86_64? In-Reply-To: <200703152226.10050.jkeating@redhat.com> References: <20070315213846.GA13190@jadzia.bu.edu> <20070315231057.2c7f7179.mschwendt.tmp0701.nospam@arcor.de> <20070316020859.GA3080@jadzia.bu.edu> <200703152226.10050.jkeating@redhat.com> Message-ID: <20070316080854.8771175a.mschwendt.tmp0701.nospam@arcor.de> On Thu, 15 Mar 2007 22:26:09 -0400, Jesse Keating wrote: > On Thursday 15 March 2007 22:08:59 Matthew Miller wrote: > > How hard is it to get a program added to the blacklist? Festival probably > > should be. And then I should do: > > %ifarch x86_64 > > Obsoletes: festival.i386 < 1.96 > > %endif > > First, I don't think you can reference arch like that in a spec. > > Secondly, why don't you split out the two libs into a festival-libs package, > that is required by festival? festival-devel will pick up the library > requires out of the -libs package, the libs package will have a generic > requires on festival, not an arch specific one. If festival-libs required festival, the split would be pointless as we first would need to create a multi-lib resolver that works like that and implements a well-defined way and/or copies yum's exact behaviour. If foo-devel.i386 requires bar-devel and bar-devel is provided by bar.x86_64 as well as bar.i386, what happens? If foo-devel.i386 requires foo = %version-release, the spec can't require foo.i386, so would foo.x86_64 also be sufficient? The split would be pointless on a single arch, too, as festival-libs would always pull in festival. Unless there is a typo in your comment. > This will leave > festival-devel and festival-libs as multiarch, while festival itself is not. > This is the solution that many other packages use. From tmus at tmus.dk Fri Mar 16 07:17:47 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 16 Mar 2007 08:17:47 +0100 Subject: Fedora extras metadata In-Reply-To: <20070315234339.7065f318.mschwendt.tmp0701.nospam@arcor.de> References: <45F9C515.3060804@zoeloelip.be> <20070315234339.7065f318.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt wrote: >> >> What is going on with fedora extras metadata lately? > > Nothing. It's just the mirrors that choke on daily updates and don't sync > safely and frequently enough. > This seems to be happening more often that we could hope for. Is there a documented way to set up mirroring, to ENSURE that the mirrors are in a consistent state? If not - and I believe this has been brought up earlier (by myself). I really think we could do with a simple timestamping mirror handshake mechanism, kinda like what debian does. This would allow mirrors to monitor for a special file and when that file is available, we know the mirror is in a consistent state (as consistent as it's master - which can also be tracked in this way). Mirrors could easily add a few lines to their scripts to honor this kind of thing, without the need for special mirroring tools. Just a suggestion /Thomas From tmus at tmus.dk Fri Mar 16 07:36:28 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 16 Mar 2007 08:36:28 +0100 Subject: Fedora extras metadata In-Reply-To: References: <45F9C515.3060804@zoeloelip.be> <20070315234339.7065f318.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Thomas M Steenholdt wrote: > ( ... ) Mirrors could easily add a few lines > to their scripts to honor this kind of thing, without the need for > special mirroring tools. > Yum could easily use the very same technique to make a quick *validation* of a mirror before it goes on to download the large files... This should be done in a plugin though, since this is not related directly to yum. /Thomas From fedora at camperquake.de Fri Mar 16 07:46:42 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 16 Mar 2007 08:46:42 +0100 Subject: rawhide report: 20070315 changes In-Reply-To: <200703151630.56906.jkeating@redhat.com> References: <1173979254.3163.2.camel@sonlaptop> <200703151630.56906.jkeating@redhat.com> Message-ID: <20070316084642.2ed8122e@banea.int.addix.net> Hi. On Thu, 15 Mar 2007 16:30:56 -0400, Jesse Keating wrote: > It should be in Extras now. Which is merged with Core now? Or is it? From fedora at camperquake.de Fri Mar 16 07:52:16 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 16 Mar 2007 08:52:16 +0100 Subject: User directories integration - request for help In-Reply-To: <45F9A7A0.3010607@fedoraproject.org> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> Message-ID: <20070316085216.1457851f@banea.int.addix.net> Hi. On Fri, 16 Mar 2007 01:38:00 +0530, Rahul Sundaram wrote: > > Renaming a user's directories doesn't seem to be "The UNIX Way" TM > > Traditional Unix systems never had to deal with many of the modern > desktop requirements so it's high time we stopped citing the "the > unix way" as a excuse not to change anything. All modern Linux > desktop systems happily automount devices which is distinctly not > unixy either. If there are real practical reasons just cite that > specifically. OSX gets this right, from what I remember. The applications folder is always called "Applications" on disk, but the displayed name in Finder (and open/save dialogs) is specific to the language settings of the current user. This is true for system wide folders and folders in users home dirs. I do not know what MS does with their "Program Files" folder. From nicolas.mailhot at laposte.net Fri Mar 16 07:55:53 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 16 Mar 2007 08:55:53 +0100 (CET) Subject: [RFC] Filesystem-local databases in mlocate In-Reply-To: <45FA1A1A.9060201@volny.cz> References: <45FA1A1A.9060201@volny.cz> Message-ID: <58979.192.54.193.51.1174031753.squirrel@rousalka.dyndns.org> Le Ven 16 mars 2007 05:16, Miloslav Trmac a ?crit : > Can anyone see a problem with the plan, or an important feature that the > above fails to address? 1. You're spreading rw files all over the filesystems, which is contrary to the FHS. 2. You're putting hidden directories where people won't expect them, which will seriously annoy sysadmins I don't have any magic solution, but IMHO you need to think about file location & naming a little more. -- Nicolas Mailhot From giallu at gmail.com Fri Mar 16 08:05:45 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 16 Mar 2007 09:05:45 +0100 Subject: Not signed updates Message-ID: This is probably known but, just in case, I just received in my local mirror updates for: tcpdump-3.9.4-10.fc6.i386.rpm libpcap-0.9.4-10.fc6.i386.rpm whose are 1. not announced in fedora-package-announce (though probably this not a problem) 2. not signed Cheers Gianluca From buildsys at fedoraproject.org Fri Mar 16 08:13:02 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 16 Mar 2007 04:13:02 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-16 Message-ID: <20070316081302.A3C7F152130@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 40 aquamarine-0.2.0-1.fc7 bdock-0.2.0-1.fc7 beryl-core-0.2.0-1.fc7 beryl-manager-0.2.0-1.fc7 beryl-plugins-0.2.0-1.fc7 beryl-settings-0.2.0-1.fc7 ccache-2.4-8.fc7 emerald-0.2.0-1.fc7 emerald-themes-0.2.0-1.fc7 NEW firmware-addon-dell-1.2.2-1.fc7 NEW firmware-tools-1.2.3-1.fc7 gaim-meanwhile-2.0.0-0.6.beta6.fc7 gconfmm26-2.18.0-1.fc7 gdal-1.4.0-15.fc7 glibmm24-2.12.7-1.fc7 glom-1.4.0-1.fc7 gnome-vfsmm26-2.18.0-1.fc7 gtk-murrine-engine-0.51-2.fc7 gtkmm24-2.10.8-1.fc7 NEW hawknl-1.68-1.fc7 heliodor-0.2.0-1.fc7 NEW java-1.5.0-gcj-1.5.0.0-2.fc7 jd-1.8.8-0.1.cvs070315.1.fc7 libfreebob-1.0.3-1.fc7 libgnomemm26-2.18.0-1 libgnomeuimm26-2.18.0-1 linux_logo-4.16-1.fc7 NEW maven-wagon-1.0-0.1.a5.3jpp.1.fc7 opensc-0.11.2-0.2.pre6.fc7 plexus-compiler-1.5.2-2jpp.2.fc7 poker-engine-1.0.24-1.fc7 poker-network-1.0.36-1.fc7 poker2d-1.0.36-1.fc7 qt4-4.2.3-3.fc7 rhino-1.6-0.1.r5.1jpp.2.fc7 NEW scorchwentbonkers-1.1-2.fc7 NEW sinjdoc-0.5-1.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.2987.fc7 NEW xine-plugin-1.0-3.fc7 xtide-2.9.1-1.fc7 Packages built and released for Fedora Extras 6: 12 NEW firmware-tools-1.2.3-1.fc6 gdal-1.4.0-15.fc6 gtk-murrine-engine-0.51-2.fc6 NEW hawknl-1.68-1.fc6 linux_logo-4.16-1.fc6 poker-engine-1.0.24-1.fc6 poker-network-1.0.36-1.fc6 poker2d-1.0.36-1.fc6 qt4-4.2.3-3.fc6.1 NEW scorchwentbonkers-1.1-2.fc6 NEW xine-plugin-1.0-3.fc6 xtide-2.9.1-1.fc6 Packages built and released for Fedora Extras 5: 7 gtk-murrine-engine-0.51-2.fc5 linux_logo-4.16-1.fc5 poker-engine-1.0.24-1.fc5 poker-network-1.0.36-1.fc5 poker2d-1.0.36-1.fc5 qt4-4.2.3-3.fc5 xtide-2.9.1-1.fc5 aquamarine-0.2.0-1.fc7 ---------------------- * Thu Mar 15 2007 Jarod Wilson 0.2.0-1 - beryl 0.2.0 bdock-0.2.0-1.fc7 ----------------- * Thu Mar 15 2007 Jarod Wilson 0.2.0-1 - beryl 0.2.0 -- though outside of the VERSION file, bdock hasn't actually changed in like five months and the project doesn't roll tarballs of it... beryl-core-0.2.0-1.fc7 ---------------------- * Thu Mar 15 2007 Jarod Wilson 0.2.0-1 - beryl 0.2.0 beryl-manager-0.2.0-1.fc7 ------------------------- * Thu Mar 15 2007 Jarod Wilson 0.2.0-1 - beryl 0.2.0 beryl-plugins-0.2.0-1.fc7 ------------------------- * Thu Mar 15 2007 Jarod Wilson 0.2.0 - beryl 0.2.0 beryl-settings-0.2.0-1.fc7 -------------------------- * Thu Mar 15 2007 Jarod Wilson 0.2.0 - beryl 0.2.0 ccache-2.4-8.fc7 ---------------- * Thu Mar 15 2007 Ville Skytt? - 2.4-8 - Bypass cache with --coverage, -fprofile-arcs and -ftest-coverage (upstream CVS and Matt Fago, #231462). emerald-0.2.0-1.fc7 ------------------- * Thu Mar 15 2007 Jarod Wilson 0.2.0 - beryl 0.2.0 emerald-themes-0.2.0-1.fc7 -------------------------- * Thu Mar 15 2007 Jarod Wilson 0.2.0-1 - beryl 0.2.0 firmware-addon-dell-1.2.2-1.fc7 ------------------------------- * Thu Mar 15 2007 Michael E Brown - 1.2.2-1 - Trivial changes to add specific {_datadir}/firmware/dell * Thu Mar 15 2007 Michael E Brown - 1.2.1-1 - Trivial changes to make rpmlint happier * Wed Mar 14 2007 Michael E Brown - 1.2.0-1 - Fedora-compliant packaging changes. firmware-tools-1.2.3-1.fc7 -------------------------- * Wed Mar 14 2007 Michael E Brown - 1.2.3-1 - create and own {_sysconfdir}/firmware/firmware.d/ for plugins. - Fedora review changes * Mon Mar 12 2007 Michael E Brown - 1.2.0-1 - Fedora-compliant packaging changes. gaim-meanwhile-2.0.0-0.6.beta6.fc7 ---------------------------------- * Wed Mar 14 2007 Josh Boyer 2.0.0-0.6.beta6 - Rebuidl against most recent core package gconfmm26-2.18.0-1.fc7 ---------------------- * Thu Mar 15 2007 Denis Leroy - 2.18.0-1 - Update to Gnome 2.18, to follow GConf2 version * Mon Aug 28 2006 Denis Leroy - 2.16.0-2 - FE6 Rebuild gdal-1.4.0-15.fc7 ----------------- * Thu Mar 15 2007 Balint Cristian 1.4.0-15 - require pkgconfig - generate pkgconfig from spec instead * Thu Mar 15 2007 Balint Cristian 1.4.0-14 - require perl(ExtUtils::MakeMaker) instead ?dist checking - add pkgconfig file glibmm24-2.12.7-1.fc7 --------------------- * Thu Mar 15 2007 Denis Leroy - 2.12.7-1 - Update to 2.12.7 glom-1.4.0-1.fc7 ---------------- * Thu Mar 15 2007 Denis Leroy - 1.4.0-1 - Update to 1.4.0 gnome-vfsmm26-2.18.0-1.fc7 -------------------------- * Thu Mar 15 2007 Denis Leroy - 2.18.0-1 - Update to Gnome 2.18, to follow gnome-vfs2 version - Added dist tag gtk-murrine-engine-0.51-2.fc7 ----------------------------- * Thu Mar 15 2007 Leo, Shidai Liu 0.51-2 - fix last change * Thu Mar 15 2007 Leo, Shidai Liu 0.51-1 - 0.51 gtkmm24-2.10.8-1.fc7 -------------------- * Thu Mar 15 2007 Denis Leroy - 2.10.8-1 - Update to 2.10.8 hawknl-1.68-1.fc7 ----------------- * Mon Mar 12 2007 Hans de Goede 1.68-1 - Initial FE package heliodor-0.2.0-1.fc7 -------------------- * Thu Mar 15 2007 Jarod Wilson 0.2.0 - beryl 0.2.0 java-1.5.0-gcj-1.5.0.0-2.fc7 ---------------------------- * Thu Mar 15 2007 Thomas Fitzsimmons - 1.5.0.0-2.fc7 - Set bootstrap to 0 to build javadoc sub-package, now that sinjdoc has been built. - Add temporary gjdoc build requirement. * Thu Mar 15 2007 Thomas Fitzsimmons - 1.5.0.0-1.fc7 - Set bootstrap to 1 since sinjdoc is not yet available to build javadocs. - Import java-gcj-compat 1.0.70. - Port java-1.4.2-gcj-compat to java-1.5.0-gcj. jd-1.8.8-0.1.cvs070315.1.fc7 ---------------------------- * Fri Mar 16 2007 Mamoru Tasaka - Remove size_t warning * Thu Mar 15 2007 Mamoru Tasaka - 1.8.8-0.1.cvs070315 - cvs 070315 (24:55 JST) libfreebob-1.0.3-1.fc7 ---------------------- * Thu Mar 15 2007 Anthony Green 1.0.3-1 - Upgrade sources to 1.0.3. libgnomemm26-2.18.0-1 --------------------- * Thu Mar 15 2007 Denis Leroy - 2.18.0-1 - Update to Gnome 2.18, to follow libgnome2 version libgnomeuimm26-2.18.0-1 ----------------------- * Thu Mar 15 2007 Denis Leroy - 2.18.0-1 - Update to Gnome 2.18, to follow libgnomeui version linux_logo-4.16-1.fc7 --------------------- * Thu Mar 15 2007 Matthias Saou 4.16-1 - Update to 4.16. maven-wagon-1.0-0.1.a5.3jpp.1.fc7 --------------------------------- * Tue Mar 13 2007 Matt Wringe - 0:1.0-0.1.a5.3jpp.1 - Merge in the changes neeeded to build without jetty - Fix rpmlint issues - Generate new *-build.xml files from pom.xml files as origins of *-project files is unknown. - Remove maven1 project.xml files from sources - Comment out various section requiring maven or javadocs (to be re-enabled at a future time). Note that the ant:ant task for maven2 does not currently generate javadocs. opensc-0.11.2-0.2.pre6.fc7 -------------------------- * Thu Mar 15 2007 Ville Skytt? - 0.11.2-0.2.pre6 - 0.11.2-pre6. plexus-compiler-1.5.2-2jpp.2.fc7 -------------------------------- * Thu Mar 15 2007 Deepak Bhole - 0:1.5.2-2jpp.2 - Fix bug in spec that prevented unversioned symlink creation poker-engine-1.0.24-1.fc7 ------------------------- * Thu Mar 15 2007 Christopher Stone 1.0.24-1 - Upstream sync poker-network-1.0.36-1.fc7 -------------------------- * Thu Mar 15 2007 Christopher Stone 1.0.36-1 - Upstream sync poker2d-1.0.36-1.fc7 -------------------- * Thu Mar 15 2007 Christopher Stone 1.0.36-1 - Upstream sync qt4-4.2.3-3.fc7 --------------- * Thu Mar 15 2007 Rex Dieter 4.2.3-3 - make /etc/rpm/macros.qt4 owned only by qt4-devel * Thu Mar 15 2007 Rex Dieter 4.2.3-2 - fix mkspecs/common availability (#232392) rhino-1.6-0.1.r5.1jpp.2.fc7 --------------------------- * Thu Mar 15 2007 Matt Wringe 0:1.6-0.1.r5.1jpp.2 - Remove script from build as the debugging tool is disabled due to it containing proprietary code from Sun. scorchwentbonkers-1.1-2.fc7 --------------------------- * Tue Mar 13 2007 Hans de Goede 1.1-2 - Fix a divide by zero crash when playing against the computer - Add missing BuildRequires: jpgalleg-devel, libGLU-devel sinjdoc-0.5-1.fc7 ----------------- * Thu Mar 15 2007 Thomas Fitzsimmons - 0.5-1 - Initial release. sysprof-kmod-1.0.8-1.2.6.20_1.2987.fc7 -------------------------------------- xine-plugin-1.0-3.fc7 --------------------- * Wed Mar 14 2007 Martin Sourada - 1.0-3 - fix rpmlint warning * Tue Mar 13 2007 Martin Sourada - 1.0-2 - add BR: xorg-x11-proto-devel, libX11-devel xtide-2.9.1-1.fc7 ----------------- * Thu Mar 15 2007 Mamoru Tasaka - 2.9.1-1 - 2.9.1 * Wed Feb 28 2007 Mamoru Tasaka - 2.9-1 - 2.9 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From alexl at redhat.com Fri Mar 16 08:54:48 2007 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 16 Mar 2007 09:54:48 +0100 Subject: User directories integration - request for help In-Reply-To: <45F92B9F.5090409@redhat.com> References: <1173953610.10024.132.camel@greebo> <45F92B9F.5090409@redhat.com> Message-ID: <1174035288.10024.171.camel@greebo> On Thu, 2007-03-15 at 16:48 +0530, A S Alam wrote: > > eog/gthumb/f-spot: PICTURES as default for file selector > > > Any idea about KDE applications? are those usefuly for kde? Sure, the idea is for KDE to support this too. To really integrate well it would need some work on the kde core too. For instance, xdg-user-dirs-gtk adds default bookmarks to the file selector and the nautilus integration uses it to find the desktop folder and tracks changes to these folders and updates the config files. Something similar should be done in kde. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a time-tossed amnesiac dog-catcher haunted by memories of 'Nam. She's an enchanted winged queen of the dead with a flame-thrower. They fight crime! From alexl at redhat.com Fri Mar 16 08:57:33 2007 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 16 Mar 2007 09:57:33 +0100 Subject: User directories integration - request for help In-Reply-To: <36175.192.54.193.51.1173968308.squirrel@rousalka.dyndns.org> References: <1173953610.10024.132.camel@greebo> <1173964884.3339.18.camel@localhost.localdomain> <45F94E31.2080405@nicubunu.ro> <60599.142.205.241.254.1173963440.squirrel@lattica.com> <36175.192.54.193.51.1173968308.squirrel@rousalka.dyndns.org> Message-ID: <1174035453.10024.174.camel@greebo> On Thu, 2007-03-15 at 15:18 +0100, Nicolas Mailhot wrote: > Le Jeu 15 mars 2007 13:57, Dimi Paun a ?crit : > > > > On Thu, March 15, 2007 09:46, Nicu Buculei wrote: > >> I don't know, a PNG or JPG to open/save with GIMP may be expected in > >> PICTURES but XCF is more likely to go in DOCUMENTS. > >> And probably the same for Inkscape: SVG is a document and PNG a picture. > > > > Not necessarily. IMO PICTURES/DOCUMENTS is not to be decided blindly > > on the extension of the file, that's useless, but rather on the > > intended use for the file. > > > > In other words, it seems to me that PICTURES should really hold things > > that qualify as photos. > > IMHO PICTURES should be PHOTOS period. The file type is less important > that the usage pattern: > - everything that comes from the outside (mail, internet) -> DOWNLOAD > - files I work on -> DOCUMENTS > - static media content library -> MUSIC, PHOTOS, VIDEO > > That means media editors look in DOCUMENTS, media players in MUSIC, > PHOTOS, VIDEO, and internet tools in DOWNLOAD For those that especially like this, xdg-user-dirs also has translations for Photos and photos, so if you change /etc/xdg/user-dirs.defaults to have: PICTURES=Photos Then users will get a translated photos directories for the PICTURES location. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a scarfaced day-dreaming werewolf plagued by the memory of his family's brutal murder. She's a tortured French-Canadian archaeologist from the wrong side of the tracks. They fight crime! From buildsys at fedoraproject.org Fri Mar 16 08:58:44 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Fri, 16 Mar 2007 08:58:44 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2007-03-16 Message-ID: <20070316085844.21662.31635@extras64.linux.duke.edu> New report for: mebrown AT michaels-house.net package: firmware-addon-dell - 1.2.2-1.fc7.noarch from fedora-extras-development-ppc unresolved deps: libsmbios-bin ====================================================================== Summary of broken packages (by owner): Jochen AT herr-schmitt.de pdftk - 1.41-3.fc7.i386 (16 days) pdftk - 1.41-3.fc7.ppc (16 days) pdftk - 1.41-3.fc7.x86_64 (16 days) braden AT endoframe.com openvrml - 0.16.3-2.fc6.i386 (17 days) openvrml - 0.16.3-2.fc6.ppc (17 days) openvrml - 0.16.3-2.fc6.x86_64 (17 days) openvrml - 0.16.3-3.fc7.i386 (16 days) openvrml - 0.16.3-3.fc7.i386 (16 days) openvrml - 0.16.3-3.fc7.ppc (16 days) openvrml - 0.16.3-3.fc7.x86_64 (16 days) openvrml-devel - 0.16.3-2.fc6.i386 (17 days) openvrml-devel - 0.16.3-2.fc6.ppc (17 days) openvrml-devel - 0.16.3-2.fc6.x86_64 (17 days) openvrml-devel - 0.16.3-3.fc7.i386 (16 days) openvrml-devel - 0.16.3-3.fc7.i386 (16 days) openvrml-devel - 0.16.3-3.fc7.ppc (16 days) openvrml-devel - 0.16.3-3.fc7.x86_64 (16 days) dcbw AT redhat.com csound - 5.03.0-9.fc7.i386 (98 days) csound - 5.03.0-9.fc7.i386 (98 days) csound - 5.03.0-9.fc7.ppc (98 days) csound - 5.03.0-9.fc7.x86_64 (98 days) csound-python - 5.03.0-9.fc7.i386 (98 days) csound-python - 5.03.0-9.fc7.ppc (98 days) csound-python - 5.03.0-9.fc7.x86_64 (98 days) enrico.scholz AT informatik.tu-chemnitz.de tor-core - 0.1.1.26-3.fc7.i386 (5 days) tor-core - 0.1.1.26-3.fc7.ppc (5 days) tor-core - 0.1.1.26-3.fc7.x86_64 (5 days) foolish AT guezz.net flac123 - 0.0.9-1.fc7.i386 (29 days) flac123 - 0.0.9-1.fc7.ppc (29 days) flac123 - 0.0.9-1.fc7.x86_64 (29 days) ifoox AT redhat.com libreadline-java - 0.8.0-13.fc6.i386 (95 days) libreadline-java - 0.8.0-13.fc6.i386 (95 days) libreadline-java - 0.8.0-13.fc6.ppc (95 days) libreadline-java - 0.8.0-13.fc6.x86_64 (95 days) mebrown AT michaels-house.net firmware-addon-dell - 1.2.2-1.fc7.noarch orion AT cora.nwra.com paraview - 2.4.4-3.fc6.x86_64 (98 days) paraview-mpi - 2.4.4-3.fc6.x86_64 (98 days) overholt AT redhat.com eclipse-emf - 2.2.1-9.fc7.i386 eclipse-emf - 2.2.1-9.fc7.ppc eclipse-emf - 2.2.1-9.fc7.x86_64 rdieter AT math.unl.edu k3b-extras - 0.12.17-1.fc6.i386 (27 days) k3b-extras - 0.12.17-1.fc6.ppc (27 days) k3b-extras - 0.12.17-1.fc6.x86_64 (27 days) ryo-dairiki AT users.sourceforge.net libtomoe-gtk - 0.5.1-1.fc7.i386 (3 days) libtomoe-gtk - 0.5.1-1.fc7.i386 (3 days) libtomoe-gtk - 0.5.1-1.fc7.ppc (3 days) libtomoe-gtk - 0.5.1-1.fc7.x86_64 (3 days) stickster AT gmail.com xmldiff - 0.6.7-12.fc6.i386 (98 days) xmldiff - 0.6.7-12.fc6.ppc (98 days) xmldiff - 0.6.7-12.fc6.x86_64 (98 days) ville.skytta AT iki.fi kmod-em8300 - 0.16.1-6.2.6.20_1.2962.fc7.i586 (9 days) kmod-em8300 - 0.16.1-6.2.6.20_1.2962.fc7.i686 (9 days) kmod-em8300 - 0.16.1-6.2.6.20_1.2962.fc7.ppc (9 days) kmod-em8300 - 0.16.1-6.2.6.20_1.2962.fc7.x86_64 (9 days) kmod-em8300-PAE - 0.16.1-6.2.6.20_1.2962.fc7.i686 (9 days) kmod-em8300-kdump - 0.16.1-6.2.6.20_1.2962.fc7.x86_64 (9 days) kmod-em8300-smp - 0.16.1-6.2.6.20_1.2962.fc7.ppc (9 days) ====================================================================== Broken packages in fedora-extras-6-i386: openvrml-0.16.3-2.fc6.i386 requires firefox = 0:1.5.0.9 openvrml-devel-0.16.3-2.fc6.i386 requires firefox-devel = 0:1.5.0.9 ====================================================================== Broken packages in fedora-extras-6-ppc: openvrml-0.16.3-2.fc6.ppc requires firefox = 0:1.5.0.9 openvrml-devel-0.16.3-2.fc6.ppc requires firefox-devel = 0:1.5.0.9 ====================================================================== Broken packages in fedora-extras-6-x86_64: openvrml-0.16.3-2.fc6.x86_64 requires firefox = 0:1.5.0.9 openvrml-devel-0.16.3-2.fc6.x86_64 requires firefox-devel = 0:1.5.0.9 ====================================================================== Broken packages in fedora-extras-development-i386: csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.i386 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 eclipse-emf-2.2.1-9.fc7.i386 requires eclipse-platform < 1:3.2.2 flac123-0.0.9-1.fc7.i386 requires libFLAC.so.7 k3b-extras-0.12.17-1.fc6.i386 requires libk3bdevice.so.2 k3b-extras-0.12.17-1.fc6.i386 requires libk3b.so.2 kmod-em8300-0.16.1-6.2.6.20_1.2962.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2962.fc7 kmod-em8300-0.16.1-6.2.6.20_1.2962.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2962.fc7 kmod-em8300-PAE-0.16.1-6.2.6.20_1.2962.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2962.fc7PAE libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libtomoe-gtk-0.5.1-1.fc7.i386 requires libgucharmap.so.5 openvrml-0.16.3-3.fc7.i386 requires firefox = 0:2.0.0.1 openvrml-devel-0.16.3-3.fc7.i386 requires firefox-devel = 0:2.0.0.1 pdftk-1.41-3.fc7.i386 requires libgcj.so.7rh tor-core-0.1.1.26-3.fc7.i386 requires libevent-1.2a.so.1 xmldiff-0.6.7-12.fc6.i386 requires python(abi) = 0:2.4 xmldiff-0.6.7-12.fc6.i386 requires python-abi = 0:2.4 ====================================================================== Broken packages in fedora-extras-development-ppc: csound-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.ppc requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 eclipse-emf-2.2.1-9.fc7.ppc requires eclipse-platform < 1:3.2.2 firmware-addon-dell-1.2.2-1.fc7.noarch requires libsmbios-bin flac123-0.0.9-1.fc7.ppc requires libFLAC.so.7 k3b-extras-0.12.17-1.fc6.ppc requires libk3bdevice.so.2 k3b-extras-0.12.17-1.fc6.ppc requires libk3b.so.2 kmod-em8300-0.16.1-6.2.6.20_1.2962.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2962.fc7 kmod-em8300-smp-0.16.1-6.2.6.20_1.2962.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2962.fc7smp libreadline-java-0.8.0-13.fc6.ppc requires libedit >= 0:2.9 libtomoe-gtk-0.5.1-1.fc7.ppc requires libgucharmap.so.5 openvrml-0.16.3-3.fc7.ppc requires firefox = 0:2.0.0.1 openvrml-devel-0.16.3-3.fc7.ppc requires firefox-devel = 0:2.0.0.1 pdftk-1.41-3.fc7.ppc requires libgcj.so.7rh tor-core-0.1.1.26-3.fc7.ppc requires libevent-1.2a.so.1 xmldiff-0.6.7-12.fc6.ppc requires python(abi) = 0:2.4 xmldiff-0.6.7-12.fc6.ppc requires python-abi = 0:2.4 ====================================================================== Broken packages in fedora-extras-development-x86_64: csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-python-5.03.0-9.fc7.x86_64 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) eclipse-emf-2.2.1-9.fc7.x86_64 requires eclipse-platform < 1:3.2.2 flac123-0.0.9-1.fc7.x86_64 requires libFLAC.so.7()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3bdevice.so.2()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3b.so.2()(64bit) kmod-em8300-0.16.1-6.2.6.20_1.2962.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2962.fc7 kmod-em8300-kdump-0.16.1-6.2.6.20_1.2962.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2962.fc7kdump libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libreadline-java-0.8.0-13.fc6.x86_64 requires libedit >= 0:2.9 libtomoe-gtk-0.5.1-1.fc7.i386 requires libgucharmap.so.5 libtomoe-gtk-0.5.1-1.fc7.x86_64 requires libgucharmap.so.5()(64bit) openvrml-0.16.3-3.fc7.i386 requires firefox = 0:2.0.0.1 openvrml-0.16.3-3.fc7.x86_64 requires firefox = 0:2.0.0.1 openvrml-devel-0.16.3-3.fc7.i386 requires firefox-devel = 0:2.0.0.1 openvrml-devel-0.16.3-3.fc7.x86_64 requires firefox-devel = 0:2.0.0.1 paraview-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) paraview-mpi-2.4.4-3.fc6.x86_64 requires libpython2.4.so.1.0()(64bit) pdftk-1.41-3.fc7.x86_64 requires libgcj.so.7rh()(64bit) tor-core-0.1.1.26-3.fc7.x86_64 requires libevent-1.2a.so.1()(64bit) xmldiff-0.6.7-12.fc6.x86_64 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.x86_64 requires python(abi) = 0:2.4 From alexl at redhat.com Fri Mar 16 08:59:24 2007 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 16 Mar 2007 09:59:24 +0100 Subject: User directories integration - request for help In-Reply-To: <20070315145337.GA9180@jadzia.bu.edu> References: <1173953610.10024.132.camel@greebo> <20070315145337.GA9180@jadzia.bu.edu> Message-ID: <1174035564.10024.177.camel@greebo> On Thu, 2007-03-15 at 10:53 -0400, Matthew Miller wrote: > On Thu, Mar 15, 2007 at 11:13:30AM +0100, Alexander Larsson wrote: > > The directories availible are: > > DESKTOP: the standard desktop dir > > DOWNLOAD: default location for downloads > > TEMPLATES: used by nautilus for templates > > PUBLICSHARE: This is ~/Public as used by gnome-user-share > > DOCUMENTS: default location for "documents" > > MUSIC: default location for music > > PICTURES: default location for pictures > > VIDEOS: default location for movies > > What's with the ALL CAPS? I'm having an Apple ][ flashback. The config is stored in a shell-style file to make it easier to read in a shell script: cat ~/.config/user-dirs.dirs # This file is written by xdg-user-dirs-update # If you want to change or add directories, just edit the line you're # interested in. All local changes will be retained on the next run # Format is XDG_xxx_DIR="$HOME/yyy", where yyy is a shell-escaped # homedir-relative path, or XDG_xxx_DIR="/yyy", where /yyy is an # absolute path. No other format is supported. # XDG_DESKTOP_DIR="$HOME/Skrivbord" XDG_DOWNLOAD_DIR="$HOME/H?mtat" XDG_TEMPLATES_DIR="$HOME/Templates" ... For some historical reason env vars (PATH, HOME, etc) are all caps, so I just followed suit. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a sword-wielding ninja paramedic She's an orphaned renegade soap star on the trail of a serial killer. They fight crime! From alexl at redhat.com Fri Mar 16 09:05:24 2007 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 16 Mar 2007 10:05:24 +0100 Subject: User directories integration - request for help In-Reply-To: <1173986979.3051.0.camel@sb-home.lan> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> Message-ID: <1174035924.10024.184.camel@greebo> On Thu, 2007-03-15 at 20:29 +0100, nodata wrote: > Am Donnerstag, den 15.03.2007, 14:03 -0400 schrieb Matthias Clasen: > > On Thu, 2007-03-15 at 11:13 +0100, Alexander Larsson wrote: > > > > > > Any other ideas? > > > > Might be a good idea to give a quick explanation of what happens, and > > what people should expect to see if they install the packages. > > > > Matthias > > > > From the looks of it, the directories get continually renamed if you > switch languages. Stay away from my home dir, use a dot file if you > must! I don't know where you got this idea from? Did you even try it? What happens is this: First time you log in, directories will be created based on the current locale and pointers to them will be created in the file ~/.config/user-dirs.dirs. We also record the locale used in a separate file. The second time you log in we will only create directories specified in the defaults file that are not listed in your ~/.config/user-dirs.dirs file. (So, you'll get new default dirs.) Directories specified in your config file that has been removed will be changed in the config file to point to $HOME. If you log in a second time in a language different than the original one you will get a dialog asking you whether you want to move to the new locale, with a list of what would change if you did. Then you can pick, yes, no, and "never show me this again". At the moment the migration is kind of lame. We just create the new folders and point to them, and the user will have to move stuff over manually. Moving user data automatically is tricky and risky, but this is quite lame. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a Nobel prize-winning moralistic gentleman spy on the run. She's a sharp-shooting snooty stripper operating on the wrong side of the law. They fight crime! From Axel.Thimm at ATrpms.net Fri Mar 16 09:28:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Mar 2007 10:28:11 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <58979.192.54.193.51.1174031753.squirrel@rousalka.dyndns.org> References: <45FA1A1A.9060201@volny.cz> <58979.192.54.193.51.1174031753.squirrel@rousalka.dyndns.org> Message-ID: <20070316092811.GB24022@neu.nirvana> On Fri, Mar 16, 2007 at 08:55:53AM +0100, Nicolas Mailhot wrote: > Le Ven 16 mars 2007 05:16, Miloslav Trmac a ?crit : > > > Can anyone see a problem with the plan, or an important feature that the > > above fails to address? > > 1. You're spreading rw files all over the filesystems, which is contrary > to the FHS. > 2. You're putting hidden directories where people won't expect them, which > will seriously annoy sysadmins > > I don't have any magic solution, but IMHO you need to think about file > location & naming a little more. It's quite similar to maintaining quotas (unless the filesystem is capable of maintaining quotas in its own metadata), e.g. consider the path information managed by mlocate the same metadata quality as the quotas following similar exceptions. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mschwendt.tmp0701.nospam at arcor.de Fri Mar 16 09:38:56 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 16 Mar 2007 10:38:56 +0100 Subject: Fedora extras metadata In-Reply-To: References: <45F9C515.3060804@zoeloelip.be> <20070315234339.7065f318.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070316103856.9156a362.mschwendt.tmp0701.nospam@arcor.de> On Fri, 16 Mar 2007 08:17:47 +0100, Thomas M Steenholdt wrote: > Michael Schwendt wrote: > >> > >> What is going on with fedora extras metadata lately? > > > > Nothing. It's just the mirrors that choke on daily updates and don't sync > > safely and frequently enough. > > > This seems to be happening more often that we could hope for. As mentioned in the thread "repoview in our repositories", I believe repoview may be one culprit, since it's located *inside* the repodata directory and potentially increases the time a mirror spends in that tree. Repoview was put in place at the beginning of Fedora Extras and has been kept in pretty much a "nobody cares about it" state. Meanwhile it results in thousands of html files. More than 16,000 pages per dist release! And until recently several thousands more for the debuginfo repos. Too many of the pages change when we publish updated packages. It's not 1:1, but 1:N (one updated package => many updated pages), see the other thread for more details. And this is the size of repoview for extras devel: 24M ./SRPMS/repodata/repoview 39M ./i386/repodata/repoview 38M ./ppc/repoview 41M ./x86_64/repodata/repoview > Is there a documented way to set up mirroring, to ENSURE that the > mirrors are in a consistent state? Not that I know of, as we don't do anything like clearing and setting a flag file before and after the sync. So, theoretically it can happen that a mirror is downloading while we copy new packages and new metadata to Red Hat. And if that happens while a mirror is choking on thousands of repoview pages inside the repodata dir, this increases the window during which downloads can become inconsistent. Mirrors that don't sync daily are hit hard apparently: development/i386/repodata/ mirrors.kernel.org 2007-03-11 11:44 repomd.xml > If not - and I believe this has been brought up earlier (by myself). I > really think we could do with a simple timestamping mirror handshake > mechanism, kinda like what debian does. This would allow mirrors to > monitor for a special file and when that file is available, we know the > mirror is in a consistent state (as consistent as it's master - which > can also be tracked in this way). Mirrors could easily add a few lines > to their scripts to honor this kind of thing, without the need for > special mirroring tools. > > Just a suggestion > > /Thomas What does the algorithm look like? "Handshake" implies bidirectional communication, which is not available. We only have "slave retrieves from master" or "slave retrieves from slave" relationships. Mutual exclusion is not possible either. Flag files don't make the mirroring an atomic operation. The master can still break the scheme and push updates while a mirror is downloading in believe that the previously checked flag file was up-to-date. From aportal at univ-montp2.fr Fri Mar 16 09:38:17 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Fri, 16 Mar 2007 10:38:17 +0100 Subject: Need help in anaconada po translation Message-ID: <200703161038.17750.aportal@univ-montp2.fr> Hi Can somebody tell me what means "completed" in "%s of %s packages completed" Entry 371 (yuminstall.py:194). Installed? Downloaded? Other meaning? Regards, Alain -- 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 hunter at userfriendly.net Fri Mar 16 10:24:32 2007 From: hunter at userfriendly.net (Michael Weiner) Date: Fri, 16 Mar 2007 06:24:32 -0400 Subject: Not signed updates In-Reply-To: References: Message-ID: On 3/16/07, Gianluca Sforna wrote: > > This is probably known but, just in case, I just received in my local > mirror updates for: > > tcpdump-3.9.4-10.fc6.i386.rpm > libpcap-0.9.4-10.fc6.i386.rpm Interesting, for me it was 'package arpwatch-2.1a13-17.fc6.i386.rpm is not signed' while the previously mentioned 2 were ok. Weird, huh?!? Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at redhat.com Fri Mar 16 10:37:14 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Fri, 16 Mar 2007 06:37:14 -0400 Subject: rawhide report: 20070316 changes Message-ID: <200703161037.l2GAbEgv032292@hs20-bc2-6.build.redhat.com> Removed package compat-slang Removed package compat-readline43 Updated Packages: NetworkManager-1:0.6.5-0.4.svn2474.fc7 -------------------------------------- * Thu Mar 15 2007 Dan Williams - 1:0.6.5-0.4.svn2474 - Update to pre-0.6.5 snapshot anaconda-11.2.0.37-1 -------------------- * Thu Mar 15 2007 David Cantrell - 11.2.0.37-1 - Fix confusing wording in loader (clumens, #163329) - Don't tell the user to eject the CD at the end (clumens, #137275) - Remove some unused functions (clumens) - More intelligent error handling when the number of packages exceeds the CD size (clumens, #232104) - Partitioning UI string fixes (clumens, #203346) - Name the cciss module 'HP/Compaq Smart Array Controller (#210414) - More partitioning UI string fixes (#208394) autofs-1:5.0.1-5 ---------------- * Fri Mar 16 2007 Ian Kent - 5.0.1-5 - drop "DEFAULT_" prefix from configuration names. - add option to select replicated server at random (instead of ping response time) (bz 227604). - fix incorrect cast in directory cleanup routines (bz 231864). - fixed numeric export match (bz 231188). avahi-0.6.17-1.fc7 ------------------ * Mon Mar 12 2007 Martin Bacovsky - 0.6.17-1 - upgrade to new upstream 0.6.17 - redundant patches removal - removed auto* stuff from specfile since that was no longer needed - Resolves: #232205: 'service {avahi-dnsconfd,avahi-daemon} status' returns 0 when the service is stopped bzip2-1.0.4-8.fc7 ----------------- * Thu Mar 15 2007 Ivana Varekova 1.0.4-8 - remove unnecessary "/" after RPM_BUILD_ROOT macro eclipse-1:3.2.2-4.fc7 --------------------- * Thu Mar 15 2007 Ben Konrath 3.2.2-4 - Update to tomcat 5.5.20. evolution-webcal-2.10.0-1.fc7 ----------------------------- * Thu Mar 15 2007 Matthew Barnes - 2.10.0-1.fc7 - Update to 2.10.0 fedora-logos-6.0.95-1.fc7 ------------------------- * Thu Mar 15 2007 Ray Strode - 6.0.95-1 - Drop weird gnome-logo-icon-transparent.png symlink that makes fedora show up where gnome logo is supposed to * Thu Mar 15 2007 Matthias Clasen - 6.0.94-1 - Retouch parts of the rhgb image to align it better with the login screen filesystem-2.4.3-1.fc7 ---------------------- * Thu Mar 15 2007 Phil Knirsch - 2.4.3-1 - Fixed typo for new /etc/xdg entries (#224052) - One more tiny specile cleanup fonts-japanese-0.20061016-4.fc7 ------------------------------- * Thu Mar 15 2007 Akira TAGOH - 0.20061016-4 - more cleanups. (#225765) gdb-6.6-7.fc7 ------------- * Thu Mar 15 2007 Jan Kratochvil - 6.6-7 - Suggest SELinux permissions problem; no assertion failure anymore (BZ 232371). * Wed Mar 14 2007 Jan Kratochvil - 6.6-6 - Fix occasional dwarf2_read_address: Corrupted DWARF expression (BZ 232353). * Mon Mar 12 2007 Jan Kratochvil - 6.6-5 - Temporary support for shared libraries >2GB on 64bit hosts. (BZ 231832) gettext-0.16.1-7.fc7 -------------------- * Thu Mar 15 2007 Jens Petersen - 0.16.1-7 - set preloadable_libintl.so executable in %install so it gets stripped - force removal of infodir/dir since it is not there when /sbin is not in path gftp-1:2.0.18-5.fc7 ------------------- * Thu Mar 15 2007 Alexander Larsson - 1:2.0.18-5 - Default to download directory if started from $HOME gnuplot-4.0.0-17.fc7 -------------------- * Thu Mar 15 2007 Ivana Varekova - 4.0.0-17 - incorporate the package review feedback gtkhtml2-2.11.0-4 ----------------- * Thu Mar 15 2007 Karsten Hopp 2.11.0-4 - rebuild with current gtk2 to add png support (#232013) icon-slicer-0.3-8 ----------------- * Thu Mar 15 2007 Karsten Hopp 0.3-8 - rebuild with current gtk2 to add png support (#232013) iputils-20070202-1.fc7 ---------------------- * Thu Mar 15 2007 Martin Bacovsky - 20070202-1 - upgarde to new upstream iputils-s20070202 - Resolves: #229995 - Resolves: #225909 - Merge Review: iputils - patches revision kernel-2.6.20-1.2990.fc7 ------------------------ * Thu Mar 15 2007 Dave Jones - 2.6.21-rc3-git10 * Wed Mar 14 2007 Roland McGrath - utrace update - fix wait for clone threads of ptracer's own child (#232236) - fix wait for previously delayed group leader (#232381) kexec-tools-1.101-63.fc7 ------------------------ * Thu Mar 15 2007 Neil Horman - 1.101-63.fc7 - Adding extra check to avoid oom kills on nfs mount failure (bz 215056) krb5-auth-dialog-0.7-2 ---------------------- * Thu Mar 15 2007 Karsten Hopp 0.7-2 - rebuild with current gtk2 to add png support (#232013) libgail-gnome-1.18.0-2.fc7 -------------------------- * Thu Mar 15 2007 Karsten Hopp 1.18.0-2 - rebuild with current gtk2 to add png support (#232013) lm_sensors-2.10.2-2.fc7 ----------------------- * Thu Mar 15 2007 Phil Knirsch - 2.10.2-2 - Only require dmidecode on supported archs (#232264) m17n-db-1.3.4-8.fc7 ------------------- * Thu Mar 15 2007 Mayank Jain - Added key summary to kn-itrans,inscript keymaps - resolves 228806 mesa-6.5.2-8.fc7 ---------------- * Thu Mar 08 2007 Adam Jackson 6.5.2-8 - Hush the (useless) warning about the synthetic visual not being supported. mtr-2:0.72-2 ------------ * Thu Mar 15 2007 Karsten Hopp 2:0.72-2 - rebuild with current gtk2 to add png support (#232013) net-tools-1.60-80.fc7 --------------------- * Thu Mar 15 2007 Radek Vok??l - 1.60-80 - we don't have -n/--node option (#225554) nmap-2:4.20-4.fc7 ----------------- * Thu Mar 15 2007 Karsten Hopp 4.20-4 - rebuild with current gtk2 to add png support (#232013) openoffice.org-1:2.2.0-12.1 --------------------------- * Thu Mar 15 2007 Caolan McNamara - 1:2.2.0-12.1 - Resolves: rhbz#232389 enable tango theme - support xdguserdir translated user dirs - add alloc debugging library to testtools - next release candidate pycairo-1.4.0-1.fc7 ------------------- * Thu Mar 15 2007 Matthew Barnes - 1.4.0-1.fc7 - Update to 1.4.0 readline-5.2-3.fc7 ------------------ * Thu Mar 15 2007 Miroslav Lichvar 5.2-3 - link libreadline with libtinfo (#232277) - include upstream 5.2-001 patch - move static libraries to -static subpackage, spec cleanup rhpl-0.203-2 ------------ * Thu Mar 15 2007 David Cantrell - 0.203-2 - Remove 'Red Hat Linux' from the package description (#208444) rhythmbox-0.9.8-2.fc7 --------------------- * Thu Mar 15 2007 - Bastien Nocera - 0.9.8-2.fc7 - Add missing dependency on gnome-python2 for the Python gnome-vfs bindings (#232189) ruby-1.8.6-1.fc7 ---------------- * Thu Mar 15 2007 Akira TAGOH - 1.8.6-1 - New upstream release. - clean up a spec file. sane-frontends-1.0.14-2 ----------------------- * Thu Mar 15 2007 Karsten Hopp 1.0.14-2 - rebuild with current gtk2 to add png support (#232013) selinux-policy-2.5.8-5.fc7 -------------------------- * Thu Mar 15 2007 Dan Walsh 2.5.8-5 - Fix prelink to be able to manage usr dirs. tcpdump-14:3.9.5-3.fc7 ---------------------- * Thu Mar 15 2007 Miroslav Lichvar - 14:3.9.5-3 - fix buffer overflow in 802.11 printer (#232349, CVE-2007-1218) - spec cleanup (#226481) wordtrans-1:1.1-0.1.pre13.fc7 ----------------------------- * Thu Mar 15 2007 Than Ngo - 1:1.1-0.1.pre13.fc7 - introduce Epoch to fix Versioning mess - use preferred BuildRoot - use of cat inside of specfile is replaced by SourceX - s/BuildPreReq:/BuildRequires: * Mon Jul 17 2006 Than Ngo 1.1pre13-14 - rebuild * Wed Jul 12 2006 Jesse Keating - 1.1pre13-13.1 - rebuild wpa_supplicant-1:0.5.7-1.fc7 ---------------------------- * Thu Mar 15 2007 Dan Williams - 0.5.7-1 - Update to 0.5.7 stable release xcdroast-0.98a15-13 ------------------- * Thu Mar 15 2007 Karsten Hopp 0.98a15-13 - rebuild with current gtk2 to add png support (#232013) 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 Axel.Thimm at ATrpms.net Fri Mar 16 10:51:23 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Mar 2007 11:51:23 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <45FA1A1A.9060201@volny.cz> References: <45FA1A1A.9060201@volny.cz> Message-ID: <20070316105123.GC24022@neu.nirvana> On Fri, Mar 16, 2007 at 05:16:26AM +0100, Miloslav Trmac wrote: > Hi, > I'm planning to add filesystem-local database support to mlocate. This > allows: First of all thanks for attacking this! > - running updatedb on a file server and making the database > automatically available to clients without any client-side > configuration > - using locate on GFS volumes without running updatedb on each host that > has the volume mounted (which slows the volumes down due to lock > contention) > > The plan: > * the mlocate.db format is extended to support databases without a fixed > path prefix, such that all entries in a database in > /foo/bar/.mlocate/mlocate.db are implicitly prefixed by /foo/bar. > (this allows using /srv/home on the file server, mounting it as /home, > and using a single database on both the server and the client). > * locate(1)'s default database is not just /var/lib/mlocate/mlocate.db; > mlocate also checks each mounted filesystem for a .mlocate/mlocate.db > file, owned by root or the invoking user, and not writable by anyone > but the owner. Such files are automatically added to the database > path. locate should also include .mlocate/mlocate.db a previous updatedb has found and skipped. E.g. if updatedb detects a .mlocate/mlocate.db in a folder in its path it skips it and registers it for locate to use. Perhaps that way you can even save the explicit mentioning of --single-fs paths in /etc/sysconfig/mlocate. If a paths is to be handled as such the admin just creates an .mlocate folder and updatedb and locate automatically pick it up. > * To allow overriding this check, the LOCATE_PATH variable is changed > to override the default database path instead of appending to the > database path. > *note*: this is an incompatible change > * updatedb(8) gets a new option, --single-fs PATH. > This option generates a database in PATH/.mlocate/mlocate.db that > spans only the subtree of PATH. filesystems mounted in subdirectories > of PATH are automatically excluded, PRUNEFS is ignored. PRUNEPATHS is > honored, except for PATH itself. > * /etc/cron.daily/mlocate reads /etc/sysconfig/mlocate to get a list > of single-fs PATHs. For each PATH it checks PATH/.mlocate/mlocate.db > is older than 12 hours, creates a lock to prevent a concurrent > updatedb, and runs updatedb --single-fs PATH. > > The standard daily run is performed as well, with all entries of > /etc/sysconfig/mlocate added to PRUNEPATHS automatically. > > Usage for /home on NFS: > - NFS is automatically excluded by clients, so updatedb on clients > does not walk the filesystem. > - On the server: > Add /srv/home to /etc/sysconfig/mlocate. If /srv/home is not a > separate mount point, add LOCATE_PATH=:/srv/home/.mlocate/mlocate.db > to the global environment. > > Usage for /home on GFS: > - GFS is automatically excluded, so no host walks the filesystem by > default. > - On all hosts: add /home to /etc/sysconfig/mlocate > > > Can anyone see a problem with the plan, or an important feature that the > above fails to address? > > Thanks, > Mirek > -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tjanouse at redhat.com Fri Mar 16 11:26:06 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Fri, 16 Mar 2007 12:26:06 +0100 Subject: [RFC] Filesystem-local databases in mlocate In-Reply-To: <45FA1A1A.9060201@volny.cz> References: <45FA1A1A.9060201@volny.cz> Message-ID: <20070316112606.GA14793@redhat.com> Hi, On Fri, Mar 16, 2007 at 05:16:26AM +0100, Miloslav Trmac wrote: > Can anyone see a problem with the plan, or an important feature that the > above fails to address? If I understood it correctly, every locate search would read the files on the remote volumes, right? The performance will suffer a bit I think. For example, NFS over 11mbit wifi is fine, but waiting tens of seconds for the database to download isn't good. Probably a global locate cache db that merges all the fs-local ones would be nice. -- TJ., BaseOS, Brno, CZ From jkeating at redhat.com Fri Mar 16 11:27:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Mar 2007 07:27:53 -0400 Subject: Need help in anaconada po translation In-Reply-To: <200703161038.17750.aportal@univ-montp2.fr> References: <200703161038.17750.aportal@univ-montp2.fr> Message-ID: <200703160728.00189.jkeating@redhat.com> On Friday 16 March 2007 05:38:17 Alain PORTAL wrote: > Installed? Downloaded? Other meaning? Installed I do believe. -- 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 Fri Mar 16 11:35:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Mar 2007 07:35:08 -0400 Subject: Not signed updates In-Reply-To: References: Message-ID: <200703160735.08711.jkeating@redhat.com> On Friday 16 March 2007 04:05:45 Gianluca Sforna wrote: > tcpdump-3.9.4-10.fc6.i386.rpm > libpcap-0.9.4-10.fc6.i386.rpm Fixing. -- 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 Fri Mar 16 11:35:20 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Mar 2007 07:35:20 -0400 Subject: rawhide report: 20070315 changes In-Reply-To: <20070316084642.2ed8122e@banea.int.addix.net> References: <1173979254.3163.2.camel@sonlaptop> <200703151630.56906.jkeating@redhat.com> <20070316084642.2ed8122e@banea.int.addix.net> Message-ID: <200703160735.20373.jkeating@redhat.com> On Friday 16 March 2007 03:46:42 Ralf Ertzinger wrote: > Which is merged with Core now? Or is it? Not yet. -- 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 Fri Mar 16 11:50:49 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 16 Mar 2007 07:50:49 -0400 Subject: what makes a package get i386 on x86_64? In-Reply-To: <20070316080854.8771175a.mschwendt.tmp0701.nospam@arcor.de> References: <20070315213846.GA13190@jadzia.bu.edu> <20070315231057.2c7f7179.mschwendt.tmp0701.nospam@arcor.de> <20070316020859.GA3080@jadzia.bu.edu> <200703152226.10050.jkeating@redhat.com> <20070316080854.8771175a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070316115049.GA13295@jadzia.bu.edu> On Fri, Mar 16, 2007 at 08:08:54AM +0100, Michael Schwendt wrote: > If festival-libs required festival, the split would be pointless as we It wouldn't, though. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From Axel.Thimm at ATrpms.net Fri Mar 16 11:58:28 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Mar 2007 12:58:28 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <20070316112606.GA14793@redhat.com> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> Message-ID: <20070316115828.GD24022@neu.nirvana> On Fri, Mar 16, 2007 at 12:26:06PM +0100, Tomas Janousek wrote: > Hi, > > On Fri, Mar 16, 2007 at 05:16:26AM +0100, Miloslav Trmac wrote: > > Can anyone see a problem with the plan, or an important feature that the > > above fails to address? > > If I understood it correctly, every locate search would read the files on the > remote volumes, right? The performance will suffer a bit I think. For example, > NFS over 11mbit wifi is fine, but waiting tens of seconds for the database to > download isn't good. Probably a global locate cache db that merges all the > fs-local ones would be nice. Perhaps the remote .mlocatedbs could be cached based on size and timestamp? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From fedora at camperquake.de Fri Mar 16 12:04:35 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 16 Mar 2007 13:04:35 +0100 Subject: rawhide report: 20070315 changes In-Reply-To: <200703160735.20373.jkeating@redhat.com> References: <1173979254.3163.2.camel@sonlaptop> <200703151630.56906.jkeating@redhat.com> <20070316084642.2ed8122e@banea.int.addix.net> <200703160735.20373.jkeating@redhat.com> Message-ID: <20070316130435.260eede7@banea.int.addix.net> Hi. On Fri, 16 Mar 2007 07:35:20 -0400, Jesse Keating wrote: > On Friday 16 March 2007 03:46:42 Ralf Ertzinger wrote: > > Which is merged with Core now? Or is it? > > Not yet. I was just wondering what we gain by moving packages between Core and Extras at this time. From jkeating at redhat.com Fri Mar 16 12:15:01 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Mar 2007 08:15:01 -0400 Subject: rawhide report: 20070315 changes In-Reply-To: <20070316130435.260eede7@banea.int.addix.net> References: <1173979254.3163.2.camel@sonlaptop> <200703160735.20373.jkeating@redhat.com> <20070316130435.260eede7@banea.int.addix.net> Message-ID: <200703160815.01653.jkeating@redhat.com> On Friday 16 March 2007 08:04:35 Ralf Ertzinger wrote: > I was just wondering what we gain by moving packages between Core and > Extras at this time. We gain testing the actual mechanism of the merge so that we have confidence that the merge will actually happen instead of blow up in our face. -- 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 pertusus at free.fr Fri Mar 16 12:35:36 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 16 Mar 2007 13:35:36 +0100 Subject: User directories integration - request for help In-Reply-To: <45F9EF29.6020901@fedoraproject.org> References: <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> Message-ID: <20070316123536.GC2923@free.fr> On Fri, Mar 16, 2007 at 06:43:13AM +0530, Rahul Sundaram wrote: > Andr? Kelpe wrote: > > >Because many people hate it, when something automagically clutters up > >their home. My home is my castle :-)! I decide, not a tool, that thinks > >it knows better than me... > > Desktop is the folder you would seeing on a typical desktop environment. > Not home. If are you not using a desktop environment, you wouldn't be > using these applications either. So what they do would not affect you at > all. Currently applications like Firefox actually save files into your > desktop by default. Organizing the data better will result in less But allow to change the location each time the save action is performed. > Again providing defaults for these applications doesn't take away your > ability to customize anything. We have continued to adopt several ideas > from other operating systems if that makes sense and that is a good thing. It seems like those folders are created automatically when user logs in. That's what I dislike. If they are defaults for 'save' actions in every apps, fine. If they are created and used automatically, I think it isn't right. -- Pat From aportal at univ-montp2.fr Fri Mar 16 12:45:34 2007 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Fri, 16 Mar 2007 13:45:34 +0100 Subject: Need help in anaconada po translation In-Reply-To: <200703160728.00189.jkeating@redhat.com> References: <200703161038.17750.aportal@univ-montp2.fr> <200703160728.00189.jkeating@redhat.com> Message-ID: <200703161345.34832.aportal@univ-montp2.fr> Le Friday 16 March 2007 12:27:53 Jesse Keating, vous avez ?crit?: > On Friday 16 March 2007 05:38:17 Alain PORTAL wrote: > > Installed? Downloaded? Other meaning? > > Installed I do believe. Thanks! Regards Alain -- 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 pertusus at free.fr Fri Mar 16 12:45:30 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 16 Mar 2007 13:45:30 +0100 Subject: User directories integration - request for help In-Reply-To: <1174035924.10024.184.camel@greebo> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> Message-ID: <20070316124530.GD2923@free.fr> On Fri, Mar 16, 2007 at 10:05:24AM +0100, Alexander Larsson wrote: > > What happens is this: > > First time you log in, directories will be created based on the current > locale and pointers to them will be created in the file > ~/.config/user-dirs.dirs. We also record the locale used in a separate > file. I really dislikes the idea that directories are created at login time. Couldn't it be possible instead to have them created when needed and use the names and locales recorded in ~/.config/user-dirs.dirs for the default name? > The second time you log in we will only create directories specified in > the defaults file that are not listed in your ~/.config/user-dirs.dirs > file. (So, you'll get new default dirs.) Directories specified in your > config file that has been removed will be changed in the config file to > point to $HOME. It seems to me that there is too much magic in this... > If you log in a second time in a language different than the original > one you will get a dialog asking you whether you want to move to the new > locale, with a list of what would change if you did. Then you can pick, > yes, no, and "never show me this again". I think this is unavoidable, but this should only be done with existing directories. -- Pat From dimi at lattica.com Fri Mar 16 11:56:20 2007 From: dimi at lattica.com (Dimi Paun) Date: Fri, 16 Mar 2007 07:56:20 -0400 (EDT) Subject: User directories integration - request for help In-Reply-To: <1174035924.10024.184.camel@greebo> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> Message-ID: <46940.74.96.19.63.1174046180.squirrel@lattica.com> On Fri, March 16, 2007 05:05, Alexander Larsson wrote: > At the moment the migration is kind of lame. We just create the new > folders and point to them, and the user will have to move stuff over > manually. Moving user data automatically is tricky and risky, but this > is quite lame. This is so lame that we'd be _much_ better off not showing it to the user -- I mean, most people can intuitively understand that once created, things will remain like that, but most will be quite pissed off (and rightly so) if we force them at login time to make a decision out of which one of the choices is totally broken. Maybe just create a "language changer" utility that the use explicitly invokes to do the switch, so that only folks that want to change the language of said dirs (and I'd expect them to be in the minority!) would have to deal with it. And being invoked as an explicit migration, it can also move the files as an explicit step that may involve the user for further clarifications. -- Dimi Paun Lattica, Inc. From baris at teamforce.name.tr Fri Mar 16 13:00:31 2007 From: baris at teamforce.name.tr (Baris Cicek) Date: Fri, 16 Mar 2007 15:00:31 +0200 Subject: User directories integration - request for help In-Reply-To: <46940.74.96.19.63.1174046180.squirrel@lattica.com> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> <46940.74.96.19.63.1174046180.squirrel@lattica.com> Message-ID: <1174050031.3441.10.camel@localhost.localdomain> On Fri, 2007-03-16 at 07:56 -0400, Dimi Paun wrote: > On Fri, March 16, 2007 05:05, Alexander Larsson wrote: > > At the moment the migration is kind of lame. We just create the new > > folders and point to them, and the user will have to move stuff over > > manually. Moving user data automatically is tricky and risky, but this > > is quite lame. > > This is so lame that we'd be _much_ better off not showing it to the > user -- I mean, most people can intuitively understand that once created, > things will remain like that, but most will be quite pissed off (and rightly > so) if we force them at login time to make a decision out of which one > of the choices is totally broken. > > Maybe just create a "language changer" utility that the use explicitly > invokes to do the switch, so that only folks that want to change the > language of said dirs (and I'd expect them to be in the minority!) would > have to deal with it. And being invoked as an explicit migration, it can > also move the files as an explicit step that may involve the user for > further clarifications. It would be really trivial to implement language switching if user exposed directories are symlinks. So that actual directories should be hidden with lowercase (ie. .downloads, .pictures), and symlinks can be translated directory names, which could be easily created on login time w/ a small bash profile script. By this way, actual directories can stay with standard names. > > -- > Dimi Paun > Lattica, Inc. > > From ssorce at redhat.com Fri Mar 16 13:33:22 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 16 Mar 2007 09:33:22 -0400 Subject: User directories integration - request for help In-Reply-To: <20070316085216.1457851f@banea.int.addix.net> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> Message-ID: <1174052002.5941.49.camel@willson> On Fri, 2007-03-16 at 08:52 +0100, Ralf Ertzinger wrote: > Hi. > > On Fri, 16 Mar 2007 01:38:00 +0530, Rahul Sundaram wrote: > > > > Renaming a user's directories doesn't seem to be "The UNIX Way" TM > > > > Traditional Unix systems never had to deal with many of the modern > > desktop requirements so it's high time we stopped citing the "the > > unix way" as a excuse not to change anything. All modern Linux > > desktop systems happily automount devices which is distinctly not > > unixy either. If there are real practical reasons just cite that > > specifically. > > OSX gets this right, from what I remember. The applications folder is > always called "Applications" on disk, but the displayed name in Finder > (and open/save dialogs) is specific to the language settings of the > current user. YES, please, DO NOT rename directories in different languages! Madness will come out of it. > This is true for system wide folders and folders in users home dirs. > > I do not know what MS does with their "Program Files" folder. Bloody Windows, can't change installation language, and they change also *system* folders like Program Files to a localized name. There are then countless of programs that on installation simply point to the English name, and recreate it, so that you end up with 2 "Program Files" folders. This is broken, and thinking of changing user folder names is also UTTERLY broken. All application that save a path name for user convenience, will start popping up error or warning messages about not finding some file or will just annoy the user into browsing to find again their documents. Think simply at OO.org "Recently Used" menu option. I use it a lot, and it would simply break if I switch language and my files were stored in a folder that changed name. Also as soon as you make a default, people will start using it, and, like in the Windows case, you will find out apps devs that do not think of this possibility of changing folders and you may end up with the same folder with different languages. _BAD_ If you really want to do it, choose a fixed name and change Gnome/Kde to understand how to display these "special" dirs names into a localized way (maybe with an option to disable this thing). Simo. From mclasen at redhat.com Fri Mar 16 13:48:08 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 16 Mar 2007 09:48:08 -0400 Subject: User directories integration - request for help In-Reply-To: <1174052002.5941.49.camel@willson> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> Message-ID: <1174052888.5822.5.camel@localhost.localdomain> On Fri, 2007-03-16 at 09:33 -0400, Simo Sorce wrote: > On Fri, 2007-03-16 at 08:52 +0100, Ralf Ertzinger wrote: > > Hi. > > > > On Fri, 16 Mar 2007 01:38:00 +0530, Rahul Sundaram wrote: > > > > > > Renaming a user's directories doesn't seem to be "The UNIX Way" TM > > > > > > Traditional Unix systems never had to deal with many of the modern > > > desktop requirements so it's high time we stopped citing the "the > > > unix way" as a excuse not to change anything. All modern Linux > > > desktop systems happily automount devices which is distinctly not > > > unixy either. If there are real practical reasons just cite that > > > specifically. > > > > OSX gets this right, from what I remember. The applications folder is > > always called "Applications" on disk, but the displayed name in Finder > > (and open/save dialogs) is specific to the language settings of the > > current user. > > YES, please, DO NOT rename directories in different languages! Madness > will come out of it. > [...] > If you really want to do it, choose a fixed name and change Gnome/Kde to > understand how to display these "special" dirs names into a localized > way (maybe with an option to disable this thing). The tradeoffs of translation-on-disk vs. translation-only-in-ui have been discussed for years. Please don't let this thread devolve into rehashing all the arguments for the umpteenth time. From nicolas.mailhot at laposte.net Fri Mar 16 13:51:24 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 16 Mar 2007 14:51:24 +0100 (CET) Subject: User directories integration - request for help In-Reply-To: <1173993597.3535.3.camel@localhost.localdomain> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <1173992650.5024.9.camel@rousalka.dyndns.org> <1173993597.3535.3.camel@localhost.localdomain> Message-ID: <62734.192.54.193.51.1174053084.squirrel@rousalka.dyndns.org> Le Jeu 15 mars 2007 22:19, Matthias Clasen a ?crit : > >> >> You need to expose an invariant namespace in addition to the user-chosen >> one (with hard/sym links one way or the other) >> >> Every app, script or process that does not run for a single user within >> his session will have trouble with user-specific namespaces. (yes every >> user on a single system won't use the same layout) > What do you mean ? These directories are in no way special or different > from any other directory you may create in your home directory. They're different because their content is semi defined (as opposed to the usual homedir mess) so other apps/scrips than yours will want to play with them > The only > difference is that we create them at login time, and that we make > desktop apps know about them. Others have already answered, but while the renaming dance is fine for GUI tools apps would really like to use stable FS objects (stable as in "user & locale-independant") Could you add please add a dot dir containing (hard|sym) links pointing to whatever renamed directories the user configured at the moment ? -- Nicolas Mailhot From rc040203 at freenet.de Fri Mar 16 13:57:15 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Mar 2007 14:57:15 +0100 Subject: User directories integration - request for help In-Reply-To: <1174052888.5822.5.camel@localhost.localdomain> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> Message-ID: <1174053435.4680.150.camel@mccallum.corsepiu.local> On Fri, 2007-03-16 at 09:48 -0400, Matthias Clasen wrote: > On Fri, 2007-03-16 at 09:33 -0400, Simo Sorce wrote: > > On Fri, 2007-03-16 at 08:52 +0100, Ralf Ertzinger wrote: > > > Hi. > > > > > > On Fri, 16 Mar 2007 01:38:00 +0530, Rahul Sundaram wrote: > > > > > > > > Renaming a user's directories doesn't seem to be "The UNIX Way" TM > > > > > > > > Traditional Unix systems never had to deal with many of the modern > > > > desktop requirements so it's high time we stopped citing the "the > > > > unix way" as a excuse not to change anything. All modern Linux > > > > desktop systems happily automount devices which is distinctly not > > > > unixy either. If there are real practical reasons just cite that > > > > specifically. > > > > > > OSX gets this right, from what I remember. The applications folder is > > > always called "Applications" on disk, but the displayed name in Finder > > > (and open/save dialogs) is specific to the language settings of the > > > current user. > > > > YES, please, DO NOT rename directories in different languages! Madness > > will come out of it. > > > > [...] ACK. > > If you really want to do it, choose a fixed name and change Gnome/Kde to > > understand how to display these "special" dirs names into a localized > > way (maybe with an option to disable this thing). > > The tradeoffs of translation-on-disk vs. translation-only-in-ui have > been discussed for years. Please don't let this thread devolve into > rehashing all the arguments for the umpteenth time. Well, provided what you seem to plan, whether you like it or not: Please do, time is due to re-heat this discussion! Alternatively, if you want to avoid this discussion: Implement a 3-state user's choice (With a) being the default): a) Don't translate directories b) Translate their GUI representation only. c) Translate and move them around wheneven i18n is being changed. Ralf From nicolas.mailhot at laposte.net Fri Mar 16 14:00:35 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 16 Mar 2007 15:00:35 +0100 (CET) Subject: User directories integration - request for help In-Reply-To: <45F9EF29.6020901@fedoraproject.org> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> Message-ID: <34708.192.54.193.51.1174053635.squirrel@rousalka.dyndns.org> Le Ven 16 mars 2007 02:13, Rahul Sundaram a ?crit : > Andr? Kelpe wrote: > >> Because many people hate it, when something automagically clutters up >> their home. My home is my castle :-)! I decide, not a tool, that thinks >> it knows better than me... > > Desktop is the folder you would seeing on a typical desktop environment. > Not home. Enough people disagree with this using $HOME as default has been an option for a very long time. Many people that promoted Desktop instead of HOME publicly conceded the main reason was the legacy dotfoo mess in homedirs Ironically GNOME & KDE have become complete and prevalent enough had GNOME & KDE people decided to clean their dotdir/file use then this reason would not stand now. Instead we hid the mess under the "Desktop" carpet and it's still lurking there. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Fri Mar 16 14:02:07 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 16 Mar 2007 15:02:07 +0100 (CET) Subject: User directories integration - request for help In-Reply-To: <3adc77210703152006g20adce56x9f003083454a9da6@mail.gmail.com> References: <1173953610.10024.132.camel@greebo> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> <3adc77210703152006g20adce56x9f003083454a9da6@mail.gmail.com> Message-ID: <39373.192.54.193.51.1174053727.squirrel@rousalka.dyndns.org> Le Ven 16 mars 2007 04:06, Naheem Zaffar a ?crit : > This will probably be a totally stupid idea, but I have to mention it. > > Why not dump everything in the home folder as standard and then use > that nautilus search folders thing to organise everything? Because a boatload of tools do not use nautilus not should rely on it Because good rules always work better than euristics -- Nicolas Mailhot From mattdm at mattdm.org Fri Mar 16 14:15:05 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 16 Mar 2007 10:15:05 -0400 Subject: what makes a package get i386 on x86_64? In-Reply-To: <200703152248.33585.jkeating@redhat.com> References: <20070315213846.GA13190@jadzia.bu.edu> <200703152226.10050.jkeating@redhat.com> <20070316024230.GA6280@jadzia.bu.edu> <200703152248.33585.jkeating@redhat.com> Message-ID: <20070316141505.GA25567@jadzia.bu.edu> On Thu, Mar 15, 2007 at 10:48:33PM -0400, Jesse Keating wrote: > > My understanding is that you can, as of 4.4.1. > Hrm, I know you can on the cli, rpm -q foo.i386 rpm -e bar.x86_64, but you > couldn't do arch specific things in the spec, like BuildRequires glibc.i386 > or some such. Okay, so I can confirm that this doesn't work. However, it turns out that my package update has rearranged things enough so that there's no conflict. So the worst that happens is cruft, not a conflict during upgrade. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From nicolas.mailhot at laposte.net Fri Mar 16 14:17:44 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 16 Mar 2007 15:17:44 +0100 (CET) Subject: User directories integration - request for help In-Reply-To: <1174035564.10024.177.camel@greebo> References: <1173953610.10024.132.camel@greebo> <20070315145337.GA9180@jadzia.bu.edu> <1174035564.10024.177.camel@greebo> Message-ID: <39996.192.54.193.51.1174054664.squirrel@rousalka.dyndns.org> Le Ven 16 mars 2007 09:59, Alexander Larsson a ?crit : > The config is stored in a shell-style file to make it easier to read in > a shell script: > > cat ~/.config/user-dirs.dirs > # This file is written by xdg-user-dirs-update > # If you want to change or add directories, just edit the line you're > # interested in. All local changes will be retained on the next run > # Format is XDG_xxx_DIR="$HOME/yyy", where yyy is a shell-escaped > # homedir-relative path, or XDG_xxx_DIR="/yyy", where /yyy is an > # absolute path. No other format is supported. > # > XDG_DESKTOP_DIR="$HOME/Skrivbord" > XDG_DOWNLOAD_DIR="$HOME/H?mtat" > XDG_TEMPLATES_DIR="$HOME/Templates" > ... > Alternate KISS implementation : A. first time a GUI app needs MUSIC, DOWNLOAD or whatever open a file selector allowing the user: b. to select the appropriate directory he created (and named) by other means c. or to create a new dir (with a default hint) B. When a (pre)existing dir is selected create ~/.config/user-dirs/ (if it does not exist) C. put a MUSIC, DOWNLOAD or whatever symmlink there pointing to the user selection D. when another app needs the same resource, have it follow the symlink if it exists, else go to A No pre-created directory skeleton, no renaming dance, no "MyFoo" structure forced on the user, no file migration, just symlinks any GUI or CLI app can find and follow -- Nicolas Mailhot From ajackson at redhat.com Fri Mar 16 14:22:35 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 16 Mar 2007 10:22:35 -0400 Subject: New User With A Suggestion In-Reply-To: References: Message-ID: <1174054955.10657.138.camel@localhost.localdomain> On Thu, 2007-03-15 at 22:38 -0400, Jesse Petre wrote: > The root of all problems came from the X config being installed with a > default bit-depth of 24-bits. My monitor does not support 24-bit > color, only 16 and 32, so after installing Fedora, my monitor would > simply flash "input not supported". Nope, sorry. So there's two phenomena here. There's color depth, and there's bits per pixel. Bits per pixel is how many bits of memory a pixel consumes. Color depth is how many of those bits are used to represent color information. Color depth <= bits per pixel, always. The normal format we choose is depth 24, 32bpp. You can also do depth 24, 24bpp, but it's usually much slower since 3/4's of your pixels will now require unaligned memory accesses. But there's literally no depth 32 format in the X server. All of which is sort of besides the point: your monitor never sees any of this. If it's VGA, then you're just wiggling analog pins, and the color depth just reflects the precision with which the pins are wiggled. If it's a digital connector like DVI-D or laptop-internal LVDS, then the DVI transmitter pads the color information out to eight bits per color channel anyway. So what you actually found was a bug in which we appear to program the monitor _timings_ wrong in 16bpp, but not in 32bpp. That's actually quite interesting, and I would greatly appreciate it if you would file a bug report with the X logs (/var/log/Xorg.0.log) from attempting to start at both 16 and 32bpp. - ajax From tmus at tmus.dk Fri Mar 16 15:10:33 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 16 Mar 2007 16:10:33 +0100 Subject: Fedora extras metadata In-Reply-To: <20070316103856.9156a362.mschwendt.tmp0701.nospam@arcor.de> References: <45F9C515.3060804@zoeloelip.be> <20070315234339.7065f318.mschwendt.tmp0701.nospam@arcor.de> <20070316103856.9156a362.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt wrote: >> /Thomas > > What does the algorithm look like? > > "Handshake" implies bidirectional communication, which is not > available. We only have "slave retrieves from master" or "slave retrieves > from slave" relationships. Mutual exclusion is not possible either. Flag > files don't make the mirroring an atomic operation. The master can still > break the scheme and push updates while a mirror is downloading in believe > that the previously checked flag file was up-to-date. > IIRC, something like echoing the output of `date` into af file named "mirror.wherever.com" in a special dir, upon successful synchronization from upstream mirror. That same file would be deleted when starting the next sync (there are tricks you can do, like download new packages to a temporary dir before deleting old packages and moving stuff in place, to shorten that period as much as possible). The point would be that if I'm syncing from mirror.somehost.com, I can check if the file mirror.somehost.com exists before even trying. If it exists, the mirror is consistent, but could still be stale. Staleness would be evident from the timestamp. Also, since we would sync the special directory with the mirror.somehost.com file, we can even track problems to watever upstream mirror host and check how old this particular set of packages has been on their way from the main site. Something along those lines. See http://www.debian.org/mirror/ftpmirror for more info on how the debian project does it, and perhaps we can be inspired by that. search for project/trace on that site, since that's where they'll throw the timestamp file. /Thomas From paul at city-fan.org Fri Mar 16 15:42:49 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 16 Mar 2007 15:42:49 +0000 Subject: ppc/fc5 build failure for lat 1.2.2 Message-ID: <45FABAF9.6040205@city-fan.org> I'm trying to build an update for lat 1.2.2 (which has already built successfully in the past but installed into different directories) and the FC5/ppc build is failing: http://buildsys.fedoraproject.org/logs/fedora-5-extras/29458-lat-1.2.2-2.fc5/ppc/build.log The same package builds ok on FC-6 and devel (all arches) and FC-5.(i386 & x86_64). + umask 022 + cd /builddir/build/BUILD + cd lat-1.2.2 + LANG=C + export LANG + unset DISPLAY + /bin/rm -rf /var/tmp/lat-1.2.2-2.fc5-root-mockbuild + /usr/bin/make DESTDIR=/var/tmp/lat-1.2.2-2.fc5-root-mockbuild appicondir=/usr/share/icons/hicolor/22x22/apps install Making install in gnome-keyring-glue make[1]: Entering directory `/builddir/build/BUILD/lat-1.2.2/gnome-keyring-glue' /usr/bin/gmcs -unsafe -target:library -out:gnome-keyring-glue.dll ./Attribute.cs ./AttributeType.cs ./Found.cs ./Global.cs ./GnomeKeyringSharp.OperationGetIntCallbackNative.cs ./GnomeKeyringSharp.OperationGetListCallbackNative.cs ./ItemType.cs ./NetworkPasswordData.cs ./OperationGetIntCallback.cs ./OperationGetListCallback.cs ./Result.cs -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/pango-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/atk-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gdk-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gtk-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/glib-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gnome-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/art-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gnome-vfs-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gconf-sharp.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/gconf-sharp-peditors.dll -r:/usr/lib/pkgconfig/../../lib/mono/gtk-sharp-2.0/glade-sharp.dll ** ERROR **: _wapi_collection_init: Couldn't create handle collection thread: Invalid argument aborting... make[1]: *** [gnome-keyring-glue.dll] Aborted make[1]: Leaving directory `/builddir/build/BUILD/lat-1.2.2/gnome-keyring-glue' make: *** [install-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.49317 (%install) I tried requeueing the build in case it was a transient failure and it fell over in exactly the same way. Any thoughts? Paul. From Michael_E_Brown at dell.com Fri Mar 16 17:06:59 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 16 Mar 2007 12:06:59 -0500 Subject: User directories integration - request for help In-Reply-To: <1173988854.3535.0.camel@localhost.localdomain> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> Message-ID: <20070316170658.GA5795@humbolt.us.dell.com> On Thu, Mar 15, 2007 at 04:00:54PM -0400, Matthias Clasen wrote: > On Thu, 2007-03-15 at 20:29 +0100, nodata wrote: > > Am Donnerstag, den 15.03.2007, 14:03 -0400 schrieb Matthias Clasen: > > > On Thu, 2007-03-15 at 11:13 +0100, Alexander Larsson wrote: > > > > > > > > Any other ideas? > > > > > > Might be a good idea to give a quick explanation of what happens, and > > > what people should expect to see if they install the packages. > > > > > > Matthias > > > > > > > >From the looks of it, the directories get continually renamed if you > > switch languages. Stay away from my home dir, use a dot file if you > > must! > > Any you continually switch languages ?! Necesito practicar todos los lenguas que hablo, y por eso, I switch login sessions periodically between English and Spanish to keep my spanish from becoming rusty. Y, a veces, uso dos lenguas a el mismo tiempo. -- Michael From skvidal at linux.duke.edu Fri Mar 16 17:22:01 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 16 Mar 2007 13:22:01 -0400 Subject: repoview in our repositories In-Reply-To: <20070315154423.4b861ee1.mschwendt.tmp0701.nospam@arcor.de> References: <20070309181701.feaff257.mschwendt.tmp0701.nospam@arcor.de> <6792.65.192.24.190.1173473218.squirrel@mail.jcomserv.net> <20070315154423.4b861ee1.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1174065721.20424.283.camel@cutter> On Thu, 2007-03-15 at 15:44 +0100, Michael Schwendt wrote: > After some modifications in repoview, here's what it could look like: > > http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/ > > http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/repoview/pbzip2.html > > *** Note that the download links to the packages don't work, as above URL > is not a full repository. Did you pass these modification upstream to the repoview maintainer? I'm sure Icon would take a look at them. -sv From Michael_E_Brown at dell.com Fri Mar 16 17:24:18 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 16 Mar 2007 12:24:18 -0500 Subject: Fedora extras metadata In-Reply-To: References: <45F9C515.3060804@zoeloelip.be> <20070315234339.7065f318.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070316172417.GB5795@humbolt.us.dell.com> On Fri, Mar 16, 2007 at 08:17:47AM +0100, Thomas M Steenholdt wrote: > Michael Schwendt wrote: > >> > >>What is going on with fedora extras metadata lately? > > > >Nothing. It's just the mirrors that choke on daily updates and don't sync > >safely and frequently enough. > > > This seems to be happening more often that we could hope for. > Is there a documented way to set up mirroring, to ENSURE that the > mirrors are in a consistent state? > If not - and I believe this has been brought up earlier (by myself). I > really think we could do with a simple timestamping mirror handshake > mechanism, kinda like what debian does. This would allow mirrors to > monitor for a special file and when that file is available, we know the > mirror is in a consistent state (as consistent as it's master - which > can also be tracked in this way). Mirrors could easily add a few lines > to their scripts to honor this kind of thing, without the need for > special mirroring tools. > > Just a suggestion Matt Domsch is working on just such a tool and is looking to have it in place for F7 release, afaik. The tool is Mirror Manager. http://fedoraproject.org/wiki/Infrastructure/RFR/MirrorManager He has a beta out there, iirc. If you have python/turbogears experience, I think he could use help on it. -- Michael From wtogami at redhat.com Fri Mar 16 17:34:22 2007 From: wtogami at redhat.com (Warren Togami) Date: Fri, 16 Mar 2007 13:34:22 -0400 Subject: Merge Review Process, Clarification Message-ID: <45FAD51E.80206@redhat.com> http://fedoraproject.org/PackageReviewStatus As of yesterday, 21% of Merge Review tickets have been touched. Merge Review as Cleanup Sweep ============================= FESCO and Fedora Rel-eng have decided to treat the Merge Review as a package quality cleanup sweep. This means the Merge Review is not a blocker for the Fedora Merge. All Core packages will merge into the Fedora distribution when the infrastructure is ready regardless of their approval status. Cleanup Sweep ============= Core package maintainers: - Please continue to follow your Merge Review tickets and check changes into your rawhide packages if they are technically sound. - After the ticket is flagged fedora-review+ approved, the package may be set to CLOSED RAWHIDE after the new binary package has been tested and verified. http://www.redhat.com/mailman/listinfo/fedora-maintainers If disagreements occur between reviewers and package maintainers, please escalate the issue to fedora-maintainers list. fedora-maintainers is our public facing, by-invite-only development discussion list that is typically more focused than fedora-devel-list. All Red Hat package maintainers and engineers please subscribe to this list and I will approve you. Merge Review Cleanup Ends at Fedora 7 Test4 =========================================== http://fedoraproject.org/wiki/Releases/Schedule By the current schedule, this means April 16th. We will want to slow down the rate of churn at that point in order to ensure greater distribution stability. After this development freeze, please no longer include mere cleanups to the rawhide packages unless there is a REALLY GOOD REASON. Any exceptions to the development freeze may be permitted by standard release engineering procedures. After Fedora 7 is released, Merge Review quality cleanups are to continue in rawhide. Warren Togami wtogami at redhat.com From mclasen at redhat.com Fri Mar 16 17:45:32 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 16 Mar 2007 13:45:32 -0400 Subject: User directories integration - request for help In-Reply-To: <1174053435.4680.150.camel@mccallum.corsepiu.local> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> Message-ID: <1174067132.3434.1.camel@localhost.localdomain> On Fri, 2007-03-16 at 14:57 +0100, Ralf Corsepius wrote: > > The tradeoffs of translation-on-disk vs. translation-only-in-ui have > > been discussed for years. Please don't let this thread devolve into > > rehashing all the arguments for the umpteenth time. > > Well, provided what you seem to plan, whether you like it or not: Please > do, time is due to re-heat this discussion! No. Just go read xdg-list archives if you are interested in the arguments. > Alternatively, if you want to avoid this discussion: > > Implement a 3-state user's choice (With a) being the default): > a) Don't translate directories > b) Translate their GUI representation only. > c) Translate and move them around wheneven i18n is being changed. Avoid discussion by not making any decisions ? How is that a solution ? From dwmw2 at infradead.org Fri Mar 16 17:47:04 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 16 Mar 2007 18:47:04 +0100 Subject: ppc/fc5 build failure for lat 1.2.2 In-Reply-To: <45FABAF9.6040205@city-fan.org> References: <45FABAF9.6040205@city-fan.org> Message-ID: <1174067224.32129.2.camel@shinybook.infradead.org> On Fri, 2007-03-16 at 15:42 +0000, Paul Howarth wrote: > I'm trying to build an update for lat 1.2.2 (which has already built > successfully in the past but installed into different directories) and > the FC5/ppc build is failing: Mail me a SSH public key and I'll provide an account on a suitable machine for debugging. -- dwmw2 From Michael_E_Brown at dell.com Fri Mar 16 17:50:07 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 16 Mar 2007 12:50:07 -0500 Subject: noarch packages that arent applicable for ppc? Message-ID: <20070316175007.GC5795@humbolt.us.dell.com> How do I get a noarch package to stay out of the PPC repo? I just added firmware-tools and firmware-addon-dell to FC6/7 and then got the broken dependencies message this morning for firmware-addon-dell. The firmware-addon-dell package is pure python, and thus noarch. It has a dependency on libsmbios-bin, as it runs a couple of binaries and interprets their output. Libsmbios is ia64/ix86/x86_64 only as other arches do not have the DMI BIOS tables. -- Michael From seg at haxxed.com Fri Mar 16 18:10:26 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 16 Mar 2007 13:10:26 -0500 Subject: User directories integration - request for help In-Reply-To: <1174001196.3535.9.camel@localhost.localdomain> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <1174001196.3535.9.camel@localhost.localdomain> Message-ID: <1174068626.14325.76.camel@localhost.localdomain> On Thu, 2007-03-15 at 19:26 -0400, Matthias Clasen wrote: > On Fri, 2007-03-16 at 00:01 +0100, Patrice Dumas wrote: > > On Fri, Mar 16, 2007 at 01:38:00AM +0530, Rahul Sundaram wrote: > > > > > > If there are real practical reasons just cite that specifically. > > > > The use home directory shouldn't have non dot files (or directories) > > used by the applications. > > Because we like to leave the user alone with the task of organizing his > data, music, documents, etc ? To force them to learn something about > filesystem organization and application configuration before they can > use their systems ? +1 Especially once you toss internationalization into the mix, this is all turning in to a giant gob of over-complex hacks that overshadows any benefit. KISS. If the user wants folders, they can make them themselves, in whatever language they want. Make all apps default their file selectors to the last directory used in a sane manner. -------------- 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 mclasen at redhat.com Fri Mar 16 18:17:39 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 16 Mar 2007 14:17:39 -0400 Subject: User directories integration - request for help In-Reply-To: <1174068626.14325.76.camel@localhost.localdomain> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <1174001196.3535.9.camel@localhost.localdomain> <1174068626.14325.76.camel@localhost.localdomain> Message-ID: <1174069059.3434.3.camel@localhost.localdomain> On Fri, 2007-03-16 at 13:10 -0500, Callum Lerwick wrote: > On Thu, 2007-03-15 at 19:26 -0400, Matthias Clasen wrote: > > On Fri, 2007-03-16 at 00:01 +0100, Patrice Dumas wrote: > > > On Fri, Mar 16, 2007 at 01:38:00AM +0530, Rahul Sundaram wrote: > > > > > > > > If there are real practical reasons just cite that specifically. > > > > > > The use home directory shouldn't have non dot files (or directories) > > > used by the applications. > > > > Because we like to leave the user alone with the task of organizing his > > data, music, documents, etc ? To force them to learn something about > > filesystem organization and application configuration before they can > > use their systems ? > > +1 > > Especially once you toss internationalization into the mix, this is all > turning in to a giant gob of over-complex hacks that overshadows any > benefit. KISS. If the user wants folders, they can make them themselves, > in whatever language they want. Make all apps default their file > selectors to the last directory used in a sane manner. I guess you didn't pick up the sarcasm in my response... From jkeating at redhat.com Fri Mar 16 18:29:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 16 Mar 2007 14:29:33 -0400 Subject: noarch packages that arent applicable for ppc? In-Reply-To: <20070316175007.GC5795@humbolt.us.dell.com> References: <20070316175007.GC5795@humbolt.us.dell.com> Message-ID: <200703161429.33974.jkeating@redhat.com> On Friday 16 March 2007 13:50:07 Michael E Brown wrote: > ? ? How do I get a noarch package to stay out of the PPC repo? You have to add an ExcludeArch to the package and rely upon ugly ugly hacks in compose tools that look up the srpm for each noarch package to determine what the Exclude/Exclusive arches are and adjust accordingly. See my attempts at ending this insanity on fedora-maintainers. I think we either need to stop calling these things noarch since they rely on arch specific things, or we need to patch rpm so that Exclude/ExclusiveArch is propagated from the srpm to the resultant rpm. -- 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 rc040203 at freenet.de Fri Mar 16 18:29:36 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Mar 2007 19:29:36 +0100 Subject: User directories integration - request for help In-Reply-To: <1174067132.3434.1.camel@localhost.localdomain> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> Message-ID: <1174069776.4680.170.camel@mccallum.corsepiu.local> On Fri, 2007-03-16 at 13:45 -0400, Matthias Clasen wrote: > On Fri, 2007-03-16 at 14:57 +0100, Ralf Corsepius wrote: > > > > The tradeoffs of translation-on-disk vs. translation-only-in-ui have > > > been discussed for years. Please don't let this thread devolve into > > > rehashing all the arguments for the umpteenth time. > > > > Well, provided what you seem to plan, whether you like it or not: Please > > do, time is due to re-heat this discussion! > > No. Just go read xdg-list archives if you are interested in the > arguments. Frankly speaking, I am not interested in arguing, I wanted to hear yours, because I for one find "i18n'ed" dirs utterly stupid. > > Alternatively, if you want to avoid this discussion: > > > > Implement a 3-state user's choice (With a) being the default): > > a) Don't translate directories > > b) Translate their GUI representation only. > > c) Translate and move them around wheneven i18n is being changed. > > Avoid discussion by not making any decisions ? Yes, let the user/admin choose, instead of pestering them with a half-cooked decision you will always make enemies with. > How is that a solution ? See above - It's basically trying to avoid a problem. IMO, to a large amount of users, you are not solving a problem, you are constructing a new ones. Ralf From seg at haxxed.com Fri Mar 16 18:31:14 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 16 Mar 2007 13:31:14 -0500 Subject: disabling warn_unused_result attribute with FORTIFY_SOURCE? In-Reply-To: References: <20070315023020.GA20627@jadzia.bu.edu> <45F8CC99.1000907@ioa.s.u-tokyo.ac.jp> Message-ID: <1174069874.14325.80.camel@localhost.localdomain> On Thu, 2007-03-15 at 14:47 +0000, Kevin Kofler wrote: > Kevin Kofler chello.at> writes: > > You're right, I didn't know that. That's pretty stupid, (void) has always > > meant "I intentionally throw away this value and I mean it". :-/ > > This has actually been filed as a GCC bug (which I agree it is) over a year ago > by Dirk Mueller from KDE. Sadly, it has been marked WONTFIX. :-( > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509 It looks like it was closed WONTFIX because the gcc developers believe the "bug" is in glibc setting warn_unused_result in the first place. gcc is merely acting as designed. Seems reasonable 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 jwboyer at jdub.homelinux.org Fri Mar 16 19:41:09 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 16 Mar 2007 14:41:09 -0500 Subject: User directories integration - request for help In-Reply-To: <20070316170658.GA5795@humbolt.us.dell.com> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <20070316170658.GA5795@humbolt.us.dell.com> Message-ID: <1174074070.16140.13.camel@zod.rchland.ibm.com> On Fri, 2007-03-16 at 12:06 -0500, Michael E Brown wrote: > On Thu, Mar 15, 2007 at 04:00:54PM -0400, Matthias Clasen wrote: > > On Thu, 2007-03-15 at 20:29 +0100, nodata wrote: > > > Am Donnerstag, den 15.03.2007, 14:03 -0400 schrieb Matthias Clasen: > > > > On Thu, 2007-03-15 at 11:13 +0100, Alexander Larsson wrote: > > > > > > > > > > Any other ideas? > > > > > > > > Might be a good idea to give a quick explanation of what happens, and > > > > what people should expect to see if they install the packages. > > > > > > > > Matthias > > > > > > > > > > >From the looks of it, the directories get continually renamed if you > > > switch languages. Stay away from my home dir, use a dot file if you > > > must! > > > > Any you continually switch languages ?! > > Necesito practicar todos los lenguas que hablo, y por eso, > > I switch login sessions periodically between English and Spanish to > keep my spanish from becoming rusty. > > Y, a veces, uso dos lenguas a el mismo tiempo. Tu estas loco. josh From mattdm at mattdm.org Fri Mar 16 20:01:34 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 16 Mar 2007 16:01:34 -0400 Subject: Request for review: festival 1.96 update Message-ID: <20070316200134.GA21634@jadzia.bu.edu> I posted about this on the maintainers list the other day, and I figure I should open up to a wider audience too. I'm working on new Festival packages, which among other things splits the voices out so we can take up less room on the livecd. (4.7M instead of 24M.) See for details (and get packages from , as mentioned there). I think at this point the packages are pretty much good to go, and I think David Zeuthen is going to put them into rawhide soon (hopefully before the feature freeze). But more eyes would be good. Some notes: rpmlint complains: W: festival-devel no-dependency-on festival W: festival-speechtools-devel no-dependency-on festival-speechtools which is intentional -- there's deps on the corresponding -lib/-libs packages instead. There's a zillion subpackages; my intention is to change to separate source RPMs in some future incarnation. (This is why I went ahead and split out festival-devel and festival-speech-tools-devel at this point.) Also, I note that the package is a mashup of licenses. I think they're all various compatible MIT/BSD-style (and the documentation takes pains to note that everything is under free and compatible licenses), but someone should look at that. Preferably not me. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jsacco at gnome.org Fri Mar 16 20:01:55 2007 From: jsacco at gnome.org (Joseph Sacco) Date: Fri, 16 Mar 2007 16:01:55 -0400 Subject: Problem setting up IP MASQUERADE with recent kernels Message-ID: <1174075315.3270.2.camel@rt.jesacco.com> Problem ------- With recent 2.6.21.x kernels IP-Masquerading, required by Mac-On-Linux, has stopped working as expected. Question -------- Has anyone successfully set up IP Masquerading using a recent kernel? Discussion ---------- Mac-On-Linux http://sourceforge.net/projects/mac-on-linux/ is a Linux/PPC program that virtualizes MacOS or MacOSX in Linux. MOL uses an IP tunnel to eastabish communications between the Linux host and the virtualized MAC operating system. -Ethernet---------------------------------------- | | 130.237.226.234 | 130.237.226.239 eth0 | other_machine linux tun1 | 192.168.41.1 | | virtual +--- ip-tunnel ------- MOL 192.168.41.2 The Linux host performs network address translation to enable MOL to communicate with the external network. The mechanisms used by Mac-On-Linux to set up the IP tunnel and set up NAT have worked successfully with 2.4.x and 2.6.x series kernels until recently. Mac-on-Linux networking works correctly when run on FC6. It has also run on fedora/rawhide with earlier 2.6.20.x kernels. Two thoughts come to mind: * a kernel module has gone missing ==> kernel configuration problem * "something has changed" with how IP-Masquerading is setup / works. I have examined the kernel configuration file for IPV4 netfiltering and have not found any obvious omissions. [That does not mean that there are no omissions of required modules. It just means I did not spot them.] The only "suspect" is CONN_NF_CONNTRACK_PROC_COMPAT. What appears to be happening with the latest kernels is some necessary kernel modules are not being loaded initially. Consider the output from 'lsmod' from two successive attempts of starting Mac-On-Linux: Attempt #1 ---------- Mac-On-Linux comes up. Networking is borked. [output from ldmod] Module Size Used by nf_nat 20660 0 nf_conntrack_ipv4 13448 1 nf_conntrack 73408 2 nf_nat,nf_conntrack_ipv4 nfnetlink 8344 3 nf_nat,nf_conntrack_ipv4,nf_conntrack ip_tables 14900 0 x_tables 18404 1 ip_tables tun 13728 1 mol 59304 1 Conspicuously absent from this list are * iptable_nat * ipt_MASQUERADE Running 'dmesg' may provide a hint: [output from dmesg] MOL 0.9.73-SVN kernel module loaded PM: Adding info for No Bus:mol tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky PM: Adding info for No Bus:tun PM: Adding info for No Bus:tun1 Hmmmm... "can't setup rules." There it is again. Wonder what's going on. Thoughts??? -Joseph -- jsacco [at] gnome [dot] org From pertusus at free.fr Fri Mar 16 20:32:13 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 16 Mar 2007 21:32:13 +0100 Subject: Merge Review Process, Clarification In-Reply-To: <45FAD51E.80206@redhat.com> References: <45FAD51E.80206@redhat.com> Message-ID: <20070316203213.GA2918@free.fr> On Fri, Mar 16, 2007 at 01:34:22PM -0400, Warren Togami wrote: > All this seems right to me. Indeed, sometime the issues are not problematic in the short term, but the package isn't acceptable and cleaning things requires some work. This is typically the case for patchesets that accumulated over the years and have become unreadable. Also, (unless I am wrong) the merge will allow dependencies or merge with former extras packages, and I think it is better to do that during packages review. -- Pat From tmus at tmus.dk Fri Mar 16 21:01:57 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 16 Mar 2007 22:01:57 +0100 Subject: Fedora extras metadata In-Reply-To: <20070316172417.GB5795@humbolt.us.dell.com> References: <45F9C515.3060804@zoeloelip.be> <20070315234339.7065f318.mschwendt.tmp0701.nospam@arcor.de> <20070316172417.GB5795@humbolt.us.dell.com> Message-ID: Michael E Brown wrote: > > Matt Domsch is working on just such a tool and is looking to have it in > place for F7 release, afaik. The tool is Mirror Manager. > This looks like a very competent tool indeed and there's no doubt that it will be very useful for a lot of cases. However I have no idea how the mirror validation in the package will work, I just hope it will be implemented in a way that will be usable without special tools. Having a way to validate a mirror from within the ftp directory listing is very valuable - especially to mirror scripts etc. It looks to me like the MirrorManager will notify the main site that the sync has completed. This is useful, but probably not to other mirror sites (or we may need specialized tools to perform the check). I could easily be mistaken here, though! /Thomas From Matt_Domsch at dell.com Fri Mar 16 23:26:24 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 16 Mar 2007 18:26:24 -0500 Subject: Fedora extras metadata In-Reply-To: References: <45F9C515.3060804@zoeloelip.be> <20070315234339.7065f318.mschwendt.tmp0701.nospam@arcor.de> <20070316172417.GB5795@humbolt.us.dell.com> Message-ID: <20070316232624.GA30219@lists.us.dell.com> On Fri, Mar 16, 2007 at 10:01:57PM +0100, Thomas M Steenholdt wrote: > Michael E Brown wrote: > > > >Matt Domsch is working on just such a tool and is looking to have it in > >place for F7 release, afaik. The tool is Mirror Manager. > > > > This looks like a very competent tool indeed and there's no doubt that > it will be very useful for a lot of cases. However I have no idea how > the mirror validation in the package will work, I just hope it will be > implemented in a way that will be usable without special tools. Having a > way to validate a mirror from within the ftp directory listing is very > valuable - especially to mirror scripts etc. > > It looks to me like the MirrorManager will notify the main site that the > sync has completed. This is useful, but probably not to other mirror > sites (or we may need specialized tools to perform the check). I could > easily be mistaken here, though! First, the problems with the current mirroring is really twofold: 1) the storage array backing the master rsync servers is undergoing some serious stress. This is causing it to be very slow for the master rsync servers that serve the data, thus the global mirror servers pulling from it are seeing very slow syncs. Red Hat I/T is working on it. (It isn't helping that the RHEL5 floodgates opened on Wednesday either - that just added stress to an already stressed set of people and colo networks). 2) the global mirrors aren't being notified when content has changed on the master, such that they should start a new rsync run. mirrormanager takes a per-host email address, which the master sign-and-push scripts will eventually send an email to when the content changes. As it stands, syncing every 6 hours when nothing has changed doesn't make any sense. Now, mirrormanager has 2 methods by which it can know a give mirror host is up-to-date. First is a new report_mirrors script that uploads directory data back to the database from the mirror itself. Not everyone will want to run that, and there's always the 'trust but verify' model, so I've also got a (fast?) crawler that crawls each host using HTTP HEADs and keepalives or FTP DIR calls looking for content it should be carrying compared to the master list, and tracking presence and up-to-date-ness on a per-directory level. Those that aren't up2date get dropped from the appropriate per-directory lists (e.g. the repodata dirs) in real time. That's the idea. A lot of the code is implemented, there's more to go. If you're good with python, turbogears, and the like, I'm sure I could put you to work on it. Drop me a note. Thanks, Matt -- 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 david at fubar.dk Sat Mar 17 00:45:07 2007 From: david at fubar.dk (David Zeuthen) Date: Fri, 16 Mar 2007 20:45:07 -0400 Subject: User directories integration - request for help In-Reply-To: <1174069776.4680.170.camel@mccallum.corsepiu.local> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> Message-ID: <1174092307.2653.29.camel@zelda.fubar.dk> On Fri, 2007-03-16 at 19:29 +0100, Ralf Corsepius wrote: > > No. Just go read xdg-list archives if you are interested in the > > arguments. > Frankly speaking, I am not interested in arguing, I wanted to hear > yours, I think the point was that the arguments are already on that list where, for the record, highly respected GNOME, KDE, XFCE developers already reviewed this without objections. > because I for one find "i18n'ed" dirs utterly stupid. You are entitled to your opinion as is anyone here. Keep in mind it's just not constructive, nor is it useful, to rehash discussions here especially when people like you labels something as "utterly stupid" instead of, say, doing his homework and reading the discussions that already took place in a much better forum e.g. xdg-list. David From ssorce at redhat.com Sat Mar 17 01:49:45 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 16 Mar 2007 21:49:45 -0400 Subject: User directories integration - request for help In-Reply-To: <1174092307.2653.29.camel@zelda.fubar.dk> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> Message-ID: <1174096185.26640.0.camel@willson> On Fri, 2007-03-16 at 20:45 -0400, David Zeuthen wrote: > You are entitled to your opinion as is anyone here. Keep in mind it's > just not constructive, nor is it useful, to rehash discussions here > especially when people like you labels something as "utterly stupid" > instead of, say, doing his homework and reading the discussions that > already took place in a much better forum e.g. xdg-list. Can you please point to a specific thread in the list archives ? Thanks. Simo. From david at fubar.dk Sat Mar 17 02:51:05 2007 From: david at fubar.dk (David Zeuthen) Date: Fri, 16 Mar 2007 22:51:05 -0400 Subject: User directories integration - request for help In-Reply-To: <1174096185.26640.0.camel@willson> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174096185.26640.0.camel@willson> Message-ID: <1174099865.2653.32.camel@zelda.fubar.dk> On Fri, 2007-03-16 at 21:49 -0400, Simo Sorce wrote: > Can you please point to a specific thread in the list archives ? Thread starts here http://lists.freedesktop.org/archives/xdg-list/2007-February/009343.html and isn't that huge. David From rc040203 at freenet.de Sat Mar 17 02:58:36 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Mar 2007 03:58:36 +0100 Subject: User directories integration - request for help In-Reply-To: <1174092307.2653.29.camel@zelda.fubar.dk> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> Message-ID: <1174100317.4680.211.camel@mccallum.corsepiu.local> On Fri, 2007-03-16 at 20:45 -0400, David Zeuthen wrote: > On Fri, 2007-03-16 at 19:29 +0100, Ralf Corsepius wrote: > > > No. Just go read xdg-list archives if you are interested in the > > > arguments. > > Frankly speaking, I am not interested in arguing, I wanted to hear > > yours, > > I think the point was that the arguments are already on that list where, > for the record, highly respected GNOME, KDE, XFCE developers already > reviewed this without objections. Well, I am long enough into this business to have an opinion on my own. > > because I for one find "i18n'ed" dirs utterly stupid. > > You are entitled to your opinion as is anyone here. Keep in mind it's > just not constructive, nor is it useful, to rehash discussions here > especially when people like you labels something as "utterly stupid" Yes, I find this "utterly stupid" because I fail to see any problem this solves and only see "problems this introduces". I am still missing an answer from any of these highly respected GUI devs telling me which USER problem they are solving. The only argument I can imagine is: "Intuition of dirnames" - What they miss: * This had not been an issue to Linux/Unix users ever since Linux/Unix-GUIs exists. * This might only be an issue to Windows users, who expect Linux/Unix to mimic Windows. Technically, all this does is introducing another layer of complexity. > instead of, say, doing his homework and reading the discussions that > already took place in a much better forum e.g. xdg-list. Quite simple, I dislike this (IMO completely useless mal-) feature they want to introduce. I am inclined to consider this to be a "cargo-cult", as somebody recently named such Linux developments on another Fedora list. Ralf From david at fubar.dk Sat Mar 17 03:33:07 2007 From: david at fubar.dk (David Zeuthen) Date: Fri, 16 Mar 2007 23:33:07 -0400 Subject: User directories integration - request for help In-Reply-To: <1174100317.4680.211.camel@mccallum.corsepiu.local> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> Message-ID: <1174102387.2653.62.camel@zelda.fubar.dk> On Sat, 2007-03-17 at 03:58 +0100, Ralf Corsepius wrote: > > I think the point was that the arguments are already on that list where, > > for the record, highly respected GNOME, KDE, XFCE developers already > > reviewed this without objections. > > Well, I am long enough into this business to have an opinion on my own. Again: if you have an opinion then participate upstream because that is where we want to solve a problems if possible. Developers in general are not happy to repeat the same answers over and over again especially to people "too busy" to participate in the right forum. Even if you disagree with the people on xdg-list or their desire to solve some problems (that you obviously disagree with), at least have the courtesy to avoid bike shedding [1] on this list and instead find some more constructive ways to get people to listen to you. Thanks. David [1] : we probably all know this term but just for reference, this is from http://www.bikeshed.com/ From rc040203 at freenet.de Sat Mar 17 03:51:31 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Mar 2007 04:51:31 +0100 Subject: User directories integration - request for help In-Reply-To: <1174102387.2653.62.camel@zelda.fubar.dk> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> Message-ID: <1174103491.4680.227.camel@mccallum.corsepiu.local> On Fri, 2007-03-16 at 23:33 -0400, David Zeuthen wrote: > On Sat, 2007-03-17 at 03:58 +0100, Ralf Corsepius wrote: > > > I think the point was that the arguments are already on that list where, > > > for the record, highly respected GNOME, KDE, XFCE developers already > > > reviewed this without objections. > > > > Well, I am long enough into this business to have an opinion on my own. > > Again: if you have an opinion then participate upstream because that is > where we want to solve a problems if possible. Developers in general are > not happy to repeat the same answers over and over again especially to > people "too busy" to participate in the right forum. You've got it, I don't have the time to participate "in every possible, arbitrary GUI-forum". But I am taking myself the time to warn Fedora devs when a Fedora dev wants to push something into Fedora, "because some upstream" says so. Ralf From david at fubar.dk Sat Mar 17 04:27:37 2007 From: david at fubar.dk (David Zeuthen) Date: Sat, 17 Mar 2007 00:27:37 -0400 Subject: User directories integration - request for help In-Reply-To: <1174103491.4680.227.camel@mccallum.corsepiu.local> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <1174103491.4680.227.camel@mccallum.corsepiu.local> Message-ID: <1174105657.2691.24.camel@zelda.fubar.dk> On Sat, 2007-03-17 at 04:51 +0100, Ralf Corsepius wrote: > On Fri, 2007-03-16 at 23:33 -0400, David Zeuthen wrote: > > On Sat, 2007-03-17 at 03:58 +0100, Ralf Corsepius wrote: > > > > I think the point was that the arguments are already on that list where, > > > > for the record, highly respected GNOME, KDE, XFCE developers already > > > > reviewed this without objections. > > > > > > Well, I am long enough into this business to have an opinion on my own. > > > > Again: if you have an opinion then participate upstream because that is > > where we want to solve a problems if possible. Developers in general are > > not happy to repeat the same answers over and over again especially to > > people "too busy" to participate in the right forum. > You've got it, I don't have the time to participate "in every possible, > arbitrary GUI-forum". But I am taking myself the time to warn Fedora > devs when a Fedora dev wants to push something into Fedora, "because > some upstream" says so. If you had bothered to read the thread on xdg-list (which would have taken less than an hour) you would have found that the "Fedora dev [who] wants to push something into Fedora" is the same person who proposed the this solution on xdg-list and, for the record, got lots of feedback from people affiliated with KDE, XFCE, SUSE, Mandriva, Red Hat, LTSP and others. In the same breath, Alex (aka the "Fedora dev"), is upstream for the Gnome bits (Nautilus and the VFS) using this proposal. It's fine to give feedback on what is flowing into Fedora (because sometimes we want to change defaults), this is partly what we do on this list and the Project encourages it, but if you do so without having done your homework about you're just wasting lots of peoples time. Please don't do that. Thanks. David From rc040203 at freenet.de Sat Mar 17 04:35:34 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Mar 2007 05:35:34 +0100 Subject: User directories integration - request for help In-Reply-To: <1174105657.2691.24.camel@zelda.fubar.dk> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <1174103491.4680.227.camel@mccallum.corsepiu.local> <1174105657.2691.24.camel@zelda.fubar.dk> Message-ID: <1174106134.4680.249.camel@mccallum.corsepiu.local> On Sat, 2007-03-17 at 00:27 -0400, David Zeuthen wrote: > On Sat, 2007-03-17 at 04:51 +0100, Ralf Corsepius wrote: > > On Fri, 2007-03-16 at 23:33 -0400, David Zeuthen wrote: > > > On Sat, 2007-03-17 at 03:58 +0100, Ralf Corsepius wrote: > > > > > I think the point was that the arguments are already on that list where, > > > > > for the record, highly respected GNOME, KDE, XFCE developers already > > > > > reviewed this without objections. > > > > > > > > Well, I am long enough into this business to have an opinion on my own. > > > > > > Again: if you have an opinion then participate upstream because that is > > > where we want to solve a problems if possible. Developers in general are > > > not happy to repeat the same answers over and over again especially to > > > people "too busy" to participate in the right forum. > > You've got it, I don't have the time to participate "in every possible, > > arbitrary GUI-forum". But I am taking myself the time to warn Fedora > > devs when a Fedora dev wants to push something into Fedora, "because > > some upstream" says so. > > If you had bothered to read the thread on xdg-list (which would have > taken less than an hour) you would have found that the "Fedora dev [who] > wants to push something into Fedora" is the same person who proposed the > this solution on xdg-list and, for the record, got lots of feedback from > people affiliated with KDE, XFCE, SUSE, Mandriva, Red Hat, LTSP and > others. In the same breath, Alex (aka the "Fedora dev"), is upstream for > the Gnome bits (Nautilus and the VFS) using this proposal. I am well aware, who this Fedora dev is - It is exactly the reason why I spoke up now. I say: Alex, Matthias wake up and take off your shades. You are going to commit something "stupid"! > It's fine to give feedback on what is flowing into Fedora (because > sometimes we want to change defaults), this is partly what we do on this > list and the Project encourages it, but if you do so without having done > your homework about you're just wasting lots of peoples time. I did read the link you gave, and saw a GUI focused community nodding off an "seemingly innocent" proposal, without fundamental discussion. I say: They missed the lack of usefulness, because they are too focused. Ralf > Please > don't do that. Thanks. From david at fubar.dk Sat Mar 17 04:50:04 2007 From: david at fubar.dk (David Zeuthen) Date: Sat, 17 Mar 2007 00:50:04 -0400 Subject: User directories integration - request for help In-Reply-To: <1174106134.4680.249.camel@mccallum.corsepiu.local> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <1174103491.4680.227.camel@mccallum.corsepiu.local> <1174105657.2691.24.camel@zelda.fubar.dk> <1174106134.4680.249.camel@mccallum.corsepiu.local> Message-ID: <1174107004.2691.31.camel@zelda.fubar.dk> On Sat, 2007-03-17 at 05:35 +0100, Ralf Corsepius wrote: > I say: Alex, Matthias wake up and take off your shades. You are going to > commit something "stupid"! [...] > I say: They missed the lack of usefulness, because they are too focused. So the developers from the desktop projects and the distros (e.g. the people who participate on xdg-list) are all wrong and stupid because they want this feature and you don't? I think we can end this thread... David From rc040203 at freenet.de Sat Mar 17 05:02:56 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Mar 2007 06:02:56 +0100 Subject: User directories integration - request for help In-Reply-To: <1174107004.2691.31.camel@zelda.fubar.dk> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <1174103491.4680.227.camel@mccallum.corsepiu.local> <1174105657.2691.24.camel@zelda.fubar.dk> <1174106134.4680.249.camel@mccallum.corsepiu.local> <1174107004.2691.31.camel@zelda.fubar.dk> Message-ID: <1174107776.4680.259.camel@mccallum.corsepiu.local> On Sat, 2007-03-17 at 00:50 -0400, David Zeuthen wrote: > On Sat, 2007-03-17 at 05:35 +0100, Ralf Corsepius wrote: > > I say: Alex, Matthias wake up and take off your shades. You are going to > > commit something "stupid"! > > [...] > > > I say: They missed the lack of usefulness, because they are too focused. > > So the developers from the desktop projects and the distros (e.g. the > people who participate on xdg-list) are all wrong and stupid because > they want this feature and you don't? _THEY_ (a small group of GUI-focused folks) want it! What they didn't consider: * Many USERS don't want it (I am not alone in complaining here!), because they have been bitten by similar issues before (e.g. under Windows and under certain apps) * This approach will break a lot of things - Not all of this world is GUI-apps. Finally, please answer my question: "Which problem does this approach solve?" Ralf From lightsolphoenix at gmail.com Sat Mar 17 05:46:15 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Sat, 17 Mar 2007 01:46:15 -0400 Subject: User directories integration - request for help In-Reply-To: <1174107776.4680.259.camel@mccallum.corsepiu.local> References: <1173953610.10024.132.camel@greebo> <1174107004.2691.31.camel@zelda.fubar.dk> <1174107776.4680.259.camel@mccallum.corsepiu.local> Message-ID: <200703170146.15455.lightsolphoenix@gmail.com> On Saturday 17 March 2007 1:02:56 am Ralf Corsepius wrote: > [...] > > * This approach will break a lot of things - Not all of this world is > GUI-apps. > > Finally, please answer my question: > "Which problem does this approach solve?" > > Ralf Wait, when did the world switch to using English as a universal language? And "bitten by Windows"? How so; Windows does exactly what you're suggesting here, and in fact I know of cases where people have BROKEN Windows simply because they wanted things named in a non-English language. -- http://www.mozilla.org/products/firefox/ - Get Firefox! http://www.mozilla.org/products/thunderbird/ - Reclaim Your Inbox! Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From rc040203 at freenet.de Sat Mar 17 05:57:53 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Mar 2007 06:57:53 +0100 Subject: User directories integration - request for help In-Reply-To: <200703170146.15455.lightsolphoenix@gmail.com> References: <1173953610.10024.132.camel@greebo> <1174107004.2691.31.camel@zelda.fubar.dk> <1174107776.4680.259.camel@mccallum.corsepiu.local> <200703170146.15455.lightsolphoenix@gmail.com> Message-ID: <1174111073.4680.275.camel@mccallum.corsepiu.local> On Sat, 2007-03-17 at 01:46 -0400, Kelly wrote: > On Saturday 17 March 2007 1:02:56 am Ralf Corsepius wrote: > > [...] > > > > * This approach will break a lot of things - Not all of this world is > > GUI-apps. > > > > Finally, please answer my question: > > "Which problem does this approach solve?" > > > > Ralf > > Wait, when did the world switch to using English as a universal language? Since when has "Desktop", "Mail" or "News" been an issue? Unix users are used to seeing them for decades - Windows aren't used to seeing them. > And "bitten by Windows"? How so; Windows does exactly what you're suggesting > here, The old copy of Win95 I have, uses i18n'ed directories, e.g. ... Anwendungen Netzwerkumgebung ... English counterparts: Programs Network > and in fact I know of cases where people have BROKEN Windows simply > because they wanted things named in a non-English language. Exactly - C.f. above - Push this Windows HOME onto a Samba share and access it from different windows clients using different languages. Ralf From paul at city-fan.org Sat Mar 17 08:30:20 2007 From: paul at city-fan.org (Paul Howarth) Date: Sat, 17 Mar 2007 08:30:20 +0000 Subject: ppc/fc5 build failure for lat 1.2.2 In-Reply-To: <1174067224.32129.2.camel@shinybook.infradead.org> References: <45FABAF9.6040205@city-fan.org> <1174067224.32129.2.camel@shinybook.infradead.org> Message-ID: <1174120220.27507.2.camel@metropolis.intra.city-fan.org> On Fri, 2007-03-16 at 18:47 +0100, David Woodhouse wrote: > On Fri, 2007-03-16 at 15:42 +0000, Paul Howarth wrote: > > I'm trying to build an update for lat 1.2.2 (which has already built > > successfully in the past but installed into different directories) and > > the FC5/ppc build is failing: > > Mail me a SSH public key and I'll provide an account on a suitable > machine for debugging. OK, attached, but it's strange that this version of lat has built on FC5/ppc before so I guess it's an issue with either the builder or one of the buildreqs having changed since that previous build. Cheers, Paul. -------------- next part -------------- ssh-dss AAAAB3NzaC1kc3MAAACBAK31fj1EM+Eqbxl9sz/qW3h2nd6wTuIDPSsyriQAHs2HXfS7kpWY8quOjnTBBMsG3Sst0kjeN1bnSz66nq8SklqUx/3bE1toe9RYxVeYsBaL+nP2IFX+4p4T7Tq/Z5Ub1BN/lyPDgxrZgp1vKZOj8ybJEhW7M5SnyIns2vsxi61DAAAAFQDmnz6rrjEfNw37AXY+OH0RFeMY7QAAAIB3JYubGLUyf4BJdsNA7pJsooFZkSnbaFlMJMpdHdokEbG0O/A4Y1VYCz58M2BBz+wFlCXuSA+IpI9qne7hGLGFztYTl1TxSdcQ7FvuvEZjPKiR/tVc5nBmvJyzpvECg8BJXsjuJ8+0ix3IuhCa0XCL211QnreAcDqSlQn7B5s/TQAAAIAETwgK/I/9YOt14dwSEOi9DGUSy2zCtO3CwMYUYPPjhC1wEhp1dr8dGs3a6rnXq0YTfVRBqW2VeloiDCU9bOZ0EhKon1xeHMExvK+DAkLCz/3LqnhiqFO+rnOwiDKwLb7E+7wdAifUgJdv8qrWHWxUWwgvWlvFI0yZhXWcVyLOuw== paul at city-fan.org From nicolas.mailhot at laposte.net Sat Mar 17 08:46:47 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 17 Mar 2007 09:46:47 +0100 Subject: User directories integration - request for help In-Reply-To: <1174107004.2691.31.camel@zelda.fubar.dk> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <1174103491.4680.227.camel@mccallum.corsepiu.local> <1174105657.2691.24.camel@zelda.fubar.dk> <1174106134.4680.249.camel@mccallum.corsepiu.local> <1174107004.2691.31.camel@zelda.fubar.dk> Message-ID: <1174121207.11892.6.camel@rousalka.dyndns.org> Le samedi 17 mars 2007 ? 00:50 -0400, David Zeuthen a ?crit : > On Sat, 2007-03-17 at 05:35 +0100, Ralf Corsepius wrote: > > I say: Alex, Matthias wake up and take off your shades. You are going to > > commit something "stupid"! > > [...] > > > I say: They missed the lack of usefulness, because they are too focused. > > So the developers from the desktop projects and the distros (e.g. the > people who participate on xdg-list) are all wrong and stupid because > they want this feature and you don't? I think we can end this thread... The people on xdg-list are not stupid but they are GUI devs and they tend to forget a lot of things on a *nix system is not GUI stuff. Remind us again how high gnome-terminal piked in mugshot stats? Would it be so difficult to use symlinks as directory pointers instead of hiding them in yet another config file? That would make cross-user scripting so much easier -- Nicolas Mailhot From pertusus at free.fr Sat Mar 17 08:52:10 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 17 Mar 2007 09:52:10 +0100 Subject: User directories integration - request for help In-Reply-To: <1174092307.2653.29.camel@zelda.fubar.dk> References: <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> Message-ID: <20070317085210.GB3550@free.fr> On Fri, Mar 16, 2007 at 08:45:07PM -0400, David Zeuthen wrote: > > I think the point was that the arguments are already on that list where, > for the record, highly respected GNOME, KDE, XFCE developers already > reviewed this without objections. The group of people you are talking about is a specific group (I will call people in this group the desktop people). It certainly represents a large share of users, especially users that are not unix/linux developpers, but not all. There is a bias in this group toward things that just work and innovation, while in other parts of the community the priority is on user control and stability. And in general those in the non-desktop group are not in the same forums and are specialized in other parts of the system, and ignore the desktop until it changes something in the design of the system that really upset them... (as a side note this is has similarities with the issue of pam in consolekit, for another example). I don't think that one or the other approach are intrinsically better, both target a different audience. Still the solution should satisfy both communities, in my opinion. -- Pat From pertusus at free.fr Sat Mar 17 09:17:50 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 17 Mar 2007 10:17:50 +0100 Subject: User directories integration - request for help In-Reply-To: <1174099865.2653.32.camel@zelda.fubar.dk> References: <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174096185.26640.0.camel@willson> <1174099865.2653.32.camel@zelda.fubar.dk> Message-ID: <20070317091750.GC3550@free.fr> On Fri, Mar 16, 2007 at 10:51:05PM -0400, David Zeuthen wrote: > On Fri, 2007-03-16 at 21:49 -0400, Simo Sorce wrote: > > Can you please point to a specific thread in the list archives ? > > Thread starts here > > http://lists.freedesktop.org/archives/xdg-list/2007-February/009343.html > > and isn't that huge. Still not something somebody not specifically interested in desktop would like to read. Well I read it, and first there doesn't seems to be an agreement on everything. It seems that different approaches are advocated and that there is dissension about localization. What is much more annoying is that nobody said that the user dir should not be cluttered with directories. And also having to discuss about using UTF-8 or user locale encoding is, well, surprising. Something I didn't exactly understood is how and when exactly those directories are to be created. And what about other window managers (fluxbox, icewm...)? -- Pat From pertusus at free.fr Sat Mar 17 09:39:50 2007 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 17 Mar 2007 10:39:50 +0100 Subject: User directories integration - request for help In-Reply-To: <20070317091750.GC3550@free.fr> References: <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174096185.26640.0.camel@willson> <1174099865.2653.32.camel@zelda.fubar.dk> <20070317091750.GC3550@free.fr> Message-ID: <20070317093950.GD3550@free.fr> On Sat, Mar 17, 2007 at 10:17:50AM +0100, Patrice Dumas wrote: > On Fri, Mar 16, 2007 at 10:51:05PM -0400, David Zeuthen wrote: > > On Fri, 2007-03-16 at 21:49 -0400, Simo Sorce wrote: > > > Can you please point to a specific thread in the list archives ? > > > > Thread starts here > > > > http://lists.freedesktop.org/archives/xdg-list/2007-February/009343.html > > > > and isn't that huge. > > Still not something somebody not specifically interested in desktop > would like to read. I didn't read it all. The thread was broken in several pieces on the web interface... > Well I read it, and first there doesn't seems to be an agreement on > everything. It seems that different approaches are advocated and that > there is dissension about localization. > > What is much more annoying is that nobody said that the user dir > should not be cluttered with directories. Now that I have read the whole thread, the proposal to change defaults in file selectors instead of creating directories has already been suggested. I personally agree much more to that approach than with an automatic creation of directories. Something I didn't exactly understood is how and when exactly those directories are to be created (in the advocated approach, that I don't like ;-). And what about other window managers (fluxbox, icewm...)? -- Pat From nicolas.mailhot at laposte.net Sat Mar 17 09:50:03 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 17 Mar 2007 10:50:03 +0100 Subject: User directories integration - request for help In-Reply-To: <20070317091750.GC3550@free.fr> References: <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174096185.26640.0.camel@willson> <1174099865.2653.32.camel@zelda.fubar.dk> <20070317091750.GC3550@free.fr> Message-ID: <1174125003.11892.17.camel@rousalka.dyndns.org> Le samedi 17 mars 2007 ? 10:17 +0100, Patrice Dumas a ?crit : > Still not something somebody not specifically interested in desktop > would like to read. Also it's funny the distribution that actually already tried something like this (mandriva) on production systems used symlinks. They are summarily dismissed afterwards because of users mounting a CIFS home where "the remote host is having a broken/incomplete implementation of CIFS (usually a Windows system)" (SIC). Way to go, make shell users miserable because of this corner case (that could be handled with a config fallback) > Something I didn't exactly understood is how and when exactly those > directories are to be created. Seems this part is not hammered out yet. I'd love if it was "never pre-create/auto-create, prompt the user to select a dir/create a new one whenever we can't find the dir we need" -- Nicolas Mailhot From rc040203 at freenet.de Sat Mar 17 10:10:35 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Mar 2007 11:10:35 +0100 Subject: User directories integration - request for help In-Reply-To: <1174121207.11892.6.camel@rousalka.dyndns.org> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <1174103491.4680.227.camel@mccallum.corsepiu.local> <1174105657.2691.24.camel@zelda.fubar.dk> <1174106134.4680.249.camel@mccallum.corsepiu.local> <1174107004.2691.31.camel@zelda.fubar.dk> <1174121207.11892.6.camel@rousalka.dyndns.org> Message-ID: <1174126235.4680.284.camel@mccallum.corsepiu.local> On Sat, 2007-03-17 at 09:46 +0100, Nicolas Mailhot wrote: > Le samedi 17 mars 2007 ? 00:50 -0400, David Zeuthen a ?crit : > > On Sat, 2007-03-17 at 05:35 +0100, Ralf Corsepius wrote: > > > I say: Alex, Matthias wake up and take off your shades. You are going to > > > commit something "stupid"! > > > > [...] > > > > > I say: They missed the lack of usefulness, because they are too focused. > > > > So the developers from the desktop projects and the distros (e.g. the > > people who participate on xdg-list) are all wrong and stupid because > > they want this feature and you don't? I think we can end this thread... > > The people on xdg-list are not stupid Note: I never said they are stupid - I said they are "going to commit something stupid". > but they are GUI devs and they > tend to forget a lot of things on a *nix system is not GUI stuff. Exactly. As I see it, they are simply too focused/too close to GUI's and probably to keen on imitating WIN features, such they tend to forget about other aspects. E.g. networked $HOME's, user/machine/site-wide defaults/configuration, system integration, runlevels etc. Ralf From buildsys at redhat.com Sat Mar 17 10:27:37 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 17 Mar 2007 06:27:37 -0400 Subject: rawhide report: 20070317 changes Message-ID: <200703171027.l2HARb8o011226@hs20-bc2-6.build.redhat.com> Updated Packages: ElectricFence-2.2.2-22 ---------------------- * Fri Mar 16 2007 Petr Machata - 2.2.2-22 - Remove bad cast in ElectricFence mmap (George Beshers) - Resolves: #232695 * Wed Feb 07 2007 Petr Machata - 2.2.2-21 - Tidy up the specfile per rpmlint comments ant-0:1.6.5-4jpp.1.fc7 ---------------------- * Fri Mar 16 2007 Permaine Cheung 1.6.5-4jpp.1 - Merge with upstream, get rid of the endorsed patch * Tue Feb 20 2007 Permaine Cheung 1.6.5-2jpp.3 - Add endorsed dir and create symlinks for xml-commons-apis and jaxp_parser_impl there, and add the option when running ant. - Add missing BR - Fix some rpmlint issues * Fri Feb 09 2007 Ralph Apel - 0:1.6.5-4jpp - Must skip release 3 because Youri::Bugzilla::_add_version doesn't distinguish between JPP-1.6 and JPP-1.7 and we have 1.6.5-3 in 1.6 bind-31:9.4.0-3.fc7 ------------------- * Tue Mar 13 2007 Adam Tkac 31:9.4.0-3.fc7 - prepared bind to merge review - added experimental idn support to bind-utils utils (not enabled by default yet) - change chroot policy in caching-nameserver post section - fixed bug in bind-chroot-admin - rootdir function is called properly now cups-1:1.2.9-1.fc7 ------------------ * Fri Mar 16 2007 Tim Waugh 1:1.2.9-1 - 1.2.9. eclipse-1:3.2.2-5.fc7 --------------------- * Fri Mar 16 2007 Ben Konrath 3.2.2-5 - Update package-build releng script to work with mylar. epiphany-2.18.0-2.fc7 --------------------- * Fri Mar 16 2007 - Bastien Nocera 2.18.0-2 - Have ephy pick up on the 64-bit plugins (#204547) jakarta-commons-daemon-1:1.0.1-6jpp.2.fc7 ----------------------------------------- * Fri Jan 26 2007 Permaine Cheung - 1:1.0.1-6jpp.2 - Added versioning to provides and obsoletes and rpmlint cleanup jakarta-commons-httpclient-1:3.0.1-1jpp.1.fc7 --------------------------------------------- * Fri Mar 16 2007 Permaine Cheung - 1:3.0.1-1jpp.1 - Merge with upstream and more rpmlint cleanup. * Thu Feb 15 2007 Fernando Nasser - 1:3.0.1-1jpp - Upgrade to 3.0.1 * Fri Jan 26 2007 Permaine Cheung - 1:3.0-8jpp - Added versions for provides and obsoletes and rpmlint cleanup. kernel-2.6.20-1.2997.fc7 ------------------------ * Fri Mar 16 2007 Dave Jones - don't wakeup ondemand timer whilst idle. * Fri Mar 16 2007 Dave Jones - Add driver for USB EHCI debug cables. * Fri Mar 16 2007 John W. Linville - Add snapshot of iwlwifi driver from www.intellinuxwireless.org libvirt-0.2.1-1.fc7 ------------------- * Fri Mar 16 2007 Daniel Veillard - 2.0.1-1.fc7 - Release of 0.2.1 - lot of bug and portability fixes - Add support for network autostart and init scripts - New API to detect the virtualization capabilities of a host - Documentation updates libwpd-0.8.9-1.fc7 ------------------ * Fri Mar 16 2007 Caolan McNamara - 0.8.9-1 - next version make-1:3.81-6.fc7 ----------------- * Fri Mar 16 2007 Petr Machata - 1:3.81-6 - Always run testsuite with C locale. - Resolves: #232607 man-pages-2.43-11.fc7 --------------------- * Fri Mar 16 2007 Ivana Varekova 2.43-11 - Resolves: 230899 Error in the man-pages.spec file: incorrect encoding convertation man-pages-ja-20070315-1 ----------------------- * Fri Mar 16 2007 Akira TAGOH - 20070315-1 - updates to 20070315. - convert a spec file to UTF-8. - remove empty translation_list. samba-0:3.0.24-4.fc7 -------------------- * Fri Mar 16 2007 Guenther Deschner 3.0.24-4.fc7 - fix arch macro which reported Vista to Samba clients. * Thu Mar 15 2007 Simo Sorce 3.0.24-3.fc7 - Directories reorg, tdb files must go to /var/lib, not to /var/cache, add migration script in %post common - Split out devel and doc packages - Remove libmsrpc.[h|so] for now as they are not really usable shadow-utils-2:4.0.18.1-11.fc7 ------------------------------ * Fri Mar 16 2007 Peter Vrabec 2:4.0.18.1-11 - assign system dynamic UID/GID from the top of available UID/GID (#190523) system-config-printer-0.7.56-1.fc7 ---------------------------------- * Fri Mar 16 2007 Tim Waugh 0.7.56-1 - 0.7.56: - Parse Boolean strings correctly in job options. - Small command-set list/string fix (bug #230665). - Handle hostname look-up failures. - Updated filter-to-driver map. - Don't parse printers.conf (bug #231826). 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 mschwendt.tmp0701.nospam at arcor.de Sat Mar 17 10:41:19 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Sat, 17 Mar 2007 11:41:19 +0100 Subject: repoview in our repositories In-Reply-To: <1174065721.20424.283.camel@cutter> References: <20070309181701.feaff257.mschwendt.tmp0701.nospam@arcor.de> <6792.65.192.24.190.1173473218.squirrel@mail.jcomserv.net> <20070315154423.4b861ee1.mschwendt.tmp0701.nospam@arcor.de> <1174065721.20424.283.camel@cutter> Message-ID: <20070317114119.96db3d67.mschwendt.tmp0701.nospam@arcor.de> On Fri, 16 Mar 2007 13:22:01 -0400, seth vidal wrote: > On Thu, 2007-03-15 at 15:44 +0100, Michael Schwendt wrote: > > After some modifications in repoview, here's what it could look like: > > > > http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/ > > > > http://buildsys.fedoraproject.org/plague-results/repoview-test/repodata/repoview/pbzip2.html > > > > *** Note that the download links to the packages don't work, as above URL > > is not a full repository. > > Did you pass these modification upstream to the repoview maintainer? Yes, yesterday. Plus the original post went to him via Cc. ;) > I'm sure Icon would take a look at them. My current proof-of-concept patch collection and changes summary is this: http://home.arcor.de/ms2002sep/tmp/repoview.patch It reduces the size of repoview a tiny bit even. Making it a clean patch that adds the different package view as an option would require a lot of work, which I doubt would be worthwhile (considering the problems with the old structure and user interface). Example for Fedora Extras 6 x86_64 + SRPMS here: http://buildsys.fedoraproject.org/plague-results/repoview-test/6/ One thing I'm still not sure about is what package details to display? Listing Vendor or Packager is not interesting when the values are constants (at least for Fedora) and when a changelog is printed. I think Repoview is great for browsing the package groups, reading the package descriptions, learning about the package names, available versions, but it should not touch the area of old rpmfind, which listed low-level dependencies and other low-level details. From buildsys at fedoraproject.org Sat Mar 17 11:25:30 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sat, 17 Mar 2007 07:25:30 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-17 Message-ID: <20070317112530.6237F152130@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 20 abcm2ps-5.3.1-1.fc7 bwm-ng-0.6-1.fc7 comix-3.6.3-1.fc7 firmware-addon-dell-1.2.4-1.fc7 firmware-tools-1.2.4-1.fc7 gdal-1.4.0-16.fc7 NEW gle-4.0.12a-1.fc7 java-1.5.0-gcj-1.5.0.0-4.fc7 jd-1.8.8-0.2.beta070317.fc7 lat-1.2.2-2.fc7 linphone-1.6.0-4.fc7 linux-libertine-fonts-2.4.9-1.fc7 openvrml-0.16.3-4.fc7 paraview-2.4.4-6.fc7 perl-Devel-StackTrace-1.14-1.fc7 smolt-0.9.4-1.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.2990.fc7 NEW tetrinetx-1.13.16-2.fc7 wesnoth-1.2.3-1.fc7 xmoto-0.2.6-2.fc7 Packages built and released for Fedora Extras 6: 24 abcm2ps-5.3.1-1.fc6 aquamarine-0.2.0-1.fc6 bdock-0.2.0-1.fc6 beryl-core-0.2.0-1.fc6 beryl-manager-0.2.0-1.fc6 beryl-plugins-0.2.0-1.fc6 beryl-settings-0.2.0-1.fc6 comix-3.6.3-1.fc6 emerald-0.2.0-1.fc6 emerald-themes-0.2.0-1.fc6 NEW firmware-addon-dell-1.2.4-1.fc6 gdal-1.4.0-16.fc6 NEW gle-4.0.12a-1.fc6 heliodor-0.2.0-1.fc6 jd-1.8.8-0.2.beta070317.fc6 lat-1.2.2-2.fc6 linphone-1.5.1-4.fc6 linux-libertine-fonts-2.4.9-1.fc6 openvrml-0.16.3-3.fc6 perl-Devel-StackTrace-1.14-1.fc6 smolt-0.9.4-1.fc6 NEW tetrinetx-1.13.16-2.fc6 wesnoth-1.2.3-1.fc6 xmoto-0.2.6-2.fc6 Packages built and released for Fedora Extras 5: 8 Inventor-2.1.5-26.fc5 comix-3.6.3-1.fc5 jd-1.8.8-0.2.beta070317.fc5 linux-libertine-fonts-2.4.9-1.fc5 perl-Devel-StackTrace-1.14-1.fc5 smolt-0.9.4-1.fc5 NEW tetrinetx-1.13.16-2.fc5 xmoto-0.2.6-2.fc5 abcm2ps-5.3.1-1.fc7 ------------------- * Fri Mar 16 2007 Gerard Milmeister - 5.3.1-1 - new version 5.3.1 bwm-ng-0.6-1.fc7 ---------------- * Fri Mar 16 2007 Patrick "Jima" Laughton 0.6-1 - Update - Filename change: changelog -> ChangeLog - Removed tag at start of spec (since I don't use it) comix-3.6.3-1.fc7 ----------------- * Sat Mar 17 2007 Mamoru Tasaka - 3.6.3-1 - 3.6.3 firmware-addon-dell-1.2.4-1.fc7 ------------------------------- * Fri Mar 16 2007 Michael E Brown - 1.2.4-1 - Add ExcludeArch to fix problem where f-a-d was being added to ppc repo firmware-tools-1.2.4-1.fc7 -------------------------- * Fri Mar 16 2007 Michael E Brown - 1.2.4-1 - fix typo in sitelib path -- only for RHEL3 build gdal-1.4.0-16.fc7 ----------------- * Fri Mar 16 2007 Balint Cristian 1.4.0-16 - fix gdal flag from pkgconfig file gle-4.0.12a-1.fc7 ----------------- * Tue Mar 13 2007 Terje Rosten - 4.0.12a-1 - New src upstream, lots of fixes - Dropped subpackage: see updated LICENSE.txt - Add ghostscript to req - Add PDF doc * Mon Mar 12 2007 Terje Rosten - 4.0.12-4 - Try to fix X11 preview support - Drop preserve timestamps patch * Mon Mar 12 2007 Terje Rosten - 4.0.12-3 - Subpackage: gui (different license on gui) - Fix perms on src files (for debug pkg) - Fix src url - Fix LICENSE.txt - Preserve timestamps - More info: bz #229676 * Thu Feb 22 2007 Terje Rosten - 4.0.12-2 - Spec cleanup - Build and ship qgle - Add patch to avoid stripping java-1.5.0-gcj-1.5.0.0-4.fc7 ---------------------------- * Fri Mar 16 2007 Thomas Fitzsimmons - 1.5.0.0-4.fc7 - Remove config(noreplace) markings on security.d files. - Make java-1.4.2-gcj-compat* provides strictly-greater-than 1.4.2.0-40jpp.111. - Remove gjdoc build requirement. - Import java-gcj-compat 1.0.72. * Fri Mar 16 2007 Thomas Fitzsimmons - 1.5.0.0-3.fc7 - Require sinjdoc. jd-1.8.8-0.2.beta070317.fc7 --------------------------- * Sat Mar 17 2007 Mamoru Tasaka - 1.8.8-0.2.beta070317 - 1.8.8 beta 070317 lat-1.2.2-2.fc7 --------------- * Fri Mar 16 2007 Paul Howarth 1.2.2-2 - Upstream now installs correctly into %{_libdir} rather than %{_prefix}/lib so there's no need to override the destination directory in %install; this change gets the plugins installed into the correct directory too (#232278) linphone-1.6.0-4.fc7 -------------------- * Fri Mar 16 2007 Jeffrey C. Ollie - 1.6.0-4 - Fix up encodings in Czech manpages * Fri Mar 16 2007 Jeffrey C. Ollie - 1.6.0-3 - Move autoheader after aclocal, fixes 232592 linux-libertine-fonts-2.4.9-1.fc7 --------------------------------- * Sat Mar 17 2007 Frank Arnold 2.4.9-1 - Updated to 2.4.9 - Reenabled generation of PDF files openvrml-0.16.3-4.fc7 --------------------- * Fri Mar 16 2007 Braden McDaniel - 0.16.3-4 - Updated firefox dependency to 2.0.0.2. paraview-2.4.4-6.fc7 -------------------- * Thu Mar 08 2007 - Orion Poplawski - 2.4.4-6 - Don't build mpi version until upstream fixes the build system * Fri Dec 22 2006 - Orion Poplawski - 2.4.4-5 - Fix .so permissions - Patch for const issue - Patch for new cmake - Build with openmpi * Thu Dec 14 2006 - Jef Spaleta - 2.4.4-4 - Bump and build for python 2.5 perl-Devel-StackTrace-1.14-1.fc7 -------------------------------- * Sat Mar 17 2007 Ralf Cors?pius - 1.14-1 - Upstream update. smolt-0.9.4-1.fc7 ----------------- * Fri Mar 16 2007 Mike McGrath 0.9.4-1 - Upstream released new version - Major changes - Added initial i18n support (Probably doesn't work) sysprof-kmod-1.0.8-1.2.6.20_1.2990.fc7 -------------------------------------- tetrinetx-1.13.16-2.fc7 ----------------------- * Tue Mar 13 2007 Francois Aucamp - 1.13.16-2 - Cleaned up sed scripts in %prep - Replaced config.h patch with sed script in order to support RPM macros - Removed trademarked names from %description wesnoth-1.2.3-1.fc7 ------------------- * Fri Mar 16 2007 Brian Pepple - 1.2.3-1 - Update to 1.2.3. xmoto-0.2.6-2.fc7 ----------------- * Fri Mar 16 2007 Jon Ciesla 0.2.6-1 - Bumped release, build mistake. * Fri Mar 16 2007 Jon Ciesla 0.2.6-1 - New upstream release. - Removed Application from .desktop. - Spec cleanup. - Fixed man path with patch. - Removed X-Fedora. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From sander at hoentjen.eu Sat Mar 17 13:41:39 2007 From: sander at hoentjen.eu (Sander Hoentjen) Date: Sat, 17 Mar 2007 14:41:39 +0100 Subject: tcl in rawhide Message-ID: <1174138899.25580.6.camel@peecee.hoentjen.eu> Hi, when updating tcl in rawhide i get the following: ----------------------------------------------------------------------------- # yum update tcl Loading "fedorakmod" plugin Loading "installonlyn" plugin Setting up Update Process Resolving Dependencies --> Running transaction check Checking deps for tcl.x86_64 1-8.4.13-12.fc7 - None Checking deps for tcl.x86_64 1-8.4.13-13.fc7 - u Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: tcl x86_64 1:8.4.13-13.fc7 development 1.8 M Transaction Summary ============================================================================= Install 0 Package(s) Update 1 Package(s) Remove 0 Package(s) Total download size: 1.8 M Is this ok [y/N]: y Downloading Packages: Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : tcl ######################### [1/2] error: unpacking of archive failed on file /usr/lib64/tcl8.4: cpio: rename Updated: tcl.x86_64 1:8.4.13-13.fc7 Complete! ----------------------------------------------------------------------------- I have 2 comments about this: - Should yum complain about this, like putting failed instead of complete? (first time i didn't notice the update failed) - I think the problem is because in the tcl specfile there is: mkdir -p $RPM_BUILD_ROOT/%{_prefix}/lib ln -s %{_datadir}/%{name}%{majorver} $RPM_BUILD_ROOT/%{_libdir}/%{name}%{majorver} the top line should have libdir too of course. If this is the problem, why doesn't the build fail instead of failing on install time? Sander From alan at redhat.com Sat Mar 17 13:56:28 2007 From: alan at redhat.com (Alan Cox) Date: Sat, 17 Mar 2007 09:56:28 -0400 Subject: User directories integration - request for help In-Reply-To: <1174102387.2653.62.camel@zelda.fubar.dk> References: <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> Message-ID: <20070317135628.GB8832@devserv.devel.redhat.com> On Fri, Mar 16, 2007 at 11:33:07PM -0400, David Zeuthen wrote: > Again: if you have an opinion then participate upstream because that is > where we want to solve a problems if possible. Developers in general are > not happy to repeat the same answers over and over again especially to > people "too busy" to participate in the right forum. I believe the word for that is "Arrogance". Let me rephrase it "Developers are too busy doing what they think is right to listen to anyone who will actually have to use their stuff" Thats also known as "not doing your research" Alan From alan at redhat.com Sat Mar 17 13:59:44 2007 From: alan at redhat.com (Alan Cox) Date: Sat, 17 Mar 2007 09:59:44 -0400 Subject: User directories integration - request for help In-Reply-To: <1174107004.2691.31.camel@zelda.fubar.dk> References: <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <1174103491.4680.227.camel@mccallum.corsepiu.local> <1174105657.2691.24.camel@zelda.fubar.dk> <1174106134.4680.249.camel@mccallum.corsepiu.local> <1174107004.2691.31.camel@zelda.fubar.dk> Message-ID: <20070317135944.GC8832@devserv.devel.redhat.com> On Sat, Mar 17, 2007 at 12:50:04AM -0400, David Zeuthen wrote: > So the developers from the desktop projects and the distros (e.g. the > people who participate on xdg-list) are all wrong and stupid because > they want this feature and you don't? I think we can end this thread... Stick your fingers in your ears again, just like with HAL (which still keeps crashing cdrom drives, draining laptop batteries and stopping people burn CDs) Alan From alan at redhat.com Sat Mar 17 14:05:24 2007 From: alan at redhat.com (Alan Cox) Date: Sat, 17 Mar 2007 10:05:24 -0400 Subject: User directories integration - request for help In-Reply-To: <1174111073.4680.275.camel@mccallum.corsepiu.local> References: <1173953610.10024.132.camel@greebo> <1174107004.2691.31.camel@zelda.fubar.dk> <1174107776.4680.259.camel@mccallum.corsepiu.local> <200703170146.15455.lightsolphoenix@gmail.com> <1174111073.4680.275.camel@mccallum.corsepiu.local> Message-ID: <20070317140524.GD8832@devserv.devel.redhat.com> On Sat, Mar 17, 2007 at 06:57:53AM +0100, Ralf Corsepius wrote: > > Wait, when did the world switch to using English as a universal language? > Since when has "Desktop", "Mail" or "News" been an issue? For a lot of cultures they are. But having 'name of the week' and magic gconf links doens't solve the problem either it makes it worse. Having them set at first login (first not every) when your account gets all the desktop setup works as they then keep stable names. Having the ability in Nastilus to do right-click->Make this the default for->[Downloads|Photos|Music...] lets you do any renaming in a natural discoverable fashion Having them change name between languages (which may vary) is dumb, but the XDG folk are IMHO at least right tht this isn't good enough. A lot of cultures don't even use the same symbols as are found in "Mail" etc let alone the words. From ssorce at redhat.com Sat Mar 17 14:16:53 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 17 Mar 2007 10:16:53 -0400 Subject: User directories integration - request for help In-Reply-To: <200703170146.15455.lightsolphoenix@gmail.com> References: <1173953610.10024.132.camel@greebo> <1174107004.2691.31.camel@zelda.fubar.dk> <1174107776.4680.259.camel@mccallum.corsepiu.local> <200703170146.15455.lightsolphoenix@gmail.com> Message-ID: <1174141013.26640.3.camel@willson> On Sat, 2007-03-17 at 01:46 -0400, Kelly wrote: > Wait, when did the world switch to using English as a universal language? If you do not create directories by default, you don't have to impose any language. > And "bitten by Windows"? How so; Windows does exactly what you're suggesting > here, and in fact I know of cases where people have BROKEN Windows simply > because they wanted things named in a non-English language. You never used a localized version of Windows, right? Simo. From ssorce at redhat.com Sat Mar 17 14:21:14 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 17 Mar 2007 10:21:14 -0400 Subject: User directories integration - request for help In-Reply-To: <20070317140524.GD8832@devserv.devel.redhat.com> References: <1173953610.10024.132.camel@greebo> <1174107004.2691.31.camel@zelda.fubar.dk> <1174107776.4680.259.camel@mccallum.corsepiu.local> <200703170146.15455.lightsolphoenix@gmail.com> <1174111073.4680.275.camel@mccallum.corsepiu.local> <20070317140524.GD8832@devserv.devel.redhat.com> Message-ID: <1174141274.26640.8.camel@willson> On Sat, 2007-03-17 at 10:05 -0400, Alan Cox wrote: > On Sat, Mar 17, 2007 at 06:57:53AM +0100, Ralf Corsepius wrote: > > > Wait, when did the world switch to using English as a universal language? > > Since when has "Desktop", "Mail" or "News" been an issue? > > For a lot of cultures they are. But having 'name of the week' and magic > gconf links doens't solve the problem either it makes it worse. agree > Having them set at first login (first not every) when your account gets > all the desktop setup works as they then keep stable names. Having the > ability in Nastilus to do > > right-click->Make this the default for->[Downloads|Photos|Music...] > > lets you do any renaming in a natural discoverable fashion +1 I want to be able to decide what names these folders have, or if I want them at all (I'd probably choose not to have them, or to put them in a place and in a language of my own) Connecting them to the locale Is very stupid. I use when I install, because I can't stand the way most of the things are translated in Italian, but then I use some Italian names for some of my folders. I would get really really mad if switching english->italian->english I'd found out that some smart utility changed my folder names! > Having them change name between languages (which may vary) is dumb, but > the XDG folk are IMHO at least right tht this isn't good enough. > > A lot of cultures don't even use the same symbols as are found in "Mail" etc > let alone the words. +1 Yet another reason to add eventually emblems and not make some magic association. From ssorce at redhat.com Sat Mar 17 14:33:41 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 17 Mar 2007 10:33:41 -0400 Subject: User directories integration - request for help In-Reply-To: <1174125003.11892.17.camel@rousalka.dyndns.org> References: <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174096185.26640.0.camel@willson> <1174099865.2653.32.camel@zelda.fubar.dk> <20070317091750.GC3550@free.fr> <1174125003.11892.17.camel@rousalka.dyndns.org> Message-ID: <1174142021.26640.15.camel@willson> On Sat, 2007-03-17 at 10:50 +0100, Nicolas Mailhot wrote: > Le samedi 17 mars 2007 ? 10:17 +0100, Patrice Dumas a ?crit : > > > Still not something somebody not specifically interested in desktop > > would like to read. > > Also it's funny the distribution that actually already tried something > like this (mandriva) on production systems used symlinks. > > They are summarily dismissed afterwards because of users mounting a CIFS > home where "the remote host is having a broken/incomplete implementation > of CIFS (usually a Windows system)" (SIC). Way to go, make shell users > miserable because of this corner case (that could be handled with a > config fallback) CIFS never defined symlinks, and Windows never had them up to Vista, and even in Vista they can be created only by admins, because there isn't a single app that uses mkstemp to create temp file, as symlinks races simply does not exist in that world. So there is no much space to say CIFS is broken. However with the UNIX Extensions we put in it will allow you to have everything you want and symlinks when speaking to another CIFS server with UNIX extensions. That said it is silly to think of people using windows shares as home directories, I see the case insensitivity problem much more problematic as our apps are not thought with that in mind, and besides, if an admin, really really really want to do something stupid like that, then he will take care of the consistencies. > > Something I didn't exactly understood is how and when exactly those > > directories are to be created. > > Seems this part is not hammered out yet. I'd love if it was "never > pre-create/auto-create, prompt the user to select a dir/create a new one > whenever we can't find the dir we need" +1 and once created other apps can see them by default Simo. From axel.azerty at laposte.net Sat Mar 17 14:35:08 2007 From: axel.azerty at laposte.net (Axel) Date: Sat, 17 Mar 2007 15:35:08 +0100 Subject: User directories integration - request for help In-Reply-To: <1174111073.4680.275.camel@mccallum.corsepiu.local> References: <1173953610.10024.132.camel@greebo> <1174107004.2691.31.camel@zelda.fubar.dk> <1174107776.4680.259.camel@mccallum.corsepiu.local> <200703170146.15455.lightsolphoenix@gmail.com> <1174111073.4680.275.camel@mccallum.corsepiu.local> Message-ID: <1174142108.5632.7.camel@localhost.localdomain> Le samedi 17 mars 2007 ? 06:57 +0100, Ralf Corsepius a ?crit : > On Sat, 2007-03-17 at 01:46 -0400, Kelly wrote: > > > Since when has "Desktop", "Mail" or "News" been an issue? > > Unix users are used to seeing them for decades - Windows aren't used to > seeing them. > > > And "bitten by Windows"? How so; Windows does exactly what you're suggesting > > here, > > The old copy of Win95 I have, uses i18n'ed > directories, e.g. > ... > Anwendungen > Netzwerkumgebung > ... > > English counterparts: > Programs > Network > > > and in fact I know of cases where people have BROKEN Windows simply > > because they wanted things named in a non-English language. > Exactly - C.f. above - Push this Windows HOME onto a Samba share and > access it from different windows clients using different languages. > > Ralf > > Just my 2 cents about this, I'm just a "lambda" user, and such directories would be a good thing for me. I wonder just : what for is the translation needed ? Just for GUIs I think. If Fedora targets mainly "lambda users", the use of console shouldn't be a focus. I think someone able to use the console, would be able to understand "Documents", "Mails", "Pictures", and so on, even if he (or she) is japanese. So why not don't care about the physical name, and why not just use the same system MacOSX use, i.e. translate only for GUIed applications? Make these directories as default directories like explained by someone (alan cox iirc) for widely used applications would be a good thing, off course for my personnal case. (please excuse my poor english) Axel From david at lovesunix.net Sat Mar 17 14:55:51 2007 From: david at lovesunix.net (David Nielsen) Date: Sat, 17 Mar 2007 15:55:51 +0100 Subject: User directories integration - request for help In-Reply-To: <20070317135628.GB8832@devserv.devel.redhat.com> References: <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <20070317135628.GB8832@devserv.devel.redhat.com> Message-ID: <1174143351.2857.11.camel@dawkins> l?r, 17 03 2007 kl. 09:56 -0400, skrev Alan Cox: > On Fri, Mar 16, 2007 at 11:33:07PM -0400, David Zeuthen wrote: > > Again: if you have an opinion then participate upstream because that is > > where we want to solve a problems if possible. Developers in general are > > not happy to repeat the same answers over and over again especially to > > people "too busy" to participate in the right forum. > > I believe the word for that is "Arrogance". Let me rephrase it > > "Developers are too busy doing what they think is right to listen to anyone > who will actually have to use their stuff" > > Thats also known as "not doing your research" Okay, let me inject, as a user of a i18n enabled desktop, my honest opinion. I hate every English folder name imposed on me, I'd love for everything to be neat and if possible dynamic not to mention translated. I consider it a bug in an application when it hardcodes an English folder name just to be sure it knows where to put stuff (Like f-spot does). I'm not convinced this solution is the best one but it's at least taking, for once, into consideration the fact that there are a shitload of people who don't speak English or do but prefer to use their native language on their desktop. So here's one user, very thankful for developments in this area, it has been talked about for years and Alex had the balls to try a solution. I couldn't care less if it turns out to be a slightly bad one or we decide to replace it at some later stage, at least there's now code so we can test the concept instead if bickering about it. Let's try it out, if there's a Wiki page up somewhere to say how to enable this on an existing account I'll gladly start testing it out. Let's get some real metrics in, have users try this out and see what they think. - 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 rc040203 at freenet.de Sat Mar 17 16:32:12 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 17 Mar 2007 17:32:12 +0100 Subject: User directories integration - request for help In-Reply-To: <1174141013.26640.3.camel@willson> References: <1173953610.10024.132.camel@greebo> <1174107004.2691.31.camel@zelda.fubar.dk> <1174107776.4680.259.camel@mccallum.corsepiu.local> <200703170146.15455.lightsolphoenix@gmail.com> <1174141013.26640.3.camel@willson> Message-ID: <1174149132.4680.291.camel@mccallum.corsepiu.local> On Sat, 2007-03-17 at 10:16 -0400, Simo Sorce wrote: > On Sat, 2007-03-17 at 01:46 -0400, Kelly wrote: > > > Wait, when did the world switch to using English as a universal language? > > If you do not create directories by default, you don't have to impose > any language. How do you portably implement scripts or daemons to work on files in such dirs? > > And "bitten by Windows"? How so; Windows does exactly what you're suggesting > > here, and in fact I know of cases where people have BROKEN Windows simply > > because they wanted things named in a non-English language. > > You never used a localized version of Windows, right? I don't know what you are referring to. The only Windows I have ever used is an ancient "German Win95". The files I had been referring to are more than 10 years old. Ralf From nicolas.mailhot at laposte.net Sat Mar 17 17:16:24 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 17 Mar 2007 18:16:24 +0100 Subject: User directories integration - request for help In-Reply-To: <1174143351.2857.11.camel@dawkins> References: <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <20070317135628.GB8832@devserv.devel.redhat.com> <1174143351.2857.11.camel@dawkins> Message-ID: <1174151784.18279.31.camel@rousalka.dyndns.org> Le samedi 17 mars 2007 ? 15:55 +0100, David Nielsen a ?crit : > Okay, let me inject, as a user of a i18n enabled desktop, my honest > opinion. I hate every English folder name imposed on me, I'd love for > everything to be neat and if possible dynamic not to mention translated. > I consider it a bug in an application when it hardcodes an English > folder name just to be sure it knows where to put stuff (Like f-spot > does). > > I'm not convinced this solution is the best one but it's at least > taking, for once, into consideration the fact that there are a shitload > of people who don't speak English or do but prefer to use their native > language on their desktop. There is one thing worse than not taking i18n in consideration that's botching your i18n implementation. I for one am deeply attached to i18n due to my personal background. And I'd rather wait a few weeks/months for a proper solution that have a semi-broken hack that will be set in stone as soon as a release goes out with it. I don't want a windows-like i18n where my filesystem is polluted with several translations of the same directories because someone made a hasty partial implementation. I don't want the usual experimental Desktop great leap forward followed by years of trying to convince developers that making 70% of users happy and 30% mad is not a success, it's a damn failure. For once I'd like people try to get it right from the start on, not pretend it's an experiment that will be corrected later. The Desktop team does no have a good track record admitting its mistakes, especially once it managed to shove them through people's throats. Now some will say the signal-to-noise ratio on fedora-devel is poor, and hiding on confidential mailing-lists or IRC channels is better. Well if you don't have the time to explain and convince don't pretend participating in a community process. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Sat Mar 17 17:20:04 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 17 Mar 2007 18:20:04 +0100 Subject: User directories integration - request for help In-Reply-To: <1174149132.4680.291.camel@mccallum.corsepiu.local> References: <1173953610.10024.132.camel@greebo> <1174107004.2691.31.camel@zelda.fubar.dk> <1174107776.4680.259.camel@mccallum.corsepiu.local> <200703170146.15455.lightsolphoenix@gmail.com> <1174141013.26640.3.camel@willson> <1174149132.4680.291.camel@mccallum.corsepiu.local> Message-ID: <1174152004.18279.34.camel@rousalka.dyndns.org> Le samedi 17 mars 2007 ? 17:32 +0100, Ralf Corsepius a ?crit : > On Sat, 2007-03-17 at 10:16 -0400, Simo Sorce wrote: > > On Sat, 2007-03-17 at 01:46 -0400, Kelly wrote: > > > > > Wait, when did the world switch to using English as a universal language? > > > > If you do not create directories by default, you don't have to impose > > any language. > > How do you portably implement scripts or daemons to work on files in > such dirs? You make a symlink with a stable name pointing to the user-named custom directory (of course that works on home subdirs only, because home content is personal and supposed to be customizable) -- Nicolas Mailhot From hughsient at gmail.com Sat Mar 17 19:19:38 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 17 Mar 2007 19:19:38 +0000 Subject: User directories integration - request for help In-Reply-To: <20070317135944.GC8832@devserv.devel.redhat.com> References: <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <1174103491.4680.227.camel@mccallum.corsepiu.local> <1174105657.2691.24.camel@zelda.fubar.dk> <1174106134.4680.249.camel@mccallum.corsepiu.local> <1174107004.2691.31.camel@zelda.fubar.dk> <20070317135944.GC8832@devserv.devel.redhat.com> Message-ID: <1174159178.2759.7.camel@localhost.localdomain> On Sat, 2007-03-17 at 09:59 -0400, Alan Cox wrote: > On Sat, Mar 17, 2007 at 12:50:04AM -0400, David Zeuthen wrote: > > So the developers from the desktop projects and the distros (e.g. the > > people who participate on xdg-list) are all wrong and stupid because > > they want this feature and you don't? I think we can end this thread... > > Stick your fingers in your ears again, just like with HAL (which still keeps > crashing cdrom drives, draining laptop batteries and stopping people burn > CDs) Excuse me?! Compare the pre-HAL day with what we have now. Have you got specific bugzillas open for the issues you mention? Thanks. Richard. From alan at redhat.com Sat Mar 17 19:55:44 2007 From: alan at redhat.com (Alan Cox) Date: Sat, 17 Mar 2007 15:55:44 -0400 Subject: User directories integration - request for help In-Reply-To: <1174159178.2759.7.camel@localhost.localdomain> References: <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <1174103491.4680.227.camel@mccallum.corsepiu.local> <1174105657.2691.24.camel@zelda.fubar.dk> <1174106134.4680.249.camel@mccallum.corsepiu.local> <1174107004.2691.31.camel@zelda.fubar.dk> <20070317135944.GC8832@devserv.devel.redhat.com> <1174159178.2759.7.camel@localhost.localdomain> Message-ID: <20070317195544.GA21441@devserv.devel.redhat.com> On Sat, Mar 17, 2007 at 07:19:38PM +0000, Richard Hughes wrote: > Excuse me?! Compare the pre-HAL day with what we have now. Have you got > specific bugzillas open for the issues you mention? I get about 4 messages a week from people with problems. Some are in bugzilla a lot of folks just turn off the polling and never file bugs unfortunately. Some we can precisely characterise - certain Dell CD devices for example the rest are a mix off odd and weird. The longer term good news btw is that there is a spec for proper, disconnected non-polling eject button notification in the hardware, and we'll begin to see it on new devices soon. From baris at teamforce.name.tr Sat Mar 17 20:03:05 2007 From: baris at teamforce.name.tr (Baris Cicek) Date: Sat, 17 Mar 2007 22:03:05 +0200 Subject: User directories integration - request for help In-Reply-To: <1173953610.10024.132.camel@greebo> References: <1173953610.10024.132.camel@greebo> Message-ID: <1174161785.3429.16.camel@localhost.localdomain> I could not find where to post this, so sending over here. I changed Alex's xdg-user-dirs application to make it using symlinks instead of actual directories. Maybe it's something in vain but just wanted to put my solution into a prototype so as to be tested. (Maybe someone like it). Actually using symlinks give better handling of localization than using --force. It does not touch directories, so can be considered theoretically more secure. I've also changed handling of user-dirs.dirs which make it possible to use CUSTOM_DESKTOP_DIR, so that this directories are never touched. Currently user-dirs.dirs is used to store old localized directories, so that left-over symlinks don't exist. Actual files are to be stored in (.desktop, .download, etc.) so they are hidden. If it's necessary, packages can use those directories without worrying about internationalized names. It removes symlinks using unlink, so that it's impossible to delete directories (no risk of losing actual data). Some parts are dirty hack, and I could not follow coding style of the Alex, but I did not want to spend much more time about it, keeping in my mind that this kind of usage is not decided. Anyways, I've attached patch against v0.0.1 of xdg-user-dirs. (I figured out new version exists but was too late :() Hopefully it's enough to show approach this way. I'd be happy to hear about comments on it. And here's the real thing; http://www.gnome.org/~alexl/xdg-user-dirs-0.0.1.tar.gz On Thu, 2007-03-15 at 11:13 +0100, Alexander Larsson wrote: > The basic user directories stuff discussed on fedora-desktop-list has > now landed in rawhide (install the xdg-user-dirs and xdg-user-dirs-gtk > packages to get it). I've created patches to the core desktop packages > that needed it (nautilus, gnome-panel, gnome-user-share) to make it > work. However, to fully make use of this we need to patch a bunch of > applications to take advantage of this new feature. > > The directories availible are: > DESKTOP: the standard desktop dir > DOWNLOAD: default location for downloads > TEMPLATES: used by nautilus for templates > PUBLICSHARE: This is ~/Public as used by gnome-user-share > DOCUMENTS: default location for "documents" > MUSIC: default location for music > PICTURES: default location for pictures > VIDEOS: default location for movies > eog/gthumb/f-spot: PICTURES as default for file selector > > Any other ideas? > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alla at lysator.liu.se > He's a jaded alcoholic romance novelist from the 'hood. She's a radical > antique-collecting nun from Mars. They fight crime! > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -------------- next part -------------- A non-text attachment was scrubbed... Name: symlink.patch.gz Type: application/x-gzip Size: 2727 bytes Desc: not available URL: -------------- next part -------------- # Default settings for user directories # # The values are relative pathnames from the home directory and # will be translated on a per-path-element basis into the users locale DESKTOP=.desktop DOWNLOAD=.download TEMPLATES=.templates PUBLICSHARE=.public DOCUMENTS=.documents MUSIC=.music PHOTOS=.photos # Another alternative is: #MUSIC=Documents/Music #PHOTOS=Documents/Photos -------------- next part -------------- # Default settings for user directories # # The values are relative pathnames from the home directory and # will be translated on a per-path-element basis into the users locale DESKTOP=.desktop DOWNLOAD=.download TEMPLATES=.templates PUBLICSHARE=.public DOCUMENTS=.documents MUSIC=.music PHOTOS=.photos # Another alternative is: #MUSIC=Documents/Music #PHOTOS=Documents/Photos From hughsient at gmail.com Sat Mar 17 20:39:55 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 17 Mar 2007 20:39:55 +0000 Subject: User directories integration - request for help In-Reply-To: <20070317195544.GA21441@devserv.devel.redhat.com> References: <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <1174103491.4680.227.camel@mccallum.corsepiu.local> <1174105657.2691.24.camel@zelda.fubar.dk> <1174106134.4680.249.camel@mccallum.corsepiu.local> <1174107004.2691.31.camel@zelda.fubar.dk> <20070317135944.GC8832@devserv.devel.redhat.com> <1174159178.2759.7.camel@localhost.localdomain> <20070317195544.GA21441@devserv.devel.redhat.com> Message-ID: <1174163995.2834.2.camel@localhost.localdomain> On Sat, 2007-03-17 at 15:55 -0400, Alan Cox wrote: > On Sat, Mar 17, 2007 at 07:19:38PM +0000, Richard Hughes wrote: > > Excuse me?! Compare the pre-HAL day with what we have now. Have you got > > specific bugzillas open for the issues you mention? > > I get about 4 messages a week from people with problems. Some are in bugzilla > a lot of folks just turn off the polling and never file bugs unfortunately. > > Some we can precisely characterise - certain Dell CD devices for example the > rest are a mix off odd and weird. Then surely we should patch HAL to ignore these Dell CD devices? Richard. From tmus at tmus.dk Sat Mar 17 20:55:24 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sat, 17 Mar 2007 21:55:24 +0100 Subject: Fedora extras metadata In-Reply-To: <20070316232624.GA30219@lists.us.dell.com> References: <45F9C515.3060804@zoeloelip.be> <20070315234339.7065f318.mschwendt.tmp0701.nospam@arcor.de> <20070316172417.GB5795@humbolt.us.dell.com> <20070316232624.GA30219@lists.us.dell.com> Message-ID: Matt Domsch wrote: > > First, the problems with the current mirroring is really twofold: > ( ... snip ... ) > 2) the global mirrors aren't being notified when content has > changed on the master, such that they should start a new rsync > run. mirrormanager takes a per-host email address, which the > master sign-and-push scripts will eventually send an email to when > the content changes. As it stands, syncing every 6 hours when > nothing has changed doesn't make any sense. > > Now, mirrormanager has 2 methods by which it can know a give mirror > host is up-to-date. First is a new report_mirrors script that uploads > directory data back to the database from the mirror itself. Not > everyone will want to run that, and there's always the 'trust but > verify' model, so I've also got a (fast?) crawler that crawls each > host using HTTP HEADs and keepalives or FTP DIR calls looking for > content it should be carrying compared to the master list, and > tracking presence and up-to-date-ness on a per-directory level. Those > that aren't up2date get dropped from the appropriate per-directory > lists (e.g. the repodata dirs) in real time. > Sounds good, but it still seems like we need special tools to determine on the fly, with standard tools, if a mirror is in a sync'ed state. If I need to create a local mirror of fedora X with updates, with standard tools, I have to figure out when to mirror by trial and error and have no way to check before the sync, if the mirror is in the middle of syncing itself. The mirrormanager you're working on will be useful for monitoring and flagging stale mirrors. It could work well for yum too, but for the basic mirroring, we still lack a simple mechanism to allow us to track the state of upstream mirrors. Mirroring a few gigs of inconsistent data makes no sense at all and this can be implemented very very easily. It's all a matter of documenting "HOWTO setup a fedora mirror". > That's the idea. A lot of the code is implemented, there's more to > go. If you're good with python, turbogears, and the like, I'm sure I > could put you to work on it. Drop me a note. > Never worked with turbogears, sorry ;-) /Thomas From david at fubar.dk Sat Mar 17 17:12:04 2007 From: david at fubar.dk (David Zeuthen) Date: Sat, 17 Mar 2007 13:12:04 -0400 Subject: User directories integration - request for help In-Reply-To: <20070317195544.GA21441@devserv.devel.redhat.com> References: <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <1174103491.4680.227.camel@mccallum.corsepiu.local> <1174105657.2691.24.camel@zelda.fubar.dk> <1174106134.4680.249.camel@mccallum.corsepiu.local> <1174107004.2691.31.camel@zelda.fubar.dk> <20070317135944.GC8832@devserv.devel.redhat.com> <1174159178.2759.7.camel@localhost.localdomain> <20070317195544.GA21441@devserv.devel.redhat.com> Message-ID: <1174151524.2784.8.camel@zelda.fubar.dk> On Sat, 2007-03-17 at 15:55 -0400, Alan Cox wrote: > The longer term good news btw is that there is a spec for proper, disconnected > non-polling eject button notification in the hardware, and we'll begin to see > it on new devices soon. One useful bug for adding such information would be this https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204969 since it already raises some discussion on the kernel/user interface for things like async notification for media change events. David From mclasen at redhat.com Sun Mar 18 02:36:24 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Sat, 17 Mar 2007 22:36:24 -0400 Subject: User directories integration - request for help In-Reply-To: <1174151524.2784.8.camel@zelda.fubar.dk> References: <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <1174103491.4680.227.camel@mccallum.corsepiu.local> <1174105657.2691.24.camel@zelda.fubar.dk> <1174106134.4680.249.camel@mccallum.corsepiu.local> <1174107004.2691.31.camel@zelda.fubar.dk> <20070317135944.GC8832@devserv.devel.redhat.com> <1174159178.2759.7.camel@localhost.localdomain> <20070317195544.GA21441@devserv.devel.redhat.com> <1174151524.2784.8.camel@zelda.fubar.dk> Message-ID: <1174185384.3455.4.camel@localhost.localdomain> fedora-devel has done its magic and managed to make this thread too long for any meaningful response in just a few days, but let me just ask this one question here: How many of the people who go ballistic here about stupid gui developers with fingers in their ears trying to imitate win95 have actually tried Alex' implementation ? From louisg00 at bellsouth.net Sun Mar 18 01:10:24 2007 From: louisg00 at bellsouth.net (Louis E Garcia II) Date: Sat, 17 Mar 2007 21:10:24 -0400 Subject: kernel config question Message-ID: <1174180224.30317.3.camel@sonlaptop> Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits still need this? Is work being done to eliminate the need for this? -Louis From oliver at linux-kernel.at Sun Mar 18 07:55:47 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Sun, 18 Mar 2007 08:55:47 +0100 Subject: kernel config question In-Reply-To: <1174180224.30317.3.camel@sonlaptop> References: <1174180224.30317.3.camel@sonlaptop> Message-ID: <45FCF083.8090108@linux-kernel.at> Louis E Garcia II schrieb: > Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits > still need this? Is work being done to eliminate the need for this? > > -Louis > You could also ask x86 core maintainers. They also do set it in config-generic. :-) I guess no pkg in core/extras needs it, but maybe RH folks have it included for the wild? Who knows what proggies people out there want to run on their machines.... :-) Best, Oliver PS: [oliver at pils ~/cvs/Fedora/core/devel/kernel/configs]$ grep CONFIG_SYSFS_DEPRECATED *config* config-generic:CONFIG_SYSFS_DEPRECATED=y From buildsys at redhat.com Sun Mar 18 10:01:32 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sun, 18 Mar 2007 06:01:32 -0400 Subject: rawhide report: 20070318 changes Message-ID: <200703181001.l2IA1Wew004162@hs20-bc2-6.build.redhat.com> Updated Packages: gcc-4.1.2-5 ----------- * Sat Mar 17 2007 Jakub Jelinek 4.1.2-5 - update from gcc-4_1-branch (-r122833:123011) - PRs debug/29906, middle-end/30364, middle-end/30433, target/31123 - rebuilt against newer rpm to fix libgcj debuginfo (#232222) 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 fedora at leemhuis.info Sun Mar 18 10:40:41 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 18 Mar 2007 11:40:41 +0100 Subject: kernel config question In-Reply-To: <45FCF083.8090108@linux-kernel.at> References: <1174180224.30317.3.camel@sonlaptop> <45FCF083.8090108@linux-kernel.at> Message-ID: <45FD1729.6090108@leemhuis.info> Oliver Falk schrieb: > Louis E Garcia II schrieb: >> Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits >> still need this? Is work being done to eliminate the need for this? > You could also ask x86 core maintainers. [...] Or the changelog: $ rpm -q kernel-2.6.20-1.2990.fc7 --changelog | grep -i -A 1 -B 1 DEPRECATED * Fr Jan 26 2007 Bill Nottingham - turn on CONFIG_SYSFS_DEPRECATED so that things actually work. *sigh* Not that this information in this case actually helps what things didn't work without it. ;-) CU thl From nicolas.mailhot at laposte.net Sun Mar 18 10:44:35 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 18 Mar 2007 11:44:35 +0100 Subject: kernel config question In-Reply-To: <1174180224.30317.3.camel@sonlaptop> References: <1174180224.30317.3.camel@sonlaptop> Message-ID: <1174214675.19932.4.camel@rousalka.dyndns.org> Le samedi 17 mars 2007 ? 21:10 -0400, Louis E Garcia II a ?crit : > Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits > still need this? Is work being done to eliminate the need for this? Run a kernel without this option, test, report problems IMHO if we wanted we could target F7 without this. So far I've only found lm_sensors broken because of class changes, and upstream promised me a fixed version last week (running with a local patch I tested for them now) -- Nicolas Mailhot From bernie at develer.com Sun Mar 18 11:11:27 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Sun, 18 Mar 2007 12:11:27 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <20070316115828.GD24022@neu.nirvana> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> <20070316115828.GD24022@neu.nirvana> Message-ID: <45FD1E5F.6040407@develer.com> Axel Thimm wrote: >> If I understood it correctly, every locate search would read the files on the >> remote volumes, right? The performance will suffer a bit I think. For example, >> NFS over 11mbit wifi is fine, but waiting tens of seconds for the database to >> download isn't good. Probably a global locate cache db that merges all the >> fs-local ones would be nice. > > Perhaps the remote .mlocatedbs could be cached based on size and timestamp? Linux NFS always has had very poor performance wrt local filesystems, but adding another layer of complexity in updatedb to overcome the limitations of NFS over slow links is inappropriate. The NFSv4 spec allows very aggressive client-side caching. Recent kernels with cachefs may even use local files for backing store. This general solution should speedup most usage patterns without the need to add specialized caches to all applications. -- // Bernardo Innocenti - Develer R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Sun Mar 18 11:18:28 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Sun, 18 Mar 2007 12:18:28 +0100 Subject: [RFC] Filesystem-local databases in mlocate In-Reply-To: <45FA1A1A.9060201@volny.cz> References: <45FA1A1A.9060201@volny.cz> Message-ID: <45FD2004.4040003@develer.com> Miloslav Trmac wrote: > Can anyone see a problem with the plan, or an important feature that the > above fails to address? I love your proposal, but I'm concerned with littering the roots of all mountpoints with .mlocate and possibily 10 other dot files from other applications. I hope that you and the authors of other system services with similar requirements could get together and come up with a standard place for these files named .volume/, .info/, .db/ or something similar. Subsystems that may want to use it include full-text search engines, quota, etc. Great care must be taken to make all this metadata interoperable between different architectures, operating systems and software versions. Maybe the LSB would care to publish a standard within the next 10 years? -- // Bernardo Innocenti - Develer R&D dept. \X/ http://www.develer.com/ From Axel.Thimm at ATrpms.net Sun Mar 18 11:19:37 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 18 Mar 2007 12:19:37 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <45FD1E5F.6040407@develer.com> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> <20070316115828.GD24022@neu.nirvana> <45FD1E5F.6040407@develer.com> Message-ID: <20070318111937.GB18524@neu.nirvana> On Sun, Mar 18, 2007 at 12:11:27PM +0100, Bernardo Innocenti wrote: > Axel Thimm wrote: > > >> If I understood it correctly, every locate search would read the files on the > >> remote volumes, right? The performance will suffer a bit I think. For example, > >> NFS over 11mbit wifi is fine, but waiting tens of seconds for the database to > >> download isn't good. Probably a global locate cache db that merges all the > >> fs-local ones would be nice. > > > > Perhaps the remote .mlocatedbs could be cached based on size and timestamp? > > Linux NFS always has had very poor performance wrt local filesystems, but > adding another layer of complexity in updatedb to overcome the limitations > of NFS over slow links is inappropriate. > > The NFSv4 spec allows very aggressive client-side caching. Recent kernels > with cachefs may even use local files for backing store. This general > solution should speedup most usage patterns without the need to add > specialized caches to all applications. We're certainly not there yet to disallow connecting to NFS3 servers (or anything but NFSv4). -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Sun Mar 18 11:27:27 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 18 Mar 2007 12:27:27 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <20070318111937.GB18524@neu.nirvana> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> <20070316115828.GD24022@neu.nirvana> <45FD1E5F.6040407@develer.com> <20070318111937.GB18524@neu.nirvana> Message-ID: <1174217247.19932.21.camel@rousalka.dyndns.org> Le dimanche 18 mars 2007 ? 12:19 +0100, Axel Thimm a ?crit : > We're certainly not there yet to disallow connecting to NFS3 servers > (or anything but NFSv4). However for the proposition to work the new mlocate must exist server (to create the files) and client-side (to read them). Is it reasonable to expect both ends to switch to a not-even-yet-released mlocate but not be able to do nfsv4 ? -- Nicolas Mailhot From nicolas.mailhot at laposte.net Sun Mar 18 11:28:49 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 18 Mar 2007 12:28:49 +0100 Subject: [RFC] Filesystem-local databases in mlocate In-Reply-To: <45FD2004.4040003@develer.com> References: <45FA1A1A.9060201@volny.cz> <45FD2004.4040003@develer.com> Message-ID: <1174217329.19932.24.camel@rousalka.dyndns.org> Le dimanche 18 mars 2007 ? 12:18 +0100, Bernardo Innocenti a ?crit : Hi Bernardo, You're rephrasing my opinion much better than I stated it originally > Maybe the LSB would care to publish a standard within the next > 10 years? Replace LSB with FHS, if we want something quick -- Nicolas Mailhot From bernie at develer.com Sun Mar 18 11:45:17 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Sun, 18 Mar 2007 12:45:17 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <20070318111937.GB18524@neu.nirvana> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> <20070316115828.GD24022@neu.nirvana> <45FD1E5F.6040407@develer.com> <20070318111937.GB18524@neu.nirvana> Message-ID: <45FD264D.4030502@develer.com> Axel Thimm wrote: >> The NFSv4 spec allows very aggressive client-side caching. Recent kernels >> with cachefs may even use local files for backing store. This general >> solution should speedup most usage patterns without the need to add >> specialized caches to all applications. > > We're certainly not there yet to disallow connecting to NFS3 servers > (or anything but NFSv4). NFSv3 still works, but will do less caching. Actually, I'm not sure whether NFSv3 can do efficient read-only caching or not. Maybe yes. And btw, I can't find cachefs anywhere in recent 2.6.20 kernels. Does anyone know where it's gone? -- // Bernardo Innocenti - Develer R&D dept. \X/ http://www.develer.com/ From Axel.Thimm at ATrpms.net Sun Mar 18 11:55:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 18 Mar 2007 12:55:13 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <1174217247.19932.21.camel@rousalka.dyndns.org> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> <20070316115828.GD24022@neu.nirvana> <45FD1E5F.6040407@develer.com> <20070318111937.GB18524@neu.nirvana> <1174217247.19932.21.camel@rousalka.dyndns.org> Message-ID: <20070318115513.GC18524@neu.nirvana> On Sun, Mar 18, 2007 at 12:27:27PM +0100, Nicolas Mailhot wrote: > Le dimanche 18 mars 2007 ? 12:19 +0100, Axel Thimm a ?crit : > > > We're certainly not there yet to disallow connecting to NFS3 servers > > (or anything but NFSv4). > > However for the proposition to work the new mlocate must exist server > (to create the files) and client-side (to read them). Is it reasonable > to expect both ends to switch to a not-even-yet-released mlocate but not > be able to do nfsv4 ? With mlocate you will not really have a choice when it the changes are applied, while with NFS it's an admin's choice to use NFS3 or NFSv4, and 3 still has the larger share and will probably do so long after mlocate introduces these changes. And NFS is not the only remote filesystem, nor the only filesystem in general where this will be applied. Other prominent fs that will benefit from this setup are GFS and openafs. So we need not only a solution that works with NFSv4, but NFS3 and other filesystems as well. Therefore we can't rely on NFSv4 specifica. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at fedoraproject.org Sun Mar 18 12:31:58 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 18 Mar 2007 08:31:58 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-18 Message-ID: <20070318123158.6203C152130@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 19 R-2.4.1-4.fc7 Zim-0.18-1.fc7 aumix-2.8-13.fc7 NEW giggle-0.1-3.fc7 gimmie-0.2.5-1.fc7 gnome-schedule-1.1.0-2.fc7 grip-3.2.0-16.fc7 gweled-0.7-8.fc7 hatari-0.90-6.fc7 jd-1.8.8-0.2.cvs070318.fc7 kronolith-2.1.5-1.fc7 libnetfilter_conntrack-0.0.50-2.fc7 ngspice-17-11.fc7 notecase-1.4.5-1.fc7 qucs-0.0.11-1.fc7 scribes-0.3.1-1.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.2997.fc7 xca-0.6.0-1.fc7 xmlrpc-c-1.06.11-1.fc7 Packages built and released for Fedora Extras 6: 16 R-2.4.1-4.fc6 Zim-0.18-1.fc6 aumix-2.8-13.fc6 buildbot-0.7.5-1.fc6 NEW giggle-0.1-3.fc6 gimmie-0.2.5-1.fc6 grip-3.2.0-16.fc6 gweled-0.7-8.fc6 hatari-0.90-6.fc6 imp-4.1.4-1.fc6 jd-1.8.8-0.2.beta070317.fc6.1 ngspice-17-11.fc6 notecase-1.4.5-1.fc6 qucs-0.0.11-1.fc6 scribes-0.3.1-1.fc6 xmlrpc-c-1.06.11-1.fc6 Packages built and released for Fedora Extras 5: 10 R-2.4.1-4.fc5 Zim-0.18-1.fc5 aumix-2.8-13.fc5 grip-3.2.0-16.fc5 hatari-0.90-6.fc5 imp-4.1.4-1.fc5 jd-1.8.8-0.2.beta070317.fc5.1 ngspice-17-11.fc5 qucs-0.0.11-1.fc5 xmlrpc-c-1.06.11-1.fc5 aumix-2.8-13.fc7 ---------------- * Sat Mar 17 2007 Gabriel L. Somlo 2.8-13 - bumped rel. to 13, to be ahead of latest core (unreleased) cvs giggle-0.1-3.fc7 ---------------- * Sat Mar 17 2007 James Bowes - 0.1-3 - Minor specfile fixes from the initial review. * Fri Mar 09 2007 James Bowes - 0.1-2 - Use desktop-file-install for the desktop file. * Wed Mar 07 2007 James Bowes - 0.1-1 - Initial packaging. gimmie-0.2.5-1.fc7 ------------------ * Sat Mar 17 2007 Deji Akingunola - 0.2.5-1 - New release * Thu Mar 01 2007 Deji Akingunola - 0.2.4-1 - New release gnome-schedule-1.1.0-2.fc7 -------------------------- * Sat Mar 17 2007 Frank Arnold 1.1.0-2 - Added BuildRequires gnome-python2-devel gnome-python2-gconf * Sat Mar 17 2007 Frank Arnold 1.1.0-1 - Updated to 1.1.0 - Fix for help display problems (GNOME 419213) - Fix for help build problems (GNOME 409311) grip-3.2.0-16.fc7 ----------------- * Wed Jan 17 2007 Adrian Reber - 1:3.2.0-16 - fixes for #220777, #222574, #232755 gweled-0.7-8.fc7 ---------------- * Sat Mar 17 2007 Thorsten Leemhuis - 0.7-8 - create gweled.timed.scores manually, fixes 232184 hatari-0.90-6.fc7 ----------------- * Sat Mar 17 2007 Andrea Musuruane 0.90-6.fc7 - dropped --add-category X-Fedora from desktop-file-install - changed .desktop category to Game;Emulator; - now using sed to fix makefile not to strip binaries during make install - cosmetic changes to BR section jd-1.8.8-0.2.cvs070318.fc7 -------------------------- * Sun Mar 18 2007 Mamoru Tasaka - 1.8.8-0.2.cvs070318 - cvs 070318 (12:25 JST) kronolith-2.1.5-1.fc7 --------------------- * Sat Mar 17 2007 Brandon Holbrook 2.1.5-1 - Upgraded to upstream 2.1.5 libnetfilter_conntrack-0.0.50-2.fc7 ----------------------------------- * Sat Mar 17 2007 Paul P. Komkoff Jr - 0.0.50-2 - new way of handling rpaths (as in current packaging guidelines) ngspice-17-11.fc7 ----------------- * Sat Mar 17 2007 Chitlesh Goorah 17-11 - droped patch: ngspice-bjt.patch, upstream will provide a better patch soon * Sat Mar 17 2007 Chitlesh Goorah 17-10 - fixed bug #227519 in spec file - Ville Skytt? - patch: ngspice-bjt.patch fixes the problem with bjt devices that have less than five nodes notecase-1.4.5-1.fc7 -------------------- * Sat Mar 17 2007 Damien Durand 1.4.5-1 - Upgrade to 1.4.5 - Fix desktop file qucs-0.0.11-1.fc7 ----------------- * Sun Mar 18 2007 Eric Tanguy - 0.0.11-1 - Update to 0.0.11 R-2.4.1-4.fc7 ------------- * Tue Mar 13 2007 Tom "spot" Callaway 2.4.1-4 - get rid of termcap related requires, replace with ncurses - use java-1.5.0-gcj instead of old java-1.4.2 - add /usr/share/R/library as a valid R_LIBS directory for noarch bits scribes-0.3.1-1.fc7 ------------------- * Sat Mar 17 2007 Peter Gordon - 0.3.1-1 - Update to new upstream release (0.3.1). - Update Source0 URL - Drop pygobject2 as a run-time dependency (since it's pulled in by pygtk2). - Drop the fix-plugins-installation-dir patch (this bug was fixed upstream): - fix-plugins-installation-dir.patch - Don't mark installed GConf schemas file as %config. sysprof-kmod-1.0.8-1.2.6.20_1.2997.fc7 -------------------------------------- xca-0.6.0-1.fc7 --------------- * Sat Mar 17 2007 Enrico Scholz - 0.6.0-1 - updated to 0.6.0 - removed old patches xmlrpc-c-1.06.11-1.fc7 ---------------------- * Sat Mar 17 2007 Enrico Scholz - 1.06.11-1 - updated to 1.06.11 Zim-0.18-1.fc7 -------------- * Sat Mar 17 2007 Chris Weyl 0.18-1 - update to 0.18 - fix homepage/download links - drop dep on shared-mime-info as bz#215972 has been resolved For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From bernie at develer.com Sun Mar 18 13:26:37 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Sun, 18 Mar 2007 14:26:37 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <1174217247.19932.21.camel@rousalka.dyndns.org> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> <20070316115828.GD24022@neu.nirvana> <45FD1E5F.6040407@develer.com> <20070318111937.GB18524@neu.nirvana> <1174217247.19932.21.camel@rousalka.dyndns.org> Message-ID: <45FD3E0D.6060904@develer.com> Nicolas Mailhot wrote: > However for the proposition to work the new mlocate must exist server > (to create the files) and client-side (to read them). Is it reasonable > to expect both ends to switch to a not-even-yet-released mlocate but not > be able to do nfsv4 ? Not in Fedora, but people running mlocate on propretary systems such Win32 and MacOSX will have a hard time trying to get NFSv4 support from their vendors ;-) -- // Bernardo Innocenti - Develer R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Sun Mar 18 13:38:59 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Sun, 18 Mar 2007 14:38:59 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <20070318115513.GC18524@neu.nirvana> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> <20070316115828.GD24022@neu.nirvana> <45FD1E5F.6040407@develer.com> <20070318111937.GB18524@neu.nirvana> <1174217247.19932.21.camel@rousalka.dyndns.org> <20070318115513.GC18524@neu.nirvana> Message-ID: <45FD40F3.3060003@develer.com> Axel Thimm wrote: > With mlocate you will not really have a choice when it the changes are > applied, while with NFS it's an admin's choice to use NFS3 or NFSv4, > and 3 still has the larger share and will probably do so long after > mlocate introduces these changes. Both of which always have done a better job than NFSv3 with client-side caching. Even Samba is much better. As far as I can tell, NFSv4 is just catching up. And as of today I still find many trivial workloads for which NFSv4 still performs poorly. Try "time find /nfs_share >/dev/null" versus the same command on a local filesystem to see what I mean. > And NFS is not the only remote filesystem, nor the only filesystem in > general where this will be applied. Other prominent fs that will > benefit from this setup are GFS and openafs. Why would GFS be any slower than a non-clustered filesystem when it comes to raw data read performance? The DLM overhead would supposedly not get in the way of every single block being read. GFS is usually accessed through the same bus types of ordinary filesystems, including SAS, fiber-channel and even SATA. Even gigabit ethernet, which would be a very uncommon transport for block-level storage, would be fast enough for the bandwidth of today's ordinary hard drives. -- // Bernardo Innocenti - Develer R&D dept. \X/ http://www.develer.com/ From Axel.Thimm at ATrpms.net Sun Mar 18 14:12:30 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 18 Mar 2007 15:12:30 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <45FD40F3.3060003@develer.com> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> <20070316115828.GD24022@neu.nirvana> <45FD1E5F.6040407@develer.com> <20070318111937.GB18524@neu.nirvana> <1174217247.19932.21.camel@rousalka.dyndns.org> <20070318115513.GC18524@neu.nirvana> <45FD40F3.3060003@develer.com> Message-ID: <20070318141230.GH24404@neu.nirvana> On Sun, Mar 18, 2007 at 02:38:59PM +0100, Bernardo Innocenti wrote: > Axel Thimm wrote: > > > With mlocate you will not really have a choice when it the changes are > > applied, while with NFS it's an admin's choice to use NFS3 or NFSv4, > > and 3 still has the larger share and will probably do so long after > > mlocate introduces these changes. > > Both of which always have done a better job than NFSv3 with client-side > caching. Even Samba is much better. > > As far as I can tell, NFSv4 is just catching up. And as of today I still > find many trivial workloads for which NFSv4 still performs poorly. Try > "time find /nfs_share >/dev/null" versus the same command on a local > filesystem to see what I mean. Well, aren't you just arguing against your original proposal to move everything to NFSv4 and rely on the caching done by NFSv4? ;) > > And NFS is not the only remote filesystem, nor the only filesystem in > > general where this will be applied. Other prominent fs that will > > benefit from this setup are GFS and openafs. > > Why would GFS be any slower than a non-clustered filesystem when it > comes to raw data read performance? The DLM overhead would supposedly > not get in the way of every single block being read. You should try and time GFS. When it drops the domain locks, no caching survives. > GFS is usually accessed through the same bus types of ordinary > filesystems, including SAS, fiber-channel and even SATA. And network block devices. > Even gigabit ethernet, which would be a very uncommon transport for > block-level storage, would be fast enough for the bandwidth of > today's ordinary hard drives. You are trying to solve an easy-to-solve caching problem by requiring o usage of NFSv4 o high bandwidth of drives o gigabit ethernet o and more while the original poster mentioned he needs this for his wireless connection of his laptop ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bernie at develer.com Sun Mar 18 14:27:57 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Sun, 18 Mar 2007 15:27:57 +0100 Subject: speed of yum depsolver (use Smart to fix) In-Reply-To: <20070315203711.GA7264@jadzia.bu.edu> References: <45F483C9.5000008@fedoraproject.org> <45F554C7.3060302@gmail.com> <20070312161310.GA27101@redhat.com> <1173716340.20424.31.camel@cutter> <20070312163921.GA30150@jadzia.bu.edu> <20070315203711.GA7264@jadzia.bu.edu> Message-ID: <45FD4C6D.4040006@develer.com> Matthew Miller wrote: > I know it's kind of sad to laugh at my own joke, but I've been running with > this plugin all week, and I can attest that it actually *has* significantly > improved my Rawhide user experience. I think maybe I'll extend it to provide > a variety of similar helpful tips at random. I'm sorry if I'm stating the obvious, but switching to smart for my distro upgrading stuff fixed the yum depsolver problem for me ultimately. I had been looking at smart with interest for several months, but so far I've been avoiding it for regular updates because it's so "unofficial". And guess what? Despite being beta, unofficial and unsupported, I've seen Smart doing exactly the right thing in a number of complex situations where yum had failed. And it's much faster, and has three very usable and feature-complete user interfaces too (gui, shell and cli). I've also tried Smart on SuSE and it's much, much better than the native tools even for the yast repository formats. Never had the chance to test Smart on Ubuntu or other DEB/APT distros, but at this point I'm willing to bet on it working perfectly. So: even if all things were equal, switching to smart means that you need to learn one less custom tool when you need to use different Linux distibutions. -- // Bernardo Innocenti - Develer R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Sun Mar 18 14:52:14 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Sun, 18 Mar 2007 15:52:14 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <20070318141230.GH24404@neu.nirvana> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> <20070316115828.GD24022@neu.nirvana> <45FD1E5F.6040407@develer.com> <20070318111937.GB18524@neu.nirvana> <1174217247.19932.21.camel@rousalka.dyndns.org> <20070318115513.GC18524@neu.nirvana> <45FD40F3.3060003@develer.com> <20070318141230.GH24404@neu.nirvana> Message-ID: <45FD521E.6040705@develer.com> Axel Thimm wrote: >> As far as I can tell, NFSv4 is just catching up. And as of today I still >> find many trivial workloads for which NFSv4 still performs poorly. Try >> "time find /nfs_share >/dev/null" versus the same command on a local >> filesystem to see what I mean. > > Well, aren't you just arguing against your original proposal to move > everything to NFSv4 and rely on the caching done by NFSv4? ;) :-) Telling the truth shall outweigh one's desire of being always right. Well, the NFSv4 performance problem I was talking about affects stat()-ing many files. Filesystem metadata is not being cached as efficiently as one would expect and client requests are not being clustered together as much as possibile. *But* the contents of a single largish file such as mlocate.db should be cached on the clients. At least, that's what I'm experiencing with NFSv4 in my LAN. To measure NFSv4 read() performance, I must create a file on the server, read it on the server to make sure it's in buffer-cache (otherwise I'd be measruing the performance of the RAID array too), then go on the client and cat the file to /dev/null. To repeat the test, I must remove the test file from the server and create a new one from scratch, otherwise the client would have cached it all and get much better results. >> Why would GFS be any slower than a non-clustered filesystem when it >> comes to raw data read performance? The DLM overhead would supposedly >> not get in the way of every single block being read. > > You should try and time GFS. When it drops the domain locks, no > caching survives. Are you talking about GFS2? I've never had a chance to try it. It's been a while since I used GFS, and it was GFS1 on RHAS3 or maybe 4. At that time, GFS performance was poor wrt ext3 even when the storage was locally attached to a single server. But what it did was so useful for an HA cluster that you would excuse it for not being also fast. > You are trying to solve an easy-to-solve caching problem by requiring > > o usage of NFSv4 > o high bandwidth of drives > o gigabit ethernet > o and more Ouch... But these conditions were just ORed together! The reason I try to drive away from the caching solution is that most caches are more fragile and complex than their designers initially thought. Most break in the face of the user who's not even aware of them (because caches are designed to be transparent). > while the original poster mentioned he needs this for his wireless > connection of his laptop ... Then he's only got NFSv4 left... -- // Bernardo Innocenti - Develer R&D dept. \X/ http://www.develer.com/ From tjanouse at redhat.com Sun Mar 18 15:22:39 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Sun, 18 Mar 2007 16:22:39 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <20070318141230.GH24404@neu.nirvana> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> <20070316115828.GD24022@neu.nirvana> <45FD1E5F.6040407@develer.com> <20070318111937.GB18524@neu.nirvana> <1174217247.19932.21.camel@rousalka.dyndns.org> <20070318115513.GC18524@neu.nirvana> <45FD40F3.3060003@develer.com> <20070318141230.GH24404@neu.nirvana> Message-ID: <20070318152239.GA17706@redhat.com> Hi, On Sun, Mar 18, 2007 at 03:12:30PM +0100, Axel Thimm wrote: > while the original poster mentioned he needs this for his wireless > connection of his laptop ... Well the original poster had something like NFS over the globe in mind, but mentioned wifi because 1) it's more common and 2) nobody would say I'm crazy. :] -- TJ., BaseOS, Brno, CZ From oliver at linux-kernel.at Sun Mar 18 15:30:17 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Sun, 18 Mar 2007 16:30:17 +0100 Subject: kernel config question In-Reply-To: <45FD1729.6090108@leemhuis.info> References: <1174180224.30317.3.camel@sonlaptop> <45FCF083.8090108@linux-kernel.at> <45FD1729.6090108@leemhuis.info> Message-ID: <45FD5B09.6020302@linux-kernel.at> Thorsten Leemhuis schrieb: > Oliver Falk schrieb: > >> Louis E Garcia II schrieb: >> >>> Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits >>> still need this? Is work being done to eliminate the need for this? >>> >> You could also ask x86 core maintainers. [...] >> > > Or the changelog: > Good point. Should have grep-ed in spec also :-) -of From dwmw2 at infradead.org Sun Mar 18 15:40:36 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 18 Mar 2007 15:40:36 +0000 Subject: kernel config question In-Reply-To: <1174180224.30317.3.camel@sonlaptop> References: <1174180224.30317.3.camel@sonlaptop> Message-ID: <1174232436.3461.619.camel@pmac.infradead.org> On Sat, 2007-03-17 at 21:10 -0400, Louis E Garcia II wrote: > Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits > still need this? Is work being done to eliminate the need for this? Hopefully. It's causing oopses. We should ideally have bugs filed for anything in userspace which needs it. -- dwmw2 From fedora.lists at burns.me.uk Sun Mar 18 16:34:58 2007 From: fedora.lists at burns.me.uk (Andy Burns) Date: Sun, 18 Mar 2007 16:34:58 +0000 Subject: 50% speed penalty for LVM on mdraid Message-ID: I have an F7/rawhide machine with 6x400GB SATA II disks all partitioned as 100MB + 399.9GB /boot is on /dev/sda1 (would be RAID1 across /dev/sd[abc]1 partitions except for mkinitrd raid1.ko breakage) with /dev/md1 as RAID5 on /dev/sd[abcdef]2 Then a single LVM vg00 on top of /dev/md1 root and swap as LVs within vg00 and plenty of spare space. Doing some timings of the various block devices (so far just roughly with hdparm, bonnie installed for more detail later). Results of "hdparm -Tt" averaged over a few runs, showing cached and buffered speeds /dev/sda1 gives 1995MB/s and 72MB/s which seems quite good for a single spindle /dev/md1 gives 2040MB/s and 260MB/s also fairly good (I had hoped with six spindles and parity to get closer to 5x performance than 3.5x) /dev/mapper/vg00-lv01 (my root fs) gives 2100MB/s and 135MB/s which is a little disappointing Nearly a 50% speed penalty seems a heavy price to pay for LVM, is there any slow debug code currently in rawhide that might explain it? Could I have some bad choices of block sizes between RAID/LVM layers which are reducing throughput by splitting reads? Anything else? From sundaram at fedoraproject.org Sun Mar 18 16:40:09 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 18 Mar 2007 22:10:09 +0530 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files In-Reply-To: References: <20070313093842.GA21675@localhost> <45F729FE.1080508@olen.net> Message-ID: <45FD6B69.3050902@fedoraproject.org> Aurelien Bompard wrote: > Darn, wrong link. It's : > http://gauret.free.fr/fichiers/rpms/fedora/yum-merge-conf/yum-merge-conf-1.1-1.noarch.rpm > for the fixed version. Is there any quick way to test this plugin? Rahul From david at lovesunix.net Sun Mar 18 17:31:47 2007 From: david at lovesunix.net (David Nielsen) Date: Sun, 18 Mar 2007 18:31:47 +0100 Subject: 50% speed penalty for LVM on mdraid In-Reply-To: References: Message-ID: <1174239107.2814.24.camel@dawkins> s?n, 18 03 2007 kl. 16:34 +0000, skrev Andy Burns: > I have an F7/rawhide machine with 6x400GB SATA II disks all > partitioned as 100MB + 399.9GB > > /boot is on /dev/sda1 (would be RAID1 across /dev/sd[abc]1 partitions > except for mkinitrd raid1.ko breakage) with /dev/md1 as RAID5 on > /dev/sd[abcdef]2 > > Then a single LVM vg00 on top of /dev/md1 > > root and swap as LVs within vg00 and plenty of spare space. > > Doing some timings of the various block devices (so far just roughly > with hdparm, bonnie installed for more detail later). Results of > "hdparm -Tt" averaged over a few runs, showing cached and buffered > speeds > > /dev/sda1 gives 1995MB/s and 72MB/s which seems quite good for a single spindle > /dev/md1 gives 2040MB/s and 260MB/s also fairly good (I had hoped with > six spindles and parity to get closer to 5x performance than 3.5x) > /dev/mapper/vg00-lv01 (my root fs) gives 2100MB/s and 135MB/s which is > a little disappointing > > Nearly a 50% speed penalty seems a heavy price to pay for LVM, is > there any slow debug code currently in rawhide that might explain it? > Could I have some bad choices of block sizes between RAID/LVM layers > which are reducing throughput by splitting reads? Anything else? Wow that explains a lot.. performance on Development has be awful for me lately and I have been unable to figure out why, this might be related. My setup is 2 400GB drives in RAID0 using dmraid with LVM ontop. - 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 Axel.Thimm at ATrpms.net Sun Mar 18 17:33:12 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 18 Mar 2007 18:33:12 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <45FD521E.6040705@develer.com> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> <20070316115828.GD24022@neu.nirvana> <45FD1E5F.6040407@develer.com> <20070318111937.GB18524@neu.nirvana> <1174217247.19932.21.camel@rousalka.dyndns.org> <20070318115513.GC18524@neu.nirvana> <45FD40F3.3060003@develer.com> <20070318141230.GH24404@neu.nirvana> <45FD521E.6040705@develer.com> Message-ID: <20070318173312.GD31755@neu.nirvana> On Sun, Mar 18, 2007 at 03:52:14PM +0100, Bernardo Innocenti wrote: > Axel Thimm wrote: > >> And as of today I still find many trivial workloads for which > >> NFSv4 still performs poorly. > > > > Well, aren't you just arguing against your original proposal to move > > everything to NFSv4 and rely on the caching done by NFSv4? ;) > > :-) Telling the truth shall outweigh one's desire of being always > right. OK, but ... > >> Why would GFS be any slower than a non-clustered filesystem when it > >> comes to raw data read performance? The DLM overhead would supposedly > >> not get in the way of every single block being read. > It's been a while since I used GFS, and it was GFS1 on RHAS3 or > maybe 4. At that time, GFS performance was poor wrt ext3 even when > the storage was locally attached to a single server. But what it > did was so useful for an HA cluster that you would excuse it for > not being also fast. ... aren't you doing it again? On one post you assume GFS being as fast as any local fs, only to admit that it isn't. Anyway, seems at the end we do agree ;) > > You are trying to solve an easy-to-solve caching problem by requiring > > > > o usage of NFSv4 > > o high bandwidth of drives > > o gigabit ethernet > > o and more > > Ouch... But these conditions were just ORed together! Even so, what does the poor fellow with a laptop and NFS3 do? Which is a very common setup? > The reason I try to drive away from the caching solution is that > most caches are more fragile and complex than their designers > initially thought. Most break in the face of the user who's not > even aware of them (because caches are designed to be transparent). In this case the caching is rather trivial, since it is just a copy operation and checking sizes & mtime. It can be made _perfect_ by adding a checksum at the beginning or end of the db. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From d.jacobfeuerborn at conversis.de Sun Mar 18 17:43:37 2007 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sun, 18 Mar 2007 18:43:37 +0100 Subject: No shape and sync extensions in xorg? Message-ID: <45FD7A49.3000900@conversis.de> Hi, When I try to enable the desktop effects (ie. compiz) I get the following output: [dennis at nexus ~]$ desktop-effects compiz: No sync extension The program 'gnome-window-decorator' received an X Window System error. This probably reflects a bug in the program. The error was 'BadMatch (invalid parameter attributes)'. (Details: serial 426 error_code 8 request_code 72 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Xlib: extension "SHAPE" missing on display ":0.0". Xlib: extension "SHAPE" missing on display ":0.0". Xlib: extension "SHAPE" missing on display ":0.0". Xlib: extension "SHAPE" missing on display ":0.0". Xlib: extension "SHAPE" missing on display ":0.0". Xlib: extension "SHAPE" missing on display ":0.0". Xlib: extension "SHAPE" missing on display ":0.0". Xlib: extension "SHAPE" missing on display ":0.0". Xlib: extension "SHAPE" missing on display ":0.0". Xlib: extension "SHAPE" missing on display ":0.0". Xlib: extension "SHAPE" missing on display ":0.0". Xlib: extension "SHAPE" missing on display ":0.0". Xlib: extension "SHAPE" missing on display ":0.0". Xlib: extension "SHAPE" missing on display ":0.0". [dennis at nexus ~]$ Xlib: extension "SHAPE" missing on display ":0.0". Xlib: extension "SHAPE" missing on display ":0.0". I checked the extensions directory, the xorg log and the xdpyinfo output but I can't find those extensions mentioned anywhere. The window corners in metacity aren't rounded either. Is this a known problem or should I file a bug? Regards, Dennis From fedora.lists at burns.me.uk Sun Mar 18 17:59:19 2007 From: fedora.lists at burns.me.uk (Andy Burns) Date: Sun, 18 Mar 2007 17:59:19 +0000 Subject: 50% speed penalty for LVM on mdraid In-Reply-To: <1174239107.2814.24.camel@dawkins> References: <1174239107.2814.24.camel@dawkins> Message-ID: > Wow that explains a lot.. performance on Development has be awful for me > lately and I have been unable to figure out why, this might be related. > > My setup is 2 400GB drives in RAID0 using dmraid with LVM ontop. It's a while since it tried dmraid instead of mdraid, does it use a UUID as the PV name for /dev/mapper? I suppose pvdisplay would show, then you could try hdparm on the PV under LVM compared to the LV above it. From david at lovesunix.net Sun Mar 18 18:39:22 2007 From: david at lovesunix.net (David Nielsen) Date: Sun, 18 Mar 2007 19:39:22 +0100 Subject: 50% speed penalty for LVM on mdraid In-Reply-To: References: <1174239107.2814.24.camel@dawkins> Message-ID: <1174243162.2814.33.camel@dawkins> s?n, 18 03 2007 kl. 17:59 +0000, skrev Andy Burns: > > Wow that explains a lot.. performance on Development has be awful for me > > lately and I have been unable to figure out why, this might be related. > > > > My setup is 2 400GB drives in RAID0 using dmraid with LVM ontop. > > It's a while since it tried dmraid instead of mdraid, does it use a > UUID as the PV name for /dev/mapper? I suppose pvdisplay would show, > then you could try hdparm on the PV under LVM compared to the LV above > it. /dev/mapper/VolGroup00-LogVol00: Timing cached reads: 1050 MB in 2.00 seconds = 524.68 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device Timing buffered disk reads: 162 MB in 3.01 seconds = 53.84 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device /dev/mapper/nvidia_bbgdbcgj: Timing cached reads: 1142 MB in 2.00 seconds = 571.12 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device Timing buffered disk reads: 300 MB in 3.00 seconds = 99.97 MB/sec HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device /dev/sda: Timing cached reads: 1096 MB in 2.00 seconds = 547.65 MB/sec Timing buffered disk reads: 182 MB in 3.00 seconds = 60.61 MB/sec Yep something odd is definitely going on. -- "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 fedora at camperquake.de Sun Mar 18 18:44:23 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 18 Mar 2007 19:44:23 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <45FD521E.6040705@develer.com> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> <20070316115828.GD24022@neu.nirvana> <45FD1E5F.6040407@develer.com> <20070318111937.GB18524@neu.nirvana> <1174217247.19932.21.camel@rousalka.dyndns.org> <20070318115513.GC18524@neu.nirvana> <45FD40F3.3060003@develer.com> <20070318141230.GH24404@neu.nirvana> <45FD521E.6040705@develer.com> Message-ID: <45FD8887.20001@camperquake.de> Hi. Bernardo Innocenti schrieb: > To repeat the test, I must remove the test file from the server > and create a new one from scratch, otherwise the client would have > cached it all and get much better results. Newer kernels make this a bit easier for you: http://linux-mm.org/Drop_Caches From jcm at redhat.com Sun Mar 18 18:47:32 2007 From: jcm at redhat.com (Jon Masters) Date: Sun, 18 Mar 2007 14:47:32 -0400 Subject: 50% speed penalty for LVM on mdraid In-Reply-To: <1174243162.2814.33.camel@dawkins> References: <1174239107.2814.24.camel@dawkins> <1174243162.2814.33.camel@dawkins> Message-ID: <45FD8944.2020803@redhat.com> David Nielsen wrote: > Yep something odd is definitely going on. I forwarded a couple of mails from this thread to one of the LVM developers...maybe he'll have something to add on this. Jon. From fedora.lists at burns.me.uk Sun Mar 18 18:58:38 2007 From: fedora.lists at burns.me.uk (Andy Burns) Date: Sun, 18 Mar 2007 18:58:38 +0000 Subject: 50% speed penalty for LVM on mdraid In-Reply-To: <1174243162.2814.33.camel@dawkins> References: <1174239107.2814.24.camel@dawkins> <1174243162.2814.33.camel@dawkins> Message-ID: On 18/03/07, David Nielsen wrote: > > Yep something odd is definitely going on. ok, bz'ed https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232843 From peter at thecodergeek.com Sun Mar 18 19:22:23 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 18 Mar 2007 12:22:23 -0700 Subject: No shape and sync extensions in xorg? In-Reply-To: <45FD7A49.3000900@conversis.de> References: <45FD7A49.3000900@conversis.de> Message-ID: <1174245743.5715.10.camel@tuxhugs> On Sun, 2007-03-18 at 18:43 +0100, Dennis Jacobfeuerborn wrote: > [dennis at nexus ~]$ desktop-effects > compiz: No sync extension > [dennis at nexus ~]$ Xlib: extension "SHAPE" missing on display ":0.0". > Xlib: extension "SHAPE" missing on display ":0.0". > What video card and driver combination are you using? -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 bernie at develer.com Sun Mar 18 20:40:08 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Sun, 18 Mar 2007 21:40:08 +0100 Subject: [RFC] Filesystem-local databases in mlocate In-Reply-To: <1174217329.19932.24.camel@rousalka.dyndns.org> References: <45FA1A1A.9060201@volny.cz> <45FD2004.4040003@develer.com> <1174217329.19932.24.camel@rousalka.dyndns.org> Message-ID: <45FDA3A8.4010401@develer.com> Nicolas Mailhot wrote: > You're rephrasing my opinion much better than I stated it originally Thanks :) >> Maybe the LSB would care to publish a standard within the next >> 10 years? > > Replace LSB with FHS, if we want something quick I've looked at their web site, but the FHS spec has not been updated since early 2004, and their mailing-list archives look like a spam dumpyard. These two clues make me suppose the FHS standardization body may have retired or maybe just moved elsewhere. -- // Bernardo Innocenti - Develer R&D dept. \X/ http://www.develer.com/ From bernie at develer.com Sun Mar 18 21:17:46 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Sun, 18 Mar 2007 22:17:46 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <20070318152239.GA17706@redhat.com> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> <20070316115828.GD24022@neu.nirvana> <45FD1E5F.6040407@develer.com> <20070318111937.GB18524@neu.nirvana> <1174217247.19932.21.camel@rousalka.dyndns.org> <20070318115513.GC18524@neu.nirvana> <45FD40F3.3060003@develer.com> <20070318141230.GH24404@neu.nirvana> <20070318152239.GA17706@redhat.com> Message-ID: <45FDAC7A.2010700@develer.com> Tomas Janousek wrote: > Well the original poster had something like NFS over the globe in mind, but > mentioned wifi because 1) it's more common and 2) nobody would say I'm crazy. Back when the web was still a new idea, wuarchive.wustl.edu used to run a public NFS share to access its huge Amiga software collection. Mounting that over an analog modem link and saying: "Finally, I can get rid of the ftp client"... *that* would be crazy! -- // Bernardo Innocenti - Develer R&D dept. \X/ http://www.develer.com/ From michel.salim at gmail.com Sun Mar 18 22:00:31 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 18 Mar 2007 18:00:31 -0400 Subject: Pre-release kernel versioning? Message-ID: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> Hi, Currently each Rawhide pre-release kernel reports as its version number the version number of the previous stable version, rather than the current version. This sometimes causes problems with out-of-kernel modules (e.g. with madwifi), since the exposed kernel API has changed and the #ifdef's normally checks for the new version. Since the typical end-user on a stable Fedora release will never see these pre-release kernels, what would be the downside of, say, calling the current kernel 2.6.21-0.2997.fc7 rather than 2.6.20-1.2997.fc7 ? Thanks, -- Michel Salim http://hircus.wordpress.com/ From kwizart at gmail.com Sun Mar 18 22:13:05 2007 From: kwizart at gmail.com (KH KH) Date: Sun, 18 Mar 2007 23:13:05 +0100 Subject: Pre-release kernel versioning? In-Reply-To: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> References: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> Message-ID: 2007/3/18, Michel Salim : > Hi, > > Currently each Rawhide pre-release kernel reports as its version > number the version number of the previous stable version, rather than > the current version. > > This sometimes causes problems with out-of-kernel modules (e.g. with > madwifi), since the exposed kernel API has changed and the #ifdef's > normally checks for the new version. > > Since the typical end-user on a stable Fedora release will never see > these pre-release kernels, what would be the downside of, say, calling > the current kernel 2.6.21-0.2997.fc7 rather than 2.6.20-1.2997.fc7 ? > > Thanks, > > -- > Michel Salim > http://hircus.wordpress.com/ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Well, i have the same problem some time ago with rt2x00 Ralink chipsets (when it was not inside the kernel, mean since 2.6.21rc1 ) I try to build some kmod (review was here : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202528 - This is planned to be closed when 2.6.21 will be stable...) It was working fine with each 2.6.19 release but not for 2.6.20-1.2925.fc6 See here: http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?p=20463#20463 There is a problem with the rfkill part...I din't dig more for now... I'm surprised that another driver have the same issue, i've thought this was happenning only with rt2x00. Developpers of this module don't support fedora build error for this reason... Nicolas (kwizart) From sundaram at fedoraproject.org Sun Mar 18 22:14:55 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 03:44:55 +0530 Subject: KDE-Live-CD: basic cd layout and localizations In-Reply-To: <20070314011000.5b0cbcb8@localhost.localdomain> References: <20070314011000.5b0cbcb8@localhost.localdomain> Message-ID: <45FDB9DF.2000809@fedoraproject.org> Sebastian Vahl wrote: > Hi. > > I've created a new basic layout for the cd: > http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/KDELiveCD > The size on todays rawhide is about 667 MB. > Please tell me which package should be added or removed. > > > On todays KDE-SIG-Meeting Rex Dieter and Kevin Kofler suggested to give > the local communities the ability to create their own localized cds > easily. To do this there should be an extra configuration file for each > language which adds the needed packages and do some configurations. And > also the additional language must fit on one cd. > A second option for localized versions could (or should?) be a > live-dvd with all available language packages. livecd-creator in git > seems to be able to do this (but I haven't checked this yet). [1] > > I've created a first draft for an configuration for the german language. > This adds kde-i18n-de and koffice-langpack-de to the cd. Also the > standard keyboard layout, the local timezone and the locale is changed. > To change the keyboard layout inside kde I've used an ugly > workaround.[2] > If anybody knows a better way, please tell me. :) > Compared to the version above this one needs ~675 MB. > > > To create the configuration files for different languages I need some > informations from one person that uses the language: > 1. /etc/sysconfig/i18n > 2. /etc/sysconfig/keyboard > 3. /etc/sysconfig/clock > 4. keybordtype from "system-config-keyboard --help" > 5. needed additional packages (eg. scim-* or fonts-*) > > > And of course all are invited to discuss this. :) > > Sebastian > > > > > [1] http://git.fedoraproject.org/?p=hosted/livecd > [2] > http://www.deadbabylon.de/fedora/livecd/source/50-fedora-livecd-kde-german.conf > > ######### > > How to create the live cd: > > Install livecd-tools: > > wget > "http://people.redhat.com/~katzj/live/f7test2/livecd-tools-001-3.fc7.i386.rpm" > rpm -ivh livecd-tools-001-3.fc7.i386.rpm > > Create the spin: > > livecd-creator \ > --repo=c7,http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/RPMS/ > \ > --repo=e7,http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ > \ > --repo=lcd7,http://www.deadbabylon.de/fedora/livecd/i386/ \ > --package=fedora-livecd-kde \ > --fslabel=Fedora-7-Test2-KDE This results in the error: Cannot open/read repomd.xml file for repositry:lcdr_c7 Error installing packages Error during installation Rahul From michel.salim at gmail.com Sun Mar 18 22:33:13 2007 From: michel.salim at gmail.com (Michel Salim) Date: Sun, 18 Mar 2007 18:33:13 -0400 Subject: Pre-release kernel versioning? In-Reply-To: References: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> Message-ID: <883cfe6d0703181533v58ec8b33r73abbf9241d5976e@mail.gmail.com> 2007/3/18, KH KH : > Well, i have the same problem some time ago with rt2x00 Ralink chipsets > (when it was not inside the kernel, mean since 2.6.21rc1 ) > I try to build some kmod > (review was here : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202528 - This is > planned to be closed when 2.6.21 will be stable...) > It was working fine with each 2.6.19 release but not for 2.6.20-1.2925.fc6 > See here: http://rt2x00.serialmonkey.com/phpBB2/viewtopic.php?p=20463#20463 > There is a problem with the rfkill part...I din't dig more for now... > I'm surprised that another driver have the same issue, i've thought > this was happenning only with rt2x00. Developpers of this module don't > support fedora build error for this reason... > Generally the fix is quite trivial: if the kernel module supports several different kernels, find the place where it probes what kernel it's being built against and change references to the upstream kernel version (in this case 2.6.21) to 2.6.20, which is what your kernel is reporting. It's just a bit annoying to have to do it each time, since I'd have to delete the modified file everytime it's modified upstream, get the newer version and then re-modify it. Regards, -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From ml at deadbabylon.de Sun Mar 18 22:59:25 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sun, 18 Mar 2007 23:59:25 +0100 Subject: KDE-Live-CD: basic cd layout and localizations In-Reply-To: <45FDB9DF.2000809@fedoraproject.org> References: <20070314011000.5b0cbcb8@localhost.localdomain> <45FDB9DF.2000809@fedoraproject.org> Message-ID: <200703182359.32762.ml@deadbabylon.de> > > > > How to create the live cd: > > > > Install livecd-tools: > > > > wget > > "http://people.redhat.com/~katzj/live/f7test2/livecd-tools-001-3.fc7.i386 > >.rpm" rpm -ivh livecd-tools-001-3.fc7.i386.rpm > > > > Create the spin: > > > > livecd-creator \ > > --repo=c7,http://download.fedora.redhat.com/pub/fedora/linux/core/develop > >ment/i386/os/Fedora/RPMS/ \ > > --repo=e7,http://download.fedora.redhat.com/pub/fedora/linux/extras/devel > >opment/i386/ \ > > --repo=lcd7,http://www.deadbabylon.de/fedora/livecd/i386/ \ > > --package=fedora-livecd-kde \ > > --fslabel=Fedora-7-Test2-KDE > > This results in the error: > > Cannot open/read repomd.xml file for repositry:lcdr_c7 > Error installing packages > Error during installation > > Rahul My mistake. Wrong url for [development]. Please use: livecd-creator \ --repo=c7,http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/ \ --repo=e7,http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ \ --repo=lcd7,http://www.deadbabylon.de/fedora/livecd/i386/ \ --package=fedora-livecd-kde \ --fslabel=Fedora-7-Test2-KDE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Sun Mar 18 23:02:27 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 04:32:27 +0530 Subject: KDE-Live-CD: basic cd layout and localizations In-Reply-To: <200703182359.32762.ml@deadbabylon.de> References: <20070314011000.5b0cbcb8@localhost.localdomain> <45FDB9DF.2000809@fedoraproject.org> <200703182359.32762.ml@deadbabylon.de> Message-ID: <45FDC503.3000508@fedoraproject.org> Sebastian Vahl wrote: > My mistake. Wrong url for [development]. Please use: > > livecd-creator \ > --repo=c7,http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/ > \ > --repo=e7,http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ > \ > --repo=lcd7,http://www.deadbabylon.de/fedora/livecd/i386/ \ > --package=fedora-livecd-kde \ > --fslabel=Fedora-7-Test2-KDE Got it already since I watch all the wiki edits. I am rerunning with this set of arguments. Report back later. It would be useful if you can put in a sample output (it is reassuring to know that the output you are getting is expected) and explicitly mention that you need to be running as root user and how long it would take on specific system configurations. Rahul From d.jacobfeuerborn at conversis.de Sun Mar 18 23:16:25 2007 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Mon, 19 Mar 2007 00:16:25 +0100 Subject: No shape and sync extensions in xorg? In-Reply-To: <1174245743.5715.10.camel@tuxhugs> References: <45FD7A49.3000900@conversis.de> <1174245743.5715.10.camel@tuxhugs> Message-ID: <45FDC849.5090203@conversis.de> Peter Gordon wrote: > On Sun, 2007-03-18 at 18:43 +0100, Dennis Jacobfeuerborn wrote: >> [dennis at nexus ~]$ desktop-effects >> compiz: No sync extension >> [dennis at nexus ~]$ Xlib: extension "SHAPE" missing on display ":0.0". >> Xlib: extension "SHAPE" missing on display ":0.0". >> > > What video card and driver combination are you using? > I'm using the "nv" driver and the card (well, it's on-board) is identified as "nVidia Corporation GeForce 6100 nForce 430". Xorg says "Chipset Unknown NVIDIA chip found" in the log but except for some graphical glitches it seems to work ok. Cursors don't get drawn correctly and sometimes parts of the terminal text output appear a bit bolder then regular text (though not bold as in "bold font", just a tiny bit bolder as if the anti-aliasing is a bit off or there is some sort of pixel/rounding error). Regards, Dennis From dcbw at redhat.com Sun Mar 18 23:27:09 2007 From: dcbw at redhat.com (Dan Williams) Date: Sun, 18 Mar 2007 19:27:09 -0400 Subject: kernel config question In-Reply-To: <1174232436.3461.619.camel@pmac.infradead.org> References: <1174180224.30317.3.camel@sonlaptop> <1174232436.3461.619.camel@pmac.infradead.org> Message-ID: <1174260429.8053.12.camel@localhost.localdomain> On Sun, 2007-03-18 at 15:40 +0000, David Woodhouse wrote: > On Sat, 2007-03-17 at 21:10 -0400, Louis E Garcia II wrote: > > Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits > > still need this? Is work being done to eliminate the need for this? > > Hopefully. It's causing oopses. We should ideally have bugs filed for > anything in userspace which needs it. See the message on lkml and linux-wireless with the subject: Recent wireless breakage (ipw2200, iwconfig, NetworkManager) It actually has nothing to do with NetworkManager, but the problem is that gregkh's patch broke HAL in ways that only an as-then unreleased version of HAL could cope with (and possibly other stuff). Root cause was that the patch gregkh landed was faulty. See his mail with this subject and the date of "Tue, 6 Mar 2007 12:05:37 -0800 (15:05 EST)". The patch removed the 'device' link from /sys/class/net/XXX/ directories, which means you simply cannot match up the class device with the hardware it actually is, which is wrong & bad. Dan ----- Can you try the patch below? And enable CONFIG_SYSFS_DEPRECATED. It should cause HAL to see the network devices again, as the symlink is now back (it shouldn't have gone away, that was my fault...) I tried this with HAL 0.5.7, which is pretty old, and hal-device-manager shows my network devices properly. thanks for your patience, greg k-h ----- From ml at deadbabylon.de Sun Mar 18 23:37:59 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Mon, 19 Mar 2007 00:37:59 +0100 Subject: KDE-Live-CD: basic cd layout and localizations In-Reply-To: <45FDC503.3000508@fedoraproject.org> References: <20070314011000.5b0cbcb8@localhost.localdomain> <200703182359.32762.ml@deadbabylon.de> <45FDC503.3000508@fedoraproject.org> Message-ID: <200703190038.05132.ml@deadbabylon.de> Am Montag, 19. M?rz 2007 schrieb Rahul Sundaram: > Sebastian Vahl wrote: > > My mistake. Wrong url for [development]. Please use: > > > > livecd-creator \ > > --repo=c7,http://download.fedora.redhat.com/pub/fedora/linux/core/develop > >ment/i386/os/ \ > > --repo=e7,http://download.fedora.redhat.com/pub/fedora/linux/extras/devel > >opment/i386/ \ > > --repo=lcd7,http://www.deadbabylon.de/fedora/livecd/i386/ \ > > --package=fedora-livecd-kde \ > > --fslabel=Fedora-7-Test2-KDE > > Got it already since I watch all the wiki edits. I am rerunning with > this set of arguments. Report back later. It would be useful if you can > put in a sample output (it is reassuring to know that the output you are > getting is expected) and explicitly mention that you need to be running > as root user and how long it would take on specific system configurations. > > Rahul OK. Will do this tomorrow. For now: On my machine (Athlon XP 2400+, 1GB Ram) it takes 30-45 min for one run (normal load). And the expected result is that livecd-creator creates an iso. ;) Normally it fails on errors (except eg. non-signed packages). Some minor note: I have to stick to udev-105 to get a bootable iso. With udev-106 I get the same problem like many people with F7T1 and F7T2 (again) [1]. Already reported this to fedora-livecd-list but nobody answered yet. So this is probably a local problem. Sebastian [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227734 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jsacco at gnome.org Mon Mar 19 02:14:17 2007 From: jsacco at gnome.org (Joseph Sacco) Date: Sun, 18 Mar 2007 22:14:17 -0400 Subject: Problem setting up IP MASQUERADE with recent kernels In-Reply-To: <1174075315.3270.2.camel@rt.jesacco.com> References: <1174075315.3270.2.camel@rt.jesacco.com> Message-ID: <1174270457.3261.5.camel@rt.jesacco.com> Hoisted by my own petard... Using the TUN driver supplied with the kernel rather than building one within MOL, avoids the problem. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231606 -Joseph ==================================================================== On Fri, 2007-03-16 at 16:01 -0400, Joseph Sacco wrote: > Problem > ------- > > With recent 2.6.21.x kernels IP-Masquerading, required by > Mac-On-Linux, has stopped working as expected. > > > Question > -------- > > Has anyone successfully set up IP Masquerading using a recent > kernel? > > > > Discussion > ---------- > Mac-On-Linux > > http://sourceforge.net/projects/mac-on-linux/ > > is a Linux/PPC program that virtualizes MacOS or MacOSX in Linux. MOL > uses an IP tunnel to eastabish communications between the Linux host and > the virtualized MAC operating system. > > -Ethernet---------------------------------------- > | | > 130.237.226.234 | 130.237.226.239 > eth0 | other_machine > linux > tun1 | > 192.168.41.1 | > | virtual > +--- ip-tunnel ------- MOL > 192.168.41.2 > > > The Linux host performs network address translation to enable MOL to > communicate with the external network. > > The mechanisms used by Mac-On-Linux to set up the IP tunnel and set up > NAT have worked successfully with 2.4.x and 2.6.x series kernels until > recently. Mac-on-Linux networking works correctly when run on FC6. It > has also run on fedora/rawhide with earlier 2.6.20.x kernels. > > Two thoughts come to mind: > > * a kernel module has gone missing ==> kernel configuration > problem > > * "something has changed" with how IP-Masquerading is setup / > works. > > I have examined the kernel configuration file for IPV4 netfiltering and > have not found any obvious omissions. [That does not mean that there are > no omissions of required modules. It just means I did not spot them.] > The only "suspect" is CONN_NF_CONNTRACK_PROC_COMPAT. > > What appears to be happening with the latest kernels is some necessary > kernel modules are not being loaded initially. > > Consider the output from 'lsmod' from two successive attempts of > starting Mac-On-Linux: > > > Attempt #1 > ---------- > Mac-On-Linux comes up. Networking is borked. > > [output from ldmod] > > Module Size Used by > nf_nat 20660 0 > nf_conntrack_ipv4 13448 1 > nf_conntrack 73408 2 nf_nat,nf_conntrack_ipv4 > nfnetlink 8344 3 nf_nat,nf_conntrack_ipv4,nf_conntrack > ip_tables 14900 0 > x_tables 18404 1 ip_tables > tun 13728 1 > mol 59304 1 > > Conspicuously absent from this list are > > * iptable_nat > * ipt_MASQUERADE > > > Running 'dmesg' may provide a hint: > > [output from dmesg] > > MOL 0.9.73-SVN kernel module loaded > PM: Adding info for No Bus:mol > tun: Universal TUN/TAP device driver, 1.6 > tun: (C) 1999-2004 Max Krasnyansky > PM: Adding info for No Bus:tun > PM: Adding info for No Bus:tun1 > > Hmmmm... "can't setup rules." There it is again. Wonder what's going on. > > > > Thoughts??? > > > -Joseph > > > -- > jsacco [at] gnome [dot] org -- jsacco [at] gnome [dot] org From tspauld98 at yahoo.com Mon Mar 19 02:57:22 2007 From: tspauld98 at yahoo.com (Timothy Spaulding) Date: Sun, 18 Mar 2007 19:57:22 -0700 (PDT) Subject: Where Do I Debug Issues With An App Packaged By Fedora? Message-ID: <664892.48829.qm@web60524.mail.yahoo.com> I'm an engineer and a user of Fedora. I've used Fedora at work for years now. Recently, I've run into some problems using Evolution with our corporate exchange server. Figuring this was my chance to get involved with the community, I started digging into the Fedora and Gnome projects trying to figure out how to proceed. The big question I have is: Which project should I start with? Fedora packages Evolution, but as I understand it, doesn't really add anything to its development other than bug reports and some fixes. Would it be more appropriate to start by installing the development versions of Evolution from Gnome? Should I start by installing from rawhide? How do you make a decision about where to start debugging? Also, I'd love to hear anyone's strategies with debugging a specific application on Fedora without disrupting the rest of the machine. Thanks, tims ____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ From sundaram at fedoraproject.org Mon Mar 19 03:17:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 08:47:11 +0530 Subject: KDE-Live-CD: basic cd layout and localizations In-Reply-To: <200703190038.05132.ml@deadbabylon.de> References: <20070314011000.5b0cbcb8@localhost.localdomain> <200703182359.32762.ml@deadbabylon.de> <45FDC503.3000508@fedoraproject.org> <200703190038.05132.ml@deadbabylon.de> Message-ID: <45FE00B7.5000603@fedoraproject.org> Sebastian Vahl wrote: > Am Montag, 19. M?rz 2007 schrieb Rahul Sundaram: >> Sebastian Vahl wrote: >>> My mistake. Wrong url for [development]. Please use: >>> >>> livecd-creator \ >>> --repo=c7,http://download.fedora.redhat.com/pub/fedora/linux/core/develop >>> ment/i386/os/ \ >>> --repo=e7,http://download.fedora.redhat.com/pub/fedora/linux/extras/devel >>> opment/i386/ \ >>> --repo=lcd7,http://www.deadbabylon.de/fedora/livecd/i386/ \ >>> --package=fedora-livecd-kde \ >>> --fslabel=Fedora-7-Test2-KDE >> Got it already since I watch all the wiki edits. I am rerunning with >> this set of arguments. Report back later. It would be useful if you can >> put in a sample output (it is reassuring to know that the output you are >> getting is expected) and explicitly mention that you need to be running >> as root user and how long it would take on specific system configurations. >> >> Rahul > > OK. Will do this tomorrow. For now: On my machine (Athlon XP 2400+, 1GB Ram) > it takes 30-45 min for one run (normal load). And the expected result is that > livecd-creator creates an iso. ;) Normally it fails on errors (except eg. > non-signed packages). > Some minor note: I have to stick to udev-105 to get a bootable iso. With > udev-106 I get the same problem like many people with F7T1 and F7T2 (again) > [1]. Already reported this to fedora-livecd-list but nobody answered yet. So > this is probably a local problem. > > Sebastian > > > [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227734 It produced a 650 MB KDE ISO image. Booting it on qemu fails with the same error message as described in the above bug report. I am not sure which udev it downloaded. Are the packages downloaded saved anywhere? Rahul From louisg00 at bellsouth.net Mon Mar 19 05:33:06 2007 From: louisg00 at bellsouth.net (Louis E Garcia II) Date: Mon, 19 Mar 2007 01:33:06 -0400 Subject: kernel config question In-Reply-To: <1174180224.30317.3.camel@sonlaptop> References: <1174180224.30317.3.camel@sonlaptop> Message-ID: <1174282386.4236.4.camel@sonlaptop> > > > Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits > > > still need this? Is work being done to eliminate the need for this? > > > > Hopefully. It's causing oopses. We should ideally have bugs filed for > > anything in userspace which needs it. > > See the message on lkml and linux-wireless with the subject: > > Recent wireless breakage (ipw2200, iwconfig, NetworkManager) > > It actually has nothing to do with NetworkManager, but the problem is > that gregkh's patch broke HAL in ways that only an as-then unreleased > version of HAL could cope with (and possibly other stuff). > > Root cause was that the patch gregkh landed was faulty. See his mail > with this subject and the date of "Tue, 6 Mar 2007 12:05:37 -0800 > (15:05 EST)". The patch removed the 'device' link > from /sys/class/net/XXX/ directories, which means you simply cannot > match up the class device with the hardware it actually is, which is > wrong & bad. > > Dan So this might be fixed in 2.6.21? Might be fun to unset this for one fedora kernel release to see what happens. Bill? Dave? -Louis From ssorce at redhat.com Mon Mar 19 06:10:41 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 19 Mar 2007 02:10:41 -0400 Subject: [RFC] Filesystem-local databases in mlocate In-Reply-To: <45FA1A1A.9060201@volny.cz> References: <45FA1A1A.9060201@volny.cz> Message-ID: <1174284641.16983.8.camel@willson> On Fri, 2007-03-16 at 05:16 +0100, Miloslav Trmac wrote: > Hi, > I'm planning to add filesystem-local database support to mlocate. This > allows: > - running updatedb on a file server and making the database > automatically available to clients without any client-side > configuration > - using locate on GFS volumes without running updatedb on each host that > has the volume mounted (which slows the volumes down due to lock > contention) [...] > Usage for /home on NFS: > - NFS is automatically excluded by clients, so updatedb on clients > does not walk the filesystem. > - On the server: > Add /srv/home to /etc/sysconfig/mlocate. If /srv/home is not a > separate mount point, add LOCATE_PATH=:/srv/home/.mlocate/mlocate.db > to the global environment. I am deeply concerned about the security implications of this idea. You are basically making it possible for everyone to get access to the complete remote FS layout ??? > Can anyone see a problem with the plan, or an important feature that the > above fails to address? Yes, security and privacy wise it is BAD BAAD BAAAD :-) Simo. From dwmw2 at infradead.org Mon Mar 19 07:19:38 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 19 Mar 2007 07:19:38 +0000 Subject: Pre-release kernel versioning? In-Reply-To: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> References: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> Message-ID: <1174288778.3392.55.camel@pmac.infradead.org> On Sun, 2007-03-18 at 18:00 -0400, Michel Salim wrote: > Currently each Rawhide pre-release kernel reports as its version > number the version number of the previous stable version, rather than > the current version. > > This sometimes causes problems with out-of-kernel modules I stopped caring here. Either way, you're shipping something which is neither 2.6.20 nor 2.6.21, and in fact isn't even a point between them; we have patches of our own. Neither version is 'correct'. -- dwmw2 From david at lovesunix.net Mon Mar 19 07:40:08 2007 From: david at lovesunix.net (David Nielsen) Date: Mon, 19 Mar 2007 08:40:08 +0100 Subject: Where Do I Debug Issues With An App Packaged By Fedora? In-Reply-To: <664892.48829.qm@web60524.mail.yahoo.com> References: <664892.48829.qm@web60524.mail.yahoo.com> Message-ID: <1174290008.2772.14.camel@dawkins> s?n, 18 03 2007 kl. 19:57 -0700, skrev Timothy Spaulding: > I'm an engineer and a user of Fedora. I've used Fedora at work for years now. Recently, I've run > into some problems using Evolution with our corporate exchange server. Figuring this was my > chance to get involved with the community, I started digging into the Fedora and Gnome projects > trying to figure out how to proceed. The big question I have is: Which project should I start > with? > > Fedora packages Evolution, but as I understand it, doesn't really add anything to its development > other than bug reports and some fixes. Would it be more appropriate to start by installing the > development versions of Evolution from Gnome? Should I start by installing from rawhide? > > How do you make a decision about where to start debugging? Also, I'd love to hear anyone's > strategies with debugging a specific application on Fedora without disrupting the rest of the > machine. The traditional road would be installing the -debuginfo packages for evolution and all it's dependencies, then use gdb to gain a bit of insight into what's going on. It would be nice if you could expand on the issue you are seeing, it's likely there's already a bug filed on the issue which might give you additional information on where to start digging. Upstream for evolution is Novell, the very latest code is available via the GNOME SVN repo at svn.gnome.org. - 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: This is a digitally signed message part URL: From fedora at leemhuis.info Mon Mar 19 07:50:12 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Mar 2007 08:50:12 +0100 Subject: Pre-release kernel versioning? In-Reply-To: <1174288778.3392.55.camel@pmac.infradead.org> References: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> <1174288778.3392.55.camel@pmac.infradead.org> Message-ID: <45FE40B4.4070607@leemhuis.info> On 19.03.2007 08:19, David Woodhouse wrote: > On Sun, 2007-03-18 at 18:00 -0400, Michel Salim wrote: >> Currently each Rawhide pre-release kernel reports as its version >> number the version number of the previous stable version, rather than >> the current version. >> This sometimes causes problems with out-of-kernel modules > I stopped caring here. [...] @davej: This issue was discussed on FudCON Boston. Didn't you indicate you might want to change it, so that a 2.6.foo-rc kernel actually gets the proper version (e.g. 2.6.foo and not 2.6.(foo-1) )? Or did I got you wrong here? CU thl (who really hates this version games, as it confused users a whole lot and breaks external modules for no good reasons afaics) From alexl at redhat.com Mon Mar 19 08:47:31 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 09:47:31 +0100 Subject: User directories integration - request for help In-Reply-To: <62734.192.54.193.51.1174053084.squirrel@rousalka.dyndns.org> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <1173992650.5024.9.camel@rousalka.dyndns.org> <1173993597.3535.3.camel@localhost.localdomain> <62734.192.54.193.51.1174053084.squirrel@rousalka.dyndns.org> Message-ID: <1174294051.3035.5.camel@greebo> On Fri, 2007-03-16 at 14:51 +0100, Nicolas Mailhot wrote: > Could you add please add a dot dir containing (hard|sym) links pointing to > whatever renamed directories the user configured at the moment ? Symlinks are a bad idea, they will leak out into the user interface (in file selectors and whatnot) and are not supported by all filesystems (lots of people use SMB homedirs). Hardlinks are not even possible for directories. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an old-fashioned overambitious paramedic with no name. She's a transdimensional communist college professor with her own daytime radio talk show. They fight crime! From alexl at redhat.com Mon Mar 19 08:49:56 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 09:49:56 +0100 Subject: User directories integration - request for help In-Reply-To: <20070316123536.GC2923@free.fr> References: <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> <20070316123536.GC2923@free.fr> Message-ID: <1174294196.3035.8.camel@greebo> On Fri, 2007-03-16 at 13:35 +0100, Patrice Dumas wrote: > > Again providing defaults for these applications doesn't take away your > > ability to customize anything. We have continued to adopt several ideas > > from other operating systems if that makes sense and that is a good thing. > > It seems like those folders are created automatically when user logs in. > That's what I dislike. If they are defaults for 'save' actions in every > apps, fine. If they are created and used automatically, I think it isn't > right. This would limit the use of these dirs to "automatic setting of default dir" only, and only for applications that use a specific version of the fileselector with specific APIs. It won't e.g. let you to have nice default bookmarks, nor would it work instantly with all applications. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a short-sighted alcoholic cop haunted by an iconic dead American confidante She's a warm-hearted bisexual politician with an evil twin sister. They fight crime! From mitr at volny.cz Mon Mar 19 08:54:31 2007 From: mitr at volny.cz (Miloslav Trmac) Date: Mon, 19 Mar 2007 09:54:31 +0100 Subject: User directories integration - request for help In-Reply-To: <1174294196.3035.8.camel@greebo> References: <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> <20070316123536.GC2923@free.fr> <1174294196.3035.8.camel@greebo> Message-ID: <45FE4FC7.4070106@volny.cz> Alexander Larsson napsal(a): > On Fri, 2007-03-16 at 13:35 +0100, Patrice Dumas wrote: >> It seems like those folders are created automatically when user logs in. >> That's what I dislike. If they are defaults for 'save' actions in every >> apps, fine. If they are created and used automatically, I think it isn't >> right. > nor would it work instantly with all applications. The specification is new, so it won't "work instantly with all applications" anyway. Mirek From bernie at develer.com Mon Mar 19 08:58:42 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Mon, 19 Mar 2007 09:58:42 +0100 Subject: [RFC] Filesystem-local databases in mlocate In-Reply-To: <1174284641.16983.8.camel@willson> References: <45FA1A1A.9060201@volny.cz> <1174284641.16983.8.camel@willson> Message-ID: <45FE50C2.8070207@develer.com> Simo Sorce wrote: >> Usage for /home on NFS: >> - NFS is automatically excluded by clients, so updatedb on clients >> does not walk the filesystem. >> - On the server: >> Add /srv/home to /etc/sysconfig/mlocate. If /srv/home is not a >> separate mount point, add LOCATE_PATH=:/srv/home/.mlocate/mlocate.db >> to the global environment. > > I am deeply concerned about the security implications of this idea. > You are basically making it possible for everyone to get access to the > complete remote FS layout ??? In the local case, mlocate.db contains the whole directory structure as read by the root user. Local security is based on unix permissions: the locate.db is not readable to normal users and the locate binary is set-gid locate. Remote databases exported in NFS shares cannot of course use this trick becausae it requires trusting the remote root of all clients. A solution could be crawling the filesystem as user nobody to avoid disclosing private information, but this would make the shared locate.db completely useless to index home directories. How did Apple solve the problem with Spotlight? Spotlight also stores its database in the root directory of all volumes, including flash pens and remote NFS shares. -- // Bernardo Innocenti - Develer R&D dept. \X/ http://www.develer.com/ From alexl at redhat.com Mon Mar 19 09:04:50 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 10:04:50 +0100 Subject: User directories integration - request for help In-Reply-To: <1174141274.26640.8.camel@willson> References: <1173953610.10024.132.camel@greebo> <1174107004.2691.31.camel@zelda.fubar.dk> <1174107776.4680.259.camel@mccallum.corsepiu.local> <200703170146.15455.lightsolphoenix@gmail.com> <1174111073.4680.275.camel@mccallum.corsepiu.local> <20070317140524.GD8832@devserv.devel.redhat.com> <1174141274.26640.8.camel@willson> Message-ID: <1174295090.3035.18.camel@greebo> On Sat, 2007-03-17 at 10:21 -0400, Simo Sorce wrote: > On Sat, 2007-03-17 at 10:05 -0400, Alan Cox wrote: > > > Having them set at first login (first not every) when your account gets > > all the desktop setup works as they then keep stable names. Having the > > ability in Nastilus to do > > > > right-click->Make this the default for->[Downloads|Photos|Music...] > > > > lets you do any renaming in a natural discoverable fashion > > +1 I want to be able to decide what names these folders have, or if I > want them at all (I'd probably choose not to have them, or to put them > in a place and in a language of my own) This would never be possible with an english on disk solution, but is perfectly (and extremely simple!) with the current solution. I'm not sure what you are arguing against. > Connecting them to the locale Is very stupid. I use when I install, > because I can't stand the way most of the things are translated in > Italian, but then I use some Italian names for some of my folders. There are multiple options: 1) Use an english locale 2) Rename the folders to whatever you want Just renaming it in nautilus will work fine. If you do it in a shell you need to also edit the config file. 3) Don't use the user directories Two approaches possible: a) disabling the feature in the system config file b) just remove the directories, they won't be recreated > I would get really really mad if switching english->italian->english I'd > found out that some smart utility changed my folder names! No such automatic switching is done, as I have said previously. To handle the case where you initially log in in English before later swtiching to your final locale we do however ask you on login if you want to switch to the new directory names. Just click on "no" (which is the default) and select "never ask me this again". =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a sword-wielding devious cowboy on the wrong side of the law. She's a sharp-shooting blonde vampire married to the Mob. They fight crime! From alexl at redhat.com Mon Mar 19 09:11:09 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 10:11:09 +0100 Subject: User directories integration - request for help In-Reply-To: <1174151784.18279.31.camel@rousalka.dyndns.org> References: <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <20070317135628.GB8832@devserv.devel.redhat.com> <1174143351.2857.11.camel@dawkins> <1174151784.18279.31.camel@rousalka.dyndns.org> Message-ID: <1174295469.3035.23.camel@greebo> On Sat, 2007-03-17 at 18:16 +0100, Nicolas Mailhot wrote: > There is one thing worse than not taking i18n in consideration that's > botching your i18n implementation. I for one am deeply attached to i18n > due to my personal background. And I'd rather wait a few weeks/months > for a proper solution that have a semi-broken hack that will be set in > stone as soon as a release goes out with it. A few weeks? The english-on-disk or translations-on-disk flamewar has been going on for at least five years. > > I don't want a windows-like i18n where my filesystem is polluted with > several translations of the same directories because someone made a > hasty partial implementation. Those would be from buggy applications that should be fixed. Since when do we cater to buggy applications enought to go with a worse solution. > For once I'd like people try to get it right from the start on, not > pretend it's an experiment that will be corrected later. The Desktop > team does no have a good track record admitting its mistakes, especially > once it managed to shove them through people's throats. I like it when we think something is right we are arrogant, but you're obviously not arrogant when you think our solution suck ass and yours is perfect. I'm well aware of the pros and cons of the solutions, having discussed them on and off for many years. No solution is perfect, but I have picked the one I think is best. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a maverick pirate boxer with a passion for fast cars. She's a radical cigar-chomping journalist from out of town. They fight crime! From hughsient at gmail.com Mon Mar 19 09:12:07 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Mar 2007 09:12:07 +0000 Subject: Kernel BUG caused by iwlwifi Message-ID: <1174295527.2881.4.camel@localhost.localdomain> Not sure what to do here - normally I wouldn't dare report out-of-vanilla modules for BUG'ing, but this one is being included in rawhide and stops the boot process dead. Worth filing a RH bugzilla or a kernel bugzilla? This is with latest rawhide. Thanks, Richard. Mar 19 08:53:15 localhost kernel: BUG: workqueue leaked lock or atomic: iwlwifi/0/0x00000000/1230 Mar 19 08:53:15 localhost kernel: last function: ipw_bg_reg_txpower_periodic+0x0/0x33 [iwlwifi] Mar 19 08:53:15 localhost kernel: 2 locks held by iwlwifi/0/1230: Mar 19 08:53:15 localhost kernel: #0: (rtnl_mutex){--..}, at: [] mutex_lock+0x21/0x24 Mar 19 08:53:15 localhost kernel: #1: (&sysfs_inode_imutex_key){--..}, at: [] mutex_lock+0x21/0x24 Mar 19 08:53:15 localhost kernel: [] show_trace_log_lvl +0x1a/0x2f Mar 19 08:53:15 localhost kernel: [] show_trace+0x12/0x14 Mar 19 08:53:15 localhost kernel: [] dump_stack+0x16/0x18 Mar 19 08:53:15 localhost kernel: [] run_workqueue+0xfe/0x145 Mar 19 08:53:15 localhost kernel: [] worker_thread+0xf8/0x124 Mar 19 08:53:15 localhost kernel: [] kthread+0xb3/0xdc Mar 19 08:53:15 localhost kernel: [] kernel_thread_helper +0x7/0x10 Mar 19 08:53:15 localhost kernel: ======================= Mar 19 08:54:15 localhost kernel: BUG: workqueue leaked lock or atomic: iwlwifi/0/0x00000000/1230 Mar 19 08:54:15 localhost kernel: last function: ipw_bg_reg_txpower_periodic+0x0/0x33 [iwlwifi] Mar 19 08:54:15 localhost kernel: 2 locks held by iwlwifi/0/1230: Mar 19 08:54:15 localhost kernel: #0: (rtnl_mutex){--..}, at: [] mutex_lock+0x21/0x24 Mar 19 08:54:15 localhost kernel: #1: (&sysfs_inode_imutex_key){--..}, at: [] mutex_lock+0x21/0x24 Mar 19 08:54:15 localhost kernel: [] show_trace_log_lvl +0x1a/0x2f Mar 19 08:54:15 localhost kernel: [] show_trace+0x12/0x14 Mar 19 08:54:15 localhost kernel: [] dump_stack+0x16/0x18 Mar 19 08:54:15 localhost kernel: [] run_workqueue+0xfe/0x145 Mar 19 08:54:15 localhost kernel: [] worker_thread+0xf8/0x124 Mar 19 08:54:15 localhost kernel: [] kthread+0xb3/0xdc Mar 19 08:54:15 localhost kernel: [] kernel_thread_helper +0x7/0x10 Mar 19 08:54:15 localhost kernel: ======================= Mar 19 08:55:15 localhost kernel: BUG: workqueue leaked lock or atomic: iwlwifi/0/0x00000000/1230 Mar 19 08:55:15 localhost kernel: last function: ipw_bg_reg_txpower_periodic+0x0/0x33 [iwlwifi] Mar 19 08:55:15 localhost kernel: 2 locks held by iwlwifi/0/1230: Mar 19 08:55:15 localhost kernel: #0: (rtnl_mutex){--..}, at: [] mutex_lock+0x21/0x24 Mar 19 08:55:15 localhost kernel: #1: (&sysfs_inode_imutex_key){--..}, at: [] mutex_lock+0x21/0x24 Mar 19 08:55:15 localhost kernel: [] show_trace_log_lvl +0x1a/0x2f Mar 19 08:55:15 localhost kernel: [] show_trace+0x12/0x14 Mar 19 08:55:15 localhost kernel: [] dump_stack+0x16/0x18 Mar 19 08:55:15 localhost kernel: [] run_workqueue+0xfe/0x145 Mar 19 08:55:15 localhost kernel: [] worker_thread+0xf8/0x124 Mar 19 08:55:15 localhost kernel: [] kthread+0xb3/0xdc Mar 19 08:55:15 localhost kernel: [] kernel_thread_helper +0x7/0x10 Mar 19 08:55:15 localhost kernel: ======================= Mar 19 08:56:15 localhost kernel: BUG: workqueue leaked lock or atomic: iwlwifi/0/0x00000000/1230 Mar 19 08:56:15 localhost kernel: last function: ipw_bg_reg_txpower_periodic+0x0/0x33 [iwlwifi] Mar 19 08:56:15 localhost kernel: 2 locks held by iwlwifi/0/1230: Mar 19 08:56:15 localhost kernel: #0: (rtnl_mutex){--..}, at: [] mutex_lock+0x21/0x24 Mar 19 08:56:15 localhost kernel: #1: (&sysfs_inode_imutex_key){--..}, at: [] mutex_lock+0x21/0x24 Mar 19 08:56:15 localhost kernel: [] show_trace_log_lvl +0x1a/0x2f Mar 19 08:56:15 localhost kernel: [] show_trace+0x12/0x14 Mar 19 08:56:15 localhost kernel: [] dump_stack+0x16/0x18 Mar 19 08:56:15 localhost kernel: [] run_workqueue+0xfe/0x145 Mar 19 08:56:15 localhost kernel: [] worker_thread+0xf8/0x124 Mar 19 08:56:15 localhost kernel: [] kthread+0xb3/0xdc Mar 19 08:56:15 localhost kernel: [] kernel_thread_helper +0x7/0x10 Mar 19 08:56:15 localhost kernel: ======================= Mar 19 08:57:15 localhost kernel: BUG: workqueue leaked lock or atomic: iwlwifi/0/0x00000000/1230 Mar 19 08:57:15 localhost kernel: last function: ipw_bg_reg_txpower_periodic+0x0/0x33 [iwlwifi] Mar 19 08:57:15 localhost kernel: 2 locks held by iwlwifi/0/1230: Mar 19 08:57:15 localhost kernel: #0: (rtnl_mutex){--..}, at: [] mutex_lock+0x21/0x24 Mar 19 08:57:15 localhost kernel: #1: (&sysfs_inode_imutex_key){--..}, at: [] mutex_lock+0x21/0x24 Mar 19 08:57:15 localhost kernel: [] show_trace_log_lvl +0x1a/0x2f Mar 19 08:57:15 localhost kernel: [] show_trace+0x12/0x14 Mar 19 08:57:15 localhost kernel: [] dump_stack+0x16/0x18 Mar 19 08:57:15 localhost kernel: [] run_workqueue+0xfe/0x145 Mar 19 08:57:15 localhost kernel: [] worker_thread+0xf8/0x124 Mar 19 08:57:15 localhost kernel: [] kthread+0xb3/0xdc Mar 19 08:57:15 localhost kernel: [] kernel_thread_helper +0x7/0x10 Mar 19 08:57:15 localhost kernel: ======================= Mar 19 08:58:15 localhost kernel: BUG: workqueue leaked lock or atomic: iwlwifi/0/0x00000000/1230 Mar 19 08:58:15 localhost kernel: last function: ipw_bg_reg_txpower_periodic+0x0/0x33 [iwlwifi] Mar 19 08:58:15 localhost kernel: 2 locks held by iwlwifi/0/1230: Mar 19 08:58:15 localhost kernel: #0: (rtnl_mutex){--..}, at: [] mutex_lock+0x21/0x24 Mar 19 08:58:15 localhost kernel: #1: (&sysfs_inode_imutex_key){--..}, at: [] mutex_lock+0x21/0x24 Mar 19 08:58:15 localhost kernel: [] show_trace_log_lvl +0x1a/0x2f Mar 19 08:58:15 localhost kernel: [] show_trace+0x12/0x14 Mar 19 08:58:15 localhost kernel: [] dump_stack+0x16/0x18 Mar 19 08:58:15 localhost kernel: [] run_workqueue+0xfe/0x145 Mar 19 08:58:15 localhost kernel: [] worker_thread+0xf8/0x124 Mar 19 08:58:15 localhost kernel: [] kthread+0xb3/0xdc Mar 19 08:58:15 localhost kernel: [] kernel_thread_helper +0x7/0x10 Mar 19 08:58:15 localhost kernel: ======================= Mar 19 08:59:15 localhost kernel: BUG: workqueue leaked lock or atomic: iwlwifi/0/0x00000000/1230 Mar 19 08:59:15 localhost kernel: last function: ipw_bg_reg_txpower_periodic+0x0/0x33 [iwlwifi] Mar 19 08:59:15 localhost kernel: 2 locks held by iwlwifi/0/1230: Mar 19 08:59:15 localhost kernel: #0: (rtnl_mutex){--..}, at: [] mutex_lock+0x21/0x24 Mar 19 08:59:15 localhost kernel: #1: (&sysfs_inode_imutex_key){--..}, at: [] mutex_lock+0x21/0x24 Mar 19 08:59:15 localhost kernel: [] show_trace_log_lvl +0x1a/0x2f Mar 19 08:59:15 localhost kernel: [] show_trace+0x12/0x14 Mar 19 08:59:15 localhost kernel: [] dump_stack+0x16/0x18 Mar 19 08:59:15 localhost kernel: [] run_workqueue+0xfe/0x145 Mar 19 08:59:15 localhost kernel: [] worker_thread+0xf8/0x124 Mar 19 08:59:15 localhost kernel: [] kthread+0xb3/0xdc Mar 19 08:59:15 localhost kernel: [] kernel_thread_helper +0x7/0x10 Mar 19 08:59:15 localhost kernel: ======================= From alexl at redhat.com Mon Mar 19 09:13:04 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 10:13:04 +0100 Subject: User directories integration - request for help In-Reply-To: <20070316170658.GA5795@humbolt.us.dell.com> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <20070316170658.GA5795@humbolt.us.dell.com> Message-ID: <1174295584.3035.26.camel@greebo> On Fri, 2007-03-16 at 12:06 -0500, Michael E Brown wrote: > On Thu, Mar 15, 2007 at 04:00:54PM -0400, Matthias Clasen wrote: > > On Thu, 2007-03-15 at 20:29 +0100, nodata wrote: > > > Am Donnerstag, den 15.03.2007, 14:03 -0400 schrieb Matthias Clasen: > > > > On Thu, 2007-03-15 at 11:13 +0100, Alexander Larsson wrote: > > > > > > > > > > Any other ideas? > > > > > > > > Might be a good idea to give a quick explanation of what happens, and > > > > what people should expect to see if they install the packages. > > > > > > > > Matthias > > > > > > > > > > >From the looks of it, the directories get continually renamed if you > > > switch languages. Stay away from my home dir, use a dot file if you > > > must! > > > > Any you continually switch languages ?! > > Necesito practicar todos los lenguas que hablo, y por eso, > > I switch login sessions periodically between English and Spanish to > keep my spanish from becoming rusty. So, with this system you get to pick either English or Spanish folder names. That seems perfectly right, given that the same is true for all your other folders. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a notorious gay farmboy on his last day in the job. She's a foxy thirtysomething queen of the dead with an MBA from Harvard. They fight crime! From bernie at develer.com Mon Mar 19 09:15:18 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Mon, 19 Mar 2007 10:15:18 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <20070318173312.GD31755@neu.nirvana> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> <20070316115828.GD24022@neu.nirvana> <45FD1E5F.6040407@develer.com> <20070318111937.GB18524@neu.nirvana> <1174217247.19932.21.camel@rousalka.dyndns.org> <20070318115513.GC18524@neu.nirvana> <45FD40F3.3060003@develer.com> <20070318141230.GH24404@neu.nirvana> <45FD521E.6040705@develer.com> <20070318173312.GD31755@neu.nirvana> Message-ID: <45FE54A6.5080906@develer.com> Axel Thimm wrote: >> It's been a while since I used GFS, and it was GFS1 on RHAS3 or >> maybe 4. At that time, GFS performance was poor wrt ext3 even when >> the storage was locally attached to a single server. But what it >> did was so useful for an HA cluster that you would excuse it for >> not being also fast. > > ... aren't you doing it again? On one post you assume GFS being as > fast as any local fs, only to admit that it isn't. Yes, I look confused but actually I'm not. Or so I believe. The slow performance I'm talking about is again something you'd measure by running "find . >/dev/null", maybe twice. Issuing thousands of small queries makes most network filesystems, and the old GFS1, crawl. That's probably because these filesystems can't cache metadata at the VFS layer and must go through the lower layers to answer. If you think this access pattern is uncommon, consider that git, svn, cvs, and even make are designed around the assumption that stat'ting is cheap. When it comes to read() and write() in big chunks -- which is what you do to access mlocate.db -- I'd expect any half-decent filesystem to deliver almost the same raw performance of its underlying media. > Anyway, seems at the end we do agree ;) Yep :) > Even so, what does the poor fellow with a laptop and NFS3 do? Which is > a very common setup? A local cache would be needed in this case. > In this case the caching is rather trivial, since it is just a copy > operation and checking sizes & mtime. It can be made _perfect_ by > adding a checksum at the beginning or end of the db. Yes, I wasn't considering the whole picture: mlocate.db already *is* a cache. Caching a cache is trivial :-) -- // Bernardo Innocenti - Develer R&D dept. \X/ http://www.develer.com/ From alexl at redhat.com Mon Mar 19 09:19:47 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 10:19:47 +0100 Subject: User directories integration - request for help In-Reply-To: <20070316124530.GD2923@free.fr> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> <20070316124530.GD2923@free.fr> Message-ID: <1174295987.3035.33.camel@greebo> On Fri, 2007-03-16 at 13:45 +0100, Patrice Dumas wrote: > On Fri, Mar 16, 2007 at 10:05:24AM +0100, Alexander Larsson wrote: > > > > What happens is this: > > > > First time you log in, directories will be created based on the current > > locale and pointers to them will be created in the file > > ~/.config/user-dirs.dirs. We also record the locale used in a separate > > file. > > I really dislikes the idea that directories are created at login time. > Couldn't it be possible instead to have them created when needed and use > the names and locales recorded in ~/.config/user-dirs.dirs for the default > name? That would limit the use of this to "default fileselector directory" for applications that have that hardcoded. There are other uses too, like default bookmarks (in file manager, file selector, etc). I'll also say (and I know some people will hate me for this) that I think a lot of unexperienced users will like having some initial structure to their homedirectory. Experienced users can set it up how they want (and do!), but unexperienced users are unlikely to start their experimenting with a new OS by setting up a homedirectory structure. > > The second time you log in we will only create directories specified in > > the defaults file that are not listed in your ~/.config/user-dirs.dirs > > file. (So, you'll get new default dirs.) Directories specified in your > > config file that has been removed will be changed in the config file to > > point to $HOME. > > It seems to me that there is too much magic in this... Whats magic about it. There isn't really a first-time/second-time version of the code of course. We just create directories that haven't been added to the config file yet. > > If you log in a second time in a language different than the original > > one you will get a dialog asking you whether you want to move to the new > > locale, with a list of what would change if you did. Then you can pick, > > yes, no, and "never show me this again". > > I think this is unavoidable, but this should only be done with existing > directories. How could you do it with non-existing directories? I'm not sure what you mean. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a witless albino cop from a doomed world. She's a ditzy cigar-chomping femme fatale with only herself to blame. They fight crime! From alexl at redhat.com Mon Mar 19 09:27:34 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 10:27:34 +0100 Subject: User directories integration - request for help In-Reply-To: <46940.74.96.19.63.1174046180.squirrel@lattica.com> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> <46940.74.96.19.63.1174046180.squirrel@lattica.com> Message-ID: <1174296454.3035.39.camel@greebo> On Fri, 2007-03-16 at 07:56 -0400, Dimi Paun wrote: > On Fri, March 16, 2007 05:05, Alexander Larsson wrote: > > At the moment the migration is kind of lame. We just create the new > > folders and point to them, and the user will have to move stuff over > > manually. Moving user data automatically is tricky and risky, but this > > is quite lame. > > This is so lame that we'd be _much_ better off not showing it to the > user -- I mean, most people can intuitively understand that once created, > things will remain like that, but most will be quite pissed off (and rightly > so) if we force them at login time to make a decision out of which one > of the choices is totally broken. > > Maybe just create a "language changer" utility that the use explicitly > invokes to do the switch, so that only folks that want to change the > language of said dirs (and I'd expect them to be in the minority!) would > have to deal with it. And being invoked as an explicit migration, it can > also move the files as an explicit step that may involve the user for > further clarifications. There is already a lanugage changer. Just run "xdg-user-dirs-update --force". Its what the login app do. However, the dialog was added for the quite common case where you log in english first, and then switch to your "real" locale. We could of course disable this dialog, but then a lot of people would end up with english directories because they didn't know how to invoke the "language change" (or in fact, that such a thing existed at all). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an uncontrollable hunchbacked inventor on the wrong side of the law. She's a vivacious nymphomaniac socialite on the trail of a serial killer. They fight crime! From alexl at redhat.com Mon Mar 19 09:31:50 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 10:31:50 +0100 Subject: User directories integration - request for help In-Reply-To: <1174121207.11892.6.camel@rousalka.dyndns.org> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <1174103491.4680.227.camel@mccallum.corsepiu.local> <1174105657.2691.24.camel@zelda.fubar.dk> <1174106134.4680.249.camel@mccallum.corsepiu.local> <1174107004.2691.31.camel@zelda.fubar.dk> <1174121207.11892.6.camel@rousalka.dyndns.org> Message-ID: <1174296710.3035.44.camel@greebo> On Sat, 2007-03-17 at 09:46 +0100, Nicolas Mailhot wrote: > Le samedi 17 mars 2007 ? 00:50 -0400, David Zeuthen a ?crit : > > On Sat, 2007-03-17 at 05:35 +0100, Ralf Corsepius wrote: > > > I say: Alex, Matthias wake up and take off your shades. You are going to > > > commit something "stupid"! > > > > [...] > > > > > I say: They missed the lack of usefulness, because they are too focused. > > > > So the developers from the desktop projects and the distros (e.g. the > > people who participate on xdg-list) are all wrong and stupid because > > they want this feature and you don't? I think we can end this thread... > > The people on xdg-list are not stupid but they are GUI devs and they > tend to forget a lot of things on a *nix system is not GUI stuff. Remind > us again how high gnome-terminal piked in mugshot stats? > > Would it be so difficult to use symlinks as directory pointers instead > of hiding them in yet another config file? That would make cross-user > scripting so much easier There are several problems with symlinks. They don't work on all filesystems (smb homedirs). They easily escape into the user interface (i.e. you default your fileselector to ~/.user-dirs/desktop and the user presses "up" and is greeted with some desktop implementation internals). However, I'm aware that it has to be easy to write script using these directores. Thats why I made the config file a shell script so that you can do: test -f ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs && source ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs echo ${XDG_DESKTOP_DIR:-$HOME/Desktop} echo ${XDG_DOWNLOAD_DIR:-$HOME} =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a fiendish ninja inventor on a mission from God. She's an elegant impetuous mechanic from a family of eight older brothers. They fight crime! From alexl at redhat.com Mon Mar 19 09:36:46 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 10:36:46 +0100 Subject: User directories integration - request for help In-Reply-To: <45FE4FC7.4070106@volny.cz> References: <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> <20070316123536.GC2923@free.fr> <1174294196.3035.8.camel@greebo> <45FE4FC7.4070106@volny.cz> Message-ID: <1174297007.3035.48.camel@greebo> On Mon, 2007-03-19 at 09:54 +0100, Miloslav Trmac wrote: > Alexander Larsson napsal(a): > > On Fri, 2007-03-16 at 13:35 +0100, Patrice Dumas wrote: > >> It seems like those folders are created automatically when user logs in. > >> That's what I dislike. If they are defaults for 'save' actions in every > >> apps, fine. If they are created and used automatically, I think it isn't > >> right. > > > nor would it work instantly with all applications. > The specification is new, so it won't "work instantly with all > applications" anyway. It very much does. All applications using the gtk file selector will have some default folders as file selector bookmars, and *all* applications get translated filenames for common directories. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a scrappy Republican astronaut who knows the secret of the alien invasion. She's a vivacious foul-mouthed advertising executive with someone else's memories. They fight crime! From alexl at redhat.com Mon Mar 19 09:42:10 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 10:42:10 +0100 Subject: User directories integration - request for help In-Reply-To: <1174161785.3429.16.camel@localhost.localdomain> References: <1173953610.10024.132.camel@greebo> <1174161785.3429.16.camel@localhost.localdomain> Message-ID: <1174297330.3035.53.camel@greebo> On Sat, 2007-03-17 at 22:03 +0200, Baris Cicek wrote: > I could not find where to post this, so sending over here. > > I changed Alex's xdg-user-dirs application to make it using symlinks > instead of actual directories. Maybe it's something in vain but just > wanted to put my solution into a prototype so as to be tested. (Maybe > someone like it). > > Actually using symlinks give better handling of localization than using > --force. It does not touch directories, so can be considered > theoretically more secure. Each application will have to use readlink() to find the actual directory to use. For sure you don't want have a filename like ~/.desktop/file.txt to ever be seen by the user, so you must always store the expanded form. Plus, you need to fallback on a file if symlinks are not supported. So, I don't think this is a better solution. (As I didn't when it was proposed in the discussions leading to the design of xdg-user-dirs.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an underprivileged flyboy gentleman spy living undercover at Ringling Bros. Circus. She's a foxy cigar-chomping hooker on her way to prison for a murder she didn't commit. They fight crime! From mitr at volny.cz Mon Mar 19 09:42:15 2007 From: mitr at volny.cz (Miloslav Trmac) Date: Mon, 19 Mar 2007 10:42:15 +0100 Subject: User directories integration - request for help In-Reply-To: <1174297007.3035.48.camel@greebo> References: <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> <20070316123536.GC2923@free.fr> <1174294196.3035.8.camel@greebo> <45FE4FC7.4070106@volny.cz> <1174297007.3035.48.camel@greebo> Message-ID: <45FE5AF7.1000103@volny.cz> Alexander Larsson napsal(a): > It very much does. All applications using the gtk file selector will > have some default folders as file selector bookmars, and *all* > applications get translated filenames for common directories. If you rely on smart file selector bookmarks, can't you just as well let the smart file selector bookmarks create the directory on first use? Mirek From buildsys at redhat.com Mon Mar 19 09:47:01 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 19 Mar 2007 05:47:01 -0400 Subject: rawhide report: 20070319 changes Message-ID: <200703190947.l2J9l1dY008773@hs20-bc2-6.build.redhat.com> Updated Packages: glibc-2.5.90-19 --------------- * Sat Mar 17 2007 Jakub Jelinek 2.5.90-19 - fix power6 libm compat symbols on ppc32 (#232633) - fix child refcntr in NPTL fork (#230198) - fix ifaddrs with many net devices on > 4KB page size arches (#230151) - fix pthread_mutex_timedlock on x86_64 (#228103) - various fixes (BZ#3919, BZ#4101, BZ#4130, BZ#4181, BZ#4069, BZ#3458) * Wed Feb 21 2007 Jakub Jelinek 2.5.90-18 - fix nftw with FTW_CHDIR on / (BZ#4076) - nscd fixes (BZ#4074) - fix fmod{,f,l} on i?86 (BZ#3325) - support localized digits for fp values in *scanf (BZ#2211) - namespaces fixes (BZ#2633) - fix euidaccess (BZ#3842) - glob fixes (BZ#3996) - assorted locale data fixes (BZ#1430, BZ#672, BZ#58, BZ#3156, BZ#2692, BZ#2648, BZ#3363, BZ#3334, BZ#3326, BZ#3322, BZ#3995, BZ#3885, BZ#3884, BZ#3851) scim-tables-0.5.7-2.fc7 ----------------------- * Mon Mar 19 2007 Caius Chance - 0.5.7-2.fc7 - Fixed bz#217639: scim-tables Chang-Jie preedit was not cleared after focus out then focus in. startup-notification-0.9-1.fc7 ------------------------------ * Sun Mar 18 2007 Matthias Clasen - 0.9-1 - Update to 0.9 system-config-date-1.8.90-1.fc7 ------------------------------- * Mon Mar 19 2007 Nils Philippsen 1.8.90 - add tooltip to zoomed-in canvas to describe panning * Sun Mar 18 2007 Nils Philippsen - display to-be-selected city inside map instead of status bar (#211550) - remove remaining regions cruft - make currently selected city non-selectable * Sat Mar 17 2007 Nils Philippsen - implement panning of zoomed timezone map system-config-printer-0.7.56-2.fc7 ---------------------------------- * Sun Mar 18 2007 Tim Waugh 0.7.56-2 - Updated to pycups-1.9.18. xorg-x11-drv-via-0.2.2-1.fc7 ---------------------------- * Sun Mar 18 2007 Adam Jackson 0.2.2-1 - Update to 0.2.2 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 sundaram at fedoraproject.org Mon Mar 19 09:51:53 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 15:21:53 +0530 Subject: too many deamons by default - F7 test 2 live cd Message-ID: <45FE5D39.7020002@fedoraproject.org> Hi Been fiddling with a installation of Fedora 7 Test 2 from the Live CD and it still enables way too may daemons by default. The following deserve special mention. Hardware specific - Bluetooth (along with hidd), cups (FC6 even had smartcard daemon by default). Should check and enable on demand Definitely superfluous - firstboot, livecd. Should disable after first run completely or even remove the packages. Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. Can't see a reason to enable these by default. Default? - Possibly NetworkManagerDispatcher since NetworkManager is enabled by default Exim should probably replaced with something like esmtp or ssmtp in the live cd. Folks wanting to install a full blown MTA can install sendmail, postfix or email on their own. Comments? From pertusus at free.fr Mon Mar 19 09:53:49 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 19 Mar 2007 10:53:49 +0100 Subject: User directories integration - request for help In-Reply-To: <1174295987.3035.33.camel@greebo> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> <20070316124530.GD2923@free.fr> <1174295987.3035.33.camel@greebo> Message-ID: <20070319095349.GA3186@free.fr> On Mon, Mar 19, 2007 at 10:19:47AM +0100, Alexander Larsson wrote: > > That would limit the use of this to "default fileselector directory" for > applications that have that hardcoded. Apps using special directories have to be changed too. What is complicated in adding to fileselector an argument like 'pictures' to use a given default directory? > There are other uses too, like > default bookmarks (in file manager, file selector, etc). They could create the directory when the user click on the icon? > I'll also say (and I know some people will hate me for this) that I > think a lot of unexperienced users will like having some initial > structure to their homedirectory. Experienced users can set it up how > they want (and do!), but unexperienced users are unlikely to start their > experimenting with a new OS by setting up a homedirectory structure. Unexperienced users don't want something specific. Except if you think that what unexperienced users want is what is in windows. Adding something (non dot file or dot dir) in the home directory is bad design, especially when there is another solution. > > > The second time you log in we will only create directories specified in > > > the defaults file that are not listed in your ~/.config/user-dirs.dirs > > > file. (So, you'll get new default dirs.) Directories specified in your > > > config file that has been removed will be changed in the config file to > > > point to $HOME. > > > > It seems to me that there is too much magic in this... > > Whats magic about it. There isn't really a first-time/second-time > version of the code of course. We just create directories that haven't > been added to the config file yet. How can you do 'Directories specified in your config file that has been removed will be changed in the config file to point to $HOME.' without something magic? > How could you do it with non-existing directories? I'm not sure what you > mean. In the 'created by fileselecor proposal' only the directories already created would have to be moved. -- Pat From pertusus at free.fr Mon Mar 19 09:57:22 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 19 Mar 2007 10:57:22 +0100 Subject: User directories integration - request for help In-Reply-To: <1174185384.3455.4.camel@localhost.localdomain> References: <1174102387.2653.62.camel@zelda.fubar.dk> <1174103491.4680.227.camel@mccallum.corsepiu.local> <1174105657.2691.24.camel@zelda.fubar.dk> <1174106134.4680.249.camel@mccallum.corsepiu.local> <1174107004.2691.31.camel@zelda.fubar.dk> <20070317135944.GC8832@devserv.devel.redhat.com> <1174159178.2759.7.camel@localhost.localdomain> <20070317195544.GA21441@devserv.devel.redhat.com> <1174151524.2784.8.camel@zelda.fubar.dk> <1174185384.3455.4.camel@localhost.localdomain> Message-ID: <20070319095722.GB3186@free.fr> On Sat, Mar 17, 2007 at 10:36:24PM -0400, Matthias Clasen wrote: > fedora-devel has done its magic and managed to make this thread too long > for any meaningful response in just a few days, but let me just ask this > one question here: > > How many of the people who go ballistic here about stupid gui developers > with fingers in their ears trying to imitate win95 have actually tried > Alex' implementation ? No need to try it to discuss about the design. Avoiding a bad design ealy is likely to help better than trying an implementation of a design we don't like anyway. -- Pat From oliver at linux-kernel.at Mon Mar 19 10:05:10 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 19 Mar 2007 11:05:10 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE5D39.7020002@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> Message-ID: <45FE6056.9080004@linux-kernel.at> Hi Rahul! On 03/19/2007 10:51 AM, Rahul Sundaram wrote: > Been fiddling with a installation of Fedora 7 Test 2 from the Live CD > and it still enables way too may daemons by default. The following > deserve special mention. > > Hardware specific - Bluetooth (along with hidd), cups (FC6 even had > smartcard daemon by default). Should check and enable on demand Hm. Sounds good, shouldn't be enabled by default; Not only on the LiveCD... > Definitely superfluous - firstboot, livecd. Should disable after first > run completely or even remove the packages. > > Extra - cpuspeed. This one makes sense on laptops, doesn't it? I wouldn't disable that one. Or only if there's some way to check if the cpu supports it or not. If not I wouldn't even install it. > mdmonitor, netfs Yes, also think these shouldn't be enabled; Or installed... > ntpd, I would let this one. Time synchronization makes sense. > portmap. Can't see a reason to enable these by default. Maybe. [ ... ] Just my 2 cent... -of From rc040203 at freenet.de Mon Mar 19 09:51:38 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Mar 2007 10:51:38 +0100 Subject: User directories integration - request for help In-Reply-To: <1174297007.3035.48.camel@greebo> References: <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> <20070316123536.GC2923@free.fr> <1174294196.3035.8.camel@greebo> <45FE4FC7.4070106@volny.cz> <1174297007.3035.48.camel@greebo> Message-ID: <1174297898.3667.1.camel@mccallum.corsepiu.local> On Mon, 2007-03-19 at 10:36 +0100, Alexander Larsson wrote: > On Mon, 2007-03-19 at 09:54 +0100, Miloslav Trmac wrote: > > Alexander Larsson napsal(a): > > > On Fri, 2007-03-16 at 13:35 +0100, Patrice Dumas wrote: > > >> It seems like those folders are created automatically when user logs in. > > >> That's what I dislike. If they are defaults for 'save' actions in every > > >> apps, fine. If they are created and used automatically, I think it isn't > > >> right. > > > > > nor would it work instantly with all applications. > > The specification is new, so it won't "work instantly with all > > applications" anyway. > > It very much does. All applications using the gtk file selector will > have some default folders as file selector bookmars, and *all* > applications get translated filenames for common directories. And all other applications, such as gui-less apps will be broken. Related to this: Explain who all this is supposed without any login-manager (plain su -l without running any GUI) Ralf From alexl at redhat.com Mon Mar 19 10:13:12 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 11:13:12 +0100 Subject: User directories integration - request for help In-Reply-To: <1174297898.3667.1.camel@mccallum.corsepiu.local> References: <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> <20070316123536.GC2923@free.fr> <1174294196.3035.8.camel@greebo> <45FE4FC7.4070106@volny.cz> <1174297007.3035.48.camel@greebo> <1174297898.3667.1.camel@mccallum.corsepiu.local> Message-ID: <1174299192.3035.59.camel@greebo> On Mon, 2007-03-19 at 10:51 +0100, Ralf Corsepius wrote: > > It very much does. All applications using the gtk file selector will > > have some default folders as file selector bookmars, and *all* > > applications get translated filenames for common directories. > > And all other applications, such as gui-less apps will be broken. How are they broken? The only thing I can see that is possible to break is if some application hardcodes ~/Desktop. Of course, thats already broken since gnome has a config option to use $HOME as desktop and KDE has a general config option for where to put the desktop directory. > Related to this: Explain who all this is supposed without any > login-manager (plain su -l without running any GUI) If you don't log in through a gui then xdg-user-dirs-update won't be run (unless you manually run it). This is not a problem and shouldn't affect anything (except you won't get the default dirs if you never run it). Everything should keep working as it is right now. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a maverick native American barbarian from the Mississippi delta. She's a provocative paranoid opera singer with a birthmark shaped like Liberty's torch. They fight crime! From nigel.metheringham at dev.intechnology.co.uk Mon Mar 19 10:18:40 2007 From: nigel.metheringham at dev.intechnology.co.uk (Nigel Metheringham) Date: Mon, 19 Mar 2007 10:18:40 +0000 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE6056.9080004@linux-kernel.at> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> Message-ID: <296B7F7B-1123-47F5-AC53-EEE7D24B1560@dev.intechnology.co.uk> On 19 Mar 2007, at 10:05, Oliver Falk wrote: > > > ntpd, > > I would let this one. Time synchronization makes sense. We could use something slimmer than the full ntpd - a client only (s) ntp implementation, say. Maybe openntpd. Nigel. -- [ Nigel Metheringham Nigel.Metheringham at InTechnology.co.uk ] [ - Comments in this message are my own and not ITO opinion/policy - ] From nicolas.mailhot at laposte.net Mon Mar 19 10:05:21 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 11:05:21 +0100 (CET) Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE5D39.7020002@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> Message-ID: <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 10:51, Rahul Sundaram a ?crit : > Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. Can't see a reason to > enable these by default. cpuspeed, mdmonitor and ntpd are no more extra than NetworkManager Daemon number is a red herring. A gigantic do-it-all daemon is worse than a set of small well-defined services. cpuspeed, mdmonitor and ntpd are definitively not the ones who should be axed first - they're small, proven and without side-effects (unlike others) -- Nicolas Mailhot From rc040203 at freenet.de Mon Mar 19 10:29:41 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Mar 2007 11:29:41 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE5D39.7020002@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> Message-ID: <1174300182.3667.5.camel@mccallum.corsepiu.local> On Mon, 2007-03-19 at 15:21 +0530, Rahul Sundaram wrote: > Hi > > Been fiddling with a installation of Fedora 7 Test 2 from the Live CD > and it still enables way too may daemons by default. The following > deserve special mention. > > Hardware specific - Bluetooth (along with hidd), cups (FC6 even had > smartcard daemon by default). Should check and enable on demand > > Definitely superfluous - firstboot, livecd. Should disable after first > run completely or even remove the packages. > > Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. No portmap => no nis, no nfs, no rpc. > Can't see a reason to > enable these by default. > > Default? - Possibly NetworkManagerDispatcher since > NetworkManager is enabled by default Disable this. It has never worked for me anywhere and is the first daemon I disable after FC installs. > Exim should probably replaced with something like esmtp or ssmtp in the > live cd. Folks wanting to install a full blown MTA can install sendmail, > postfix or email on their own. > > Comments? You are scratching on the surface of a weak spot in Fedora. Ralf From sundaram at fedoraproject.org Mon Mar 19 10:31:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 16:01:39 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> Message-ID: <45FE668B.8000904@fedoraproject.org> Nicolas Mailhot wrote: > Le Lun 19 mars 2007 10:51, Rahul Sundaram a ?crit : > >> Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. Can't see a reason to >> enable these by default. > > cpuspeed, mdmonitor and ntpd are no more extra than NetworkManager Yes, They are. For a desktop. A Live CD is targeted at the desktop. Nothing else. > Daemon number is a red herring. A gigantic do-it-all daemon is worse than > a set of small well-defined services. cpuspeed, mdmonitor and ntpd are > definitively not the ones who should be axed first - they're small, proven > and without side-effects (unlike others) Unless there is any do-it-all daemon enabled by default this is irrelevant. There are side effects for all daemons - slower performance, potential higher security risks etc. The less the better. Rahul From jonathan.underwood at gmail.com Mon Mar 19 10:31:28 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 19 Mar 2007 10:31:28 +0000 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE5D39.7020002@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> Message-ID: <645d17210703190331k4798b8f2wa86590bc63fc218d@mail.gmail.com> On 19/03/07, Rahul Sundaram wrote: > Exim should probably replaced with something like esmtp or ssmtp in the > live cd. Folks wanting to install a full blown MTA can install sendmail, > postfix or email on their own. Problem is, as far as I can tell neither of these provide local mail delivery, so things that expect to deliver mail to root will break, for example. From alexl at redhat.com Mon Mar 19 10:35:10 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 11:35:10 +0100 Subject: User directories integration - request for help In-Reply-To: <20070319095349.GA3186@free.fr> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> <20070316124530.GD2923@free.fr> <1174295987.3035.33.camel@greebo> <20070319095349.GA3186@free.fr> Message-ID: <1174300510.3035.79.camel@greebo> On Mon, 2007-03-19 at 10:53 +0100, Patrice Dumas wrote: > > There are other uses too, like > > default bookmarks (in file manager, file selector, etc). > > They could create the directory when the user click on the icon? I don't think this is largely different from creating them at login. Many dirs will be created at first login anyway (Desktop, Templates, maybe Public), and others will be created as you go. Seems very similar to the create-at-login approach except the code needs to be duplicated all over the place and the homedirectory is slowly modified over time instead of just once. > > I'll also say (and I know some people will hate me for this) that I > > think a lot of unexperienced users will like having some initial > > structure to their homedirectory. Experienced users can set it up how > > they want (and do!), but unexperienced users are unlikely to start their > > experimenting with a new OS by setting up a homedirectory structure. > > Unexperienced users don't want something specific. Except if you think > that what unexperienced users want is what is in windows. Ah, the old "you just want us to be windows" argument. Lets just say we disagree on this point without having to fall into name-calling. > Adding something (non dot file or dot dir) in the home directory is > bad design, especially when there is another solution. Its pretty bad to create visible folders in the homedir that expose the internals of an applications. However, things are different if you're designing an application for the explicit purpose of creating visible directories in the home directory. We can of course disagree on whether such an application should exist or not... > How can you do 'Directories specified in your config file that has been > removed will be changed in the config file to point to $HOME.' without > something magic? While we scan the list of the users already configured directories we call stat() to see if they are stale, if so we reset it to something that is not stale. How is an if and a stat "magic". =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a lonely albino matador living undercover at Ringling Bros. Circus. She's a blind bisexual research scientist descended from a line of powerful witches. They fight crime! From nicolas.mailhot at laposte.net Mon Mar 19 10:35:15 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 11:35:15 +0100 (CET) Subject: User directories integration - request for help In-Reply-To: <1174297330.3035.53.camel@greebo> References: <1173953610.10024.132.camel@greebo> <1174161785.3429.16.camel@localhost.localdomain> <1174297330.3035.53.camel@greebo> Message-ID: <9622.192.54.193.51.1174300515.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 10:42, Alexander Larsson a ?crit : > On Sat, 2007-03-17 at 22:03 +0200, Baris Cicek wrote: >> I could not find where to post this, so sending over here. >> >> I changed Alex's xdg-user-dirs application to make it using symlinks >> instead of actual directories. Maybe it's something in vain but just >> wanted to put my solution into a prototype so as to be tested. (Maybe >> someone like it). >> >> Actually using symlinks give better handling of localization than using >> --force. It does not touch directories, so can be considered >> theoretically more secure. > > Each application will have to use readlink() to find the actual > directory to use. For sure you don't want have a filename like > ~/.desktop/file.txt to ever be seen by the user, so you must always > store the expanded form. Plus, you need to fallback on a file if > symlinks are not supported. And all this can be put in a nice common GUI library. OTOH all the unix utilities that work on a file (including symlinks) won't learn to parse your special file. Shell wrappers will multiply (getting parsing of this file wrong most often than not) > So, I don't think this is a better solution. (As I didn't when it was > proposed in the discussions leading to the design of xdg-user-dirs.) And I can (and do) disagree with you -- Nicolas Mailhot From sundaram at fedoraproject.org Mon Mar 19 10:36:07 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 16:06:07 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174300182.3667.5.camel@mccallum.corsepiu.local> References: <45FE5D39.7020002@fedoraproject.org> <1174300182.3667.5.camel@mccallum.corsepiu.local> Message-ID: <45FE6797.2010307@fedoraproject.org> Ralf Corsepius wrote: > On Mon, 2007-03-19 at 15:21 +0530, Rahul Sundaram wrote: >> Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. > No portmap => no nis, no nfs, no rpc. Again, This live CD is meant for a desktop. You can always enable it if you need it. >> Default? - Possibly NetworkManagerDispatcher since >> NetworkManager is enabled by default > Disable this. It has never worked for me anywhere and is the first > daemon I disable after FC installs. You will have to look beyond just your personal consideration. It works for me. Bug reports? > You are scratching on the surface of a weak spot in Fedora. I checked all the daemons and listing the ones find I found unnecessarily enabled for a desktop. If there are more do list them specifically. Vague comments are not helpful. Rahul From rc040203 at freenet.de Mon Mar 19 10:42:22 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Mar 2007 11:42:22 +0100 Subject: User directories integration - request for help In-Reply-To: <1174299192.3035.59.camel@greebo> References: <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> <20070316123536.GC2923@free.fr> <1174294196.3035.8.camel@greebo> <45FE4FC7.4070106@volny.cz> <1174297007.3035.48.camel@greebo> <1174297898.3667.1.camel@mccallum.corsepiu.local> <1174299192.3035.59.camel@greebo> Message-ID: <1174300942.3667.18.camel@mccallum.corsepiu.local> On Mon, 2007-03-19 at 11:13 +0100, Alexander Larsson wrote: > On Mon, 2007-03-19 at 10:51 +0100, Ralf Corsepius wrote: > > > > It very much does. All applications using the gtk file selector will > > > have some default folders as file selector bookmars, and *all* > > > applications get translated filenames for common directories. > > > > And all other applications, such as gui-less apps will be broken. > > How are they broken? The only thing I can see that is possible to break > is if some application hardcodes ~/Desktop. Well, how is your local backup script to collect all music files from ~/Musique? > Of course, thats already > broken since gnome has a config option to use $HOME as desktop and KDE > has a general config option for where to put the desktop directory. > > Related to this: Explain who all this is supposed without any > > login-manager (plain su -l without running any GUI) > > If you don't log in through a gui then xdg-user-dirs-update won't be run > (unless you manually run it). You've got it => Your i18n won't take effect. Non-GUI logins will have to cope with random side-effects of former logins. Also did you consider simulaneously accessing dirs with different locales, e.g. network'ed (automounted) homes? The same $HOME can appear in different locales simultaneously from different machines. > This is not a problem How this? > and shouldn't affect > anything (except you won't get the default dirs if you never run it). > Everything should keep working as it is right now. It will not - Nowadays one can write command-line scripts with hard coded/deterministic directory names to process the files in "Desktop" or "Pictures", "Music", "Documents", "Mail". With your approach this won't be possible anymore. Ralf From alexl at redhat.com Mon Mar 19 10:42:43 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 11:42:43 +0100 Subject: User directories integration - request for help In-Reply-To: <9622.192.54.193.51.1174300515.squirrel@rousalka.dyndns.org> References: <1173953610.10024.132.camel@greebo> <1174161785.3429.16.camel@localhost.localdomain> <1174297330.3035.53.camel@greebo> <9622.192.54.193.51.1174300515.squirrel@rousalka.dyndns.org> Message-ID: <1174300963.3035.86.camel@greebo> On Mon, 2007-03-19 at 11:35 +0100, Nicolas Mailhot wrote: > Le Lun 19 mars 2007 10:42, Alexander Larsson a ?crit : > > So, I don't think this is a better solution. (As I didn't when it was > > proposed in the discussions leading to the design of xdg-user-dirs.) > > And I can (and do) disagree with you That is absolutely fine. People have been disagreeing on this for over five years. There are many many proposals that all work. However, we can really only have one implementation. I picked the one I though was best, given a balance of all the input. None is "right" in the optimal sense, as all proposals have issues. I think having something actually implemented and used is better than discussing for another five years, even if some people think that another approach would be better (that would be true whatever approach we picked after all). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a short-sighted Republican astronaut haunted by memories of 'Nam. She's a tortured junkie magician's assistant with a knack for trouble. They fight crime! From nicolas.mailhot at laposte.net Mon Mar 19 10:45:33 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 11:45:33 +0100 (CET) Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE668B.8000904@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> Message-ID: <64629.192.54.193.51.1174301133.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 11:31, Rahul Sundaram a ?crit : > Nicolas Mailhot wrote: >> Le Lun 19 mars 2007 10:51, Rahul Sundaram a ?crit : >> >>> Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. Can't see a reason >>> to >>> enable these by default. >> >> cpuspeed, mdmonitor and ntpd are no more extra than NetworkManager > > Yes, They are. For a desktop. A Live CD is targeted at the desktop. > Nothing else. Bzzt. Lots of things on the desktop require a working clock (try to unsync yours and watch havoc breaking loose), cpuspeed is a requirement on laptops and nice-to-have on every recent desktop system (a hot mobo is a loud mobo, people like hearing their ogg files too), and killing mdadm removes access to parts of the disks (md is used on desktops, and live cds are used on systems with a linux version on disc) > here are side effects for all daemons - slower performance, > potential higher security risks etc. The less the better. The same arguments applies to every app exposed to external files, and you'll win more killing bad evo/firefox/openoffice code. (also all the GUI-oriented daemons you "forget" in your analysis have youth problems the daemons you target have not). Granted it's easier to kill some daemons than work of GUI bloat, but you're rewarding bad intermingled code and penalising small dedicated audited components there. -- Nicolas Mailhot From laroche at redhat.com Mon Mar 19 10:46:12 2007 From: laroche at redhat.com (Florian La Roche) Date: Mon, 19 Mar 2007 11:46:12 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE668B.8000904@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> Message-ID: <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> On Mon, Mar 19, 2007 at 04:01:39PM +0530, Rahul Sundaram wrote: > Nicolas Mailhot wrote: > >Le Lun 19 mars 2007 10:51, Rahul Sundaram a ?crit : > > > >>Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. Can't see a reason to > >>enable these by default. > > > >cpuspeed, mdmonitor and ntpd are no more extra than NetworkManager > > Yes, They are. For a desktop. A Live CD is targeted at the desktop. > Nothing else. We should really target a Live-DVD instead of a Live-CD. regards, Florian La Roche From pertusus at free.fr Mon Mar 19 10:40:39 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 19 Mar 2007 11:40:39 +0100 Subject: User directories integration - request for help In-Reply-To: <1174300510.3035.79.camel@greebo> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> <20070316124530.GD2923@free.fr> <1174295987.3035.33.camel@greebo> <20070319095349.GA3186@free.fr> <1174300510.3035.79.camel@greebo> Message-ID: <20070319104039.GC3186@free.fr> On Mon, Mar 19, 2007 at 11:35:10AM +0100, Alexander Larsson wrote: > > I don't think this is largely different from creating them at login. > Many dirs will be created at first login anyway (Desktop, Templates, > maybe Public), and others will be created as you go. Seems very similar Why should those dirs be created? > to the create-at-login approach except the code needs to be duplicated > all over the place and the homedirectory is slowly modified over time > instead of just once. It is very different for the user who want to keep control over their desktop. > > Unexperienced users don't want something specific. Except if you think > > that what unexperienced users want is what is in windows. > > Ah, the old "you just want us to be windows" argument. Lets just say we > disagree on this point without having to fall into name-calling. It is not 'name-calling'. My (limited) experience is that unexperienced users that haven't used anything are not biased toward anything, while those who have ever used something are biased against that something, how bad it could be. > Its pretty bad to create visible folders in the homedir that expose the > internals of an applications. However, things are different if you're > designing an application for the explicit purpose of creating visible > directories in the home directory. We can of course disagree on whether > such an application should exist or not... The problem mis not with creating visible directories in the home directory, but about creating them automatically. > > How can you do 'Directories specified in your config file that has been > > removed will be changed in the config file to point to $HOME.' without > > something magic? > > While we scan the list of the users already configured directories we > call stat() to see if they are stale, if so we reset it to something > that is not stale. How is an if and a stat "magic". How do you distinguish between new directory to be created and directory removed? Because a removed directory ios already in the config file, and a directory to be added is not in the config file? -- Pat From jwboyer at jdub.homelinux.org Mon Mar 19 10:45:48 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 19 Mar 2007 05:45:48 -0500 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE668B.8000904@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> Message-ID: <1174301148.2977.21.camel@vader.jdub.homelinux.org> On Mon, 2007-03-19 at 16:01 +0530, Rahul Sundaram wrote: > Nicolas Mailhot wrote: > > Le Lun 19 mars 2007 10:51, Rahul Sundaram a ?crit : > > > >> Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. Can't see a reason to > >> enable these by default. > > > > cpuspeed, mdmonitor and ntpd are no more extra than NetworkManager > > Yes, They are. For a desktop. A Live CD is targeted at the desktop. > Nothing else. cpuspeed is very useful, especially in the case of a laptop which several people use as their desktop. Your narrow definition of a desktop is perhaps too limiting. josh From sundaram at fedoraproject.org Mon Mar 19 10:48:58 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 16:18:58 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> Message-ID: <45FE6A9A.6080505@fedoraproject.org> Florian La Roche wrote: > On Mon, Mar 19, 2007 at 04:01:39PM +0530, Rahul Sundaram wrote: >> Nicolas Mailhot wrote: >>> Le Lun 19 mars 2007 10:51, Rahul Sundaram a ?crit : >>> >>>> Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. Can't see a reason to >>>> enable these by default. >>> cpuspeed, mdmonitor and ntpd are no more extra than NetworkManager >> Yes, They are. For a desktop. A Live CD is targeted at the desktop. >> Nothing else. > > > We should really target a Live-DVD instead of a Live-CD. DVD drives are way too costly in many regions. We still need a Live CD. Rahul From fedora at leemhuis.info Mon Mar 19 10:51:30 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Mar 2007 11:51:30 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE6056.9080004@linux-kernel.at> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> Message-ID: <45FE6B32.2000905@leemhuis.info> On 19.03.2007 11:05, Oliver Falk wrote: > On 03/19/2007 10:51 AM, Rahul Sundaram wrote: >> Extra - cpuspeed. > This one makes sense on laptops, doesn't it? It makes also much sense on Desktops -- nearly all modern Desktop-CPUs and also a lot of Server-CPUs support some kind power-saving features. It IMHO would be wise to use them so save power and keeps systems cool (and quiet -- I don't want to hear people saying "my System is much louder when I use the Fedora Live-CD"). CU thl From sundaram at fedoraproject.org Mon Mar 19 10:52:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 16:22:24 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <64629.192.54.193.51.1174301133.squirrel@rousalka.dyndns.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <64629.192.54.193.51.1174301133.squirrel@rousalka.dyndns.org> Message-ID: <45FE6B68.6040307@fedoraproject.org> Nicolas Mailhot wrote: > Le Lun 19 mars 2007 11:31, Rahul Sundaram a ?crit : >> Nicolas Mailhot wrote: >>> Le Lun 19 mars 2007 10:51, Rahul Sundaram a ?crit : >>> >>>> Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. Can't see a reason >>>> to >>>> enable these by default. >>> cpuspeed, mdmonitor and ntpd are no more extra than NetworkManager >> Yes, They are. For a desktop. A Live CD is targeted at the desktop. >> Nothing else. > > Bzzt. Lots of things on the desktop require a working clock (try to unsync > yours and watch havoc breaking loose) Working clock is a requirement. Not ntpd. There is a difference. , cpuspeed is a requirement on > laptops and nice-to-have on every recent desktop system (a hot mobo is a > loud mobo, people like hearing their ogg files too) They are not required to be enabled on every system. Only on laptops. , and killing mdadm > removes access to parts of the disks (md is used on desktops, and live cds > are used on systems with a linux version on disc) Remember that Live CD dont support upgrades. You can only target first time user's with them as of now. Rahul From pertusus at free.fr Mon Mar 19 10:45:51 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 19 Mar 2007 11:45:51 +0100 Subject: User directories integration - request for help In-Reply-To: <1174300963.3035.86.camel@greebo> References: <1173953610.10024.132.camel@greebo> <1174161785.3429.16.camel@localhost.localdomain> <1174297330.3035.53.camel@greebo> <9622.192.54.193.51.1174300515.squirrel@rousalka.dyndns.org> <1174300963.3035.86.camel@greebo> Message-ID: <20070319104551.GD3186@free.fr> On Mon, Mar 19, 2007 at 11:42:43AM +0100, Alexander Larsson wrote: > > That is absolutely fine. People have been disagreeing on this for over > five years. There are many many proposals that all work. However, we can > really only have one implementation. I picked the one I though was best, > given a balance of all the input. None is "right" in the optimal sense, > as all proposals have issues. I think having something actually > implemented and used is better than discussing for another five years, > even if some people think that another approach would be better (that > would be true whatever approach we picked after all). But why chose the solution that upsets those who want to keep control over their home directories, and satisfy those who want automatic setup of directories in user dirs? -- Pat From oliver at linux-kernel.at Mon Mar 19 10:56:02 2007 From: oliver at linux-kernel.at (Oliver Falk) Date: Mon, 19 Mar 2007 11:56:02 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE6B32.2000905@leemhuis.info> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> Message-ID: <45FE6C42.30208@linux-kernel.at> On 03/19/2007 11:51 AM, Thorsten Leemhuis wrote: > On 19.03.2007 11:05, Oliver Falk wrote: >> On 03/19/2007 10:51 AM, Rahul Sundaram wrote: >>> Extra - cpuspeed. >> This one makes sense on laptops, doesn't it? > > It makes also much sense on Desktops -- nearly all modern Desktop-CPUs > and also a lot of Server-CPUs support some kind power-saving features. > It IMHO would be wise to use them so save power and keeps systems cool > (and quiet -- I don't want to hear people saying "my System is much > louder when I use the Fedora Live-CD"). Yes, OK, but installing/starting cpuspeed on a computer that actually doesn't support it doesn't make sense. Right? :-) -of From rc040203 at freenet.de Mon Mar 19 10:56:18 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Mar 2007 11:56:18 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE6797.2010307@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <1174300182.3667.5.camel@mccallum.corsepiu.local> <45FE6797.2010307@fedoraproject.org> Message-ID: <1174301778.3667.26.camel@mccallum.corsepiu.local> On Mon, 2007-03-19 at 16:06 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > On Mon, 2007-03-19 at 15:21 +0530, Rahul Sundaram wrote: > > >> Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. > > No portmap => no nis, no nfs, no rpc. > > Again, This live CD is meant for a desktop. You can always enable it if > you need it. "desktop" doesn't mean "standalone". nfs, nis, rpc are used by desktops once they integrate into a network. > >> Default? - Possibly NetworkManagerDispatcher since > >> NetworkManager is enabled by default > > Disable this. It has never worked for me anywhere and is the first > > daemon I disable after FC installs. > > You will have to look beyond just your personal consideration. It works > for me. Bug reports? If there was something to report, I would have done so. When ever I enable Network Manager, for me, absolutely NOTHING network-related works. I.e. NetworkManager for me works SO POOR, I can't even test nor report bugs (It is seemingly screwing up on several things at the same time. Amongst them DHCP, NIS, DNS and network interfaces - I even saw network device names change at run-time). > > You are scratching on the surface of a weak spot in Fedora. > > I checked all the daemons and listing the ones find I found > unnecessarily enabled for a desktop. That's why I say "weak spot" - There is no "one-fits-all set of daemons to enable/disable" - Each situation is different, but there is hardly any means to customize an installation for an individual situation during installation with Fedora. Ralf From rc040203 at freenet.de Mon Mar 19 10:59:57 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Mar 2007 11:59:57 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE6A9A.6080505@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> Message-ID: <1174301997.3667.30.camel@mccallum.corsepiu.local> On Mon, 2007-03-19 at 16:18 +0530, Rahul Sundaram wrote: > Florian La Roche wrote: > > On Mon, Mar 19, 2007 at 04:01:39PM +0530, Rahul Sundaram wrote: > >> Nicolas Mailhot wrote: > >>> Le Lun 19 mars 2007 10:51, Rahul Sundaram a ?crit : > >>> > >>>> Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. Can't see a reason to > >>>> enable these by default. > >>> cpuspeed, mdmonitor and ntpd are no more extra than NetworkManager > >> Yes, They are. For a desktop. A Live CD is targeted at the desktop. > >> Nothing else. > > > > > > We should really target a Live-DVD instead of a Live-CD. > > DVD drives are way too costly in many regions. We still need a Live CD. Pardon, but I would not recommend Fedora to anybody who doesn't have broadband access. Those who have broadband access also very likely have a DVD drive. Also: Do you know how Ubuntu and Knoppix are being shipped in Germany. As free add-ons to magazines. Ralf From alexl at redhat.com Mon Mar 19 11:01:11 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 12:01:11 +0100 Subject: User directories integration - request for help In-Reply-To: <1174300942.3667.18.camel@mccallum.corsepiu.local> References: <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> <20070316123536.GC2923@free.fr> <1174294196.3035.8.camel@greebo> <45FE4FC7.4070106@volny.cz> <1174297007.3035.48.camel@greebo> <1174297898.3667.1.camel@mccallum.corsepiu.local> <1174299192.3035.59.camel@greebo> <1174300942.3667.18.camel@mccallum.corsepiu.local> Message-ID: <1174302071.3035.104.camel@greebo> On Mon, 2007-03-19 at 11:42 +0100, Ralf Corsepius wrote: > On Mon, 2007-03-19 at 11:13 +0100, Alexander Larsson wrote: > > On Mon, 2007-03-19 at 10:51 +0100, Ralf Corsepius wrote: > > > > > > It very much does. All applications using the gtk file selector will > > > > have some default folders as file selector bookmars, and *all* > > > > applications get translated filenames for common directories. > > > > > > And all other applications, such as gui-less apps will be broken. > > > > How are they broken? The only thing I can see that is possible to break > > is if some application hardcodes ~/Desktop. > Well, how is your local backup script to collect all music files from > ~/Musique? If you just want to backup the directory named "Musique" then it will work fine just as before. If you want a special sort of backup script that backs up the special MUSIC directory it would go: test -f ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs && source ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs tar czvf /tmp/music.tar.gz ${XDG_MUSIC_DIR} Thats a sort of weird backup script to have though. Backup scripts are typically personalized for your homedir, and can hardcode whatever structure you use. > > > Related to this: Explain who all this is supposed without any > > > login-manager (plain su -l without running any GUI) > > > > If you don't log in through a gui then xdg-user-dirs-update won't be run > > (unless you manually run it). > You've got it => Your i18n won't take effect. Non-GUI logins will have > to cope with random side-effects of former logins. What do you mean. Either you have previously ran it and there will be i18n directories that we can correctly find, or there will be no special directories. Things should work fine without any special directories availible. > Also did you consider simulaneously accessing dirs with different > locales, e.g. network'ed (automounted) homes? Yes, i did. You will have to pick one translation for your folder name. This is the same as any other non-special folder names in your homedirectory. You will have to select "don't ask me this again" once you've decided which locale you want. > > and shouldn't affect > > anything (except you won't get the default dirs if you never run it). > > Everything should keep working as it is right now. > > It will not - Nowadays one can write command-line scripts with hard > coded/deterministic directory names to process the files in "Desktop" or > "Pictures", "Music", "Documents", "Mail". > > With your approach this won't be possible anymore. Anyone can currently write a command line script that hardcodes ~/Documents, and they could in the past too. It will be broken now as it was in the past. Users can do whatever they want with their homedirectory and there is no guarantee that there will be a ~/Documents directory (and there hasn't ever been one in Fedora). Even for ~/Desktop which exist in some fedora users homedir it is not right, as there is a home-is-desktop gconf key for gnome and a kde config option for the desktop directory location. But, this is not my main disagreement. My main disagreement is on the idea that it is more important that you need two lines less code in some script than that the users personal files should be in a language they can understand. And translation of the filenames in the UI will *never* be complete. There will always be 3rd party applications that don't translate the names, and even in a translated desktop apps we need to show the english name whenever we display a pathname. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a suave shark-wrestling astronaut with no name. She's a violent out-of-work pearl diver who hides her beauty behind a pair of thick-framed spectacles. They fight crime! From gajownik at gmail.com Mon Mar 19 11:01:09 2007 From: gajownik at gmail.com (Dawid Gajownik) Date: Mon, 19 Mar 2007 12:01:09 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE5D39.7020002@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> Message-ID: <9aa7c6490703190401v626f73c3iff099cb208ddf4b8@mail.gmail.com> On 3/19/07, Rahul Sundaram wrote: > Hardware specific - Bluetooth (along with hidd), cups (FC6 even had > smartcard daemon by default). Should check and enable on demand https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222315 From alexl at redhat.com Mon Mar 19 11:05:58 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 12:05:58 +0100 Subject: User directories integration - request for help In-Reply-To: <20070319104039.GC3186@free.fr> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> <20070316124530.GD2923@free.fr> <1174295987.3035.33.camel@greebo> <20070319095349.GA3186@free.fr> <1174300510.3035.79.camel@greebo> <20070319104039.GC3186@free.fr> Message-ID: <1174302358.3035.110.camel@greebo> On Mon, 2007-03-19 at 11:40 +0100, Patrice Dumas wrote: > On Mon, Mar 19, 2007 at 11:35:10AM +0100, Alexander Larsson wrote: > > > > I don't think this is largely different from creating them at login. > > Many dirs will be created at first login anyway (Desktop, Templates, > > maybe Public), and others will be created as you go. Seems very similar > > Why should those dirs be created? Because they would be created on use, and they are used at login. > > to the create-at-login approach except the code needs to be duplicated > > all over the place and the homedirectory is slowly modified over time > > instead of just once. > > It is very different for the user who want to keep control over their > desktop. If you want to keep control of your desktop its better to have them all initially and then clean them up to how you want them all at the same time. I.e. log in, remove or rename dirs, keep on with life. In a dynamic model you constantly have to keep a watch for newly created directories. > > While we scan the list of the users already configured directories we > > call stat() to see if they are stale, if so we reset it to something > > that is not stale. How is an if and a stat "magic". > > How do you distinguish between new directory to be created and directory > removed? Because a removed directory ios already in the config file, > and a directory to be added is not in the config file? Yes. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a suave white trash firefighter from the 'hood. She's a time-travelling red-headed mechanic in the wrong place at the wrong time. They fight crime! From alan at redhat.com Mon Mar 19 11:08:22 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 19 Mar 2007 07:08:22 -0400 Subject: User directories integration - request for help In-Reply-To: <1174295090.3035.18.camel@greebo> References: <1173953610.10024.132.camel@greebo> <1174107004.2691.31.camel@zelda.fubar.dk> <1174107776.4680.259.camel@mccallum.corsepiu.local> <200703170146.15455.lightsolphoenix@gmail.com> <1174111073.4680.275.camel@mccallum.corsepiu.local> <20070317140524.GD8832@devserv.devel.redhat.com> <1174141274.26640.8.camel@willson> <1174295090.3035.18.camel@greebo> Message-ID: <20070319110822.GD24026@devserv.devel.redhat.com> On Mon, Mar 19, 2007 at 10:04:50AM +0100, Alexander Larsson wrote: > To handle the case where you initially log in in English before later > swtiching to your final locale we do however ask you on login if you > want to switch to the new directory names. Just click on "no" (which is > the default) and select "never ask me this again". What happens if the objects already exist when you first login to a new Gnome with this feature btw ? Say if I have a named pipe called "Music" ? From alexl at redhat.com Mon Mar 19 11:12:45 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 12:12:45 +0100 Subject: User directories integration - request for help In-Reply-To: <20070319104551.GD3186@free.fr> References: <1173953610.10024.132.camel@greebo> <1174161785.3429.16.camel@localhost.localdomain> <1174297330.3035.53.camel@greebo> <9622.192.54.193.51.1174300515.squirrel@rousalka.dyndns.org> <1174300963.3035.86.camel@greebo> <20070319104551.GD3186@free.fr> Message-ID: <1174302765.3035.117.camel@greebo> On Mon, 2007-03-19 at 11:45 +0100, Patrice Dumas wrote: > On Mon, Mar 19, 2007 at 11:42:43AM +0100, Alexander Larsson wrote: > > > > That is absolutely fine. People have been disagreeing on this for over > > five years. There are many many proposals that all work. However, we can > > really only have one implementation. I picked the one I though was best, > > given a balance of all the input. None is "right" in the optimal sense, > > as all proposals have issues. I think having something actually > > implemented and used is better than discussing for another five years, > > even if some people think that another approach would be better (that > > would be true whatever approach we picked after all). > > But why chose the solution that upsets those who want to keep control > over their home directories, and satisfy those who want automatic setup of > directories in user dirs? Its because the user who wants to keep control of his homedirectory is extremely likely to be an experienced user who can easily handle customizing or removing these directories. However for an unexperienced user for whom it would be useful to have some initial folder structure it would be unlikely that they even found the feature if it had to be enabled manually. One thing i can't understand is how so many people who like to keep control of their homedir are so attached to the english-on-disk model, because in that model you can't ever set things up how you'd like them. You're forced into a static hierarchy. At least my solution lets you set things up how you want it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a one-legged albino paramedic gone bad. She's a ditzy green-skinned mercenary with the power to see death. They fight crime! From alan at redhat.com Mon Mar 19 11:13:16 2007 From: alan at redhat.com (Alan Cox) Date: Mon, 19 Mar 2007 07:13:16 -0400 Subject: User directories integration - request for help In-Reply-To: <20070319104039.GC3186@free.fr> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> <20070316124530.GD2923@free.fr> <1174295987.3035.33.camel@greebo> <20070319095349.GA3186@free.fr> <1174300510.3035.79.camel@greebo> <20070319104039.GC3186@free.fr> Message-ID: <20070319111316.GE24026@devserv.devel.redhat.com> On Mon, Mar 19, 2007 at 11:40:39AM +0100, Patrice Dumas wrote: > > Many dirs will be created at first login anyway (Desktop, Templates, > > maybe Public), and others will be created as you go. Seems very similar > > Why should those dirs be created? To make life feel better for new users, to give them default locations for things like downloads that are best kept seperated. And for a new user who doesn't like them coming to an otherwise empty desktop it is trivial to remove them if they don't like it, or rename them. Doing it to an existing user is I guess more controversial. From sundaram at fedoraproject.org Mon Mar 19 11:16:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 16:46:12 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174301778.3667.26.camel@mccallum.corsepiu.local> References: <45FE5D39.7020002@fedoraproject.org> <1174300182.3667.5.camel@mccallum.corsepiu.local> <45FE6797.2010307@fedoraproject.org> <1174301778.3667.26.camel@mccallum.corsepiu.local> Message-ID: <45FE70FC.4000100@fedoraproject.org> Ralf Corsepius wrote: > "desktop" doesn't mean "standalone". For the Live CD that's mostly the use case. Live CD has very limited space. So they have to very much targeted towards a particular set of users. See the package list. > nfs, nis, rpc are used by desktops once they integrate into a network. Those folks can integrating it on the network can enable them. There is no reason to enable them by default. > If there was something to report, I would have done so. > > When ever I enable Network Manager, for me, absolutely NOTHING > network-related works. I.e. NetworkManager for me works SO POOR, I can't > even test nor report bugs (It is seemingly screwing up on several things > at the same time. Amongst them DHCP, NIS, DNS and network interfaces - I > even saw network device names change at run-time). You said it doesn't work for you. If you consider that a bug then you should file a bug report on a best effort basis. Developers can always ask for more information if they need it to solve the problem. If there is no bug report there cannot be even a attempt made to resolve it. Asking it to be disabled by default just because it does not work for you with no bug reports is not very reasonable. Sorry. > That's why I say "weak spot" - There is no "one-fits-all set of daemons > to enable/disable" - Each situation is different, but there is hardly > any means to customize an installation for an individual situation > during installation with Fedora. Anaconda, Kickstart, targeted and custom spins enable you to customize Fedora for individual situations. Don't they? We aren't talking about what daemons can be enabled for Fedora in general which then is indeed very hard to define but about the GNOME based Live CD for Fedora 7 Test 2 release. Rahul From pertusus at free.fr Mon Mar 19 11:09:00 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 19 Mar 2007 12:09:00 +0100 Subject: User directories integration - request for help In-Reply-To: <20070319111316.GE24026@devserv.devel.redhat.com> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> <20070316124530.GD2923@free.fr> <1174295987.3035.33.camel@greebo> <20070319095349.GA3186@free.fr> <1174300510.3035.79.camel@greebo> <20070319104039.GC3186@free.fr> <20070319111316.GE24026@devserv.devel.redhat.com> Message-ID: <20070319110900.GE3186@free.fr> On Mon, Mar 19, 2007 at 07:13:16AM -0400, Alan Cox wrote: > On Mon, Mar 19, 2007 at 11:40:39AM +0100, Patrice Dumas wrote: > > > Many dirs will be created at first login anyway (Desktop, Templates, > > > maybe Public), and others will be created as you go. Seems very similar > > > > Why should those dirs be created? > > To make life feel better for new users, to give them default locations for > things like downloads that are best kept seperated. And for a new user who > doesn't like them coming to an otherwise empty desktop it is trivial to > remove them if they don't like it, or rename them. > > Doing it to an existing user is I guess more controversial. But determining new versus existing users is not easy, because there isn't one way to login. -- Pat From sundaram at fedoraproject.org Mon Mar 19 11:18:03 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 16:48:03 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174301997.3667.30.camel@mccallum.corsepiu.local> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> Message-ID: <45FE716B.1070107@fedoraproject.org> Ralf Corsepius wrote: > On Mon, 2007-03-19 at 16:18 +0530, Rahul Sundaram wrote: >> Florian La Roche wrote: >>> On Mon, Mar 19, 2007 at 04:01:39PM +0530, Rahul Sundaram wrote: >>>> Nicolas Mailhot wrote: >>>>> Le Lun 19 mars 2007 10:51, Rahul Sundaram a ?crit : >>>>> >>>>>> Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. Can't see a reason to >>>>>> enable these by default. >>>>> cpuspeed, mdmonitor and ntpd are no more extra than NetworkManager >>>> Yes, They are. For a desktop. A Live CD is targeted at the desktop. >>>> Nothing else. >>> >>> We should really target a Live-DVD instead of a Live-CD. >> DVD drives are way too costly in many regions. We still need a Live CD. > > Pardon, but I would not recommend Fedora to anybody who doesn't have > broadband access. Those who have broadband access also very likely have > a DVD drive Can you specify the factors for your recommendation? Live CD's can be installed to a hard disk and works out of the box. That doesnt require any broadband connection. Broad connection does not automatically translate into systems with DVD. Many work places have restrictions on removable disk access (No CD/DVD drivers, USB ports locked etc). > Also: Do you know how Ubuntu and Knoppix are being shipped in Germany. > As free add-ons to magazines Fedora is included in magazines all over the world too. Does not change the fact that Live CD are still very much a good thing for several end users and for promotional events. Rahul From alexl at redhat.com Mon Mar 19 11:19:08 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 12:19:08 +0100 Subject: User directories integration - request for help In-Reply-To: <20070319110822.GD24026@devserv.devel.redhat.com> References: <1173953610.10024.132.camel@greebo> <1174107004.2691.31.camel@zelda.fubar.dk> <1174107776.4680.259.camel@mccallum.corsepiu.local> <200703170146.15455.lightsolphoenix@gmail.com> <1174111073.4680.275.camel@mccallum.corsepiu.local> <20070317140524.GD8832@devserv.devel.redhat.com> <1174141274.26640.8.camel@willson> <1174295090.3035.18.camel@greebo> <20070319110822.GD24026@devserv.devel.redhat.com> Message-ID: <1174303148.3035.122.camel@greebo> On Mon, 2007-03-19 at 07:08 -0400, Alan Cox wrote: > On Mon, Mar 19, 2007 at 10:04:50AM +0100, Alexander Larsson wrote: > > To handle the case where you initially log in in English before later > > swtiching to your final locale we do however ask you on login if you > > want to switch to the new directory names. Just click on "no" (which is > > the default) and select "never ask me this again". > > What happens if the objects already exist when you first login to a new > Gnome with this feature btw ? Say if I have a named pipe called "Music" ? mkdir will fail and we won't set up that kind of directory in the user config file. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an impetuous alcoholic farmboy with a passion for fast cars. She's a manipulative Buddhist widow fleeing from a Satanic cult. They fight crime! From pertusus at free.fr Mon Mar 19 11:13:02 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 19 Mar 2007 12:13:02 +0100 Subject: User directories integration - request for help In-Reply-To: <1174302765.3035.117.camel@greebo> References: <1173953610.10024.132.camel@greebo> <1174161785.3429.16.camel@localhost.localdomain> <1174297330.3035.53.camel@greebo> <9622.192.54.193.51.1174300515.squirrel@rousalka.dyndns.org> <1174300963.3035.86.camel@greebo> <20070319104551.GD3186@free.fr> <1174302765.3035.117.camel@greebo> Message-ID: <20070319111302.GF3186@free.fr> On Mon, Mar 19, 2007 at 12:12:45PM +0100, Alexander Larsson wrote: > > Its because the user who wants to keep control of his homedirectory is > extremely likely to be an experienced user who can easily handle > customizing or removing these directories. However for an unexperienced Not necessarily. Now I know about this because I read on devel list, but imagine I wouldn't, what would have happened is the day I start gnomme instead of fluxbox I would have those directories created. And I wouldn't have known if I was likely to screw things if I remove them. > user for whom it would be useful to have some initial folder structure > it would be unlikely that they even found the feature if it had to be > enabled manually. I am not advocating doing things manually, but through file-selector defaults. > One thing i can't understand is how so many people who like to keep > control of their homedir are so attached to the english-on-disk model, That's not my case, though. I don't have any idea on that subject. > because in that model you can't ever set things up how you'd like them. > You're forced into a static hierarchy. At least my solution lets you set > things up how you want it. At the expense of having directories created at the first login in GNOME. -- Pat From fedora at leemhuis.info Mon Mar 19 11:22:21 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Mar 2007 12:22:21 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE6C42.30208@linux-kernel.at> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> Message-ID: <45FE726D.6000305@leemhuis.info> On 19.03.2007 11:56, Oliver Falk wrote: > On 03/19/2007 11:51 AM, Thorsten Leemhuis wrote: >> On 19.03.2007 11:05, Oliver Falk wrote: >>> On 03/19/2007 10:51 AM, Rahul Sundaram wrote: >>>> Extra - cpuspeed. >>> This one makes sense on laptops, doesn't it? >> It makes also much sense on Desktops -- nearly all modern Desktop-CPUs >> and also a lot of Server-CPUs support some kind power-saving features. >> It IMHO would be wise to use them so save power and keeps systems cool >> (and quiet -- I don't want to hear people saying "my System is much >> louder when I use the Fedora Live-CD"). > Yes, OK, but installing/starting cpuspeed on a computer that actually > doesn't support it doesn't make sense. Right? :-) Installing IMHO make sense, as people might install a CPU with power-saving capabilities later (or they simple enable it in the BIOS-Setup). Stating the daemon by default IMHO makes sense, too, but it probably should be possible by the start script to quickly notice if cpufreq support is available and abort cleanly if not. CU thl From pertusus at free.fr Mon Mar 19 11:17:04 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 19 Mar 2007 12:17:04 +0100 Subject: User directories integration - request for help In-Reply-To: <1174302358.3035.110.camel@greebo> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> <20070316124530.GD2923@free.fr> <1174295987.3035.33.camel@greebo> <20070319095349.GA3186@free.fr> <1174300510.3035.79.camel@greebo> <20070319104039.GC3186@free.fr> <1174302358.3035.110.camel@greebo> Message-ID: <20070319111704.GG3186@free.fr> On Mon, Mar 19, 2007 at 12:05:58PM +0100, Alexander Larsson wrote: > > Why should those dirs be created? > > Because they would be created on use, and they are used at login. And these are visible directories? That's bad in my opinion. > If you want to keep control of your desktop its better to have them all > initially and then clean them up to how you want them all at the same > time. I.e. log in, remove or rename dirs, keep on with life. In a > dynamic model you constantly have to keep a watch for newly created > directories. My view is that nothing should be created automatically. No need to watch anything if I can always say no to a new directory creation when I click on a bookmark or want to save something. -- Pat From pertusus at free.fr Mon Mar 19 11:18:34 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 19 Mar 2007 12:18:34 +0100 Subject: User directories integration - request for help In-Reply-To: <1174295987.3035.33.camel@greebo> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> <20070316124530.GD2923@free.fr> <1174295987.3035.33.camel@greebo> Message-ID: <20070319111834.GH3186@free.fr> On Mon, Mar 19, 2007 at 10:19:47AM +0100, Alexander Larsson wrote: > > That would limit the use of this to "default fileselector directory" for > applications that have that hardcoded. There are other uses too, like > default bookmarks (in file manager, file selector, etc). As I said in another mail, the directory should be created when the user click on it, with a popup asking for confirmation, set to yes for the default. That way nothing is automatic. -- Pat From benny+usenet at amorsen.dk Mon Mar 19 11:29:35 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 19 Mar 2007 12:29:35 +0100 Subject: too many deamons by default - F7 test 2 live cd References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> Message-ID: >>>>> "JB" == Josh Boyer writes: JB> cpuspeed is very useful, especially in the case of a laptop which JB> several people use as their desktop. Your narrow definition of a JB> desktop is perhaps too limiting. cpuspeed really isn't optional on modern desktop machines either. Rahul Sundaram may have lots of machines with fixed clockspeeds, but that is no reason to not support newer stuff. Desktops are in the minority anyway, a live CD/DVD needs to be useful on laptops. /Benny From axel.azerty at laposte.net Mon Mar 19 11:33:12 2007 From: axel.azerty at laposte.net (Axel) Date: Mon, 19 Mar 2007 12:33:12 +0100 Subject: User directories integration - request for help In-Reply-To: <20070319111834.GH3186@free.fr> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> <20070316124530.GD2923@free.fr> <1174295987.3035.33.camel@greebo> <20070319111834.GH3186@free.fr> Message-ID: <45FE74F8.6050909@laposte.net> Patrice Dumas a ?crit : > On Mon, Mar 19, 2007 at 10:19:47AM +0100, Alexander Larsson wrote: > >> That would limit the use of this to "default fileselector directory" for >> applications that have that hardcoded. There are other uses too, like >> default bookmarks (in file manager, file selector, etc). >> > > As I said in another mail, the directory should be created when the user > click on it, with a popup asking for confirmation, set to yes for the > default. That way nothing is automatic. > Automatic creation doesn't sound bad to me. If the user doesn't like it, he can delete them, (I do this for some "My *" folders under Windows). The point that I found bad is the translation of the folder. What is planned ? To create translated directories ? If yes, the translation is in my opinion only needed for desktop applications, since a wide-user distribution isn't intended to be used with a terminal. Axel From alexl at redhat.com Mon Mar 19 11:49:40 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 12:49:40 +0100 Subject: User directories integration - request for help In-Reply-To: <20070319111302.GF3186@free.fr> References: <1173953610.10024.132.camel@greebo> <1174161785.3429.16.camel@localhost.localdomain> <1174297330.3035.53.camel@greebo> <9622.192.54.193.51.1174300515.squirrel@rousalka.dyndns.org> <1174300963.3035.86.camel@greebo> <20070319104551.GD3186@free.fr> <1174302765.3035.117.camel@greebo> <20070319111302.GF3186@free.fr> Message-ID: <1174304980.3035.132.camel@greebo> On Mon, 2007-03-19 at 12:13 +0100, Patrice Dumas wrote: > On Mon, Mar 19, 2007 at 12:12:45PM +0100, Alexander Larsson wrote: > > > > Its because the user who wants to keep control of his homedirectory is > > extremely likely to be an experienced user who can easily handle > > customizing or removing these directories. However for an unexperienced > > Not necessarily. Now I know about this because I read on devel list, > but imagine I wouldn't, what would have happened is the day I start > gnomme instead of fluxbox I would have those directories created. And > I wouldn't have known if I was likely to screw things if I remove them. I'm sure you would have tried just removing them, and that would have worked fine. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a scrappy soccer-playing filmmaker who dotes on his loving old ma. She's a disco-crazy French-Canadian mermaid with an evil twin sister. They fight crime! From nicolas.mailhot at laposte.net Mon Mar 19 11:58:41 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 12:58:41 +0100 (CET) Subject: User directories integration - request for help In-Reply-To: <20070319111316.GE24026@devserv.devel.redhat.com> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> <20070316124530.GD2923@free.fr> <1174295987.3035.33.camel@greebo> <20070319095349.GA3186@free.fr> <1174300510.3035.79.camel@greebo> <20070319104039.GC3186@free.fr> <20070319111316.GE24026@devserv.devel.redhat.com> Message-ID: <43773.192.54.193.51.1174305521.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 12:13, Alan Cox a ?crit : > On Mon, Mar 19, 2007 at 11:40:39AM +0100, Patrice Dumas wrote: >> > Many dirs will be created at first login anyway (Desktop, Templates, >> > maybe Public), and others will be created as you go. Seems very >> similar >> >> Why should those dirs be created? > > To make life feel better for new users, ... > And for a new user who > doesn't like them coming to an otherwise empty desktop it is trivial to > remove them if they don't like it, or rename them. That's the argument that was used to justify every app dumping its icon on the desktop. I have little doubt as soon as we start pre-creating stuff in home every app writer will feel justified in putting his helpful junk in there too. (bittorent is one example) Opt-in is better than opt-out. What's wrong with just-in-time creation ? If the user never start an app that could make use of those bits, what's the point of pre-creating them (nautilus is not a user, it's a desktop tool)? Do you really believe a user will create a huge music collection before launching totem/rhythmbox/sound-juicer once? That will only happen if he imports a huge pre-existing archive, which won't use the pre-created hierarchy anyway. -- Nicolas Mailhot From rdieter at math.unl.edu Mon Mar 19 11:55:56 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 19 Mar 2007 06:55:56 -0500 Subject: KDE-Live-CD: basic cd layout and localizations References: <20070314011000.5b0cbcb8@localhost.localdomain> Message-ID: Sebastian Vahl wrote: > I've created a new basic layout for the cd: > http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/KDELiveCD > The size on todays rawhide is about 667 MB. > Please tell me which package should be added or removed. Just found today you should add xine-lib-extras to the pkglist (for arts support). Hrm, in the meantime, will ping xine-lib maintainer to see if we can come up with something better/easier that doesn't pull in a whole bunch of other/extraneous deps. -- Rex From baris at teamforce.name.tr Mon Mar 19 11:49:57 2007 From: baris at teamforce.name.tr (Baris Cicek) Date: Mon, 19 Mar 2007 13:49:57 +0200 Subject: User directories integration - request for help In-Reply-To: <1174297330.3035.53.camel@greebo> References: <1173953610.10024.132.camel@greebo> <1174161785.3429.16.camel@localhost.localdomain> <1174297330.3035.53.camel@greebo> Message-ID: <1174304997.3428.37.camel@localhost.localdomain> On Mon, 2007-03-19 at 10:42 +0100, Alexander Larsson wrote: > On Sat, 2007-03-17 at 22:03 +0200, Baris Cicek wrote: > > I could not find where to post this, so sending over here. > > > > I changed Alex's xdg-user-dirs application to make it using symlinks > > instead of actual directories. Maybe it's something in vain but just > > wanted to put my solution into a prototype so as to be tested. (Maybe > > someone like it). > > > > Actually using symlinks give better handling of localization than using > > --force. It does not touch directories, so can be considered > > theoretically more secure. > > Each application will have to use readlink() to find the actual > directory to use. For sure you don't want have a filename like > ~/.desktop/file.txt to ever be seen by the user, so you must always > store the expanded form. Plus, you need to fallback on a file if > symlinks are not supported. Applications should look at "user-dirs.dirs", which points to symlink. If they won't, they were making big mistake at all, losing necessity of "user-dirs.dirs". Using static non-visible-english-on-disk would make life of packagers easy if dotted directories are standardized. Think about a tarball, created with full of pictures. Packager can use directories relative to ".pictures", and user can see it in his/her "~/Pictures" symlink. How could that possible with translated directories? Fallback is possible and can be implemented. However limiting people using native Linux technologies for those using (no offense) ad-hoc solutions like samba is not a way to go. People share their directories as well, so should we encourage not using symlinks anywhere? I know that's not what you mean. But if someone using Windows servers and using shares with samba, then s/he should bare it's constrains. Using samba as a domain server and file server won't have this problem of not supporting symlinks (samba shares support symlinks). > > So, I don't think this is a better solution. (As I didn't when it was > proposed in the discussions leading to the design of xdg-user-dirs.) I believe that strength of Linux is coming from it's ability to address needs/requests of most possible user base. That's why I wanted to put symlink approach into implementation as well. If we won't use coolness of symlinks for that, where should we use it? (only for library naming conventions?) > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, > Inc > alexl at redhat.com alla at lysator.liu.se > He's an underprivileged flyboy gentleman spy living undercover at Ringling > Bros. Circus. She's a foxy cigar-chomping hooker on her way to prison for a > murder she didn't commit. They fight crime! > From pertusus at free.fr Mon Mar 19 11:57:08 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 19 Mar 2007 12:57:08 +0100 Subject: User directories integration - request for help In-Reply-To: <1174304980.3035.132.camel@greebo> References: <1173953610.10024.132.camel@greebo> <1174161785.3429.16.camel@localhost.localdomain> <1174297330.3035.53.camel@greebo> <9622.192.54.193.51.1174300515.squirrel@rousalka.dyndns.org> <1174300963.3035.86.camel@greebo> <20070319104551.GD3186@free.fr> <1174302765.3035.117.camel@greebo> <20070319111302.GF3186@free.fr> <1174304980.3035.132.camel@greebo> Message-ID: <20070319115708.GJ3186@free.fr> On Mon, Mar 19, 2007 at 12:49:40PM +0100, Alexander Larsson wrote: > On Mon, 2007-03-19 at 12:13 +0100, Patrice Dumas wrote: > > On Mon, Mar 19, 2007 at 12:12:45PM +0100, Alexander Larsson wrote: > > > > > > Its because the user who wants to keep control of his homedirectory is > > > extremely likely to be an experienced user who can easily handle > > > customizing or removing these directories. However for an unexperienced > > > > Not necessarily. Now I know about this because I read on devel list, > > but imagine I wouldn't, what would have happened is the day I start > > gnomme instead of fluxbox I would have those directories created. And > > I wouldn't have known if I was likely to screw things if I remove them. > > I'm sure you would have tried just removing them, and that would have > worked fine. No I wouldn't. If something has been created automatically I fear a lot that something is relying on it to work properly. -- Pat From nicolas.mailhot at laposte.net Mon Mar 19 11:46:17 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 12:46:17 +0100 (CET) Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE6B68.6040307@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <64629.192.54.193.51.1174301133.squirrel@rousalka.dyndns.org> <45FE6B68.6040307@fedoraproject.org> Message-ID: <50377.192.54.193.51.1174304777.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 11:52, Rahul Sundaram a ?crit : > Nicolas Mailhot wrote: >> Le Lun 19 mars 2007 11:31, Rahul Sundaram a ?crit : >>> Nicolas Mailhot wrote: >>>> Le Lun 19 mars 2007 10:51, Rahul Sundaram a ?crit : >>>> >>>>> Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. Can't see a reason >>>>> to >>>>> enable these by default. >>>> cpuspeed, mdmonitor and ntpd are no more extra than NetworkManager >>> Yes, They are. For a desktop. A Live CD is targeted at the desktop. >>> Nothing else. >> >> Bzzt. Lots of things on the desktop require a working clock (try to >> unsync >> yours and watch havoc breaking loose) > > Working clock is a requirement. Not ntpd. There is a difference. I didn't wrote working I wrote synchronised > , cpuspeed is a requirement on >> laptops and nice-to-have on every recent desktop system (a hot mobo is a >> loud mobo, people like hearing their ogg files too) > > They are not required to be enabled on every system. Only on laptops. > > , and killing mdadm >> removes access to parts of the disks (md is used on desktops, and live >> cds >> are used on systems with a linux version on disc) > > Remember that Live CD dont support upgrades. You can only target first > time user's with them as of now. Users from others distros will want to check support in Fedora for the files they have on their local disc, which may be using md -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Mar 19 12:09:59 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 13:09:59 +0100 (CET) Subject: User directories integration - request for help In-Reply-To: <1174302071.3035.104.camel@greebo> References: <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> <20070316123536.GC2923@free.fr> <1174294196.3035.8.camel@greebo> <45FE4FC7.4070106@volny.cz> <1174297007.3035.48.camel@greebo> <1174297898.3667.1.camel@mccallum.corsepiu.local> <1174299192.3035.59.camel@greebo> <1174300942.3667.18.camel@mccallum.corsepiu.local> <1174302071.3035.104.camel@greebo> Message-ID: <35639.192.54.193.51.1174306199.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 12:01, Alexander Larsson a ?crit : > On Mon, 2007-03-19 at 11:42 +0100, Ralf Corsepius wrote: >> On Mon, 2007-03-19 at 11:13 +0100, Alexander Larsson wrote: >> > On Mon, 2007-03-19 at 10:51 +0100, Ralf Corsepius wrote: >> > >> > > > It very much does. All applications using the gtk file selector >> will >> > > > have some default folders as file selector bookmars, and *all* >> > > > applications get translated filenames for common directories. >> > > >> > > And all other applications, such as gui-less apps will be broken. >> > >> > How are they broken? The only thing I can see that is possible to >> break >> > is if some application hardcodes ~/Desktop. >> Well, how is your local backup script to collect all music files from >> ~/Musique? > > If you just want to backup the directory named "Musique" then it will > work fine just as before. If you want a special sort of backup script > that backs up the special MUSIC directory it would go: > > test -f ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs && source > ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs > tar czvf /tmp/music.tar.gz ${XDG_MUSIC_DIR} Add looping to handle multi-user setups, and you get the magnitude of problems to replicate a simple ls /home/*/.config/xdg-dir/music/ > Thats a sort of weird backup script to have though. Backup scripts are > typically personalized for your homedir, and can hardcode whatever > structure you use. Just like GUI apps are typically personalized for your homedir, and can hardcode whatever structure you use... Wait, wasn't the whole point making accesses to common stuff standardised? You're stopping midways there. Why do you assume only single-user GUI stuff needs streamlined access to your directories? > But, this is not my main disagreement. My main disagreement is on the > idea that it is more important that you need two lines less code in some > script than that the users personal files should be in a language they > can understand. You can have it both ways with english symlinks to localised "real" directories. > And translation of the filenames in the UI will *never* be complete. More reason *not* to pre-create directories with faulty names, and ask users on creation what they would like to call their directories. > There will always be 3rd party applications that don't translate the > names, And apps that won't parse your config file but can be pointed at a default symlink -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Mar 19 10:53:01 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 11:53:01 +0100 (CET) Subject: User directories integration - request for help In-Reply-To: <1174294051.3035.5.camel@greebo> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <1173992650.5024.9.camel@rousalka.dyndns.org> <1173993597.3535.3.camel@localhost.localdomain> <62734.192.54.193.51.1174053084.squirrel@rousalka.dyndns.org> <1174294051.3035.5.camel@greebo> Message-ID: <36721.192.54.193.51.1174301581.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 09:47, Alexander Larsson a ?crit : > On Fri, 2007-03-16 at 14:51 +0100, Nicolas Mailhot wrote: > >> Could you add please add a dot dir containing (hard|sym) links pointing >> to >> whatever renamed directories the user configured at the moment ? > > Symlinks are a bad idea, they will leak out into the user interface They have no more reason to leak in the UI than the conf file unless you mess up the implementation. Just show the link target, the user has no reason to know it's been found through a symlink than through a conf file. They will work (through "leaking") with every legacy app without easy-to-get-wrong shell wrapping (when it's possible) More people use legacy and shell apps than SMB homedirs on windows systems (samba supports symlinks IIRC). Also when the vista link stuff gets widely available that choice won't look too smart. Do you want to restrict directory names to 7-bit ASCII because some people have home on a FAT usb stick too ? -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Mar 19 12:19:39 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 13:19:39 +0100 (CET) Subject: User directories integration - request for help In-Reply-To: <45FE74F8.6050909@laposte.net> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> <20070316124530.GD2923@free.fr> <1174295987.3035.33.camel@greebo> <20070319111834.GH3186@free.fr> <45FE74F8.6050909@laposte.net> Message-ID: <23291.192.54.193.51.1174306779.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 12:33, Axel a ?crit : > Automatic creation doesn't sound bad to me. If the user doesn't like it, > he can delete them, Or rename it, since Alex already acknowledged the translations may be incomplete, or the locale wrong at first boot. Seems except for first-class locales, most people will end up undoing this auto-stuff. Will this really help them ? On the same subject here http://denbeste.nu/Chizumatic/ is what actual non-tech windows users think about silently using pre-created directories (search for Wonderduck). And this was an english dir, not a localized one (localizations change over time) -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Mar 19 12:27:18 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 13:27:18 +0100 (CET) Subject: User directories integration - request for help In-Reply-To: <1174295469.3035.23.camel@greebo> References: <45F9A7A0.3010607@fedoraproject.org> <20070316085216.1457851f@banea.int.addix.net> <1174052002.5941.49.camel@willson> <1174052888.5822.5.camel@localhost.localdomain> <1174053435.4680.150.camel@mccallum.corsepiu.local> <1174067132.3434.1.camel@localhost.localdomain> <1174069776.4680.170.camel@mccallum.corsepiu.local> <1174092307.2653.29.camel@zelda.fubar.dk> <1174100317.4680.211.camel@mccallum.corsepiu.local> <1174102387.2653.62.camel@zelda.fubar.dk> <20070317135628.GB8832@devserv.devel.redhat.com> <1174143351.2857.11.camel@dawkins> <1174151784.18279.31.camel@rousalka.dyndns.org> <1174295469.3035.23.camel@greebo> Message-ID: <63359.192.54.193.51.1174307238.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 10:11, Alexander Larsson a ?crit : > On Sat, 2007-03-17 at 18:16 +0100, Nicolas Mailhot wrote: >> There is one thing worse than not taking i18n in consideration that's >> botching your i18n implementation. I for one am deeply attached to i18n >> due to my personal background. And I'd rather wait a few weeks/months >> for a proper solution that have a semi-broken hack that will be set in >> stone as soon as a release goes out with it. > > A few weeks? The english-on-disk or translations-on-disk flamewar has > been going on for at least five years. You'll note *I* never advocated using English-only or Localized-only pathnames. I advocated allowing both accesses at once through symlinks, because some use cases will be better with localised pathnames ant others with un-localized ones (and the five-years flamewar should strongly hint doing one at the expense of the other won't work) -- Nicolas Mailhot From sundaram at fedoraproject.org Mon Mar 19 12:29:43 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 17:59:43 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> Message-ID: <45FE8237.4@fedoraproject.org> Benny Amorsen wrote: >>>>>> "JB" == Josh Boyer writes: > > JB> cpuspeed is very useful, especially in the case of a laptop which > JB> several people use as their desktop. Your narrow definition of a > JB> desktop is perhaps too limiting. > > cpuspeed really isn't optional on modern desktop machines either. > Rahul Sundaram may have lots of machines with fixed clockspeeds, but > that is no reason to not support newer stuff. There is simply no need to get personal. If hardware doesn't support it, it needs to be disabled by default. Disagree? > Desktops are in the minority anyway, a live CD/DVD needs to be useful > on laptops. I would love to see some back up the claim that desktops are i the minority. Rahul From hughsient at gmail.com Mon Mar 19 12:31:55 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Mar 2007 12:31:55 +0000 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> Message-ID: <1174307515.2873.3.camel@localhost.localdomain> On Mon, 2007-03-19 at 12:29 +0100, Benny Amorsen wrote: > JB> cpuspeed is very useful, especially in the case of a laptop which > JB> several people use as their desktop. Your narrow definition of a > JB> desktop is perhaps too limiting. > > cpuspeed really isn't optional on modern desktop machines either. > Rahul Sundaram may have lots of machines with fixed clockspeeds, but > that is no reason to not support newer stuff. GNOME Power Manager can control CPU speed with policy set in the session, usually saving power more aggressively than cpuspeed. It also has the benefit of using a HAL addon rather than a system service, which is only loaded if the machine is frequency scale supported. So really, I think the system daemon can be stopped by default, and leave it there if some admin wants to install it on a big server. Richard. From nicolas.mailhot at laposte.net Mon Mar 19 12:33:08 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 13:33:08 +0100 (CET) Subject: User directories integration - request for help In-Reply-To: <1174300510.3035.79.camel@greebo> References: <1173953610.10024.132.camel@greebo> <1173981802.3566.2.camel@localhost.localdomain> <1173986979.3051.0.camel@sb-home.lan> <1174035924.10024.184.camel@greebo> <20070316124530.GD2923@free.fr> <1174295987.3035.33.camel@greebo> <20070319095349.GA3186@free.fr> <1174300510.3035.79.camel@greebo> Message-ID: <31797.192.54.193.51.1174307588.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 11:35, Alexander Larsson a ?crit : > On Mon, 2007-03-19 at 10:53 +0100, Patrice Dumas wrote: > >> > There are other uses too, like >> > default bookmarks (in file manager, file selector, etc). >> >> They could create the directory when the user click on the icon? > > I don't think this is largely different from creating them at login. > Many dirs will be created at first login anyway (Desktop, Templates, > maybe Public), Why? > and others will be created as you go. Seems very similar > to the create-at-login approach except the code needs to be duplicated > all over the place and the homedirectory is slowly modified over time > instead of just once. The "slowly modified over time" has the nice property of walking the user through directory creation progressively, when he's interested in related stuff instead of dumping a big hierarchy he'll dismiss as irrelevant (and ignore from now on) -- Nicolas Mailhot From linville at redhat.com Mon Mar 19 12:38:11 2007 From: linville at redhat.com (John W. Linville) Date: Mon, 19 Mar 2007 08:38:11 -0400 Subject: Kernel BUG caused by iwlwifi In-Reply-To: <1174295527.2881.4.camel@localhost.localdomain> References: <1174295527.2881.4.camel@localhost.localdomain> Message-ID: <20070319123811.GB18472@redhat.com> On Mon, Mar 19, 2007 at 09:12:07AM +0000, Richard Hughes wrote: > Not sure what to do here - normally I wouldn't dare report > out-of-vanilla modules for BUG'ing, but this one is being included in > rawhide and stops the boot process dead. > > Worth filing a RH bugzilla or a kernel bugzilla? This is with latest > rawhide. It is not in the upstream kernel, so only the RH bugzilla would be appropriate. Please make sure to CC: me. Thanks, John -- John W. Linville linville at redhat.com From benny+usenet at amorsen.dk Mon Mar 19 12:38:15 2007 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 19 Mar 2007 13:38:15 +0100 Subject: too many deamons by default - F7 test 2 live cd References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <45FE8237.4@fedoraproject.org> Message-ID: >>>>> "RS" == Rahul Sundaram writes: RS> Benny Amorsen wrote: >>>>>>> "JB" == Josh Boyer writes: JB> cpuspeed is very useful, especially in the case of a laptop which JB> several people use as their desktop. Your narrow definition of a JB> desktop is perhaps too limiting. >> cpuspeed really isn't optional on modern desktop machines either. >> Rahul Sundaram may have lots of machines with fixed clockspeeds, >> but that is no reason to not support newer stuff. RS> There is simply no need to get personal. If hardware doesn't RS> support it, it needs to be disabled by default. Disagree? Disagree. cpuspeed is harmless if the hardware doesn't support it. No reason to go out of your way to disable it. /Benny From nicolas.mailhot at laposte.net Mon Mar 19 12:39:33 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 13:39:33 +0100 (CET) Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE8237.4@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <45FE8237.4@fedoraproject.org> Message-ID: <4013.192.54.193.51.1174307973.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 13:29, Rahul Sundaram a ?crit : > Benny Amorsen wrote: >>>>>>> "JB" == Josh Boyer writes: >> >> JB> cpuspeed is very useful, especially in the case of a laptop which >> JB> several people use as their desktop. Your narrow definition of a >> JB> desktop is perhaps too limiting. >> >> cpuspeed really isn't optional on modern desktop machines either. >> Rahul Sundaram may have lots of machines with fixed clockspeeds, but >> that is no reason to not support newer stuff. > > There is simply no need to get personal. If hardware doesn't support it, > it needs to be disabled by default. Disagree? If a large proportion of hardware supports it, and launching it for the rest is relatively harmless, it needs to be enabled by default. I find it ridiculous to push network manager (which is only really needed for wifi users, for hardware we have free drivers for, and tends to mess up the system when going bad) and ask to remove cpuspeed. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Mar 19 12:41:31 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 13:41:31 +0100 (CET) Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174307515.2873.3.camel@localhost.localdomain> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <1174307515.2873.3.camel@localhost.localdomain> Message-ID: <13880.192.54.193.51.1174308091.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 13:31, Richard Hughes a ?crit : > > GNOME Power Manager can control CPU speed with policy set in the > session, usually saving power more aggressively than cpuspeed. It also > has the benefit of using a HAL addon rather than a system service, which > is only loaded if the machine is frequency scale supported. Does it work for KDE users or when logged of? (just curious, my system is mostly iddle when I'm not sitting in front of it) -- Nicolas Mailhot From sundaram at fedoraproject.org Mon Mar 19 12:42:41 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 18:12:41 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <4013.192.54.193.51.1174307973.squirrel@rousalka.dyndns.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <45FE8237.4@fedoraproject.org> <4013.192.54.193.51.1174307973.squirrel@rousalka.dyndns.org> Message-ID: <45FE8541.1020906@fedoraproject.org> Nicolas Mailhot wrote: > Le Lun 19 mars 2007 13:29, Rahul Sundaram a ?crit : >> Benny Amorsen wrote: >>>>>>>> "JB" == Josh Boyer writes: >>> JB> cpuspeed is very useful, especially in the case of a laptop which >>> JB> several people use as their desktop. Your narrow definition of a >>> JB> desktop is perhaps too limiting. >>> >>> cpuspeed really isn't optional on modern desktop machines either. >>> Rahul Sundaram may have lots of machines with fixed clockspeeds, but >>> that is no reason to not support newer stuff. >> There is simply no need to get personal. If hardware doesn't support it, >> it needs to be disabled by default. Disagree? > > If a large proportion of hardware supports it, and launching it for the > rest is relatively harmless, it needs to be enabled by default. Do we know if a large portion of hardware supports it, useful on those? Wouldn't gnome-power-manager be enough on those systems? > I find it ridiculous to push network manager (which is only really needed > for wifi users, for hardware we have free drivers for, and tends to mess > up the system when going bad) and ask to remove cpuspeed. Where did I ask for cpuspeed to be removed? You are just making things up now. Rahul From jwboyer at jdub.homelinux.org Mon Mar 19 12:41:50 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 19 Mar 2007 07:41:50 -0500 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174307515.2873.3.camel@localhost.localdomain> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <1174307515.2873.3.camel@localhost.localdomain> Message-ID: <1174308110.30079.3.camel@zod.rchland.ibm.com> On Mon, 2007-03-19 at 12:31 +0000, Richard Hughes wrote: > On Mon, 2007-03-19 at 12:29 +0100, Benny Amorsen wrote: > > JB> cpuspeed is very useful, especially in the case of a laptop which > > JB> several people use as their desktop. Your narrow definition of a > > JB> desktop is perhaps too limiting. > > > > cpuspeed really isn't optional on modern desktop machines either. > > Rahul Sundaram may have lots of machines with fixed clockspeeds, but > > that is no reason to not support newer stuff. > > GNOME Power Manager can control CPU speed with policy set in the > session, usually saving power more aggressively than cpuspeed. It also > has the benefit of using a HAL addon rather than a system service, which > is only loaded if the machine is frequency scale supported. > > So really, I think the system daemon can be stopped by default, and > leave it there if some admin wants to install it on a big server. For the discussion purposes of the LiveCD, which will be Gnome based, that is technically possible. In general though, unless KDE, XFCE, < $ramdom foo> has the same thing, g-p-m doesn't help at all. josh From sundaram at fedoraproject.org Mon Mar 19 12:44:42 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 18:14:42 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <45FE8237.4@fedoraproject.org> Message-ID: <45FE85BA.2000004@fedoraproject.org> Benny Amorsen wrote: >>>>>> "RS" == Rahul Sundaram writes: > > RS> Benny Amorsen wrote: >>>>>>>> "JB" == Josh Boyer writes: > JB> cpuspeed is very useful, especially in the case of a laptop which > JB> several people use as their desktop. Your narrow definition of a > JB> desktop is perhaps too limiting. >>> cpuspeed really isn't optional on modern desktop machines either. >>> Rahul Sundaram may have lots of machines with fixed clockspeeds, >>> but that is no reason to not support newer stuff. > > RS> There is simply no need to get personal. If hardware doesn't > RS> support it, it needs to be disabled by default. Disagree? > > Disagree. cpuspeed is harmless if the hardware doesn't support it. No > reason to go out of your way to disable it. There is no daemon designed by be harmful. We might as well as enable everything by default by this logic. Rahul From wolfy at nobugconsulting.ro Mon Mar 19 12:52:35 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Mon, 19 Mar 2007 14:52:35 +0200 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE5D39.7020002@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> Message-ID: <45FE8793.1000203@nobugconsulting.ro> Rahul Sundaram wrote: > > Exim should probably replaced with something like esmtp or ssmtp in > the live cd. Folks wanting to install a full blown MTA can install > sendmail, postfix or email on their own. As maintainer of ssmtp I would be more then pleased to have it included as default MTA. Unfortunatelly it is close to useless without a real MTA (read: mailhub) around. It cannot be used even by thunderbird who expects to talk SMTP with outgoing server(s) ( the presence of a binary called sendmail is not enough ). I've found ssmtp to be most useful in a farm of computers which can/should send their mails to a central server From nicolas.mailhot at laposte.net Mon Mar 19 12:57:25 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 13:57:25 +0100 (CET) Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE8541.1020906@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <45FE8237.4@fedoraproject.org> <4013.192.54.193.51.1174307973.squirrel@rousalka.dyndns.org> <45FE8541.1020906@fedoraproject.org> Message-ID: <35632.192.54.193.51.1174309045.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 13:42, Rahul Sundaram a ?crit : > Do we know if a large portion of hardware supports it, Every single 64 bit AMD processor supports it, some 32 bit AMD processors too, probably at least the laptop intel processors. > useful on those? How could it be not useful? laptop benefits are obvious, desktop win on energy bill and loudness factor (also badly ventilated cases will die if you move them from cpufreq windows to fixed freq linux) -- Nicolas Mailhot From jwilson at redhat.com Mon Mar 19 12:59:46 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 19 Mar 2007 08:59:46 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE726D.6000305@leemhuis.info> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> Message-ID: <45FE8942.8050602@redhat.com> Thorsten Leemhuis wrote: > On 19.03.2007 11:56, Oliver Falk wrote: >> On 03/19/2007 11:51 AM, Thorsten Leemhuis wrote: >>> On 19.03.2007 11:05, Oliver Falk wrote: >>>> On 03/19/2007 10:51 AM, Rahul Sundaram wrote: >>>>> Extra - cpuspeed. >>>> This one makes sense on laptops, doesn't it? >>> It makes also much sense on Desktops -- nearly all modern Desktop-CPUs >>> and also a lot of Server-CPUs support some kind power-saving features. >>> It IMHO would be wise to use them so save power and keeps systems cool >>> (and quiet -- I don't want to hear people saying "my System is much >>> louder when I use the Fedora Live-CD"). >> Yes, OK, but installing/starting cpuspeed on a computer that actually >> doesn't support it doesn't make sense. Right? :-) > > Installing IMHO make sense, as people might install a CPU with > power-saving capabilities later (or they simple enable it in the > BIOS-Setup). > > Stating the daemon by default IMHO makes sense, too, but it probably > should be possible by the start script to quickly notice if cpufreq > support is available and abort cleanly if not. Everyone please kindly read the cpuspeed initscript before continuing to hypothesize about it. It does indeed already look for necessary support, and silently exits without doing a thing it its not present. /me is the cpuspeed maintainer... :) -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From hughsient at gmail.com Mon Mar 19 12:54:52 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Mar 2007 12:54:52 +0000 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <13880.192.54.193.51.1174308091.squirrel@rousalka.dyndns.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <1174307515.2873.3.camel@localhost.localdomain> <13880.192.54.193.51.1174308091.squirrel@rousalka.dyndns.org> Message-ID: <15e53e180703190554h6059a1abx477e5c585db69e86@mail.gmail.com> On 19/03/07, Nicolas Mailhot wrote: > > Le Lun 19 mars 2007 13:31, Richard Hughes a ?crit : > > > > GNOME Power Manager can control CPU speed with policy set in the > > session, usually saving power more aggressively than cpuspeed. It also > > has the benefit of using a HAL addon rather than a system service, which > > is only loaded if the machine is frequency scale supported. > > Does it work for KDE users or when logged of? (just curious, my system is > mostly iddle when I'm not sitting in front of it) Locked yes, not logged in no. That's something that will be fixed really soon, now that g-p-m can be run headless. KDE has a K-version of power manager, the name of which escapes me. I would expect that to do cpu freq just like g-p-m does. Richard. From hughsient at gmail.com Mon Mar 19 12:56:09 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Mar 2007 12:56:09 +0000 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <4013.192.54.193.51.1174307973.squirrel@rousalka.dyndns.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <45FE8237.4@fedoraproject.org> <4013.192.54.193.51.1174307973.squirrel@rousalka.dyndns.org> Message-ID: <15e53e180703190556u707be177wcbf5e486c22460b7@mail.gmail.com> On 19/03/07, Nicolas Mailhot wrote: > > Le Lun 19 mars 2007 13:29, Rahul Sundaram a ?crit : > > Benny Amorsen wrote: > >>>>>>> "JB" == Josh Boyer writes: > >> > >> JB> cpuspeed is very useful, especially in the case of a laptop which > >> JB> several people use as their desktop. Your narrow definition of a > >> JB> desktop is perhaps too limiting. > >> > >> cpuspeed really isn't optional on modern desktop machines either. > >> Rahul Sundaram may have lots of machines with fixed clockspeeds, but > >> that is no reason to not support newer stuff. > > > > There is simply no need to get personal. If hardware doesn't support it, > > it needs to be disabled by default. Disagree? > > If a large proportion of hardware supports it, and launching it for the > rest is relatively harmless, it needs to be enabled by default. But it takes a finite amount of time to start the service, even on machines without the hardware. Richard. From sundaram at fedoraproject.org Mon Mar 19 13:11:22 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 18:41:22 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE8793.1000203@nobugconsulting.ro> References: <45FE5D39.7020002@fedoraproject.org> <45FE8793.1000203@nobugconsulting.ro> Message-ID: <45FE8BFA.6000603@fedoraproject.org> Manuel Wolfshant wrote: > Rahul Sundaram wrote: >> >> Exim should probably replaced with something like esmtp or ssmtp in >> the live cd. Folks wanting to install a full blown MTA can install >> sendmail, postfix or email on their own. > As maintainer of ssmtp I would be more then pleased to have it included > as default MTA. Unfortunatelly it is close to useless without a real MTA > (read: mailhub) around. It cannot be used even by thunderbird who > expects to talk SMTP with outgoing server(s) ( the presence of a binary > called sendmail is not enough ). I've found ssmtp to be most useful in a > farm of computers which can/should send their mails to a central server Thanks for the information. Is there some kind of simple MTA which would just take of delivering local mail? Rahul From sundaram at fedoraproject.org Mon Mar 19 13:13:26 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 18:43:26 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE8942.8050602@redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> Message-ID: <45FE8C76.5030405@fedoraproject.org> Jarod Wilson wrote: > > Everyone please kindly read the cpuspeed initscript before continuing to > hypothesize about it. It does indeed already look for necessary support, > and silently exits without doing a thing it its not present. > > /me is the cpuspeed maintainer... :) It would do that everytime on bootup though. Right? Can we make it disable itself if the support is not there on first run? Rahul From sundaram at fedoraproject.org Mon Mar 19 13:15:48 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 18:45:48 +0530 Subject: Where Do I Debug Issues With An App Packaged By Fedora? In-Reply-To: <664892.48829.qm@web60524.mail.yahoo.com> References: <664892.48829.qm@web60524.mail.yahoo.com> Message-ID: <45FE8D04.5010308@fedoraproject.org> Timothy Spaulding wrote: > I'm an engineer and a user of Fedora. I've used Fedora at work for years now. Recently, I've run > into some problems using Evolution with our corporate exchange server. Figuring this was my > chance to get involved with the community, I started digging into the Fedora and Gnome projects > trying to figure out how to proceed. The big question I have is: Which project should I start > with? > > Fedora packages Evolution, but as I understand it, doesn't really add anything to its development > other than bug reports and some fixes. Would it be more appropriate to start by installing the > development versions of Evolution from Gnome? Should I start by installing from rawhide? > > How do you make a decision about where to start debugging? Also, I'd love to hear anyone's > strategies with debugging a specific application on Fedora without disrupting the rest of the > machine. If you are looking to debug Evolution on Fedora and report bugs, see http://fedoraproject.org/wiki/StackTraces. Evolution is minimally patched is Fedora. If you are looking to contribute to code development running the latest version from CVS/SVN from upstream and reporting bugs/ sending patches there would be better. Rahul From rc040203 at freenet.de Mon Mar 19 13:20:32 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Mar 2007 14:20:32 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE716B.1070107@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> Message-ID: <1174310432.3667.53.camel@mccallum.corsepiu.local> On Mon, 2007-03-19 at 16:48 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > On Mon, 2007-03-19 at 16:18 +0530, Rahul Sundaram wrote: > >> Florian La Roche wrote: > >>> On Mon, Mar 19, 2007 at 04:01:39PM +0530, Rahul Sundaram wrote: > >>>> Nicolas Mailhot wrote: > >>>>> Le Lun 19 mars 2007 10:51, Rahul Sundaram a ?crit : > >>>>> > >>>>>> Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. Can't see a reason to > >>>>>> enable these by default. > >>>>> cpuspeed, mdmonitor and ntpd are no more extra than NetworkManager > >>>> Yes, They are. For a desktop. A Live CD is targeted at the desktop. > >>>> Nothing else. > >>> > >>> We should really target a Live-DVD instead of a Live-CD. > >> DVD drives are way too costly in many regions. We still need a Live CD. > > > > Pardon, but I would not recommend Fedora to anybody who doesn't have > > broadband access. Those who have broadband access also very likely have > > a DVD drive > > Can you specify the factors for your recommendation? Let me put it this way: I live in a region German Telekom so far has not been able to provide reasonable DSL bandwidth. All that is available is ISDN (64kb/s) or "DSL Lite" (350kb/s). Now compare these bandwidths with the update rates Fedora Core updates impose (Feel free to only consider the very essential packages, such as gcc, the kernel, openoffice, X11, firefox, ...). Also consider the poor synchronicity/unreliability of the Fedora mirrors and yum's missing ability to abort properly (Yum iterating over all mirrors on broadband is a matter of minutes, the same on ISDN or modem is simply embarrassing) >From my experience (I've used Fedora with both ISDN and with DSL Lite), Fedora with ISDN or modem is plain unusable, with "DSL Lite", the situation is "bearable", but isn't fun (an openoffice update takes a working-day). I.e. I'd claim Fedora to require a minimum bandwidth: ~300kb/s recommended bandwidth >= 1000kb/s > Live CD's can be > installed to a hard disk and works out of the box. I know, Live CD/DVS's primary purpose is to provide "a sneak-preview". > That doesnt require > any broadband connection. Broad connection does not automatically > translate into systems with DVD. Many work places have restrictions on > removable disk access (No CD/DVD drivers, USB ports locked etc). Such work places typically have a sysadmin. Live CD users normally are "SISO"/home-users. > > Also: Do you know how Ubuntu and Knoppix are being shipped in Germany. > > As free add-ons to magazines > > Fedora is included in magazines all over the world too. Then I must ask myself, why I own several Knoppix and Ubuntu DVDs, but not a single Fedora DVD? > Does not change > the fact that Live CD are still very much a good thing for several end > users and for promotional events. Exactly. Live CDs are promo/marketing-material, i.e. either directly going to waste-bin or being launched very few times and then replaced with the "real stuff", soon. Ralf From nicolas.mailhot at laposte.net Mon Mar 19 13:21:53 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 14:21:53 +0100 (CET) Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE8C76.5030405@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> Message-ID: <1624.192.54.193.51.1174310513.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 14:13, Rahul Sundaram a ?crit : > Jarod Wilson wrote: >> >> Everyone please kindly read the cpuspeed initscript before continuing to >> hypothesize about it. It does indeed already look for necessary support, >> and silently exits without doing a thing it its not present. >> >> /me is the cpuspeed maintainer... :) > > It would do that everytime on bootup though. Right? Can we make it > disable itself if the support is not there on first run? Will harm users that enable/disble cpufreq in bios -- Nicolas Mailhot From ssorce at redhat.com Mon Mar 19 13:24:45 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 19 Mar 2007 09:24:45 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE8C76.5030405@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> Message-ID: <1174310685.16983.14.camel@willson> On Mon, 2007-03-19 at 18:43 +0530, Rahul Sundaram wrote: > Jarod Wilson wrote: > > > > Everyone please kindly read the cpuspeed initscript before continuing to > > hypothesize about it. It does indeed already look for necessary support, > > and silently exits without doing a thing it its not present. > > > > /me is the cpuspeed maintainer... :) > > It would do that everytime on bootup though. Right? Can we make it > disable itself if the support is not there on first run? on a live CD ? From sundaram at fedoraproject.org Mon Mar 19 13:28:36 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 18:58:36 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174310685.16983.14.camel@willson> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> <1174310685.16983.14.camel@willson> Message-ID: <45FE9004.70906@fedoraproject.org> Simo Sorce wrote: > On Mon, 2007-03-19 at 18:43 +0530, Rahul Sundaram wrote: >> Jarod Wilson wrote: >>> Everyone please kindly read the cpuspeed initscript before continuing to >>> hypothesize about it. It does indeed already look for necessary support, >>> and silently exits without doing a thing it its not present. >>> >>> /me is the cpuspeed maintainer... :) >> It would do that everytime on bootup though. Right? Can we make it >> disable itself if the support is not there on first run? > > on a live CD ? ... which is installable Rahul From aph at redhat.com Mon Mar 19 13:28:58 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 19 Mar 2007 13:28:58 +0000 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174310432.3667.53.camel@mccallum.corsepiu.local> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> Message-ID: <17918.36890.861729.982547@zebedee.pink> Ralf Corsepius writes: > >From my experience (I've used Fedora with both ISDN and with DSL Lite), > Fedora with ISDN or modem is plain unusable, with "DSL Lite", the > situation is "bearable", but isn't fun (an openoffice update takes a > working-day). So don't do that, then. Fedora doesn't require anyone to yum update openoffice. > On Mon, 2007-03-19 at 16:48 +0530, Rahul Sundaram wrote: > > Ralf Corsepius wrote: > > > Also: Do you know how Ubuntu and Knoppix are being shipped in Germany. > > > As free add-ons to magazines > > > > Fedora is included in magazines all over the world too. > > Then I must ask myself, why I own several Knoppix and Ubuntu DVDs, but > not a single Fedora DVD? How are we supposed to know that? Do you suppose we are telepathic? Andrew. From sundaram at fedoraproject.org Mon Mar 19 13:29:22 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 18:59:22 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1624.192.54.193.51.1174310513.squirrel@rousalka.dyndns.org> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> <1624.192.54.193.51.1174310513.squirrel@rousalka.dyndns.org> Message-ID: <45FE9032.7070001@fedoraproject.org> Nicolas Mailhot wrote: > Le Lun 19 mars 2007 14:13, Rahul Sundaram a ?crit : >> Jarod Wilson wrote: >>> Everyone please kindly read the cpuspeed initscript before continuing to >>> hypothesize about it. It does indeed already look for necessary support, >>> and silently exits without doing a thing it its not present. >>> >>> /me is the cpuspeed maintainer... :) >> It would do that everytime on bootup though. Right? Can we make it >> disable itself if the support is not there on first run? > > Will harm users that enable/disble cpufreq in bios Surely those users know to enable/disable services too? Rahul From rc040203 at freenet.de Mon Mar 19 13:29:52 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Mar 2007 14:29:52 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE70FC.4000100@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <1174300182.3667.5.camel@mccallum.corsepiu.local> <45FE6797.2010307@fedoraproject.org> <1174301778.3667.26.camel@mccallum.corsepiu.local> <45FE70FC.4000100@fedoraproject.org> Message-ID: <1174310992.3667.57.camel@mccallum.corsepiu.local> On Mon, 2007-03-19 at 16:46 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > That's why I say "weak spot" - There is no "one-fits-all set of daemons > > to enable/disable" - Each situation is different, but there is hardly > > any means to customize an installation for an individual situation > > during installation with Fedora. > > Anaconda, Kickstart, targeted and custom spins enable you to customize > Fedora for individual situations. Don't they? Once you have a system up, or if you already have a system up, yes, there are means to customize, but during installation (esp. first time installation) - no, to a large extend, this doesn't apply. Ralf From mclasen at redhat.com Mon Mar 19 13:34:57 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 19 Mar 2007 09:34:57 -0400 Subject: User directories integration - request for help In-Reply-To: <1174297898.3667.1.camel@mccallum.corsepiu.local> References: <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> <20070316123536.GC2923@free.fr> <1174294196.3035.8.camel@greebo> <45FE4FC7.4070106@volny.cz> <1174297007.3035.48.camel@greebo> <1174297898.3667.1.camel@mccallum.corsepiu.local> Message-ID: <1174311297.3341.6.camel@dhcp83-33.boston.redhat.com> On Mon, 2007-03-19 at 10:51 +0100, Ralf Corsepius wrote: > On Mon, 2007-03-19 at 10:36 +0100, Alexander Larsson wrote: > > On Mon, 2007-03-19 at 09:54 +0100, Miloslav Trmac wrote: > > > Alexander Larsson napsal(a): > > > > On Fri, 2007-03-16 at 13:35 +0100, Patrice Dumas wrote: > > > >> It seems like those folders are created automatically when user logs in. > > > >> That's what I dislike. If they are defaults for 'save' actions in every > > > >> apps, fine. If they are created and used automatically, I think it isn't > > > >> right. > > > > > > > nor would it work instantly with all applications. > > > The specification is new, so it won't "work instantly with all > > > applications" anyway. > > > > It very much does. All applications using the gtk file selector will > > have some default folders as file selector bookmars, and *all* > > applications get translated filenames for common directories. > > And all other applications, such as gui-less apps will be broken. Care to explain how they will be broken ? gui vs no-gui does not even enter the picture here. Yes, gui-less apps will not benefit from the bookmarks, because they don't have a filechooser. Do you say they are broken because they don't have a filechooser ? You are not making any sense here. > Related to this: Explain who all this is supposed without any > login-manager (plain su -l without running any GUI) It won't work if you are booting with emacs replacing init either. I fail to see how this is relevant. From sundaram at fedoraproject.org Mon Mar 19 13:34:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 19:04:04 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174310992.3667.57.camel@mccallum.corsepiu.local> References: <45FE5D39.7020002@fedoraproject.org> <1174300182.3667.5.camel@mccallum.corsepiu.local> <45FE6797.2010307@fedoraproject.org> <1174301778.3667.26.camel@mccallum.corsepiu.local> <45FE70FC.4000100@fedoraproject.org> <1174310992.3667.57.camel@mccallum.corsepiu.local> Message-ID: <45FE914C.3000201@fedoraproject.org> Ralf Corsepius wrote: > On Mon, 2007-03-19 at 16:46 +0530, Rahul Sundaram wrote: >> Ralf Corsepius wrote: > >>> That's why I say "weak spot" - There is no "one-fits-all set of daemons >>> to enable/disable" - Each situation is different, but there is hardly >>> any means to customize an installation for an individual situation >>> during installation with Fedora. >> Anaconda, Kickstart, targeted and custom spins enable you to customize >> Fedora for individual situations. Don't they? > Once you have a system up, or if you already have a system up, yes, > there are means to customize, but during installation (esp. first time > installation) - no, to a large extend, this doesn't apply. What are you talking about? All of these steps I mentioned above allow to customize during installation whatever you want. Rahul From mclasen at redhat.com Mon Mar 19 13:37:06 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 19 Mar 2007 09:37:06 -0400 Subject: User directories integration - request for help In-Reply-To: <20070319095722.GB3186@free.fr> References: <1174102387.2653.62.camel@zelda.fubar.dk> <1174103491.4680.227.camel@mccallum.corsepiu.local> <1174105657.2691.24.camel@zelda.fubar.dk> <1174106134.4680.249.camel@mccallum.corsepiu.local> <1174107004.2691.31.camel@zelda.fubar.dk> <20070317135944.GC8832@devserv.devel.redhat.com> <1174159178.2759.7.camel@localhost.localdomain> <20070317195544.GA21441@devserv.devel.redhat.com> <1174151524.2784.8.camel@zelda.fubar.dk> <1174185384.3455.4.camel@localhost.localdomain> <20070319095722.GB3186@free.fr> Message-ID: <1174311426.3341.9.camel@dhcp83-33.boston.redhat.com> On Mon, 2007-03-19 at 10:57 +0100, Patrice Dumas wrote: > On Sat, Mar 17, 2007 at 10:36:24PM -0400, Matthias Clasen wrote: > > fedora-devel has done its magic and managed to make this thread too long > > for any meaningful response in just a few days, but let me just ask this > > one question here: > > > > How many of the people who go ballistic here about stupid gui developers > > with fingers in their ears trying to imitate win95 have actually tried > > Alex' implementation ? > > No need to try it to discuss about the design. Avoiding a bad design > ealy is likely to help better than trying an implementation of a design > we don't like anyway. > No, you didn't get it; the design discussion has been going on upstream for ~5 years now. We are finally beyond that. From fedora at leemhuis.info Mon Mar 19 13:38:28 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 19 Mar 2007 14:38:28 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE9032.7070001@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> <1624.192.54.193.51.1174310513.squirrel@rousalka.dyndns.org> <45FE9032.7070001@fedoraproject.org> Message-ID: <45FE9254.1090306@leemhuis.info> On 19.03.2007 14:29, Rahul Sundaram wrote: > Nicolas Mailhot wrote: >> Le Lun 19 mars 2007 14:13, Rahul Sundaram a ?crit : >>> Jarod Wilson wrote: >>>> Everyone please kindly read the cpuspeed initscript before continuing to >>>> hypothesize about it. It does indeed already look for necessary support, >>>> and silently exits without doing a thing it its not present. >>>> >>>> /me is the cpuspeed maintainer... :) >>> It would do that everytime on bootup though. Right? Can we make it >>> disable itself if the support is not there on first run? >> Will harm users that enable/disble cpufreq in bios > Surely those users know to enable/disable services too? Stuff like that should "just work" IMHO, so no, those users should not have to enable services IMHO. /me is wondering why we are discussing cpuspeed, which starts quite quickly, while yum-updatesd needs 4 to 5 seconds on my system :-( CU thl From jwilson at redhat.com Mon Mar 19 13:39:28 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 19 Mar 2007 09:39:28 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE8C76.5030405@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> Message-ID: <45FE9290.6060404@redhat.com> Rahul Sundaram wrote: > Jarod Wilson wrote: >> >> Everyone please kindly read the cpuspeed initscript before continuing to >> hypothesize about it. It does indeed already look for necessary support, >> and silently exits without doing a thing it its not present. >> >> /me is the cpuspeed maintainer... :) > > It would do that everytime on bootup though. Right? Yes. And within a few lines of bash, it'll exit if support isn't found. The second line of the start function is essentially: if /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver doesn't exist, immediately exit silently. > Can we make it > disable itself if the support is not there on first run? Not worth it, if you ask me. This adds unnecessary complexity. And there are good reasons to try again the next boot. Sometimes things break or are broken in the kernel or in the bios that prevent cpuspeed from working one time, and they subsequently get fixed (this actually happens quite often with newer laptops). And seriously: # time service cpuspeed start Enabling ondemand cpu frequency scaling: [ OK ] real 0m0.194s user 0m0.032s sys 0m0.043s This is on a dual dual-core system w/hyperthreading enabled (ie 8 "cpus" to adjust the freq scaling bits on). On a system without support, we'll be done even faster than that: # time service cpuspeed start real 0m0.042s user 0m0.021s sys 0m0.024s Is something in the ballpark of 0.09 seconds really a concern? I know its all cumulative, but cpu frequency scaling is a Good Thing (save the planet, save on your energy bill, yadda, yadda, etc), we want to do everything we can to make sure we enable it whenever possible without requiring users to fiddle with things. And you can chkconfig it off it you really don't want it. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From buildsys at fedoraproject.org Mon Mar 19 13:39:42 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 19 Mar 2007 09:39:42 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-19 Message-ID: <20070319133942.103FF152130@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 25 basket-1.0.1-1.fc7 deskbar-applet-2.18.0-1.fc7 emacs-vm-7.19.devo282-10.fc7 freeglut-2.4.0-11.fc7 fwbackups-1.43.0-0.1.beta1.fc7 gdeskcal-1.01-1.fc7 gnu-smalltalk-2.3.3-5.fc7 itpp-3.10.9-1.fc7 jd-1.8.8-0.2.cvs070318.1.fc7 jhead-2.7-1.fc7 libmatheval-1.1.4-1.fc7 libnetfilter_conntrack-0.0.50-3.fc7 netcdf-3.6.2-1.fc7 notecase-1.5.1-1.fc7 openbabel-2.1.0-0.2.b6.fc7 NEW openlierox-0.57-0.2.beta1.fc7 NEW pdfedit-0.2.5-2.fc7 perl-Alien-wxWidgets-0.29-1.fc7 NEW perl-CGI-Session-4.20-2.fc7 perl-Data-Compare-0.16-1.fc7 perl-Email-Address-1.886-1.fc7 perl-Gtk2-1.144-1.fc7 perl-Test-Warn-0.09-1.fc7 perl-WWW-Mechanize-1.22-2.fc7 perl-Wx-0.69-1.fc7 Packages built and released for Fedora Extras 6: 22 basket-1.0.1-1.fc6 ccache-2.4-8.fc6 emacs-vm-7.19.devo282-9.fc6 freeglut-2.4.0-11.fc6 gdeskcal-1.01-1.fc6 gnome-schedule-1.1.0-1.fc6 gnu-smalltalk-2.3.3-5.fc6 itpp-3.10.9-1.fc6 jhead-2.7-1.fc6 libmatheval-1.1.4-1.fc6 libnetfilter_conntrack-0.0.50-2.fc6 libnfnetlink-0.0.25-1.fc6 notecase-1.5.1-1.fc6 NEW openlierox-0.57-0.2.beta1.fc6 NEW pdfedit-0.2.5-2.fc6 perl-Alien-wxWidgets-0.29-1.fc6 perl-Data-Compare-0.16-1.fc6 perl-Email-Address-1.886-1.fc6 perl-Gtk2-1.144-1.fc6 perl-Test-Warn-0.09-1.fc6 perl-WWW-Mechanize-1.22-2.fc6 perl-Wx-0.69-1.fc6 Packages built and released for Fedora Extras 5: 13 emacs-vm-7.19.devo282-9.fc5 gnome-schedule-1.1.0-1.fc5 gnu-smalltalk-2.3.3-5.fc5 horde-3.1.4-1.fc5 itpp-3.10.9-1.fc5 jhead-2.7-1.fc5 libmatheval-1.1.4-1.fc5 libnetfilter_conntrack-0.0.50-2.fc5 libnfnetlink-0.0.25-1.fc5 NEW perl-CGI-Session-4.20-2.fc5 perl-Data-Compare-0.16-1.fc5 perl-Email-Address-1.886-1.fc5 perl-Test-Warn-0.09-1.fc5 basket-1.0.1-1.fc7 ------------------ * Sun Mar 18 2007 Aurelien Bompard 1.0.1-1 - version 1.0.1 * Sat Feb 17 2007 Aurelien Bompard 1.0-2 - split off the kontact plugin, patch by Laurent Rineau (see bug 228966) deskbar-applet-2.18.0-1.fc7 --------------------------- * Sun Mar 18 2007 Luke Macken - 2.18.0-1 - 2.18.0 emacs-vm-7.19.devo282-10.fc7 ---------------------------- * Sun Mar 18 2007 Jonathan G. Underwood - 7.19.devo282-10 - Fixed error in specification of Source0 * Sun Mar 18 2007 Jonathan G. Underwood - 7.19.devo282-9 - Redefine version to include vmrf patch version (devo282) - Remove pointless %{pkg} macro - Add new pixmaps with better sizing (still ugly though) - Renamed the vmrf patch to include the version freeglut-2.4.0-11.fc7 --------------------- * Sun Mar 18 2007 Hans de Goede 2.4.0-11 - Minor specfile cleanups - Add a patch from gentoo to stop flightgear from crashing fwbackups-1.43.0-0.1.beta1.fc7 ------------------------------ * Sun Mar 18 2007 Stewart Adam 1.43.0-0.1.beta1 - Make release a beta one so the upgrade to final goes smoothly... * Fri Mar 16 2007 Stewart Adam 1.43.0-3 - Minor changes to package again * Wed Mar 14 2007 Stewart Adam 1.43.0-2 - Minor changes * Mon Feb 12 2007 Stewart Adam 1.43.0-1 - Update to version 1.43 * Sun Jan 28 2007 Stewart Adam 1.42.2-1 - Update to version 1.42.2 (see CHANGELOG file for details on version changes) gdeskcal-1.01-1.fc7 ------------------- * Sun Mar 18 2007 Michael Schwendt - 1.01-1 - upgrade to 1.01 (patches merged) * Mon Feb 26 2007 Michael Schwendt - 1.0-12 - fix About dialog - fix i18n.py to initialise gettext with the right localedir - rename message object files to gdeskcal.mo to fix conflict with gdesklets package (#220187) - update URL - revert language sub-package * Fri Feb 16 2007 Paul F. Johnson 1.0-11 - removed the languages files from the main package * Wed Dec 27 2006 Paul F. Johnson 1.0-10 - added fix for about dialog gnu-smalltalk-2.3.3-5.fc7 ------------------------- * Sun Mar 18 2007 Jochen Schmitt 2.3.3-5 - Include Publish.st patch itpp-3.10.9-1.fc7 ----------------- * Sun Mar 18 2007 Ed Hill - 3.10.9-1 - new upstream 3.10.9 * Sat Feb 10 2007 Ed Hill - 3.10.8-1 - new upstream 3.10.8 jd-1.8.8-0.2.cvs070318.1.fc7 ---------------------------- * Sun Mar 18 2007 Mamoru Tasaka - 1.8.8-0.2.cvs070318.1 - cvs 070318 (25:05 JST) jhead-2.7-1.fc7 --------------- * Sun Mar 18 2007 Adrian Reber - 2.7-1 - updated to 2.7 libmatheval-1.1.4-1.fc7 ----------------------- * Sun Mar 18 2007 Ed Hill - 1.1.4-1 - new upstream 1.1.4 libnetfilter_conntrack-0.0.50-3.fc7 ----------------------------------- * Mon Mar 19 2007 Paul P. Komkoff Jr - 0.0.50-3 - include libnfnetlink-devel into -devel deps netcdf-3.6.2-1.fc7 ------------------ * Sat Mar 17 2007 Ed Hill - 3.6.2-1 - 3.6.2 has a new build system supporting shared libs notecase-1.5.1-1.fc7 -------------------- * Sun Mar 18 2007 Damien Durand 1.5.1-1 - Upgrade to 1.5.1 openbabel-2.1.0-0.2.b6.fc7 -------------------------- * Sun Mar 18 2007 Dominik Mierzejewski 2.1.0-0.2.b6 - updated to beta6 - dropped upstream'd patch - fixed my name in ChangeLog - copied inchi header for inchi-devel (TODO: make inchi a separate package) - added %check openlierox-0.57-0.2.beta1.fc7 ----------------------------- * Thu Mar 15 2007 Hans de Goede 0.57-0.2.beta1 - Various specfile fixes from review (bz 232071) - Source instead of execute the bash scripts to avoid umask problems * Mon Mar 12 2007 Hans de Goede 0.57-0.1.beta1 - Initial Fedora Extras package pdfedit-0.2.5-2.fc7 ------------------- * Thu Mar 15 2007 Bernard Johnson - 0.2.5-2 - add scriptlets to update icon cache - add doxygen user docs * Wed Mar 14 2007 Bernard Johnson - 0.2.5-1 - initial release perl-Alien-wxWidgets-0.29-1.fc7 ------------------------------- * Sun Mar 18 2007 Jose Pedro Oliveira - 0.29-1 - Update to 0.29. perl-CGI-Session-4.20-2.fc7 --------------------------- * Sat Mar 17 2007 Andreas Thienemann 4.20-2 - Fixed perl-devel req * Sat Mar 10 2007 Andreas Thienemann 4.20-1 - Cleaned up for FE - Specfile autogenerated by cpanspec 1.69.1. perl-Data-Compare-0.16-1.fc7 ---------------------------- * Sun Mar 18 2007 Jose Pedro Oliveira - 0.16-1 - Update to 0.16. perl-Email-Address-1.886-1.fc7 ------------------------------ * Sun Mar 18 2007 Jose Pedro Oliveira - 1.886-1 - Update to 1.886. perl-Gtk2-1.144-1.fc7 --------------------- * Sun Mar 18 2007 Jose Pedro Oliveira - 1.144-1 - Update to 1.144. perl-Test-Warn-0.09-1.fc7 ------------------------- * Sun Mar 18 2007 Jose Pedro Oliveira - 0.09-1 - Update to 0.09. - New upstream maintainer. - New BR: perl(Test::Pod). perl-WWW-Mechanize-1.22-2.fc7 ----------------------------- * Sun Mar 18 2007 Jose Pedro Oliveira - 1.22-2 - New BR: perl(IO::Socket::SSL). * Sun Mar 18 2007 Jose Pedro Oliveira - 1.22-1 - Update to 1.22. perl-Wx-0.69-1.fc7 ------------------ * Sun Mar 18 2007 Jose Pedro Oliveira - 0.69-1 - Update to 0.69. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From jima at beer.tclug.org Mon Mar 19 13:42:53 2007 From: jima at beer.tclug.org (Jima) Date: Mon, 19 Mar 2007 08:42:53 -0500 (CDT) Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE85BA.2000004@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <45FE8237.4@fedoraproject.org> <45FE85BA.2000004@fedoraproject.org> Message-ID: On Mon, 19 Mar 2007, Rahul Sundaram wrote: > Benny Amorsen wrote: >> Disagree. cpuspeed is harmless if the hardware doesn't support it. No >> reason to go out of your way to disable it. > > There is no daemon designed by be harmful. We might as well as enable > everything by default by this logic. Are you saying I should drop kittenblenderd from my kitten_blender package? Jima From rc040203 at freenet.de Mon Mar 19 13:53:05 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Mar 2007 14:53:05 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE914C.3000201@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <1174300182.3667.5.camel@mccallum.corsepiu.local> <45FE6797.2010307@fedoraproject.org> <1174301778.3667.26.camel@mccallum.corsepiu.local> <45FE70FC.4000100@fedoraproject.org> <1174310992.3667.57.camel@mccallum.corsepiu.local> <45FE914C.3000201@fedoraproject.org> Message-ID: <1174312385.3667.67.camel@mccallum.corsepiu.local> On Mon, 2007-03-19 at 19:04 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > On Mon, 2007-03-19 at 16:46 +0530, Rahul Sundaram wrote: > >> Ralf Corsepius wrote: > > > >>> That's why I say "weak spot" - There is no "one-fits-all set of daemons > >>> to enable/disable" - Each situation is different, but there is hardly > >>> any means to customize an installation for an individual situation > >>> during installation with Fedora. > >> Anaconda, Kickstart, targeted and custom spins enable you to customize > >> Fedora for individual situations. Don't they? > > Once you have a system up, or if you already have a system up, yes, > > there are means to customize, but during installation (esp. first time > > installation) - no, to a large extend, this doesn't apply. > > What are you talking about? Two examples: * user management - There is no way to reserve uids before installation, there is no way to custiomize nsswitch.conf, there is no way to configure network'ed homes. * kickstart is only a means for advanced users, who are familiar with RH-based distros. It's not suiteable to "first-timers". Ralf From jwboyer at jdub.homelinux.org Mon Mar 19 13:54:15 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 19 Mar 2007 08:54:15 -0500 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <17918.36890.861729.982547@zebedee.pink> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> <17918.36890.861729.982547@zebedee.pink> Message-ID: <1174312455.30079.7.camel@zod.rchland.ibm.com> On Mon, 2007-03-19 at 13:28 +0000, Andrew Haley wrote: > Ralf Corsepius writes: > > > >From my experience (I've used Fedora with both ISDN and with DSL Lite), > > Fedora with ISDN or modem is plain unusable, with "DSL Lite", the > > situation is "bearable", but isn't fun (an openoffice update takes a > > working-day). > > So don't do that, then. Fedora doesn't require anyone to yum update openoffice. That isn't a particularly helpful comment. Telling people to not update packages is actually really bad. Think of security issues, etc. The kernel itself is 16MiB or so, and that can't be a speed download on a link like that either. Anyway, there really isn't a nice solution to the problem but blatantly telling someone "don't do that" is pretty asinine. josh From buc at odusz.so-cdu.ru Mon Mar 19 13:56:00 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 19 Mar 2007 16:56:00 +0300 Subject: exec bit mess Message-ID: <45FE9670.5000303@odu.neva.ru> Recently updated tcpdump package (both FC-5 and FC-6) has executable bit set (rwxr-xr-x) on the download servers, which can be visible throw ftp access. Something going wrong?... Dmitry Butskoy From sundaram at fedoraproject.org Mon Mar 19 13:57:37 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 19:27:37 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174312385.3667.67.camel@mccallum.corsepiu.local> References: <45FE5D39.7020002@fedoraproject.org> <1174300182.3667.5.camel@mccallum.corsepiu.local> <45FE6797.2010307@fedoraproject.org> <1174301778.3667.26.camel@mccallum.corsepiu.local> <45FE70FC.4000100@fedoraproject.org> <1174310992.3667.57.camel@mccallum.corsepiu.local> <45FE914C.3000201@fedoraproject.org> <1174312385.3667.67.camel@mccallum.corsepiu.local> Message-ID: <45FE96D1.4010404@fedoraproject.org> Ralf Corsepius wrote: > On Mon, 2007-03-19 at 19:04 +0530, Rahul Sundaram wrote: >> Ralf Corsepius wrote: >>> On Mon, 2007-03-19 at 16:46 +0530, Rahul Sundaram wrote: >>>> Ralf Corsepius wrote: >>>>> That's why I say "weak spot" - There is no "one-fits-all set of daemons >>>>> to enable/disable" - Each situation is different, but there is hardly >>>>> any means to customize an installation for an individual situation >>>>> during installation with Fedora. >>>> Anaconda, Kickstart, targeted and custom spins enable you to customize >>>> Fedora for individual situations. Don't they? >>> Once you have a system up, or if you already have a system up, yes, >>> there are means to customize, but during installation (esp. first time >>> installation) - no, to a large extend, this doesn't apply. >> What are you talking about? > Two examples: > > * user management - There is no way to reserve uids before installation, > there is no way to custiomize nsswitch.conf, there is no way to > configure network'ed homes. > > * kickstart is only a means for advanced users, who are familiar with > RH-based distros. It's not suiteable to "first-timers". Seem completely unrelated to daemons which is the topic of conversation. Rahul From markg85 at gmail.com Mon Mar 19 13:58:32 2007 From: markg85 at gmail.com (Mark) Date: Mon, 19 Mar 2007 14:58:32 +0100 Subject: [BUG] Mounted partitions are not showing up and CD/DVD link not correct Message-ID: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> Hey, First the "Mounted partitions are not showing up" bug. this bus is also in Fedora core 6 and i submitted it here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213768 and i must say that i`m really amazed that this bug is in it so long and that not a single person seems to complain about it. i don`t know how it is with you guys but i would like my mounted partitions to show up in the computer window like they are supposed to do. so about 6 months ago (or more) i found out about this bug and not a single people of the bugzilla stuff could point me to a fix or another solution.. therefore i also wonder if the bugzilla is even usefull if this forum (actually the skilled members there): http://gathering.tweakers.net/forum/list_messages/1172605///fedora%2Cpartities(dutch, tweakers.net) could solve my problem in just a few days. and isn`t there a site where all the pilicy`s are listed and described? now as annoying as the bug is.. the fix is quite simple. locate and destroy "99-redhat-storage-policy-fixed-drives.fdi". (or: rename it, vaporize it, whatever.. as long as linux can`t see the file anymore) i would also like to ask the fedora people if they could please fix this in the next fedora version (so in Core 7). as of this moment this bug is in fedora. Now for the dvd link that`s not correct. the "CD-RW/DVD?RW Drive" link in: computer:/// is very nice but not working. i`m getting: "unable to mount media" and it`s working fine when i mount it manually. the mount point i use is /dev/dvd mounted to /mnt/dvd so.. something wrong in the cd/dvd checking script? (if it`s even existing) @all of fedora: good job everyone!! i like it alot. though you will probable see some more bug reports of me here on this list. if you need more info about any of those bugs or some logs.. just ask me. good luck fixing, Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Mon Mar 19 13:38:33 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 14:38:33 +0100 (CET) Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE9032.7070001@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> <1624.192.54.193.51.1174310513.squirrel@rousalka.dyndns.org> <45FE9032.7070001@fedoraproject.org> Message-ID: <23692.192.54.193.51.1174311513.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 14:29, Rahul Sundaram a ?crit : > Nicolas Mailhot wrote: >> Le Lun 19 mars 2007 14:13, Rahul Sundaram a ?crit : >>> Jarod Wilson wrote: >>>> Everyone please kindly read the cpuspeed initscript before continuing >>>> to >>>> hypothesize about it. It does indeed already look for necessary >>>> support, >>>> and silently exits without doing a thing it its not present. >>>> >>>> /me is the cpuspeed maintainer... :) >>> It would do that everytime on bootup though. Right? Can we make it >>> disable itself if the support is not there on first run? >> >> Will harm users that enable/disble cpufreq in bios > > Surely those users know to enable/disable services too? enable/disable linux services is not part of windows cookbooks -- Nicolas Mailhot From markg85 at gmail.com Mon Mar 19 14:05:08 2007 From: markg85 at gmail.com (Mark) Date: Mon, 19 Mar 2007 15:05:08 +0100 Subject: [BUG] Fast User Switching Message-ID: <6e24a8e80703190705g119fad6dt76713ea6481bdc98@mail.gmail.com> Hey, i`m having a strange bug in Fedora Core 7 latest version with all updates. somehow the fast user switching seems to cause problems (while loading in the applet) and crashes gnome completely. the only thing you can do than is restart X. thankfully the gnome bug reporting tool found it out and offered me to disable the broken applet and i did that. (took me about 100x restarting...) now this applet is turned off in my root account and gnome is running fine but somehow my user account still has problems. sometimes gnome fully loads without any problems.. sometimes the desktop icons are all gone and most of the time the top bar (with the applets in it) is just not completely loaded and simply be useless because i can`t click any things in it. now could this also be because of the broken fast user switching? if so.. how do i remove it from gnome in text mode? since i obviously can`t remove it by clicking on it because the entire bar is useless most of the times.. Thanx, Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexl at redhat.com Mon Mar 19 14:08:40 2007 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Mar 2007 15:08:40 +0100 Subject: User directories integration - request for help In-Reply-To: <35639.192.54.193.51.1174306199.squirrel@rousalka.dyndns.org> References: <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> <20070316123536.GC2923@free.fr> <1174294196.3035.8.camel@greebo> <45FE4FC7.4070106@volny.cz> <1174297007.3035.48.camel@greebo> <1174297898.3667.1.camel@mccallum.corsepiu.local> <1174299192.3035.59.camel@greebo> <1174300942.3667.18.camel@mccallum.corsepiu.local> <1174302071.3035.104.camel@greebo> <35639.192.54.193.51.1174306199.squirrel@rousalka.dyndns.org> Message-ID: <1174313320.3035.146.camel@greebo> On Mon, 2007-03-19 at 13:09 +0100, Nicolas Mailhot wrote: > Le Lun 19 mars 2007 12:01, Alexander Larsson a ?crit : > > test -f ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs && source > > ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs > > tar czvf /tmp/music.tar.gz ${XDG_MUSIC_DIR} > > Add looping to handle multi-user setups, and you get the magnitude of > problems to replicate a simple ls /home/*/.config/xdg-dir/music/ I don't see that sort of operation as being very common though. The special directories are not some set-in-stones kind of LSB filesystem hierarchy. Its just a helping system that gets you some nice defaults for applications so that things can start up in a slightly nicer way than everything in ~/. You can't assume that a users files are in the xdg-user-dirs MUSIC directory any more than you can assume a hardcoded ~/Music. > > Thats a sort of weird backup script to have though. Backup scripts are > > typically personalized for your homedir, and can hardcode whatever > > structure you use. > > Just like GUI apps are typically personalized for your homedir, and can > hardcode whatever structure you use... Eh? GUI apps are not designed for any specific users homedir layout. > Wait, wasn't the whole point making accesses to common stuff standardised? Not exactly, the point was to make applications default to be slightly smarter about where files are normally stored, and to help new users get some form of simple structure to their homedirectory. > You're stopping midways there. Why do you assume only single-user GUI > stuff needs streamlined access to your directories? I don't. xdg-user-dirs is a console-only application and gets run from the login scripts. Not by the desktop. Any app can use it, console or not. > > But, this is not my main disagreement. My main disagreement is on the > > idea that it is more important that you need two lines less code in some > > script than that the users personal files should be in a language they > > can understand. > > You can have it both ways with english symlinks to localised "real" > directories. > > > And translation of the filenames in the UI will *never* be complete. > > More reason *not* to pre-create directories with faulty names, and ask > users on creation what they would like to call their directories. How is this different from not creating the folders at all. When your file selector defaults in $HOME you can just create your Music directory and select it. The idea is that a lot of people don't even know that you can/should do this and do something better by default. > > There will always be 3rd party applications that don't translate the > > names, > > And apps that won't parse your config file but can be pointed at a default > symlink There are many implementations that all work. Symlinks are one, config files are another. I've considered both and made the choice I believe is best. A choice must be made, and someone has to do the work. If I had picked symlinks someone else would complain. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a lonely amnesiac cowboy whom everyone believes is mad. She's an artistic Buddhist opera singer operating on the wrong side of the law. They fight crime! From jwboyer at jdub.homelinux.org Mon Mar 19 14:20:25 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 19 Mar 2007 09:20:25 -0500 Subject: [BUG] Fast User Switching In-Reply-To: <6e24a8e80703190705g119fad6dt76713ea6481bdc98@mail.gmail.com> References: <6e24a8e80703190705g119fad6dt76713ea6481bdc98@mail.gmail.com> Message-ID: <1174314025.30079.9.camel@zod.rchland.ibm.com> On Mon, 2007-03-19 at 15:05 +0100, Mark wrote: > Hey, > > i`m having a strange bug in Fedora Core 7 latest version with all > updates. File it in bugzilla please. josh From emmanuel.seyman at club-internet.fr Mon Mar 19 14:23:45 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Mon, 19 Mar 2007 15:23:45 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174312455.30079.7.camel@zod.rchland.ibm.com> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> <17918.36890.861729.982547@zebedee.pink> <1174312455.30079.7.camel@zod.rchland.ibm.com> Message-ID: <20070319142345.GA7565@orient.maison.lan> * Josh Boyer [19/03/2007 15:00]: > > > Ralf Corsepius writes: > > > > So don't do that, then. Fedora doesn't require anyone to yum update openoffice. > > That isn't a particularly helpful comment. Telling people to not update > packages is actually really bad. Think of security issues, etc. The > kernel itself is 16MiB or so, and that can't be a speed download on a > link like that either. Ralf isn't telling people not to update OOo, he's telling them to not do so using yum. > Anyway, there really isn't a nice solution to the problem but blatantly > telling someone "don't do that" is pretty asinine. Can't people use the Fedora Respin CDs/DVDs to update (after getting them shipped to them) ? Emmanuel From aph at redhat.com Mon Mar 19 14:26:39 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 19 Mar 2007 14:26:39 +0000 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174312455.30079.7.camel@zod.rchland.ibm.com> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> <17918.36890.861729.982547@zebedee.pink> <1174312455.30079.7.camel@zod.rchland.ibm.com> Message-ID: <17918.40351.521897.32976@zebedee.pink> Josh Boyer writes: > On Mon, 2007-03-19 at 13:28 +0000, Andrew Haley wrote: > > Ralf Corsepius writes: > > > > > >From my experience (I've used Fedora with both ISDN and with > > > DSL Lite), Fedora with ISDN or modem is plain unusable, with > > > "DSL Lite", the situation is "bearable", but isn't fun (an > > > openoffice update takes a working-day). > > > > So don't do that, then. Fedora doesn't require anyone to yum > > update openoffice. > > That isn't a particularly helpful comment. Look at it this way: if you really need openoffice updated, then update it. But saying that Fedora *requires* broadband because only then can you have continuous updates is nonsense. What about everyone else in the world? *Of course* it's good to have updates, and everybody who can get them should, but is it really so important that without them one would rather not even boot Fedora/whatever? > Telling people to not update packages is actually really bad. We're talking about people who claim they can't get updates. > Think of security issues, etc. The kernel itself is 16MiB or so, > and that can't be a speed download on a link like that either. > > Anyway, there really isn't a nice solution to the problem but > blatantly telling someone "don't do that" is pretty asinine. That's an opinion you get to have. Andrew. From aph at redhat.com Mon Mar 19 14:27:24 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 19 Mar 2007 14:27:24 +0000 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <20070319142345.GA7565@orient.maison.lan> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> <17918.36890.861729.982547@zebedee.pink> <1174312455.30079.7.camel@zod.rchland.ibm.com> <20070319142345.GA7565@orient.maison.lan> Message-ID: <17918.40396.831776.810211@zebedee.pink> Emmanuel Seyman writes: > * Josh Boyer [19/03/2007 15:00]: > > > > > Ralf Corsepius writes: > > > > > > So don't do that, then. Fedora doesn't require anyone to yum update openoffice. > > > > That isn't a particularly helpful comment. Telling people to not update > > packages is actually really bad. Think of security issues, etc. The > > kernel itself is 16MiB or so, and that can't be a speed download on a > > link like that either. > > Ralf isn't telling people not to update OOo, he's telling them to not do so > using yum. I think you're getting your attributions mixed up. Andrew. From markg85 at gmail.com Mon Mar 19 14:29:20 2007 From: markg85 at gmail.com (Mark) Date: Mon, 19 Mar 2007 15:29:20 +0100 Subject: [BUG] Fast User Switching In-Reply-To: <1174314025.30079.9.camel@zod.rchland.ibm.com> References: <6e24a8e80703190705g119fad6dt76713ea6481bdc98@mail.gmail.com> <1174314025.30079.9.camel@zod.rchland.ibm.com> Message-ID: <6e24a8e80703190729u6aad1fcdu6c98a5f6fda67385@mail.gmail.com> Sorry but i won`t. this is my last bug that i reported there: https://bugzilla.redhat.com/bugzilla//show_bug.cgi?id=232044 and it isn`t even solved yet. not even a reply so i will just discus it here. 2007/3/19, Josh Boyer : > > On Mon, 2007-03-19 at 15:05 +0100, Mark wrote: > > Hey, > > > > i`m having a strange bug in Fedora Core 7 latest version with all > > updates. > > File it in bugzilla please. > > josh > > -- > 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 rc040203 at freenet.de Mon Mar 19 14:31:21 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Mar 2007 15:31:21 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE96D1.4010404@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <1174300182.3667.5.camel@mccallum.corsepiu.local> <45FE6797.2010307@fedoraproject.org> <1174301778.3667.26.camel@mccallum.corsepiu.local> <45FE70FC.4000100@fedoraproject.org> <1174310992.3667.57.camel@mccallum.corsepiu.local> <45FE914C.3000201@fedoraproject.org> <1174312385.3667.67.camel@mccallum.corsepiu.local> <45FE96D1.4010404@fedoraproject.org> Message-ID: <1174314681.3667.94.camel@mccallum.corsepiu.local> On Mon, 2007-03-19 at 19:27 +0530, Rahul Sundaram wrote: > Ralf Corsepius wrote: > > On Mon, 2007-03-19 at 19:04 +0530, Rahul Sundaram wrote: > >> Ralf Corsepius wrote: > >>> On Mon, 2007-03-19 at 16:46 +0530, Rahul Sundaram wrote: > >>>> Ralf Corsepius wrote: > >>>>> That's why I say "weak spot" - There is no "one-fits-all set of daemons > >>>>> to enable/disable" - Each situation is different, but there is hardly > >>>>> any means to customize an installation for an individual situation > >>>>> during installation with Fedora. > >>>> Anaconda, Kickstart, targeted and custom spins enable you to customize > >>>> Fedora for individual situations. Don't they? > >>> Once you have a system up, or if you already have a system up, yes, > >>> there are means to customize, but during installation (esp. first time > >>> installation) - no, to a large extend, this doesn't apply. > >> What are you talking about? > > Two examples: > > > > * user management - There is no way to reserve uids before installation, > > there is no way to custiomize nsswitch.conf, there is no way to > > configure network'ed homes. > > > > * kickstart is only a means for advanced users, who are familiar with > > RH-based distros. It's not suiteable to "first-timers". > > Seem completely unrelated to daemons which is the topic of conversation. What? You've never installed a fedora client in an existing network? I realize, this live cd is addressing standalone situations only. Ralf From sundaram at fedoraproject.org Mon Mar 19 14:32:38 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 19 Mar 2007 20:02:38 +0530 Subject: [BUG] Fast User Switching In-Reply-To: <6e24a8e80703190729u6aad1fcdu6c98a5f6fda67385@mail.gmail.com> References: <6e24a8e80703190705g119fad6dt76713ea6481bdc98@mail.gmail.com> <1174314025.30079.9.camel@zod.rchland.ibm.com> <6e24a8e80703190729u6aad1fcdu6c98a5f6fda67385@mail.gmail.com> Message-ID: <45FE9F06.3090100@fedoraproject.org> Mark wrote: > Sorry but i won`t. > this is my last bug that i reported there: > https://bugzilla.redhat.com/bugzilla//show_bug.cgi?id=232044 > and it isn`t even solved yet. > not even a reply so i will just discus it here. You have even less of a chance discussing it here since not all developers are watching all the conversations on these mailing lists while bug reports get assigned to the package maintainers. Might be better to post with a bugzilla report if you want to. Rahul From rc040203 at freenet.de Mon Mar 19 14:32:24 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Mar 2007 15:32:24 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174312455.30079.7.camel@zod.rchland.ibm.com> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> <17918.36890.861729.982547@zebedee.pink> <1174312455.30079.7.camel@zod.rchland.ibm.com> Message-ID: <1174314745.3667.95.camel@mccallum.corsepiu.local> On Mon, 2007-03-19 at 08:54 -0500, Josh Boyer wrote: > On Mon, 2007-03-19 at 13:28 +0000, Andrew Haley wrote: > > Ralf Corsepius writes: > > > > > >From my experience (I've used Fedora with both ISDN and with DSL Lite), > > > Fedora with ISDN or modem is plain unusable, with "DSL Lite", the > > > situation is "bearable", but isn't fun (an openoffice update takes a > > > working-day). > > > > So don't do that, then. Fedora doesn't require anyone to yum update openoffice. > > That isn't a particularly helpful comment. Telling people to not update > packages is actually really bad. Frankly speaking, this was what I did back then. I postponed updating and explicitly launched update-jobs it at times, I was sure not to be interactively sitting in front of the system. > Think of security issues, etc. The > kernel itself is 16MiB or so, and that can't be a speed download on a > link like that either. Now consider having several machines with different archs on a network being interfaced to the public over a low bandwidth connection. ... The only way I could handle this situation was to selectively mirror public yum-repos and recreate local ones from them. > Anyway, there really isn't a nice solution to the problem but blatantly > telling someone "don't do that" is pretty asinine. Exactly, you've just noticed the reason for what I previously said. Also, you now know why the ability to upgrade from one version to another on-the-fly appears as a (so far missing) key-feature for Fedora to me (This only downloads those packages which are really needed - Download on demand - This is way less than what's in the repos or on CDs/DVD) Ralf From markg85 at gmail.com Mon Mar 19 14:32:54 2007 From: markg85 at gmail.com (Mark) Date: Mon, 19 Mar 2007 15:32:54 +0100 Subject: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> Message-ID: <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> Just noticed: Status CLOSED Resolution NOTABUG that`s for this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213768 Why is it closed and why is it not a bug if there is NO info in that thread on how to resolve it (except the last post i just made there) there isn`t even a link to a page anywhere that describes on how to solve it. 2007/3/19, Mark : > Hey, > > First the "Mounted partitions are not showing up" bug. > this bus is also in Fedora core 6 and i submitted it here: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213768 > and i must say that i`m really amazed that this bug is in it so long and that not a single person seems to complain about it. > i don`t know how it is with you guys but i would like my mounted partitions to show up in the computer window like they are supposed to do. > > so about 6 months ago (or more) i found out about this bug and not a single people of the bugzilla stuff could point me to a fix or another solution.. therefore i also wonder if the bugzilla is even usefull if this forum (actually the skilled members there): http://gathering.tweakers.net/forum/list_messages/1172605///fedora%2Cpartities(dutch, tweakers.net ) could solve my problem in just a few days. > > and isn`t there a site where all the pilicy`s are listed and described? > > now as annoying as the bug is.. the fix is quite simple. > locate and destroy "99-redhat-storage-policy-fixed-drives.fdi ". (or: rename it, vaporize it, whatever.. as long as linux can`t see the file anymore) > > i would also like to ask the fedora people if they could please fix this in the next fedora version (so in Core 7). as of this moment this bug is in fedora. > > Now for the dvd link that`s not correct. > the "CD-RW/DVD?RW Drive" link in: computer:/// is very nice but not working. i`m getting: "unable to mount media" and it`s working fine when i mount it manually. the mount point i use is /dev/dvd mounted to /mnt/dvd so.. something wrong in the cd/dvd checking script? (if it`s even existing) > > @all of fedora: > good job everyone!! i like it alot. though you will probable see some more bug reports of me here on this list. > > if you need more info about any of those bugs or some logs.. just ask me. > good luck fixing, > Mark. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at jdub.homelinux.org Mon Mar 19 14:32:39 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 19 Mar 2007 09:32:39 -0500 Subject: [BUG] Fast User Switching In-Reply-To: <6e24a8e80703190729u6aad1fcdu6c98a5f6fda67385@mail.gmail.com> References: <6e24a8e80703190705g119fad6dt76713ea6481bdc98@mail.gmail.com> <1174314025.30079.9.camel@zod.rchland.ibm.com> <6e24a8e80703190729u6aad1fcdu6c98a5f6fda67385@mail.gmail.com> Message-ID: <1174314759.30079.12.camel@zod.rchland.ibm.com> On Mon, 2007-03-19 at 15:29 +0100, Mark wrote: > Sorry but i won`t. > this is my last bug that i reported there: > https://bugzilla.redhat.com/bugzilla//show_bug.cgi?id=232044 > and it isn`t even solved yet. > not even a reply so i will just discus it here. You opened that bug 6 days ago and you expect it to be solved already? Give people time. Posting on this list won't get you fixes any sooner, and is likely to be ignored even more. josh From nicolas.mailhot at laposte.net Mon Mar 19 14:43:54 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 15:43:54 +0100 (CET) Subject: User directories integration - request for help In-Reply-To: <1174313320.3035.146.camel@greebo> References: <1173986979.3051.0.camel@sb-home.lan> <1173988854.3535.0.camel@localhost.localdomain> <1173988978.3051.6.camel@sb-home.lan> <45F9A7A0.3010607@fedoraproject.org> <20070315230108.GA3261@free.fr> <45F9D457.5040009@fedoraproject.org> <20070315234546.GB3261@free.fr> <45F9DF3D.7030305@fedoraproject.org> <45F9EC76.2090300@web.de> <45F9EF29.6020901@fedoraproject.org> <20070316123536.GC2923@free.fr> <1174294196.3035.8.camel@greebo> <45FE4FC7.4070106@volny.cz> <1174297007.3035.48.camel@greebo> <1174297898.3667.1.camel@mccallum.corsepiu.local> <1174299192.3035.59.camel@greebo> <1174300942.3667.18.camel@mccallum.corsepiu.local> <1174302071.3035.104.camel@greebo> <35639.192.54.193.51.1174306199.squirrel@rousalka.dyndns.org> <1174313320.3035.146.camel@greebo> Message-ID: <14499.192.54.193.51.1174315434.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 15:08, Alexander Larsson a ?crit : > On Mon, 2007-03-19 at 13:09 +0100, Nicolas Mailhot wrote: >> Le Lun 19 mars 2007 12:01, Alexander Larsson a ?crit : >> > test -f ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs && source >> > ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs >> > tar czvf /tmp/music.tar.gz ${XDG_MUSIC_DIR} >> >> Add looping to handle multi-user setups, and you get the magnitude of >> problems to replicate a simple ls /home/*/.config/xdg-dir/music/ > > I don't see that sort of operation as being very common though. You lack imagination ;) > The > special directories are not some set-in-stones kind of LSB filesystem > hierarchy. Its just a helping system that gets you some nice defaults > for applications so that things can start up in a slightly nicer way > than everything in ~/. You can't assume that a users files are in the > xdg-user-dirs MUSIC directory any more than you can assume a hardcoded > ~/Music. You can assume in CLI just like you're assuming in GUI Also you're consumming very precious desktop and home estate with your stuff, you bet it will be central to apps. >> > And translation of the filenames in the UI will *never* be complete. >> >> More reason *not* to pre-create directories with faulty names, and ask >> users on creation what they would like to call their directories. > > How is this different from not creating the folders at all. When your > file selector defaults in $HOME you can just create your Music directory > and select it. The idea is that a lot of people don't even know that you > can/should do this and do something better by default. When the user launches an app that needs one of your special folders, and if it's not already registered (via symlinks or conf files), you propose to create it. Advantages : - the user is doing stuff related to this dir, you'll have this attention - you can explain what the folder will be used for, he won't be surprised when other apps use it - you can propose a standard name - he can correct it if the translation is wrong for his locale, he already has a directory for this use, or he thinks your default choice is stupid for any other reason (that will happen more often than you think) Contrast it with pre-creation of folders that may fit or not with the user habits, may use the right locale or not, may be properly translated or not, may be used by the user or not (some users will never do music or pictures), may duplicate existing folders or not, etc etc Sometimes asking the user is the right thing (as long as you keep light touches) >> > There will always be 3rd party applications that don't translate the >> > names, >> >> And apps that won't parse your config file but can be pointed at a >> default symlink > > There are many implementations that all work. [...] > If I had picked symlinks someone else would complain. That's a poor argument. No need to waste fedora-devel time if your choices are set in stone -- Nicolas Mailhot From markg85 at gmail.com Mon Mar 19 14:49:51 2007 From: markg85 at gmail.com (Mark) Date: Mon, 19 Mar 2007 15:49:51 +0100 Subject: [BUG] Fast User Switching In-Reply-To: <1174314759.30079.12.camel@zod.rchland.ibm.com> References: <6e24a8e80703190705g119fad6dt76713ea6481bdc98@mail.gmail.com> <1174314025.30079.9.camel@zod.rchland.ibm.com> <6e24a8e80703190729u6aad1fcdu6c98a5f6fda67385@mail.gmail.com> <1174314759.30079.12.camel@zod.rchland.ibm.com> Message-ID: <6e24a8e80703190749y45460fa7x2874a6c94f127698@mail.gmail.com> sorry, but this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213768 is there for months and no info on how to resolve it yet it is closed and marked as not a bug!! But oke.. i will report this bug on that bugzilla. just know that if i`m not getting any reply`s on my bug report and the status gets from new to "closed" and the solution gets to "notabug" without any notification of what it might be if it`s not a bug... than i won`t leave any more bug reports there. here is my bug report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232923 i sure hope that something is being done with this bug report. 2007/3/19, Josh Boyer : > > On Mon, 2007-03-19 at 15:29 +0100, Mark wrote: > > Sorry but i won`t. > > this is my last bug that i reported there: > > https://bugzilla.redhat.com/bugzilla//show_bug.cgi?id=232044 > > and it isn`t even solved yet. > > not even a reply so i will just discus it here. > > You opened that bug 6 days ago and you expect it to be solved already? > Give people time. Posting on this list won't get you fixes any sooner, > and is likely to be ignored even more. > > josh > > -- > 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 rc040203 at freenet.de Mon Mar 19 14:50:29 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Mar 2007 15:50:29 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <17918.40351.521897.32976@zebedee.pink> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> <17918.36890.861729.982547@zebedee.pink> <1174312455.30079.7.camel@zod.rchland.ibm.com> <17918.40351.521897.32976@zebedee.pink> Message-ID: <1174315830.3667.111.camel@mccallum.corsepiu.local> On Mon, 2007-03-19 at 14:26 +0000, Andrew Haley wrote: > Josh Boyer writes: > > On Mon, 2007-03-19 at 13:28 +0000, Andrew Haley wrote: > > > Ralf Corsepius writes: > > > > > > > >From my experience (I've used Fedora with both ISDN and with > > > > DSL Lite), Fedora with ISDN or modem is plain unusable, with > > > > "DSL Lite", the situation is "bearable", but isn't fun (an > > > > openoffice update takes a working-day). > > > > > > So don't do that, then. Fedora doesn't require anyone to yum > > > update openoffice. > > > > That isn't a particularly helpful comment. > > Look at it this way: if you really need openoffice updated, then > update it. Well, then you might be able to answer why Core has replaced ca. half of the core distro since FC6's initial roll-out if there weren't sufficient reasons to do so? > But saying that Fedora *requires* broadband because only > then can you have continuous updates is nonsense. Your opinion. IMO, fedora is not usable without "rolling" updates, which are impossible to do without sufficient bandwidth. Selective updates is an escape to isolated cases (such as openoffice or eclipse) but aren't a suitable approach as a general solution. Ralf From notting at redhat.com Mon Mar 19 14:53:55 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Mar 2007 10:53:55 -0400 Subject: kernel config question In-Reply-To: <1174232436.3461.619.camel@pmac.infradead.org> References: <1174180224.30317.3.camel@sonlaptop> <1174232436.3461.619.camel@pmac.infradead.org> Message-ID: <20070319145355.GB18278@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > > Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits > > still need this? Is work being done to eliminate the need for this? > > Hopefully. It's causing oopses. We should ideally have bugs filed for > anything in userspace which needs it. It's causing oopses, so we should fix userspace because the kernel is busted? It's known what needs it, it's unlikely to be fixed before F7. Bill From rc040203 at freenet.de Mon Mar 19 15:00:36 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Mar 2007 16:00:36 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <20070319142345.GA7565@orient.maison.lan> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> <17918.36890.861729.982547@zebedee.pink> <1174312455.30079.7.camel@zod.rchland.ibm.com> <20070319142345.GA7565@orient.maison.lan> Message-ID: <1174316437.3667.120.camel@mccallum.corsepiu.local> On Mon, 2007-03-19 at 15:23 +0100, Emmanuel Seyman wrote: > * Josh Boyer [19/03/2007 15:00]: > > > > > Ralf Corsepius writes: > > > > > > So don't do that, then. Fedora doesn't require anyone to yum update openoffice. > > > > That isn't a particularly helpful comment. Telling people to not update > > packages is actually really bad. Think of security issues, etc. The > > kernel itself is 16MiB or so, and that can't be a speed download on a > > link like that either. > > Ralf isn't telling people not to update OOo, he's telling them to not do so > using yum. No, this had never been my intention. I only said: Updating Fedora using yum over low bandwidth connections is hard, and IMO qualifies Fedora not to be suitable for uses without sufficient bandwidth. Ralf From dwmw2 at infradead.org Mon Mar 19 15:16:35 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 19 Mar 2007 15:16:35 +0000 Subject: kernel config question In-Reply-To: <20070319145355.GB18278@nostromo.devel.redhat.com> References: <1174180224.30317.3.camel@sonlaptop> <1174232436.3461.619.camel@pmac.infradead.org> <20070319145355.GB18278@nostromo.devel.redhat.com> Message-ID: <1174317395.3392.146.camel@pmac.infradead.org> On Mon, 2007-03-19 at 10:53 -0400, Bill Nottingham wrote: > David Woodhouse (dwmw2 at infradead.org) said: > > > Any reason why CONFIG_SYSFS_DEPRECATED is set? Which user land bits > > > still need this? Is work being done to eliminate the need for this? > > > > Hopefully. It's causing oopses. We should ideally have bugs filed for > > anything in userspace which needs it. > > It's causing oopses, so we should fix userspace because the kernel is > busted? Because a _deprecated_ feature in the kernel is busted, you mean? The answer would be 'maybe'. I can't say; I don't know what needs it. I have a crappy workaround which disables _some_ of what CONFIG_SYSFS_DEPRECATED does, but I don't know if that's the bit which this obsolete userspace stuff is using. > It's known what needs it, it's unlikely to be fixed before F7. Bug numbers or more details? The workaround of which I speak is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227893#c9 -- dwmw2 From notting at redhat.com Mon Mar 19 15:13:44 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Mar 2007 11:13:44 -0400 Subject: kernel config question In-Reply-To: <1174317395.3392.146.camel@pmac.infradead.org> References: <1174180224.30317.3.camel@sonlaptop> <1174232436.3461.619.camel@pmac.infradead.org> <20070319145355.GB18278@nostromo.devel.redhat.com> <1174317395.3392.146.camel@pmac.infradead.org> Message-ID: <20070319151344.GA20687@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > Because a _deprecated_ feature in the kernel is busted, you mean? Yes. Kernel oopses -> kernel broken. > The answer would be 'maybe'. I can't say; I don't know what needs it. The installer. > > It's known what needs it, it's unlikely to be fixed before F7. > > Bug numbers or more details? The workaround of which I speak is > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227893#c9 It's 'port the installer to use hal & udev', there's not a bug number, probably because it's generally understood that it's not happening right now. Bill From ajackson at redhat.com Mon Mar 19 15:08:20 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 19 Mar 2007 11:08:20 -0400 Subject: No shape and sync extensions in xorg? In-Reply-To: <45FD7A49.3000900@conversis.de> References: <45FD7A49.3000900@conversis.de> Message-ID: <1174316900.10900.3.camel@localhost.localdomain> On Sun, 2007-03-18 at 18:43 +0100, Dennis Jacobfeuerborn wrote: > Hi, > When I try to enable the desktop effects (ie. compiz) I get the following > output: > > [dennis at nexus ~]$ desktop-effects > compiz: No sync extension > The program 'gnome-window-decorator' received an X Window System error. > This probably reflects a bug in the program. > The error was 'BadMatch (invalid parameter attributes)'. > (Details: serial 426 error_code 8 request_code 72 minor_code 0) > (Note to programmers: normally, X errors are reported asynchronously; > that is, you will receive the error a while after causing it. > To debug your program, run it with the --sync command line > option to change this behavior. You can then get a meaningful > backtrace from your debugger if you break on the gdk_x_error() function.) > Xlib: extension "SHAPE" missing on display ":0.0". Your X config file has a Modules section, and it doesn't contain a line for extmod. You claim to be using the nv driver later in the thread, but compiz isn't going to work with that setup, period, because we don't have a DRI driver for nvidia cards yet. More likely you installed nvidia's closed driver, and the install script for same added a Modules section that it didn't need to. - ajax From ajackson at redhat.com Mon Mar 19 15:09:53 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 19 Mar 2007 11:09:53 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE8C76.5030405@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> Message-ID: <1174316993.10900.5.camel@localhost.localdomain> On Mon, 2007-03-19 at 18:43 +0530, Rahul Sundaram wrote: > Jarod Wilson wrote: > > > > Everyone please kindly read the cpuspeed initscript before continuing to > > hypothesize about it. It does indeed already look for necessary support, > > and silently exits without doing a thing it its not present. > > > > /me is the cpuspeed maintainer... :) > > It would do that everytime on bootup though. Right? Can we make it > disable itself if the support is not there on first run? While chasing down every fork() in the init process is certainly a noble goal I think there are bigger fish to fry. - ajax From emmanuel.seyman at club-internet.fr Mon Mar 19 15:27:50 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Mon, 19 Mar 2007 16:27:50 +0100 Subject: [BUG] Fast User Switching In-Reply-To: <6e24a8e80703190749y45460fa7x2874a6c94f127698@mail.gmail.com> References: <6e24a8e80703190705g119fad6dt76713ea6481bdc98@mail.gmail.com> <1174314025.30079.9.camel@zod.rchland.ibm.com> <6e24a8e80703190729u6aad1fcdu6c98a5f6fda67385@mail.gmail.com> <1174314759.30079.12.camel@zod.rchland.ibm.com> <6e24a8e80703190749y45460fa7x2874a6c94f127698@mail.gmail.com> Message-ID: <20070319152750.GA7807@orient.maison.lan> * Mark [19/03/2007 16:09]: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213768 > is there for months and no info on how to resolve it yet it is closed and > marked as not a bug!! If you find this inappropriate, it would probably be best if you hadn't closed the bug as NOTABUG in the first place. If the issue still persists, feel free to re-open the bug. Emmanuel From dwmw2 at infradead.org Mon Mar 19 15:29:09 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 19 Mar 2007 15:29:09 +0000 Subject: kernel config question In-Reply-To: <20070319151344.GA20687@nostromo.devel.redhat.com> References: <1174180224.30317.3.camel@sonlaptop> <1174232436.3461.619.camel@pmac.infradead.org> <20070319145355.GB18278@nostromo.devel.redhat.com> <1174317395.3392.146.camel@pmac.infradead.org> <20070319151344.GA20687@nostromo.devel.redhat.com> Message-ID: <1174318149.3392.153.camel@pmac.infradead.org> On Mon, 2007-03-19 at 11:13 -0400, Bill Nottingham wrote: > David Woodhouse (dwmw2 at infradead.org) said: > > Because a _deprecated_ feature in the kernel is busted, you mean? > > Yes. Kernel oopses -> kernel broken. And CONFIG_SYSFS_DEPRECATED=n --> kernel no longer oopsing. It's probably still buggy, but at least the bug is hidden. > > The answer would be 'maybe'. I can't say; I don't know what needs it. > > The installer. > > > > It's known what needs it, it's unlikely to be fixed before F7. > > > > Bug numbers or more details? The workaround of which I speak is > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227893#c9 > > It's 'port the installer to use hal & udev', there's not a bug > number, probably because it's generally understood that it's not > happening right now. OK, so since the above workaround only removes some environment variables which were being passed to the hotplug/udev script, it shouldn't matter that they're now missing, because the installer wasn't using them anyway? It's not a very nice fix, and we still have a kernel bug. But at least it's a possibility. -- dwmw2 From ajackson at redhat.com Mon Mar 19 15:13:48 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 19 Mar 2007 11:13:48 -0400 Subject: [BUG] Fast User Switching In-Reply-To: <6e24a8e80703190749y45460fa7x2874a6c94f127698@mail.gmail.com> References: <6e24a8e80703190705g119fad6dt76713ea6481bdc98@mail.gmail.com> <1174314025.30079.9.camel@zod.rchland.ibm.com> <6e24a8e80703190729u6aad1fcdu6c98a5f6fda67385@mail.gmail.com> <1174314759.30079.12.camel@zod.rchland.ibm.com> <6e24a8e80703190749y45460fa7x2874a6c94f127698@mail.gmail.com> Message-ID: <1174317228.10900.8.camel@localhost.localdomain> On Mon, 2007-03-19 at 15:49 +0100, Mark wrote: > sorry, but this bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213768 > is there for months and no info on how to resolve it yet it is closed > and marked as not a bug!! According to the change history for that bug, you're the one that closed it. So, uh. Hmm. - ajax From axel.azerty at laposte.net Mon Mar 19 15:31:55 2007 From: axel.azerty at laposte.net (Axel) Date: Mon, 19 Mar 2007 16:31:55 +0100 Subject: No shape and sync extensions in xorg? In-Reply-To: <45FDC849.5090203@conversis.de> References: <45FD7A49.3000900@conversis.de> <1174245743.5715.10.camel@tuxhugs> <45FDC849.5090203@conversis.de> Message-ID: <45FEACEB.1070704@laposte.net> Dennis Jacobfeuerborn a ?crit : > > I'm using the "nv" driver and the card (well, it's on-board) is > identified as "nVidia Corporation GeForce 6100 nForce 430". > > Xorg says "Chipset Unknown NVIDIA chip found" in the log but except > for some graphical glitches it seems to work ok. Cursors don't get > drawn correctly and sometimes parts of the terminal text output appear > a bit bolder then regular text (though not bold as in "bold font", > just a tiny bit bolder as if the anti-aliasing is a bit off or there > is some sort of pixel/rounding error). AFAIK the nv driver doesn't provide 3D rendering for such gpu , you should use the nvidia closed source driver. It may add a line " Module glx" in your module section. I had to disable it in order to have the desktop effects working. Some other people had to not delete this line. Here's my post about this : http://www.redhat.com/archives/fedora-list/2007-March/msg02212.html Axel From notting at redhat.com Mon Mar 19 15:28:44 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Mar 2007 11:28:44 -0400 Subject: kernel config question In-Reply-To: <1174318149.3392.153.camel@pmac.infradead.org> References: <1174180224.30317.3.camel@sonlaptop> <1174232436.3461.619.camel@pmac.infradead.org> <20070319145355.GB18278@nostromo.devel.redhat.com> <1174317395.3392.146.camel@pmac.infradead.org> <20070319151344.GA20687@nostromo.devel.redhat.com> <1174318149.3392.153.camel@pmac.infradead.org> Message-ID: <20070319152844.GA22192@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > > It's 'port the installer to use hal & udev', there's not a bug > > number, probably because it's generally understood that it's not > > happening right now. > > OK, so since the above workaround only removes some environment > variables which were being passed to the hotplug/udev script, it > shouldn't matter that they're now missing, because the installer wasn't > using them anyway? !CONFIG_SYSFS_DEPRECATED changes the sysfs layout significantly. (Hey, when they say the kernel doesn't have a fixed ABI, they aren't kidding.) This breaks the hardware detection logic used by the installer in about five or six different places. Bill From markg85 at gmail.com Mon Mar 19 15:37:42 2007 From: markg85 at gmail.com (Mark) Date: Mon, 19 Mar 2007 16:37:42 +0100 Subject: [BUG] Fast User Switching In-Reply-To: <1174317228.10900.8.camel@localhost.localdomain> References: <6e24a8e80703190705g119fad6dt76713ea6481bdc98@mail.gmail.com> <1174314025.30079.9.camel@zod.rchland.ibm.com> <6e24a8e80703190729u6aad1fcdu6c98a5f6fda67385@mail.gmail.com> <1174314759.30079.12.camel@zod.rchland.ibm.com> <6e24a8e80703190749y45460fa7x2874a6c94f127698@mail.gmail.com> <1174317228.10900.8.camel@localhost.localdomain> Message-ID: <6e24a8e80703190837l73b17f01n5ebec43b28832c9b@mail.gmail.com> than it must have happened by accident. it`s open again. i didn`t even know that i could close a bug ^_^ 2007/3/19, Adam Jackson : > > On Mon, 2007-03-19 at 15:49 +0100, Mark wrote: > > sorry, but this bug: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213768 > > is there for months and no info on how to resolve it yet it is closed > > and marked as not a bug!! > > According to the change history for that bug, you're the one that closed > it. So, uh. Hmm. > > - ajax > > -- > 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 dwmw2 at infradead.org Mon Mar 19 15:54:39 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 19 Mar 2007 15:54:39 +0000 Subject: kernel config question In-Reply-To: <20070319152844.GA22192@nostromo.devel.redhat.com> References: <1174180224.30317.3.camel@sonlaptop> <1174232436.3461.619.camel@pmac.infradead.org> <20070319145355.GB18278@nostromo.devel.redhat.com> <1174317395.3392.146.camel@pmac.infradead.org> <20070319151344.GA20687@nostromo.devel.redhat.com> <1174318149.3392.153.camel@pmac.infradead.org> <20070319152844.GA22192@nostromo.devel.redhat.com> Message-ID: <1174319679.3392.157.camel@pmac.infradead.org> On Mon, 2007-03-19 at 11:28 -0400, Bill Nottingham wrote: > > OK, so since the above workaround only removes some environment > > variables which were being passed to the hotplug/udev script, it > > shouldn't matter that they're now missing, because the installer wasn't > > using them anyway? > > !CONFIG_SYSFS_DEPRECATED changes the sysfs layout significantly. (Hey, > when they say the kernel doesn't have a fixed ABI, they aren't kidding.) > > This breaks the hardware detection logic used by the installer in about > five or six different places. But changes to environment variables in the hotplug script invocations shouldn't hurt, right? -- dwmw2 From tmz at pobox.com Mon Mar 19 16:02:04 2007 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 19 Mar 2007 12:02:04 -0400 Subject: Kernel BUG caused by iwlwifi In-Reply-To: <20070319123811.GB18472@redhat.com> References: <1174295527.2881.4.camel@localhost.localdomain> <20070319123811.GB18472@redhat.com> Message-ID: <20070319160204.GO14738@psilocybe.teonanacatl.org> John, John W. Linville wrote: > It is not in the upstream kernel, so only the RH bugzilla would > be appropriate. Please make sure to CC: me. Thanks for adding the iwlwifi module. The firmware should be making its way into Fedora real soon now. See BZ# 230096: https://bugzilla.redhat.com/230096 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== You can't make something idiot proof, idiots are too damned creative. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From notting at redhat.com Mon Mar 19 15:56:56 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Mar 2007 11:56:56 -0400 Subject: kernel config question In-Reply-To: <1174319679.3392.157.camel@pmac.infradead.org> References: <1174180224.30317.3.camel@sonlaptop> <1174232436.3461.619.camel@pmac.infradead.org> <20070319145355.GB18278@nostromo.devel.redhat.com> <1174317395.3392.146.camel@pmac.infradead.org> <20070319151344.GA20687@nostromo.devel.redhat.com> <1174318149.3392.153.camel@pmac.infradead.org> <20070319152844.GA22192@nostromo.devel.redhat.com> <1174319679.3392.157.camel@pmac.infradead.org> Message-ID: <20070319155656.GB22192@nostromo.devel.redhat.com> David Woodhouse (dwmw2 at infradead.org) said: > > !CONFIG_SYSFS_DEPRECATED changes the sysfs layout significantly. (Hey, > > when they say the kernel doesn't have a fixed ABI, they aren't kidding.) > > > > This breaks the hardware detection logic used by the installer in about > > five or six different places. > > But changes to environment variables in the hotplug script invocations > shouldn't hurt, right? No, but that's not the reason we have DEPRECATED on. Bill From icon at fedoraproject.org Mon Mar 19 16:18:28 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Mon, 19 Mar 2007 12:18:28 -0400 Subject: Flag Modification Denied Message-ID: Hello, everyone: According to the new procedure, I'm supposed to set "fedora-cvs" flag whenever I'm requesting branches. Actually trying to do that results in: "You tried to request fedora-cvs. Only an authorized user can make this change." How would I go about getting authorized? And, generally, how would I go about getting authorized for any other things that I used to have access to before February? Regards, -- Konstantin Ryabitsev Montr?al, Qu?bec From davej at redhat.com Mon Mar 19 16:23:32 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 19 Mar 2007 12:23:32 -0400 Subject: Pre-release kernel versioning? In-Reply-To: <45FE40B4.4070607@leemhuis.info> References: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> <1174288778.3392.55.camel@pmac.infradead.org> <45FE40B4.4070607@leemhuis.info> Message-ID: <20070319162332.GC813@redhat.com> On Mon, Mar 19, 2007 at 08:50:12AM +0100, Thorsten Leemhuis wrote: > On 19.03.2007 08:19, David Woodhouse wrote: > > On Sun, 2007-03-18 at 18:00 -0400, Michel Salim wrote: > >> Currently each Rawhide pre-release kernel reports as its version > >> number the version number of the previous stable version, rather than > >> the current version. > >> This sometimes causes problems with out-of-kernel modules > > I stopped caring here. [...] > > @davej: This issue was discussed on FudCON Boston. Didn't you indicate > you might want to change it, so that a 2.6.foo-rc kernel actually gets > the proper version (e.g. 2.6.foo and not 2.6.(foo-1) )? Or did I got you > wrong here? We could add the 'real' upstream version in brackets in the uname field so it shows up as .. uname -r 2.6.20-1.2925.fc6debug (2.6.20.3) for eg. Dave -- http://www.codemonkey.org.uk From david at fubar.dk Mon Mar 19 15:55:26 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 19 Mar 2007 11:55:26 -0400 Subject: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> Message-ID: <1174319726.2635.2.camel@zelda.fubar.dk> On Mon, 2007-03-19 at 15:32 +0100, Mark wrote: > Just noticed: > Status CLOSED > Resolution NOTABUG > that`s for this bug: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213768 > > Why is it closed and why is it not a bug if there is NO info in that > thread on how to resolve it (except the last post i just made there) > there isn`t even a link to a page anywhere that describes on how to > solve it. Because the policy right now is to only mount hotpluggable drives and media from drives that accept removable media. Just think about security implications if you had read/write access to the password database on a Windows partition... David From nicolas.mailhot at laposte.net Mon Mar 19 16:30:40 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 17:30:40 +0100 (CET) Subject: Pre-release kernel versioning? In-Reply-To: <20070319162332.GC813@redhat.com> References: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> <1174288778.3392.55.camel@pmac.infradead.org> <45FE40B4.4070607@leemhuis.info> <20070319162332.GC813@redhat.com> Message-ID: <52335.192.54.193.51.1174321840.squirrel@rousalka.dyndns.org> Le Lun 19 mars 2007 17:23, Dave Jones a ?crit : Hi Dave, > We could add the 'real' upstream version in brackets in the uname field > so it shows up as .. > > uname -r > 2.6.20-1.2925.fc6debug (2.6.20.3) Are you violently opposed to 2.6.20.3-1.2925.fc7 for a 2.6.20.3 based kernel and 2.6.21-0.2925.rc4.f7 for a 2.6.21-rc4 based kernel That would make many people happy -- Nicolas Mailhot From notting at redhat.com Mon Mar 19 16:40:06 2007 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Mar 2007 12:40:06 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE5D39.7020002@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> Message-ID: <20070319164006.GC22192@nostromo.devel.redhat.com> Rahul Sundaram (sundaram at fedoraproject.org) said: > Hardware specific - Bluetooth (along with hidd), cups (FC6 even had > smartcard daemon by default). Should check and enable on demand Right. Heck, it's on the feature list. You have patches? :) > Definitely superfluous - firstboot, livecd. Should disable after first > run completely or even remove the packages. These don't do anything at all post-boot - the impact is minimal. You could configure the livecd installer to disable this after install. > Extra - cpuspeed. Needed. > mdmonitor Should probably be spawned off via udev rules. > , netfs, portmap. netfs does jack if noone has configured anything. Again, minimal impact. portmap is needed for NFS, ypbind, etc. > ntpd I suppose firstboot could disable it if you don't configure it. Bill From katzj at redhat.com Mon Mar 19 16:52:57 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 19 Mar 2007 12:52:57 -0400 Subject: Announcing Fedora 7 Test 2 (6.91) -- updates-f7t2.img In-Reply-To: <1173472813.7346.1.camel@localhost.localdomain> References: <200703011112.12348.jkeating@redhat.com> <45F1BD10.5060007@redhat.com> <1173472813.7346.1.camel@localhost.localdomain> Message-ID: <1174323177.14986.12.camel@erebor.boston.redhat.com> On Fri, 2007-03-09 at 15:40 -0500, Paul W. Frields wrote: > On Fri, 2007-03-09 at 12:01 -0800, John Poelstra wrote: > > Jesse Keating said the following on 03/01/2007 08:12 AM Pacific Time: > > > This test release has an rpm ordering issue that seems to affect some people > > > with regard to mkinitrd being installed correctly. If your install seems to > > > stall at installing the kernel and never continues, please try the updates > > > image http://people.redhat.com/~katzj/updates-f7t2.img. Refer to > > > http://fedoraproject.org/wiki/Anaconda/Updates for more information on using > > > updates images. > > > > What are correct steps to view or access exactly what is in the updates-f7t2.img file ? > > > > # file updates-f7t2.img > > updates-f7t2.img: gzip compressed data, from Unix, last modified: Tue Feb 27 11:02:28 2007, max compression > > > > gunzip isn't doing the trick for me. > > > > Coming up empty on google and the last part of this pages implies that it is a simple image that can be mounted loopback: http://fedoraproject.org/wiki/Anaconda/Updates > > Hmm, > > $ gunzip -c updates-f7t2.img | file - > /dev/stdin: ASCII cpio archive (SVR4 with CRC) Yep -- an updates.img can now be a gzipped cpio ball now (handy for creating/looking at without needing root). Just 'zcat updates.img |cpio -id' and you should be good Jeremy From aph at redhat.com Mon Mar 19 16:54:02 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 19 Mar 2007 16:54:02 +0000 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174315830.3667.111.camel@mccallum.corsepiu.local> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> <17918.36890.861729.982547@zebedee.pink> <1174312455.30079.7.camel@zod.rchland.ibm.com> <17918.40351.521897.32976@zebedee.pink> <1174315830.3667.111.camel@mccallum.corsepiu.local> Message-ID: <17918.49194.259929.212056@zebedee.pink> Ralf Corsepius writes: > On Mon, 2007-03-19 at 14:26 +0000, Andrew Haley wrote: > > Josh Boyer writes: > > > On Mon, 2007-03-19 at 13:28 +0000, Andrew Haley wrote: > > > > Ralf Corsepius writes: > > > > > > > > > >From my experience (I've used Fedora with both ISDN and with > > > > > DSL Lite), Fedora with ISDN or modem is plain unusable, with > > > > > "DSL Lite", the situation is "bearable", but isn't fun (an > > > > > openoffice update takes a working-day). > > > > > > > > So don't do that, then. Fedora doesn't require anyone to yum > > > > update openoffice. > > > > > > That isn't a particularly helpful comment. > > > > Look at it this way: if you really need openoffice updated, then > > update it. > > Well, then you might be able to answer why Core has replaced ca. half of > the core distro since FC6's initial roll-out if there weren't sufficient > reasons to do so? Sigh. One of the advantages of Fedora is that we do frequent updates so that you can be sure that bugs are fixed in a timely manner. That doesn't mean that Fedora is totally useless unless you have every single update the instant it is released. > > But saying that Fedora *requires* broadband because only > > then can you have continuous updates is nonsense. > Your opinion. It is. Andrew. From khc at pm.waw.pl Mon Mar 19 17:04:16 2007 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Mon, 19 Mar 2007 18:04:16 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174310432.3667.53.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Mon, 19 Mar 2007 14:20:32 +0100") References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > I.e. I'd claim Fedora to require a > minimum bandwidth: ~300kb/s > recommended bandwidth >= 1000kb/s 350 kbps = ~ 3.5 GB a day. Not sure what problems are you talking about. Slow mirrors maybe? Your fast connection wouldn't make them faster. I suspect some location-related problems (does the mirror list differs based on IP/reverse DNS name/etc?). Or maybe your DSL line is way slower than marketed? With my 512 kbps DSL I can easily get the 64-bit DVD image in 24 hrs, let alone openoffice. Perhaps you should switch to night updates? -- Krzysztof Halasa From florin at andrei.myip.org Mon Mar 19 17:09:22 2007 From: florin at andrei.myip.org (Florin Andrei) Date: Mon, 19 Mar 2007 10:09:22 -0700 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE8C76.5030405@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> Message-ID: <45FEC3C2.2030500@andrei.myip.org> Rahul Sundaram wrote: > > It would do that everytime on bootup though. Right? Can we make it > disable itself if the support is not there on first run? What would be nice is have a program that goes through all init scripts after the installer is done and disables those services for whom there's no capability in the hardware. Sounds like something that firstboot could do. -- Florin Andrei http://florin.myip.org/ From khc at pm.waw.pl Mon Mar 19 17:13:07 2007 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Mon, 19 Mar 2007 18:13:07 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <35632.192.54.193.51.1174309045.squirrel@rousalka.dyndns.org> (Nicolas Mailhot's message of "Mon, 19 Mar 2007 13:57:25 +0100 (CET)") References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <45FE8237.4@fedoraproject.org> <4013.192.54.193.51.1174307973.squirrel@rousalka.dyndns.org> <45FE8541.1020906@fedoraproject.org> <35632.192.54.193.51.1174309045.squirrel@rousalka.dyndns.org> Message-ID: "Nicolas Mailhot" writes: > Every single 64 bit AMD processor supports it, some 32 bit AMD processors > too, probably at least the laptop intel processors. AMD 32 only mobile ones I think. All (?) mobile Pentium-4s and newer from Intel. Almost all desktop P4s -> P4-clockmod, though the old ones (32-bit only?) have silicon errors and can't be clocked below 2 GHz (or something like that). IOW only some non-mainstream and older hw (Athlons XP, Pentium III) can't do cpuspeed. > How could it be not useful? laptop benefits are obvious, desktop win on > energy bill and loudness factor Certainly. -- Krzysztof Halasa From rc040203 at freenet.de Mon Mar 19 17:13:19 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Mar 2007 18:13:19 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <17918.49194.259929.212056@zebedee.pink> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> <17918.36890.861729.982547@zebedee.pink> <1174312455.30079.7.camel@zod.rchland.ibm.com> <17918.40351.521897.32976@zebedee.pink> <1174315830.3667.111.camel@mccallum.corsepiu.local> <17918.49194.259929.212056@zebedee.pink> Message-ID: <1174324400.15060.7.camel@mccallum.corsepiu.local> On Mon, 2007-03-19 at 16:54 +0000, Andrew Haley wrote: > Ralf Corsepius writes: > > On Mon, 2007-03-19 at 14:26 +0000, Andrew Haley wrote: > > > Josh Boyer writes: > > > > On Mon, 2007-03-19 at 13:28 +0000, Andrew Haley wrote: > > > > > Ralf Corsepius writes: > > > > > > > > > > > >From my experience (I've used Fedora with both ISDN and with > > > > > > DSL Lite), Fedora with ISDN or modem is plain unusable, with > > > > > > "DSL Lite", the situation is "bearable", but isn't fun (an > > > > > > openoffice update takes a working-day). > > > > > > > > > > So don't do that, then. Fedora doesn't require anyone to yum > > > > > update openoffice. > > > > > > > > That isn't a particularly helpful comment. > > > > > > Look at it this way: if you really need openoffice updated, then > > > update it. > > > > Well, then you might be able to answer why Core has replaced ca. half of > > the core distro since FC6's initial roll-out if there weren't sufficient > > reasons to do so? > > Sigh. One of the advantages of Fedora is that we do frequent updates > so that you can be sure that bugs are fixed in a timely manner. That > doesn't mean that Fedora is totally useless unless you have every > single update the instant it is released. >From a user's perspective things are a bit different: To be able to follow the benefits of Fedora, you need sufficient bandwidth. If you can't cope with the bandwidth demands, you're probably better off using a different distro. Ralf From david at fubar.dk Mon Mar 19 17:27:09 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 19 Mar 2007 13:27:09 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <20070319164006.GC22192@nostromo.devel.redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <20070319164006.GC22192@nostromo.devel.redhat.com> Message-ID: <1174325229.2713.1.camel@zelda.fubar.dk> On Mon, 2007-03-19 at 12:40 -0400, Bill Nottingham wrote: > Rahul Sundaram (sundaram at fedoraproject.org) said: > > Hardware specific - Bluetooth (along with hidd), cups (FC6 even had > > smartcard daemon by default). Should check and enable on demand > > Right. Heck, it's on the feature list. You have patches? :) > > > Definitely superfluous - firstboot, livecd. Should disable after first > > run completely or even remove the packages. > > These don't do anything at all post-boot - the impact is minimal. > You could configure the livecd installer to disable this after install. It's a bug that the livecd installer doesn't remove a) the package owning the livecd init script; and b) itself. David From hughsient at gmail.com Mon Mar 19 17:32:19 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Mar 2007 17:32:19 +0000 Subject: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: <1174319726.2635.2.camel@zelda.fubar.dk> References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> Message-ID: <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> On 19/03/07, David Zeuthen wrote: > On Mon, 2007-03-19 at 15:32 +0100, Mark wrote: > > Just noticed: > > Status CLOSED > > Resolution NOTABUG > > that`s for this bug: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213768 > > > > Why is it closed and why is it not a bug if there is NO info in that > > thread on how to resolve it (except the last post i just made there) > > there isn`t even a link to a page anywhere that describes on how to > > solve it. > > Because the policy right now is to only mount hotpluggable drives and > media from drives that accept removable media. Just think about security > implications if you had read/write access to the password database on a > Windows partition... I thought we agreed that that was okay argument for RHEL, but fedora it should be turned off in the spec? I'm sure you agree, physical access to the hardware means compromise of data, given enough time. This is a bug I've been harping on for ages, when the typical use case for non-geeks is: Install fedora on second disk or spare partition and just dual boot to Linux when possible. In this case "the windows disk" isn't detected. Bad bad bad. Richard. From mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 13:39:33 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 14:39:33 +0100 Subject: Fw: Re: rpms/openbabel/devel openbabel-changelog.patch, NONE, 1.1 .cvsignore, 1.3, 1.4 openbabel.spec, 1.5, 1.6 sources, 1.3, 1.4 openbabel-chicken.patch, 1.2, NONE Message-ID: <20070319143933.ece92340.mschwendt.tmp0701.nospam@arcor.de> [...] Begin forwarded message: Date: Mon, 19 Mar 2007 13:52:25 +0100 From: Michael Schwendt To: fedora-devel-list AT redhat com Cc: rathann AT fedoraproject org Subject: Re: rpms/openbabel/devel openbabel-changelog.patch, NONE, 1.1 .cvsignore, 1.3, 1.4 openbabel.spec, 1.5, 1.6 sources, 1.3, 1.4 openbabel-chicken.patch, 1.2, NONE On Sun, 18 Mar 2007 14:03:13 -0400, Dominik Mierzejewski (rathann) wrote: > Author: rathann > > Update of /cvs/extras/rpms/openbabel/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv28325 > - copied inchi header for inchi-devel (TODO: make inchi a separate package) > - added %%check This triggered a WARNING during the extras-push, because the inchi packages were built without a change in EVR. Old published builds with the same NEVR are never overwritten. From david at fubar.dk Mon Mar 19 17:37:38 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 19 Mar 2007 13:37:38 -0400 Subject: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> Message-ID: <1174325858.2713.7.camel@zelda.fubar.dk> On Mon, 2007-03-19 at 17:32 +0000, Richard Hughes wrote: > This is a bug I've been harping on for ages, when the typical use case > for non-geeks is: > > Install fedora on second disk or spare partition and just dual boot to > Linux when possible. > > In this case "the windows disk" isn't detected. Bad bad bad. I personally agree with that but note that it wasn't the position of the project when the current policy was decided. Hence where we are right now. David From Michael_E_Brown at dell.com Mon Mar 19 17:38:24 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 19 Mar 2007 12:38:24 -0500 Subject: Flag Modification Denied In-Reply-To: References: Message-ID: <20070319173823.GC6336@humbolt.us.dell.com> On Mon, Mar 19, 2007 at 12:18:28PM -0400, Konstantin Ryabitsev wrote: > Hello, everyone: > > According to the new procedure, I'm supposed to set "fedora-cvs" flag > whenever I'm requesting branches. Actually trying to do that results > in: > > "You tried to request fedora-cvs. Only an authorized user can make this > change." > > How would I go about getting authorized? And, generally, how would I > go about getting authorized for any other things that I used to have > access to before February? Request access to "cvsfedora" group on your FAS account: https://admin.fedora.redhat.com/accounts/userbox.cgi -- Michael From poelstra at redhat.com Mon Mar 19 17:38:35 2007 From: poelstra at redhat.com (John Poelstra) Date: Mon, 19 Mar 2007 10:38:35 -0700 Subject: Announcing Fedora 7 Test 2 (6.91) -- updates-f7t2.img In-Reply-To: <1174323177.14986.12.camel@erebor.boston.redhat.com> References: <200703011112.12348.jkeating@redhat.com> <45F1BD10.5060007@redhat.com> <1173472813.7346.1.camel@localhost.localdomain> <1174323177.14986.12.camel@erebor.boston.redhat.com> Message-ID: <45FECA9B.4010601@redhat.com> Jeremy Katz said the following on 03/19/2007 09:52 AM Pacific Time: >> $ gunzip -c updates-f7t2.img | file - >> /dev/stdin: ASCII cpio archive (SVR4 with CRC) > > Yep -- an updates.img can now be a gzipped cpio ball now (handy for > creating/looking at without needing root). > > Just 'zcat updates.img |cpio -id' and you should be good > > Jeremy > Thanks! I updated: http://fedoraproject.org/wiki/Anaconda/Updates From david at fubar.dk Mon Mar 19 17:55:54 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 19 Mar 2007 13:55:54 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <15e53e180703190554h6059a1abx477e5c585db69e86@mail.gmail.com> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <1174307515.2873.3.camel@localhost.localdomain> <13880.192.54.193.51.1174308091.squirrel@rousalka.dyndns.org> <15e53e180703190554h6059a1abx477e5c585db69e86@mail.gmail.com> Message-ID: <1174326954.2713.11.camel@zelda.fubar.dk> On Mon, 2007-03-19 at 12:54 +0000, Richard Hughes wrote: > Locked yes, not logged in no. That's something that will be fixed > really soon, now that g-p-m can be run headless. Yes, we should do this for Fedora 8. It will have the side effect of silencing a whole lot of complainers on this list. And we can actually do this now in a sane way since we have a sane entity for tracking logins. > KDE has a K-version of power manager, the name of which escapes me. I > would expect that to do cpu freq just like g-p-m does. KPowersave I think. And I absolutely think it supports CPU freq scaling since the author of KPowersave wrote the HAL addon (Holger Macht of SUSE). David From hughsient at gmail.com Mon Mar 19 17:56:06 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Mar 2007 17:56:06 +0000 Subject: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: <1174325858.2713.7.camel@zelda.fubar.dk> References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> <1174325858.2713.7.camel@zelda.fubar.dk> Message-ID: <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> On 19/03/07, David Zeuthen wrote: > On Mon, 2007-03-19 at 17:32 +0000, Richard Hughes wrote: > > This is a bug I've been harping on for ages, when the typical use case > > for non-geeks is: > > > > Install fedora on second disk or spare partition and just dual boot to > > Linux when possible. > > > > In this case "the windows disk" isn't detected. Bad bad bad. > > I personally agree with that but note that it wasn't the position of the > project when the current policy was decided. Hence where we are right > now. Is this a rh-legal type problem (in which case I understand) or rh-desktop policy (which can be re-evaluated)? Personally I've explained the 99-fixed-disk thing to at least 4 or 5 people new to linux, and they all thought it was a crazy decision. No offence intended. Richard. From wtogami at redhat.com Mon Mar 19 17:57:49 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 19 Mar 2007 13:57:49 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174324400.15060.7.camel@mccallum.corsepiu.local> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> <17918.36890.861729.982547@zebedee.pink> <1174312455.30079.7.camel@zod.rchland.ibm.com> <17918.40351.521897.32976@zebedee.pink> <1174315830.3667.111.camel@mccallum.corsepiu.local> <17918.49194.259929.212056@zebedee.pink> <1174324400.15060.7.camel@mccallum.corsepiu.local> Message-ID: <45FECF1D.9030405@redhat.com> Ralf Corsepius wrote: > On Mon, 2007-03-19 at 16:54 +0000, Andrew Haley wrote: >> Ralf Corsepius writes: >> > On Mon, 2007-03-19 at 14:26 +0000, Andrew Haley wrote: >> > > Josh Boyer writes: >> > > > On Mon, 2007-03-19 at 13:28 +0000, Andrew Haley wrote: >> > > > > Ralf Corsepius writes: >> > > > > >> > > > > > >From my experience (I've used Fedora with both ISDN and with >> > > > > > DSL Lite), Fedora with ISDN or modem is plain unusable, with >> > > > > > "DSL Lite", the situation is "bearable", but isn't fun (an >> > > > > > openoffice update takes a working-day). >> > > > > >> > > > > So don't do that, then. Fedora doesn't require anyone to yum >> > > > > update openoffice. >> > > > >> > > > That isn't a particularly helpful comment. >> > > >> > > Look at it this way: if you really need openoffice updated, then >> > > update it. >> > >> > Well, then you might be able to answer why Core has replaced ca. half of >> > the core distro since FC6's initial roll-out if there weren't sufficient >> > reasons to do so? >> >> Sigh. One of the advantages of Fedora is that we do frequent updates >> so that you can be sure that bugs are fixed in a timely manner. That >> doesn't mean that Fedora is totally useless unless you have every >> single update the instant it is released. > >>From a user's perspective things are a bit different: > > To be able to follow the benefits of Fedora, you need sufficient > bandwidth. If you can't cope with the bandwidth demands, you're probably > better off using a different distro. > https://hosted.fedoraproject.org/projects/presto Those concerned about bandwidth should help the yum-deltarpm project in development and testing. Warren Togami wtogami at redhat.com From david at fubar.dk Mon Mar 19 17:58:11 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 19 Mar 2007 13:58:11 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174308110.30079.3.camel@zod.rchland.ibm.com> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <1174307515.2873.3.camel@localhost.localdomain> <1174308110.30079.3.camel@zod.rchland.ibm.com> Message-ID: <1174327091.2713.15.camel@zelda.fubar.dk> On Mon, 2007-03-19 at 07:41 -0500, Josh Boyer wrote: > For the discussion purposes of the LiveCD, which will be Gnome based, > that is technically possible. In general though, unless KDE, XFCE, < > $ramdom foo> has the same thing, g-p-m doesn't help at all. That's probably why we need different spins so e.g. the Desktop and KDE spins doesn't need to pull in these bits but other spins may. Or maybe it can be solved in other ways, e.g. the XFCE meta package pulls in e.g. cpuspeed if they don't have that in their desktop. Either way, I don't care. Anyway, we need the ability to run services like g-p-m when no-one is logged in and hopefully that will land in Fedora 8. David From jwboyer at jdub.homelinux.org Mon Mar 19 18:01:30 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 19 Mar 2007 13:01:30 -0500 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174327091.2713.15.camel@zelda.fubar.dk> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <1174307515.2873.3.camel@localhost.localdomain> <1174308110.30079.3.camel@zod.rchland.ibm.com> <1174327091.2713.15.camel@zelda.fubar.dk> Message-ID: <1174327290.30079.38.camel@zod.rchland.ibm.com> On Mon, 2007-03-19 at 13:58 -0400, David Zeuthen wrote: > On Mon, 2007-03-19 at 07:41 -0500, Josh Boyer wrote: > > For the discussion purposes of the LiveCD, which will be Gnome based, > > that is technically possible. In general though, unless KDE, XFCE, < > > $ramdom foo> has the same thing, g-p-m doesn't help at all. > > That's probably why we need different spins so e.g. the Desktop and KDE > spins doesn't need to pull in these bits but other spins may. Or maybe > it can be solved in other ways, e.g. the XFCE meta package pulls in e.g. > cpuspeed if they don't have that in their desktop. Either way, I don't Right. I'll be working on an XFCE livecd spin again soon and will be keeping that in mind. > care. Anyway, we need the ability to run services like g-p-m when no-one > is logged in and hopefully that will land in Fedora 8. Oh please yes. josh From hughsient at gmail.com Mon Mar 19 18:05:03 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Mar 2007 18:05:03 +0000 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174326954.2713.11.camel@zelda.fubar.dk> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <1174307515.2873.3.camel@localhost.localdomain> <13880.192.54.193.51.1174308091.squirrel@rousalka.dyndns.org> <15e53e180703190554h6059a1abx477e5c585db69e86@mail.gmail.com> <1174326954.2713.11.camel@zelda.fubar.dk> Message-ID: <15e53e180703191105q24cc90a5ybc64afcabbd87306@mail.gmail.com> On 19/03/07, David Zeuthen wrote: > On Mon, 2007-03-19 at 12:54 +0000, Richard Hughes wrote: > > Locked yes, not logged in no. That's something that will be fixed > > really soon, now that g-p-m can be run headless. > > Yes, we should do this for Fedora 8. It will have the side effect of > silencing a whole lot of complainers on this list. For sure. I have a version on my local machine that can run headless and apply policy, and also exposing a dbus interface. What about putting a battery icon in the GDM screen? Sanity or insanity? Richard. From katzj at redhat.com Mon Mar 19 18:06:13 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 19 Mar 2007 14:06:13 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FEC3C2.2030500@andrei.myip.org> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> <45FEC3C2.2030500@andrei.myip.org> Message-ID: <1174327574.14986.34.camel@erebor.boston.redhat.com> On Mon, 2007-03-19 at 10:09 -0700, Florin Andrei wrote: > Rahul Sundaram wrote: > > > > It would do that everytime on bootup though. Right? Can we make it > > disable itself if the support is not there on first run? > > What would be nice is have a program that goes through all init scripts > after the installer is done and disables those services for whom there's > no capability in the hardware. > Sounds like something that firstboot could do. Except that the hardware that's attached to your system changes. Maybe you don't have bluetooth built-in on your machine, but you plug in a bluetooth USB dongle at some point. The real thing here is that more of the daemons which are currently started via initscripts need to be started when the hardware is inserted and stopped when removed. Tracking bug at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222312. Feel free to add things to the tracker, or even better, help fix things and attach patches. Jeremy From katzj at redhat.com Mon Mar 19 18:12:32 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 19 Mar 2007 14:12:32 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE5D39.7020002@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> Message-ID: <1174327953.14986.39.camel@erebor.boston.redhat.com> On Mon, 2007-03-19 at 15:21 +0530, Rahul Sundaram wrote: > Been fiddling with a installation of Fedora 7 Test 2 from the Live CD > and it still enables way too may daemons by default. The following > deserve special mention. > > Hardware specific - Bluetooth (along with hidd), Should be started if we have bluetooth hardware available, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222315. Not installing/starting it in the current situation would mean that you don't have a working keyboard/mouse if you use bluetooth. Which sucks worse. > cups Didn't we have a long thread about cups on demand vs not? > Definitely superfluous - firstboot, livecd. Should disable after first > run completely or even remove the packages. Removing packages because something has been run is an absolutely horrendous idea. Disabling may be reasonable, but at the same time, the amount of time taken for them to run and exit is going to be negligible at best. > Extra - cpuspeed. Most cpus support frequency scaling and it's pretty important for power conservation. > mdmonitor, If you have RAID, this is important to have. It could be made to exit a lot faster, though, by checking for the existence of mdadm.conf before sourcing /etc/init.d/functions. > netfs, Required if you have any non local filesystems being mounted. > ntpd, Gets enabled when you select that you want to sync your time by default. Otherwise, it stays off. See the header at the top of the initscript. > portmap. Not enabling this means that trying to do an NFS mount hangs mysteriously. > Default? - Possibly NetworkManagerDispatcher since > NetworkManager is enabled by default Arguably, NetworkManagerDispatcher shouldn't exist as a separate initscript, but that's a different flamewar for a different day :-) > Exim should probably replaced with something like esmtp or ssmtp in the > live cd. Folks wanting to install a full blown MTA can install sendmail, > postfix or email on their own. Actually, we should use the same default here that we do elsewhere, which would be sendmail. Moving to the use of a kickstart config to define the live CD and using the default package groups will help a lot here. Jeremy From dominik at greysector.net Mon Mar 19 17:50:26 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 19 Mar 2007 18:50:26 +0100 Subject: Flag Modification Denied In-Reply-To: <20070319173823.GC6336@humbolt.us.dell.com> References: <20070319173823.GC6336@humbolt.us.dell.com> Message-ID: <20070319175026.GA13693@ryvius.pekin.waw.pl> On Monday, 19 March 2007 at 18:38, Michael E Brown wrote: > On Mon, Mar 19, 2007 at 12:18:28PM -0400, Konstantin Ryabitsev wrote: > > Hello, everyone: > > > > According to the new procedure, I'm supposed to set "fedora-cvs" flag > > whenever I'm requesting branches. Actually trying to do that results > > in: > > > > "You tried to request fedora-cvs. Only an authorized user can make this > > change." > > > > How would I go about getting authorized? And, generally, how would I > > go about getting authorized for any other things that I used to have > > access to before February? > > Request access to "cvsfedora" group on your FAS account: > https://admin.fedora.redhat.com/accounts/userbox.cgi How is that different from "cvsextras"? 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 dominik at greysector.net Mon Mar 19 17:51:21 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 19 Mar 2007 18:51:21 +0100 Subject: rpms/openbabel/devel openbabel-changelog.patch, NONE, 1.1 .cvsignore, 1.3, 1.4 openbabel.spec, 1.5, 1.6 sources, 1.3, 1.4 openbabel-chicken.patch, 1.2, NONE In-Reply-To: <20070319135225.9a123b83.bugs.michael@gmx.net> References: <200703181803.l2II3Dgn028351@cvs-int.fedora.redhat.com> <20070319135225.9a123b83.bugs.michael@gmx.net> Message-ID: <20070319175121.GB13693@ryvius.pekin.waw.pl> On Monday, 19 March 2007 at 13:52, Michael Schwendt wrote: > On Sun, 18 Mar 2007 14:03:13 -0400, Dominik Mierzejewski (rathann) wrote: > > > Author: rathann > > > > Update of /cvs/extras/rpms/openbabel/devel > > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv28325 > > > - copied inchi header for inchi-devel (TODO: make inchi a separate package) > > - added %%check > > This triggered a WARNING during the extras-push, because the inchi > packages were built without a change in EVR. Old published builds with the > same NEVR are never overwritten. No harm. inchi is exactly the same. 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 mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 18:45:44 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 19:45:44 +0100 Subject: Flag Modification Denied In-Reply-To: <20070319175026.GA13693@ryvius.pekin.waw.pl> References: <20070319173823.GC6336@humbolt.us.dell.com> <20070319175026.GA13693@ryvius.pekin.waw.pl> Message-ID: <20070319194544.f97f2636.mschwendt.tmp0701.nospam@arcor.de> On Mon, 19 Mar 2007 18:50:26 +0100, Dominik 'Rathann' Mierzejewski wrote: > > Request access to "cvsfedora" group on your FAS account: > > https://admin.fedora.redhat.com/accounts/userbox.cgi > > How is that different from "cvsextras"? Different CVSROOT, different modules. But to repeat, "fedorabugs" group membership is needed for the extra privileges in bugzilla. From Michael_E_Brown at dell.com Mon Mar 19 18:53:39 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 19 Mar 2007 13:53:39 -0500 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174327574.14986.34.camel@erebor.boston.redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> <45FEC3C2.2030500@andrei.myip.org> <1174327574.14986.34.camel@erebor.boston.redhat.com> Message-ID: <20070319185338.GD6336@humbolt.us.dell.com> On Mon, Mar 19, 2007 at 02:06:13PM -0400, Jeremy Katz wrote: > On Mon, 2007-03-19 at 10:09 -0700, Florin Andrei wrote: > > Rahul Sundaram wrote: > > > > > > It would do that everytime on bootup though. Right? Can we make it > > > disable itself if the support is not there on first run? > > > > What would be nice is have a program that goes through all init scripts > > after the installer is done and disables those services for whom there's > > no capability in the hardware. > > Sounds like something that firstboot could do. > > Except that the hardware that's attached to your system changes. Maybe > you don't have bluetooth built-in on your machine, but you plug in a > bluetooth USB dongle at some point. Or, if you are on a recent Dell laptop with libsmbios installed and run "dellWirelessCtl --boot --bt 1" to enable bluetooth at runtime. (assuming you have that module installed.) -- Michael From wtogami at redhat.com Mon Mar 19 18:54:02 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 19 Mar 2007 14:54:02 -0400 Subject: Flag Modification Denied In-Reply-To: <20070319194544.f97f2636.mschwendt.tmp0701.nospam@arcor.de> References: <20070319173823.GC6336@humbolt.us.dell.com> <20070319175026.GA13693@ryvius.pekin.waw.pl> <20070319194544.f97f2636.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <45FEDC4A.1010006@redhat.com> Michael Schwendt wrote: > On Mon, 19 Mar 2007 18:50:26 +0100, Dominik 'Rathann' Mierzejewski wrote: > >>> Request access to "cvsfedora" group on your FAS account: >>> https://admin.fedora.redhat.com/accounts/userbox.cgi >> How is that different from "cvsextras"? > > Different CVSROOT, different modules. > > But to repeat, "fedorabugs" group membership is needed for the extra > privileges in bugzilla. > There is no reason in particular that fedorabugs was chosen as the needed permission for fiddling this flag, other than that is currently the only group that is propagated from FAS. I've asked FI if cvsextras sponsored status could automatically add fedorabugs to a FAS account in order to better streamline this process. Warren Togami wtogami at redhat.com From jwboyer at jdub.homelinux.org Mon Mar 19 18:56:47 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 19 Mar 2007 13:56:47 -0500 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <20070319185338.GD6336@humbolt.us.dell.com> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> <45FEC3C2.2030500@andrei.myip.org> <1174327574.14986.34.camel@erebor.boston.redhat.com> <20070319185338.GD6336@humbolt.us.dell.com> Message-ID: <1174330607.30079.55.camel@zod.rchland.ibm.com> On Mon, 2007-03-19 at 13:53 -0500, Michael E Brown wrote: > On Mon, Mar 19, 2007 at 02:06:13PM -0400, Jeremy Katz wrote: > > On Mon, 2007-03-19 at 10:09 -0700, Florin Andrei wrote: > > > Rahul Sundaram wrote: > > > > > > > > It would do that everytime on bootup though. Right? Can we make it > > > > disable itself if the support is not there on first run? > > > > > > What would be nice is have a program that goes through all init scripts > > > after the installer is done and disables those services for whom there's > > > no capability in the hardware. > > > Sounds like something that firstboot could do. > > > > Except that the hardware that's attached to your system changes. Maybe > > you don't have bluetooth built-in on your machine, but you plug in a > > bluetooth USB dongle at some point. > > Or, if you are on a recent Dell laptop with libsmbios installed and run > "dellWirelessCtl --boot --bt 1" to enable bluetooth at runtime. (assuming you > have that module installed.) Or if you're on a thinkpad and you hit "Fn-F5". All variations of "hardware that's attached to your system changes." :) josh From icon at fedoraproject.org Mon Mar 19 19:15:58 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Mon, 19 Mar 2007 15:15:58 -0400 Subject: Flag Modification Denied In-Reply-To: <20070319194544.f97f2636.mschwendt.tmp0701.nospam@arcor.de> References: <20070319173823.GC6336@humbolt.us.dell.com> <20070319175026.GA13693@ryvius.pekin.waw.pl> <20070319194544.f97f2636.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On 3/19/07, Michael Schwendt wrote: > On Mon, 19 Mar 2007 18:50:26 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > > Request access to "cvsfedora" group on your FAS account: > > > https://admin.fedora.redhat.com/accounts/userbox.cgi > > > > How is that different from "cvsextras"? > > Different CVSROOT, different modules. > > But to repeat, "fedorabugs" group membership is needed for the extra > privileges in bugzilla. So, is it "cvsfedora" or "fedorabugs"? -- Konstantin Ryabitsev Montr?al, Qu?bec From jwboyer at jdub.homelinux.org Mon Mar 19 19:18:57 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 19 Mar 2007 14:18:57 -0500 Subject: Flag Modification Denied In-Reply-To: References: <20070319173823.GC6336@humbolt.us.dell.com> <20070319175026.GA13693@ryvius.pekin.waw.pl> <20070319194544.f97f2636.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1174331937.30079.59.camel@zod.rchland.ibm.com> On Mon, 2007-03-19 at 15:15 -0400, Konstantin Ryabitsev wrote: > On 3/19/07, Michael Schwendt wrote: > > On Mon, 19 Mar 2007 18:50:26 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > > > > Request access to "cvsfedora" group on your FAS account: > > > > https://admin.fedora.redhat.com/accounts/userbox.cgi > > > > > > How is that different from "cvsextras"? > > > > Different CVSROOT, different modules. > > > > But to repeat, "fedorabugs" group membership is needed for the extra > > privileges in bugzilla. > > So, is it "cvsfedora" or "fedorabugs"? "fedorabugs" josh From bpepple at fedoraproject.org Mon Mar 19 19:20:14 2007 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 19 Mar 2007 15:20:14 -0400 Subject: FESCo Meeting Summary for 2007-03-15 Message-ID: <1174332014.15923.3.camel@lincoln> === Members Present === * Brian Pepple (bpepple) * Jason Tibbitts (tibbs) * Christian Iseli (ch4chris) * Rex Dieter (rdieter) * Toshio Kuratomi (abadger1999) * Kevin Fenzi (nirik) * Dennis Gilmore (dgilmore) * Jesse Keating (f13) * Warren Togami (warren) * Tom Callaway (spot) * Josh Boyer (jwb) * Bill Nottingham (notting) === Absent === * Jeremy Katz (jeremy) == Summary == === Core Review Process === * The Merge Review is only a cleanup sweep, and the cleanup changes need to end at Test4. The merge will happens whether or not they are approved in a Merge Review. The cleanup will continue after F7. === Packaging Committee Report === * FESCo approved the Packaging Committee's guidelines regarding: * http://fedoraproject.org/wiki/PackagingDraft/ScriptletsWriteDirs * http://fedoraproject.org/wiki/PackagingDrafts/BuildRootHandling For full IRC log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070315 Thanks. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- 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 law at redhat.com Mon Mar 19 19:32:02 2007 From: law at redhat.com (Jeffrey Law) Date: Mon, 19 Mar 2007 13:32:02 -0600 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <4013.192.54.193.51.1174307973.squirrel@rousalka.dyndns.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <45FE8237.4@fedoraproject.org> <4013.192.54.193.51.1174307973.squirrel@rousalka.dyndns.org> Message-ID: <1174332722.5239.65.camel@sweet.slc.redhat.com> On Mon, 2007-03-19 at 13:39 +0100, Nicolas Mailhot wrote: > Le Lun 19 mars 2007 13:29, Rahul Sundaram a ?crit : > > Benny Amorsen wrote: > >>>>>>> "JB" == Josh Boyer writes: > >> > >> JB> cpuspeed is very useful, especially in the case of a laptop which > >> JB> several people use as their desktop. Your narrow definition of a > >> JB> desktop is perhaps too limiting. > >> > >> cpuspeed really isn't optional on modern desktop machines either. > >> Rahul Sundaram may have lots of machines with fixed clockspeeds, but > >> that is no reason to not support newer stuff. > > > > There is simply no need to get personal. If hardware doesn't support it, > > it needs to be disabled by default. Disagree? > > If a large proportion of hardware supports it, and launching it for the > rest is relatively harmless, it needs to be enabled by default. > > I find it ridiculous to push network manager (which is only really needed > for wifi users, for hardware we have free drivers for, and tends to mess > up the system when going bad) and ask to remove cpuspeed. There are cases where NetworkManager is used for wired connections in addition to wireless connections. Stateless Linux for example uses NetworkManager exclusively to manage its network connections. Jeff From pertusus at free.fr Mon Mar 19 19:49:13 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 19 Mar 2007 20:49:13 +0100 Subject: User directories integration - request for help In-Reply-To: <1174311426.3341.9.camel@dhcp83-33.boston.redhat.com> References: <1174105657.2691.24.camel@zelda.fubar.dk> <1174106134.4680.249.camel@mccallum.corsepiu.local> <1174107004.2691.31.camel@zelda.fubar.dk> <20070317135944.GC8832@devserv.devel.redhat.com> <1174159178.2759.7.camel@localhost.localdomain> <20070317195544.GA21441@devserv.devel.redhat.com> <1174151524.2784.8.camel@zelda.fubar.dk> <1174185384.3455.4.camel@localhost.localdomain> <20070319095722.GB3186@free.fr> <1174311426.3341.9.camel@dhcp83-33.boston.redhat.com> Message-ID: <20070319194913.GD2905@free.fr> On Mon, Mar 19, 2007 at 09:37:06AM -0400, Matthias Clasen wrote: > > No, you didn't get it; the design discussion has been going on upstream > for ~5 years now. We are finally beyond that. Seems like not everybody was there, nor heard. And my remark still holds. No need to test something when not agreeing on the design. -- Pat From Axel.Thimm at ATrpms.net Mon Mar 19 20:13:21 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 21:13:21 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <45FDA3A8.4010401@develer.com> References: <45FA1A1A.9060201@volny.cz> <45FD2004.4040003@develer.com> <1174217329.19932.24.camel@rousalka.dyndns.org> <45FDA3A8.4010401@develer.com> Message-ID: <20070319201321.GA18607@neu.nirvana> On Sun, Mar 18, 2007 at 09:40:08PM +0100, Bernardo Innocenti wrote: > Nicolas Mailhot wrote: > > > > You're rephrasing my opinion much better than I stated it originally > > Thanks :) > > > >> Maybe the LSB would care to publish a standard within the next > >> 10 years? > > > > Replace LSB with FHS, if we want something quick > > I've looked at their web site, but the FHS spec has not been updated > since early 2004, and their mailing-list archives look like a spam > dumpyard. > > These two clues make me suppose the FHS standardization body may > have retired or maybe just moved elsewhere. Unfortunately it hasn't moved. The spamfest is indeed the main mailing list :( -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmus at tmus.dk Mon Mar 19 20:13:57 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 19 Mar 2007 21:13:57 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE8C76.5030405@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Jarod Wilson wrote: >> >> Everyone please kindly read the cpuspeed initscript before continuing to >> hypothesize about it. It does indeed already look for necessary support, >> and silently exits without doing a thing it its not present. >> >> /me is the cpuspeed maintainer... :) > > It would do that everytime on bootup though. Right? Can we make it > disable itself if the support is not there on first run? > > Rahul > Having daemons deactivate themselves like this seems like a bad idea from a users perspective... God knows in how many places you'd be searching for the reason why feature xyz isn't working, if all services would do that. The will have a pretty hard time re-enabling themselves as it stands right now. Btw, from my experience, the cpuspeed daemon isn't even started from the initscript (at least on my machine, running FC6), it really only modprobes the cpufreq_ondemand module. /Thomas /Thomas From mike at miketc.com Mon Mar 19 20:18:10 2007 From: mike at miketc.com (Mike Chambers) Date: Mon, 19 Mar 2007 15:18:10 -0500 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE5D39.7020002@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> Message-ID: <1174335490.2831.5.camel@scrappy.miketc.com> On Mon, 2007-03-19 at 15:21 +0530, Rahul Sundaram wrote: > Been fiddling with a installation of Fedora 7 Test 2 from the Live CD > and it still enables way too may daemons by default. The following > deserve special mention. > Comments? Don't know if this has been brought up before, but why can't firstboot be allowed to configure what services/daemons we want to run? As in a configurable option/menu after display/users or whatever? Or is this the wrong thread/circumstance to mention this? -- Mike Chambers Madisonville, KY "Sex is like air, it's not important unless your not getting any!" From buildsys at fedoraproject.org Mon Mar 19 20:21:18 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 19 Mar 2007 16:21:18 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-19 Message-ID: <20070319202118.8FB47152130@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 13 aqbanking-2.2.9-1 em8300-kmod-0.16.1-7.2.6.20_1.2997.fc7 NEW ettercap-0.7.3-12.fc7 NEW gfa-0.4.1-4.fc7 gwenhywfar-2.5.4-1 NEW httpunit-1.6.2-1jpp.1.fc7 jd-1.8.8-0.2.cvs070319.fc7 NEW perl-Class-Factory-1.05-2.fc7 NEW perl-DBD-Mock-1.34-2.fc7 qps-1.9.19-0.2.b.fc7 wcstools-3.6.8-1.fc7 xmoto-0.2.7-1.fc7 yumex-1.9.4-1.0.fc7 aqbanking-2.2.9-1 ----------------- * Mon Mar 19 2007 Bill Nottingham - 2.2.9-1 - update to 2.2.9 em8300-kmod-0.16.1-7.2.6.20_1.2997.fc7 -------------------------------------- * Mon Mar 19 2007 Ville Skytt? - 0.16.1-7 - Drop OSS default patch, making ALSA the default now; users who need OSS should use the audio_driver=oss option of the em8300 module. - Use upstream 2.6.21/ALSA patch. - Build for kernel 2.6.20-1.2997.fc7, including ppc64. ettercap-0.7.3-12.fc7 --------------------- * Fri Mar 16 2007 Jon Ciesla - 0.7.3-13 - Added -text -curses symlinks * Thu Mar 15 2007 Jon Ciesla - 0.7.3-12 - Added ettercap-README.fedora - Fixed Requires versioning. * Thu Mar 15 2007 Jon Ciesla - 0.7.3-11 - Fixed several typos, clarified a few minor things. * Thu Mar 15 2007 Jon Ciesla - 0.7.3-10 - Added doc and README. - Replaced symlinks with alternatives solution. * Thu Mar 15 2007 Jon Ciesla - 0.7.3-9 - Removed libtool BR. - Removed .la files. - Moved plugins to subpackage. - Re-added Provides to GTK package. * Tue Mar 13 2007 Jon Ciesla - 0.7.3-8 - Added libtool-ltdl-devel BR. - Removed full path from desktop. - Dropped provides from gtk package * Tue Mar 13 2007 Jon Ciesla - 0.7.3-7 - Fixed .desktop icon path * Tue Mar 13 2007 Jon Ciesla - 0.7.3-6 - Moved to consistent buildroot. - Fixed BR, Rs. * Tue Mar 13 2007 Jon Ciesla - 0.7.3-5 - Removed dupes, moved symlinks for t and c to common only - Moved desktop scriptlets to gtk package. - Moved curses man page to curses package. * Tue Mar 13 2007 Jon Ciesla - 0.7.3-4 - Added Provides * Tue Mar 13 2007 Jon Ciesla - 0.7.3-3 - Updated BRs. - Split out gtk and NCURSES versions from common package. - Added UI patch from Till Maas, symlinks, .desktop, icon installation. * Sat Mar 10 2007 Jon Ciesla - 0.7.3-2 - Corrected Source URL. * Sat Mar 10 2007 Jon Ciesla - 0.7.3-1 - Initial packaging. gfa-0.4.1-4.fc7 --------------- * Mon Mar 19 2007 Damien Durand - 0.4.1-4 - Fix source0 * Sun Mar 18 2007 Damien Durand - 0.4.1-3 - Fix Desktop-file * Sat Mar 17 2007 Damien Durand - 0.4.1-2 - Fix timestamp - Fix file section gwenhywfar-2.5.4-1 ------------------ * Mon Mar 19 2007 Bill Nottingham - 2.5.4-1 - update to 2.5.4 httpunit-1.6.2-1jpp.1.fc7 ------------------------- jd-1.8.8-0.2.cvs070319.fc7 -------------------------- * Mon Mar 19 2007 Mamoru Tasaka - 1.8.8-0.2.cvs070319 - cvs 070319 (24:25 JST) perl-Class-Factory-1.05-2.fc7 ----------------------------- * Mon Mar 19 2007 Chris Weyl 1.05-2 - bump * Sat Mar 10 2007 Chris Weyl 1.05-1 - Specfile autogenerated by cpanspec 1.70. perl-DBD-Mock-1.34-2.fc7 ------------------------ * Mon Mar 19 2007 Chris Weyl 1.34-2 - bump * Sat Mar 10 2007 Chris Weyl 1.34-1 - Specfile autogenerated by cpanspec 1.70. qps-1.9.19-0.2.b.fc7 -------------------- * Mon Mar 19 2007 Dawid Gajownik - 1.9.19-0.2.b - Update to 1.9.9b wcstools-3.6.8-1.fc7 -------------------- * Mon Mar 19 2007 Sergio Pascual 3.6.8-1 - New upstream source 3.6.8 - Added pacthes to remove warnings during the compilation xmoto-0.2.7-1.fc7 ----------------- * Mon Mar 19 2007 Jon Ciesla 0.2.7-1 - Bumped to upstream, fixed man issues. * Fri Mar 16 2007 Jon Ciesla 0.2.6-2 - Bumped release, build mistake. * Fri Mar 16 2007 Jon Ciesla 0.2.6-1 - New upstream release. - Removed Application from .desktop. - Spec cleanup. - Fixed man path with patch. - Removed X-Fedora. yumex-1.9.4-1.0.fc7 ------------------- * Mon Mar 19 2007 Tim Lauridsen - 1.9.4-1.0 - Development Release 1.9.4-1.0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From Axel.Thimm at ATrpms.net Mon Mar 19 20:24:07 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 21:24:07 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <1174284641.16983.8.camel@willson> References: <45FA1A1A.9060201@volny.cz> <1174284641.16983.8.camel@willson> Message-ID: <20070319202407.GB18607@neu.nirvana> On Mon, Mar 19, 2007 at 02:10:41AM -0400, Simo Sorce wrote: > On Fri, 2007-03-16 at 05:16 +0100, Miloslav Trmac wrote: > > Hi, > > I'm planning to add filesystem-local database support to mlocate. This > > allows: > > - running updatedb on a file server and making the database > > automatically available to clients without any client-side > > configuration > > - using locate on GFS volumes without running updatedb on each host that > > has the volume mounted (which slows the volumes down due to lock > > contention) > > [...] > > > Usage for /home on NFS: > > - NFS is automatically excluded by clients, so updatedb on clients > > does not walk the filesystem. > > - On the server: > > Add /srv/home to /etc/sysconfig/mlocate. If /srv/home is not a > > separate mount point, add LOCATE_PATH=:/srv/home/.mlocate/mlocate.db > > to the global environment. > > I am deeply concerned about the security implications of this idea. > You are basically making it possible for everyone to get access to the > complete remote FS layout ??? The remote mlocate.db can be exported as owned by root with 0600, and depending on root_squash or other factors the database will be remotely readable or not. Or placed differently: If the remote server allows root mounts, then reading the mlocate.db will only be possible, if the remote client can also traverse the real paths anyway (due to unsquashed root priviledges), so you're not giving more security sensitive information away than what's already possible. > > Can anyone see a problem with the plan, or an important feature that the > > above fails to address? > > Yes, security and privacy wise it is BAD BAAD BAAAD :-) It would need to elevate /usr/bin/locate from an sgid to an suid program. That's a risk that needs to be weighed, but other than that I don't see any further issues. Or is there something still? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmus at tmus.dk Mon Mar 19 20:25:30 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 19 Mar 2007 21:25:30 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE6B68.6040307@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <64629.192.54.193.51.1174301133.squirrel@rousalka.dyndns.org> <45FE6B68.6040307@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Nicolas Mailhot wrote: >> Le Lun 19 mars 2007 11:31, Rahul Sundaram a ?crit : >>> Nicolas Mailhot wrote: >>>> Le Lun 19 mars 2007 10:51, Rahul Sundaram a ?crit : >>>> >>>>> Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. Can't see a reason >>>>> to >>>>> enable these by default. >>>> cpuspeed, mdmonitor and ntpd are no more extra than NetworkManager >>> Yes, They are. For a desktop. A Live CD is targeted at the desktop. >>> Nothing else. >> >> Bzzt. Lots of things on the desktop require a working clock (try to >> unsync >> yours and watch havoc breaking loose) > > Working clock is a requirement. Not ntpd. There is a difference. > > , cpuspeed is a requirement on >> laptops and nice-to-have on every recent desktop system (a hot mobo is a >> loud mobo, people like hearing their ogg files too) > > They are not required to be enabled on every system. Only on laptops. > This is completely and utterly untrue. Cpuspeed will save resources and reduce heat on any supported system. Cpuspeed should be installed and enabled on *ALL* systems (that support it). The only place where it could theoretically be a bad thing would be on HPC nodes, and the ondemand governor is probably fast enough that this is PURELY a theoretical issue. Hey - We may actually be saving trees/whales here! > , and killing mdadm >> removes access to parts of the disks (md is used on desktops, and live >> cds >> are used on systems with a linux version on disc) > > Remember that Live CD dont support upgrades. You can only target first > time user's with them as of now. > The Live CD could prove useful as a handdy rescue system complete with GUI, browsers and such - But not if you can't see your storage devices. > Rahul > /Thomas From markg85 at gmail.com Mon Mar 19 20:27:06 2007 From: markg85 at gmail.com (Mark) Date: Mon, 19 Mar 2007 21:27:06 +0100 Subject: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> <1174325858.2713.7.camel@zelda.fubar.dk> <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> Message-ID: <6e24a8e80703191327q1a41f0ebnd313b1bc89d7b258@mail.gmail.com> well.. how i want to run my Linux is in a way that i can just see all my partitions. i don`t want to be limited with that stuff. perhaps making a on/of switch for this? (on = all partitions visable/mounted off = the way it`s currently done) fedora is making this way to hard in there current releases.. 2007/3/19, Richard Hughes : > > On 19/03/07, David Zeuthen wrote: > > On Mon, 2007-03-19 at 17:32 +0000, Richard Hughes wrote: > > > This is a bug I've been harping on for ages, when the typical use case > > > for non-geeks is: > > > > > > Install fedora on second disk or spare partition and just dual boot to > > > Linux when possible. > > > > > > In this case "the windows disk" isn't detected. Bad bad bad. > > > > I personally agree with that but note that it wasn't the position of the > > project when the current policy was decided. Hence where we are right > > now. > > Is this a rh-legal type problem (in which case I understand) or > rh-desktop policy (which can be re-evaluated)? Personally I've > explained the 99-fixed-disk thing to at least 4 or 5 people new to > linux, and they all thought it was a crazy decision. No offence > intended. > > Richard. > > -- > 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 Axel.Thimm at ATrpms.net Mon Mar 19 20:28:06 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 21:28:06 +0100 Subject: Pre-release kernel versioning? In-Reply-To: <52335.192.54.193.51.1174321840.squirrel@rousalka.dyndns.org> References: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> <1174288778.3392.55.camel@pmac.infradead.org> <45FE40B4.4070607@leemhuis.info> <20070319162332.GC813@redhat.com> <52335.192.54.193.51.1174321840.squirrel@rousalka.dyndns.org> Message-ID: <20070319202806.GC18607@neu.nirvana> On Mon, Mar 19, 2007 at 05:30:40PM +0100, Nicolas Mailhot wrote: > Le Lun 19 mars 2007 17:23, Dave Jones a ?crit : > > We could add the 'real' upstream version in brackets in the uname field > > so it shows up as .. > > > > uname -r > > 2.6.20-1.2925.fc6debug (2.6.20.3) > > Are you violently opposed to > 2.6.20.3-1.2925.fc7 for a 2.6.20.3 based kernel > > and > > 2.6.21-0.2925.rc4.f7 for a 2.6.21-rc4 based kernel > > That would make many people happy Nicolas += 1000; :) (and nice-to-have: Instead of 1.2925 why not a simple integer? E.g. 2.6.20.3-1.fc7) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Mon Mar 19 20:33:22 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Mar 2007 16:33:22 -0400 Subject: Pre-release kernel versioning? In-Reply-To: <20070319202806.GC18607@neu.nirvana> References: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> <52335.192.54.193.51.1174321840.squirrel@rousalka.dyndns.org> <20070319202806.GC18607@neu.nirvana> Message-ID: <200703191633.22294.jkeating@redhat.com> On Monday 19 March 2007 16:28:06 Axel Thimm wrote: > Instead of 1.2925 why not a simple integer? 2925 is generated from the cvs checkin ID. No need to worry about it ever, cvs IDs are always incrementing. -- 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 Michael_E_Brown at dell.com Mon Mar 19 20:34:47 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Mon, 19 Mar 2007 15:34:47 -0500 Subject: Flag Modification Denied In-Reply-To: References: <20070319173823.GC6336@humbolt.us.dell.com> <20070319175026.GA13693@ryvius.pekin.waw.pl> <20070319194544.f97f2636.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070319203447.GE6336@humbolt.us.dell.com> On Mon, Mar 19, 2007 at 03:15:58PM -0400, Konstantin Ryabitsev wrote: > On 3/19/07, Michael Schwendt wrote: > >On Mon, 19 Mar 2007 18:50:26 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > >> > Request access to "cvsfedora" group on your FAS account: > >> > https://admin.fedora.redhat.com/accounts/userbox.cgi > >> > >> How is that different from "cvsextras"? > > > >Different CVSROOT, different modules. > > > >But to repeat, "fedorabugs" group membership is needed for the extra > >privileges in bugzilla. > > So, is it "cvsfedora" or "fedorabugs"? I think I probably misspoke: probably fedorabugs as the later posters mentioned. -- Michael From tmus at tmus.dk Mon Mar 19 20:44:58 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 19 Mar 2007 21:44:58 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FECF1D.9030405@redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> <17918.36890.861729.982547@zebedee.pink> <1174312455.30079.7.camel@zod.rchland.ibm.com> <17918.40351.521897.32976@zebedee.pink> <1174315830.3667.111.camel@mccallum.corsepiu.local> <17918.49194.259929.212056@zebedee.pink> <1174324400.15060.7.camel@mccallum.corsepiu.local> <45FECF1D.9030405@redhat.com> Message-ID: Warren Togami wrote: > > https://hosted.fedoraproject.org/projects/presto > Those concerned about bandwidth should help the yum-deltarpm project in > development and testing. > The whole idea of delta rpms has looked as a nasty hack to me, since i first saw the SUSE implementation back-in-the-days (btw, i think they changed it since). That out of the way, the intention for this project seems to be based very much on the fact that the full rpms should always be available and the delta rpms are auto-generated from those (in some way). When implemented this way, we don't loose all the benefits of having the full rpms, but we gain the smaller downloads for updates. This seems like a very noble project, so I hope we can get it working soon. > Warren Togami > wtogami at redhat.com > /Thomas From giallu at gmail.com Mon Mar 19 20:46:15 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 19 Mar 2007 21:46:15 +0100 Subject: Pre-release kernel versioning? In-Reply-To: <200703191633.22294.jkeating@redhat.com> References: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> <52335.192.54.193.51.1174321840.squirrel@rousalka.dyndns.org> <20070319202806.GC18607@neu.nirvana> <200703191633.22294.jkeating@redhat.com> Message-ID: On 3/19/07, Jesse Keating wrote: > On Monday 19 March 2007 16:28:06 Axel Thimm wrote: > > Instead of 1.2925 why not a simple integer? > > 2925 is generated from the cvs checkin ID. No need to worry about it ever, > cvs IDs are always incrementing. cvs ? working on kernel at RH has to be really... interesting ;) anyway, I'm glad to finally know where that "magic" number come from From nicolas.mailhot at laposte.net Mon Mar 19 20:58:00 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 19 Mar 2007 21:58:00 +0100 Subject: Pre-release kernel versioning? In-Reply-To: <200703191633.22294.jkeating@redhat.com> References: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> <52335.192.54.193.51.1174321840.squirrel@rousalka.dyndns.org> <20070319202806.GC18607@neu.nirvana> <200703191633.22294.jkeating@redhat.com> Message-ID: <1174337880.28512.2.camel@rousalka.dyndns.org> Le lundi 19 mars 2007 ? 16:33 -0400, Jesse Keating a ?crit : > On Monday 19 March 2007 16:28:06 Axel Thimm wrote: > > Instead of 1.2925 why not a simple integer? > > 2925 is generated from the cvs checkin ID. No need to worry about it ever, > cvs IDs are always incrementing. You have to wonder why davej is bothering with versionning at all. He could use the cvs ID as epoch, that would only be slightly more horrible. -- Nicolas Mailhot From jkeating at redhat.com Mon Mar 19 21:01:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Mar 2007 17:01:23 -0400 Subject: Pre-release kernel versioning? In-Reply-To: References: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> <200703191633.22294.jkeating@redhat.com> Message-ID: <200703191701.23736.jkeating@redhat.com> On Monday 19 March 2007 16:46:15 Gianluca Sforna wrote: > cvs ? working on kernel at RH has to be really... interesting ;) All the specs for every package is in CVS. -- 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 giallu at gmail.com Mon Mar 19 21:02:51 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 19 Mar 2007 22:02:51 +0100 Subject: Pre-release kernel versioning? In-Reply-To: <200703191701.23736.jkeating@redhat.com> References: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> <200703191633.22294.jkeating@redhat.com> <200703191701.23736.jkeating@redhat.com> Message-ID: On 3/19/07, Jesse Keating wrote: > On Monday 19 March 2007 16:46:15 Gianluca Sforna wrote: > > cvs ? working on kernel at RH has to be really... interesting ;) > > All the specs for every package is in CVS. ahh the specs. For a minute I thought it could be the sources... From buildsys at fedoraproject.org Mon Mar 19 21:03:10 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Mon, 19 Mar 2007 21:03:10 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2007-03-19 Message-ID: <20070319210310.5901.31320@extras64.linux.duke.edu> New report for: rpm AT greysector.net package: openbabel - 2.1.0-0.2.b6.fc7.i386 from fedora-extras-development-x86_64 unresolved deps: libinchi.so.0 package: openbabel - 2.1.0-0.2.b6.fc7.i386 from fedora-extras-development-i386 unresolved deps: libinchi.so.0 package: openbabel - 2.1.0-0.2.b6.fc7.ppc from fedora-extras-development-ppc unresolved deps: libinchi.so.0 package: openbabel - 2.1.0-0.2.b6.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libinchi.so.0()(64bit) ====================================================================== Summary of broken packages (by owner): Jochen AT herr-schmitt.de pdftk - 1.41-3.fc7.i386 (19 days) pdftk - 1.41-3.fc7.ppc (19 days) pdftk - 1.41-3.fc7.x86_64 (19 days) dcbw AT redhat.com csound - 5.03.0-9.fc7.i386 (101 days) csound - 5.03.0-9.fc7.i386 (101 days) csound - 5.03.0-9.fc7.ppc (101 days) csound - 5.03.0-9.fc7.x86_64 (101 days) csound-python - 5.03.0-9.fc7.i386 (101 days) csound-python - 5.03.0-9.fc7.ppc (101 days) csound-python - 5.03.0-9.fc7.x86_64 (101 days) enrico.scholz AT informatik.tu-chemnitz.de tor-core - 0.1.1.26-3.fc7.i386 (8 days) tor-core - 0.1.1.26-3.fc7.ppc (8 days) tor-core - 0.1.1.26-3.fc7.x86_64 (8 days) foolish AT guezz.net flac123 - 0.0.9-1.fc7.i386 (32 days) flac123 - 0.0.9-1.fc7.ppc (32 days) flac123 - 0.0.9-1.fc7.x86_64 (32 days) ifoox AT redhat.com libreadline-java - 0.8.0-13.fc6.i386 (98 days) libreadline-java - 0.8.0-13.fc6.i386 (98 days) libreadline-java - 0.8.0-13.fc6.ppc (98 days) libreadline-java - 0.8.0-13.fc6.x86_64 (98 days) overholt AT redhat.com eclipse-emf - 2.2.1-9.fc7.i386 (4 days) eclipse-emf - 2.2.1-9.fc7.ppc (4 days) eclipse-emf - 2.2.1-9.fc7.x86_64 (4 days) rdieter AT math.unl.edu k3b-extras - 0.12.17-1.fc6.i386 (30 days) k3b-extras - 0.12.17-1.fc6.ppc (30 days) k3b-extras - 0.12.17-1.fc6.x86_64 (30 days) rpm AT greysector.net openbabel - 2.1.0-0.2.b6.fc7.i386 openbabel - 2.1.0-0.2.b6.fc7.i386 openbabel - 2.1.0-0.2.b6.fc7.ppc openbabel - 2.1.0-0.2.b6.fc7.x86_64 ryo-dairiki AT users.sourceforge.net libtomoe-gtk - 0.5.1-1.fc7.i386 (6 days) libtomoe-gtk - 0.5.1-1.fc7.i386 (6 days) libtomoe-gtk - 0.5.1-1.fc7.ppc (6 days) libtomoe-gtk - 0.5.1-1.fc7.x86_64 (6 days) stickster AT gmail.com xmldiff - 0.6.7-12.fc6.i386 (101 days) xmldiff - 0.6.7-12.fc6.ppc (101 days) xmldiff - 0.6.7-12.fc6.x86_64 (101 days) ====================================================================== Broken packages in fedora-extras-development-i386: csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.i386 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 eclipse-emf-2.2.1-9.fc7.i386 requires eclipse-platform < 1:3.2.2 flac123-0.0.9-1.fc7.i386 requires libFLAC.so.7 k3b-extras-0.12.17-1.fc6.i386 requires libk3bdevice.so.2 k3b-extras-0.12.17-1.fc6.i386 requires libk3b.so.2 libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libtomoe-gtk-0.5.1-1.fc7.i386 requires libgucharmap.so.5 openbabel-2.1.0-0.2.b6.fc7.i386 requires libinchi.so.0 pdftk-1.41-3.fc7.i386 requires libgcj.so.7rh tor-core-0.1.1.26-3.fc7.i386 requires libevent-1.2a.so.1 xmldiff-0.6.7-12.fc6.i386 requires python(abi) = 0:2.4 xmldiff-0.6.7-12.fc6.i386 requires python-abi = 0:2.4 ====================================================================== Broken packages in fedora-extras-development-ppc: csound-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.ppc requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 eclipse-emf-2.2.1-9.fc7.ppc requires eclipse-platform < 1:3.2.2 flac123-0.0.9-1.fc7.ppc requires libFLAC.so.7 k3b-extras-0.12.17-1.fc6.ppc requires libk3bdevice.so.2 k3b-extras-0.12.17-1.fc6.ppc requires libk3b.so.2 libreadline-java-0.8.0-13.fc6.ppc requires libedit >= 0:2.9 libtomoe-gtk-0.5.1-1.fc7.ppc requires libgucharmap.so.5 openbabel-2.1.0-0.2.b6.fc7.ppc requires libinchi.so.0 pdftk-1.41-3.fc7.ppc requires libgcj.so.7rh tor-core-0.1.1.26-3.fc7.ppc requires libevent-1.2a.so.1 xmldiff-0.6.7-12.fc6.ppc requires python(abi) = 0:2.4 xmldiff-0.6.7-12.fc6.ppc requires python-abi = 0:2.4 ====================================================================== Broken packages in fedora-extras-development-x86_64: csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-python-5.03.0-9.fc7.x86_64 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) eclipse-emf-2.2.1-9.fc7.x86_64 requires eclipse-platform < 1:3.2.2 flac123-0.0.9-1.fc7.x86_64 requires libFLAC.so.7()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3bdevice.so.2()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3b.so.2()(64bit) libreadline-java-0.8.0-13.fc6.i386 requires libedit >= 0:2.9 libreadline-java-0.8.0-13.fc6.x86_64 requires libedit >= 0:2.9 libtomoe-gtk-0.5.1-1.fc7.i386 requires libgucharmap.so.5 libtomoe-gtk-0.5.1-1.fc7.x86_64 requires libgucharmap.so.5()(64bit) openbabel-2.1.0-0.2.b6.fc7.i386 requires libinchi.so.0 openbabel-2.1.0-0.2.b6.fc7.x86_64 requires libinchi.so.0()(64bit) pdftk-1.41-3.fc7.x86_64 requires libgcj.so.7rh()(64bit) tor-core-0.1.1.26-3.fc7.x86_64 requires libevent-1.2a.so.1()(64bit) xmldiff-0.6.7-12.fc6.x86_64 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.x86_64 requires python(abi) = 0:2.4 From mclasen at redhat.com Mon Mar 19 21:08:06 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 19 Mar 2007 17:08:06 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <15e53e180703191105q24cc90a5ybc64afcabbd87306@mail.gmail.com> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <1174307515.2873.3.camel@localhost.localdomain> <13880.192.54.193.51.1174308091.squirrel@rousalka.dyndns.org> <15e53e180703190554h6059a1abx477e5c585db69e86@mail.gmail.com> <1174326954.2713.11.camel@zelda.fubar.dk> <15e53e180703191105q24cc90a5ybc64afcabbd87306@mail.gmail.com> Message-ID: <1174338486.3432.2.camel@localhost.localdomain> On Mon, 2007-03-19 at 18:05 +0000, Richard Hughes wrote: > On 19/03/07, David Zeuthen wrote: > > On Mon, 2007-03-19 at 12:54 +0000, Richard Hughes wrote: > > > Locked yes, not logged in no. That's something that will be fixed > > > really soon, now that g-p-m can be run headless. > > > > Yes, we should do this for Fedora 8. It will have the side effect of > > silencing a whole lot of complainers on this list. > > For sure. I have a version on my local machine that can run headless > and apply policy, and also exposing a dbus interface. > > What about putting a battery icon in the GDM screen? Sanity or insanity? At some point in the past I had a gdm patch to put a notification area in the login screen. The intention was to put things like NM or g-p-m there. Unfortunately, I think I may have lost that patch... Matthias From jkeating at redhat.com Mon Mar 19 21:10:37 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Mar 2007 17:10:37 -0400 Subject: Pre-release kernel versioning? In-Reply-To: References: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> <200703191701.23736.jkeating@redhat.com> Message-ID: <200703191710.40726.jkeating@redhat.com> On Monday 19 March 2007 17:02:51 Gianluca Sforna wrote: > ahh the specs. For a minute I thought it could be the sources... Well, it is. The sources that don't come in the upstream tarball that is. Now granted, one could mange all of it in a different SCM, generate a srpm from that scm, import it into the package CVS and clobber whatever was there first, but meh... -- 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 tmus at tmus.dk Mon Mar 19 20:58:18 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 19 Mar 2007 21:58:18 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <15e53e180703190554h6059a1abx477e5c585db69e86@mail.gmail.com> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <1174307515.2873.3.camel@localhost.localdomain> <13880.192.54.193.51.1174308091.squirrel@rousalka.dyndns.org> <15e53e180703190554h6059a1abx477e5c585db69e86@mail.gmail.com> Message-ID: Richard Hughes wrote: > > Locked yes, not logged in no. That's something that will be fixed > really soon, now that g-p-m can be run headless. > So lets discuss disabling cpuspeed by default (or better yet - not installing it by default) when headless g-p-m is ready and included in fedora... Of course that will still require a daemon to be started. > Richard. > /Thomas From tmus at tmus.dk Mon Mar 19 20:55:06 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 19 Mar 2007 21:55:06 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <15e53e180703190556u707be177wcbf5e486c22460b7@mail.gmail.com> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <45FE8237.4@fedoraproject.org> <4013.192.54.193.51.1174307973.squirrel@rousalka.dyndns.org> <15e53e180703190556u707be177wcbf5e486c22460b7@mail.gmail.com> Message-ID: Richard Hughes wrote: > > But it takes a finite amount of time to start the service, even on > machines without the hardware. > About one tenths of a second according to *my* measurements. I don't think we should choose to always enable all daemons by default, but for cpuspeed, the time spent on systems that does not support it, does not justify disabling it out-of-the-box, IMHO. > Richard. > /Thomas From hughsient at gmail.com Mon Mar 19 21:11:18 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Mar 2007 21:11:18 +0000 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174338486.3432.2.camel@localhost.localdomain> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <1174307515.2873.3.camel@localhost.localdomain> <13880.192.54.193.51.1174308091.squirrel@rousalka.dyndns.org> <15e53e180703190554h6059a1abx477e5c585db69e86@mail.gmail.com> <1174326954.2713.11.camel@zelda.fubar.dk> <15e53e180703191105q24cc90a5ybc64afcabbd87306@mail.gmail.com> <1174338486.3432.2.camel@localhost.localdomain> Message-ID: <1174338678.10563.0.camel@localhost.localdomain> On Mon, 2007-03-19 at 17:08 -0400, Matthias Clasen wrote: > > At some point in the past I had a gdm patch to put a notification area > in the login screen. The intention was to put things like NM or g-p-m > there. Unfortunately, I think I may have lost that patch... Please find it! :-) That would be fantastic, although would there be a security concern with gdm running as it is now? Richard. From Axel.Thimm at ATrpms.net Mon Mar 19 21:22:35 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 19 Mar 2007 22:22:35 +0100 Subject: Pre-release kernel versioning? In-Reply-To: <200703191633.22294.jkeating@redhat.com> References: <883cfe6d0703181500n31aa3813u3ab5e084d6ebefcc@mail.gmail.com> <52335.192.54.193.51.1174321840.squirrel@rousalka.dyndns.org> <20070319202806.GC18607@neu.nirvana> <200703191633.22294.jkeating@redhat.com> Message-ID: <20070319212235.GI18607@neu.nirvana> On Mon, Mar 19, 2007 at 04:33:22PM -0400, Jesse Keating wrote: > On Monday 19 March 2007 16:28:06 Axel Thimm wrote: > > Instead of 1.2925 why not a simple integer? > > 2925 is generated from the cvs checkin ID. Yes, I know, but why do we need to know that on the user level? :=) We don't have this convenience setup in other packages, although nothing stops a package to use the same embed-the-CVS-id-and-never- bump-the-release-tag-ever method. > No need to worry about it ever, cvs IDs are always incrementing. Given that we'd like to rethink whether CVS can finally rip, that it is not really needed anyway in the release tag, maybe it would be good to cast it away, too. But the may part is getting %version right, everything else is just cosmetics. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hughsient at gmail.com Mon Mar 19 21:22:51 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 19 Mar 2007 21:22:51 +0000 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <1174307515.2873.3.camel@localhost.localdomain> <13880.192.54.193.51.1174308091.squirrel@rousalka.dyndns.org> <15e53e180703190554h6059a1abx477e5c585db69e86@mail.gmail.com> Message-ID: <1174339371.10563.4.camel@localhost.localdomain> On Mon, 2007-03-19 at 21:58 +0100, Thomas M Steenholdt wrote: > Richard Hughes wrote: > > > > Locked yes, not logged in no. That's something that will be fixed > > really soon, now that g-p-m can be run headless. > > > > So lets discuss disabling cpuspeed by default (or better yet - not > installing it by default) when headless g-p-m is ready and included > in > fedora... Of course that will still require a daemon to be started. Sure, agreed. I just wanted to let you guys know. Richard. From gauret at free.fr Mon Mar 19 22:09:16 2007 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 19 Mar 2007 23:09:16 +0100 Subject: Announcing yum-merge-conf, a yum plugin to merge configuration files References: <20070313093842.GA21675@localhost> <45F729FE.1080508@olen.net> <45FD6B69.3050902@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Is there any quick way to test this plugin? Yes, just install this rpm (it's two files, the plugin and the ini file, no scriptlets) Then, you'll have to trigger the .rpm{save,new}-creating behavior by installing an old version of an rpm which has %config files, modifying one of them, and upgrading to a newer version using "yum --merge-conf update thepackage" RPM should create an .rpm{save,orig} file, which should be picked up by the plugins, and then you'll see what happens. I've been using it for a few days now, it seems to work fine for me. I'm very interested by any feedback. Thanks Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." -- Doug Gwyn From ianburrell at gmail.com Mon Mar 19 22:29:31 2007 From: ianburrell at gmail.com (Ian Burrell) Date: Mon, 19 Mar 2007 15:29:31 -0700 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174327953.14986.39.camel@erebor.boston.redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <1174327953.14986.39.camel@erebor.boston.redhat.com> Message-ID: On 3/19/07, Jeremy Katz wrote: > On Mon, 2007-03-19 at 15:21 +0530, Rahul Sundaram wrote: > > portmap. > > Not enabling this means that trying to do an NFS mount hangs > mysteriously. > It would be nice if there was dependency support between services. nfs or ypbind or other RPC server would depend on portmap. The ideal would be portmap always started before the services that needed it even when doing "/etc/init.d/nfs start". Less ideal would be for chkconfig to enable portmap when a service that required it was enabled. - Ian From mitr at volny.cz Mon Mar 19 22:45:57 2007 From: mitr at volny.cz (Miloslav Trmac) Date: Mon, 19 Mar 2007 23:45:57 +0100 Subject: [RFC] Filesystem-local databases in mlocate In-Reply-To: <58979.192.54.193.51.1174031753.squirrel@rousalka.dyndns.org> References: <45FA1A1A.9060201@volny.cz> <58979.192.54.193.51.1174031753.squirrel@rousalka.dyndns.org> Message-ID: <45FF12A5.4080702@volny.cz> Hello, Nicolas Mailhot napsal(a): > 1. You're spreading rw files all over the filesystems, which is contrary > to the FHS. Moving the database to the filesystem described by the database is the whole point. It might be the only shared filesystem between the computers, there is no other place to put the database in general. > 2. You're putting hidden directories where people won't expect them, which > will seriously annoy sysadmins None of this happens automatically. The sysadmin must edit /etc/sysconfig/mlocate in order to use filesystem-local databases. Mirek From mmcgrath at redhat.com Mon Mar 19 22:47:55 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 19 Mar 2007 17:47:55 -0500 Subject: fedora.redhat.com is no more Message-ID: <45FF131B.8050201@redhat.com> We now have a redirect for fedora.redhat.com. If you have anything specific you'd like redirected please let me know. Though these redirects will only be temporary. -Mike From mschwendt.tmp0701.nospam at arcor.de Mon Mar 19 17:56:44 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 19 Mar 2007 18:56:44 +0100 Subject: Flag Modification Denied In-Reply-To: <20070319173823.GC6336@humbolt.us.dell.com> References: <20070319173823.GC6336@humbolt.us.dell.com> Message-ID: <20070319185644.5d6efab4.mschwendt.tmp0701.nospam@arcor.de> On Mon, 19 Mar 2007 12:38:24 -0500, Michael E Brown wrote: > On Mon, Mar 19, 2007 at 12:18:28PM -0400, Konstantin Ryabitsev wrote: > > Hello, everyone: > > > > According to the new procedure, I'm supposed to set "fedora-cvs" flag > > whenever I'm requesting branches. Actually trying to do that results > > in: > > > > "You tried to request fedora-cvs. Only an authorized user can make this > > change." > > > > How would I go about getting authorized? And, generally, how would I > > go about getting authorized for any other things that I used to have > > access to before February? > > Request access to "cvsfedora" group on your FAS account: https://admin.fedora.redhat.com/accounts/userbox.cgi It's the "fedorabugs" group. From mitr at volny.cz Mon Mar 19 22:51:19 2007 From: mitr at volny.cz (Miloslav Trmac) Date: Mon, 19 Mar 2007 23:51:19 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <20070316105123.GC24022@neu.nirvana> References: <45FA1A1A.9060201@volny.cz> <20070316105123.GC24022@neu.nirvana> Message-ID: <45FF13E7.1020309@volny.cz> Hello, Axel Thimm napsal(a): >> * locate(1)'s default database is not just /var/lib/mlocate/mlocate.db; >> mlocate also checks each mounted filesystem for a .mlocate/mlocate.db >> file, owned by root or the invoking user, and not writable by anyone >> but the owner. Such files are automatically added to the database >> path. > locate should also include .mlocate/mlocate.db a previous updatedb has > found and skipped. E.g. if updatedb detects a .mlocate/mlocate.db in a > folder in its path it skips it and registers it for locate to use. This would make a difference only for "subdirectory-local" databases within a filesystem. I can't think of a reason why they would be necessary. > Perhaps that way you can even save the explicit mentioning of > --single-fs paths in /etc/sysconfig/mlocate. If a paths is to be > handled as such the admin just creates an .mlocate folder and updatedb > and locate automatically pick it up. I'd prefer a more specific administrator action; otherwise just extracting an archive could unintentionally add a mlocate database and, in the worst case, double the updatedb overhead. Mirek From mitr at volny.cz Mon Mar 19 23:04:48 2007 From: mitr at volny.cz (Miloslav Trmac) Date: Tue, 20 Mar 2007 00:04:48 +0100 Subject: [RFC] Filesystem-local databases in mlocate In-Reply-To: <20070316112606.GA14793@redhat.com> References: <45FA1A1A.9060201@volny.cz> <20070316112606.GA14793@redhat.com> Message-ID: <45FF1710.4050202@volny.cz> Hello, Tomas Janousek napsal(a): > If I understood it correctly, every locate search would read the files on the > remote volumes, right? Yes. > The performance will suffer a bit I think. For example, > NFS over 11mbit wifi is fine, but waiting tens of seconds for the database to > download isn't good. Good point. It's still an improvement over no mlocate database, though. > Probably a global locate cache db that merges all the > fs-local ones would be nice. This might inflate the local storage requirements a lot, though. In the most efficient case (system-global cache that is updated on each access) it also expands the part of locate that must run with elevated privileges. Given that this mlocate feature certainly won't be ready in time for FC7, we have enough time to experiment with caching after some practical experience is collected. Mirek From mitr at volny.cz Mon Mar 19 23:09:56 2007 From: mitr at volny.cz (Miloslav Trmac) Date: Tue, 20 Mar 2007 00:09:56 +0100 Subject: [RFC] Filesystem-local databases in mlocate In-Reply-To: <45FD2004.4040003@develer.com> References: <45FA1A1A.9060201@volny.cz> <45FD2004.4040003@develer.com> Message-ID: <45FF1844.9000808@volny.cz> Hello, Bernardo Innocenti napsal(a): >> Can anyone see a problem with the plan, or an important feature that the >> above fails to address? > I love your proposal, but I'm concerned with littering the roots of > all mountpoints with .mlocate and possibily 10 other dot files from > other applications. > > I hope that you and the authors of other system services with > similar requirements could get together and come up with a standard > place for these files named .volume/, .info/, .db/ or something > similar. Subsystems that may want to use it include full-text > search engines, quota, etc. Using a service-specific directory is slightly more secure: accessing files within the .mlocate directory is allowed only to root and the slocate user, so the risk of exploiting some other application and using the privileges to attack mlocate data files is smaller. > Maybe the LSB would care to publish a standard within the next > 10 years? It seems most successful standards codify existing practice, so there must be some practical applications first. Anyway, I'll make sure to make the mlocate database format not depend on the specific .mlocate/mlocate.db suffix. Mirek From davej at redhat.com Mon Mar 19 23:12:52 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 19 Mar 2007 19:12:52 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174327574.14986.34.camel@erebor.boston.redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> <45FEC3C2.2030500@andrei.myip.org> <1174327574.14986.34.camel@erebor.boston.redhat.com> Message-ID: <20070319231252.GC12006@redhat.com> On Mon, Mar 19, 2007 at 02:06:13PM -0400, Jeremy Katz wrote: > The real thing here is that more of the daemons which are currently > started via initscripts need to be started when the hardware is inserted > and stopped when removed. I'm sure I heard mumblings that this feature requires dbus changes that won't land until post F7. Dave -- http://www.codemonkey.org.uk From mitr at volny.cz Mon Mar 19 23:12:52 2007 From: mitr at volny.cz (Miloslav Trmac) Date: Tue, 20 Mar 2007 00:12:52 +0100 Subject: [RFC] Filesystem-local databases in mlocate In-Reply-To: <1174284641.16983.8.camel@willson> References: <45FA1A1A.9060201@volny.cz> <1174284641.16983.8.camel@willson> Message-ID: <45FF18F4.5090308@volny.cz> Simo Sorce napsal(a): >> - NFS is automatically excluded by clients, so updatedb on clients >> does not walk the filesystem. >> - On the server: >> Add /srv/home to /etc/sysconfig/mlocate. If /srv/home is not a >> separate mount point, add LOCATE_PATH=:/srv/home/.mlocate/mlocate.db >> to the global environment. > I am deeply concerned about the security implications of this idea. > You are basically making it possible for everyone to get access to the > complete remote FS layout ??? No, only the layout of the specific NFS filesystem that can be mounted from the client. mlocate.db would be readable only by the slocate user, like the current /var/lib/mlocate/mlocate.db. Therefore, if a client can fake the UID and read the whole mlocate.db, it can fake the UID and traverse the whole NFS filesystem just the same. Mirek From davej at redhat.com Mon Mar 19 23:15:36 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 19 Mar 2007 19:15:36 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE85BA.2000004@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <45FE8237.4@fedoraproject.org> <45FE85BA.2000004@fedoraproject.org> Message-ID: <20070319231536.GD12006@redhat.com> On Mon, Mar 19, 2007 at 06:14:42PM +0530, Rahul Sundaram wrote: > > RS> There is simply no need to get personal. If hardware doesn't > > RS> support it, it needs to be disabled by default. Disagree? > > > > Disagree. cpuspeed is harmless if the hardware doesn't support it. No > > reason to go out of your way to disable it. > > There is no daemon designed by be harmful. We might as well as enable > everything by default by this logic. Rahul, please read the initscript you're complaining about. If the hardware doesn't support scaling, the daemon isn't even started. We're talking about 2-3 lines of bash script here, which isn't even a blip on the radar when you look at the big picture. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Mon Mar 19 23:23:47 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 19 Mar 2007 19:23:47 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174307515.2873.3.camel@localhost.localdomain> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <1174307515.2873.3.camel@localhost.localdomain> Message-ID: <20070319232347.GE12006@redhat.com> On Mon, Mar 19, 2007 at 12:31:55PM +0000, Richard Hughes wrote: > On Mon, 2007-03-19 at 12:29 +0100, Benny Amorsen wrote: > > JB> cpuspeed is very useful, especially in the case of a laptop which > > JB> several people use as their desktop. Your narrow definition of a > > JB> desktop is perhaps too limiting. > > > > cpuspeed really isn't optional on modern desktop machines either. > > Rahul Sundaram may have lots of machines with fixed clockspeeds, but > > that is no reason to not support newer stuff. > > GNOME Power Manager can control CPU speed with policy set in the > session, usually saving power more aggressively than cpuspeed. It also > has the benefit of using a HAL addon rather than a system service, which > is only loaded if the machine is frequency scale supported. It does that by checking for existance of files in sysfs doesn't it? If so, nuking the cpuspeed service will break that, as the modules won't get loaded, and the sysfs files won't exist. > So really, I think the system daemon can be stopped by default, and > leave it there if some admin wants to install it on a big server. Read the initscript. In some cases it doesn't start the daemon but sets up the kernel ondemand module. (You don't want ondemand on all scaling implementations due to latency reasons). Dave -- http://www.codemonkey.org.uk From lsof at nodata.co.uk Mon Mar 19 23:27:09 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 20 Mar 2007 00:27:09 +0100 Subject: fedora.redhat.com is no more In-Reply-To: <45FF131B.8050201@redhat.com> References: <45FF131B.8050201@redhat.com> Message-ID: <1174346829.3627.1.camel@sb-home.lan> Am Montag, den 19.03.2007, 17:47 -0500 schrieb Mike McGrath: > We now have a redirect for fedora.redhat.com. If you have anything > specific you'd like redirected please let me know. Though these > redirects will only be temporary. > > -Mike > HTTP/1.1 302 Found Please can you change the temporary redirect (as in 302) to a permanent redirect (as in 301) so that the search engines and link checkers will see the new page. http://httpd.apache.org/docs/2.0/mod/mod_alias.html#redirect From davej at redhat.com Mon Mar 19 23:40:13 2007 From: davej at redhat.com (Dave Jones) Date: Mon, 19 Mar 2007 19:40:13 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174327953.14986.39.camel@erebor.boston.redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <1174327953.14986.39.camel@erebor.boston.redhat.com> Message-ID: <20070319234013.GF12006@redhat.com> On Mon, Mar 19, 2007 at 02:12:32PM -0400, Jeremy Katz wrote: > > mdmonitor, > > If you have RAID, this is important to have. It could be made to exit a > lot faster, though, by checking for the existence of mdadm.conf before > sourcing /etc/init.d/functions. Hmm, what about raid arrays created post install ? Checking /proc/mdstat might be safer, a la.. --- mdmonitor~ 2007-03-19 19:38:23.000000000 -0400 +++ mdmonitor 2007-03-19 19:38:38.000000000 -0400 @@ -16,6 +16,9 @@ OPTIONS="--monitor --scan -f --pid-file= prog=mdmonitor +if [ ! -f /proc/mdstat ]; then exit; fi +if [ $(cat /proc/mdstat | wc -l) -eq 2 ]; then exit; fi + # Source function library. . /etc/rc.d/init.d/functions -- http://www.codemonkey.org.uk From Axel.Thimm at ATrpms.net Mon Mar 19 23:44:11 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 00:44:11 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <45FF13E7.1020309@volny.cz> References: <45FA1A1A.9060201@volny.cz> <20070316105123.GC24022@neu.nirvana> <45FF13E7.1020309@volny.cz> Message-ID: <20070319234411.GB27468@neu.nirvana> On Mon, Mar 19, 2007 at 11:51:19PM +0100, Miloslav Trmac wrote: > Hello, > Axel Thimm napsal(a): > >> * locate(1)'s default database is not just /var/lib/mlocate/mlocate.db; > >> mlocate also checks each mounted filesystem for a .mlocate/mlocate.db > >> file, owned by root or the invoking user, and not writable by anyone > >> but the owner. Such files are automatically added to the database > >> path. > > locate should also include .mlocate/mlocate.db a previous updatedb has > > found and skipped. E.g. if updatedb detects a .mlocate/mlocate.db in a > > folder in its path it skips it and registers it for locate to use. > This would make a difference only for "subdirectory-local" databases > within a filesystem. Exactly. > I can't think of a reason why they would be necessary. Consider for example a single volume nfs server exporting /home. So you want to have updatedb create a subdirectory-local db in /home, so it can be used on remote clients. E.g. you can't assume that every exported volume will be identical to a mounted volume on the server. Every exported dir is subject to create an .mlocate/mlocate.db which for the server itself looks like an ordinary subdirectory. And instead of having to configure it in /etc/sysconfig it is easier to keep the metainformation of about where such .mlocate/mlocate.db should be maintained in the fs itself simply by creating the folder .mlocate. > > Perhaps that way you can even save the explicit mentioning of > > --single-fs paths in /etc/sysconfig/mlocate. If a paths is to be > > handled as such the admin just creates an .mlocate folder and updatedb > > and locate automatically pick it up. > I'd prefer a more specific administrator action; otherwise just > extracting an archive could unintentionally add a mlocate database and, > in the worst case, double the updatedb overhead. You mean an archive that contains .mlocate? That would be an unfortunate archiving and given that only root can do that it means the admin did it. Same would apply to quota or backup metainformation which also doesn't make sense to archive away. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mitr at volny.cz Mon Mar 19 23:50:26 2007 From: mitr at volny.cz (Miloslav Trmac) Date: Tue, 20 Mar 2007 00:50:26 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <20070319234411.GB27468@neu.nirvana> References: <45FA1A1A.9060201@volny.cz> <20070316105123.GC24022@neu.nirvana> <45FF13E7.1020309@volny.cz> <20070319234411.GB27468@neu.nirvana> Message-ID: <45FF21C2.6080604@volny.cz> Axel Thimm napsal(a): > On Mon, Mar 19, 2007 at 11:51:19PM +0100, Miloslav Trmac wrote: >> Hello, >> Axel Thimm napsal(a): >>>> * locate(1)'s default database is not just /var/lib/mlocate/mlocate.db; >>>> mlocate also checks each mounted filesystem for a .mlocate/mlocate.db >>>> file, owned by root or the invoking user, and not writable by anyone >>>> but the owner. Such files are automatically added to the database >>>> path. >>> locate should also include .mlocate/mlocate.db a previous updatedb has >>> found and skipped. E.g. if updatedb detects a .mlocate/mlocate.db in a >>> folder in its path it skips it and registers it for locate to use. >> I can't think of a reason why they would be necessary. > Consider for example a single volume nfs server exporting /home. So > you want to have updatedb create a subdirectory-local db in /home, so > it can be used on remote clients. But on the client, where locate runs, /home/foo would be a separate filesystem. As for updatedb, > And instead of having to configure it in /etc/sysconfig it is easier > to keep the metainformation of about where such .mlocate/mlocate.db > should be maintained in the fs itself simply by creating the folder > .mlocate. wouldn't it be even more practical to support FS_DB_GLOB=/srv/home/* in /etc/sysconfig/mlocate ? Mirek From gdk at redhat.com Mon Mar 19 23:48:24 2007 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Mon, 19 Mar 2007 19:48:24 -0400 (EDT) Subject: fedora.redhat.com is no more In-Reply-To: <45FF131B.8050201@redhat.com> References: <45FF131B.8050201@redhat.com> Message-ID: Ding dong, the witch is dead! :) --g On Mon, 19 Mar 2007, Mike McGrath wrote: > We now have a redirect for fedora.redhat.com. If you have anything specific > you'd like redirected please let me know. Though these redirects will only > be temporary. > > -Mike > > -- ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From katzj at redhat.com Tue Mar 20 00:47:57 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 19 Mar 2007 20:47:57 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: References: <45FE5D39.7020002@fedoraproject.org> <1174327953.14986.39.camel@erebor.boston.redhat.com> Message-ID: <1174351677.3115.2.camel@aglarond.local> On Mon, 2007-03-19 at 15:29 -0700, Ian Burrell wrote: > On 3/19/07, Jeremy Katz wrote: > > On Mon, 2007-03-19 at 15:21 +0530, Rahul Sundaram wrote: > > > portmap. > > > > Not enabling this means that trying to do an NFS mount hangs > > mysteriously. > > > > It would be nice if there was dependency support between services. > nfs or ypbind or other RPC server would depend on portmap. The ideal > would be portmap always started before the services that needed it > even when doing "/etc/init.d/nfs start". Less ideal would be for > chkconfig to enable portmap when a service that required it was > enabled. That doesn't help mount server:/path/to/export /local/place which is pretty common to expect to work[1] Jeremy [1] I still see semi-regular bug reports/questions about the need to use -o nolock when mounting nfs from the chroot in %post with kickstart. :-/ I really don't want to see the questions then also for _all_ cases of doing NFS mounts. From jwilson at redhat.com Tue Mar 20 02:02:15 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 19 Mar 2007 22:02:15 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE9290.6060404@redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> <45FE9290.6060404@redhat.com> Message-ID: <45FF40A7.3080902@redhat.com> Jarod Wilson wrote: > Rahul Sundaram wrote: >> Jarod Wilson wrote: >>> Everyone please kindly read the cpuspeed initscript before continuing to >>> hypothesize about it. It does indeed already look for necessary support, >>> and silently exits without doing a thing it its not present. >>> >>> /me is the cpuspeed maintainer... :) >> It would do that everytime on bootup though. Right? > > Yes. And within a few lines of bash, it'll exit if support isn't found. > The second line of the start function is essentially: > > if /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver doesn't exist, > immediately exit silently. Heee, need to read more closely myself. The check on the second line of the start function actually determines if we should try to load up a scaling driver, and its the check on the 23rd line (half of which are comments) that the silent exit happens if we still don't see support after trying to load up a driver. Just the same, we do bail out pretty quickly. -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Tue Mar 20 02:04:56 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 19 Mar 2007 22:04:56 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> Message-ID: <45FF4148.2040900@redhat.com> Thomas M Steenholdt wrote: > Rahul Sundaram wrote: >> Jarod Wilson wrote: >>> >>> Everyone please kindly read the cpuspeed initscript before continuing to >>> hypothesize about it. It does indeed already look for necessary support, >>> and silently exits without doing a thing it its not present. >>> >>> /me is the cpuspeed maintainer... :) >> >> It would do that everytime on bootup though. Right? Can we make it >> disable itself if the support is not there on first run? >> >> Rahul >> > > Having daemons deactivate themselves like this seems like a bad idea > from a users perspective... God knows in how many places you'd be > searching for the reason why feature xyz isn't working, if all services > would do that. The will have a pretty hard time re-enabling themselves > as it stands right now. > > Btw, from my experience, the cpuspeed daemon isn't even started from the > initscript (at least on my machine, running FC6), it really only > modprobes the cpufreq_ondemand module. Yep, we try to use the in-kernel ondemand governor wherever possible, only falling back to userspace (cpuspeed daemon) when we have to or when the user has set userspace as their governor. It modprobes, *and* twiddles things in /sys/devices/system/cpu/cpu*/cpufreq/. :) -- Jarod Wilson jwilson at redhat.com From buildsys at fedoraproject.org Tue Mar 20 02:11:15 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Mon, 19 Mar 2007 22:11:15 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-19 Message-ID: <20070320021115.DF76F152130@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 1 openbabel-2.1.0-0.2.b6.fc7 openbabel-2.1.0-0.2.b6.fc7 -------------------------- For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From brent at brentnorris.net Tue Mar 20 02:17:59 2007 From: brent at brentnorris.net (Brent) Date: Mon, 19 Mar 2007 21:17:59 -0500 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE8942.8050602@redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> Message-ID: <45FF4457.4080309@brentnorris.net> Jarod Wilson wrote: > Everyone please kindly read the cpuspeed initscript before continuing to > hypothesize about it. It does indeed already look for necessary support, > and silently exits without doing a thing it its not present. > > /me is the cpuspeed maintainer... :) Perhaps a new third result for initscripts. Instead of just [ok] or [Failed], maybe a new one like [Unneeded] or [N/A] or something. Might help people realize that these things are running instead of giving them the impression that they are running and using system resources. Just and idea. Brent From jwilson at redhat.com Tue Mar 20 02:19:54 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 19 Mar 2007 22:19:54 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <20070319232347.GE12006@redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <1174301148.2977.21.camel@vader.jdub.homelinux.org> <1174307515.2873.3.camel@localhost.localdomain> <20070319232347.GE12006@redhat.com> Message-ID: <45FF44CA.4010009@redhat.com> Dave Jones wrote: > On Mon, Mar 19, 2007 at 12:31:55PM +0000, Richard Hughes wrote: > > On Mon, 2007-03-19 at 12:29 +0100, Benny Amorsen wrote: > > > JB> cpuspeed is very useful, especially in the case of a laptop which > > > JB> several people use as their desktop. Your narrow definition of a > > > JB> desktop is perhaps too limiting. > > > > > > cpuspeed really isn't optional on modern desktop machines either. > > > Rahul Sundaram may have lots of machines with fixed clockspeeds, but > > > that is no reason to not support newer stuff. > > > > GNOME Power Manager can control CPU speed with policy set in the > > session, usually saving power more aggressively than cpuspeed. It also > > has the benefit of using a HAL addon rather than a system service, which > > is only loaded if the machine is frequency scale supported. > > It does that by checking for existance of files in sysfs doesn't it? > If so, nuking the cpuspeed service will break that, as the modules won't > get loaded, and the sysfs files won't exist. I think it depends on the frequency scaling driver. If I recall correctly, you get nothing in the acpi-cpufreq case, but in the powernow-k8 case, you still have most of the sysfs bits present (including access to the performance and userspace governors). -- Jarod Wilson jwilson at redhat.com From jwilson at redhat.com Tue Mar 20 02:28:11 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Mon, 19 Mar 2007 22:28:11 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FF4457.4080309@brentnorris.net> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FF4457.4080309@brentnorris.net> Message-ID: <45FF46BB.2000701@redhat.com> Brent wrote: > Jarod Wilson wrote: >> Everyone please kindly read the cpuspeed initscript before continuing to >> hypothesize about it. It does indeed already look for necessary support, >> and silently exits without doing a thing it its not present. >> >> /me is the cpuspeed maintainer... :) > Perhaps a new third result for initscripts. Instead of just [ok] or > [Failed], maybe a new one like [Unneeded] or [N/A] or something. We already have a 3rd result, 'warning', but... > Might help people realize that these things are running instead of > giving them the impression that they are running and using system > resources. ...Meh. I prefer what we do w/cpuspeed right now. If the support isn't there, we silently exit. We never even print out a "starting cpuspeed:" or any status. -- Jarod Wilson jwilson at redhat.com From brent at brentnorris.net Tue Mar 20 02:32:07 2007 From: brent at brentnorris.net (Brent) Date: Mon, 19 Mar 2007 21:32:07 -0500 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FF4457.4080309@brentnorris.net> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FF4457.4080309@brentnorris.net> Message-ID: <45FF47A7.6080800@brentnorris.net> Brent wrote: > Might help people realize that these things are running instead of > giving them the impression that they are running and using system > resources. ^^^ aren't Sorry, just wanted to clear that up. Brent From rc040203 at freenet.de Tue Mar 20 04:36:48 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 20 Mar 2007 05:36:48 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> Message-ID: <1174365408.4531.35.camel@mccallum.corsepiu.local> On Mon, 2007-03-19 at 18:04 +0100, Krzysztof Halasa wrote: > Ralf Corsepius writes: > > > I.e. I'd claim Fedora to require a > > minimum bandwidth: ~300kb/s > > recommended bandwidth >= 1000kb/s > > 350 kbps = ~ 3.5 GB a day. In an ideal world, yes. => ~1GB / working day (8hrs) => < ~500MB per "uptime" for users booting for "a couple of hours a day". In practice, real world bandwidth is below this. > Not sure what problems are you talking about. If you update an existing Fedora installation once a week, you'll observe one update to typically be in the order of "some 100MBs" (occasionally several 100MBs). > Slow mirrors maybe? Yes, this is one issue, but there are others. For example: * broken mirrors * periodic interrupts on DSL each 24hrs (=> Downloading isos is a matter of syncs between these interrupts) * other network load (downloading isn't the only usage of a system) * mirrors being updated (and temporarily corrupted) right midst of a "yum update". > Your fast connection wouldn't make them faster. Sorry - No, bandwidth makes a HUGE difference. The whole "way of working with Fedora" changes upon available bandwidth. > I suspect some location-related problems (does the mirror list differs > based on IP/reverse DNS name/etc?). Or maybe your DSL line is way > slower than marketed? With my 512 kbps DSL I can easily get the 64-bit > DVD image in 24 hrs, let alone openoffice. Now change to some X000 DSL - You'll probably very soon notice what I said above. Or change to ISDN/modem ... (ca. 1/10th of the bandwidth you currently have) - Any major update is becoming a killer, in such situations. > Perhaps you should switch to night updates? If yum was working reliable, this would have been an option to me. I resorted to "weekly updates" on weekends and "selective updates" throughout weekdays. Ralf From naoki at valuecommerce.com Tue Mar 20 08:09:52 2007 From: naoki at valuecommerce.com (Naoki) Date: Tue, 20 Mar 2007 17:09:52 +0900 Subject: OCFS2 and tools in FC. Message-ID: <1174378192.13906.12.camel@localhost.localdomain> Hello all, OCFS2 made it into the mainstream kernel a while ago. But while Debian and SUSE ship OCFS2 tools, FC does not. Is this simply a case of nobody submitting them, or is there a license issue (nah, it's GPL) ? If the answer is the former then is there time to add them before FC7 ? It's the only main line clustered file system and I'd like to run it through the gauntlet with my favourite OS. Cheers. From laroche at redhat.com Tue Mar 20 08:51:33 2007 From: laroche at redhat.com (Florian La Roche) Date: Tue, 20 Mar 2007 09:51:33 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FE6A9A.6080505@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> Message-ID: <20070320085133.GA3092@dudweiler.stuttgart.redhat.com> On Mon, Mar 19, 2007 at 04:18:58PM +0530, Rahul Sundaram wrote: > Florian La Roche wrote: > >On Mon, Mar 19, 2007 at 04:01:39PM +0530, Rahul Sundaram wrote: > >>Nicolas Mailhot wrote: > >>>Le Lun 19 mars 2007 10:51, Rahul Sundaram a ?crit : > >>> > >>>>Extra - cpuspeed. mdmonitor, netfs, ntpd, portmap. Can't see a reason to > >>>>enable these by default. > >>>cpuspeed, mdmonitor and ntpd are no more extra than NetworkManager > >>Yes, They are. For a desktop. A Live CD is targeted at the desktop. > >>Nothing else. > > > > > >We should really target a Live-DVD instead of a Live-CD. > > DVD drives are way too costly in many regions. We still need a Live CD. Rahul, this is really wrong. First goal should be a good DVD. This does not prevent a smaller CD to show up, but those will really be more specialized for certain setups anyway. It is also really wrong to select exim instead of the default sendmail. I am all for improving exim and checking if it should be default in the future for Fedora, but changing this from a default install to the Live-CD is not very good. regards, Florian La Roche From abo at kth.se Tue Mar 20 09:11:44 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Tue, 20 Mar 2007 10:11:44 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <45FE5D39.7020002@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> Message-ID: <1174381904.3528.175.camel@home.alexander.bostrom.net> m?n 2007-03-19 klockan 15:21 +0530 skrev Rahul Sundaram: > Hi > > Been fiddling with a installation of Fedora 7 Test 2 from the Live CD > and it still enables way too may daemons by default. Oh, is the SSH server still enabled by default (if you install the openssh-server package)? Because if it is, pretty pretty please disable it! People don't use good passwords and they don't realize that their password can be used remotely. Giving millions of people an sshd they don't know or care about is a recipe for zombie machines and bad security reputation. /abo From nicolas.mailhot at laposte.net Tue Mar 20 09:24:25 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 20 Mar 2007 10:24:25 +0100 (CET) Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174381904.3528.175.camel@home.alexander.bostrom.net> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> Message-ID: <24903.192.54.193.51.1174382665.squirrel@rousalka.dyndns.org> Le Mar 20 mars 2007 10:11, Alexander Bostr?m a ?crit : > m?n 2007-03-19 klockan 15:21 +0530 skrev Rahul Sundaram: >> Hi >> >> Been fiddling with a installation of Fedora 7 Test 2 from the Live CD >> and it still enables way too may daemons by default. > > Oh, is the SSH server still enabled by default (if you install the > openssh-server package)? > > Because if it is, pretty pretty please disable it! > > People don't use good passwords and they don't realize that their > password can be used remotely. Giving millions of people an sshd they > don't know or care about is a recipe for zombie machines and bad > security reputation. Disabling ssh is not a good solution, many people need it. However the default fedora ssh setup is woefully insecure At least ssh rate-limiting should be in the default firewall install. Pam_abl would be even better (for other network services) Haven't we sat on this problem too long already ? -- Nicolas Mailhot From ml at deadbabylon.de Tue Mar 20 09:38:04 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 20 Mar 2007 10:38:04 +0100 Subject: KDE-Live-CD: basic cd layout and localizations In-Reply-To: <45FE00B7.5000603@fedoraproject.org> References: <20070314011000.5b0cbcb8@localhost.localdomain> <200703182359.32762.ml@deadbabylon.de> <45FDC503.3000508@fedoraproject.org> <200703190038.05132.ml@deadbabylon.de> <45FE00B7.5000603@fedoraproject.org> Message-ID: <20070320103804.3c8445f2@localhost.localdomain> Am Mon, 19 Mar 2007 08:47:11 +0530 schrieb Rahul Sundaram : > It produced a 650 MB KDE ISO image. Booting it on qemu fails with the > same error message as described in the above bug report. I am not > sure which udev it downloaded. Are the packages downloaded saved > anywhere? The downloaded rpms in (default) /var/tmp/livecd-creator/build-*/yum-cache/ would be deleted in the cleanup. But you can chroot into the iso: # mkdir /mnt/iso # mount -o loop .iso /mnt/iso # mount -o loop -t squashfs /mnt/iso/squashfs.img /mnt/iso/sysroot # mount -o loop /mnt/iso/sysroot/os.img /mnt/iso/sysroot/sysroot # rpm -q udev It should be udev-106 because this is the only version in rawhide atm. I've tried to replace this with udev-105 when using the --shell command from the git-version. But it seems not to work. So the only way I know to create a bootable iso atm is to have a local repository of [development] with udev-105 only. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ml at deadbabylon.de Tue Mar 20 09:38:43 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 20 Mar 2007 10:38:43 +0100 Subject: KDE-Live-CD: basic cd layout and localizations In-Reply-To: References: <20070314011000.5b0cbcb8@localhost.localdomain> Message-ID: <20070320103843.02351679@localhost.localdomain> Am Mon, 19 Mar 2007 06:55:56 -0500 schrieb Rex Dieter : > Sebastian Vahl wrote: > > > I've created a new basic layout for the cd: > > http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/KDELiveCD > > The size on todays rawhide is about 667 MB. > > Please tell me which package should be added or removed. > > Just found today you should add > xine-lib-extras > to the pkglist (for arts support). Ok. I will include it in the next version. Thanks. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From giallu at gmail.com Tue Mar 20 09:42:14 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 20 Mar 2007 10:42:14 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <20070320085133.GA3092@dudweiler.stuttgart.redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <20070320085133.GA3092@dudweiler.stuttgart.redhat.com> Message-ID: On 3/20/07, Florian La Roche wrote: > > It is also really wrong to select exim instead of the default sendmail. > I am all for improving exim and checking if it should be default in the > future for Fedora, but changing this from a default install to the > Live-CD is not very good. IIRC exim landed on the LiveCD mostly by chance, being the package with the shorter name satisfying the /usr/sbin/sendmail require... From tmus at tmus.dk Tue Mar 20 09:42:55 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 20 Mar 2007 10:42:55 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <24903.192.54.193.51.1174382665.squirrel@rousalka.dyndns.org> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <24903.192.54.193.51.1174382665.squirrel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > > Disabling ssh is not a good solution, many people need it. However the > default fedora ssh setup is woefully insecure > > At least ssh rate-limiting should be in the default firewall install. > Pam_abl would be even better (for other network services) > Blacklisting opens the potential for denial-of-service attacks. I'm not too familiar with the pam_abl implementation, but we should at least be very cautious if we choose to include and enable such features by default. Same thing goes for rate-limiting. I'm not saying that either of these are *bad*. I'm saying that for default setups, we need to be very cautious with these things. A more direct, less intrusive (for some/most) approach would perhaps be to disallow root logins by default?!? /Thomas From abo at kth.se Tue Mar 20 09:46:41 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Tue, 20 Mar 2007 10:46:41 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <24903.192.54.193.51.1174382665.squirrel@rousalka.dyndns.org> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <24903.192.54.193.51.1174382665.squirrel@rousalka.dyndns.org> Message-ID: <1174384001.3528.182.camel@home.alexander.bostrom.net> tis 2007-03-20 klockan 10:24 +0100 skrev Nicolas Mailhot: > Disabling ssh is not a good solution, many people need it. However the > default fedora ssh setup is woefully insecure I think it can be off by default. To use it securely you should log in locally and look at or replace the host key anyway, so you might as well enable it at the same time. (But I guess people use SSH for better-than-nothing security, rather than checking host keys.) > At least ssh rate-limiting should be in the default firewall install. That'll just delay the problem. > Haven't we sat on this problem too long already ? This I can agree with. :) /abo From nicolas.mailhot at laposte.net Tue Mar 20 09:53:20 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 20 Mar 2007 10:53:20 +0100 (CET) Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <24903.192.54.193.51.1174382665.squirrel@rousalka.dyndns.org> Message-ID: <19400.192.54.193.51.1174384400.squirrel@rousalka.dyndns.org> Le Mar 20 mars 2007 10:42, Thomas M Steenholdt a ?crit : > Nicolas Mailhot wrote: >> >> Disabling ssh is not a good solution, many people need it. However the >> default fedora ssh setup is woefully insecure >> >> At least ssh rate-limiting should be in the default firewall install. >> Pam_abl would be even better (for other network services) >> > > Blacklisting opens the potential for denial-of-service attacks. I'm not > too familiar with the pam_abl implementation, You have per-source-host and per-target-user tuneables > but we should at least be > very cautious if we choose to include and enable such features by default. Sure. But sitting on the problem won't solve it. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Tue Mar 20 09:55:55 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 20 Mar 2007 10:55:55 +0100 (CET) Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174384001.3528.182.camel@home.alexander.bostrom.net> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <24903.192.54.193.51.1174382665.squirrel@rousalka.dyndns.org> <1174384001.3528.182.camel@home.alexander.bostrom.net> Message-ID: <31175.192.54.193.51.1174384555.squirrel@rousalka.dyndns.org> Le Mar 20 mars 2007 10:46, Alexander Bostr?m a ?crit : > tis 2007-03-20 klockan 10:24 +0100 skrev Nicolas Mailhot: > >> Disabling ssh is not a good solution, many people need it. However the >> default fedora ssh setup is woefully insecure > > I think it can be off by default. To use it securely you should log in > locally and look at or replace the host key anyway, so you might as well > enable it at the same time. (But I guess people use SSH for > better-than-nothing security, rather than checking host keys.) > >> At least ssh rate-limiting should be in the default firewall install. > > That'll just delay the problem. For casual brute-force attacks it will solve the problem, but it's true firewall-level blacklisting is prone to DOSing (as opposed to pam-level blacklisting that knows about "users") -- Nicolas Mailhot From Axel.Thimm at ATrpms.net Tue Mar 20 09:56:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 10:56:29 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <45FF21C2.6080604@volny.cz> References: <45FA1A1A.9060201@volny.cz> <20070316105123.GC24022@neu.nirvana> <45FF13E7.1020309@volny.cz> <20070319234411.GB27468@neu.nirvana> <45FF21C2.6080604@volny.cz> Message-ID: <20070320095629.GE14567@neu.nirvana> On Tue, Mar 20, 2007 at 12:50:26AM +0100, Miloslav Trmac wrote: > Axel Thimm napsal(a): > > On Mon, Mar 19, 2007 at 11:51:19PM +0100, Miloslav Trmac wrote: > >> Hello, > >> Axel Thimm napsal(a): > >>>> * locate(1)'s default database is not just /var/lib/mlocate/mlocate.db; > >>>> mlocate also checks each mounted filesystem for a .mlocate/mlocate.db > >>>> file, owned by root or the invoking user, and not writable by anyone > >>>> but the owner. Such files are automatically added to the database > >>>> path. > >>> locate should also include .mlocate/mlocate.db a previous updatedb has > >>> found and skipped. E.g. if updatedb detects a .mlocate/mlocate.db in a > >>> folder in its path it skips it and registers it for locate to use. > >> I can't think of a reason why they would be necessary. > > Consider for example a single volume nfs server exporting /home. So > > you want to have updatedb create a subdirectory-local db in /home, so > > it can be used on remote clients. > But on the client, where locate runs, /home/foo would be a separate > filesystem. Yes, but updatedb (and locate) runs also on the server. > As for updatedb, > > And instead of having to configure it in /etc/sysconfig it is easier > > to keep the metainformation of about where such .mlocate/mlocate.db > > should be maintained in the fs itself simply by creating the folder > > .mlocate. > wouldn't it be even more practical to support > FS_DB_GLOB=/srv/home/* > in /etc/sysconfig/mlocate ? It's better not to have any knowledge under /etc of where special .mlocate/mlocate.db are injected on the (local) filesystem. Consider the (local) volume in question to be mounted from a SAN device, maybe even in a cluster active/passive setup. Or consider moving a data disk from one system to another. It's better to try and keep the metainformation non-global (e.g. out of /etc) and self-describing, so it is rather transparent for the admin. Otherwise he needs to cater for any change of host <-> storage mapping in mlocate as well. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tmus at tmus.dk Tue Mar 20 09:59:46 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 20 Mar 2007 10:59:46 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <19400.192.54.193.51.1174384400.squirrel@rousalka.dyndns.org> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <24903.192.54.193.51.1174382665.squirrel@rousalka.dyndns.org> <19400.192.54.193.51.1174384400.squirrel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > Le Mar 20 mars 2007 10:42, Thomas M Steenholdt a ?crit : >> Nicolas Mailhot wrote: >>> Disabling ssh is not a good solution, many people need it. However the >>> default fedora ssh setup is woefully insecure >>> >>> At least ssh rate-limiting should be in the default firewall install. >>> Pam_abl would be even better (for other network services) >>> >> Blacklisting opens the potential for denial-of-service attacks. I'm not >> too familiar with the pam_abl implementation, > > You have per-source-host and per-target-user tuneables Potential problems with user=root and/or IP spoofing? > >> but we should at least be >> very cautious if we choose to include and enable such features by default. > > Sure. But sitting on the problem won't solve it. > Agreed! /Thomas From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Mar 20 10:08:21 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 20 Mar 2007 11:08:21 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FF46BB.2000701@redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FF4457.4080309@brentnorris.net> <45FF46BB.2000701@redhat.com> Message-ID: <20070320110821.0c5e92c6@python3.es.egwn.lan> Jarod Wilson wrote : > > Perhaps a new third result for initscripts. Instead of just [ok] or > > [Failed], maybe a new one like [Unneeded] or [N/A] or something. > > We already have a 3rd result, 'warning', but... We also have that yellow [PASSED] :-) I have no idea what the initial idea behind it was. Maybe notting knows. > > Might help people realize that these things are running instead of > > giving them the impression that they are running and using system > > resources. > > ...Meh. I prefer what we do w/cpuspeed right now. If the support isn't > there, we silently exit. We never even print out a "starting cpuspeed:" > or any status. This can be a little confusing from a user perspective : "I enabled the service, so why doesn't it start when I boot?". But scripts wanting to do this could easily put useful information into /var/log/messages. A possible solution for "on demand" services would be : - If the service is disabled, never run it. - If the service is enabled : - If the relevant hardware is present, start the service - If the relevant hardware isn't present, skip starting the service Then once all the hooks are present to be able to start/stop services upon hot (un)plugging devices, start/stop the service when detecting the device's addition or removal, if the service is enabled. That way we can keep useful services "enabled" by default, although they'll only actually run if/when the relevant devices are detected. And we still leave experienced users a way to completely disable services they wouldn't want running for whatever reason. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2911.6.5.fc6 Load : 0.63 0.30 0.31 From buildsys at redhat.com Tue Mar 20 10:10:13 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 20 Mar 2007 06:10:13 -0400 Subject: rawhide report: 20070320 changes Message-ID: <200703201010.l2KAADpE013829@hs20-bc2-6.build.redhat.com> New package java-1.5.0-gcj JPackage runtime compatibility layer for GCJ New package sinjdoc Documentation generator for Java source code New package xml-commons-apis APIs for DOM, SAX, and JAXP New package xml-commons-which Which subproject of xml-commons Updated Packages: ConsoleKit-0.2.0-2.fc7 ---------------------- * Mon Mar 19 2007 David Zeuthen - 0.2.0-2 - BR gtk2-devel and make ConsoleKit Require gtk2 (could just be libX11 with a simple patch) * Mon Mar 19 2007 David Zeuthen - 0.2.0-1 - Update to upstream release 0.2.0 - Daemonize properly (#229206) SDL-1.2.11-1 ------------ * Mon Mar 19 2007 Thomas Woerner 1.2.11-1 - new version 1.2.11 - fixed man page SDL_ListModes (rhbz#208212) - fixed spurious esound, audiofile dependencies (rhbz#217389) Thanks to Ville Skytt?? for the patch - dropped requirements for imake and libXt-devel (rhbz#226402) - made nasm arch %{ix86} only (rhbz#226402) - dropped O3 from options (rhbz#226402) - dropped tagname environment variable (rhbz#226402) anaconda-11.2.0.38-1 -------------------- * Mon Mar 19 2007 Chris Lumens - 11.2.0.38-1 - Add new firewire modules (katzj, #231708). - String fixes (#232778). - Update for new system-config-date (#232905). - Fix package selection (#232701). - Default to no drives selected on the RAID screen (#195636). - Display a caps lock warning on the password screen (#207894). - Kickstart documentation updates (#209966). ant-0:1.6.5-4jpp.2.fc7 ---------------------- * Mon Mar 19 2007 Permaine Cheung 1.6.5-4jpp.2 - Get rid of the Provides for ant-optional and ant-optional-full. authconfig-5.3.13-2.fc7 ----------------------- * Mon Mar 19 2007 Tomas Mraz - 5.3.13-2 - nss_ldap is now in /usr/lib (#232975) automake15-1.5-21 ----------------- * Mon Mar 19 2007 Karsten Hopp 1.5-21 - remove erroneous provides (#224569) classpathx-mail-0:1.1.1-4jpp.3 ------------------------------ * Fri Mar 16 2007 Thomas Fitzsimmons - 0:1.1.1-4jpp.3 - Remove gnu-crypto build requirement. control-center-1:2.18.0-3.fc7 ----------------------------- * Mon Mar 19 2007 Soren Sandmann - 2.18.0-3 - Add control-center-2.18 * Mon Mar 19 2007 Matthias Clasen - 2.18.0-2 - Don't show the theme installer in the menus dovecot-1.0-7.rc27.fc7 ---------------------- * Mon Mar 19 2007 Tomas Janousek - 1.0-7.rc27 - use dovecot-sieve's version for the package * Mon Mar 19 2007 Tomas Janousek - 1.0-6.rc27 - update to latest upstream - added dovecot-sieve * Fri Mar 02 2007 Tomas Janousek - 1.0-5.rc25 - update to latest upstream eel2-2.18.0.1-2.fc7 ------------------- * Mon Mar 19 2007 Soren Sandmann - 2.18.0.1-2 - Add patch that makes eel-background.c use GnomeBG from libgnome-desktop. fedora-logos-6.0.96-1.fc7 ------------------------- * Tue Mar 20 2007 Matthias Clasen - 6.0.96-1 - Add dual screen backgrounds festival-1.96-0.11.fc7 ---------------------- * Mon Mar 19 2007 David Zeuthen 1.96-0.11 - Forgot to add the .scm files * Mon Mar 19 2007 David Zeuthen 1.96-0.10 - Update to Matthew Miller's much improved package (#232105) - Move the buildroot patch around * Sun Mar 18 2007 Matthew Miller 1.96-0.9 - fix the library link patch to use -lncurses instead of -ltinfo -- the later is all that's really needed, but the former works on older distros too. gdm-1:2.18.0-4.fc7 ------------------ * Mon Mar 19 2007 Ray Strode - 1:2.18.0-4 - update and reenable security token patch * Mon Mar 19 2007 David Zeuthen - 1:2.18.0-3 - Also pass AT's to the session from the plain greeter (#232518) - New faces including new subpackage gdm-extra-faces gnome-desktop-2.18.0-2.fc7 -------------------------- * Mon Mar 19 2007 Soren Sandmann - 2.18.0-2 - Add GnomeBG class. guile-5:1.8.1-3.fc7 ------------------- * Mon Mar 19 2007 Miroslav Lichvar - 5:1.8.1-3 - spec cleanup intltool-0.35.5-2.fc7 --------------------- * Mon Mar 19 2007 Bill Nottingham - 0.35.5-2 - add upstream changeset 674 (GNOME bz#413461 - fix intltool-extract path) iproute-2.6.20-2.fc7 -------------------- * Mon Mar 19 2007 Radek Vok??l - 2.6.20-2 - fix broken tc-pfifo man page (#232891) kernel-2.6.20-1.2999.fc7 ------------------------ * Mon Mar 19 2007 Dave Jones - 2.6.21-rc4-git4 * Mon Mar 19 2007 Dave Jones - Only enable sleep-in-irq debugging in the -debug build. lvm2-2.02.24-1.fc7 ------------------ * Mon Mar 19 2007 Alasdair Kergon - 2.02.24-1 - Add BuildRequires readline-static until makefiles get fixed. - Fix processing of exit status in init scripts - Fix vgremove to require at least one vg argument. - Fix reading of striped LVs in LVM1 format. - Flag nolocking as clustered so clvmd startup sees clustered LVs. - Add a few missing pieces of vgname command line validation. - Support the /dev/mapper prefix on most command lines. mkinitrd-6.0.8-3 ---------------- * Tue Mar 20 2007 David Cantrell - 6.0.8-3 - Rebuild for GNU parted-1.8.5 * Mon Mar 19 2007 David Cantrell - 6.0.8-2 - Rebuild for GNU parted-1.8.4 mutt-5:1.5.14-3.fc7 ------------------- * Mon Mar 19 2007 Miroslav Lichvar 5:1.5.14-3 - fix building * Mon Mar 19 2007 Miroslav Lichvar 5:1.5.14-2 - add check_mbox_size configuration variable; if enabled, file size is used instead of access time when checking for new mail - bind delete key to delete-char (#232601) openssh-4.5p1-5.fc7 ------------------- * Mon Mar 19 2007 Tomas Mraz - 4.5p1-5 - make profile.d/gnome-ssh-askpass.* regular files (#226218) parted-1.8.5-1.fc7 ------------------ * Tue Mar 20 2007 David Cantrell - 1.8.5-1 - Upgrade to GNU parted-1.8.5 (added missing po files) * Fri Mar 16 2007 David Cantrell - 1.8.4-1 - Upgrade to GNU parted-1.8.4, summary of major changes: a) Update to use newest GNU developer tools b) Use gnulib, the GNU portability library c) HFS+ resize support d) Windows Vista fixes e) AIX disk label fixes f) >512 byte logical sector read support on Linux - Spec file cleanups per Fedora packaging guidelines policycoreutils-2.0.7-4.fc7 --------------------------- * Mon Mar 19 2007 Dan Walsh 2.0.7-4 - Add polgen gui - Many fixes to system-config-selinux pykickstart-0.100-1.fc7 ----------------------- * Mon Mar 19 2007 Chris Lumens - 0.100-1 - bootloader should be written out after upgrade/install. - Treat class names as unicode strings (#231053). pyparted-1.8.5-3.fc7 -------------------- * Tue Mar 20 2007 David Cantrell - 1.8.5-3 - Rebuild for GNU parted-1.8.5 * Mon Mar 19 2007 David Cantrell - 1.8.5-2 - Rebuild for GNU parted-1.8.4 qt-1:3.3.8-1.fc7 ---------------- * Mon Mar 19 2007 Than Ngo 1:3.3.8-1.fc7 - update to 3.3.8 redhat-menus-7.8.11-1.fc7 ------------------------- * Mon Mar 19 2007 Matthias Clasen - 7.8.11-1 - Don't use Application category samba-0:3.0.24-5.fc7 -------------------- * Mon Mar 19 2007 Simo Sorce 3.0.24-5.fc7 - fix pam_winbindd bug that prevents local users to log in (patch by GD) - actually use the correct samba.pamd file not the old samba.pamd.stack file - fix logifles and use upstream convention of log.* instead of our old *.log Winbindd creates its own log.* files anyway so we will be more consistent - install our own (enhanced) default smb.conf file - Fix pam_winbind acct_mgmt PAM result code (prevented local users from logging in). Fixed by Guenther. - move some files from samba to samba-common as they are used with winbindd as well screen-4.0.3-4.fc7 ------------------ * Mon Mar 19 2007 Marcela Maslanova - 4.0.3-4 - rebuilt (change in spec file) selinux-policy-2.5.8-8.fc7 -------------------------- * Mon Mar 19 2007 Dan Walsh 2.5.8-8 - Fixes for samba_var_t * Mon Mar 19 2007 Dan Walsh 2.5.8-7 - Allow networkmanager to setpgid - Fixes for hal_acl_t * Mon Mar 19 2007 Dan Walsh 2.5.8-6 - Remove disable_trans booleans - hald_acl_t needs to talk to nscd sqlite-3.3.13-1.fc7 ------------------- * Mon Mar 19 2007 Paul Nasrat - 3.3.13-1 - Update to 3.3.13 system-config-kickstart-2.7.4-1.fc7 ----------------------------------- * Mon Mar 19 2007 Chris Lumens 2.7.4-1 - Fix loading packages section (#232285). - Fix preview/save on upgrade (#232282). - Add UI for authconfig's --ldaploadcert option (#232664). system-config-users-1.2.53-1.fc7 -------------------------------- * Mon Mar 19 2007 Nils Philippsen - 1.2.53 - some UI cleanup - when adding new users, let gid be set manually (#201500) * Mon Feb 05 2007 Nils Philippsen - fix erroneous tooltips (#227205) - mark python files as utf-8 (#226772) * Thu Feb 01 2007 Nils Philippsen - use named arguments in translatable format strings - use ngettext to allow proper pluralization usermode-1.91-1 --------------- * Mon Mar 19 2007 Miloslav Trmac - 1.91-1 - Preserve environment variables in consolehelper if specified in the service config file Related: #213402 webalizer-2.01_10-32 -------------------- * Mon Mar 19 2007 Joe Orton 2.01_10-32 - spec file cleanups (#226536): * convert to UTF-8 * fix BuildRoot, Summary * add Requires(pre) for shadow-utils, remove Prereqs * trim BuildRequires to png-devel, db4-devel * use smp_mflags in make * use sysconfdir macro throughout * preserve file timestamps on installation xorg-x11-drv-nv-2.0.0-1.fc7 --------------------------- * Mon Mar 19 2007 Adam Jackson 2.0.0-1 - Update to 2.0.0. xorg-x11-drv-siliconmotion-1.5.1-1.fc7 -------------------------------------- * Mon Mar 19 2007 Adam Jackson 1.5.1-1 - Update to 1.5.1 xorg-x11-drv-tdfx-1.3.0-4.fc7 ----------------------------- * Mon Mar 19 2007 Adam Jackson 1.3.0-4 - tdfx-1.3.0-fix-ddc-order.patch: Move DDC probe before mode validation. xorg-x11-server-1.2.99.902-1.fc7 -------------------------------- * Mon Mar 19 2007 Adam Jackson 1.2.99.902-1 - xserver 1.3 RC2. 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 thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Mar 20 10:21:00 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 20 Mar 2007 11:21:00 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <20070319234013.GF12006@redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <1174327953.14986.39.camel@erebor.boston.redhat.com> <20070319234013.GF12006@redhat.com> Message-ID: <20070320112100.4361a429@python3.es.egwn.lan> Dave Jones wrote : > On Mon, Mar 19, 2007 at 02:12:32PM -0400, Jeremy Katz wrote: > > > > mdmonitor, > > > > If you have RAID, this is important to have. It could be made to exit a > > lot faster, though, by checking for the existence of mdadm.conf before > > sourcing /etc/init.d/functions. > > Hmm, what about raid arrays created post install ? > Checking /proc/mdstat might be safer, a la.. > > --- mdmonitor~ 2007-03-19 19:38:23.000000000 -0400 > +++ mdmonitor 2007-03-19 19:38:38.000000000 -0400 > @@ -16,6 +16,9 @@ OPTIONS="--monitor --scan -f --pid-file= > > prog=mdmonitor > > +if [ ! -f /proc/mdstat ]; then exit; fi > +if [ $(cat /proc/mdstat | wc -l) -eq 2 ]; then exit; fi > + > # Source function library. > . /etc/rc.d/init.d/functions Sometimes it's easy to recognize a C programmer ;-) # Skip starting if we have no proc entry or if it has 2 lines or less [ $(cat /proc/mdstat 2>/dev/null | wc -l) -le 2 ] && exit 0 (warning, totally untested!) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2911.6.5.fc6 Load : 1.07 1.05 0.84 From ndbecker2 at gmail.com Tue Mar 20 10:22:56 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 20 Mar 2007 06:22:56 -0400 Subject: Improvement to rescue mode? Message-ID: I have found on a number of occasions that I wanted to use a rescue cd to boot an installation, where the grub install was broken. It would be really helpful if the fedora rescue mode would allow this. From nicolas.mailhot at laposte.net Tue Mar 20 10:28:12 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 20 Mar 2007 11:28:12 +0100 (CET) Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <24903.192.54.193.51.1174382665.squirrel@rousalka.dyndns.org> <19400.192.54.193.51.1174384400.squirrel@rousalka.dyndns.org> Message-ID: <49522.192.54.193.51.1174386492.squirrel@rousalka.dyndns.org> Le Mar 20 mars 2007 10:59, Thomas M Steenholdt a ?crit : > Nicolas Mailhot wrote: >> Le Mar 20 mars 2007 10:42, Thomas M Steenholdt a ?crit : >>> Nicolas Mailhot wrote: >>>> Disabling ssh is not a good solution, many people need it. However the >>>> default fedora ssh setup is woefully insecure >>>> >>>> At least ssh rate-limiting should be in the default firewall install. >>>> Pam_abl would be even better (for other network services) >>>> >>> Blacklisting opens the potential for denial-of-service attacks. I'm not >>> too familiar with the pam_abl implementation, >> >> You have per-source-host and per-target-user tuneables > > Potential problems with user=root and/or IP spoofing? You have to balance the risk of DOSing with the protection level. But at least you can special-case dangerous users, and protect against distributed root attacks, which iptables won't notice. -- Nicolas Mailhot From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Mar 20 10:31:11 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 20 Mar 2007 11:31:11 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <31175.192.54.193.51.1174384555.squirrel@rousalka.dyndns.org> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <24903.192.54.193.51.1174382665.squirrel@rousalka.dyndns.org> <1174384001.3528.182.camel@home.alexander.bostrom.net> <31175.192.54.193.51.1174384555.squirrel@rousalka.dyndns.org> Message-ID: <20070320113111.44e61612@python3.es.egwn.lan> Nicolas Mailhot wrote : > >> At least ssh rate-limiting should be in the default firewall install. > > > > That'll just delay the problem. > > For casual brute-force attacks it will solve the problem, but it's true > firewall-level blacklisting is prone to DOSing (as opposed to pam-level > blacklisting that knows about "users") If you want to "protect" your ssh access, this is a slick solution I really like. A pure iptables based port knocking! Example : -A INPUT -j SSH-KNOCK -A SSH-KNOCK -p tcp -m state --state NEW -m tcp --dport 22 -m recent --rcheck --name SSH1 --rsource -j ACCEPT -A SSH-KNOCK -p tcp -m state --state NEW -m tcp -m recent --remove --name SSH1 --rsource -j DROP -A SSH-KNOCK -p tcp -m state --state NEW -m tcp --dport 5678 -m recent --rcheck --name SSH0 --rsource -j SSH-INPUT -A SSH-KNOCK -p tcp -m state --state NEW -m tcp -m recent --remove --name SSH0 --rsource -j DROP -A SSH-KNOCK -p tcp -m state --state NEW -m tcp --dport 1234 -m recent --set --name SSH0 --rsource -j DROP -A SSH-INPUT -m recent --set --name SSH1 --rsource -j DROP Simply telnet to port 1234, stop it, telnet to 5678, stop it, and you can ssh in from your local IP address ("recent" is amazing!). Once you're done, telnet to any closed port other than 5678 and you won't be able to go in anymore, but your established connections won't be closed as long as you've set an ESTABLISHED state to ACCEPT somewhere above. You can also whitelist some networks to your ssh port before this trick, just in case. Note that you also need to set DROP as your INPUT policy. I'm *NOT* saying I want this by default in Fedora, I don't. I'm just suggesting this as a real world working solution for those who currently use blacklists, denyhosts, pam modules etc. to protect themselves against brute force attacks. Nothing will ever beat a non answering ssh port to get attackers to move on ;-) (Sorry for this OT post, but I thought it might be useful) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2911.6.5.fc6 Load : 1.18 1.10 0.89 From nphilipp at redhat.com Tue Mar 20 11:08:58 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 20 Mar 2007 12:08:58 +0100 Subject: [BUG] Fast User Switching In-Reply-To: <6e24a8e80703190837l73b17f01n5ebec43b28832c9b@mail.gmail.com> References: <6e24a8e80703190705g119fad6dt76713ea6481bdc98@mail.gmail.com> <1174314025.30079.9.camel@zod.rchland.ibm.com> <6e24a8e80703190729u6aad1fcdu6c98a5f6fda67385@mail.gmail.com> <1174314759.30079.12.camel@zod.rchland.ibm.com> <6e24a8e80703190749y45460fa7x2874a6c94f127698@mail.gmail.com> <1174317228.10900.8.camel@localhost.localdomain> <6e24a8e80703190837l73b17f01n5ebec43b28832c9b@mail.gmail.com> Message-ID: <1174388938.9873.11.camel@gibraltar.stuttgart.redhat.com> On Mon, 2007-03-19 at 16:37 +0100, Mark wrote: > than it must have happened by accident. it`s open again. > i didn`t even know that i could close a bug ^_^ You can always close bugs you opened yourself. It helps if you differentiate between the following: - policy stuff: there is policy you don't like, you file that as a bug, it may get closed NOTABUG, in that case this could be discussed on the list. And still be shot down in the end ;-). - bugs: something doesn't work as it should (which is again defined by policy ;-). File a bug in bugzilla, in the case of particularly nasty bugs you might mention it here or on fedora-test so others may be warned (people can always query bugzilla if they run into non-fatal bugs). The worst that should happen to a real bug is "WONTFIX" which means "yes this is a bug, but I can't fix it for whatever reason". Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nphilipp at redhat.com Tue Mar 20 11:15:08 2007 From: nphilipp at redhat.com (Nils Philippsen) Date: Tue, 20 Mar 2007 12:15:08 +0100 Subject: OCFS2 and tools in FC. In-Reply-To: <1174378192.13906.12.camel@localhost.localdomain> References: <1174378192.13906.12.camel@localhost.localdomain> Message-ID: <1174389309.9873.15.camel@gibraltar.stuttgart.redhat.com> Hi, On Tue, 2007-03-20 at 17:09 +0900, Naoki wrote: > OCFS2 made it into the mainstream kernel a while ago. But while Debian > and SUSE ship OCFS2 tools, FC does not. > > Is this simply a case of nobody submitting them, or is there a license > issue (nah, it's GPL) ? perhaps you need somebody with a bit of knowledge about and willing to support that file system? > If the answer is the former then is there time to add them before FC7 ? Nope, today is feature freeze. > It's the only main line clustered file system and I'd like to run it > through the gauntlet with my favourite OS. Not true, GFS2 is in the kernel as well: http://kernelnewbies.org/Linux_2_6_19 Its tools are included in Fedora. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From naoki at valuecommerce.com Tue Mar 20 12:13:12 2007 From: naoki at valuecommerce.com (Naoki) Date: Tue, 20 Mar 2007 21:13:12 +0900 Subject: OCFS2 and tools in FC. In-Reply-To: <1174389309.9873.15.camel@gibraltar.stuttgart.redhat.com> References: <1174378192.13906.12.camel@localhost.localdomain> <1174389309.9873.15.camel@gibraltar.stuttgart.redhat.com> Message-ID: <45FFCFD8.3010601@valuecommerce.com> > On Tue, 2007-03-20 at 17:09 +0900, Naoki wrote: > >> OCFS2 made it into the mainstream kernel a while ago. But while Debian >> and SUSE ship OCFS2 tools, FC does not. >> >> Is this simply a case of nobody submitting them, or is there a license >> issue (nah, it's GPL) ? >> > > perhaps you need somebody with a bit of knowledge about and willing to > support that file system? I can't see that as being an issue. On the most basic level it is as any other file system, you format and mount. Other than that support would be on the ocfs or fedora mailing lists as usual. >> If the answer is the former then is there time to add them before FC7 ? >> > > Nope, today is feature freeze. > Which ends on the 29th. That raises a question though, as it would be essentially the same as adding something to 'extras', we're not talking about a major (or minor) feature change or an API alteration. Just adding some open tools for an already existing feature. If this was the FC6 cycle it could probably just slip into extras unnoticed, so how would it work under the merge? Add it to the extras wish list or just submit it? >> It's the only main line clustered file system and I'd like to run it >> through the gauntlet with my favourite OS. >> > > Not true, GFS2 is in the kernel as well: > > http://kernelnewbies.org/Linux_2_6_19 > > Its tools are included in Fedora. > I stand corrected! It "was" the only one in the kernel. But I'd still not rather use GFS and have been waiting for OCFS2 tools to appear in FC for over a year. Yes I know one can download the tools from the oracle site but when we ship tools for most (all?) other file systems (e2fsprogs & ntfsprogs as expected, xfsprogs, hfsplus-tools, plus fuse and other randomness) it hardly seems logical to just leave it out. If it isn't already I would expect standard policy would be to ship the utilities package for any standard, enabled, file system ? From pertusus at free.fr Tue Mar 20 12:13:38 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 20 Mar 2007 13:13:38 +0100 Subject: OCFS2 and tools in FC. In-Reply-To: <45FFCFD8.3010601@valuecommerce.com> References: <1174378192.13906.12.camel@localhost.localdomain> <1174389309.9873.15.camel@gibraltar.stuttgart.redhat.com> <45FFCFD8.3010601@valuecommerce.com> Message-ID: <20070320121338.GB2900@free.fr> On Tue, Mar 20, 2007 at 09:13:12PM +0900, Naoki wrote: > unnoticed, so how would it work under the merge? Add it to the extras > wish list or just submit it? Just submit it is the best, if you are willing to maintain it. If you are not already a fedora contributor, please have a look at http://fedoraproject.org/wiki/PackageMaintainers http://fedoraproject.org/wiki/PackageMaintainers/Join -- Pat From naoki at valuecommerce.com Tue Mar 20 12:26:12 2007 From: naoki at valuecommerce.com (Naoki) Date: Tue, 20 Mar 2007 21:26:12 +0900 Subject: OCFS2 and tools in FC. In-Reply-To: <20070320121338.GB2900@free.fr> References: <1174378192.13906.12.camel@localhost.localdomain> <1174389309.9873.15.camel@gibraltar.stuttgart.redhat.com> <45FFCFD8.3010601@valuecommerce.com> <20070320121338.GB2900@free.fr> Message-ID: <45FFD2E4.1040304@valuecommerce.com> Patrice Dumas wrote: > On Tue, Mar 20, 2007 at 09:13:12PM +0900, Naoki wrote: > > >> unnoticed, so how would it work under the merge? Add it to the extras >> wish list or just submit it? >> > > Just submit it is the best, if you are willing to maintain it. If you > are not already a fedora contributor, please have a look at > > http://fedoraproject.org/wiki/PackageMaintainers > http://fedoraproject.org/wiki/PackageMaintainers/Join > Mucho Gracias! From ssorce at redhat.com Tue Mar 20 12:28:51 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 20 Mar 2007 08:28:51 -0400 Subject: [RFC] Filesystem-local databases in mlocate In-Reply-To: <45FF18F4.5090308@volny.cz> References: <45FA1A1A.9060201@volny.cz> <1174284641.16983.8.camel@willson> <45FF18F4.5090308@volny.cz> Message-ID: <1174393731.16983.39.camel@willson> On Tue, 2007-03-20 at 00:12 +0100, Miloslav Trmac wrote: > Simo Sorce napsal(a): > >> - NFS is automatically excluded by clients, so updatedb on clients > >> does not walk the filesystem. > >> - On the server: > >> Add /srv/home to /etc/sysconfig/mlocate. If /srv/home is not a > >> separate mount point, add LOCATE_PATH=:/srv/home/.mlocate/mlocate.db > >> to the global environment. > > I am deeply concerned about the security implications of this idea. > > You are basically making it possible for everyone to get access to the > > complete remote FS layout ??? > No, only the layout of the specific NFS filesystem that can be mounted > from the client. This is what I am talking about, the whole remote (exported) FS. > mlocate.db would be readable only by the slocate user, > like the current /var/lib/mlocate/mlocate.db. You are thinking in 1990 terms (NFSv3), how do you authenticate the slocate user on NFSv4 and CIFS? > Therefore, if a client can fake the UID and read the whole mlocate.db, > it can fake the UID and traverse the whole NFS filesystem just the same. You are thinking in 1990 terms (NFSv3), in 2007 we have CIFS and NFSv4 that authenticate per user, such a file would be a considerable security breach, on these file systems. Simo. From ssorce at redhat.com Tue Mar 20 12:36:36 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 20 Mar 2007 08:36:36 -0400 Subject: Filesystem-local databases in mlocate In-Reply-To: <20070320095629.GE14567@neu.nirvana> References: <45FA1A1A.9060201@volny.cz> <20070316105123.GC24022@neu.nirvana> <45FF13E7.1020309@volny.cz> <20070319234411.GB27468@neu.nirvana> <45FF21C2.6080604@volny.cz> <20070320095629.GE14567@neu.nirvana> Message-ID: <1174394196.16983.44.camel@willson> On Tue, 2007-03-20 at 10:56 +0100, Axel Thimm wrote: > On Tue, Mar 20, 2007 at 12:50:26AM +0100, Miloslav Trmac wrote: > > Axel Thimm napsal(a): > > > On Mon, Mar 19, 2007 at 11:51:19PM +0100, Miloslav Trmac wrote: > > >> Hello, > > >> Axel Thimm napsal(a): > > >>>> * locate(1)'s default database is not just /var/lib/mlocate/mlocate.db; > > >>>> mlocate also checks each mounted filesystem for a .mlocate/mlocate.db > > >>>> file, owned by root or the invoking user, and not writable by anyone > > >>>> but the owner. Such files are automatically added to the database > > >>>> path. > > >>> locate should also include .mlocate/mlocate.db a previous updatedb has > > >>> found and skipped. E.g. if updatedb detects a .mlocate/mlocate.db in a > > >>> folder in its path it skips it and registers it for locate to use. > > >> I can't think of a reason why they would be necessary. > > > Consider for example a single volume nfs server exporting /home. So > > > you want to have updatedb create a subdirectory-local db in /home, so > > > it can be used on remote clients. > > But on the client, where locate runs, /home/foo would be a separate > > filesystem. > > Yes, but updatedb (and locate) runs also on the server. > > > As for updatedb, > > > And instead of having to configure it in /etc/sysconfig it is easier > > > to keep the metainformation of about where such .mlocate/mlocate.db > > > should be maintained in the fs itself simply by creating the folder > > > .mlocate. > > wouldn't it be even more practical to support > > FS_DB_GLOB=/srv/home/* > > in /etc/sysconfig/mlocate ? > > It's better not to have any knowledge under /etc of where special > .mlocate/mlocate.db are injected on the (local) filesystem. Consider > the (local) volume in question to be mounted from a SAN device, maybe > even in a cluster active/passive setup. Or consider moving a data disk > from one system to another. > > It's better to try and keep the metainformation non-global (e.g. out > of /etc) and self-describing, so it is rather transparent for the > admin. Otherwise he needs to cater for any change of host <-> storage > mapping in mlocate as well. The more I think of it, the more I think .mlocate directories and files are a very BAD idea. Security is not enforceable this way across machines boundaries, so anything that shares the filesystem layout cross machine IS a problem. The only way to solve the problem (and also avoid the uglyness of having writable files all over the places, but keep them in /var/cache where they should stay) is to have a network service that use authentication mechanisms _per user_ (kerberized), and returns back only the information such user is entitled to see. Simo. From email.ahmedkamal at googlemail.com Tue Mar 20 12:49:30 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Tue, 20 Mar 2007 14:49:30 +0200 Subject: Improvement to rescue mode? In-Reply-To: References: Message-ID: <3da3b5b40703200549v5e0bc6adxe4c40417433aac2d@mail.gmail.com> Why don't you install grub on the broken system and boot it? On 3/20/07, Neal Becker wrote: > > I have found on a number of occasions that I wanted to use a rescue cd to > boot an installation, where the grub install was broken. It would be > really helpful if the fedora rescue mode would allow this. > > -- > 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 Axel.Thimm at ATrpms.net Tue Mar 20 12:55:54 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 13:55:54 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <1174393731.16983.39.camel@willson> References: <45FA1A1A.9060201@volny.cz> <1174284641.16983.8.camel@willson> <45FF18F4.5090308@volny.cz> <1174393731.16983.39.camel@willson> Message-ID: <20070320125554.GK14567@neu.nirvana> On Tue, Mar 20, 2007 at 08:28:51AM -0400, Simo Sorce wrote: > On Tue, 2007-03-20 at 00:12 +0100, Miloslav Trmac wrote: > > Simo Sorce napsal(a): > > >> - NFS is automatically excluded by clients, so updatedb on clients > > >> does not walk the filesystem. > > >> - On the server: > > >> Add /srv/home to /etc/sysconfig/mlocate. If /srv/home is not a > > >> separate mount point, add LOCATE_PATH=:/srv/home/.mlocate/mlocate.db > > >> to the global environment. > > > I am deeply concerned about the security implications of this idea. > > > You are basically making it possible for everyone to get access to the > > > complete remote FS layout ??? > > No, only the layout of the specific NFS filesystem that can be mounted > > from the client. > > This is what I am talking about, the whole remote (exported) FS. > > > mlocate.db would be readable only by the slocate user, > > like the current /var/lib/mlocate/mlocate.db. > > You are thinking in 1990 terms (NFSv3), how do you authenticate the > slocate user on NFSv4 and CIFS? > > > Therefore, if a client can fake the UID and read the whole mlocate.db, > > it can fake the UID and traverse the whole NFS filesystem just the same. > > You are thinking in 1990 terms (NFSv3), in 2007 we have CIFS and NFSv4 > that authenticate per user, such a file would be a considerable security > breach, on these file systems. Why, on these filesystems (assuming the proper authentication mechanism is in place) you cannot fake the uid anymore, so you have even less access rights to any root owned file. It's the elder, fakable protocols that need attention. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Tue Mar 20 12:56:14 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 20 Mar 2007 08:56:14 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <20070320085133.GA3092@dudweiler.stuttgart.redhat.com> Message-ID: <1174395374.3115.8.camel@aglarond.local> On Tue, 2007-03-20 at 10:42 +0100, Gianluca Sforna wrote: > On 3/20/07, Florian La Roche wrote: > > It is also really wrong to select exim instead of the default sendmail. > > I am all for improving exim and checking if it should be default in the > > future for Fedora, but changing this from a default install to the > > Live-CD is not very good. > > IIRC exim landed on the LiveCD mostly by chance, being the package > with the shorter name satisfying the /usr/sbin/sendmail require... And with the test3 live CD using a kickstart config and the groups defined in comps, we'll end up with sendmail instead as that's what's marked as default in the comps file. Jeremy From Axel.Thimm at ATrpms.net Tue Mar 20 13:02:29 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 14:02:29 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <1174394196.16983.44.camel@willson> References: <45FA1A1A.9060201@volny.cz> <20070316105123.GC24022@neu.nirvana> <45FF13E7.1020309@volny.cz> <20070319234411.GB27468@neu.nirvana> <45FF21C2.6080604@volny.cz> <20070320095629.GE14567@neu.nirvana> <1174394196.16983.44.camel@willson> Message-ID: <20070320130229.GL14567@neu.nirvana> On Tue, Mar 20, 2007 at 08:36:36AM -0400, Simo Sorce wrote: > On Tue, 2007-03-20 at 10:56 +0100, Axel Thimm wrote: > > On Tue, Mar 20, 2007 at 12:50:26AM +0100, Miloslav Trmac wrote: > > > Axel Thimm napsal(a): > > > > On Mon, Mar 19, 2007 at 11:51:19PM +0100, Miloslav Trmac wrote: > > > >> Hello, > > > >> Axel Thimm napsal(a): > > > >>>> * locate(1)'s default database is not just /var/lib/mlocate/mlocate.db; > > > >>>> mlocate also checks each mounted filesystem for a .mlocate/mlocate.db > > > >>>> file, owned by root or the invoking user, and not writable by anyone > > > >>>> but the owner. Such files are automatically added to the database > > > >>>> path. > > > >>> locate should also include .mlocate/mlocate.db a previous updatedb has > > > >>> found and skipped. E.g. if updatedb detects a .mlocate/mlocate.db in a > > > >>> folder in its path it skips it and registers it for locate to use. > > > >> I can't think of a reason why they would be necessary. > > > > Consider for example a single volume nfs server exporting /home. So > > > > you want to have updatedb create a subdirectory-local db in /home, so > > > > it can be used on remote clients. > > > But on the client, where locate runs, /home/foo would be a separate > > > filesystem. > > > > Yes, but updatedb (and locate) runs also on the server. > > > > > As for updatedb, > > > > And instead of having to configure it in /etc/sysconfig it is easier > > > > to keep the metainformation of about where such .mlocate/mlocate.db > > > > should be maintained in the fs itself simply by creating the folder > > > > .mlocate. > > > wouldn't it be even more practical to support > > > FS_DB_GLOB=/srv/home/* > > > in /etc/sysconfig/mlocate ? > > > > It's better not to have any knowledge under /etc of where special > > .mlocate/mlocate.db are injected on the (local) filesystem. Consider > > the (local) volume in question to be mounted from a SAN device, maybe > > even in a cluster active/passive setup. Or consider moving a data disk > > from one system to another. > > > > It's better to try and keep the metainformation non-global (e.g. out > > of /etc) and self-describing, so it is rather transparent for the > > admin. Otherwise he needs to cater for any change of host <-> storage > > mapping in mlocate as well. > > The more I think of it, the more I think .mlocate directories and > files are a very BAD idea. Security is not enforceable this way > across machines boundaries, so anything that shares the filesystem > layout cross machine IS a problem. The argument here is more about where to keep information about what is to be subindexed, not whether it makes security-wise sense to do so. Even so if the the .mlocate bits are only readable by the remote client if the remote client can traverse anyway through the filesystem, then there is no security leak anywhere. This means that either the remote filesystem is root-mounted w/o root_suqashing or a per-user authetication is put in place. In the former case only the non-suqashed root get's to read it (and is allowed to traverse the fs anyway since he's unsquashed) and in the latter you have set up per user trust (by nfs/krb or cifs) and setup any finer-grained security model suiting your site's needs. The default setup should asume the worst, e.g. have the indexes owned by root:root, so no remote fs old or new will be able to access the data if the admin of the server doesn't allow it. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ssorce at redhat.com Tue Mar 20 13:22:01 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 20 Mar 2007 09:22:01 -0400 Subject: Filesystem-local databases in mlocate In-Reply-To: <20070320130229.GL14567@neu.nirvana> References: <45FA1A1A.9060201@volny.cz> <20070316105123.GC24022@neu.nirvana> <45FF13E7.1020309@volny.cz> <20070319234411.GB27468@neu.nirvana> <45FF21C2.6080604@volny.cz> <20070320095629.GE14567@neu.nirvana> <1174394196.16983.44.camel@willson> <20070320130229.GL14567@neu.nirvana> Message-ID: <1174396921.16983.49.camel@willson> On Tue, 2007-03-20 at 14:02 +0100, Axel Thimm wrote: > The default setup should asume the worst, e.g. have the indexes owned > by root:root, so no remote fs old or new will be able to access the > data if the admin of the server doesn't allow it. Which kind of defeats the whole thing of having per FS locatedbs ... and is a temptation for admins to change it to nobody:nobody and give away info easily without fully recognizing the security problem. However, I see the value for those 0.01% users using clustered file systems. So, if we stop talking about net FSs and instead we talk about SANs and GFS/GPFS/Lustre/OCFS2/whatever, I think it makes more sense :) Simo. From jwilson at redhat.com Tue Mar 20 13:25:53 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Tue, 20 Mar 2007 09:25:53 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <20070320110821.0c5e92c6@python3.es.egwn.lan> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FF4457.4080309@brentnorris.net> <45FF46BB.2000701@redhat.com> <20070320110821.0c5e92c6@python3.es.egwn.lan> Message-ID: <45FFE0E1.10603@redhat.com> Matthias Saou wrote: > Jarod Wilson wrote : > >>> Perhaps a new third result for initscripts. Instead of just [ok] or >>> [Failed], maybe a new one like [Unneeded] or [N/A] or something. >> We already have a 3rd result, 'warning', but... > > We also have that yellow [PASSED] :-) > I have no idea what the initial idea behind it was. Maybe notting knows. Ah yes, seen that one once or twice too, forgot about that... >>> Might help people realize that these things are running instead of >>> giving them the impression that they are running and using system >>> resources. >> ...Meh. I prefer what we do w/cpuspeed right now. If the support isn't >> there, we silently exit. We never even print out a "starting cpuspeed:" >> or any status. > > This can be a little confusing from a user perspective : "I enabled the > service, so why doesn't it start when I boot?". But scripts wanting to > do this could easily put useful information into /var/log/messages. The cpuspeed case is a bit interesting. We've decided that we're going to start the cpuspeed initscript on every system we possibly can, doing our part to help conserve energy, make users lives easier w/o them having to do anything, etc. At the same time, we don't want a myriad of support calls/bugzillas opened because we alerted the user that we tried to start cpuspeed and failed. We've got logging support in the initscript, so we could certainly log failed startup attempts. I'd just want to word any log message *very* carefully... (Open to suggestions) > A possible solution for "on demand" services would be : > - If the service is disabled, never run it. > - If the service is enabled : > - If the relevant hardware is present, start the service > - If the relevant hardware isn't present, skip starting the service Essentially what cpuspeed does now. > Then once all the hooks are present to be able to start/stop services > upon hot (un)plugging devices, start/stop the service when detecting > the device's addition or removal, if the service is enabled. > > That way we can keep useful services "enabled" by default, although > they'll only actually run if/when the relevant devices are detected. > And we still leave experienced users a way to completely disable > services they wouldn't want running for whatever reason. Would certainly be very cool for stuff like bluetooth support. Not relevant in the cpuspeed case (not saying that you were saying it was, just making sure we're making this distinction). Well, I guess it *could* be relevant if you wanted frequency scaling to start up automagically after you manually load up a module, such as acpi-cpufreq, and the necessary support is suddenly there, but that sounds like a suboptimal way to do things in this particular case... -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From Axel.Thimm at ATrpms.net Tue Mar 20 13:38:59 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 14:38:59 +0100 Subject: Filesystem-local databases in mlocate In-Reply-To: <1174396921.16983.49.camel@willson> References: <45FA1A1A.9060201@volny.cz> <20070316105123.GC24022@neu.nirvana> <45FF13E7.1020309@volny.cz> <20070319234411.GB27468@neu.nirvana> <45FF21C2.6080604@volny.cz> <20070320095629.GE14567@neu.nirvana> <1174394196.16983.44.camel@willson> <20070320130229.GL14567@neu.nirvana> <1174396921.16983.49.camel@willson> Message-ID: <20070320133859.GP14567@neu.nirvana> On Tue, Mar 20, 2007 at 09:22:01AM -0400, Simo Sorce wrote: > On Tue, 2007-03-20 at 14:02 +0100, Axel Thimm wrote: > > > The default setup should asume the worst, e.g. have the indexes owned > > by root:root, so no remote fs old or new will be able to access the > > data if the admin of the server doesn't allow it. > > Which kind of defeats the whole thing of having per FS locatedbs ... and > is a temptation for admins to change it to nobody:nobody and give away > info easily without fully recognizing the security problem. The same admins would probably write the root password on their door, so they don't forget ;) > However, I see the value for those 0.01% users using clustered file > systems. So, if we stop talking about net FSs and instead we talk about > SANs and GFS/GPFS/Lustre/OCFS2/whatever, I think it makes more sense :) Cluster users will certainly benefit, as well as such juggling data storage around either physical or by (re)assigning luns on the raid, and such using NFS for the homes on trusted clients as well. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Mar 20 13:52:47 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 20 Mar 2007 14:52:47 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FFE0E1.10603@redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FF4457.4080309@brentnorris.net> <45FF46BB.2000701@redhat.com> <20070320110821.0c5e92c6@python3.es.egwn.lan> <45FFE0E1.10603@redhat.com> Message-ID: <20070320145247.722b4000@python3.es.egwn.lan> Jarod Wilson wrote : > > A possible solution for "on demand" services would be : > > - If the service is disabled, never run it. > > - If the service is enabled : > > - If the relevant hardware is present, start the service > > - If the relevant hardware isn't present, skip starting the service > > Essentially what cpuspeed does now. Yup. It's doing the right thing, alright! :-) > > Then once all the hooks are present to be able to start/stop services > > upon hot (un)plugging devices, start/stop the service when detecting > > the device's addition or removal, if the service is enabled. > > > > That way we can keep useful services "enabled" by default, although > > they'll only actually run if/when the relevant devices are detected. > > And we still leave experienced users a way to completely disable > > services they wouldn't want running for whatever reason. > > Would certainly be very cool for stuff like bluetooth support. Not > relevant in the cpuspeed case (not saying that you were saying it was, > just making sure we're making this distinction). Well, I guess it > *could* be relevant if you wanted frequency scaling to start up > automagically after you manually load up a module, such as acpi-cpufreq, > and the necessary support is suddenly there, but that sounds like a > suboptimal way to do things in this particular case... I was definitely thinking about things like bluetooth, smartcards etc. which aren't useful for many users, but need to "just work" for all the others. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2911.6.5.fc6 Load : 0.31 0.34 0.36 From ajackson at redhat.com Tue Mar 20 13:34:45 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 20 Mar 2007 09:34:45 -0400 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174381904.3528.175.camel@home.alexander.bostrom.net> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> Message-ID: <1174397685.10900.15.camel@localhost.localdomain> On Tue, 2007-03-20 at 10:11 +0100, Alexander Bostr?m wrote: > m?n 2007-03-19 klockan 15:21 +0530 skrev Rahul Sundaram: > > Hi > > > > Been fiddling with a installation of Fedora 7 Test 2 from the Live CD > > and it still enables way too may daemons by default. > > Oh, is the SSH server still enabled by default (if you install the > openssh-server package)? > > Because if it is, pretty pretty please disable it! > > People don't use good passwords and they don't realize that their > password can be used remotely. Giving millions of people an sshd they > don't know or care about is a recipe for zombie machines and bad > security reputation. So I think you mean "disable password auth by default". - ajax From ajackson at redhat.com Tue Mar 20 13:37:06 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 20 Mar 2007 09:37:06 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <20070319231252.GC12006@redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FE8C76.5030405@fedoraproject.org> <45FEC3C2.2030500@andrei.myip.org> <1174327574.14986.34.camel@erebor.boston.redhat.com> <20070319231252.GC12006@redhat.com> Message-ID: <1174397826.10900.18.camel@localhost.localdomain> On Mon, 2007-03-19 at 19:12 -0400, Dave Jones wrote: > On Mon, Mar 19, 2007 at 02:06:13PM -0400, Jeremy Katz wrote: > > > The real thing here is that more of the daemons which are currently > > started via initscripts need to be started when the hardware is inserted > > and stopped when removed. > > I'm sure I heard mumblings that this feature requires dbus changes > that won't land until post F7. Service activation on the system bus is apparently scheduled for some point in dbus' future. IIRC the patch is written and works, just isn't merged. - ajax From markg85 at gmail.com Tue Mar 20 13:56:30 2007 From: markg85 at gmail.com (Mark) Date: Tue, 20 Mar 2007 14:56:30 +0100 Subject: [BUG] Fast User Switching In-Reply-To: <1174388938.9873.11.camel@gibraltar.stuttgart.redhat.com> References: <6e24a8e80703190705g119fad6dt76713ea6481bdc98@mail.gmail.com> <1174314025.30079.9.camel@zod.rchland.ibm.com> <6e24a8e80703190729u6aad1fcdu6c98a5f6fda67385@mail.gmail.com> <1174314759.30079.12.camel@zod.rchland.ibm.com> <6e24a8e80703190749y45460fa7x2874a6c94f127698@mail.gmail.com> <1174317228.10900.8.camel@localhost.localdomain> <6e24a8e80703190837l73b17f01n5ebec43b28832c9b@mail.gmail.com> <1174388938.9873.11.camel@gibraltar.stuttgart.redhat.com> Message-ID: <6e24a8e80703200656i5ab35691gf313b26354e8e364@mail.gmail.com> Thanx for clearing that up. so i can open up a topic here in this list about a policy.. in that case i probably will do that for the mountable stuff. and can we now get back on: [BUG] Fast User Switching Thanx 2007/3/20, Nils Philippsen : > On Mon, 2007-03-19 at 16:37 +0100, Mark wrote: > > than it must have happened by accident. it`s open again. > > i didn`t even know that i could close a bug ^_^ > > You can always close bugs you opened yourself. It helps if you > differentiate between the following: > > - policy stuff: there is policy you don't like, you file that as a bug, > it may get closed NOTABUG, in that case this could be discussed on the > list. And still be shot down in the end ;-). > > - bugs: something doesn't work as it should (which is again defined by > policy ;-). File a bug in bugzilla, in the case of particularly nasty > bugs you might mention it here or on fedora-test so others may be warned > (people can always query bugzilla if they run into non-fatal bugs). The > worst that should happen to a real bug is "WONTFIX" which means "yes > this is a bug, but I can't fix it for whatever reason". > > Nils > -- > Nils Philippsen / Red Hat / nphilipp at redhat.com > "Those who would give up Essential Liberty to purchase a little Temporary > Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759 > PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From jreiser at BitWagon.com Tue Mar 20 14:10:58 2007 From: jreiser at BitWagon.com (John Reiser) Date: Tue, 20 Mar 2007 07:10:58 -0700 Subject: Improvement to rescue mode? In-Reply-To: <3da3b5b40703200549v5e0bc6adxe4c40417433aac2d@mail.gmail.com> References: <3da3b5b40703200549v5e0bc6adxe4c40417433aac2d@mail.gmail.com> Message-ID: <45FFEB72.40002@BitWagon.com> >> I have found on a number of occasions that I wanted to use a rescue cd to >> boot an installation, where the grub install was broken. It would be >> really helpful if the fedora rescue mode would allow this. > Why don't you install grub on the broken system and boot it? Because rescue mode cannot install grub via grub-install; reported as: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198064 The mechanism that grub-install uses to identify the "hardware" is incompatible with the "virtualization" provided by chroot and rescue mode. -- From notting at redhat.com Tue Mar 20 15:06:35 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Mar 2007 11:06:35 -0400 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <20070320110821.0c5e92c6@python3.es.egwn.lan> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FF4457.4080309@brentnorris.net> <45FF46BB.2000701@redhat.com> <20070320110821.0c5e92c6@python3.es.egwn.lan> Message-ID: <20070320150635.GC11089@nostromo.devel.redhat.com> Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > We already have a 3rd result, 'warning', but... > > We also have that yellow [PASSED] :-) > I have no idea what the initial idea behind it was. Maybe notting knows. fsck - the fs wasn't clean, but it was cleaned up. > - If the service is enabled : > - If the relevant hardware is present, start the service > - If the relevant hardware isn't present, skip starting the service Isn't this essentially what we do now in the individual scripts? Bill From notting at redhat.com Tue Mar 20 15:08:28 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 20 Mar 2007 11:08:28 -0400 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174384001.3528.182.camel@home.alexander.bostrom.net> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <24903.192.54.193.51.1174382665.squirrel@rousalka.dyndns.org> <1174384001.3528.182.camel@home.alexander.bostrom.net> Message-ID: <20070320150828.GD11089@nostromo.devel.redhat.com> Alexander Bostr?m (abo at kth.se) said: > I think it can be off by default. To use it securely you should log in > locally and look at or replace the host key anyway, so you might as well > enable it at the same time. (But I guess people use SSH for > better-than-nothing security, rather than checking host keys.) Not everything has local console access - although, you could require such instances to access via the serial console, or do various things with kickstart. Bill From miles.lane at gmail.com Tue Mar 20 15:28:03 2007 From: miles.lane at gmail.com (Miles Lane) Date: Tue, 20 Mar 2007 15:28:03 +0000 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <45FFE0E1.10603@redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FF4457.4080309@brentnorris.net> <45FF46BB.2000701@redhat.com> <20070320110821.0c5e92c6@python3.es.egwn.lan> <45FFE0E1.10603@redhat.com> Message-ID: On 3/20/07, Jarod Wilson wrote: > The cpuspeed case is a bit interesting. We've decided that we're going > to start the cpuspeed initscript on every system we possibly can, doing > our part to help conserve energy, make users lives easier w/o them > having to do anything, etc. Speaking of conserving energy, is there any plan to enable Suspend from a gdm login display? I notice that closing the lid of a laptop won't suspend the machine until I have logged into Gnome, which has led to dead batteries, wasted energy and potential heat overload in stowed laptops. Miles From wtogami at redhat.com Tue Mar 20 15:35:08 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Mar 2007 11:35:08 -0400 Subject: OCFS2 and tools in FC. In-Reply-To: <1174378192.13906.12.camel@localhost.localdomain> References: <1174378192.13906.12.camel@localhost.localdomain> Message-ID: <45FFFF2C.5000405@redhat.com> Naoki wrote: > Hello all, > > OCFS2 made it into the mainstream kernel a while ago. But while Debian > and SUSE ship OCFS2 tools, FC does not. > > Is this simply a case of nobody submitting them, or is there a license > issue (nah, it's GPL) ? > > If the answer is the former then is there time to add them before FC7 ? > > It's the only main line clustered file system and I'd like to run it > through the gauntlet with my favourite OS. > Please submit it as a Fedora Extras package review. It is too late to get it on the standard Fedora 7 media, but it will at least be easy to install from the repo. Warren From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Tue Mar 20 16:15:41 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Tue, 20 Mar 2007 17:15:41 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <20070320150635.GC11089@nostromo.devel.redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FF4457.4080309@brentnorris.net> <45FF46BB.2000701@redhat.com> <20070320110821.0c5e92c6@python3.es.egwn.lan> <20070320150635.GC11089@nostromo.devel.redhat.com> Message-ID: <20070320171541.024abc4c@python3.es.egwn.lan> Bill Nottingham wrote : > Matthias Saou (thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net) said: > > > We already have a 3rd result, 'warning', but... > > > > We also have that yellow [PASSED] :-) > > I have no idea what the initial idea behind it was. Maybe notting knows. > > fsck - the fs wasn't clean, but it was cleaned up. Oh, I don't recall having ever seen it :-) > > - If the service is enabled : > > - If the relevant hardware is present, start the service > > - If the relevant hardware isn't present, skip starting the service > > Isn't this essentially what we do now in the individual scripts? For some fixed hardware, yes, but not for hot pluggable hardware like bluetooth, smartcard etc. where the daemons are started anyway in the eventuality that the hardware gets added after the boot. This is the best that can be done for now, but does lead to useless daemons running, taking up boot time and system memory. I'm really looking forward for the day we can start services only when the hardware they need gets plugged in. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2911.6.5.fc6 Load : 0.38 0.39 0.45 From khc at pm.waw.pl Tue Mar 20 17:46:49 2007 From: khc at pm.waw.pl (Krzysztof Halasa) Date: Tue, 20 Mar 2007 18:46:49 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174365408.4531.35.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Tue, 20 Mar 2007 05:36:48 +0100") References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> <1174365408.4531.35.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > => < ~500MB per "uptime" for users booting for "a couple of hours a > day". > > In practice, real world bandwidth is below this. Still more than enough for a weekly update, right? Of course, using delta would make things much faster and (if working correctly) would be appreciated by both clients and mirrors. > If you update an existing Fedora installation once a week, you'll > observe one update to typically be in the order of "some > 100MBs" (occasionally several 100MBs). Quite possible. > Now change to some X000 DSL - You'll probably very soon notice what I > said above. I have Fedora boxes connected with XX Mbps Ethernet, but since there is no problem with my home 512 kbps DSL (previously 128 and 256), there is none with these on Ethernet either. > Or change to ISDN/modem ... (ca. 1/10th of the bandwidth you currently > have) - Any major update is becoming a killer, in such situations. ISDN/modem, i.e., dialup connection with per minute fee? Sure, that's different story, the updates are just too expensive on that. BTW: I've been using such dialups for years, before DSL and similar cheaper services became available. The key word here is "price per minute", not "speed". -- Krzysztof Halasa From sundaram at fedoraproject.org Tue Mar 20 18:11:44 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 20 Mar 2007 23:41:44 +0530 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FF4457.4080309@brentnorris.net> <45FF46BB.2000701@redhat.com> <20070320110821.0c5e92c6@python3.es.egwn.lan> <45FFE0E1.10603@redhat.com> Message-ID: <460023E0.5080102@fedoraproject.org> Miles Lane wrote: > On 3/20/07, Jarod Wilson wrote: >> The cpuspeed case is a bit interesting. We've decided that we're going >> to start the cpuspeed initscript on every system we possibly can, doing >> our part to help conserve energy, make users lives easier w/o them >> having to do anything, etc. > > Speaking of conserving energy, is there any plan to enable Suspend > from a gdm login display? I notice that closing the lid of a laptop > won't suspend the machine until I have logged into Gnome, which has > led to dead batteries, wasted energy and potential heat overload in > stowed laptops. In a earlier part of this thread, David Zuethen said that the plan is that g-p-m will do system wide power management for Fedora 8. Rahul From Axel.Thimm at ATrpms.net Tue Mar 20 18:39:13 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 20 Mar 2007 19:39:13 +0100 Subject: fedora-maintainers vs fedora-devel Message-ID: <20070320183913.GB20185@neu.nirvana> Hi, since it comes up every now and then, I'd like to get the differences clarified, especially since there are ideas to get them united, which if the contents and target groups are too different would be wrong. The way I see it it is like the following: o fedora-devel - concentrates on rawhide and its way to a release - has in-house upstream development discussion - more in-depth Linux mechanics - manages release cycle o fedora-maintainers - concentrates on the packaging community as a whole - More issues about packaging than on upstream development, if any - cares more about current and past releases There is some (IMHO) healthy overlap, but I do think that they differ enough to keep them separated to have each group enjoy a better SNR level. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Tue Mar 20 18:48:49 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Mar 2007 14:48:49 -0400 Subject: fedora-maintainers vs fedora-devel In-Reply-To: <20070320183913.GB20185@neu.nirvana> References: <20070320183913.GB20185@neu.nirvana> Message-ID: <20070320184849.GA18323@jadzia.bu.edu> On Tue, Mar 20, 2007 at 07:39:13PM +0100, Axel Thimm wrote: > since it comes up every now and then, I'd like to get the differences > clarified, especially since there are ideas to get them united, which > if the contents and target groups are too different would be wrong. [...] > o fedora-devel > - concentrates on rawhide and its way to a release > - has in-house upstream development discussion > - more in-depth Linux mechanics > - manages release cycle > o fedora-maintainers > - concentrates on the packaging community as a whole > - More issues about packaging than on upstream development, if any > - cares more about current and past releases I'd kind of like it like this: extended discussion goes on fedora-devel. If you get behind and have to delete it all to catch up, you'll be okay. Things on fedora-maintainers should at least have the subjects skimmed through. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From fedora at leemhuis.info Tue Mar 20 18:55:52 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 20 Mar 2007 19:55:52 +0100 Subject: fedora-maintainers vs fedora-devel In-Reply-To: <20070320183913.GB20185@neu.nirvana> References: <20070320183913.GB20185@neu.nirvana> Message-ID: <46002E38.5020907@leemhuis.info> Axel Thimm schrieb: > > The way I see it it is like the following: > [...] The way it was meant was the following afaics and iirc: * fedora-maintainers -- important discussions between maintainers where we exclude the world (remember: it's a closed list!), no endless flamewars, not that much traffic, so people can easily follow it * fedora-devel -- all the other devel stuff I'd say we failed with what fedora-maintainers was meant for. We have quite some flamewars on fedora-maintainers, we discussed stuff here that we should have discussed in the open on fedora-devel-list, where non-contributors can participate, it's high traffic and we scared people away with it. CU thl From wtogami at redhat.com Tue Mar 20 18:59:11 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Mar 2007 14:59:11 -0400 Subject: fedora-maintainers vs fedora-devel In-Reply-To: <46002E38.5020907@leemhuis.info> References: <20070320183913.GB20185@neu.nirvana> <46002E38.5020907@leemhuis.info> Message-ID: <46002EFF.4010900@redhat.com> Thorsten Leemhuis wrote: > > I'd say we failed with what fedora-maintainers was meant for. We have > quite some flamewars on fedora-maintainers, we discussed stuff here that > we should have discussed in the open on fedora-devel-list, where > non-contributors can participate, it's high traffic and we scared people > away with it. > Perhaps *both* lists are failures in different ways? Warren Togami wtogami at redhat.com From hughsient at gmail.com Tue Mar 20 19:00:45 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 20 Mar 2007 19:00:45 +0000 Subject: Launching g-p-m in gdm, Was: too many deamons by default - F7 test 2 live cd In-Reply-To: <460023E0.5080102@fedoraproject.org> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FF4457.4080309@brentnorris.net> <45FF46BB.2000701@redhat.com> <20070320110821.0c5e92c6@python3.es.egwn.lan> <45FFE0E1.10603@redhat.com> <460023E0.5080102@fedoraproject.org> Message-ID: <1174417245.30528.6.camel@localhost.localdomain> On Tue, 2007-03-20 at 23:41 +0530, Rahul Sundaram wrote: > > In a earlier part of this thread, David Zuethen said that the plan is > that g-p-m will do system wide power management for Fedora 8. Sure, all we have to work out is how we can launch a session instance of g-p-m at the login screen, what to do with any UI (if any) and how to set system preferences. Richard. From jkeating at redhat.com Tue Mar 20 18:45:06 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Mar 2007 14:45:06 -0400 Subject: fedora-maintainers vs fedora-devel In-Reply-To: <20070320183913.GB20185@neu.nirvana> References: <20070320183913.GB20185@neu.nirvana> Message-ID: <200703201445.06284.jkeating@redhat.com> On Tuesday 20 March 2007 14:39:13 Axel Thimm wrote: > The way I see it it is like the following: > > o fedora-devel > ? - concentrates on rawhide and its way to a release > ? - has in-house upstream development discussion > ? - more in-depth Linux mechanics > ? - manages release cycle > > o fedora-maintainers > ? - concentrates on the packaging community as a whole > ? - More issues about packaging than on upstream development, if any > ? - cares more about current and past releases Actually I do all the freeze and collection announcements to fedora-maintainers. They're the people that need to know, and it's largely just noise for fedora-devel. To me, fedora-maintainers are the people doing the work, and a communication place for that. fedora-devel is a combo of people doing work and a larger community consuming the work. -- 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: -------------- next part -------------- -- Fedora-maintainers mailing list Fedora-maintainers at redhat.com https://www.redhat.com/mailman/listinfo/fedora-maintainers From sundaram at fedoraproject.org Tue Mar 20 19:15:56 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Mar 2007 00:45:56 +0530 Subject: KDE-Live-CD: basic cd layout and localizations In-Reply-To: <20070320103804.3c8445f2@localhost.localdomain> References: <20070314011000.5b0cbcb8@localhost.localdomain> <200703182359.32762.ml@deadbabylon.de> <45FDC503.3000508@fedoraproject.org> <200703190038.05132.ml@deadbabylon.de> <45FE00B7.5000603@fedoraproject.org> <20070320103804.3c8445f2@localhost.localdomain> Message-ID: <460032EC.4060106@fedoraproject.org> Sebastian Vahl wrote: > Am Mon, 19 Mar 2007 08:47:11 +0530 > schrieb Rahul Sundaram : > >> It produced a 650 MB KDE ISO image. Booting it on qemu fails with the >> same error message as described in the above bug report. I am not >> sure which udev it downloaded. Are the packages downloaded saved >> anywhere? > > The downloaded rpms in > (default) /var/tmp/livecd-creator/build-*/yum-cache/ would be deleted > in the cleanup. But you can chroot into the iso: > > # mkdir /mnt/iso > # mount -o loop .iso /mnt/iso > # mount -o loop -t squashfs /mnt/iso/squashfs.img /mnt/iso/sysroot > # mount -o loop /mnt/iso/sysroot/os.img /mnt/iso/sysroot/sysroot > # rpm -q udev > > It should be udev-106 because this is the only version in rawhide atm. > > I've tried to replace this with udev-105 when using the --shell > command from the git-version. But it seems not to work. So the only way > I know to create a bootable iso atm is to have a local repository of > [development] with udev-105 only. udev-106 is in the version I have in the ISO image I build. Since the bug in the live cd tool is fixed and confirmed by you in fedora-livecd-list can you build a new RPM for it for me to test the KDE live cd? Rahul From kmacmill at redhat.com Tue Mar 20 20:33:55 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 20 Mar 2007 16:33:55 -0400 Subject: fedora-maintainers vs fedora-devel In-Reply-To: <200703201445.06284.jkeating@redhat.com> References: <20070320183913.GB20185@neu.nirvana> <200703201445.06284.jkeating@redhat.com> Message-ID: <1174422835.31342.11.camel@localhost.localdomain> On Tue, 2007-03-20 at 14:45 -0400, Jesse Keating wrote: > On Tuesday 20 March 2007 14:39:13 Axel Thimm wrote: > > The way I see it it is like the following: > > > > o fedora-devel > > - concentrates on rawhide and its way to a release > > - has in-house upstream development discussion > > - more in-depth Linux mechanics > > - manages release cycle > > > > o fedora-maintainers > > - concentrates on the packaging community as a whole > > - More issues about packaging than on upstream development, if any > > - cares more about current and past releases > > Actually I do all the freeze and collection announcements to > fedora-maintainers. They're the people that need to know, and it's largely > just noise for fedora-devel. I may not be typical as I don't maintain any packages, but I do upstream work that often specifically targets Fedora releases. So seeing freeze announcements and similar on fedora-devel would be helpful. Not a big deal as I usually hear this from package maintainers indirectly, but more direct information would sometimes help. Karl From Lam at Lam.pl Tue Mar 20 20:50:28 2007 From: Lam at Lam.pl (Leszek Matok) Date: Tue, 20 Mar 2007 21:50:28 +0100 Subject: Improvement to rescue mode? In-Reply-To: <45FFEB72.40002@BitWagon.com> References: <3da3b5b40703200549v5e0bc6adxe4c40417433aac2d@mail.gmail.com> <45FFEB72.40002@BitWagon.com> Message-ID: <1174423828.11172.10.camel@pensja.lam.pl> Dnia 20-03-2007, wto o godzinie 07:10 -0700, John Reiser napisa?(a): > > Why don't you install grub on the broken system and boot it? > Because rescue mode cannot install grub via grub-install; reported as: > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198064 > The mechanism that grub-install uses to identify the "hardware" > is incompatible with the "virtualization" provided by chroot > and rescue mode. But it works with grub-install --root-directory, at least in F6 (fully updated F6 and rescue mode from the original install CD - tested yesterday). The chroot has problems related to mtab, which can be faked, but --root-directory was simpler and it works. And for the original poster: you can make a boot floppy for your system. I don't remember if Anaconda still has an option for it, though. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From Lam at Lam.pl Tue Mar 20 21:15:03 2007 From: Lam at Lam.pl (Leszek Matok) Date: Tue, 20 Mar 2007 22:15:03 +0100 Subject: too many deamons by default - F7 test 2 live cd In-Reply-To: References: <45FE5D39.7020002@fedoraproject.org> <49675.192.54.193.51.1174298721.squirrel@rousalka.dyndns.org> <45FE668B.8000904@fedoraproject.org> <20070319104612.GA5647@dudweiler.stuttgart.redhat.com> <45FE6A9A.6080505@fedoraproject.org> <1174301997.3667.30.camel@mccallum.corsepiu.local> <45FE716B.1070107@fedoraproject.org> <1174310432.3667.53.camel@mccallum.corsepiu.local> <1174365408.4531.35.camel@mccallum.corsepiu.local> Message-ID: <1174425303.11172.27.camel@pensja.lam.pl> Dnia 20-03-2007, wto o godzinie 18:46 +0100, Krzysztof Halasa napisa?(a): > ISDN/modem, i.e., dialup connection with per minute fee? Sure, that's > different story, the updates are just too expensive on that. BTW: I've > been using such dialups for years, before DSL and similar cheaper > services became available. The key word here is "price per minute", > not "speed". Your memory doesn't serve you well. Please, get yourself access to a 64Kbps link, make Fedora update itself and try to do anything else in the process. Let me propose remote SSH session. Especially when you use it for work when something's broken and you need to fix it, quick. I give you 30 seconds before you either smash your keyboard with a hammer or killall -9 yum. Because, you know, people use Fedora to do other things than updating it. I, for one, turn my computer on only when I need it. It can't download updates when I'm asleep or at work, because it's turned off at the time. Oh, I use cpuspeed on the desktop, because it saves me over 2 Watts of energy :) Don't think you can make me leave the thing on for 9 hours a day (when I'm at work, which, coincidentally, is the time needed to update OOo on my previous link; now I have a fast connection, able to update OOo in 4 hours, whoah!) Price per minute (dialup) and price per byte (GPRS) are two another factors, but don't tell me I can update my system and do anything else, even on a 256 Kbps link. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From davej at redhat.com Tue Mar 20 21:16:58 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 20 Mar 2007 17:16:58 -0400 Subject: new list: Fedora-kernel-list. Message-ID: <20070320211658.GA27030@redhat.com> In days of old, changes to the Fedora kernel would typically mean sending me a patch in an email. These days, now that we've got more than one fulltime Fedora kernel maintainer, it's meant I've had to educate people into adding Chuck onto the Cc: when people send me stuff. Rather than have to go through this process each time someone new joins the kernel team, creating a mailing list, and adding more people to a mailing list seems to make more sense. Rather than have another internal @redhat list however, it makes more sense in the interests of openness to make this an external list that *anyone* can subscribe to should they feel motivated to do so. So here it is: https://www.redhat.com/mailman/listinfo/fedora-kernel-list I'm sure there'll be additional purposes for the list over time, but off the top of my head, I come up with.. * Things like public decisions over config options, other packaging decisions, and just general 'direction'. A lot of decisions happen just inside my head right now, or in hallways on the rare occasions I make it to the office. With this list, hopefully I can get a little more of that info public, and surprise less people when things happen. * We could also use it as a place for people to send patches that belong in Fedora (be they backported ones for older releases, or 'lets try this' type one-offs that may not belong upstream). * We could also use it for bug-discussion and the like, although it wouldn't replace bugzilla, but instead compliment it. * Userspace bits on the periphery of the kernel (mkinitrd etc). What the list isn't for: * Anything that would be better discussed upstream at linux-kernel at vger.kernel.org Dave -- http://www.codemonkey.org.uk From j.w.r.degoede at hhs.nl Tue Mar 20 21:46:04 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 20 Mar 2007 22:46:04 +0100 Subject: new list: Fedora-kernel-list. In-Reply-To: <20070320211658.GA27030@redhat.com> References: <20070320211658.GA27030@redhat.com> Message-ID: <4600561C.7020307@hhs.nl> Dave Jones wrote: > In days of old, changes to the Fedora kernel would typically > mean sending me a patch in an email. These days, now that > we've got more than one fulltime Fedora kernel maintainer, > it's meant I've had to educate people into adding Chuck onto > the Cc: when people send me stuff. > Rather than have to go through this process each time someone > new joins the kernel team, creating a mailing list, and adding > more people to a mailing list seems to make more sense. > > Rather than have another internal @redhat list however, it > makes more sense in the interests of openness to make this > an external list that *anyone* can subscribe to should they > feel motivated to do so. > Agreed, if this is indeed meant to be public you should make the archives public too. Regards, Hans (potential fedora-kernel-list lurker, who likes to start lurking through the archives). From davej at redhat.com Tue Mar 20 21:33:54 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 20 Mar 2007 17:33:54 -0400 Subject: new list: Fedora-kernel-list. In-Reply-To: <4600561C.7020307@hhs.nl> References: <20070320211658.GA27030@redhat.com> <4600561C.7020307@hhs.nl> Message-ID: <20070320213354.GB27030@redhat.com> On Tue, Mar 20, 2007 at 10:46:04PM +0100, Hans de Goede wrote: > > > Dave Jones wrote: > > In days of old, changes to the Fedora kernel would typically > > mean sending me a patch in an email. These days, now that > > we've got more than one fulltime Fedora kernel maintainer, > > it's meant I've had to educate people into adding Chuck onto > > the Cc: when people send me stuff. > > Rather than have to go through this process each time someone > > new joins the kernel team, creating a mailing list, and adding > > more people to a mailing list seems to make more sense. > > > > Rather than have another internal @redhat list however, it > > makes more sense in the interests of openness to make this > > an external list that *anyone* can subscribe to should they > > feel motivated to do so. > > > > Agreed, if this is indeed meant to be public you should make the archives > public too. Hmm, that's odd. The admin interface showed that set to public. I'll fiddle it some more. It certainly isn't intentional. Dave -- http://www.codemonkey.org.uk From tmus at tmus.dk Tue Mar 20 20:53:09 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 20 Mar 2007 21:53:09 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174397685.10900.15.camel@localhost.localdomain> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> Message-ID: Adam Jackson wrote: > On Tue, 2007-03-20 at 10:11 +0100, Alexander Bostr?m wrote: >> >> People don't use good passwords and they don't realize that their >> password can be used remotely. Giving millions of people an sshd they >> don't know or care about is a recipe for zombie machines and bad >> security reputation. > > So I think you mean "disable password auth by default". > That would probably be the ideal solution, security-wise, to this problem. However, since we're talking about the default configuration here, I feel this would make it "too hard" to get sshd set up initally. If we disable password auth completely, we would have to manually put public keys in place via USB keys or something. That's too much work. Lets settle for a default configuration with a good balance between usability and security. Like perhaps disabling root login or something. Just my thoughts. /Thomas From dakshay at gmail.com Tue Mar 20 22:13:46 2007 From: dakshay at gmail.com (Akshay Dua) Date: Tue, 20 Mar 2007 15:13:46 -0700 Subject: Google Summer of Code Project Message-ID: <1174428826.5833.19.camel@gumpy.cecs.pdx.edu> Hello, I contacted Patrick Barnes about the following Google Summer of Code project on the Fedora site, System G-Conf (or other configuration) backend He wanted me to find out if there was any interest among fedora developers in the above topic. If so, then do let me know, and also feel free to volunteer as a mentor for this project :-> Thank you, Akshay Dua From sundaram at fedoraproject.org Tue Mar 20 22:24:12 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 21 Mar 2007 03:54:12 +0530 Subject: new list: Fedora-kernel-list. In-Reply-To: <20070320213354.GB27030@redhat.com> References: <20070320211658.GA27030@redhat.com> <4600561C.7020307@hhs.nl> <20070320213354.GB27030@redhat.com> Message-ID: <46005F0C.30007@fedoraproject.org> Dave Jones wrote: > On Tue, Mar 20, 2007 at 10:46:04PM +0100, Hans de Goede wrote: > > > > > > Dave Jones wrote: > > > In days of old, changes to the Fedora kernel would typically > > > mean sending me a patch in an email. These days, now that > > > we've got more than one fulltime Fedora kernel maintainer, > > > it's meant I've had to educate people into adding Chuck onto > > > the Cc: when people send me stuff. > > > Rather than have to go through this process each time someone > > > new joins the kernel team, creating a mailing list, and adding > > > more people to a mailing list seems to make more sense. > > > > > > Rather than have another internal @redhat list however, it > > > makes more sense in the interests of openness to make this > > > an external list that *anyone* can subscribe to should they > > > feel motivated to do so. > > > > > > > Agreed, if this is indeed meant to be public you should make the archives > > public too. > > Hmm, that's odd. The admin interface showed that set to public. > I'll fiddle it some more. It certainly isn't intentional. Is it meant for developers or do you want users to come up with bugs or questions to that list? If it just for the developer coordination fedora-kernel-devel list is a better name. Rahul From lsof at nodata.co.uk Tue Mar 20 22:45:44 2007 From: lsof at nodata.co.uk (nodata) Date: Tue, 20 Mar 2007 23:45:44 +0100 Subject: fedora.redhat.com is no more In-Reply-To: <1174346829.3627.1.camel@sb-home.lan> References: <45FF131B.8050201@redhat.com> <1174346829.3627.1.camel@sb-home.lan> Message-ID: <1174430744.3163.0.camel@sb-home.lan> Am Dienstag, den 20.03.2007, 00:27 +0100 schrieb nodata: > Am Montag, den 19.03.2007, 17:47 -0500 schrieb Mike McGrath: > > We now have a redirect for fedora.redhat.com. If you have anything > > specific you'd like redirected please let me know. Though these > > redirects will only be temporary. > > > > -Mike > > > > HTTP/1.1 302 Found > > Please can you change the temporary redirect (as in 302) to a permanent > redirect (as in 301) so that the search engines and link checkers will > see the new page. > > http://httpd.apache.org/docs/2.0/mod/mod_alias.html#redirect > > Hello? From ml at deadbabylon.de Tue Mar 20 22:53:57 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 20 Mar 2007 23:53:57 +0100 Subject: KDE-Live-CD: basic cd layout and localizations In-Reply-To: <460032EC.4060106@fedoraproject.org> References: <20070314011000.5b0cbcb8@localhost.localdomain> <20070320103804.3c8445f2@localhost.localdomain> <460032EC.4060106@fedoraproject.org> Message-ID: <200703202354.02629.ml@deadbabylon.de> Am Di 20.M?rz 2007 schrieb Rahul Sundaram: > > udev-106 is in the version I have in the ISO image I build. Since the > bug in the live cd tool is fixed and confirmed by you in > fedora-livecd-list can you build a new RPM for it for me to test the KDE > live cd? The patch is for the git-version. I'm no python-programmer, so I cannot backport it (have tried it, but it didn't work). Jeremy Katz included the patch in git an hour ago. So I would suggest to use this version instead (see wiki for usage [1]). I also don't use the rpms anymore because the git-version don't support them anymore. And F7Test3-Gnome would also use kickstart-files so I don't want to lag behind this. :) Sebastian [1] http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/KDELiveCD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jwboyer at jdub.homelinux.org Tue Mar 20 23:10:52 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 20 Mar 2007 18:10:52 -0500 Subject: new list: Fedora-kernel-list. In-Reply-To: <20070320211658.GA27030@redhat.com> References: <20070320211658.GA27030@redhat.com> Message-ID: <1174432252.2977.34.camel@vader.jdub.homelinux.org> On Tue, 2007-03-20 at 17:16 -0400, Dave Jones wrote: > In days of old, changes to the Fedora kernel would typically > mean sending me a patch in an email. These days, now that > we've got more than one fulltime Fedora kernel maintainer, > it's meant I've had to educate people into adding Chuck onto > the Cc: when people send me stuff. > Rather than have to go through this process each time someone > new joins the kernel team, creating a mailing list, and adding > more people to a mailing list seems to make more sense. > > Rather than have another internal @redhat list however, it > makes more sense in the interests of openness to make this > an external list that *anyone* can subscribe to should they > feel motivated to do so. > > So here it is: > https://www.redhat.com/mailman/listinfo/fedora-kernel-list > > I'm sure there'll be additional purposes for the list over time, > but off the top of my head, I come up with.. Excellent. Thanks Dave. josh From davej at redhat.com Tue Mar 20 23:25:11 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 20 Mar 2007 19:25:11 -0400 Subject: new list: Fedora-kernel-list. In-Reply-To: <46005F0C.30007@fedoraproject.org> References: <20070320211658.GA27030@redhat.com> <4600561C.7020307@hhs.nl> <20070320213354.GB27030@redhat.com> <46005F0C.30007@fedoraproject.org> Message-ID: <20070320232511.GB7115@redhat.com> On Wed, Mar 21, 2007 at 03:54:12AM +0530, Rahul Sundaram wrote: > > Hmm, that's odd. The admin interface showed that set to public. > > I'll fiddle it some more. It certainly isn't intentional. > > Is it meant for developers or do you want users to come up with bugs or > questions to that list? If it just for the developer coordination > fedora-kernel-devel list is a better name. Pretty much anything goes, other than stuff that obviously belongs upstream. I've no objection to bug discussion happening there (or even coordination on bugsweeps for eg), but it's unlikely to become a replacement for bugzilla. Dave -- http://www.codemonkey.org.uk From buildsys at fedoraproject.org Wed Mar 21 00:13:00 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 20 Mar 2007 20:13:00 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-20 Message-ID: <20070321001300.68CF7152130@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 69 asciidoc-8.1.0-1.fc7 bcfg2-0.9.2-4.fc7 buoh-0.8.2-2.fc7 (!) cycle-0.3.1-3.fc7 : INVALID rebuild, not published! dejavu-fonts-2.16-0.1.20070319svn1699.fc7 deluge-0.5.0-1.fc7 NEW dom4j-1.6.1-2jpp.1.fc7 dstat-0.6.4-1.fc7 NEW eclipse-mylar-1.0-2.fc7 NEW eclipse-nlspackager-0.1.3-1.fc7 NEW eclipse-sdk-nls-3.2.1-1.fc7 fedora-ds-base-1.1.0-0.1.20070320.fc7 git-1.5.0.5-1.fc7 gobby-0.4.2-3.fc7 gparted-0.3.3-5.fc7 gpsd-2.34-3.fc7 NEW grass-6.2.1-13.fc7 gtk-recordmydesktop-0.3.3.1-4.fc7 gtkwave-3.0.23-1.fc7 horde-3.1.4-2.fc7 NEW icu4j-3.4.5-2jpp.2.fc7 NEW ipw2100-firmware-1.3-8 NEW ipw2200-firmware-3.0-9 NEW iwlwifi-firmware-2.14.1-4 java-1.5.0-gcj-1.5.0.0-4.fc7.2 NEW jaxen-1.1-1jpp.1.fc7 NEW jaxen-bootstrap-1.1-1jpp.1.fc7 jd-1.8.8-0.2.cvs070320.fc7 jtidy-1.0-0.1.r7dev.1jpp.2.fc7 knetworkmanager-0.1-0.6.svn20061113.fc7 libburn-0.2.6.3-2.fc7 lilypond-2.10.20-1.fc7 logjam-4.5.3-9.fc7.1 maven-jxr-1.0-2jpp.2.fc7 NEW maven-scm-1.0-0.1.b3.2jpp.1.fc7 NEW maven-shared-1.0-4jpp.2.fc7 maven-surefire-1.5.3-2jpp.2.fc7 NEW maven2-2.0.4-10jpp.5.fc7 maven2-common-poms-1.0-4jpp.2.fc7 NEW modello-1.0-0.1.a8.4jpp.3.fc7 notecase-1.5.2-1.fc7 ntfs-config-0.5.5-2.fc7 obby-0.4.3-2.fc7 pan-0.125-2.fc7 perl-Convert-UUlib-1.08-2.fc7 perl-Font-TTF-0.40.0-3.fc7 perl-Net-Server-0.95-1.fc7 perl-Perl-Critic-1.05-1.fc7 plexus-ant-factory-1.0-0.1.a1.2jpp.2.fc7 plexus-appserver-1.0-0.1.a5.3jpp.2.fc7 plexus-bsh-factory-1.0-0.1.a7s.2jpp.2.fc7 NEW plexus-cdc-1.0-0.1.a4.2jpp.2.fc7 NEW plexus-maven-plugin-1.2-2jpp.1.fc7 NEW plexus-runtime-builder-1.0-0.1.a9.2jpp.1.fc7 plexus-xmlrpc-1.0-0.1.b4.3jpp.5.fc7 NEW pmd-3.6-1jpp.2.fc7 puppet-0.22.2-1.fc7 NEW unpaper-0_2-2.fc7 vpnc-0.4.0-2.fc7 warzone2100-2.0.5-4.fc7 wcstools-3.6.8-2.fc7 NEW ws-commons-util-1.0.1-1.fc7 xfce4-fsguard-plugin-0.3.0-4.fc7 xfce4-websearch-plugin-0.1.1-0.4.20070128svn2458.fc7 xl2tpd-1.1.09-1.fc7 NEW xmlrpc3-3.0-1jpp.1.fc7 NEW xmlunit-1.0-4jpp.1.fc7 NEW xom-1.0-3jpp.3.fc7 yumex-1.9.5-1.0.fc7 Packages built and released for Fedora Extras 6: 22 bcfg2-0.9.2-4.fc6 NEW cycle-0.3.1-3.fc6 NEW ettercap-0.7.3-12.fc6 fedora-ds-base-1.1.0-0.1.20070320.fc6 fwbackups-1.42.3-1.fc6 NEW gfa-0.4.1-4.fc6 git-1.5.0.5-1.fc6 gnubg-20061119-8.fc6 gpsd-2.34-3.fc6 NEW grass-6.2.1-13.fc6 gtkwave-3.0.23-1.fc6 kerry-0.2.1-1.fc6 notecase-1.5.2-1.fc6 NEW perl-Class-Factory-1.05-2.fc6 NEW perl-DBD-Mock-1.34-2.fc6 perl-Perl-Critic-1.05-1.fc6 puppet-0.22.2-1.fc6 NEW unpaper-0_2-2.fc6 warzone2100-2.0.5-4.fc6 wcstools-3.6.8-2.fc6 xl2tpd-1.1.09-1.fc6 xmoto-0.2.7-1.fc6 Packages built and released for Fedora Extras 5: 16 NEW cycle-0.3.1-3.fc5 NEW ettercap-0.7.3-13.3.fc5 fedora-ds-base-1.1.0-0.1.20070320.fc5 fwbackups-1.42.3-1.fc5 gdeskcal-1.01-1.fc5 git-1.5.0.5-1.fc5 gtkwave-3.0.23-1.fc5 kerry-0.2.1-1.fc5 NEW perl-Class-Factory-1.05-2.fc5 NEW perl-DBD-Mock-1.34-2.fc5 perl-Perl-Critic-1.05-1.fc5 puppet-0.22.2-1.fc5 NEW unpaper-0_2-2.fc5 wcstools-3.6.8-2.fc5 xl2tpd-1.1.09-1.fc5 xmoto-0.2.7-1.fc5 asciidoc-8.1.0-1.fc7 -------------------- * Mon Mar 19 2007 Chris Wright - 8.1.0-1 - update to asciidoc 8.1.0 bcfg2-0.9.2-4.fc7 ----------------- * Tue Mar 20 2007 Jeffrey C. Ollie - 0.9.2-4 - Server needs pyOpenSSL * Wed Feb 28 2007 Jeffrey C. Ollie - 0.9.2-3 - Don't forget %dir * Wed Feb 28 2007 Jeffrey C. Ollie - 0.9.2-2 - Fix #230478 buoh-0.8.2-2.fc7 ---------------- * Tue Mar 20 2007 Michael Schwendt - 0.8.2-2 - add dist tag for FE6 -> Fedora 7 upgrade path cycle-0.3.1-3.fc7 ----------------- dejavu-fonts-2.16-0.1.20070319svn1699.fc7 ----------------------------------------- * Tue Mar 20 2007 Nicolas Mailhot - 2.16-0.1.20070319svn1699 - early snapshot to account for F7T3 freeze deluge-0.5.0-1.fc7 ------------------ * Mon Mar 12 2007 Peter Gordon - 0.5.0-1 - Update to new upstream release (0.5.0). dom4j-1.6.1-2jpp.1.fc7 ---------------------- dstat-0.6.4-1.fc7 ----------------- * Tue Dec 12 2006 Scott Baker - 0.6.4-1 - Bumped to 0.6.4 eclipse-mylar-1.0-2.fc7 ----------------------- * Tue Mar 20 2007 Andrew Overholt 1.0-2 - Use xmlrpc3 jars instead of xmlrpc * Fri Mar 16 2007 Andrew Overholt 1.0-1 - Initial build eclipse-nlspackager-0.1.3-1.fc7 ------------------------------- * Mon Mar 19 2007 Kyu Lee 0.1.3-1 - Various fixes for extra package review. Bug#232709. * Thu Mar 15 2007 Kyu Lee 0.1.2-1 - Initial release. eclipse-sdk-nls-3.2.1-1.fc7 --------------------------- * Mon Mar 19 2007 Kyu Lee 3.2.1-1 - Fixed descriptions and Require/BuildRequire. - Version bump to match upstream eclipse-sdk. - Other minor fixes for extra review BZ#232710. - Added a line to run dos2unix on epl-v10.html files. * Mon Mar 19 2007 Kyu Lee 0.1.0-3 - Added license files to files section and minor fixes for extra package review. * Wed Feb 28 2007 Kyu Lee 0.1.0-2 - Added install and files section. fedora-ds-base-1.1.0-0.1.20070320.fc7 ------------------------------------- * Tue Mar 20 2007 Rich Megginson - 1.1.0-0.1.20070320 - update to latest sources - added migrateTo11 to allow migrating instances from 1.0.x to 1.1 - ldapi support - fixed pam passthru plugin ENTRY method git-1.5.0.5-1.fc7 ----------------- * Mon Mar 19 2007 Chris Wright 1.5.0.5-1 - git-1.5.0.5 gobby-0.4.2-3.fc7 ----------------- * Tue Mar 20 2007 Luke Macken - 0.4.2-3 - Add avahi-compat-howl-devel to BuildRequires * Tue Mar 20 2007 Luke Macken - 0.4.2-2 - Rebuild for new obby with Zeroconf support (#232961) gparted-0.3.3-5.fc7 ------------------- * Tue Mar 20 2007 Deji Akingunola - 0.3.3-5 - Rebuild for GNU parted-1.8.5 gpsd-2.34-3.fc7 --------------- * Tue Mar 20 2007 Michael Schwendt - 2.34-3 - Bump release for FE5 -> Fedora 7 upgrade path. * Tue Feb 27 2007 Matthew Truch - 2.34-2 - BR python-devel instead of python to make it build. * Tue Feb 27 2007 Matthew Truch - 2.34-1 - Upgrade to 2.34. - Get rid of %makeinstall (which was never needed). - Possibly fix hotplug issuses (BZ 219750). - Use %python_sitelib for python site-files stuff. grass-6.2.1-13.fc7 ------------------ * Tue Mar 20 2007 Balint Cristian 6.2.1-13 - see README-fedora for license fix in redistributed tarball - r.terraflow plugin removal from -fedora tarball * Tue Mar 13 2007 Balint Cristian 6.2.1-12 - more spec review * Tue Mar 13 2007 Balint Cristian 6.2.1-11 - more spec review * Tue Mar 13 2007 Balint Cristian 6.2.1-10 - more spec review * Fri Mar 02 2007 Balint Cristian 6.2.1-9 - require missing libjpeg-devel * Tue Feb 27 2007 Balint Cristian 6.2.1-8 - more buildfixes, should build now in mock for any arches - estetic changes in spec file * Sun Feb 25 2007 Balint Cristian 6.2.1-7 - fix mock build on any arch. * Fri Feb 23 2007 Balint Cristian 6.2.1-6 - fix mock build, more spec cleanup. - fix docs lookup from g.manual - disable fedora c flags, ssp break functionality for now. * Fri Feb 23 2007 Balint Cristian 6.2.1-5 - use macros if posible. gtk-recordmydesktop-0.3.3.1-4.fc7 --------------------------------- * Tue Mar 20 2007 Sindre Pedersen Bj?rdal - 0.3.3.1-4 - Bump release and rebuild gtkwave-3.0.23-1.fc7 -------------------- * Tue Mar 20 2007 Paul Howarth 3.0.23-1 - update to 3.0.23 horde-3.1.4-2.fc7 ----------------- * Mon Mar 19 2007 Brandon Holbrook 3.1.4-2 - Fix webroot to '/horde' in registry.php (Horde's webroot auto-detection doesn't work with our config files under /etc) * Wed Mar 14 2007 Brandon Holbrook 3.1.4-1 - Bumped to upstream 3.1.4 - Made jeta 'active' in registry.php since it is no longer beta * Wed Dec 27 2006 Brandon Holbrook 3.1.3-11 - created the 'enhanced' subpackage to pull in extented deps * Wed Dec 27 2006 Brandon Holbrook 3.1.3-10 - Remove execute permission from all php scripts under horde/lib/ - Make /usr/share/horde/config/ symlink relative - Don't echo anything in %post icu4j-3.4.5-2jpp.2.fc7 ---------------------- * Fri Mar 16 2007 Jeff Johnston - 0:3.4.5-2jpp.2 - Disable eclipse plugin support temporarily until build problems can be worked out. Plugin is still being built as part of eclipse platform. - BuildRequire sinjdoc. ipw2100-firmware-1.3-8 ---------------------- * Tue Mar 20 2007 Matthias Saou 1.3-8 - Add "noarch" to the ExclusiveArchs since plague chokes otherwise. * Mon Mar 05 2007 Matthias Saou 1.3-7 - Change group and license fields to reflect latest firmware guidelines. * Sat Feb 24 2007 Matthias Saou 1.3-6 - Fix group and license tags. - Add (partially useful) exclusivearch. - Quiet %setup. ipw2200-firmware-3.0-9 ---------------------- * Tue Mar 20 2007 Matthias Saou 3.0-9 - Add "noarch" to the ExclusiveArchs since plague chokes otherwise. * Mon Mar 05 2007 Matthias Saou 3.0-8 - Change group and license fields to reflect latest firmware guidelines. * Mon Feb 26 2007 Matthias Saou 3.0-7 - Move from a symlink to using a copy for the LICENSE (cleaner and easier). * Sat Feb 24 2007 Matthias Saou 3.0-6 - Fix group and license tags. - Add (partially useful) exclusivearch. - Quiet %setup. iwlwifi-firmware-2.14.1-4 ------------------------- * Tue Mar 20 2007 Matthias Saou 2.14.1-4 - Add "noarch" to the ExclusiveArchs since plague chokes otherwise. * Mon Mar 05 2007 Matthias Saou 2.14.1-3 - Change group and license fields to reflect latest firmware guidelines. - Replace "microcode" with "firmware" in summary and description. * Mon Feb 26 2007 Matthias Saou 2.14.1-2 - Initial RPM release. - Rename from -ucode to -firmware. java-1.5.0-gcj-1.5.0.0-4.fc7.2 ------------------------------ * Mon Mar 19 2007 Thomas Fitzsimmons - 1.5.0.0-4.2 - Add bootstrap hacks. * Mon Mar 19 2007 Thomas Fitzsimmons - 1.5.0.0-4.1 - Temporary build to get Extras Java packages building again. * Fri Mar 16 2007 Thomas Fitzsimmons - 1.5.0.0-4 - Remove config(noreplace) markings on security.d files. - Make java-1.4.2-gcj-compat* provides strictly-greater-than 1.4.2.0-40jpp.111. - Remove gjdoc build requirement. - Import java-gcj-compat 1.0.72. * Fri Mar 16 2007 Thomas Fitzsimmons - 1.5.0.0-3 - Require sinjdoc. jaxen-1.1-1jpp.1.fc7 -------------------- * Mon Feb 19 2007 Andrew Overholt 0:1.1-1jpp.1 - Add explicit version-release on Provides and Obsoletes - Untabify - Remove %ghost on versioned javadoc dir - Just include %{_javadocdir}/* for javadoc package jaxen-bootstrap-1.1-1jpp.1.fc7 ------------------------------ jd-1.8.8-0.2.cvs070320.fc7 -------------------------- * Tue Mar 20 2007 Mamoru Tasaka - 1.8.8-0.2.cvs070320 - cvs 070320 (24:55 JST) jtidy-1.0-0.1.r7dev.1jpp.2.fc7 ------------------------------ * Fri Mar 16 2007 Thomas Fitzsimmons - 2:1.0-0.1.r7dev.1jpp.2 - Remove gnu-crypto build requirement. knetworkmanager-0.1-0.6.svn20061113.fc7 --------------------------------------- * Fri Jan 26 2007 Dennis Gilmore - 0.1-0.6.svn20061113 - build against dbus-qt package libburn-0.2.6.3-2.fc7 --------------------- * Tue Mar 20 2007 Denis Leroy - 0.2.6.3-2 - Moved documentation into devel package, #228372 - Updated source URL to new upstream location lilypond-2.10.20-1.fc7 ---------------------- * Tue Mar 20 2007 Quentin Spencer 2.10.20-1 - New release. logjam-4.5.3-9.fc7.1 -------------------- * Mon Mar 19 2007 Tom "spot" Callaway 1:4.5.3-9.1 - rebuild for new gtkhtml, new patch to detect it maven-jxr-1.0-2jpp.2.fc7 ------------------------ * Tue Mar 20 2007 Deepak Bhole 0:1.0-2jpp.2 - Build with maven maven-scm-1.0-0.1.b3.2jpp.1.fc7 ------------------------------- * Tue Feb 27 2007 Tania Bento 0:1.0-0.1.b3.2jpp.1 - Fixed %Release. - Fixed %BuildRoot. - Removed %Vendor. - Removed %Distribution. - Removed %post and %postun sections for javadoc. - Fixed instructions on how to generate source drop. - Marked documentation files as %doc in %files section. - Fixed %Summary. - Fixed %description. maven-shared-1.0-4jpp.2.fc7 --------------------------- * Tue Mar 20 2007 Deepak Bhole 0:1.0-4jpp.2 - Fixed BRs and Reqa * Tue Feb 27 2007 Tania Bento 0:1.0-4jpp.1 - Fixed %Release. - Fixed %BuildRoot. - Removed %Vendor. - Removed %Distribution. - Removed %post and %postun sections for file-management-javadoc. - Removed %post and %postun sections for plugin-testing-harness-javadoc. - Defined _with_gcj_support and gcj_support. - Fixed %License. - Fixed %Group. - Marked config file with %config(noreplace) in %files section. - Fixed instructions on how to generate source drop. maven-surefire-1.5.3-2jpp.2.fc7 ------------------------------- * Tue Mar 20 2007 Deepak Bhole 0:1.5.3-2jpp.2 - Build with maven maven2-2.0.4-10jpp.5.fc7 ------------------------ * Tue Mar 20 2007 Deepak Bhole 2.0.4-10jpp.5 - Force gcj_support to 0 * Tue Mar 20 2007 Deepak Bhole 2.0.4-10jpp.4 - Build without gcj for now * Fri Mar 16 2007 Deepak Bhole 0:2.0.4-10jpp.3 - Added gcj support - Fix up per Fedora spec - Added source locations/generation methods for binary %SOURCEes - Added workaround for gcj bug that causes plugin reload to fail maven2-common-poms-1.0-4jpp.2.fc7 --------------------------------- * Thu Mar 15 2007 Deepak Bhole 1.0-4jpp.2 - Updated depmap to make javax-servlet be tomcat-2.4-servlet-api modello-1.0-0.1.a8.4jpp.3.fc7 ----------------------------- * Tue Mar 20 2007 Matt Wringe 0:1.0-0.1.a8.4jpp.3 - disable gcj support * Tue Mar 13 2007 Matt Wringe 0:1.0-0.1.a8.4jpp.2 - Change license to MIT to reflex the actual license specified in the source headers. - fix various rpmlint issues * Mon Feb 26 2007 Tania Bento 0:1.0-0.1.a8.4jpp.1 - Fixed %Release. - Fixed %License. - Fixed %BuildRoot. - Removed %Vendor. - Removed %Distribution. - Defined _with_gcj_support and gcj_support. - Fixed instructions on how to generate the source drop. notecase-1.5.2-1.fc7 -------------------- * Tue Mar 20 2007 Damien Durand 1.5.2-1 - Upgrade to 1.5.2 ntfs-config-0.5.5-2.fc7 ----------------------- * Tue Mar 20 2007 Michael Schwendt - 0.5.5-2 - Bump release for FE6 -> Fedora 7 upgrade path. obby-0.4.3-2.fc7 ---------------- * Tue Mar 20 2007 Luke Macken - 0.4.3-2 - Rebuild with zeroconf support (Bug #232961) pan-0.125-2.fc7 --------------- * Tue Mar 20 2007 Michael Schwendt - 1:0.125-2 - Bump release for FE6 -> Fedora 7 upgrade path. perl-Convert-UUlib-1.08-2.fc7 ----------------------------- * Tue Mar 20 2007 Nicolas Mailhot - 1:1.08-2 - add perl-devel BR perl-Font-TTF-0.40.0-3.fc7 -------------------------- * Tue Mar 20 2007 Nicolas Mailhot - 0.40.0-3 - small packaging fixes perl-Net-Server-0.95-1.fc7 -------------------------- * Tue Mar 20 2007 Nicolas Mailhot - 0.95-1 perl-Perl-Critic-1.05-1.fc7 --------------------------- * Tue Mar 20 2007 Jose Pedro Oliveira - 1.05-1 - Update to 1.05. plexus-ant-factory-1.0-0.1.a1.2jpp.2.fc7 ---------------------------------------- * Tue Mar 20 2007 Deepak Bhole 1.0-0.1.a1.2jpp.2 - Build with maven plexus-appserver-1.0-0.1.a5.3jpp.2.fc7 -------------------------------------- * Tue Mar 20 2007 Deepak Bhole 0:1.0-0.1.a5.3jpp.2 - Build with maven plexus-bsh-factory-1.0-0.1.a7s.2jpp.2.fc7 ----------------------------------------- * Tue Mar 20 2007 Deepak Bhole 1.0-0.1.a7s.2jpp.2 - Build with maven plexus-cdc-1.0-0.1.a4.2jpp.2.fc7 -------------------------------- * Tue Mar 20 2007 Deepak Bhole 0:1.0-0.1.a4.2jpp.2 - Enable gcj * Tue Feb 20 2007 Tania Bento 0:1.0-0.1.a4.2jpp.1 - Fixed %Release. - Fixed %BuildRoot. - Removed %Vendor. - Removed %Distribution. - Edited instructions on how to generate the source drops. - Removed %post and %postun sections for javadoc. - Added gcj support. plexus-maven-plugin-1.2-2jpp.1.fc7 ---------------------------------- * Fri Feb 23 2007 Tania Bento 0:1.2-2jpp.1 - Fixed %Release. - Fixed %BuildRoot. - Removed %Vendor. - Removed %Distribution. - Removed %post and %postun sections for javadoc. - Fixed %License to correct license. - Edited instructions on how to generate source drop. - Edited %description. - Added gcj support option. plexus-runtime-builder-1.0-0.1.a9.2jpp.1.fc7 -------------------------------------------- * Thu Feb 22 2007 Tania Bento 0:1.0-0.1.a9.2jpp.1 - Fixed %Release. - Fixed %BuildRoot. - Removed %Vendor. - Removed %Distribution. - Fixed instructions how to generate the source drop. - Added gcj support. - Removed %post and %postun sections for javadoc. plexus-xmlrpc-1.0-0.1.b4.3jpp.5.fc7 ----------------------------------- * Tue Mar 20 2007 Deepak Bhole 0:1.0-0.1.b4.3jpp.5 - Fixed BRs * Tue Mar 20 2007 Deepak Bhole 0:1.0-0.1.b4.3jpp.4 - Build with maven pmd-3.6-1jpp.2.fc7 ------------------ * Mon Mar 19 2007 Matt Wringe - 0:3.6-1jpp.2 - Add missing jakarta-commons-oro build requires * Tue Mar 13 2007 Jeff Johnston - 0:3.6-1jpp.1 - Updated per Fedora package review process - Resolves: #227109 puppet-0.22.2-1.fc7 ------------------- * Mon Mar 19 2007 David Lutterkort - 0.22.2-1 - Set puppet's homedir to /var/lib/puppet, not /var/puppet - Remove no-lockdir patch, not needed anymore unpaper-0_2-2.fc7 ----------------- * Mon Mar 19 2007 Bernard Johnson - 0_2-2 - repackage tgz file without included ELF binary * Thu Mar 15 2007 Bernard Johnson - 0_2-1 - initial release vpnc-0.4.0-2.fc7 ---------------- * Tue Mar 20 2007 Tomas Mraz - 0.4.0-2 - -fstack-protector miscompilation on x86_64 is back (#232565) warzone2100-2.0.5-4.fc7 ----------------------- * Tue Mar 20 2007 Michael Schwendt - 2.0.5-4 - Bump release for FE5 -> Fedora 7 upgrade path. wcstools-3.6.8-2.fc7 -------------------- * Tue Mar 20 2007 Sergio Pascual 3.6.8-2 - Fix for bug #232413 ws-commons-util-1.0.1-1.fc7 --------------------------- * Fri Mar 16 2007 Anthony Green - 1.0.1-1 - Created. xfce4-fsguard-plugin-0.3.0-4.fc7 -------------------------------- * Mon Jan 22 2007 Christoph Wickert - 0.3.0-4 - Rebuild for Xfce 4.4 - Patch to compile with -Wl,--as-needed (bugzilla.xfce.org #2783) xfce4-websearch-plugin-0.1.1-0.4.20070128svn2458.fc7 ---------------------------------------------------- * Tue Mar 20 2007 Christoph Wickert - 0.1.1-0.4.20070128svn2458 - Update to svn release 2458. * Mon Jan 22 2007 Christoph Wickert - 0.1.1-0.3.20060923svn - Rebuild on Xfce 4.4. xl2tpd-1.1.09-1.fc7 ------------------- * Mon Mar 19 2007 Paul Wouters 1.1.09-1 - Upgraded to 1.1.09 xmlrpc3-3.0-1jpp.1.fc7 ---------------------- * Fri Mar 16 2007 Andrew Overholt 3.0-1jpp.1 - Create new xmlrpc3 package - Use maven to build - Shuffle to common, server, and client sub-packages - Add -devel sub-packages for -sources jars * Thu Mar 08 2007 Deepak Bhole 2.0.1-3jpp.2 - Add javax.net.ssl support to build org.apache.xmlrpc.secure.* - Minor spec file cleanup xmlunit-1.0-4jpp.1.fc7 ---------------------- * Mon Mar 12 2007 Permaine Cheung - 0:1.0-4jpp.1 - Add missing BR, patch to build javadoc, and other rpmlint issues xom-1.0-3jpp.3.fc7 ------------------ * Mon Mar 12 2007 Vivek Lakshmanan 0:1.0-3jpp.3.fc7 - Make build with dom4j optional (off by default) * Mon Mar 12 2007 Vivek Lakshmanan 0:1.0-3jpp.2.fc7 - Remove BR on classpathx-jaxp since libgcj includes the required bits yumex-1.9.5-1.0.fc7 ------------------- * Tue Mar 20 2007 Tim Lauridsen - 1.9.5-1.0 - Development Release 1.9.5-1.0 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From hughsient at gmail.com Wed Mar 21 00:19:29 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Mar 2007 00:19:29 +0000 Subject: Fedora Extras Package Build Report 2007-03-20 In-Reply-To: <20070321001300.68CF7152130@buildsys.fedoraproject.org> References: <20070321001300.68CF7152130@buildsys.fedoraproject.org> Message-ID: <1174436369.4159.17.camel@localhost.localdomain> On Tue, 2007-03-20 at 20:13 -0400, buildsys at fedoraproject.org wrote: > ipw2100-firmware-1.3-8 > ---------------------- > ipw2200-firmware-3.0-9 > ---------------------- > iwlwifi-firmware-2.14.1-4 > ------------------------- Really great to see these packages, thanks to all involved. Are these going to be installed by default for F7, as this would be great. Richard. From hughsient at gmail.com Wed Mar 21 01:09:14 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Mar 2007 01:09:14 +0000 Subject: Mount fixed partitions by default for F7. Was: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> <1174325858.2713.7.camel@zelda.fubar.dk> <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> Message-ID: <1174439354.27449.4.camel@localhost.localdomain> On Mon, 2007-03-19 at 17:56 +0000, Richard Hughes wrote: > > Is this a rh-legal type problem (in which case I understand) or > rh-desktop policy (which can be re-evaluated)? Personally I've > explained the 99-fixed-disk thing to at least 4 or 5 people new to > linux, and they all thought it was a crazy decision. No offence > intended. Any feedback on this? Thanks. Richard. From jkeating at redhat.com Wed Mar 21 01:14:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Mar 2007 21:14:36 -0400 Subject: Fedora Extras Package Build Report 2007-03-20 In-Reply-To: <1174436369.4159.17.camel@localhost.localdomain> References: <20070321001300.68CF7152130@buildsys.fedoraproject.org> <1174436369.4159.17.camel@localhost.localdomain> Message-ID: <200703202114.36787.jkeating@redhat.com> On Tuesday 20 March 2007 20:19:29 Richard Hughes wrote: > Really great to see these packages, thanks to all involved. Are these > going to be installed by default for F7, as this would be great. That is the plan. -- 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 david at fubar.dk Wed Mar 21 01:24:05 2007 From: david at fubar.dk (David Zeuthen) Date: Tue, 20 Mar 2007 21:24:05 -0400 Subject: Mount fixed partitions by default for F7. Was: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: <1174439354.27449.4.camel@localhost.localdomain> References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> <1174325858.2713.7.camel@zelda.fubar.dk> <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> <1174439354.27449.4.camel@localhost.localdomain> Message-ID: <1174440245.2673.21.camel@zelda.fubar.dk> On Wed, 2007-03-21 at 01:09 +0000, Richard Hughes wrote: > On Mon, 2007-03-19 at 17:56 +0000, Richard Hughes wrote: > > > > Is this a rh-legal type problem (in which case I understand) or > > rh-desktop policy (which can be re-evaluated)? Personally I've > > explained the 99-fixed-disk thing to at least 4 or 5 people new to > > linux, and they all thought it was a crazy decision. No offence > > intended. > > Any feedback on this? Thanks. That's a bit pushy. Well, it's certainly not a rh-legal thing and as I'm the package maintainer it ends up being my decision (though I guess the board can overrule my decisions)... and I don't think this change is justified so I'm just going to say no, sorry. FWIW, what really needs to happen is something a lot more flexible and more fine grained than pam_console so different Fedora spins can ship with different defaults, e.g. a desktop oriented spin (or livecd or whatever) will ship with this bit "on"; server / corp desktop oriented spins can ship with this bit "off". And even when the bit is "off" what yuou want is to explain to the user that this operation is locked down and give them an option to e.g. auth (as super user) to perform the operation anyway. Sounds familiar? That's because I've wrote about all that about more than a year ago http://lists.freedesktop.org/archives/hal/2006-January/004377.html (ignore most of the implementation details; this is afterall more than a year old.) but have been both busy with frying other fish plus I wasn't happy with the overall architecture of the code I ended up with - just too damn complex / abstrat plus it requires a whole new system-wide daemon. It works though; SUSE is already shipping PolicyKit AFAIK. I have some plans on how to greatly simplify PolicyKit (now that we have ConsoleKit and D-Bus system bus activation is on the horizon) but haven't had time to put these thoughts into email form just yet. Eventually. FWIW, this is something we sorely need in a modern system + all this is not restricted to HAL at all; it's about having a formal way of classifying what a user (uid) / group (gid) / program (security context) is allowed to do and not to do. Think about parental controls for example. So as this is applicable to many other things where we today do broken stuff like running X11 applications as uid 0 - and that pretty much includes everything in the System->Administration menu. It's just broken by design. David From hughsient at gmail.com Wed Mar 21 01:31:05 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Mar 2007 01:31:05 +0000 Subject: Mount fixed partitions by default for F7. Was: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: <1174440245.2673.21.camel@zelda.fubar.dk> References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> <1174325858.2713.7.camel@zelda.fubar.dk> <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> <1174439354.27449.4.camel@localhost.localdomain> <1174440245.2673.21.camel@zelda.fubar.dk> Message-ID: <1174440665.27449.16.camel@localhost.localdomain> On Tue, 2007-03-20 at 21:24 -0400, David Zeuthen wrote: > On Wed, 2007-03-21 at 01:09 +0000, Richard Hughes wrote: > > On Mon, 2007-03-19 at 17:56 +0000, Richard Hughes wrote: > > > > > > Is this a rh-legal type problem (in which case I understand) or > > > rh-desktop policy (which can be re-evaluated)? Personally I've > > > explained the 99-fixed-disk thing to at least 4 or 5 people new to > > > linux, and they all thought it was a crazy decision. No offence > > > intended. > > > > Any feedback on this? Thanks. > > That's a bit pushy. Yes sorry, that's part of who I am :-) > Well, it's certainly not a rh-legal thing and as I'm > the package maintainer it ends up being my decision (though I guess the > board can overrule my decisions)... and I don't think this change is > justified so I'm just going to say no, sorry. Sure, no worries. I just wanted some sort of conclusion to this thread. This might be worth putting as a FAQ on fedoraproject or something IMO. > FWIW, what really needs to happen is something a lot more flexible and > more fine grained than pam_console so different Fedora spins can ship > with different defaults, e.g. a desktop oriented spin (or livecd or > whatever) will ship with this bit "on"; server / corp desktop oriented > spins can ship with this bit "off". And even when the bit is "off" what > yuou want is to explain to the user that this operation is locked down > and give them an option to e.g. auth (as super user) to perform the > operation anyway. Sure, seems sane. > Sounds familiar? That's because I've wrote about all that about more > than a year ago > > http://lists.freedesktop.org/archives/hal/2006-January/004377.html > > (ignore most of the implementation details; this is afterall more > than a year old.) > > but have been both busy with frying other fish plus I wasn't happy with > the overall architecture of the code I ended up with - just too damn > complex / abstrat plus it requires a whole new system-wide daemon. It > works though; SUSE is already shipping PolicyKit AFAIK. > > I have some plans on how to greatly simplify PolicyKit (now that we have > ConsoleKit and D-Bus system bus activation is on the horizon) but > haven't had time to put these thoughts into email form just yet. > Eventually. Cheers, Richard. From david at fubar.dk Wed Mar 21 01:40:11 2007 From: david at fubar.dk (David Zeuthen) Date: Tue, 20 Mar 2007 21:40:11 -0400 Subject: Mount fixed partitions by default for F7. Was: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: <1174440665.27449.16.camel@localhost.localdomain> References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> <1174325858.2713.7.camel@zelda.fubar.dk> <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> <1174439354.27449.4.camel@localhost.localdomain> <1174440245.2673.21.camel@zelda.fubar.dk> <1174440665.27449.16.camel@localhost.localdomain> Message-ID: <1174441211.2673.27.camel@zelda.fubar.dk> On Wed, 2007-03-21 at 01:31 +0000, Richard Hughes wrote: > > Well, it's certainly not a rh-legal thing and as I'm > > the package maintainer it ends up being my decision (though I guess the > > board can overrule my decisions)... and I don't think this change is > > justified so I'm just going to say no, sorry. > > Sure, no worries. I just wanted some sort of conclusion to this thread. > This might be worth putting as a FAQ on fedoraproject or something IMO. As a stop-gap measure we might even 1) patch gnome-vfs to show the volumes anyway; and 2) patch gnome-mount's error dialog on catching the org.freedesktop.Hal.Device.Volume.PermissionDenied exception to point to said FAQ. These would be Fedora specific patches but that's fine as it just puts more pressure on upstream (me!) to finally fix this. Technically this is a bug-fix, not a new feature so I guess that would be good. Patches welcome :-) David From mattdm at mattdm.org Wed Mar 21 01:41:42 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Mar 2007 21:41:42 -0400 Subject: Mount fixed partitions by default for F7. Was: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: <1174440245.2673.21.camel@zelda.fubar.dk> References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> <1174325858.2713.7.camel@zelda.fubar.dk> <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> <1174439354.27449.4.camel@localhost.localdomain> <1174440245.2673.21.camel@zelda.fubar.dk> Message-ID: <20070321014142.GA22460@jadzia.bu.edu> On Tue, Mar 20, 2007 at 09:24:05PM -0400, David Zeuthen wrote: > FWIW, this is something we sorely need in a modern system + all this is > not restricted to HAL at all; it's about having a formal way of > classifying what a user (uid) / group (gid) / program (security context) > is allowed to do and not to do. Think about parental controls for > example. So as this is applicable to many other things where we today do > broken stuff like running X11 applications as uid 0 - and that pretty > much includes everything in the System->Administration menu. It's just > broken by design. I'm very much looking forward to seeing what you're currently thinking about all this. It'd be really nice if we could replace usermode/consolehelper with something more sane. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From hughsient at gmail.com Wed Mar 21 01:46:08 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Mar 2007 01:46:08 +0000 Subject: Mount fixed partitions by default for F7. Was: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: <1174441211.2673.27.camel@zelda.fubar.dk> References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> <1174325858.2713.7.camel@zelda.fubar.dk> <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> <1174439354.27449.4.camel@localhost.localdomain> <1174440245.2673.21.camel@zelda.fubar.dk> <1174440665.27449.16.camel@localhost.localdomain> <1174441211.2673.27.camel@zelda.fubar.dk> Message-ID: <1174441568.27962.0.camel@localhost.localdomain> On Tue, 2007-03-20 at 21:40 -0400, David Zeuthen wrote: > As a stop-gap measure we might even 1) patch gnome-vfs to show the > volumes anyway; and 2) patch gnome-mount's error dialog on catching > the > org.freedesktop.Hal.Device.Volume.PermissionDenied exception to point > to > said FAQ. That seems the best short term plan. > These would be Fedora specific patches but that's fine as it just puts > more pressure on upstream (me!) to finally fix this. Technically this > is > a bug-fix, not a new feature so I guess that would be good. Patches > welcome :-) Okay, I'll see what I can come up with. Richard. From caillon at redhat.com Wed Mar 21 01:57:57 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 20 Mar 2007 21:57:57 -0400 Subject: fedora-maintainers vs fedora-devel In-Reply-To: <20070320183913.GB20185@neu.nirvana> References: <20070320183913.GB20185@neu.nirvana> Message-ID: <46009125.4040802@redhat.com> Axel Thimm wrote: > o fedora-devel > - concentrates on rawhide and its way to a release > - has in-house upstream development discussion > - more in-depth Linux mechanics > - manages release cycle > > o fedora-maintainers > - concentrates on the packaging community as a whole > - More issues about packaging than on upstream development, if any > - cares more about current and past releases No, that's fedora-packaging AIUI. Fedora-maintainers is simply a list for issuing information for all maintainers. If there's new policy that affects maintainers, it gets sent to -maintainers. If there's a rebuild coming up that all maintainers need to notice, it gets sent to -maintainers. If someone rebuilds a library which others might depend on, -maintainers. Else, devel/rawhide stuff to -devel and packaging issues to -packaging. From david at fubar.dk Wed Mar 21 02:18:38 2007 From: david at fubar.dk (David Zeuthen) Date: Tue, 20 Mar 2007 22:18:38 -0400 Subject: Mount fixed partitions by default for F7. Was: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: <20070321014142.GA22460@jadzia.bu.edu> References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> <1174325858.2713.7.camel@zelda.fubar.dk> <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> <1174439354.27449.4.camel@localhost.localdomain> <1174440245.2673.21.camel@zelda.fubar.dk> <20070321014142.GA22460@jadzia.bu.edu> Message-ID: <1174443518.2673.65.camel@zelda.fubar.dk> On Tue, 2007-03-20 at 21:41 -0400, Matthew Miller wrote: > On Tue, Mar 20, 2007 at 09:24:05PM -0400, David Zeuthen wrote: > > FWIW, this is something we sorely need in a modern system + all this is > > not restricted to HAL at all; it's about having a formal way of > > classifying what a user (uid) / group (gid) / program (security context) > > is allowed to do and not to do. Think about parental controls for > > example. So as this is applicable to many other things where we today do > > broken stuff like running X11 applications as uid 0 - and that pretty > > much includes everything in the System->Administration menu. It's just > > broken by design. > > I'm very much looking forward to seeing what you're currently thinking about > all this. It'd be really nice if we could replace usermode/consolehelper > with something more sane. It's pretty brutal what I want to do since it involves rewriting bunch of stuff which in some circles is extremely unpopular. I've also been called naive. I'm also sure I'll get flamed and called names but anyway here goes... Basically, I'm saying that if an application needs to do privileged operations it needs to use a helper. This can either be a setuid helper (bad, but not necessarily) or a daemon can be poked via IPC. That IPC could be D-Bus. With D-Bus system bus activation this is really simple, basically this feature lets you define a service $ cat /usr/share/dbus-1/system-services/dk.fubar.Test.service [D-BUS Service] Name=dk.fubar.Test Exec=/home/davidz/Hacking/activation-test-service/test-service.py User=0 and as soon as someone (e.g. a desktop app) calls into dk.fubar.Test on the system message bus, the system message bus daemon will "activate" that service, e.g. it will spawn $Exec as $User, $Exec will acquire the name on the bus and then the bus passes the method call into the owner. It's totally transparent to the caller (e.g. the desktop app) whether that the service dk.fubar.Test exists already. This is actually extremely useful; consider the GNOME clock applet. It will simply just ship with a small helper and a file it puts in /usr/share/dbus-1/system-services. Then when you want to change the timezone / time / date etc. the clock applet simply does this D-Bus call org.gnome.ClockApplet.SetTimeZone("Europe/Copenhagen") on the system bus. Since no-one owns the name org.gnome.ClockApplet, the service for doing this is activated (call it /usr/libexec/gnome-applet-set-time), it changes the time zone and returns. After 30 secs of inactivity, or whatever, gnome-applet-set-time decides to kill itself to save system resources. If it's needed again, it will be activated again. This is really nice. It allows upstream projects, like GNOME and KDE, to actually make some of the applets useful with very few lines of code. Ideally, too, common things like D-Bus services for setting the timezone etc. can be shared via a fd.o project. It's kinda similar to gnome-system-tools... in spirit at least. Anyway, for this to be secure, the helper itself (whether it's setuid or activated via D-Bus) of course needs to determine whether it should carry out the request from the caller. This is where PolicyKit comes in; it's basically just a mechanism to make it easy to define who/what can do a certain operation. This is a bit complicated and abstract; I think basically PolicyKit will just become a small library interface that e.g. org.gnome.ClockApplet can use but with pluggable backends. By default it would use a file based backend but it should be possible to replace it with other checks; e.g. fetch the policy from a LDAP server or whatever. Oh, then there's the bit where the PolicyKit library says "user is not privileged to do XYZ". For this, the helper just throws a well-known exception via D-Bus and the user app knows it's denied because of PolicyKit. Depending on what XYZ is the admin may have configured that any user can do XYZ (such as mounting internal drives) if they auth as root. The thinking here is that the user can do this auth with the PolicyKit daemon; this leaves a small file somewhere in, say, /var/lib/PolicyKit, that the PolicyKit library will pick up and the next time the desktop calls into the helper to do XYZ it will succeed. That's party explained in http://webcvs.freedesktop.org/hal/PolicyKit/doc/spec/polkit-arch.png?revision=1.1 ... this scary diagram! It's actually pretty simple. Keep in mind this is a year old. Hmm.. it's still a bit complicated; that's why I was so hesitant to finish it. But I think _something_ like this is the way of the future, I'm just afraid to have too many moving parts and points of failure... I have to think a bit more about it. Coming back to the big dreaded rewrite, I don't think people should be too afraid; I'd imagine that things like yum could easily use this and provide UpdateSystem(), InstallPackage(), ReconfigureRepos() method calls so we don't need to run things like pup or pirut X11 apps as root. They would just activate a yum D-Bus service that carried out the work. Heck, it would help with these annoying flashes because these X11 apps are not multi-threaded; it would also help with the lock contention caused by yum-updatesd.... Anyway, hope this clarifies... David ps. will not respond to flames :-) From david at fubar.dk Wed Mar 21 02:32:48 2007 From: david at fubar.dk (David Zeuthen) Date: Tue, 20 Mar 2007 22:32:48 -0400 Subject: Mount fixed partitions by default for F7. Was: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: <1174443518.2673.65.camel@zelda.fubar.dk> References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> <1174325858.2713.7.camel@zelda.fubar.dk> <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> <1174439354.27449.4.camel@localhost.localdomain> <1174440245.2673.21.camel@zelda.fubar.dk> <20070321014142.GA22460@jadzia.bu.edu> <1174443518.2673.65.camel@zelda.fubar.dk> Message-ID: <1174444368.2673.73.camel@zelda.fubar.dk> On Tue, 2007-03-20 at 22:18 -0400, David Zeuthen wrote: > Basically, I'm saying that if an application needs to do privileged > operations it needs to use a helper. This can either be a setuid helper > (bad, but not necessarily) Btw, consolehelper / usermode can be considered that "helper" but one of the primary reasons that it's bad is that it launches an X11 running as root. This means that a) the app is not accessible; b) the toolkit gets confused and you get e.g. "root"'s home in the file chooser; c) things like gconf don't work; d) it's generally a bad idea to run GTK+ apps as root (image loaders, the sheer size of code running as uid 0 etc.); and many other reasons. FWIW, the GTK+ team seems to share this point of view http://gtk.org/setuid.html (of course this was written seven years ago before we had a patch to do D-Bus system bus activation...) I know some people still think that consolehelper is "good enough". I'm not terribly interested in discussing that... David From mattdm at mattdm.org Wed Mar 21 02:51:12 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 20 Mar 2007 22:51:12 -0400 Subject: Mount fixed partitions by default for F7. Was: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: <1174444368.2673.73.camel@zelda.fubar.dk> References: <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> <1174325858.2713.7.camel@zelda.fubar.dk> <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> <1174439354.27449.4.camel@localhost.localdomain> <1174440245.2673.21.camel@zelda.fubar.dk> <20070321014142.GA22460@jadzia.bu.edu> <1174443518.2673.65.camel@zelda.fubar.dk> <1174444368.2673.73.camel@zelda.fubar.dk> Message-ID: <20070321025112.GA27841@jadzia.bu.edu> On Tue, Mar 20, 2007 at 10:32:48PM -0400, David Zeuthen wrote: > Btw, consolehelper / usermode can be considered that "helper" but one of > the primary reasons that it's bad is that it launches an X11 running as > root. This means that a) the app is not accessible; b) the toolkit gets > confused and you get e.g. "root"'s home in the file chooser; c) things > like gconf don't work; d) it's generally a bad idea to run GTK+ apps as > root (image loaders, the sheer size of code running as uid 0 etc.); and > many other reasons. Right, I think everyone who isn't at least on this page needs to *get there*. This is basically the definition of the problem to be solved, from my point of view. > I know some people still think that consolehelper is "good enough". I'm > not terribly interested in discussing that... A convenient feature of consolehelper is that it works on unmodified code -- it's effectively like aliasing selected applications to "sudo application". Or "gksudo application" really. At doing that, it's "good enough". The problem is: no one should really be doing that. But I don't see a reason consolehelper/usermode couldn't exist in parallel until apps are ported to a user-front-end/root-mode-helper architecture. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From notting at redhat.com Wed Mar 21 05:47:21 2007 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Mar 2007 01:47:21 -0400 Subject: Google Summer of Code Project In-Reply-To: <1174428826.5833.19.camel@gumpy.cecs.pdx.edu> References: <1174428826.5833.19.camel@gumpy.cecs.pdx.edu> Message-ID: <20070321054721.GA24435@nostromo.devel.redhat.com> Akshay Dua (dakshay at gmail.com) said: > System G-Conf (or other configuration) backend > > He wanted me to find out if there was any interest among fedora > developers in the above topic. If so, then do let me know, and > also feel > free to volunteer as a mentor for this project :-> Actually, the need for this has sort of died down - I removed it from that page. Bill From peter at thecodergeek.com Wed Mar 21 06:02:16 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 20 Mar 2007 23:02:16 -0700 Subject: Fedora Extras Package Build Report 2007-03-20 In-Reply-To: <200703202114.36787.jkeating@redhat.com> References: <20070321001300.68CF7152130@buildsys.fedoraproject.org> <1174436369.4159.17.camel@localhost.localdomain> <200703202114.36787.jkeating@redhat.com> Message-ID: <1174456936.23396.1.camel@tuxhugs> On Tue, 2007-03-20 at 21:14 -0400, Jesse Keating wrote: > On Tuesday 20 March 2007 20:19:29 Richard Hughes wrote: > > Really great to see these packages, thanks to all involved. Are these > > going to be installed by default for F7, as this would be great. > > That is the plan. This is a huge boon and leap forward for getting laptop wireless "Just Working(TM)" in Fedora 7. Though I own no laptop hardware, all those involved in getting this packaged and whatnot have my sincere thanks for their efforts. :D -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Wed Mar 21 06:23:22 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Mar 2007 07:23:22 +0100 Subject: fedora-maintainers vs fedora-devel In-Reply-To: <46002EFF.4010900@redhat.com> References: <20070320183913.GB20185@neu.nirvana> <46002E38.5020907@leemhuis.info> <46002EFF.4010900@redhat.com> Message-ID: <4600CF5A.2050309@leemhuis.info> On 20.03.2007 19:59, Warren Togami wrote: > Thorsten Leemhuis wrote: >> I'd say we failed with what fedora-maintainers was meant for. We have >> quite some flamewars on fedora-maintainers, we discussed stuff here that >> we should have discussed in the open on fedora-devel-list, where >> non-contributors can participate, it's high traffic and we scared people >> away with it. > Perhaps *both* lists are failures in different ways? Agreed, that why I want to merge fedora-maintainers and fedora-devel, but want to set up another mailing list that really gets used to send important informations to maintainers (no discussions there!) that don't want to care about the details (or can read the merged devel list after they got a heads up from this new low-traffic mailing list). CU thl From lightsolphoenix at gmail.com Wed Mar 21 06:39:49 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Wed, 21 Mar 2007 02:39:49 -0400 Subject: What Happened To system-control-center? Message-ID: <200703210239.49448.lightsolphoenix@gmail.com> I noticed that the Fedora Control Center is just... gone... in FC6. Is it trashed or something? -- http://www.mozilla.org/products/firefox/ - Get Firefox! http://www.mozilla.org/products/thunderbird/ - Reclaim Your Inbox! Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From ggw at wolves.durham.nc.us Wed Mar 21 07:55:22 2007 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Wed, 21 Mar 2007 03:55:22 -0400 Subject: AWOL Maintainer? KYum not up-to-date Message-ID: <20070321075522.GA8961@wolves.durham.nc.us> I'd like to call attention to the stae of the KYum package in the rawhide/F7 repository -- it is still the fc6 package, and there are bugs filed for its UTF-8 (non)handling. It would be nice if a maintainer-relations person would prod upstream a bit and get some indication of what the status is going to be. TIA Wolfe -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Wed Mar 21 08:10:24 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 21 Mar 2007 09:10:24 +0100 Subject: rpms/perl-Gtk2-Ex-PodViewer/FC-6 perl-Gtk2-Ex-PodViewer.spec, NONE, 1.1 In-Reply-To: <200703210735.l2L7ZETE032589@cvs-int.fedora.redhat.com> References: <200703210735.l2L7ZETE032589@cvs-int.fedora.redhat.com> Message-ID: <1174464624.4531.188.camel@mccallum.corsepiu.local> On Wed, 2007-03-21 at 03:35 -0400, Bernard Johnson wrote: > Author: bjohnson > > Update of /cvs/extras/rpms/perl-Gtk2-Ex-PodViewer/FC-6 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv32562/FC-6 > > Added Files: > perl-Gtk2-Ex-PodViewer.spec > Log Message: > copy from branch devel > > > > --- NEW FILE perl-Gtk2-Ex-PodViewer.spec --- > Name: perl-Gtk2-Ex-PodViewer > BuildRequires: perl, perl-gettext, perl-IO-stringy, perl-Pod-Simple > BuildRequires: perl-Gtk2 Please don't BR: "perl-*" Use their perl(..) counterparts instead. Ralf From email.ahmedkamal at googlemail.com Wed Mar 21 08:14:03 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Wed, 21 Mar 2007 10:14:03 +0200 Subject: Quota per directory Message-ID: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> Coming from a systems administration background, I was very surprised to find out that fedora (well Linux actually) doesn't have a per directory quota. It is very common and needed IMHO to have a quota per directory, as the directory basically represents a project some people are working on. One would want to make sure that a certain project would not consume all disk space. Only XFS seemed to have per "project" quota (I even think the Linux implementation doesn't have that!) Is there any technical reason why ext3 does not offer such functionality, or has it just not been done? Is anyone aware of any patches to add such functionality? -------------- next part -------------- An HTML attachment was scrubbed... URL: From markmc at redhat.com Wed Mar 21 08:35:10 2007 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 21 Mar 2007 08:35:10 +0000 Subject: fedora-maintainers vs fedora-devel In-Reply-To: <200703201445.06284.jkeating@redhat.com> References: <20070320183913.GB20185@neu.nirvana> <200703201445.06284.jkeating@redhat.com> Message-ID: <1174466110.3328.14.camel@blaa> On Tue, 2007-03-20 at 14:45 -0400, Jesse Keating wrote: > On Tuesday 20 March 2007 14:39:13 Axel Thimm wrote: > > The way I see it it is like the following: > > > > o fedora-devel > > - concentrates on rawhide and its way to a release > > - has in-house upstream development discussion > > - more in-depth Linux mechanics > > - manages release cycle > > > > o fedora-maintainers > > - concentrates on the packaging community as a whole > > - More issues about packaging than on upstream development, if any > > - cares more about current and past releases > > Actually I do all the freeze and collection announcements to > fedora-maintainers. They're the people that need to know, and it's largely > just noise for fedora-devel. To me, fedora-maintainers are the people doing > the work, and a communication place for that. fedora-devel is a combo of > people doing work and a larger community consuming the work. It seems odd to create a boundary (i.e. fedora-maintainers is a closed list) between the people currently doing the work and people which might potentially do some work. You want to make it easier for people to contribute, not harder. Also, it's a pretty artificial distinction. Not currently owning a package does not mean one is not contributing to fedora e.g. I don't currently own any packages so I was silently dropped from fedora-maintainers, but I do contribute in various ways to some packages. Looking at the archives, I'm quite surprised at the level of discussion on fedora-maintainers I'm missing out on. Cheers, Mark. From hackman at venus.dti.ne.jp Wed Mar 21 09:06:23 2007 From: hackman at venus.dti.ne.jp (Hiroaki Kondo) Date: Wed, 21 Mar 2007 18:06:23 +0900 Subject: 802.1ag&802.1ah on embedded linux Message-ID: <00b801c76b98$32c5bfd0$1a101fac@NEUROMANCER> Hi list! Please let me know the information of packages about 802.1ag&802.1ah on embedded linux. I want to build the environment for NGN. Best Regards, Hiroaki Kondo From andy at warmcat.com Wed Mar 21 09:23:02 2007 From: andy at warmcat.com (Andy Green) Date: Wed, 21 Mar 2007 09:23:02 +0000 Subject: fedora-maintainers vs fedora-devel In-Reply-To: <1174466110.3328.14.camel@blaa> References: <20070320183913.GB20185@neu.nirvana> <200703201445.06284.jkeating@redhat.com> <1174466110.3328.14.camel@blaa> Message-ID: <4600F976.6030606@warmcat.com> Mark McLoughlin wrote: > It seems odd to create a boundary (i.e. fedora-maintainers is a closed > list) between the people currently doing the work and people which might > potentially do some work. You want to make it easier for people to > contribute, not harder. Yes it must be very annoying to have subhuman monkeys on the list, when everyone knows anything good can only come from $OUR_GROUP. And of course once you have an $OUR_GROUP, boundaries are what you like, because without them, horrors of horrors, people might not be able to tell if you are a subhuman monkey or not. Whereas now it's easy to tell by the unif- I mean which toilets - er... fedora-maintainers membership. -And From buildsys at redhat.com Wed Mar 21 09:24:30 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 21 Mar 2007 05:24:30 -0400 Subject: rawhide report: 20070321 changes Message-ID: <200703210924.l2L9OU2w018732@hs20-bc2-6.build.redhat.com> New package fedora-bookmarks Fedora Core bookmarks Updated Packages: SDL-1.2.11-2 ------------ * Tue Mar 20 2007 Thomas Woerner 1.2.11-2 - use X11 dlopen code for 64 bit architectures (rhbz#207903) anaconda-11.2.0.39-1 -------------------- * Tue Mar 20 2007 Jeremy Katz - 11.2.0.39-1 - Document asknetwork (clumens, #233035) - Fix no drives being selected by default with autopart (clumens) - Add bits for livecd install desktop file, etc audit-1.5.1-1.fc7 ----------------- * Tue Mar 20 2007 Steve Grubb 1.5.1-1 - Updated autrace to monitor *at syscalls - Add support in libaudit for AUDIT_BIT_TEST(^) and AUDIT_MASK_TEST (&) - Finish reworking auditd config parser - In auparse, interpret open, fcntl, and clone flags - In auparse, when interpreting execve record types, run args through unencode - Add support for OBJ_PID message type - Event dispatcher updates cairo-1.4.2-1.fc7 ----------------- * Tue Mar 20 2007 Carl Worth 1.4.2-1 - Update to 1.4.2 cups-1:1.2.10-1.fc7 ------------------- * Tue Mar 20 2007 Tim Waugh 1:1.2.10-1 - 1.2.10. * Tue Mar 20 2007 Tim Waugh 1:1.2.9-2 - Added %{_datadir}/ppd for LSB (bug #232893). desktop-printing-0.20-4.fc7 --------------------------- * Tue Mar 20 2007 Tim Waugh 0.20-4 - Python implementation of eggcups. eel2-2.18.0.1-3.fc7 ------------------- * Tue Mar 20 2007 Soren Sandmann - 2.18.0.1-3 - Fix bug in gnome-bg patch where backgrounds would get an uninitialized color. festival-1.96-1.fc7 ------------------- * Tue Mar 20 2007 Ray Strode 1.96-1 - rebuild gdm-1:2.18.0-5.fc7 ------------------ * Tue Mar 20 2007 Ray Strode - 1:2.18.0-5 - add fix to allow themes to cope with low resolution modes better (bug 232672) gnome-desktop-2.18.0-3.fc7 -------------------------- * Tue Mar 20 2007 Soren Sandmann - 2.18.0-3 - Fix a bug where only parts of the background pixmap would be drawn. gthumb-2.10.0-1.fc7 ------------------- * Tue Mar 20 2007 Matthias Clasen - 2.10.0-1 - Update to 2.10.0 hunspell-1.1.5-2.fc7 -------------------- * Tue Mar 20 2007 Caolan McNamara - 1.1.5-2 - some junk in delivered headers * Tue Mar 20 2007 Caolan McNamara - 1.1.5-1 - next version * Fri Feb 09 2007 Caolan McNamara - 1.1.4-6 - some spec cleanups ipsec-tools-0.6.6-3.fc7 ----------------------- * Tue Mar 20 2007 Harald Hoyer - 0.6.6-3.fc7 - fix for setting the security context into a proposal (32<->64bit) (rhbz#232508) iscsi-initiator-utils-6.2.0.754-0.0.fc7 --------------------------------------- * Tue Feb 06 2007 Mike Christie - 6.2.0.754-0.0 - Rebase to upstream. - Add back --map functionality but in session mode to match RHEL5 fixes - Break up iscsi init script into two, so iscsid can be started early for root * Tue Nov 28 2006 Mike Christie - 6.2.0.747-0.0 - Fix several bugs in actor.c (iscsi scheduling). This should result - in better dm-multipath intergation and fix bugs where time outs - or requests were missed or dropped. - Set default noop timeout correctly. * Sat Nov 25 2006 Mike Christie - 6.2.0.742-0.0 - Don't flood targets with nop-outs. libraw1394-1.2.1-3.fc7 ---------------------- * Mon Mar 19 2007 Kristian H??gsberg 1.2.1-3 - Add support for new stack (juju). * Sun Feb 04 2007 Jarod Wilson - 1.2.1-2 - Minor spec cleanups for Core/Extras merger (#226039) mkinitrd-6.0.8-4 ---------------- * Tue Mar 20 2007 David Cantrell - 6.0.8-4 - Rebuild for GNU parted-1.8.6 openssh-4.5p1-6.fc7 ------------------- * Tue Mar 20 2007 Tomas Mraz - 4.5p1-6 - mls level check must be done with default role same as requested parted-1.8.6-1.fc7 ------------------ * Tue Mar 20 2007 David Cantrell - 1.8.6-1 - Upgrade to GNU parted-1.8.6, summary of major change(s): a) Revert linux-swap(new) and linux-swap(old) fs types, it's linux-swap for all swap types (#233085) perl-DateManip-5.44-3.fc7 ------------------------- * Tue Mar 20 2007 Robin Norwood - 5.44-3 - Fix minor issues in spec file for package review - Bump release - Resolves: rhbz#226250 pyparted-1.8.5-4.fc7 -------------------- * Tue Mar 20 2007 David Cantrell - 1.8.5-4 - Rebuild for GNU parted-1.8.6 python-virtinst-0.102.0-1.fc7 ----------------------------- * Tue Mar 20 2007 Daniel P. Berrange - 0.102.0-1.fc7 - Updated to 0.102.0 release redhat-artwork-5.0.11-2.fc7 --------------------------- * Tue Mar 20 2007 Ray Strode 5.0.11-2 - hide certain peices of the Fedora 7 theme in resolutions less than 1024x768 (bug 232672) rhgb-0.17.2-2.fc7 ----------------- * Tue Mar 20 2007 Ray Strode - 0.17.2-2 - pass -br by default rp-pppoe-3.8-1.fc7 ------------------ * Tue Mar 20 2007 Than Ngo - 3.8-1.fc7 - update to 3.8 samba-0:3.0.24-6.fc7 -------------------- * Tue Mar 20 2007 Simo Sorce 3.0.24-6.fc7 - do not put comments inline on smb.conf options, they may be read as part of the value (for example log files names) selinux-policy-2.5.9-2.fc7 -------------------------- * Tue Mar 20 2007 Dan Walsh 2.5.9-2 - Update to upstream - Allow saslauthd to use kerberos keytabs setroubleshoot-1.9.4-1.fc7 -------------------------- * Mon Mar 19 2007 Dan Walsh - 1.9.4-1 - Remove disable_trans boolean - Check for paths in filesystem before suggesting chcon -R - Remove default to listen on local ports squashfs-tools-3.2-1 -------------------- * Tue Mar 20 2007 Jeremy Katz - 3.2-1 - update to 3.2r2 tclx-8.4.0-7.fc7 ---------------- * Tue Mar 20 2007 Marcela Maslanova - 8.4.0-7 - rebuild for merge review units-1.86-4.fc7 ---------------- * Tue Mar 20 2007 Harald Hoyer - 1.86-4.fc7 - added readline build requirement - changed BUILDROOT * Wed Jan 24 2007 Harald Hoyer - 1.86-3.fc7 - fixed previous fix for rhbz#220533 * Tue Jan 23 2007 Florian La Roche - 1.86-2 - rhbz#220533 virt-manager-0.3.2-1.fc7 ------------------------ * Tue Mar 20 2007 Daniel P. Berrange - 0.3.2-1.fc7 - Added online help to all windows - Bug fixes to virtual console popup, key grab & accelerator override xorg-x11-drivers-7.2-5.fc7 -------------------------- * Tue Mar 20 2007 Adam Jackson 7.2-5 - Un-Require xorg-x11-drv-vga. xorg-x11-drv-nv-2.0.0-2.fc7 --------------------------- * Tue Mar 20 2007 Adam Jackson 2.0.0-2 - nv-2.0.0-hang-fix.patch: Fix a hang during initialization. xorg-x11-drv-vesa-1.3.0-5.fc7 ----------------------------- * Tue Mar 20 2007 Adam Jackson 1.3.0-5 - vesa-1.3.0-mode-heuristics.patch: If strict intersection of VBE and EDID modes leaves no modes remaining after validation, try again with just range and VBE checks. Replaces earlier range-hack and validmode patches. xterm-224-2.fc7 --------------- * Tue Mar 20 2007 Miroslav Lichvar 224-2 - fix background color setting in alternate screen - don't display xterm in menus (#231000) 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 dwmw2 at infradead.org Wed Mar 21 09:24:32 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 21 Mar 2007 09:24:32 +0000 Subject: new list: Fedora-kernel-list. In-Reply-To: <20070320211658.GA27030@redhat.com> References: <20070320211658.GA27030@redhat.com> Message-ID: <1174469072.20505.38.camel@pmac.infradead.org> On Tue, 2007-03-20 at 17:16 -0400, Dave Jones wrote: > https://www.redhat.com/mailman/listinfo/fedora-kernel-list I just subscribed, and the moronic "Avoid duplicate copies of messages?" option seems to be enabled by default. P'raps switch the default to off? -- dwmw2 From ndbecker2 at gmail.com Wed Mar 21 10:12:47 2007 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 21 Mar 2007 06:12:47 -0400 Subject: Improvement to rescue mode? References: <3da3b5b40703200549v5e0bc6adxe4c40417433aac2d@mail.gmail.com> <45FFEB72.40002@BitWagon.com> <1174423828.11172.10.camel@pensja.lam.pl> Message-ID: Leszek Matok wrote: > Dnia 20-03-2007, wto o godzinie 07:10 -0700, John Reiser napisa?(a): >> > Why don't you install grub on the broken system and boot it? >> Because rescue mode cannot install grub via grub-install; reported as: >> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198064 >> The mechanism that grub-install uses to identify the "hardware" >> is incompatible with the "virtualization" provided by chroot >> and rescue mode. > But it works with grub-install --root-directory, at least in F6 (fully > updated F6 and rescue mode from the original install CD - tested > yesterday). The chroot has problems related to mtab, which can be faked, > but --root-directory was simpler and it works. > > And for the original poster: you can make a boot floppy for your system. > I don't remember if Anaconda still has an option for it, though. > > Lam My immediate need is this. I have a system with a pair of scsi disks. It also has 1 SATA drive. For some reason I can't understand, the SATA drive is not seen by the BIOS, so I can't boot off it, but Fedora has no trouble understanding that it's there and is happy to install /boot onto it. Of course, I have no way to boot it. I haven't tried to make a boot floppy in years. Any hints? From fedora at leemhuis.info Wed Mar 21 10:22:19 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Mar 2007 11:22:19 +0100 Subject: Launching g-p-m in gdm, Was: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174417245.30528.6.camel@localhost.localdomain> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FF4457.4080309@brentnorris.net> <45FF46BB.2000701@redhat.com> <20070320110821.0c5e92c6@python3.es.egwn.lan> <45FFE0E1.10603@redhat.com> <460023E0.5080102@fedoraproject.org> <1174417245.30528.6.camel@localhost.localdomain> Message-ID: <4601075B.5000606@leemhuis.info> On 20.03.2007 20:00, Richard Hughes wrote: > On Tue, 2007-03-20 at 23:41 +0530, Rahul Sundaram wrote: >> In a earlier part of this thread, David Zuethen said that the plan is >> that g-p-m will do system wide power management for Fedora 8. > Sure, all we have to work out is how we can launch a session instance of > g-p-m at the login screen, what to do with any UI (if any) and how to > set system preferences. BTW, will g-p-m be completely control switching itself or will it simply chose the governor to be used by the kernel? Or would both be possible? The reasons why I'm asking: From what I have heard and seen on LKML I got the *impression* (maybe that's wrong) that in-kernel governor seems to be the far better choice for modern CPUs. CU thl P.S.: I'd further say the cpufreq stuff should be enabled early in the boot-process -- gdm seems quite late for me. From giallu at gmail.com Wed Mar 21 10:29:16 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Wed, 21 Mar 2007 11:29:16 +0100 Subject: /usr/include/libxml/parser.h provided by two packages Message-ID: yum whatprovides /usr/include/libxml/parser.h reports: libxml2-devel.i386 2.6.26-2.1.1 core Matched from: /usr/include/libxml/parser.h libxml++-devel.i386 2.14.0-1.1.fc6 extras Matched from: /usr/include/libxml/parser.h bug or feature? From hughsient at gmail.com Wed Mar 21 10:31:59 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Mar 2007 10:31:59 +0000 Subject: Launching g-p-m in gdm, Was: too many deamons by default - F7 test 2 live cd In-Reply-To: <4601075B.5000606@leemhuis.info> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FF4457.4080309@brentnorris.net> <45FF46BB.2000701@redhat.com> <20070320110821.0c5e92c6@python3.es.egwn.lan> <45FFE0E1.10603@redhat.com> <460023E0.5080102@fedoraproject.org> <1174417245.30528.6.camel@localhost.localdomain> <4601075B.5000606@leemhuis.info> Message-ID: <1174473119.2793.23.camel@localhost.localdomain> On Wed, 2007-03-21 at 11:22 +0100, Thorsten Leemhuis wrote: > BTW, will g-p-m be completely control switching itself or will it > simply > chose the governor to be used by the kernel? Or would both be > possible? It simply sets the kernel governor and performance metric. At the moment we are defaulting to ondemand performance 75 for AC, and ondemand performance 25 for DC. > The reasons why I'm asking: From what I have heard and seen on LKML I > got the *impression* (maybe that's wrong) that in-kernel governor > seems to be the far better choice for modern CPUs. Totally agree. The kernel is in the best position to make those kind of decisions. Richard. From veillard at redhat.com Wed Mar 21 10:34:08 2007 From: veillard at redhat.com (Daniel Veillard) Date: Wed, 21 Mar 2007 06:34:08 -0400 Subject: /usr/include/libxml/parser.h provided by two packages In-Reply-To: References: Message-ID: <20070321103408.GD1006@redhat.com> On Wed, Mar 21, 2007 at 11:29:16AM +0100, Gianluca Sforna wrote: > yum whatprovides /usr/include/libxml/parser.h > > reports: > > libxml2-devel.i386 2.6.26-2.1.1 core > Matched from: > /usr/include/libxml/parser.h That sounds wrong this should be /usr/include/libxml2/libxml/parser.h > > libxml++-devel.i386 2.14.0-1.1.fc6 extras > Matched from: > /usr/include/libxml/parser.h > > bug or feature? Still sounds wrong, libxml (version 1.x) now deprecated and removed from the distribution used to provide /usr/include/libxml/parser.h , I don't see libxml++ providing it but rather /usr/include/libxml++/parser.h and I suspect a regexp mistake or something. In any case install libxml2-devel and use xml2-config http://xmlsoft.org/FAQ.html#Developer item #1 Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From hughsient at gmail.com Wed Mar 21 10:35:01 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Mar 2007 10:35:01 +0000 Subject: Launching g-p-m in gdm, Was: too many deamons by default - F7 test 2 live cd In-Reply-To: <4601075B.5000606@leemhuis.info> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FF4457.4080309@brentnorris.net> <45FF46BB.2000701@redhat.com> <20070320110821.0c5e92c6@python3.es.egwn.lan> <45FFE0E1.10603@redhat.com> <460023E0.5080102@fedoraproject.org> <1174417245.30528.6.camel@localhost.localdomain> <4601075B.5000606@leemhuis.info> Message-ID: <1174473301.2793.26.camel@localhost.localdomain> On Wed, 2007-03-21 at 11:22 +0100, Thorsten Leemhuis wrote: > > P.S.: I'd further say the cpufreq stuff should be enabled early in the > boot-process -- gdm seems quite late for me. Sorry, I missed this bit in your email. At startup we are not idle, or at least shouldn't be, and we gain little from switching to a different governor at startup in my opinion. Whilst we are in the initscripts we *should* be at 100% utilization on as many CPUs as we have for speed, so power saving doesn't really apply. Richard. From fedora at leemhuis.info Wed Mar 21 11:08:49 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 21 Mar 2007 12:08:49 +0100 Subject: Launching g-p-m in gdm, Was: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174473301.2793.26.camel@localhost.localdomain> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FF4457.4080309@brentnorris.net> <45FF46BB.2000701@redhat.com> <20070320110821.0c5e92c6@python3.es.egwn.lan> <45FFE0E1.10603@redhat.com> <460023E0.5080102@fedoraproject.org> <1174417245.30528.6.camel@localhost.localdomain> <4601075B.5000606@leemhuis.info> <1174473301.2793.26.camel@localhost.localdomain> Message-ID: <46011241.6040209@leemhuis.info> On 21.03.2007 11:35, Richard Hughes wrote: > On Wed, 2007-03-21 at 11:22 +0100, Thorsten Leemhuis wrote: >> P.S.: I'd further say the cpufreq stuff should be enabled early in the >> boot-process -- gdm seems quite late for me. > > At startup we are not idle, or at least shouldn't be, and we gain little > from switching to a different governor at startup in my opinion. Sure, but we need to set one afaics because... > Whilst we are in the initscripts we *should* be at 100% utilization on > as many CPUs as we have for speed, so power saving doesn't really apply. ...we are I/O bound often during startup afaics (at least these days) and the CPU is often fast enough when on lower frequency. Currently the default kernel gov is userspace: $ grep DEFAULT_GOV /boot/config-2.6.20-1.2997.fc7 # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y So no power savings until something takes care of it afaics (or am I wrong with that? anyway, that could probably easily be adjusted until F8). CU thl From hughsient at gmail.com Wed Mar 21 11:23:59 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Mar 2007 11:23:59 +0000 Subject: Launching g-p-m in gdm, Was: too many deamons by default - F7 test 2 live cd In-Reply-To: <46011241.6040209@leemhuis.info> References: <45FE5D39.7020002@fedoraproject.org> <45FE6056.9080004@linux-kernel.at> <45FE6B32.2000905@leemhuis.info> <45FE6C42.30208@linux-kernel.at> <45FE726D.6000305@leemhuis.info> <45FE8942.8050602@redhat.com> <45FF4457.4080309@brentnorris.net> <45FF46BB.2000701@redhat.com> <20070320110821.0c5e92c6@python3.es.egwn.lan> <45FFE0E1.10603@redhat.com> <460023E0.5080102@fedoraproject.org> <1174417245.30528.6.camel@localhost.localdomain> <4601075B.5000606@leemhuis.info> <1174473301.2793.26.camel@localhost.localdomain> <46011241.6040209@leemhuis.info> Message-ID: <1174476239.10888.2.camel@localhost.localdomain> On Wed, 2007-03-21 at 12:08 +0100, Thorsten Leemhuis wrote: > > ...we are I/O bound often during startup afaics (at least these days) > and the CPU is often fast enough when on lower frequency. Sure, but we spend a minute or two booting up and then several hours idle on a typical day. To me, the bootup case isn't that interesting. > Currently the default kernel gov is userspace: > > $ grep DEFAULT_GOV /boot/config-2.6.20-1.2997.fc7 > # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set > CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > > So no power savings until something takes care of it afaics (or am I > wrong with that? anyway, that could probably easily be adjusted until > F8). I think ondemand might be the best choice here (if IOwait is indeed the case), or maybe performance. Richard. From rdieter at math.unl.edu Wed Mar 21 12:07:16 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 21 Mar 2007 07:07:16 -0500 Subject: KDE-Live-CD: basic cd layout and localizations References: <20070314011000.5b0cbcb8@localhost.localdomain> <20070320103804.3c8445f2@localhost.localdomain> <460032EC.4060106@fedoraproject.org> <200703202354.02629.ml@deadbabylon.de> Message-ID: Sebastian Vahl wrote: > Am Di 20.M?rz 2007 schrieb Rahul Sundaram: >> >> udev-106 is in the version I have in the ISO image I build. Since the >> bug in the live cd tool is fixed and confirmed by you in >> fedora-livecd-list can you build a new RPM for it for me to test the KDE >> live cd? > > The patch is for the git-version. I'm no python-programmer, so I cannot > backport it (have tried it, but it didn't work). Jeremy Katz included the > patch in git an hour ago. So I would suggest to use this version instead > (see wiki for usage [1]). > I also don't use the rpms anymore because the git-version don't support > them anymore. And F7Test3-Gnome would also use kickstart-files so I don't > want to lag behind this. :) The livecd tools have passed review(1), can they get imported and built in the repo so folks (like me) can more easily use these tools? Please please? -- Rex (1) For the most part, http://bugzilla.redhat.com/220635 http://bugzilla.redhat.com/220637 From markg85 at gmail.com Wed Mar 21 12:54:50 2007 From: markg85 at gmail.com (Mark) Date: Wed, 21 Mar 2007 13:54:50 +0100 Subject: Minor Nautilus patch proposal (thumbnail size) Message-ID: <6e24a8e80703210554h41e4c183p652fcb4c4ab1c0ea@mail.gmail.com> Hey, since i use Gnome in fedora i really HATE it that the thumbnails are always oversized!!! they are giant compared to the icons and this patch solves this problem. You need to edit this file: libnautilus-private/nautilus-icon-factory.h find this line: #define NAUTILUS_ICON_SIZE_THUMBNAIL 96 change the value of it ("96" in this case) to: "48" than it`s in sync with the standard icon size. result should be: #define NAUTILUS_ICON_SIZE_THUMBNAIL 48 i also edited this: #define NAUTILUS_ICON_MAXIMUM_SIZE 320 into this: #define NAUTILUS_ICON_MAXIMUM_SIZE 150 i don`t think this is a good patch. better would be to have this in the nautilus preferences window but i don`t know how to do that.. so i can`t adjust it that far. this will do fine. this patch can be done in a patch thing in the nautilus rpm package i hope this makes it`s way into the nautilus package by default.. otherwise i need to patch it manually all the time ^_- please let me know what you think of it. From ml at deadbabylon.de Wed Mar 21 13:01:57 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 21 Mar 2007 14:01:57 +0100 Subject: KDE-Live-CD: basic cd layout and localizations In-Reply-To: References: <20070314011000.5b0cbcb8@localhost.localdomain> <200703202354.02629.ml@deadbabylon.de> Message-ID: <200703211401.58096.ml@deadbabylon.de> Am Mi 21.M?rz 2007 schrieb Rex Dieter: > The livecd tools have passed review(1), can they get imported and built in > the repo so folks (like me) can more easily use these tools? Please > please? > > -- Rex > > (1) For the most part, > http://bugzilla.redhat.com/220635 > http://bugzilla.redhat.com/220637 The reviewed versions are quite old. They are for F7Test1 and don't work anymore (so I think). The git-version also uses kickstart files now. However, I'm not developing livecd-creator so I'm not the right person to maintain them (you replied to my mail :) ). Rahul Sandaram also have asked this on fedora-livecd-list. [1] Sebastian [1] https://www.redhat.com/archives/fedora-livecd-list/2007-March/msg00142.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From markg85 at gmail.com Wed Mar 21 13:08:27 2007 From: markg85 at gmail.com (Mark) Date: Wed, 21 Mar 2007 14:08:27 +0100 Subject: What Happened To system-control-center? In-Reply-To: <200703210239.49448.lightsolphoenix@gmail.com> References: <200703210239.49448.lightsolphoenix@gmail.com> Message-ID: <6e24a8e80703210608w374574a4he98104bc7438d202@mail.gmail.com> gnome-control-center ? if you don`t have it run: yum -y install control-center or look for control-center in the software installer Mark. 2007/3/21, Kelly : > I noticed that the Fedora Control Center is just... gone... in FC6. Is it > trashed or something? > -- > http://www.mozilla.org/products/firefox/ - Get Firefox! > http://www.mozilla.org/products/thunderbird/ - Reclaim Your Inbox! > > Please avoid sending me Word or PowerPoint attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From mmcgrath at redhat.com Wed Mar 21 13:17:09 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 21 Mar 2007 08:17:09 -0500 Subject: fedora.redhat.com is no more In-Reply-To: <1ed4a0130703210144q59b55602q236fc91f200a5691@mail.gmail.com> References: <45FF131B.8050201@redhat.com> <1ed4a0130703210144q59b55602q236fc91f200a5691@mail.gmail.com> Message-ID: <46013055.6070402@redhat.com> Russell Harrison wrote: > On 3/19/07, *Greg Dekoenigsberg* > wrote: > > > Ding dong, the witch is dead! :) > > > heh, and now let the process for exorcism begin. . . > > It all seriousness where is the proper place to report dead links and > the like. The fedora infrastructure ticket system, or is there a > bugzilla category those should go under? The tickets system or just email the website-list. -Mike From mclasen at redhat.com Wed Mar 21 13:47:23 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 21 Mar 2007 09:47:23 -0400 Subject: Minor Nautilus patch proposal (thumbnail size) In-Reply-To: <6e24a8e80703210554h41e4c183p652fcb4c4ab1c0ea@mail.gmail.com> References: <6e24a8e80703210554h41e4c183p652fcb4c4ab1c0ea@mail.gmail.com> Message-ID: <1174484844.28216.3.camel@golem.boston.devel.redhat.com> On Wed, 2007-03-21 at 13:54 +0100, Mark wrote: > > i hope this makes it`s way into the nautilus package by default.. > otherwise i need to patch it manually all the time ^_- Please propose this change upstream (nautilus-list at gnome.org or bugzilla.gnome.org). Matthias From markg85 at gmail.com Wed Mar 21 13:38:14 2007 From: markg85 at gmail.com (Mark) Date: Wed, 21 Mar 2007 14:38:14 +0100 Subject: Minor Nautilus patch proposal (thumbnail size) In-Reply-To: <1174484844.28216.3.camel@golem.boston.devel.redhat.com> References: <6e24a8e80703210554h41e4c183p652fcb4c4ab1c0ea@mail.gmail.com> <1174484844.28216.3.camel@golem.boston.devel.redhat.com> Message-ID: <6e24a8e80703210638j34f87836y64ee5ad515c35a9a@mail.gmail.com> i will put it on there list. thanx. but while this is not added to gnome.. fedora could add it in the rpm :) Mark. 2007/3/21, Matthias Clasen : > > On Wed, 2007-03-21 at 13:54 +0100, Mark wrote: > > > > i hope this makes it`s way into the nautilus package by default.. > > otherwise i need to patch it manually all the time ^_- > > Please propose this change upstream (nautilus-list at gnome.org or > bugzilla.gnome.org). > > > Matthias > > -- > 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 jsacco at gnome.org Wed Mar 21 14:25:40 2007 From: jsacco at gnome.org (Joseph E. Sacco) Date: Wed, 21 Mar 2007 10:25:40 -0400 Subject: fedora-ppc: Building Mac-On-Linux Message-ID: <1174487140.2477.13.camel@rt.jesacco.com> Mac-On-Linux http://sourceforge.net/projects/mac-on-linux/ is a Linux/PPC program that virtualizes MacOS or MacOSX in Linux. Mac-On-Linux builds and runs under FC6 and Fedora/rawhide. BUILDING RPMs ------------- * Download the latest source svn co https://mac-on-linux.svn.sourceforge.net/svnroot/mac-on-linux/trunk mac-on-linux * Examine/Edit src/netdriver/Kconfig Make sure that the default for building the TUN driver is set to "no" as shown below: config TUN bool "Tun driver" default n help Build the tun/tap kernel module 2.4 kernels only, 2.6 kernels please use the kernel version instead * run 'make rpms' -Joseph -- jsacco [at] gnome [dot] org From jwboyer at jdub.homelinux.org Wed Mar 21 14:31:25 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 21 Mar 2007 09:31:25 -0500 Subject: Minor Nautilus patch proposal (thumbnail size) In-Reply-To: <6e24a8e80703210638j34f87836y64ee5ad515c35a9a@mail.gmail.com> References: <6e24a8e80703210554h41e4c183p652fcb4c4ab1c0ea@mail.gmail.com> <1174484844.28216.3.camel@golem.boston.devel.redhat.com> <6e24a8e80703210638j34f87836y64ee5ad515c35a9a@mail.gmail.com> Message-ID: <1174487485.3416.70.camel@zod.rchland.ibm.com> On Wed, 2007-03-21 at 14:38 +0100, Mark wrote: > i will put it on there list. > thanx. > > but while this is not added to gnome.. fedora could add it in the > rpm :) No. It's a change that belongs upstream and Fedora truly believes in fixing things in the proper place. If it was an outright bug, maybe. But this is an enhancement request. josh From markg85 at gmail.com Wed Mar 21 14:48:13 2007 From: markg85 at gmail.com (Mark) Date: Wed, 21 Mar 2007 15:48:13 +0100 Subject: Minor Nautilus patch proposal (thumbnail size) In-Reply-To: <1174487485.3416.70.camel@zod.rchland.ibm.com> References: <6e24a8e80703210554h41e4c183p652fcb4c4ab1c0ea@mail.gmail.com> <1174484844.28216.3.camel@golem.boston.devel.redhat.com> <6e24a8e80703210638j34f87836y64ee5ad515c35a9a@mail.gmail.com> <1174487485.3416.70.camel@zod.rchland.ibm.com> Message-ID: <6e24a8e80703210748g42c740efmd9ae96c1ab508d01@mail.gmail.com> i`ve posted it here now: http://mail.gnome.org/archives/nautilus-list/2007-March/msg00055.html together with another small request of my own: http://mail.gnome.org/archives/nautilus-list/2007-March/msg00056.html btw.. does a tweaking utility exists for nautilus besides gconf? because that would certainly be welcome for nautilus. Mark. 2007/3/21, Josh Boyer : > > On Wed, 2007-03-21 at 14:38 +0100, Mark wrote: > > i will put it on there list. > > thanx. > > > > but while this is not added to gnome.. fedora could add it in the > > rpm :) > > No. It's a change that belongs upstream and Fedora truly believes in > fixing things in the proper place. If it was an outright bug, maybe. > But this is an enhancement request. > > josh > > -- > 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 buildsys at fedoraproject.org Wed Mar 21 14:57:20 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 21 Mar 2007 10:57:20 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-21 Message-ID: <20070321145720.D666E152130@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 22 OpenSceneGraph-1.2-2.fc7 emelfm2-0.3.3-1.fc7 NEW fvwm-2.5.21-4.fc7 gdal-1.4.0-17.fc7 NEW gocr-0.44-1.fc7 gtkdatabox-0.7.0.1-1.fc7 NEW hugin-0.6.1-6.fc7 ingo-1.1.3-1.fc7 inkscape-0.45.1-1.fc7 kmymoney2-0.8.6-1.fc7 libnet10-1.0.2a-12.fc7 maven-doxia-1.0-0.1.a7.3jpp.3.fc7 maven2-2.0.4-10jpp.6.fc7 mod_auth_pam-1.1.1-4.fc7 NEW perl-Gtk2-Ex-PodViewer-0.17-1.fc7 python-simplejson-1.7-2.fc7 qtparted-0.4.5-13.fc7 sobby-0.4.2-3.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.2999.fc7 NEW thunar-volman-0.1.2-1.fc7 turba-2.1.4-1.fc7 NEW xmoto-edit-0.2.4-6.fc7 emelfm2-0.3.3-1.fc7 ------------------- * Wed Mar 21 2007 Christoph Wickert - 0.3.3-1 - Update 0.3.3. fvwm-2.5.21-4.fc7 ----------------- * Thu Mar 15 2007 Adam Goode - 2.5.21-4 - Don't patch configure, just patch a few files * Thu Mar 08 2007 Adam Goode - 2.5.21-3 - Rebuild configure with autoconf >= 2.60 (for datarootdir) - Filter out local Perl libraries from provides and requires * Wed Feb 28 2007 Adam Goode - 2.5.21-2 - Shorten description - Enable auto-generate menus in the Setup Form config generator - Use htmlview instead of netscape - Use mimeopen instead of EDITOR - Add more Requires gdal-1.4.0-17.fc7 ----------------- * Tue Mar 20 2007 Balint Cristian 1.4.0-17 - enable build against grass - fix incorrect use of 32/64 library paths lookups gocr-0.44-1.fc7 --------------- * Fri Mar 02 2007 - Orion Poplawski - 0.44-1 - Update to 0.44 gtkdatabox-0.7.0.1-1.fc7 ------------------------ * Tue Mar 20 2007 Eric Work 0.7.0.1-1 - new upstream version hugin-0.6.1-6.fc7 ----------------- * Tue Mar 20 2007 Bruno Postle 0.6.1-6 - bump release due to extras make tag brokenness * Thu Mar 15 2007 Bruno Postle 0.6.1-5 - add shared-mime-info, desktop-file-utils dependencies - use desktop-file-install for .desktop file ingo-1.1.3-1.fc7 ---------------- * Tue Mar 20 2007 Brandon Holbrook 1.1.3-1 - Upgraded to upstream 1.1.3 inkscape-0.45.1-1.fc7 --------------------- * Wed Mar 21 2007 Denis Leroy - 0.45.1-1 - Update to bugfix release 0.45.1 - Added R to ImageMagick-perl (#231563) kmymoney2-0.8.6-1.fc7 --------------------- * Sat Mar 10 2007 Rex Dieter 0.8.6-1 - kmymoney2-0.8.6 - fix Obsoletes: kmymoney libnet10-1.0.2a-12.fc7 ---------------------- * Tue Aug 29 2006 Patrice Dumas - 1.0.2a-12 - rename gcc33.patch to libnet10-gcc33.patch - patch to have a version parallel installable with libnet (#229297), correct perms and keep timestamps - remove Obsoletes and Provides for libnet and libnet-devel (#229297) maven-doxia-1.0-0.1.a7.3jpp.3.fc7 --------------------------------- * Tue Mar 20 2007 Deepak Bhole 0:1.0-0.1.a7.3jpp.3 - Added switch to ignore failures for the time being * Tue Mar 20 2007 Deepak Bhole 0:1.0-0.1.a7.3jpp.2 - Build with maven maven2-2.0.4-10jpp.6.fc7 ------------------------ * Tue Mar 20 2007 Deepak Bhole 0:2.0.4-10jpp.6 - Build without bootstrap mod_auth_pam-1.1.1-4.fc7 ------------------------ * Tue Mar 20 2007 Brandon Holbrook 1.1.1-4 - Rebuild for Fedora 7 * Mon Sep 04 2006 Brandon Holbrook 1.1.1-4 - Rebuild for Fedora Extras 6 OpenSceneGraph-1.2-2.fc7 ------------------------ * Wed Mar 21 2007 Ralf Cors?pius - 1.2-2 - Attempt to build with gdal enabled. perl-Gtk2-Ex-PodViewer-0.17-1.fc7 --------------------------------- * Mon Mar 19 2007 Bernard Johnson - 0.17-1 - initial release python-simplejson-1.7-2.fc7 --------------------------- * Wed Mar 21 2007 Luke Macken - 1.7-2 - Use python_sitearch instead of sitelib * Tue Mar 20 2007 Luke Macken - 1.7-1 - 1.7 (Bug #233212) qtparted-0.4.5-13.fc7 --------------------- * Tue Mar 20 2007 Steven Pritchard - 0.4.5-13 - Rebuild. sobby-0.4.2-3.fc7 ----------------- * Tue Mar 20 2007 Luke Macken - 0.4.2-3 - Add avahi-compat-howl-devel to BuildRequires * Tue Mar 20 2007 Luke Macken - 0.4.2-2 - Rebuild for new obby with Zeroconf support (#232961) sysprof-kmod-1.0.8-1.2.6.20_1.2999.fc7 -------------------------------------- thunar-volman-0.1.2-1.fc7 ------------------------- turba-2.1.4-1.fc7 ----------------- * Tue Mar 20 2007 Brandon Holbrook 2.1.4-1 - Upgraded to upstream 2.1.4 xmoto-edit-0.2.4-6.fc7 ---------------------- * Tue Mar 20 2007 Jon Ciesla 0.2.4-6 - Replaced man page with new upstream. * Fri Mar 16 2007 Jon Ciesla 0.2.4-5 - removed versioned requires for xmoto, as versions get out of sync. * Sun Mar 11 2007 Jon Ciesla 0.2.4-4 - Fixed post/postun scripts. * Sat Mar 10 2007 Jon Ciesla 0.2.4-3 - R: xmoto, equal version. - Cleaned up BR, space/tab. - Fixed .desktop category, removed Application. * Fri Mar 02 2007 Jon Ciesla 0.2.4-2 - Fixed man path with patch. - Removed X-Fedora. * Fri Mar 02 2007 Jon Ciesla 0.2.4-1 - Initial packaging, following split from xmoto by upstream. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From lamont at gurulabs.com Wed Mar 21 15:00:38 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Wed, 21 Mar 2007 09:00:38 -0600 Subject: Quota per directory In-Reply-To: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> Message-ID: <200703210900.46111.lamont@gurulabs.com> On Wednesday 21 March 2007 02:14am, Ahmed Kamal wrote: > Coming from a systems administration background, I was very surprised to > find out that fedora (well Linux actually) doesn't have a per directory > quota. It is very common and needed IMHO to have a quota per directory, as > the directory basically represents a project some people are working on. > One would want to make sure that a certain project would not consume all > disk space. Only XFS seemed to have per "project" quota (I even think the > Linux implementation doesn't have that!) Linux "only" has per-filesystem quota support. You're asking for what's called "tree quotas" support. > Is there any technical reason why ext3 does not offer such functionality, AIUI, tree quota implementations found in commercial UNIX systems have a very large impact on filesystem performance. The per-filesystem quotas have very little impact on performance. > or has it just not been done? I've been told that there is development work underway (for several years now) to create a tree quotas implementation for Linux, but that those doing the work are only going to release it if they can do it without the massive performance overhead typicall of the commercial UNIX implementations. > Is anyone aware of any patches to add such > functionality? AFAIK (and with just a quick Google search), there are no tree quotas implementations for Linux that are "off the ground" and running yet. -- 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 Wed Mar 21 15:11:54 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Wed, 21 Mar 2007 09:11:54 -0600 Subject: fedora.redhat.com is no more In-Reply-To: <45FF131B.8050201@redhat.com> References: <45FF131B.8050201@redhat.com> Message-ID: <200703210911.54426.lamont@gurulabs.com> On Monday 19 March 2007 04:47pm, Mike McGrath wrote: > We now have a redirect for fedora.redhat.com. If you have anything > specific you'd like redirected please let me know. Though these > redirects will only be temporary. Why only temporary? Are things going to move back to fedora.redhat.com after a while? I thought the idea was that fedora.redhat.com was going away for good. In that case, you want permanent redirects as in, "this has been permanently moved to a new location and will not be returning here." -- 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 mmcgrath at redhat.com Wed Mar 21 15:15:38 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Wed, 21 Mar 2007 10:15:38 -0500 Subject: fedora.redhat.com is no more In-Reply-To: <200703210911.54426.lamont@gurulabs.com> References: <45FF131B.8050201@redhat.com> <200703210911.54426.lamont@gurulabs.com> Message-ID: <46014C1A.4020808@redhat.com> Lamont Peterson wrote: > On Monday 19 March 2007 04:47pm, Mike McGrath wrote: > >> We now have a redirect for fedora.redhat.com. If you have anything >> specific you'd like redirected please let me know. Though these >> redirects will only be temporary. >> > > Why only temporary? Are things going to move back to fedora.redhat.com after > a while? > > I thought the idea was that fedora.redhat.com was going away for good. In > that case, you want permanent redirects as in, "this has been permanently > moved to a new location and will not be returning here." > The redirect from f.rh.c to the fp.o site is permanent. The redirect from fp.o to other places like docs.fedoraproject.org is temporary. -Mike From hackman at venus.dti.ne.jp Wed Mar 21 16:38:17 2007 From: hackman at venus.dti.ne.jp (Hiroaki Kondo) Date: Thu, 22 Mar 2007 01:38:17 +0900 Subject: 802.1ag&802.1ah on embedded linux Message-ID: <002d01c76bd7$548ff650$1a101fac@NEUROMANCER> Hi list! Please let me know the information of packages about 802.1ag&802.1ah on embedded linux, if they are. I want to build the environment for NGN. Best Regards, Hiroaki Kondo Network Security Consultant in Japan hackman a venus.dti.ne.jp From davej at redhat.com Wed Mar 21 17:02:54 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 21 Mar 2007 13:02:54 -0400 Subject: Launching g-p-m in gdm, Was: too many deamons by default - F7 test 2 live cd In-Reply-To: <46011241.6040209@leemhuis.info> References: <45FF4457.4080309@brentnorris.net> <45FF46BB.2000701@redhat.com> <20070320110821.0c5e92c6@python3.es.egwn.lan> <45FFE0E1.10603@redhat.com> <460023E0.5080102@fedoraproject.org> <1174417245.30528.6.camel@localhost.localdomain> <4601075B.5000606@leemhuis.info> <1174473301.2793.26.camel@localhost.localdomain> <46011241.6040209@leemhuis.info> Message-ID: <20070321170254.GG13218@redhat.com> On Wed, Mar 21, 2007 at 12:08:49PM +0100, Thorsten Leemhuis wrote: > > On 21.03.2007 11:35, Richard Hughes wrote: > > On Wed, 2007-03-21 at 11:22 +0100, Thorsten Leemhuis wrote: > >> P.S.: I'd further say the cpufreq stuff should be enabled early in the > >> boot-process -- gdm seems quite late for me. > > > > At startup we are not idle, or at least shouldn't be, and we gain little > > from switching to a different governor at startup in my opinion. > > Sure, but we need to set one afaics because... > > > Whilst we are in the initscripts we *should* be at 100% utilization on > > as many CPUs as we have for speed, so power saving doesn't really apply. > > ...we are I/O bound often during startup afaics (at least these days) > and the CPU is often fast enough when on lower frequency. We still do enough CPU bound stuff that will make this noticable. It'll add a few seconds onto the boot time. > Currently the default kernel gov is userspace: > > $ grep DEFAULT_GOV /boot/config-2.6.20-1.2997.fc7 > # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set > CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > > So no power savings until something takes care of it afaics (or am I > wrong with that? anyway, that could probably easily be adjusted until F8). if the userspace power management stuff starts really early in the initscripts, there's no problem here. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Mar 21 17:04:13 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 21 Mar 2007 13:04:13 -0400 Subject: Launching g-p-m in gdm, Was: too many deamons by default - F7 test 2 live cd In-Reply-To: <1174476239.10888.2.camel@localhost.localdomain> References: <45FF46BB.2000701@redhat.com> <20070320110821.0c5e92c6@python3.es.egwn.lan> <45FFE0E1.10603@redhat.com> <460023E0.5080102@fedoraproject.org> <1174417245.30528.6.camel@localhost.localdomain> <4601075B.5000606@leemhuis.info> <1174473301.2793.26.camel@localhost.localdomain> <46011241.6040209@leemhuis.info> <1174476239.10888.2.camel@localhost.localdomain> Message-ID: <20070321170413.GH13218@redhat.com> On Wed, Mar 21, 2007 at 11:23:59AM +0000, Richard Hughes wrote: > > $ grep DEFAULT_GOV /boot/config-2.6.20-1.2997.fc7 > > # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set > > CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > > > > So no power savings until something takes care of it afaics (or am I > > wrong with that? anyway, that could probably easily be adjusted until > > F8). > > I think ondemand might be the best choice here (if IOwait is indeed the > case) NO. I keep bringing this up time and time again. Ondemand is not a universal answer. Not all CPU scaling implementations have fast enough latency for it to be practical. > , or maybe performance. Which is exactly the same as the case userspace+no governor, which is what we have now. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Mar 21 17:07:30 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 21 Mar 2007 13:07:30 -0400 Subject: new list: Fedora-kernel-list. In-Reply-To: <1174469072.20505.38.camel@pmac.infradead.org> References: <20070320211658.GA27030@redhat.com> <1174469072.20505.38.camel@pmac.infradead.org> Message-ID: <20070321170730.GA17746@redhat.com> On Wed, Mar 21, 2007 at 09:24:32AM +0000, David Woodhouse wrote: > On Tue, 2007-03-20 at 17:16 -0400, Dave Jones wrote: > > https://www.redhat.com/mailman/listinfo/fedora-kernel-list > > I just subscribed, and the moronic "Avoid duplicate copies of messages?" > option seems to be enabled by default. P'raps switch the default to off? I ticked some boxes. Stuff might have happened. Dave -- http://www.codemonkey.org.uk From hughsient at gmail.com Wed Mar 21 17:26:40 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Mar 2007 17:26:40 +0000 Subject: Launching g-p-m in gdm, Was: too many deamons by default - F7 test 2 live cd In-Reply-To: <20070321170413.GH13218@redhat.com> References: <45FF46BB.2000701@redhat.com> <45FFE0E1.10603@redhat.com> <460023E0.5080102@fedoraproject.org> <1174417245.30528.6.camel@localhost.localdomain> <4601075B.5000606@leemhuis.info> <1174473301.2793.26.camel@localhost.localdomain> <46011241.6040209@leemhuis.info> <1174476239.10888.2.camel@localhost.localdomain> <20070321170413.GH13218@redhat.com> Message-ID: <15e53e180703211026m3280196bx67dd063d38a03615@mail.gmail.com> On 21/03/07, Dave Jones wrote: > On Wed, Mar 21, 2007 at 11:23:59AM +0000, Richard Hughes wrote: > > > > $ grep DEFAULT_GOV /boot/config-2.6.20-1.2997.fc7 > > > # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set > > > CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y > > > > > > So no power savings until something takes care of it afaics (or am I > > > wrong with that? anyway, that could probably easily be adjusted until > > > F8). > > > > I think ondemand might be the best choice here (if IOwait is indeed the > > case) > > NO. I keep bringing this up time and time again. > Ondemand is not a universal answer. Not all CPU scaling implementations > have fast enough latency for it to be practical. Ok, no worries. > > , or maybe performance. > > Which is exactly the same as the case userspace+no governor, which > is what we have now. Ahh, I didn't know that. Cheers for clarifying. Richard. From buildsys at fedoraproject.org Wed Mar 21 18:51:07 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 21 Mar 2007 14:51:07 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-21 Message-ID: <20070321185107.29E16152130@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 1 gparted-0.3.3-6.fc7 Packages built and released for Fedora Extras 6: 10 emelfm2-0.3.3-1.fc6 NEW fvwm-2.5.21-4.fc6 gdal-1.4.0-17.fc6 gtkdatabox-0.7.0.1-1.fc6 horde-3.1.4-2.fc6 NEW hugin-0.6.1-6.fc6 inkscape-0.45.1-1.fc6 kronolith-2.1.5-1.fc6 NEW perl-Gtk2-Ex-PodViewer-0.17-1.fc6 NEW thunar-volman-0.1.2-1.fc6 Packages built and released for Fedora Extras 5: 8 emelfm2-0.3.3-1.fc5 NEW fvwm-2.5.21-4.fc5 NEW gocr-0.44-1.fc5 gtkdatabox-0.7.0.1-1.fc5 horde-3.1.4-2.fc5 NEW hugin-0.6.1-6.fc5 kronolith-2.1.5-1.fc5 NEW perl-Gtk2-Ex-PodViewer-0.17-1.fc5 gparted-0.3.3-6.fc7 ------------------- * Wed Mar 21 2007 Deji Akingunola - 0.3.3-6 - Rebuild for GNU parted-1.8.6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From abo at kth.se Wed Mar 21 18:56:14 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Wed, 21 Mar 2007 19:56:14 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> Message-ID: <1174503374.3528.200.camel@home.alexander.bostrom.net> tis 2007-03-20 klockan 21:53 +0100 skrev Thomas M Steenholdt: > However, since we're talking about the default configuration > here, I feel this would make it "too hard" to get sshd set up initally. > If we disable password auth completely, we would have to manually put > public keys in place via USB keys or something. That's too much work. Yes, correct, an ssh server that's on by default but with password auth disabled is pointless, because it's completely unusable. There's no point in requiring people to fiddle with it to make it work. Either you leave it in a usable state by default or you disable it completely by default. Disabling it also has the advantage of one less open port where a machine that's not receiving updates (fast enough) can potentially be exploited. Really, if someone can type "ssh foo at bar", is it too much to ask that they log on to bar locally and type "/sbin/chkconfig sshd on; /sbin/service sshd start"? > Lets settle for a default configuration with a good balance between > usability and security. Like perhaps disabling root login or something. Taking over a user account is really almost as bad as root access. The typical desktop user is thoroughly screwed regardless. So: How about a checkbox in anaconda or firstboot like this? [ ] Enable remote (network) access to this computer? (OpenSSH) Note, defaults to off. /abo From clumens at redhat.com Wed Mar 21 19:00:07 2007 From: clumens at redhat.com (Chris Lumens) Date: Wed, 21 Mar 2007 15:00:07 -0400 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174503374.3528.200.camel@home.alexander.bostrom.net> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> Message-ID: <20070321190007.GN16460@exeter.boston.redhat.com> > How about a checkbox in anaconda or firstboot like this? > > [ ] Enable remote (network) access to this computer? (OpenSSH) > > Note, defaults to off. firstboot already uses system-config-securitylevel to provide a screen for setting this stuff up. The default configuration on regular installs is ssh enabled, SELinux enforcing. Note that the live CD doesn't run firstboot at all, though. - Chris From abo at kth.se Wed Mar 21 19:01:02 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Wed, 21 Mar 2007 20:01:02 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <20070320150828.GD11089@nostromo.devel.redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <24903.192.54.193.51.1174382665.squirrel@rousalka.dyndns.org> <1174384001.3528.182.camel@home.alexander.bostrom.net> <20070320150828.GD11089@nostromo.devel.redhat.com> Message-ID: <1174503663.3528.209.camel@home.alexander.bostrom.net> tis 2007-03-20 klockan 11:08 -0400 skrev Bill Nottingham: > Not everything has local console access - although, you could require > such instances to access via the serial console, or do various things > with kickstart. Right! Either you do have console (where you ran anaconda) or you know your way around kickstart files, in which case %post /sbin/chkconfig sshd on is probably rather obvious. :) /abo From marksmit at us.ibm.com Wed Mar 21 18:21:35 2007 From: marksmit at us.ibm.com (Mark Smith) Date: Wed, 21 Mar 2007 13:21:35 -0500 Subject: missing FC6 system-config-control Message-ID: 2007/3/21, Kelly : > I noticed that the Fedora Control Center is just... gone... in FC6. Is it > trashed or something? I think what you noticed is that the noarch rpm from Fedora Extras: system-config-control is in FC5 Extras, but is gone from FC6 Extras and rawhide. Even my FC5 install that I "upgrade" installed to FC6, lost it. --- Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcm at redhat.com Wed Mar 21 19:02:13 2007 From: jcm at redhat.com (Jon Masters) Date: Wed, 21 Mar 2007 15:02:13 -0400 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174503374.3528.200.camel@home.alexander.bostrom.net> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> Message-ID: <1174503733.21399.31.camel@jcm.boston.redhat.com> On Wed, 2007-03-21 at 19:56 +0100, Alexander Bostr?m wrote: > Really, if someone can type "ssh foo at bar", is it too much to ask that > they log on to bar locally and type "/sbin/chkconfig sshd > on; /sbin/service sshd start"? IMO, yes. There are few times where I'll argue for services on by default but SSH is one of those fundamental services that one expects to have, pretty much on any box where an ssh server is installed. And yes, I'd argue that even applies to desktop/laptop users :-) Jon. From pemboa at gmail.com Wed Mar 21 19:10:28 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 21 Mar 2007 14:10:28 -0500 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174503374.3528.200.camel@home.alexander.bostrom.net> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> Message-ID: <16de708d0703211210v6257595kb228e149f77e6477@mail.gmail.com> On 3/21/07, Alexander Bostr?m wrote: > tis 2007-03-20 klockan 21:53 +0100 skrev Thomas M Steenholdt: > > > However, since we're talking about the default configuration > > here, I feel this would make it "too hard" to get sshd set up initally. > > If we disable password auth completely, we would have to manually put > > public keys in place via USB keys or something. That's too much work. > > Yes, correct, an ssh server that's on by default but with password auth > disabled is pointless, because it's completely unusable. There's no > point in requiring people to fiddle with it to make it work. Either you > leave it in a usable state by default or you disable it completely by > default. How about 'on' by default, but a page in first boot turns if 'off' by default? So the gurus who don't see firstboot, but will liikely need ssh will have it on. But the newbies who don't know what ssh is, will leave firstboot to turn it off, while those of us inbetween will have the choice. -- Fedora Core 6 and proud From abo at kth.se Wed Mar 21 19:14:15 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Wed, 21 Mar 2007 20:14:15 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174503733.21399.31.camel@jcm.boston.redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> <1174503733.21399.31.camel@jcm.boston.redhat.com> Message-ID: <1174504455.3528.220.camel@home.alexander.bostrom.net> ons 2007-03-21 klockan 15:02 -0400 skrev Jon Masters: > IMO, yes. There are few times where I'll argue for services on by > default but SSH is one of those fundamental services that one expects to > have, pretty much on any box where an ssh server is installed. And yes, > I'd argue that even applies to desktop/laptop users :-) *sighs* I just really doubt there's any reasonable way to prevent bad passwords from being exploited. So it will happen, and that's just not acceptable. Zombie machines, running Fedora? Come on, we're supposed to be better than that! It's really bad and and it's also bad PR. Perhaps forcing people to use good passwords would be possible, but I doubt it. I helped a guy install Fedora once, over AIM chat where I didn't actually have any control over the machine... I had to point out to him very explicitly that if he doesn't turn off sshd it'll give him trouble. (Including explaining to him that why it's bad if someone guesses his password and gets access to his machine, it wasn't entirely obvious to him.) I think he got the point and managed to type the right commands to disable it though. /abo From katzj at redhat.com Wed Mar 21 19:13:27 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 21 Mar 2007 15:13:27 -0400 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174503663.3528.209.camel@home.alexander.bostrom.net> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <24903.192.54.193.51.1174382665.squirrel@rousalka.dyndns.org> <1174384001.3528.182.camel@home.alexander.bostrom.net> <20070320150828.GD11089@nostromo.devel.redhat.com> <1174503663.3528.209.camel@home.alexander.bostrom.net> Message-ID: <1174504407.3194.9.camel@aglarond.local> On Wed, 2007-03-21 at 20:01 +0100, Alexander Bostr?m wrote: > tis 2007-03-20 klockan 11:08 -0400 skrev Bill Nottingham: > > Not everything has local console access - although, you could require > > such instances to access via the serial console, or do various things > > with kickstart. > > Right! Either you do have console (where you ran anaconda) or you know > your way around kickstart files, in which case Sadly, this isn't true for "weirdo" arches like some of the ppc stuff and s390* Jeremy From katzj at redhat.com Wed Mar 21 19:14:19 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 21 Mar 2007 15:14:19 -0400 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <20070321190007.GN16460@exeter.boston.redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> <20070321190007.GN16460@exeter.boston.redhat.com> Message-ID: <1174504459.3194.11.camel@aglarond.local> On Wed, 2007-03-21 at 15:00 -0400, Chris Lumens wrote: > > How about a checkbox in anaconda or firstboot like this? > > > > [ ] Enable remote (network) access to this computer? (OpenSSH) > > > > Note, defaults to off. > > firstboot already uses system-config-securitylevel to provide a screen > for setting this stuff up. The default configuration on regular > installs is ssh enabled, SELinux enforcing. Note that the live CD > doesn't run firstboot at all, though. Given the lack of passwords, we make sure it's off on the live CD. Crazy, but not _that_ crazy ;-) Jeremy From cmadams at hiwaay.net Wed Mar 21 19:18:32 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 21 Mar 2007 14:18:32 -0500 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174504455.3528.220.camel@home.alexander.bostrom.net> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> <1174503733.21399.31.camel@jcm.boston.redhat.com> <1174504455.3528.220.camel@home.alexander.bostrom.net> Message-ID: <20070321191831.GC1363949@hiwaay.net> Once upon a time, Alexander Bostrm said: > Perhaps forcing people to use good passwords would be possible, but I > doubt it. The "passwd" command already applies password checking by default (and has for years). Perhaps it should be considered a bug in other tools (anaconda, firstboot, etc.) that they bypass password strength checking. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From abo at kth.se Wed Mar 21 19:24:00 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Wed, 21 Mar 2007 20:24:00 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <20070321190007.GN16460@exeter.boston.redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> <20070321190007.GN16460@exeter.boston.redhat.com> Message-ID: <1174505041.3528.228.camel@home.alexander.bostrom.net> ons 2007-03-21 klockan 15:00 -0400 skrev Chris Lumens: > firstboot already uses system-config-securitylevel to provide a screen > for setting this stuff up. The default configuration on regular > installs is ssh enabled, SELinux enforcing. I have to admit I haven't been able to test F7 yet. Is this the same screen as in FC6, where you're not actually selecting whether to have sshd on or off but rather how the firewall is set up? Because I think it's much more important to make sure the system is secure (by default and after admin's changes) even without the firewall than to set the firewall "just right". So the "SSH or not" setting should control the service, not the firewall. :) The firewall is an extra protection, and in some cases a workaround for broken software where it can't be made secure any other way. (Let's say you can't figure out how to make your local caching nameserver listen only on loopback, so you firewall the port instead.) The same way, if the system is insecure when SELinux is off, then it's a bug or configuration error. It's just an extra precaution, not where the actual security is supposed to be. /abo From pemboa at gmail.com Wed Mar 21 19:24:35 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 21 Mar 2007 14:24:35 -0500 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174504455.3528.220.camel@home.alexander.bostrom.net> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> <1174503733.21399.31.camel@jcm.boston.redhat.com> <1174504455.3528.220.camel@home.alexander.bostrom.net> Message-ID: <16de708d0703211224i7af4eca6x2305a9970d62184c@mail.gmail.com> On 3/21/07, Alexander Bostr?m wrote: > ons 2007-03-21 klockan 15:02 -0400 skrev Jon Masters: > > > IMO, yes. There are few times where I'll argue for services on by > > default but SSH is one of those fundamental services that one expects to > > have, pretty much on any box where an ssh server is installed. And yes, > > I'd argue that even applies to desktop/laptop users :-) > > *sighs* I sigh right along with you, I seem to remember bringing up having root logins on by default pre FC6 - FC6 shipped with root logins on by default > I just really doubt there's any reasonable way to prevent bad passwords > from being exploited. Fedora could at _least_ ship with DenyHosts (or similar) in by default as well > So it will happen, and that's just not acceptable. > Zombie machines, running Fedora? Come on, we're supposed to be better > than that! It's really bad and and it's also bad PR. I agree > Perhaps forcing people to use good passwords would be possible, but I > doubt it. That's how things were in FC1 and FC2, for some reason, the password strength alerts were removed in prior versions. > I helped a guy install Fedora once, over AIM chat where I didn't > actually have any control over the machine... I had to point out to him > very explicitly that if he doesn't turn off sshd it'll give him trouble. > (Including explaining to him that why it's bad if someone guesses his > password and gets access to his machine, it wasn't entirely obvious to > him.) I think he got the point and managed to type the right commands to > disable it though. > > /abo Why didn't you point him to system-config-services? Along the lines of passwords, I had firstboot (or was it Anaconda) die before allowing me to create a regular user, but that's off topic I suppose -- Fedora Core 6 and proud From abo at kth.se Wed Mar 21 19:29:02 2007 From: abo at kth.se (Alexander =?ISO-8859-1?Q?Bostr=F6m?=) Date: Wed, 21 Mar 2007 20:29:02 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <16de708d0703211224i7af4eca6x2305a9970d62184c@mail.gmail.com> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> <1174503733.21399.31.camel@jcm.boston.redhat.com> <1174504455.3528.220.camel@home.alexander.bostrom.net> <16de708d0703211224i7af4eca6x2305a9970d62184c@mail.gmail.com> Message-ID: <1174505342.3528.233.camel@home.alexander.bostrom.net> ons 2007-03-21 klockan 14:24 -0500 skrev Arthur Pemberton: > Why didn't you point him to system-config-services? Over text chat, it was easier to just tell him what commands to type. :) /abo From gauret at free.fr Wed Mar 21 19:29:20 2007 From: gauret at free.fr (Aurelien Bompard) Date: Wed, 21 Mar 2007 20:29:20 +0100 Subject: Google Summer of Code Project References: <1174428826.5833.19.camel@gumpy.cecs.pdx.edu> <20070321054721.GA24435@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > Actually, the need for this has sort of died down - I removed it > from that page. I'm interested, did we find a replacement ? Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr "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 lightsolphoenix at gmail.com Wed Mar 21 20:41:31 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Wed, 21 Mar 2007 16:41:31 -0400 Subject: missing FC6 system-config-control In-Reply-To: References: Message-ID: <200703211641.32083.lightsolphoenix@gmail.com> On Wednesday, March 21, 2007 2:21 pm Mark Smith wrote: > I think what you noticed is that the noarch rpm from Fedora Extras: > system-config-control is in FC5 Extras, but is gone from FC6 Extras and > rawhide. > > Even my FC5 install that I "upgrade" installed to FC6, lost it. That's the one, because I normally install it to have one program I can use to quick-access the system-config utilities. -- http://www.mozilla.org/products/firefox/ - Get Firefox! http://www.mozilla.org/products/thunderbird/ - Reclaim Your Inbox! Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From linville at redhat.com Wed Mar 21 20:49:59 2007 From: linville at redhat.com (John W. Linville) Date: Wed, 21 Mar 2007 16:49:59 -0400 Subject: Kernel BUG caused by iwlwifi In-Reply-To: <1174295527.2881.4.camel@localhost.localdomain> References: <1174295527.2881.4.camel@localhost.localdomain> Message-ID: <20070321204959.GG28110@redhat.com> On Mon, Mar 19, 2007 at 09:12:07AM +0000, Richard Hughes wrote: > Not sure what to do here - normally I wouldn't dare report > out-of-vanilla modules for BUG'ing, but this one is being included in > rawhide and stops the boot process dead. > > Worth filing a RH bugzilla or a kernel bugzilla? This is with latest > rawhide. > > Thanks, > > Richard. > > Mar 19 08:53:15 localhost kernel: BUG: workqueue leaked lock or atomic: > iwlwifi/0/0x00000000/1230 > Mar 19 08:53:15 localhost kernel: last function: > ipw_bg_reg_txpower_periodic+0x0/0x33 [iwlwifi] > Mar 19 08:53:15 localhost kernel: 2 locks held by iwlwifi/0/1230: > Mar 19 08:53:15 localhost kernel: #0: (rtnl_mutex){--..}, at: > [] mutex_lock+0x21/0x24 > Mar 19 08:53:15 localhost kernel: #1: (&sysfs_inode_imutex_key){--..}, > at: [] mutex_lock+0x21/0x24 > Mar 19 08:53:15 localhost kernel: [] show_trace_log_lvl > +0x1a/0x2f > Mar 19 08:53:15 localhost kernel: [] show_trace+0x12/0x14 > Mar 19 08:53:15 localhost kernel: [] dump_stack+0x16/0x18 > Mar 19 08:53:15 localhost kernel: [] run_workqueue+0xfe/0x145 > Mar 19 08:53:15 localhost kernel: [] worker_thread+0xf8/0x124 > Mar 19 08:53:15 localhost kernel: [] kthread+0xb3/0xdc > Mar 19 08:53:15 localhost kernel: [] kernel_thread_helper > +0x7/0x10 > Mar 19 08:53:15 localhost kernel: ======================= >From the iwlwifi guys: "If the submitter can load the module with the debug=0x43fff module parameter it would capture some trace information in the log that might help shed light on where the lock might be being obtained before the delayed work item fires." Give that a try and post the results? FWIW, go ahead and open a bugzilla with me CC'ed. Thanks, John -- John W. Linville linville at redhat.com From tmus at tmus.dk Wed Mar 21 19:34:48 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 21 Mar 2007 20:34:48 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174503733.21399.31.camel@jcm.boston.redhat.com> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> <1174503733.21399.31.camel@jcm.boston.redhat.com> Message-ID: Jon Masters wrote: > On Wed, 2007-03-21 at 19:56 +0100, Alexander Bostr?m wrote: > >> Really, if someone can type "ssh foo at bar", is it too much to ask that >> they log on to bar locally and type "/sbin/chkconfig sshd >> on; /sbin/service sshd start"? > > IMO, yes. There are few times where I'll argue for services on by > default but SSH is one of those fundamental services that one expects to > have, pretty much on any box where an ssh server is installed. And yes, > I'd argue that even applies to desktop/laptop users :-) > > Jon. > > I have to agree with this. We can try to improve the defaults, but I'd like to keep sshd on by default. /Thomas From tmus at tmus.dk Wed Mar 21 19:42:00 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 21 Mar 2007 20:42:00 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174503374.3528.200.camel@home.alexander.bostrom.net> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> Message-ID: Alexander Bostr?m wrote: > >> Lets settle for a default configuration with a good balance between >> usability and security. Like perhaps disabling root login or something. > > Taking over a user account is really almost as bad as root access. The > typical desktop user is thoroughly screwed regardless. > I agree that compromising a user account is still bad. But not nearly as bad as root access (if one must choose), but if root access through ssh is disabled by default, attack scripts would have to *guess* a user to bruteforce and can't rely on bruteforcing "root" who exists on every *nix system. So this would allow immediate ssh access to admins (ssh as user and su -) to newly installed machines. Admin is free to remotely log in, install public keys and reconfigure sshd as he sees fit, but he's allowed to do it from his administrative workstation instead of the physical machine console. This makes a lot of sense in my world. /Thomas From debarshi.ray at gmail.com Wed Mar 21 20:23:57 2007 From: debarshi.ray at gmail.com (Debarshi 'Rishi' Ray) Date: Thu, 22 Mar 2007 01:53:57 +0530 Subject: Google Summer of Code Project In-Reply-To: References: <1174428826.5833.19.camel@gumpy.cecs.pdx.edu> <20070321054721.GA24435@nostromo.devel.redhat.com> Message-ID: <3170f42f0703211323w38e8cb86w93fa2dd7952bdbc3@mail.gmail.com> I am interested in applying for Google Summer of Code as a student. My proposal is about an offline update and installation tool that can be integrated with Pirut. Here is a draft of my proposal: http://glug-nith.org/~rishi/download/soc/soc-proposal-fedora-offline Your comments are invited. Thanks, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu From wtogami at redhat.com Wed Mar 21 21:31:35 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 21 Mar 2007 17:31:35 -0400 Subject: missing FC6 system-config-control In-Reply-To: <200703211641.32083.lightsolphoenix@gmail.com> References: <200703211641.32083.lightsolphoenix@gmail.com> Message-ID: <4601A437.6090301@redhat.com> Kelly wrote: > On Wednesday, March 21, 2007 2:21 pm Mark Smith wrote: >> I think what you noticed is that the noarch rpm from Fedora Extras: >> system-config-control is in FC5 Extras, but is gone from FC6 Extras and >> rawhide. >> >> Even my FC5 install that I "upgrade" installed to FC6, lost it. > > That's the one, because I normally install it to have one program I can use to > quick-access the system-config utilities. > system-config-control was apparently a non-official, optional add-on in Extras. It appears to be orphaned now, meaning nobody is maintaining it, thus it was removed before FC6. The only way it will be in Fedora again is if somebody takes the steps to become the maintainer and just do the work. Warren Togami wtogami at redhat.com From ml at deadbabylon.de Wed Mar 21 21:32:35 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 21 Mar 2007 22:32:35 +0100 Subject: KDE-Live-CD (Round 2): testing of included packages Message-ID: <200703212232.41623.ml@deadbabylon.de> Hi. Yo may have noticed that I've chosen 5 basic rounds for the KDE-LiveCD [1]. To the first round (choosing packages) I've only got some few answers. So I think the current cd layout is ok. The next round should be the testing of the installed packages. Some of them may need some configuration to work from a livecd. Some things I have noticed so far: - knetworkmanager vs. kwifimanger: I don't own a laptop. So I've not noticed that kwifimanager is also started automatically. Splitting of kdenetwork should resolve this point. - the start of kdm is really slow (compared with gdm) And the current version has also some problems: - When selinux is enabled the system-config-tools are not working. Booting with enforcing=0 or selinux=0 avoids this. That is a point where I need some help because I have not much experiences with selinux. - minor issue: messagebus complains about an username "gdm" If someone knows a good hoster I can upload the current version to it. This could make it a little bit easier for some people to just test the cd. Note to the localized versions: Because I don't get _any_ mail for the needed configurations, this point would left to the local communities completely. This also affects the third point in the test plan (3). Sebastian [1] http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/KDELiveCD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hughsient at gmail.com Wed Mar 21 21:37:26 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Mar 2007 21:37:26 +0000 Subject: Kernel BUG caused by iwlwifi In-Reply-To: <20070321204959.GG28110@redhat.com> References: <1174295527.2881.4.camel@localhost.localdomain> <20070321204959.GG28110@redhat.com> Message-ID: <1174513047.3046.3.camel@localhost.localdomain> On Wed, 2007-03-21 at 16:49 -0400, John W. Linville wrote: > > "If the submitter can load the module with the debug=0x43fff module > parameter it would capture some trace information in the log that > might help > shed light on where the lock might be being obtained before the > delayed work > item fires." > > Give that a try and post the results? Also posted in bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233374 Mar 21 21:02:53 localhost kernel: PCI: Enabling device 0000:05:06.0 (0000 -> 0002) Mar 21 21:02:53 localhost kernel: ACPI: PCI Interrupt 0000:05:06.0[A] -> GSI 22 (level, low) -> IRQ 21 Mar 21 21:02:53 localhost kernel: intel_rng: FWH not detected Mar 21 21:02:53 localhost kernel: fw_ohci: Added fw-ohci device 0000:05:06.0, OHCI version 1.10 Mar 21 21:02:53 localhost kernel: ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 19 (level, low) -> IRQ 19 Mar 21 21:02:53 localhost kernel: sdhci: Secure Digital Host Controller Interface driver Mar 21 21:02:53 localhost kernel: sdhci: Copyright(c) Pierre Ossman Mar 21 21:02:53 localhost kernel: Bluetooth: HCI USB driver ver 2.9 Mar 21 21:02:53 localhost kernel: usbcore: registered new interface driver hci_usb Mar 21 21:02:53 localhost kernel: input: PC Speaker as /class/input/input3 Mar 21 21:02:53 localhost kernel: sdhci: SDHCI controller found at 0000:05:06.1 [1180:0822] (rev 19) Mar 21 21:02:53 localhost kernel: PCI: Enabling device 0000:05:06.1 (0000 -> 0002) Mar 21 21:02:53 localhost kernel: ACPI: PCI Interrupt 0000:05:06.1[B] -> GSI 23 (level, low) -> IRQ 18 Mar 21 21:02:53 localhost kernel: mmc0: SDHCI at 0xd2100400 irq 18 DMA Mar 21 21:02:53 localhost kernel: iwlwifi: Intel(R) Wireless Link driver for Linux, 0.0.11k Mar 21 21:02:53 localhost kernel: iwlwifi: Copyright(c) 2003-2006 Intel Corporation Mar 21 21:02:53 localhost kernel: ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 17 Mar 21 21:02:53 localhost kernel: iwlwifi: Detected Intel PRO/Wireless 3945ABG Network Connection Mar 21 21:02:53 localhost kernel: 8139too Fast Ethernet driver 0.9.28 Mar 21 21:02:53 localhost kernel: fw_core: created new fw device fw0 (0 config rom retries) Mar 21 21:02:53 localhost kernel: usb 5-5: reset high speed USB device using ehci_hcd and address 4 Mar 21 21:02:53 localhost kernel: rtc_cmos 00:08: rtc core: registered rtc_cmos as rtc0 Mar 21 21:02:53 localhost kernel: rtc_cmos: probe of 00:08 failed with error -16 Mar 21 21:02:53 localhost kernel: ACPI: PCI Interrupt 0000:05:01.0[A] -> GSI 21 (level, low) -> IRQ 22 Mar 21 21:02:53 localhost kernel: eth0: RealTek RTL8139 at 0xf8a00000, 00:0f:b0:c7:fd:8f, IRQ 22 Mar 21 21:02:53 localhost kernel: zd1211rw_mac80211 5-5:1.0: firmware version 4725 Mar 21 21:02:53 localhost kernel: ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 21 Mar 21 21:02:53 localhost kernel: zd1211rw_mac80211 5-5:1.0: zd1211b chip 0ace:1215 v4810 high 00-16-e0 AL2230_RF pa0 ---N Mar 21 21:02:53 localhost kernel: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 14 [2.4Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 183 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 184 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 185 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 187 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 188 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 189 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 192 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 196 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 7 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 8 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 11 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 12 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 16 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 145 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 149 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 153 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 157 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 161 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Channel 165 [5.2Ghz] is Tx only -- skipping. Mar 21 21:02:53 localhost kernel: iwlwifi: Tunable channels: 13 802.11bg, 23 802.11a channels Mar 21 21:02:53 localhost kernel: iwlwifi: XXXY start rate scale Mar 21 21:02:53 localhost kernel: iwlwifi: XXXY start rate scale Mar 21 21:02:53 localhost kernel: BUG: unable to handle kernel paging request at virtual address 6b6b6ceb Mar 21 21:02:53 localhost kernel: printing eip: Mar 21 21:02:53 localhost kernel: c0448037 Mar 21 21:02:53 localhost kernel: *pde = 00000000 Mar 21 21:02:53 localhost kernel: Oops: 0002 [#1] Mar 21 21:02:53 localhost kernel: SMP Mar 21 21:02:53 localhost kernel: last sysfs file: /class/net/lo/type Mar 21 21:02:53 localhost kernel: Modules linked in: arc4 ecb blkcipher rc80211_simple 8139cp snd_hda_intel snd_hda_codec rtc_cmos snd_seq_dummy snd_seq_oss snd_seq_midi_event rtc_core snd_seq rtc_lib zd1211rw_mac80211 snd_seq_device 8139too snd_pcm_oss iwlwifi serio_raw mii pcspkr hci_usb sdhci snd_mixer_oss mac80211 i2c_i801 mmc_core fw_ohci iTCO_wdt fw_core iTCO_vendor_support cfg80211 snd_pcm bluetooth i2c_core snd_timer snd soundcore snd_page_alloc sr_mod cdrom sg joydev ata_piix ata_generic libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd Mar 21 21:02:53 localhost kernel: CPU: 0 Mar 21 21:02:53 localhost kernel: EIP: 0060:[] Not tainted VLI Mar 21 21:02:53 localhost kernel: EFLAGS: 00210246 (2.6.20-1.2999.fc7 #1) Mar 21 21:02:53 localhost kernel: EIP is at module_put+0x19/0x2d Mar 21 21:02:53 localhost kernel: eax: 6b6b6ceb ebx: f7722554 ecx: c047981d edx: 6b6b6b6b Mar 21 21:02:53 localhost kernel: esi: f7722554 edi: 0000008f ebp: f7784bb0 esp: f7784bb0 Mar 21 21:02:53 localhost kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Mar 21 21:02:53 localhost kernel: Process modprobe (pid: 1147, ti=f7784000 task=f76d4030 task.ti=f7784000) Mar 21 21:02:53 localhost kernel: Stack: f7784bbc c04d9844 f71c2c9c f7784bcc c04d98e7 f7722554 00000000 f7784bec Mar 21 21:02:53 localhost kernel: c04d9a93 f8a29277 f8a29277 00000004 f72702e0 00000000 0000008f f7784c08 Mar 21 21:02:53 localhost kernel: c04d9cc8 00000004 f8a29277 f72702e0 00000000 20104810 f7784c14 f8a1cc14 Mar 21 21:02:53 localhost kernel: Call Trace: Mar 21 21:02:53 localhost kernel: [] show_trace_log_lvl+0x1a/0x2f Mar 21 21:02:53 localhost kernel: [] show_stack_log_lvl+0x9b/0xa3 Mar 21 21:02:53 localhost kernel: [] show_registers+0x1b8/0x289 Mar 21 21:02:53 localhost kernel: [] die+0x12d/0x242 Mar 21 21:02:53 localhost kernel: [] do_page_fault+0x3ee/0x4ba Mar 21 21:02:53 localhost kernel: [] error_code+0x7c/0x84 Mar 21 21:02:53 localhost kernel: [] crypto_mod_put+0x2a/0x2d Mar 21 21:02:53 localhost kernel: [] crypto_larval_wait+0x40/0x46 Mar 21 21:02:53 localhost kernel: [] crypto_alg_mod_lookup+0x5f/0x1c9 Mar 21 21:02:53 localhost kernel: [] crypto_alloc_base+0x1e/0x66 Mar 21 21:02:53 localhost kernel: [] ieee80211_wep_init+0x2a/0x76 [mac80211] Mar 21 21:02:53 localhost kernel: [] ieee80211_register_hw+0x128/0x1c3 [mac80211] Mar 21 21:02:53 localhost kernel: [] probe+0x440/0x52e [zd1211rw_mac80211] Mar 21 21:02:53 localhost kernel: [] usb_probe_interface+0x60/0x83 Mar 21 21:02:53 localhost kernel: [] really_probe+0xc7/0x150 Mar 21 21:02:53 localhost kernel: [] driver_probe_device+0x95/0xa1 Mar 21 21:02:53 localhost kernel: [] __driver_attach+0x76/0xaf Mar 21 21:02:53 localhost kernel: [] bus_for_each_dev+0x3a/0x5f Mar 21 21:02:53 localhost kernel: [] driver_attach+0x19/0x1b Mar 21 21:02:53 localhost kernel: [] bus_add_driver+0x6a/0x170 Mar 21 21:02:53 localhost kernel: [] driver_register+0x79/0x7e Mar 21 21:02:53 localhost kernel: [] usb_register_driver+0x7e/0xe5 Mar 21 21:02:53 localhost kernel: [] usb_init+0x51/0x82 [zd1211rw_mac80211] Mar 21 21:02:53 localhost kernel: [] sys_init_module+0x159b/0x16ea Mar 21 21:02:53 localhost kernel: [] syscall_call+0x7/0xb Mar 21 21:02:53 localhost kernel: ======================= Mar 21 21:02:53 localhost kernel: Code: 0a 00 89 f8 e8 0f 73 0a 00 89 d8 5b 5e 5b 5e 5f 5d c3 55 85 c0 89 e5 89 c2 74 22 64 a1 04 00 00 00 c1 e0 07 8d 84 10 80 01 00 00 08 83 3a 02 75 0b 8b 82 88 11 00 00 e8 ac a7 fd ff 5d c3 55 Mar 21 21:02:53 localhost kernel: EIP: [] module_put+0x19/0x2d SS:ESP 0068:f7784bb0 Mar 21 21:02:53 localhost kernel: BUG: workqueue leaked lock or atomic: iwlwifi/0/0x00000000/1224 Mar 21 21:02:53 localhost kernel: last function: ipw_bg_alive_start+0x0/0x11d3 [iwlwifi] Mar 21 21:02:53 localhost kernel: 1 lock held by iwlwifi/0/1224: Mar 21 21:02:53 localhost kernel: #0: (&priv->mutex){--..}, at: [] mutex_lock+0x21/0x24 Mar 21 21:02:53 localhost kernel: [] show_trace_log_lvl+0x1a/0x2f Mar 21 21:02:53 localhost kernel: [] show_trace+0x12/0x14 Mar 21 21:02:53 localhost kernel: [] dump_stack+0x16/0x18 Mar 21 21:02:53 localhost kernel: [] run_workqueue+0xfe/0x145 Mar 21 21:02:53 localhost kernel: [] worker_thread+0xf8/0x124 Mar 21 21:02:53 localhost kernel: [] kthread+0xb3/0xdc Mar 21 21:02:53 localhost kernel: [] kernel_thread_helper+0x7/0x10 Mar 21 21:02:53 localhost kernel: ======================= Mar 21 21:02:53 localhost kernel: si3054: cannot initialize. EXT MID = 0000 Richard. From hughsient at gmail.com Wed Mar 21 20:58:57 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 21 Mar 2007 20:58:57 +0000 Subject: Kernel BUG caused by iwlwifi In-Reply-To: <20070321204959.GG28110@redhat.com> References: <1174295527.2881.4.camel@localhost.localdomain> <20070321204959.GG28110@redhat.com> Message-ID: <1174510737.3025.58.camel@localhost.localdomain> On Wed, 2007-03-21 at 16:49 -0400, John W. Linville wrote: > On Mon, Mar 19, 2007 at 09:12:07AM +0000, Richard Hughes wrote: > > Not sure what to do here - normally I wouldn't dare report > > out-of-vanilla modules for BUG'ing, but this one is being included in > > rawhide and stops the boot process dead. > > > > Worth filing a RH bugzilla or a kernel bugzilla? This is with latest > > rawhide. > > > > Thanks, > > > > Richard. > > > > Mar 19 08:53:15 localhost kernel: BUG: workqueue leaked lock or atomic: > > iwlwifi/0/0x00000000/1230 > > Mar 19 08:53:15 localhost kernel: last function: > > ipw_bg_reg_txpower_periodic+0x0/0x33 [iwlwifi] > > Mar 19 08:53:15 localhost kernel: 2 locks held by iwlwifi/0/1230: > > Mar 19 08:53:15 localhost kernel: #0: (rtnl_mutex){--..}, at: > > [] mutex_lock+0x21/0x24 > > Mar 19 08:53:15 localhost kernel: #1: (&sysfs_inode_imutex_key){--..}, > > at: [] mutex_lock+0x21/0x24 > > Mar 19 08:53:15 localhost kernel: [] show_trace_log_lvl > > +0x1a/0x2f > > Mar 19 08:53:15 localhost kernel: [] show_trace+0x12/0x14 > > Mar 19 08:53:15 localhost kernel: [] dump_stack+0x16/0x18 > > Mar 19 08:53:15 localhost kernel: [] run_workqueue+0xfe/0x145 > > Mar 19 08:53:15 localhost kernel: [] worker_thread+0xf8/0x124 > > Mar 19 08:53:15 localhost kernel: [] kthread+0xb3/0xdc > > Mar 19 08:53:15 localhost kernel: [] kernel_thread_helper > > +0x7/0x10 > > Mar 19 08:53:15 localhost kernel: ======================= > > >From the iwlwifi guys: > > "If the submitter can load the module with the debug=0x43fff module > parameter it would capture some trace information in the log that might help > shed light on where the lock might be being obtained before the delayed work > item fires." Will do, I'll try and reproduce tonight. > Give that a try and post the results? > > FWIW, go ahead and open a bugzilla with me CC'ed. Already done (different OOPS tho), https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233364 Thanks for your help with this. Richard. From tmraz at redhat.com Wed Mar 21 22:19:49 2007 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 21 Mar 2007 23:19:49 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> Message-ID: <1174515589.3309.17.camel@perun.kabelta.loc> On Wed, 2007-03-21 at 20:42 +0100, Thomas M Steenholdt wrote: > I agree that compromising a user account is still bad. But not nearly as > bad as root access (if one must choose), but if root access through ssh > is disabled by default, attack scripts would have to *guess* a user to > bruteforce and can't rely on bruteforcing "root" who exists on every > *nix system. So this would allow immediate ssh access to admins (ssh as > user and su -) to newly installed machines. Admin is free to remotely > log in, install public keys and reconfigure sshd as he sees fit, but > he's allowed to do it from his administrative workstation instead of the > physical machine console. This makes a lot of sense in my world. Except the regular users are created in firstboot which might be inaccessible when the system is installed remotely. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From nicolas.mailhot at laposte.net Wed Mar 21 22:31:34 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 21 Mar 2007 23:31:34 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> Message-ID: <1174516294.22378.5.camel@rousalka.dyndns.org> Le mercredi 21 mars 2007 ? 20:42 +0100, Thomas M Steenholdt a ?crit : > Alexander Bostr?m wrote: > > > >> Lets settle for a default configuration with a good balance between > >> usability and security. Like perhaps disabling root login or something. > > > > Taking over a user account is really almost as bad as root access. The > > typical desktop user is thoroughly screwed regardless. > > > > I agree that compromising a user account is still bad. But not nearly as > bad as root access (if one must choose), but if root access through ssh > is disabled by default, attack scripts would have to *guess* a user to > bruteforce and can't rely on bruteforcing "root" who exists on every > *nix system. attackers *do* brute-force usernames, probably because root is usually secured but you can hope hitting a user account with no password install pam_abl. It will profile the attacks for you (for exemple on my system root is the most attacked user but this is dwarfed by one-shot dictionary-user tries) -- Nicolas Mailhot From lightsolphoenix at gmail.com Wed Mar 21 22:35:31 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Wed, 21 Mar 2007 18:35:31 -0400 Subject: missing FC6 system-config-control In-Reply-To: <4601A437.6090301@redhat.com> References: <200703211641.32083.lightsolphoenix@gmail.com> <4601A437.6090301@redhat.com> Message-ID: <200703211835.32055.lightsolphoenix@gmail.com> On Wednesday, March 21, 2007 5:31 pm Warren Togami wrote: > system-config-control was apparently a non-official, optional add-on in > Extras. > > It appears to be orphaned now, meaning nobody is maintaining it, thus it > was removed before FC6. The only way it will be in Fedora again is if > somebody takes the steps to become the maintainer and just do the work. > > Warren Togami > wtogami at redhat.com I'd offer to do it, but I'm not familiar with GTK+. -- http://www.mozilla.org/products/firefox/ - Get Firefox! http://www.mozilla.org/products/thunderbird/ - Reclaim Your Inbox! Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From lightsolphoenix at gmail.com Wed Mar 21 22:37:07 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Wed, 21 Mar 2007 18:37:07 -0400 Subject: KDE-Live-CD (Round 2): testing of included packages In-Reply-To: <200703212232.41623.ml@deadbabylon.de> References: <200703212232.41623.ml@deadbabylon.de> Message-ID: <200703211837.07694.lightsolphoenix@gmail.com> On Wednesday, March 21, 2007 5:32 pm Sebastian Vahl wrote: > - knetworkmanager vs. kwifimanger: I don't own a laptop. So I've not > noticed that kwifimanager is also started automatically. Splitting of > kdenetwork should resolve this point. I find, on my laptop anyway, that knetworkmanager works far better overall. But then, it could just be me. > - the start of kdm is really slow (compared with gdm) Actually, I noticed this when I switched FC5/6 over to using kdm. Does Fedora have some kind of optimization for gdm? -- http://www.mozilla.org/products/firefox/ - Get Firefox! http://www.mozilla.org/products/thunderbird/ - Reclaim Your Inbox! Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From neugens at limasoftware.net Wed Mar 21 20:11:52 2007 From: neugens at limasoftware.net (Mario Torre) Date: Wed, 21 Mar 2007 21:11:52 +0100 Subject: Google Summer of Code project Message-ID: <1174507912.3303.7.camel@nirvana.limasoftware.net> Hello! Someone of you already know me. I'm a developer of the GNU Classpath project and for the current edition of the Summer of Code I'm trying to promote a project that will (hopefully) create an implementation of javax.sound (the Sound API)backed up by the GStreamer framework. The benefits are obvious: provide a Gnome/Gstreamer Desktop sound integration for Java. Here is a summary of my project: http://www.limasoftware.net/neugens/downloads/gsoc-2007/gsoc_2007_application_form.pdf I'm going to submit this as part of the GCC/GCJ and GNOME/GStreamer organizations, as well as Fedora, because Fedora is currently the main Free Java platform and most Fedora developers are involved in Classpath. I'm searching for a mentor that can follow me in this adventure as well as ideas (and suggestions) for this task. Thank you in advance for your feedback! Mario -- Lima Software - http://www.limasoftware.net/ GNU Classpath Developer - http://www.classpath.org/ Jabber: neugens at jabber.org - Profile: http://www.gtalkprofile.com/profile/9661.html pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ From ml at deadbabylon.de Wed Mar 21 22:43:25 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 21 Mar 2007 23:43:25 +0100 Subject: KDE-Live-CD (Round 2): testing of included packages In-Reply-To: <200703211837.07694.lightsolphoenix@gmail.com> References: <200703212232.41623.ml@deadbabylon.de> <200703211837.07694.lightsolphoenix@gmail.com> Message-ID: <200703212343.38149.ml@deadbabylon.de> Am Mi 21.M?rz 2007 schrieb Kelly: > On Wednesday, March 21, 2007 5:32 pm Sebastian Vahl wrote: > > - knetworkmanager vs. kwifimanger: I don't own a laptop. So I've not > > noticed that kwifimanager is also started automatically. Splitting of > > kdenetwork should resolve this point. > > I find, on my laptop anyway, that knetworkmanager works far better overall. > But then, it could just be me. That is what I've tried to say :) : kwifimanger will be packaged in a subpackage (kdenetwork-extras). If this is done only knetworkmanager (which is supposed to work better) is included in the livecd only. Sebastian -------------- 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 Wed Mar 21 22:45:01 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 21 Mar 2007 17:45:01 -0500 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174516294.22378.5.camel@rousalka.dyndns.org> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> <1174516294.22378.5.camel@rousalka.dyndns.org> Message-ID: <16de708d0703211545t27402418rda2a421d9fb436b5@mail.gmail.com> On 3/21/07, Nicolas Mailhot wrote: > Le mercredi 21 mars 2007 ? 20:42 +0100, Thomas M Steenholdt a ?crit : > > Alexander Bostr?m wrote: > > > > > >> Lets settle for a default configuration with a good balance between > > >> usability and security. Like perhaps disabling root login or something. > > > > > > Taking over a user account is really almost as bad as root access. The > > > typical desktop user is thoroughly screwed regardless. > > > > > > > I agree that compromising a user account is still bad. But not nearly as > > bad as root access (if one must choose), but if root access through ssh > > is disabled by default, attack scripts would have to *guess* a user to > > bruteforce and can't rely on bruteforcing "root" who exists on every > > *nix system. > > attackers *do* brute-force usernames, probably because root is usually > secured but you can hope hitting a user account with no password > > install pam_abl. It will profile the attacks for you (for exemple on my > system root is the most attacked user but this is dwarfed by one-shot > dictionary-user tries) Hence my point of havign root login off by default. -- Fedora Core 6 and proud From nicolas.mailhot at laposte.net Wed Mar 21 22:54:04 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 21 Mar 2007 23:54:04 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <16de708d0703211545t27402418rda2a421d9fb436b5@mail.gmail.com> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> <1174516294.22378.5.camel@rousalka.dyndns.org> <16de708d0703211545t27402418rda2a421d9fb436b5@mail.gmail.com> Message-ID: <1174517644.25431.10.camel@rousalka.dyndns.org> Le mercredi 21 mars 2007 ? 17:45 -0500, Arthur Pemberton a ?crit : > On 3/21/07, Nicolas Mailhot wrote: > > attackers *do* brute-force usernames, probably because root is usually > > secured but you can hope hitting a user account with no password > > > > install pam_abl. It will profile the attacks for you (for exemple on my > > system root is the most attacked user but this is dwarfed by one-shot > > dictionary-user tries) > > Hence my point of havign root login off by default. Hence my point that most attack scripts don't even care about root anymore :) Any user account will do, and they use common username databases Failed users: (1) Not blocking nim (1) Not blocking + (1) Not blocking -nim (1) Not blocking . (1) Not blocking 000 (1) Not blocking 0000 (1) Not blocking 00000 (1) ... rooms (1) Not blocking rooot (2) Not blocking roosevelt (1) Not blocking root (340) Not blocking root-admin (5) Not blocking root-oliver (3) Not blocking root1 (1) Not blocking root12 (1) Not blocking root123 (1) ... zuza123 (1) Not blocking zv (1) Not blocking zvfx (1) Not blocking zw (1) Not blocking zx (1) Not blocking zxc (1) Not blocking zxvf (3) Not blocking zy (1) Not blocking zz (1) Not blocking zzhou (1) Not blocking zzz (3) Not blocking zzzz (1) Not blocking ?dith (1) Not blocking ?liane (1) Not blocking ?lise (1) Not blocking ?loise (1) Not blocking ?milie (1) Not blocking ???root (1) Not blocking (count is usually higher, I reseted the cache recently) -- Nicolas Mailhot From d.jacobfeuerborn at conversis.de Wed Mar 21 23:16:31 2007 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Thu, 22 Mar 2007 00:16:31 +0100 Subject: No shape and sync extensions in xorg? In-Reply-To: <1174316900.10900.3.camel@localhost.localdomain> References: <45FD7A49.3000900@conversis.de> <1174316900.10900.3.camel@localhost.localdomain> Message-ID: <4601BCCF.5090607@conversis.de> Adam Jackson wrote: > On Sun, 2007-03-18 at 18:43 +0100, Dennis Jacobfeuerborn wrote: >> Hi, >> When I try to enable the desktop effects (ie. compiz) I get the following >> output: >> >> [dennis at nexus ~]$ desktop-effects >> compiz: No sync extension >> The program 'gnome-window-decorator' received an X Window System error. >> This probably reflects a bug in the program. >> The error was 'BadMatch (invalid parameter attributes)'. >> (Details: serial 426 error_code 8 request_code 72 minor_code 0) >> (Note to programmers: normally, X errors are reported asynchronously; >> that is, you will receive the error a while after causing it. >> To debug your program, run it with the --sync command line >> option to change this behavior. You can then get a meaningful >> backtrace from your debugger if you break on the gdk_x_error() function.) >> Xlib: extension "SHAPE" missing on display ":0.0". > > Your X config file has a Modules section, and it doesn't contain a line > for extmod. Things are back to normal even though the Modules section still doesn't contain a line for extmod. Also I cannot reproduce this anymore under either nv or nvidia so I'm not really sure what has caused this in the first place. The only other change I made is I removed the "irqpoll" and "crashkernel" options from the kernel. The machine was unstable but a BIOS upgrade fixed this so they were no longer necessary (kdump complained that the kernel was unsupported anyway). > You claim to be using the nv driver later in the thread, but compiz > isn't going to work with that setup, period, because we don't have a DRI > driver for nvidia cards yet. I am (was) switching between nvidia and nv in order to get beryl/compiz to work but right now I'm back to nv. I've played with that on my old box before and never got an error that these extensions are missing. The X error seems to be gnome-terminal specific and I still get this under beryl but not when I use x-term. > More likely you installed nvidia's closed > driver, and the install script for same added a Modules section that it > didn't need to. It apparently added a Modules section with a Load "glx" command but why would that stop the extmod extension from auto-loading? Regards, Dennis From pemboa at gmail.com Wed Mar 21 23:32:22 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 21 Mar 2007 18:32:22 -0500 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174517644.25431.10.camel@rousalka.dyndns.org> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> <1174516294.22378.5.camel@rousalka.dyndns.org> <16de708d0703211545t27402418rda2a421d9fb436b5@mail.gmail.com> <1174517644.25431.10.camel@rousalka.dyndns.org> Message-ID: <16de708d0703211632x7a104cd2mc1bbaefbef1173a9@mail.gmail.com> On 3/21/07, Nicolas Mailhot wrote: > Le mercredi 21 mars 2007 ? 17:45 -0500, Arthur Pemberton a ?crit : > > On 3/21/07, Nicolas Mailhot wrote: > > > > attackers *do* brute-force usernames, probably because root is usually > > > secured but you can hope hitting a user account with no password > > > > > > install pam_abl. It will profile the attacks for you (for exemple on my > > > system root is the most attacked user but this is dwarfed by one-shot > > > dictionary-user tries) > > > > Hence my point of havign root login off by default. > > Hence my point that most attack scripts don't even care about root > anymore :) Any user account will do, and they use common username > databases > Yes, but root always exists. The others are purely hit and miss -- Fedora Core 6 and proud From d.jacobfeuerborn at conversis.de Wed Mar 21 23:37:23 2007 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Thu, 22 Mar 2007 00:37:23 +0100 Subject: Xen kernel loads audio driver but misses pcm bits Message-ID: <4601C1B3.2080106@conversis.de> Hi, I have trouble with Xen and my M-Audio Audiophile 24/96 card (ice1712 based). When I boot with a regular kernel everything work fine but when I boot the Xen kernel the modules get loaded but the pcm mixer seems to be missing. Running system-config-soundcard yields the following scsrun.log: ALSA lib pcm_hw.c:1357:(_snd_pcm_hw_open) Invalid value for card aplay: main:550: audio open error: No such device cat: /etc/asound.conf: No such file or directory amixer: Mixer attach default error: No such device Running from command-line... I filed a bug here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196045 (actually I filed that bug 9 months ago but the problem still exists) Regards, Dennis From overholt at redhat.com Thu Mar 22 00:14:47 2007 From: overholt at redhat.com (Andrew Overholt) Date: Wed, 21 Mar 2007 20:14:47 -0400 Subject: SoC idea: Review Web App Message-ID: <20070322001446.GA13508@redhat.com> Hi, I put an idea on the wiki that I think would be a good SoC project: a web app for the review process. I put some ideas here: http://fedoraproject.org/wiki/FedoraBounties#head-ed0e64b4a58f80c721d31f17a049f701644ba28d Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bjohnson-dated-1172832473.ba5e95 at symetrix.com Wed Mar 21 23:00:32 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Wed, 21 Mar 2007 17:00:32 -0600 Subject: rpms/perl-Gtk2-Ex-PodViewer/FC-6 perl-Gtk2-Ex-PodViewer.spec, NONE, 1.1 In-Reply-To: <1174464624.4531.188.camel@mccallum.corsepiu.local> References: <200703210735.l2L7ZETE032589@cvs-int.fedora.redhat.com> <1174464624.4531.188.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius wrote: >> --- NEW FILE perl-Gtk2-Ex-PodViewer.spec --- >> Name: perl-Gtk2-Ex-PodViewer > >> BuildRequires: perl, perl-gettext, perl-IO-stringy, perl-Pod-Simple >> BuildRequires: perl-Gtk2 > Please don't BR: "perl-*" > > Use their perl(..) counterparts instead. Sure I can do that... Is there a packaging doc that points this out? From sundaram at fedoraproject.org Thu Mar 22 00:33:06 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 Mar 2007 06:03:06 +0530 Subject: missing FC6 system-config-control In-Reply-To: <200703211835.32055.lightsolphoenix@gmail.com> References: <200703211641.32083.lightsolphoenix@gmail.com> <4601A437.6090301@redhat.com> <200703211835.32055.lightsolphoenix@gmail.com> Message-ID: <4601CEC2.60400@fedoraproject.org> Kelly wrote: > On Wednesday, March 21, 2007 5:31 pm Warren Togami wrote: >> system-config-control was apparently a non-official, optional add-on in >> Extras. >> >> It appears to be orphaned now, meaning nobody is maintaining it, thus it >> was removed before FC6. The only way it will be in Fedora again is if >> somebody takes the steps to become the maintainer and just do the work. >> >> Warren Togami >> wtogami at redhat.com > > I'd offer to do it, but I'm not familiar with GTK+. It is very small amount of PyGTK code. http://www.indianoss.org/modules/wfdownloads/viewcat.php?cid=10 Rahul From a.badger at gmail.com Thu Mar 22 00:38:11 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 21 Mar 2007 17:38:11 -0700 Subject: SoC idea: Review Web App In-Reply-To: <20070322001446.GA13508@redhat.com> References: <20070322001446.GA13508@redhat.com> Message-ID: <1174523891.23909.12.camel@localhost.localdomain> On Wed, 2007-03-21 at 20:14 -0400, Andrew Overholt wrote: > Hi, > > I put an idea on the wiki that I think would be a good SoC project: a > web app for the review process. I put some ideas here: > > http://fedoraproject.org/wiki/FedoraBounties#head-ed0e64b4a58f80c721d31f17a049f701644ba28d We need to think about that before implementing. We definitely need to share the responsibility for mentoring such a project between some Fedora Packagers and Fedora Infrastructure people. The Packagers will know how the current system fails and a new system could improve things. Infrastructure will know about the different systems we have to tie into/replace:: PackageDB, Bugzilla, Koji-buildsys, Account system. Trying to do the whole thing as a SoC project is, I think, overzealous. I'd like to see a definition of what we want to achieve and what existing systems it will tie into. Then break the problem down into a few pieces and allow SoC to handle any of those pieces. That way, we don't end up with a working web app that doesn't interoperate with the rest of our infrastructure. -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 tonynelson at georgeanelson.com Thu Mar 22 01:27:43 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Wed, 21 Mar 2007 21:27:43 -0400 Subject: Improvement to rescue mode? In-Reply-To: References: <3da3b5b40703200549v5e0bc6adxe4c40417433aac2d@mail.gmail.com> <45FFEB72.40002@BitWagon.com> <1174423828.11172.10.camel@pensja.lam.pl> Message-ID: At 6:12 AM -0400 3/21/07, Neal Becker wrote: >Leszek Matok wrote: > >> Dnia 20-03-2007, wto o godzinie 07:10 -0700, John Reiser napisa?(a): >>> > Why don't you install grub on the broken system and boot it? >>> Because rescue mode cannot install grub via grub-install; reported as: >>> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198064 >>> The mechanism that grub-install uses to identify the "hardware" >>> is incompatible with the "virtualization" provided by chroot >>> and rescue mode. >> But it works with grub-install --root-directory, at least in F6 (fully >> updated F6 and rescue mode from the original install CD - tested >> yesterday). The chroot has problems related to mtab, which can be faked, >> but --root-directory was simpler and it works. >> >> And for the original poster: you can make a boot floppy for your system. >> I don't remember if Anaconda still has an option for it, though. >> >> Lam > >My immediate need is this. I have a system with a pair of scsi disks. It >also has 1 SATA drive. For some reason I can't understand, the SATA drive >is not seen by the BIOS, so I can't boot off it, but Fedora has no trouble >understanding that it's there and is happy to install /boot onto it. Of >course, I have no way to boot it. > >I haven't tried to make a boot floppy in years. Any hints? Probably just put the grub bootsector into a file on the floppy, similar to booting through NTLDR. -- ____________________________________________________________________ TonyN.:' ' From sundaram at fedoraproject.org Thu Mar 22 01:36:28 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 22 Mar 2007 07:06:28 +0530 Subject: rawhide report: 20070321 changes In-Reply-To: <200703210924.l2L9OU2w018732@hs20-bc2-6.build.redhat.com> References: <200703210924.l2L9OU2w018732@hs20-bc2-6.build.redhat.com> Message-ID: <4601DD9C.2080309@fedoraproject.org> buildsys at redhat.com wrote: > New package fedora-bookmarks > Fedora Core bookmarks > Good to have this split but should drop the "core" in the description. Rahul From poelstra at redhat.com Thu Mar 22 02:51:39 2007 From: poelstra at redhat.com (John Poelstra) Date: Wed, 21 Mar 2007 19:51:39 -0700 Subject: Which unresolved bugs block a release? Message-ID: <4601EF3B.2030108@redhat.com> Hi, Being somewhat new to the Fedora releases I'm looking for a better understanding of how the release process works and the methodology Fedora uses to determine when a release is ready to ship. I'd like to document this if it isn't done already. Earlier in the week this page was discussed: http://fedoraproject.org/wiki/Releases/7/MustHave I am curious how we determine which open bugs must also be fixed in order to reach GA? I would think some of these bugs are tied to the "MustHaves?" I ran a few queries and was left wondering how bugs really do play into the GA of a new release when there are so many open bugs from the previous releases and "Development." I ran a quick query of the Fedora Core and found the following number of *unresolved* bugs in the state of: "NEW" "ASSIGNED" or "MODIFIED." Product: "Fedora Core" Version: FC5T1 20 FC5T2 24 FC5T3 80 FC5GA 1,545 -------- FC5 Total 1,669 FC6T1 37 FC6T2 82 FC6T3 153 FC6GA 2,315 -------- FC6 Total 2,587 Development 2,859 ---------- Total Bugs 7,115 ========== This raised a few questions for me: 1) Is there a mechanism to know which of the bugs above must be fixed or FC7 to GA? 2) What process do we go through to close these bugs? 3) How does Fedora decide a release is ready to GA? 4) How are bugs from previous releases considered in the planning process? Thanks, John From jkeating at redhat.com Thu Mar 22 03:04:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Mar 2007 23:04:36 -0400 Subject: Which unresolved bugs block a release? In-Reply-To: <4601EF3B.2030108@redhat.com> References: <4601EF3B.2030108@redhat.com> Message-ID: <200703212304.36498.jkeating@redhat.com> On Wednesday 21 March 2007 22:51:39 John Poelstra wrote: > This raised a few questions for me: > 1) Is there a mechanism to know which of the bugs above must be fixed or > FC7 to GA? Nothing formal. As we start looking that way a few people generally shuffle through the "Blocker" list to look for actual blockers and get rid of the noise. Since there is no committee that decides what is or isn't a blocker we can't just take every bug as an actual blocker. > 2) What process do we go through to close these bugs? Really, that depends on the bug. Generally we fix it, or find a suitable work around. > 3) How does Fedora decide a release is ready to GA? Release Engineering in conjunction with QA typically come to an agreement that the tree is "good enough". Sometimes we have to kick decisions up to the board on what to do about remaining issues. > 4) How are bugs from previous releases considered in the planning process? They aren't really, officially. We try to fix the big glaring ones immediately after the release to prevent them from happening again the next time. Some previous "blockers" are moved to the next blocker set to be reviewed later. Unlike with RHEL, there is no real good management of the blocker/target bugs for Fedora. -- 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 lightsolphoenix at gmail.com Thu Mar 22 04:24:44 2007 From: lightsolphoenix at gmail.com (Kelly) Date: Thu, 22 Mar 2007 00:24:44 -0400 Subject: missing FC6 system-config-control In-Reply-To: <4601CEC2.60400@fedoraproject.org> References: <200703211835.32055.lightsolphoenix@gmail.com> <4601CEC2.60400@fedoraproject.org> Message-ID: <200703220024.45226.lightsolphoenix@gmail.com> On Wednesday, March 21, 2007 8:33 pm Rahul Sundaram wrote: > Kelly wrote: > > On Wednesday, March 21, 2007 5:31 pm Warren Togami wrote: > >> system-config-control was apparently a non-official, optional add-on in > >> Extras. > >> > >> It appears to be orphaned now, meaning nobody is maintaining it, thus it > >> was removed before FC6. The only way it will be in Fedora again is if > >> somebody takes the steps to become the maintainer and just do the work. > >> > >> Warren Togami > >> wtogami at redhat.com > > > > I'd offer to do it, but I'm not familiar with GTK+. > > It is very small amount of PyGTK code. > > http://www.indianoss.org/modules/wfdownloads/viewcat.php?cid=10 > > Rahul You're right; it's not a lot of code. I'll see what I can do with it. -- http://www.mozilla.org/products/firefox/ - Get Firefox! http://www.mozilla.org/products/thunderbird/ - Reclaim Your Inbox! Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From ankit644 at yahoo.com Thu Mar 22 04:56:17 2007 From: ankit644 at yahoo.com (Ankit Patel) Date: Wed, 21 Mar 2007 21:56:17 -0700 (PDT) Subject: missing FC6 system-config-control Message-ID: <365127.24337.qm@web55313.mail.re4.yahoo.com> ----- Original Message ---- From: Kelly To: fedora-devel-list at redhat.com Cc: Warren Togami Sent: Thursday, March 22, 2007 9:54:44 AM Subject: Re: missing FC6 system-config-control On Wednesday, March 21, 2007 8:33 pm Rahul Sundaram wrote: > Kelly wrote: > > On Wednesday, March 21, 2007 5:31 pm Warren Togami wrote: > >> system-config-control was apparently a non-official, optional add-on in > >> Extras. > >> > >> It appears to be orphaned now, meaning nobody is maintaining it, thus it > >> was removed before FC6. The only way it will be in Fedora again is if > >> somebody takes the steps to become the maintainer and just do the work. > >> > >> Warren Togami > >> wtogami at redhat.com > > > > I'd offer to do it, but I'm not familiar with GTK+. > > It is very small amount of PyGTK code. > > http://www.indianoss.org/modules/wfdownloads/viewcat.php?cid=10 > > Rahul You're right; it's not a lot of code. I'll see what I can do with it. -- Hi Guys, Apologize for not actively working on this project. I developed this tool as a part of my interest & i thought there is a really need for system-config-control. I tried to get this package included in Core during FC5, but i didn't get enough responses from people who actually wants to see this package in Fedora. So, the proposal is disapproved. Still i would like to have this package in Fedora Extras, but lack of time doesn't allow me to work continuously on this project as my field of work is different than software development. I will be really happy if somebody, who continuously work on package development, contribute to this package. By looking at the public demands, i think this package should be maintaned. Please let me know whoever is interested, i will give all the details which i have for system-cofnig-control. Thanks a lot & let me know if i can help in any way other than maintaining this package! :) Ankit Patel ____________________________________________________________________________________ Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.salim at gmail.com Thu Mar 22 05:40:31 2007 From: michel.salim at gmail.com (Michel Salim) Date: Thu, 22 Mar 2007 01:40:31 -0400 Subject: pm-utils: why not noarch? Message-ID: <883cfe6d0703212240q690b6dadh9058008479a3709d@mail.gmail.com> The latest version of pm-utils have a bug in which %{_libdir}/pm-utils/bin/pm-action, line 86, refers to: . /usr/lib/pm-utils/functions whereas the file is located in /usr/lib64 on x86_64 and other 64-bit platforms. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233404 Would it not be better to make pm-utils noarch, and put its files in /usr/lib ? Or at least, use relative paths when loading other pm-utils files. Thanks, -- Michel Salim http://hircus.wordpress.com/ My theology, briefly, is that the universe was dictated but not signed. -- Christopher Morley From buildsys at redhat.com Thu Mar 22 10:08:28 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 22 Mar 2007 06:08:28 -0400 Subject: rawhide report: 20070322 changes Message-ID: <200703221008.l2MA8S1e016243@hs20-bc2-6.build.redhat.com> Updated Packages: fedora-release-6.92-1 --------------------- * Mon Mar 19 2007 Jesse Keating - 6.92-1 - Bump for Test 3 - No more eula in fedora-release, moved to firstboot * Fri Feb 23 2007 Jesse Keating - 6.91-1 - Bump for Test 2 * Tue Feb 13 2007 Jesse Keating - 6.90-4 - Specfile cleanups firstboot-1.4.34-1.fc7 ---------------------- * Wed Mar 21 2007 Chris Lumens - 1.4.34-1 - Reword EULA module. - Fix screenshot code. * Tue Mar 20 2007 Chris Lumens - 1.4.33-1 - Don't chop off part of the left side background. - Added a new EULA module. kernel-2.6.20-1.3003.fc7 ------------------------ * Wed Mar 21 2007 Dave Jones - New version of the ondemand 'no wakeup whilst idle' patch * Tue Mar 20 2007 Dave Jones - 2.6.21-rc4-git5 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 kevin.kofler at chello.at Thu Mar 22 10:32:19 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 22 Mar 2007 10:32:19 +0000 (UTC) Subject: disabling warn_unused_result attribute with FORTIFY_SOURCE? References: <20070315023020.GA20627@jadzia.bu.edu> <45F8CC99.1000907@ioa.s.u-tokyo.ac.jp> Message-ID: Kevin Kofler chello.at> writes: > What works is: > int dummy=foo1(); > (void)dummy; > or: > static inline __attribute__((always_inline)) int ignore(int x) {return x;} > ignore(foo1()); Found another way: __builtin_expect(foo1(),0); The __builtin_expect hint is of course thrown away because the result is, but it gets rid of the warning. Kevin Kofler From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Mar 22 12:44:30 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 22 Mar 2007 13:44:30 +0100 Subject: Conflicting types from kernel-headers and glibc-headers Message-ID: <20070322134430.4be93d95@python3.es.egwn.lan> Hi, I'm not sure which package to blame about this problem, except at least keepalived itself, which wants "low level" access to kernel includes. This is the real world problem : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228544#c7 It doesn't happen on RHEL4 or FC6, only on Fedora development. Could this be some kind of de-sync between defines in the headers provided by glibc-headers and kernel-headers packages? Even after "forcing" keepalived to not go and include headers from the kernel-devel package, I still get errors like this : In file included from /usr/include/net/ethernet.h:26, from ../include/vrrp_arp.h:29, from vrrp_arp.c:29: /usr/include/sys/types.h:62: error: conflicting types for 'dev_t' /usr/include/linux/types.h:13: error: previous declaration of 'dev_t' was here /usr/include/sys/types.h:67: error: conflicting types for 'gid_t' /usr/include/linux/types.h:27: error: previous declaration of 'gid_t' was here /usr/include/sys/types.h:72: error: conflicting types for 'mode_t' /usr/include/linux/types.h:15: error: previous declaration of 'mode_t' was here /usr/include/sys/types.h:77: error: conflicting types for 'nlink_t' /usr/include/linux/types.h:16: error: previous declaration of 'nlink_t' was here /usr/include/sys/types.h:82: error: conflicting types for 'uid_t' /usr/include/linux/types.h:26: error: previous declaration of 'uid_t' was here Should I file this as a bug? If yes, against glibc or kernel? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2911.6.5.fc6 Load : 0.08 0.22 0.51 From jwboyer at jdub.homelinux.org Thu Mar 22 13:06:38 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 22 Mar 2007 08:06:38 -0500 Subject: Conflicting types from kernel-headers and glibc-headers In-Reply-To: <20070322134430.4be93d95@python3.es.egwn.lan> References: <20070322134430.4be93d95@python3.es.egwn.lan> Message-ID: <1174568798.3416.95.camel@zod.rchland.ibm.com> On Thu, 2007-03-22 at 13:44 +0100, Matthias Saou wrote: > Hi, > > I'm not sure which package to blame about this problem, except at least > keepalived itself, which wants "low level" access to kernel includes. > > This is the real world problem : > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228544#c7 > > It doesn't happen on RHEL4 or FC6, only on Fedora development. Could > this be some kind of de-sync between defines in the headers provided by > glibc-headers and kernel-headers packages? kernel-headers Obsoletes and Provides glibc-kernheaders... You shouldn't have both installed on devel. josh From vonbrand at inf.utfsm.cl Thu Mar 22 13:45:09 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 22 Mar 2007 09:45:09 -0400 Subject: Quota per directory In-Reply-To: <200703210900.46111.lamont@gurulabs.com> References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <200703210900.46111.lamont@gurulabs.com> Message-ID: <200703221345.l2MDj9Rq009937@laptop13.inf.utfsm.cl> Lamont Peterson wrote: > On Wednesday 21 March 2007 02:14am, Ahmed Kamal wrote: > > Coming from a systems administration background, I was very surprised to > > find out that fedora (well Linux actually) doesn't have a per directory > > quota. It is very common and needed IMHO to have a quota per directory, as > > the directory basically represents a project some people are working on. > > One would want to make sure that a certain project would not consume all > > disk space. Only XFS seemed to have per "project" quota (I even think the > > Linux implementation doesn't have that!) > > Linux "only" has per-filesystem quota support. You're asking for what's > called "tree quotas" support. And that is nonsense, as a file /doesn't/ exist "in a directory", the directory only holds the name and a reference to the actual file. So, a file can exist under many different names in assorted directories (hard links). How do you acount for that? Can't count it N times if there are N links, but if you count each link 1/N, deleting stuff here may get you past quota elsewhere (even other people who happen to link to the same file). Not nice. -- 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 ajackson at redhat.com Thu Mar 22 13:58:57 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 22 Mar 2007 09:58:57 -0400 Subject: No shape and sync extensions in xorg? In-Reply-To: <4601BCCF.5090607@conversis.de> References: <45FD7A49.3000900@conversis.de> <1174316900.10900.3.camel@localhost.localdomain> <4601BCCF.5090607@conversis.de> Message-ID: <1174571937.13805.12.camel@localhost.localdomain> On Thu, 2007-03-22 at 00:16 +0100, Dennis Jacobfeuerborn wrote: > Adam Jackson wrote: > > On Sun, 2007-03-18 at 18:43 +0100, Dennis Jacobfeuerborn wrote: > >> [dennis at nexus ~]$ desktop-effects > >> compiz: No sync extension > >> The program 'gnome-window-decorator' received an X Window System error. > >> This probably reflects a bug in the program. > >> The error was 'BadMatch (invalid parameter attributes)'. > >> (Details: serial 426 error_code 8 request_code 72 minor_code 0) > >> (Note to programmers: normally, X errors are reported asynchronously; > >> that is, you will receive the error a while after causing it. > >> To debug your program, run it with the --sync command line > >> option to change this behavior. You can then get a meaningful > >> backtrace from your debugger if you break on the gdk_x_error() function.) > >> Xlib: extension "SHAPE" missing on display ":0.0". > > > > Your X config file has a Modules section, and it doesn't contain a line > > for extmod. > > Things are back to normal even though the Modules section still doesn't > contain a line for extmod. Also I cannot reproduce this anymore under > either nv or nvidia so I'm not really sure what has caused this in the > first place. The only other change I made is I removed the "irqpoll" and > "crashkernel" options from the kernel. The machine was unstable but a BIOS > upgrade fixed this so they were no longer necessary (kdump complained that > the kernel was unsupported anyway). There was a cairo bug recently that may be related to the BadMatch error: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231170 But the missing shape extension would still occur if you don't have extmod loaded. > > More likely you installed nvidia's closed > > driver, and the install script for same added a Modules section that it > > didn't need to. > > It apparently added a Modules section with a Load "glx" command but why > would that stop the extmod extension from auto-loading? Because your modules section looked like: Section "Modules" Load "glx" EndSection If it were empty, or nonexistant, then we'd load the default set, which includes glx. But since it has exactly one entry, we load just the modules you ask for, and nothing else. Hence "added a Modules section that it didn't need to". GLX is in the default module set! The driver install script needs to not muck with the Modules section, period. You know, the same way none of the drivers in core touch xorg.conf. - ajax From fedora at camperquake.de Thu Mar 22 14:36:56 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 22 Mar 2007 15:36:56 +0100 Subject: rawhide report: 20070322 changes In-Reply-To: <200703221008.l2MA8S1e016243@hs20-bc2-6.build.redhat.com> References: <200703221008.l2MA8S1e016243@hs20-bc2-6.build.redhat.com> Message-ID: <20070322153656.24ec1be8@banea.int.addix.net> Hi. On Thu, 22 Mar 2007 06:08:28 -0400, buildsys at redhat.com wrote: > kernel-2.6.20-1.3003.fc7 > ------------------------ > * Wed Mar 21 2007 Dave Jones > - New version of the ondemand 'no wakeup whilst idle' patch That fixes the softlock on shutdown bug for me. From tmus at tmus.dk Thu Mar 22 14:48:56 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 22 Mar 2007 15:48:56 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <1174515589.3309.17.camel@perun.kabelta.loc> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> <1174515589.3309.17.camel@perun.kabelta.loc> Message-ID: Tomas Mraz wrote: > On Wed, 2007-03-21 at 20:42 +0100, Thomas M Steenholdt wrote: > >> I agree that compromising a user account is still bad. But not nearly as >> bad as root access (if one must choose), but if root access through ssh >> is disabled by default, attack scripts would have to *guess* a user to >> bruteforce and can't rely on bruteforcing "root" who exists on every >> *nix system. So this would allow immediate ssh access to admins (ssh as >> user and su -) to newly installed machines. Admin is free to remotely >> log in, install public keys and reconfigure sshd as he sees fit, but >> he's allowed to do it from his administrative workstation instead of the >> physical machine console. This makes a lot of sense in my world. > > Except the regular users are created in firstboot which might be > inaccessible when the system is installed remotely. > Perhaps this could be changed, if need be. /Thomas From tmus at tmus.dk Thu Mar 22 14:51:28 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 22 Mar 2007 15:51:28 +0100 Subject: SSH on by default? (Was: too many deamons by default - F7 test 2 live cd) In-Reply-To: <16de708d0703211632x7a104cd2mc1bbaefbef1173a9@mail.gmail.com> References: <45FE5D39.7020002@fedoraproject.org> <1174381904.3528.175.camel@home.alexander.bostrom.net> <1174397685.10900.15.camel@localhost.localdomain> <1174503374.3528.200.camel@home.alexander.bostrom.net> <1174516294.22378.5.camel@rousalka.dyndns.org> <16de708d0703211545t27402418rda2a421d9fb436b5@mail.gmail.com> <1174517644.25431.10.camel@rousalka.dyndns.org> <16de708d0703211632x7a104cd2mc1bbaefbef1173a9@mail.gmail.com> Message-ID: Arthur Pemberton wrote: > On 3/21/07, Nicolas Mailhot wrote: >> Le mercredi 21 mars 2007 ? 17:45 -0500, Arthur Pemberton a ?crit : >> > On 3/21/07, Nicolas Mailhot wrote: >> >> > > attackers *do* brute-force usernames, probably because root is >> usually >> > > secured but you can hope hitting a user account with no password >> > > >> > > install pam_abl. It will profile the attacks for you (for exemple >> on my >> > > system root is the most attacked user but this is dwarfed by one-shot >> > > dictionary-user tries) >> > >> > Hence my point of havign root login off by default. >> >> Hence my point that most attack scripts don't even care about root >> anymore :) Any user account will do, and they use common username >> databases >> > > Yes, but root always exists. The others are purely hit and miss > Exactly - root exists and the attackers know this. For other users, both the usernames AND their passwords will have to be bruteforced... /Thomas From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Mar 22 15:20:23 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 22 Mar 2007 16:20:23 +0100 Subject: Conflicting types from kernel-headers and glibc-headers In-Reply-To: <1174568798.3416.95.camel@zod.rchland.ibm.com> References: <20070322134430.4be93d95@python3.es.egwn.lan> <1174568798.3416.95.camel@zod.rchland.ibm.com> Message-ID: <20070322162023.44f45489@python3.es.egwn.lan> Josh Boyer wrote : > On Thu, 2007-03-22 at 13:44 +0100, Matthias Saou wrote: > > Hi, > > > > I'm not sure which package to blame about this problem, except at least > > keepalived itself, which wants "low level" access to kernel includes. > > > > This is the real world problem : > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228544#c7 > > > > It doesn't happen on RHEL4 or FC6, only on Fedora development. Could > > this be some kind of de-sync between defines in the headers provided by > > glibc-headers and kernel-headers packages? > > kernel-headers Obsoletes and Provides glibc-kernheaders... You > shouldn't have both installed on devel. Not glibc-kernheaders but glibc-headers. And glibc-headers is in devel. Fedora devel mach chroot as of today : # rpm -qf /usr/include/sys/types.h glibc-headers-2.5.90-19 # rpm -qf /usr/include/linux/types.h kernel-headers-2.6.20-1.3003.fc7 And defines from both seem to clash, on both x86 and x86_64. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2911.6.5.fc6 Load : 0.84 0.38 0.32 From email.ahmedkamal at googlemail.com Thu Mar 22 15:34:00 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 22 Mar 2007 17:34:00 +0200 Subject: Quota per directory In-Reply-To: <200703221345.l2MDj9Rq009937@laptop13.inf.utfsm.cl> References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <200703210900.46111.lamont@gurulabs.com> <200703221345.l2MDj9Rq009937@laptop13.inf.utfsm.cl> Message-ID: <3da3b5b40703220834w1d09d08exa4f859e4783bd430@mail.gmail.com> I understand hard linked files are a logical problem for applying tree quotas. However, I don't think such a problem should kill the whole implementation! I'm happy with any solution, even if counting the file multiple times was picked as the conservative solution. Who uses hard links that much anyway. I hope that's not the only thing stopping a tree quotas implementation That's the only implementation I could find, doesn't look too up2date though http://cgi.cse.unsw.edu.au/~neilb/wiki/ On 3/22/07, Horst H. von Brand wrote: > > Lamont Peterson wrote: > > On Wednesday 21 March 2007 02:14am, Ahmed Kamal wrote: > > > Coming from a systems administration background, I was very surprised > to > > > find out that fedora (well Linux actually) doesn't have a per > directory > > > quota. It is very common and needed IMHO to have a quota per > directory, as > > > the directory basically represents a project some people are working > on. > > > One would want to make sure that a certain project would not consume > all > > > disk space. Only XFS seemed to have per "project" quota (I even think > the > > > Linux implementation doesn't have that!) > > > > Linux "only" has per-filesystem quota support. You're asking for what's > > called "tree quotas" support. > > And that is nonsense, as a file /doesn't/ exist "in a directory", the > directory only holds the name and a reference to the actual file. So, a > file can exist under many different names in assorted directories (hard > links). How do you acount for that? Can't count it N times if there are N > links, but if you count each link 1/N, deleting stuff here may get you > past > quota elsewhere (even other people who happen to link to the same file). > Not nice. > -- > 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 > > -- > 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 d.jacobfeuerborn at conversis.de Thu Mar 22 15:21:20 2007 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Thu, 22 Mar 2007 16:21:20 +0100 Subject: No shape and sync extensions in xorg? In-Reply-To: <1174571937.13805.12.camel@localhost.localdomain> References: <45FD7A49.3000900@conversis.de> <1174316900.10900.3.camel@localhost.localdomain> <4601BCCF.5090607@conversis.de> <1174571937.13805.12.camel@localhost.localdomain> Message-ID: <46029EF0.9070000@conversis.de> Adam Jackson wrote: >> It apparently added a Modules section with a Load "glx" command but why >> would that stop the extmod extension from auto-loading? > > Because your modules section looked like: > > Section "Modules" > Load "glx" > EndSection > > If it were empty, or nonexistant, then we'd load the default set, which > includes glx. But since it has exactly one entry, we load just the > modules you ask for, and nothing else. > > Hence "added a Modules section that it didn't need to". GLX is in the > default module set! The driver install script needs to not muck with > the Modules section, period. You know, the same way none of the drivers > in core touch xorg.conf. The way to determine when to load the default set doesn't look very intuitive to me. I think it would be better to make it behave like this: If a Modules section is present (even an empty one) only load the modules in that section (even if that means loading none). If no Modules section is present load the default set. Since in the presence of an empty Modules section the default set was still loaded I assumed that adding a 'Load "XYZ "'would merely add that module to the list of modules to load and not actually disable the defaults. That's why I was wondering what was going on. Regards, Dennis From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Mar 22 15:45:35 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 22 Mar 2007 16:45:35 +0100 Subject: Conflicting types from kernel-headers and glibc-headers In-Reply-To: <20070322162023.44f45489@python3.es.egwn.lan> References: <20070322134430.4be93d95@python3.es.egwn.lan> <1174568798.3416.95.camel@zod.rchland.ibm.com> <20070322162023.44f45489@python3.es.egwn.lan> Message-ID: <20070322164535.6245c875@python3.es.egwn.lan> Matthias Saou wrote : > > kernel-headers Obsoletes and Provides glibc-kernheaders... You > > shouldn't have both installed on devel. > > Not glibc-kernheaders but glibc-headers. And glibc-headers is in devel. > > Fedora devel mach chroot as of today : > > # rpm -qf /usr/include/sys/types.h > glibc-headers-2.5.90-19 > # rpm -qf /usr/include/linux/types.h > kernel-headers-2.6.20-1.3003.fc7 > > And defines from both seem to clash, on both x86 and x86_64. Actually... never mind all this, David Woodhouse seems to have found the problem : Simply including a system header _after_ the local ones in one of keepalived's files makes everything work. Many thanks to him! ;-) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228544#c8 Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.19-1.2911.6.5.fc6 Load : 0.56 0.60 0.50 From cmadams at hiwaay.net Thu Mar 22 16:04:50 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 22 Mar 2007 11:04:50 -0500 Subject: Quota per directory In-Reply-To: <3da3b5b40703220834w1d09d08exa4f859e4783bd430@mail.gmail.com> References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <200703210900.46111.lamont@gurulabs.com> <200703221345.l2MDj9Rq009937@laptop13.inf.utfsm.cl> <3da3b5b40703220834w1d09d08exa4f859e4783bd430@mail.gmail.com> Message-ID: <20070322160450.GD1283213@hiwaay.net> Once upon a time, Ahmed Kamal said: > I understand hard linked files are a logical problem for applying tree > quotas. However, I don't think such a problem should kill the whole > implementation! I'm happy with any solution, even if counting the file > multiple times was picked as the conservative solution. Who uses hard links > that much anyway. I hope that's not the only thing stopping a tree quotas > implementation What OS do you have that has quotas on anything other than the filesystem? I don't see such on Tru64 5.1B or Solaris 9. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From obi at unixkiste.org Thu Mar 22 16:08:24 2007 From: obi at unixkiste.org (Stefan Held) Date: Thu, 22 Mar 2007 17:08:24 +0100 Subject: Quota per directory In-Reply-To: <20070322160450.GD1283213@hiwaay.net> References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <200703210900.46111.lamont@gurulabs.com> <200703221345.l2MDj9Rq009937@laptop13.inf.utfsm.cl> <3da3b5b40703220834w1d09d08exa4f859e4783bd430@mail.gmail.com> <20070322160450.GD1283213@hiwaay.net> Message-ID: <1174579704.5803.2.camel@shnb> Am Donnerstag, den 22.03.2007, 11:04 -0500 schrieb Chris Adams: > What OS do you have that has quotas on anything other than the > filesystem? I don't see such on Tru64 5.1B or Solaris 9. ZFS, W2k3 R2, Netware 5.1, Netware 6 and so on. -- Stefan Held VI has only 2 Modes: obi unixkiste 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.$/' --------------------------------------------------------------------------- GPG-Keyprint = EAF2 6A65 D102 F2DB 4970 2A67 455B 98F2 572C 3FA9 From email.ahmedkamal at googlemail.com Thu Mar 22 16:13:51 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 22 Mar 2007 18:13:51 +0200 Subject: Quota per directory In-Reply-To: <1174579704.5803.2.camel@shnb> References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <200703210900.46111.lamont@gurulabs.com> <200703221345.l2MDj9Rq009937@laptop13.inf.utfsm.cl> <3da3b5b40703220834w1d09d08exa4f859e4783bd430@mail.gmail.com> <20070322160450.GD1283213@hiwaay.net> <1174579704.5803.2.camel@shnb> Message-ID: <3da3b5b40703220913w72e817f2q738f58fb6eef2130@mail.gmail.com> and HPUX xfs oh, didn't know even Windows' got that now /me envies zfs On 3/22/07, Stefan Held wrote: > > Am Donnerstag, den 22.03.2007, 11:04 -0500 schrieb Chris Adams: > > > What OS do you have that has quotas on anything other than the > > filesystem? I don't see such on Tru64 5.1B or Solaris 9. > > ZFS, W2k3 R2, Netware 5.1, Netware 6 and so on. > > -- > > Stefan Held VI has only 2 Modes: > obi unixkiste 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.$/' > > --------------------------------------------------------------------------- > GPG-Keyprint = EAF2 6A65 D102 F2DB 4970 2A67 455B 98F2 572C 3FA9 > > -- > 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 oisin.feeley at gmail.com Thu Mar 22 16:15:33 2007 From: oisin.feeley at gmail.com (Oisin Feeley) Date: Thu, 22 Mar 2007 12:15:33 -0400 Subject: Quota per directory In-Reply-To: <200703210900.46111.lamont@gurulabs.com> References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <200703210900.46111.lamont@gurulabs.com> Message-ID: On 3/21/07, Lamont Peterson wrote: > On Wednesday 21 March 2007 02:14am, Ahmed Kamal wrote: > > Coming from a systems administration background, I was very surprised to > > find out that fedora (well Linux actually) doesn't have a per directory > > quota. It is very common and needed IMHO to have a quota per directory, as > > the directory basically represents a project some people are working on. > > One would want to make sure that a certain project would not consume all > > disk space. Only XFS seemed to have per "project" quota (I even think the > > Linux implementation doesn't have that!) > > Linux "only" has per-filesystem quota support. You're asking for what's > called "tree quotas" support. What would be wrong with the OP using LVM to set up defined logical volumes per project? The quota is then enforced, it sits on top of standard ext3 and provides the possibility of expanding/changing the quotas in the future while bypassing the need to do the tree-quota stuff. Oisin From poelstra at redhat.com Thu Mar 22 16:29:42 2007 From: poelstra at redhat.com (John Poelstra) Date: Thu, 22 Mar 2007 09:29:42 -0700 Subject: Which unresolved bugs block a release? In-Reply-To: <200703212304.36498.jkeating@redhat.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> Message-ID: <4602AEF6.9000307@redhat.com> Jesse Keating said the following on 03/21/2007 08:04 PM Pacific Time: > On Wednesday 21 March 2007 22:51:39 John Poelstra wrote: >> 4) How are bugs from previous releases considered in the planning process? > > They aren't really, officially. We try to fix the big glaring ones > immediately after the release to prevent them from happening again the next > time. Some previous "blockers" are moved to the next blocker set to be > reviewed later. > > Unlike with RHEL, there is no real good management of the blocker/target bugs > for Fedora. > > Has the project discussed or determined how we will: 1) Close out the approximately 7,000+ open bugs? 2) Handle future releases in a way that the backlog doesn't get so high? Having tried to report more bugs myself recently, I wondered to myself if some people are not motivated to file bugs because they have the perception that nothing happens when they do? Naturally I'm not trying to increase the *quantity* of open bugs we have, but I wonder if with more volume we would see higher *quality* issues? Perhaps a better question to ask is if other bug reporters have the feeling that bugs they file will be addressed in one way or another (acknowledged, fixed, CLOSED_WONT_FIX, etc.)? Not wanting to place too much weight on a "number"... 7,000+ bugs jumped out at me as possibly raising this question, but I'd love to hear what other people think. I readily acknowledge that the manpower needed to address these bugs is a completely different (complex) matter and maybe it has already been discussed (thus questions #1 and #2 above). Thanks, John From drago01 at gmail.com Thu Mar 22 16:11:30 2007 From: drago01 at gmail.com (dragoran) Date: Thu, 22 Mar 2007 17:11:30 +0100 Subject: Quota per directory In-Reply-To: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> Message-ID: <4602AAB2.4070304@gmail.com> create a image with your maximum size; format it with ext2/3 and loopback mount it in this directory (should work just fine despite being a "hack") From email.ahmedkamal at googlemail.com Thu Mar 22 16:42:39 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 22 Mar 2007 18:42:39 +0200 Subject: Quota per directory In-Reply-To: <4602AAB2.4070304@gmail.com> References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <4602AAB2.4070304@gmail.com> Message-ID: <3da3b5b40703220942n52175245sd2ca25ec2935986f@mail.gmail.com> replacing each directory with a volume looks like a management nightmare!! What happens after a power failure! I fsck 100 volumes?! On 3/22/07, dragoran wrote: > > create a image with your maximum size; format it with ext2/3 and > loopback mount it in this directory (should work just fine despite being > a "hack") > > -- > 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 ssorce at redhat.com Thu Mar 22 17:01:46 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 22 Mar 2007 13:01:46 -0400 Subject: Quota per directory In-Reply-To: References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <200703210900.46111.lamont@gurulabs.com> Message-ID: <1174582906.16983.90.camel@willson> On Thu, 2007-03-22 at 12:15 -0400, Oisin Feeley wrote: > On 3/21/07, Lamont Peterson wrote: > > On Wednesday 21 March 2007 02:14am, Ahmed Kamal wrote: > > > Coming from a systems administration background, I was very surprised to > > > find out that fedora (well Linux actually) doesn't have a per directory > > > quota. It is very common and needed IMHO to have a quota per directory, as > > > the directory basically represents a project some people are working on. > > > One would want to make sure that a certain project would not consume all > > > disk space. Only XFS seemed to have per "project" quota (I even think the > > > Linux implementation doesn't have that!) > > > > Linux "only" has per-filesystem quota support. You're asking for what's > > called "tree quotas" support. > > What would be wrong with the OP using LVM to set up defined logical > volumes per project? The quota is then enforced, it sits on top of > standard ext3 and provides the possibility of expanding/changing the > quotas in the future while bypassing the need to do the tree-quota > stuff. projects: a, b, c if ((quota(a) + quota(b) + quota(c)) < totaldiskspace) { broken(idea); exit; } :-) Also broken if you have > 10-20 projects, becomes unmanageable. But there is another possible way, use ACLs, and set by default the group owner of all files under the project head directory to a specific group matched to the project (you want to do that anyway to give rw to the group), then set a group quotas. Simo. From ajackson at redhat.com Thu Mar 22 16:48:46 2007 From: ajackson at redhat.com (Adam Jackson) Date: Thu, 22 Mar 2007 12:48:46 -0400 Subject: Quota per directory In-Reply-To: <3da3b5b40703220942n52175245sd2ca25ec2935986f@mail.gmail.com> References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <4602AAB2.4070304@gmail.com> <3da3b5b40703220942n52175245sd2ca25ec2935986f@mail.gmail.com> Message-ID: <1174582126.13805.71.camel@localhost.localdomain> On Thu, 2007-03-22 at 18:42 +0200, Ahmed Kamal wrote: > replacing each directory with a volume looks like a management > nightmare!! What happens after a power failure! I fsck 100 volumes?! If you're worried about what happens after power failure, you have two problems. - ajax From wwoods at redhat.com Thu Mar 22 17:10:57 2007 From: wwoods at redhat.com (Will Woods) Date: Thu, 22 Mar 2007 13:10:57 -0400 Subject: Which unresolved bugs block a release? In-Reply-To: <200703212304.36498.jkeating@redhat.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> Message-ID: <1174583457.17842.8.camel@metroid.rdu.redhat.com> On Wed, 2007-03-21 at 23:04 -0400, Jesse Keating wrote: > On Wednesday 21 March 2007 22:51:39 John Poelstra wrote: > > This raised a few questions for me: > > 1) Is there a mechanism to know which of the bugs above must be fixed or > > FC7 to GA? > > Nothing formal. As we start looking that way a few people generally shuffle > through the "Blocker" list to look for actual blockers and get rid of the > noise. Since there is no committee that decides what is or isn't a blocker > we can't just take every bug as an actual blocker. We do actually have some guidelines for this: http://fedoraproject.org/wiki/QA/ReleaseCriteria Comments and suggestions gratefully accepted. > > 2) What process do we go through to close these bugs? > > Really, that depends on the bug. Generally we fix it, or find a suitable work > around. > > > 3) How does Fedora decide a release is ready to GA? > > Release Engineering in conjunction with QA typically come to an agreement that > the tree is "good enough". Sometimes we have to kick decisions up to the > board on what to do about remaining issues. Again, see the Release Criteria, and also the Tree Testing matrix: http://fedoraproject.org/wiki/QA/TreeTestingTemplate > > 4) How are bugs from previous releases considered in the planning process? > > They aren't really, officially. We try to fix the big glaring ones > immediately after the release to prevent them from happening again the next > time. Some previous "blockers" are moved to the next blocker set to be > reviewed later. > > Unlike with RHEL, there is no real good management of the blocker/target bugs > for Fedora. The Release Criteria should help with this, but it would be good to have slightly more work done on tracking bugs so we can do metrics and figure out some guesses on how much we can actually handle in a given release. I say "slightly more work" but there's actually a whole load of stuff that would be required there: triaging, mass-moving bugs at release time, gathering bug stats, helping enforce proper bug state changes, etc. If someone wants to be the official BugzillaKeeper, I'm sure we've all got ideas on where that person could start. -w -------------- 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 jkeating at redhat.com Thu Mar 22 17:10:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 22 Mar 2007 13:10:33 -0400 Subject: Which unresolved bugs block a release? In-Reply-To: <4602AEF6.9000307@redhat.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> Message-ID: <200703221310.33829.jkeating@redhat.com> On Thursday 22 March 2007 12:29:42 John Poelstra wrote: > Has the project discussed or determined how we will: > 1) Close out the approximately 7,000+ open bugs? > 2) Handle future releases in a way that the backlog doesn't get so high? Do you have any ideas? You're part of the projet. -- 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 ssorce at redhat.com Thu Mar 22 17:14:25 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 22 Mar 2007 13:14:25 -0400 Subject: Quota per directory In-Reply-To: <1174582906.16983.90.camel@willson> References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <200703210900.46111.lamont@gurulabs.com> <1174582906.16983.90.camel@willson> Message-ID: <1174583665.16983.92.camel@willson> On Thu, 2007-03-22 at 13:01 -0400, Simo Sorce wrote: > projects: a, b, c > > if ((quota(a) + quota(b) + quota(c)) < totaldiskspace) { that was a '>' of course not a '<' :-( > broken(idea); > exit; > } > > :-) > > Also broken if you have > 10-20 projects, becomes unmanageable. > > > But there is another possible way, use ACLs, and set by default the > group owner of all files under the project head directory to a specific > group matched to the project (you want to do that anyway to give rw to > the group), then set a group quotas. > > > Simo. > From oisin.feeley at gmail.com Thu Mar 22 17:23:56 2007 From: oisin.feeley at gmail.com (Oisin Feeley) Date: Thu, 22 Mar 2007 13:23:56 -0400 Subject: Quota per directory In-Reply-To: <1174583665.16983.92.camel@willson> References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <200703210900.46111.lamont@gurulabs.com> <1174582906.16983.90.camel@willson> <1174583665.16983.92.camel@willson> Message-ID: On 3/22/07, Simo Sorce wrote: [snip condition which must be true for any quota scheme ;)] > > Also broken if you have > 10-20 projects, becomes unmanageable. Unmanageable because of the claimed fsck speed issue mentioned by the OP or unmanageable because the admin would have to keep track of his large number of logical volumes? Just creating the LVs would be simple enough and the preparation of figuring out what size is the maxsize for each project would have to be done regardless of quota scheme. Oisin Feeley From overholt at redhat.com Thu Mar 22 17:36:24 2007 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 22 Mar 2007 13:36:24 -0400 Subject: SoC idea: Review Web App In-Reply-To: <1174523891.23909.12.camel@localhost.localdomain> References: <20070322001446.GA13508@redhat.com> <1174523891.23909.12.camel@localhost.localdomain> Message-ID: <20070322173624.GI1511@redhat.com> * Toshio Kuratomi [2007-03-21 20:38]: > > Trying to do the whole thing as a SoC project is, I think, overzealous. > I'd like to see a definition of what we want to achieve and what > existing systems it will tie into. I was envisioning just the review process itself for a SoC project. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From j.w.r.degoede at hhs.nl Thu Mar 22 18:00:53 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 22 Mar 2007 19:00:53 +0100 Subject: Which unresolved bugs block a release? In-Reply-To: <200703221310.33829.jkeating@redhat.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> Message-ID: <4602C455.8030602@hhs.nl> Jesse Keating wrote: > On Thursday 22 March 2007 12:29:42 John Poelstra wrote: >> Has the project discussed or determined how we will: >> 1) Close out the approximately 7,000+ open bugs? >> 2) Handle future releases in a way that the backlog doesn't get so high? > > Do you have any ideas? You're part of the projet. > > This is something which has amazed / annoyed me too, I've tried several times to start a community effort to something about this metric, but sofar with little success. These bugs fall into 2 categories: 1) Bugs which are simply being ignored by @redhat.com people who need to be hit with the cluebat (repeatedly) 2) Really really hard bugs (think xorg / kernel / hal /mkinitrd) Most likely a lot of 1) bugs are already solved but never got closed / retested, others should be taken upstream (and thus closed in Fedora BZ), etc. /me thinks we really should do something about the category 1 bugs.... Regards, Hans From jsacco at gnome.org Thu Mar 22 18:03:24 2007 From: jsacco at gnome.org (Joseph Sacco) Date: Thu, 22 Mar 2007 14:03:24 -0400 Subject: Problems setting up IP_MASQUERADE: take #2 Message-ID: <1174586604.3243.34.camel@rt.jesacco.com> I am experiencing some module loading weirdness with the 2.6.21.x series kernels [Fedora/rawhide] that I do not see with the 2.x.(19|20).x kernels in FC6. FC6 ---- * reboot the system * login /start the desktop * launch Mac-On-Linux ==> all is well... Mac-On-Linux is a Linux/PPC program that virtualizes MacOS or MacOSX in Linux. MOL uses an IP tunnel to establish communications between the Linux host and the virtualized MAC operating system. When MOL is launched the following kernel modules are loaded: Module Size Used by xt_tcpudp 3424 2 ipt_MASQUERADE 4096 1 iptable_nat 8388 1 nf_nat 20500 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 13448 2 iptable_nat nf_conntrack 72968 4 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4 nfnetlink 8344 3 nf_nat,nf_conntrack_ipv4,nf_conntrack ip_tables 14900 1 iptable_nat x_tables 18372 4 xt_tcpudp,ipt_MASQUERADE,iptable_nat,ip_tables tun 13728 1 mol 59304 1 Fedora/Rawhide -------------- * reboot the system * login /start the desktop * launch Mac-On-Linux ==> networking is borked. An examination of the output from 'lsmod' shows some modules did not load: Module Size Used by nf_nat 20660 0 nf_conntrack_ipv4 13448 1 nf_conntrack 73408 2 nf_nat,nf_conntrack_ipv4 nfnetlink 8344 3 nf_nat,nf_conntrack_ipv4,nf_conntrack ip_tables 14900 0 x_tables 18404 1 ip_tables tun 13504 1 mol 59304 1 * exit Mac-On-Linux * launch Mac-on-Linux ==> all is now well. An examination of the output from 'lsmod' shows the missing modules have magically appeared: Module Size Used by xt_tcpudp 3424 2 ipt_MASQUERADE 4096 1 iptable_nat 8452 1 nf_nat 20660 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 13448 2 iptable_nat nf_conntrack 73408 4 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4 nfnetlink 8344 3 nf_nat,nf_conntrack_ipv4,nf_conntrack ip_tables 14900 1 iptable_nat x_tables 18404 4 xt_tcpudp,ipt_MASQUERADE,iptable_nat,ip_tables tun 13504 1 mol 59304 1 Looks like something has changed in the 2.6.21.x kernels that effects how IP_MASQUERADE is set up. Thoughts??? -Joseph -- jsacco [at] gnome [dot] org From jwboyer at jdub.homelinux.org Thu Mar 22 18:07:00 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 22 Mar 2007 13:07:00 -0500 Subject: Which unresolved bugs block a release? In-Reply-To: <4602C455.8030602@hhs.nl> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602C455.8030602@hhs.nl> Message-ID: <1174586820.3518.12.camel@zod.rchland.ibm.com> On Thu, 2007-03-22 at 19:00 +0100, Hans de Goede wrote: > Jesse Keating wrote: > > On Thursday 22 March 2007 12:29:42 John Poelstra wrote: > >> Has the project discussed or determined how we will: > >> 1) Close out the approximately 7,000+ open bugs? > >> 2) Handle future releases in a way that the backlog doesn't get so high? > > > > Do you have any ideas? You're part of the projet. > > > > > > This is something which has amazed / annoyed me too, I've tried several times > to start a community effort to something about this metric, but sofar with > little success. > > These bugs fall into 2 categories: > 1) Bugs which are simply being ignored by @redhat.com people who need to be hit > with the cluebat (repeatedly) Don't make statements like that. They aren't helpful in any manner. You cannot claim that they are intentionally ignoring them. Hitting people with the "update your bugs" cluebat that have a massive amount of bugs simply does not work and does not help solve the problem. > 2) Really really hard bugs (think xorg / kernel / hal /mkinitrd) > > Most likely a lot of 1) bugs are already solved but never got closed / > retested, others should be taken upstream (and thus closed in Fedora BZ), etc. If a lot of 1) bugs are already solved, anyone within the 'fedorabugs' group can act as a proxy to close them out. Team effort would be a very good thing I think. josh From j.w.r.degoede at hhs.nl Thu Mar 22 18:16:06 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 22 Mar 2007 19:16:06 +0100 Subject: Which unresolved bugs block a release? In-Reply-To: <1174586820.3518.12.camel@zod.rchland.ibm.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602C455.8030602@hhs.nl> <1174586820.3518.12.camel@zod.rchland.ibm.com> Message-ID: <4602C7E6.9000907@hhs.nl> Josh Boyer wrote: > On Thu, 2007-03-22 at 19:00 +0100, Hans de Goede wrote: >> Jesse Keating wrote: >>> On Thursday 22 March 2007 12:29:42 John Poelstra wrote: >>>> Has the project discussed or determined how we will: >>>> 1) Close out the approximately 7,000+ open bugs? >>>> 2) Handle future releases in a way that the backlog doesn't get so high? >>> Do you have any ideas? You're part of the projet. >>> >>> >> This is something which has amazed / annoyed me too, I've tried several times >> to start a community effort to something about this metric, but sofar with >> little success. >> >> These bugs fall into 2 categories: >> 1) Bugs which are simply being ignored by @redhat.com people who need to be hit >> with the cluebat (repeatedly) > > Don't make statements like that. They aren't helpful in any manner. > You cannot claim that they are intentionally ignoring them. Hitting > people with the "update your bugs" cluebat that have a massive amount of > bugs simply does not work and does not help solve the problem. > >> 2) Really really hard bugs (think xorg / kernel / hal /mkinitrd) I have a different opinion and experience on this, I deliberately created 2 categories. The people with lots of bugs generally have bugs that fall into category 2 and despite the large number of these bugs they have, they respond more often to bugs of mine then people with packages with mainly category 1 bugs. Wether you like it or not, there are some people both in FC and FE, who do a bad job of responding to bugs. This is something which needs to be addressed, covering this with the blanket of love is not going to help! >> >> Most likely a lot of 1) bugs are already solved but never got closed / >> retested, others should be taken upstream (and thus closed in Fedora BZ), etc. > > If a lot of 1) bugs are already solved, anyone within the 'fedorabugs' > group can act as a proxy to close them out. Team effort would be a very > good thing I think. > Agreed, as said I've tried to start a team / group effort on this already several times, do you want to try this one more time together with me? Maybe with combined forces we have more luck. Regards, Hans From wwoods at redhat.com Thu Mar 22 18:23:19 2007 From: wwoods at redhat.com (Will Woods) Date: Thu, 22 Mar 2007 14:23:19 -0400 Subject: Which unresolved bugs block a release? In-Reply-To: <1174586820.3518.12.camel@zod.rchland.ibm.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602C455.8030602@hhs.nl> <1174586820.3518.12.camel@zod.rchland.ibm.com> Message-ID: <1174587799.17842.17.camel@metroid.rdu.redhat.com> On Thu, 2007-03-22 at 13:07 -0500, Josh Boyer wrote: > On Thu, 2007-03-22 at 19:00 +0100, Hans de Goede wrote: > > > > This is something which has amazed / annoyed me too, I've tried several times > > to start a community effort to something about this metric, but sofar with > > little success. > > > > These bugs fall into 2 categories: > > 1) Bugs which are simply being ignored by @redhat.com people who need to be hit > > with the cluebat (repeatedly) Hey now. We're really, really, really busy sometimes *coughRHEL5cough*. Be nice. > > Most likely a lot of 1) bugs are already solved but never got closed / > > retested, others should be taken upstream (and thus closed in Fedora BZ), etc. > > If a lot of 1) bugs are already solved, anyone within the 'fedorabugs' > group can act as a proxy to close them out. Team effort would be a very > good thing I think. Well then - let's start friday Bug Days again. This friday (and possibly next friday) we can try to work through the FC5 and FC6 test release bugs. It's only 380 bugs! Here's the link: http://rdr.to/W8 That's (currently) 460 ASSIGNED, MODIFIED, NEEDINFO and NEW bugs against all the FC5 and FC6 test releases. Next week: FC5, or FC6? This might be a good time to mention the recently-created fedora-qa-list: http://www.redhat.com/mailman/listinfo/fedora-qa-list Further discussion of this topic should go there. -w -------------- 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 j.w.r.degoede at hhs.nl Thu Mar 22 19:10:11 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 22 Mar 2007 20:10:11 +0100 Subject: Which unresolved bugs block a release? In-Reply-To: <1174587799.17842.17.camel@metroid.rdu.redhat.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602C455.8030602@hhs.nl> <1174586820.3518.12.camel@zod.rchland.ibm.com> <1174587799.17842.17.camel@metroid.rdu.redhat.com> Message-ID: <4602D493.7090205@hhs.nl> Will Woods wrote: > On Thu, 2007-03-22 at 13:07 -0500, Josh Boyer wrote: >> On Thu, 2007-03-22 at 19:00 +0100, Hans de Goede wrote: >>> This is something which has amazed / annoyed me too, I've tried several times >>> to start a community effort to something about this metric, but sofar with >>> little success. >>> >>> These bugs fall into 2 categories: >>> 1) Bugs which are simply being ignored by @redhat.com people who need to be hit >>> with the cluebat (repeatedly) > > Hey now. We're really, really, really busy sometimes *coughRHEL5cough*. > Be nice. > >>> Most likely a lot of 1) bugs are already solved but never got closed / >>> retested, others should be taken upstream (and thus closed in Fedora BZ), etc. >> If a lot of 1) bugs are already solved, anyone within the 'fedorabugs' >> group can act as a proxy to close them out. Team effort would be a very >> good thing I think. > > Well then - let's start friday Bug Days again. This friday (and possibly > next friday) we can try to work through the FC5 and FC6 test release > bugs. It's only 380 bugs! Here's the link: > > http://rdr.to/W8 > > That's (currently) 460 ASSIGNED, MODIFIED, NEEDINFO and NEW bugs against > all the FC5 and FC6 test releases. > > Next week: FC5, or FC6? > > This might be a good time to mention the recently-created > fedora-qa-list: > http://www.redhat.com/mailman/listinfo/fedora-qa-list > > Further discussion of this topic should go there. > Sounds like a plan to me (friday bugs day) but may I suggest starting with F7 test bugs so that we can get F7 in as good a shape as possible before release. Regards, Hans From davej at redhat.com Thu Mar 22 18:53:12 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 22 Mar 2007 14:53:12 -0400 Subject: rawhide report: 20070322 changes In-Reply-To: <20070322153656.24ec1be8@banea.int.addix.net> References: <200703221008.l2MA8S1e016243@hs20-bc2-6.build.redhat.com> <20070322153656.24ec1be8@banea.int.addix.net> Message-ID: <20070322185312.GD27202@redhat.com> On Thu, Mar 22, 2007 at 03:36:56PM +0100, Ralf Ertzinger wrote: > Hi. > > On Thu, 22 Mar 2007 06:08:28 -0400, buildsys at redhat.com wrote: > > > kernel-2.6.20-1.3003.fc7 > > ------------------------ > > * Wed Mar 21 2007 Dave Jones > > - New version of the ondemand 'no wakeup whilst idle' patch > > That fixes the softlock on shutdown bug for me. Still not quite right though, it continues to be tweaked upstream. I'll drop in newer variants as they appear (This is probably .22 stuff) Dave -- http://www.codemonkey.org.uk From wwoods at redhat.com Thu Mar 22 19:04:08 2007 From: wwoods at redhat.com (Will Woods) Date: Thu, 22 Mar 2007 15:04:08 -0400 Subject: Which unresolved bugs block a release? In-Reply-To: <4602D493.7090205@hhs.nl> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602C455.8030602@hhs.nl> <1174586820.3518.12.camel@zod.rchland.ibm.com> <1174587799.17842.17.camel@metroid.rdu.redhat.com> <4602D493.7090205@hhs.nl> Message-ID: <1174590248.17842.29.camel@metroid.rdu.redhat.com> On Thu, 2007-03-22 at 20:10 +0100, Hans de Goede wrote: > > Will Woods wrote: > > Well then - let's start friday Bug Days again. This friday (and possibly > > next friday) we can try to work through the FC5 and FC6 test release > > bugs. It's only 380 bugs! Here's the link: > > > > http://rdr.to/W8 > > > > That's (currently) 460 ASSIGNED, MODIFIED, NEEDINFO and NEW bugs against > > all the FC5 and FC6 test releases. > > > > Next week: FC5, or FC6? > > > > This might be a good time to mention the recently-created > > fedora-qa-list: > > http://www.redhat.com/mailman/listinfo/fedora-qa-list > > > > Further discussion of this topic should go there. > > > > Sounds like a plan to me (friday bugs day) but may I suggest starting with F7 > test bugs so that we can get F7 in as good a shape as possible before release. F7 bugs on Friday? Isn't that what the other 6 days a week are for? Besides, we don't have F7 test releases in bugzilla - it's all just under 'devel' (i.e. rawhide). For reference, here's the link for "rawhide bugs active this week": http://rdr.to/W9 -w -------------- 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 kevin at scrye.com Thu Mar 22 19:06:41 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Thu, 22 Mar 2007 13:06:41 -0600 Subject: Which unresolved bugs block a release? In-Reply-To: <1174587799.17842.17.camel@metroid.rdu.redhat.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602C455.8030602@hhs.nl> <1174586820.3518.12.camel@zod.rchland.ibm.com> <1174587799.17842.17.camel@metroid.rdu.redhat.com> Message-ID: <20070322130641.78095a25@ghistelwchlohm.scrye.com> On Thu, 22 Mar 2007 14:23:19 -0400 wwoods at redhat.com (Will Woods) wrote: > On Thu, 2007-03-22 at 13:07 -0500, Josh Boyer wrote: > > On Thu, 2007-03-22 at 19:00 +0100, Hans de Goede wrote: ...snipp... > > > Most likely a lot of 1) bugs are already solved but never got > > > closed / retested, others should be taken upstream (and thus > > > closed in Fedora BZ), etc. > > > > If a lot of 1) bugs are already solved, anyone within the > > 'fedorabugs' group can act as a proxy to close them out. Team > > effort would be a very good thing I think. > > Well then - let's start friday Bug Days again. This friday (and > possibly next friday) we can try to work through the FC5 and FC6 test > release bugs. It's only 380 bugs! Here's the link: > > http://rdr.to/W8 > > That's (currently) 460 ASSIGNED, MODIFIED, NEEDINFO and NEW bugs > against all the FC5 and FC6 test releases. Sounds like a good idea to me. I would be happy to help. What time? Coordinate on #fedora-devel irc? Is there more info for people who would like to help? > Next week: FC5, or FC6? Possibly. ;) If this is a weekly thing I would also like to see trying to help out some of the packages that just have way too many bugs for any single mantainer to deal with... rpm, kernel, etc. > This might be a good time to mention the recently-created > fedora-qa-list: > http://www.redhat.com/mailman/listinfo/fedora-qa-list Another list? :( Is that really needed? or couldn't discussions take place here? > Further discussion of this topic should go there. ok. I will after this I suppose. > -w kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wwoods at redhat.com Thu Mar 22 19:14:51 2007 From: wwoods at redhat.com (Will Woods) Date: Thu, 22 Mar 2007 15:14:51 -0400 Subject: Which unresolved bugs block a release? In-Reply-To: <20070322130641.78095a25@ghistelwchlohm.scrye.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602C455.8030602@hhs.nl> <1174586820.3518.12.camel@zod.rchland.ibm.com> <1174587799.17842.17.camel@metroid.rdu.redhat.com> <20070322130641.78095a25@ghistelwchlohm.scrye.com> Message-ID: <1174590891.17842.34.camel@metroid.rdu.redhat.com> On Thu, 2007-03-22 at 13:06 -0600, Kevin Fenzi wrote: > On Thu, 22 Mar 2007 14:23:19 -0400 > wwoods at redhat.com (Will Woods) wrote: > > > On Thu, 2007-03-22 at 13:07 -0500, Josh Boyer wrote: > > > On Thu, 2007-03-22 at 19:00 +0100, Hans de Goede wrote: > > ...snipp... > > > > > Most likely a lot of 1) bugs are already solved but never got > > > > closed / retested, others should be taken upstream (and thus > > > > closed in Fedora BZ), etc. > > > > > > If a lot of 1) bugs are already solved, anyone within the > > > 'fedorabugs' group can act as a proxy to close them out. Team > > > effort would be a very good thing I think. > > > > Well then - let's start friday Bug Days again. This friday (and > > possibly next friday) we can try to work through the FC5 and FC6 test > > release bugs. It's only 380 bugs! Here's the link: > > > > http://rdr.to/W8 > > > > That's (currently) 460 ASSIGNED, MODIFIED, NEEDINFO and NEW bugs > > against all the FC5 and FC6 test releases. > > Sounds like a good idea to me. I would be happy to help. > > What time? Coordinate on #fedora-devel irc? > Is there more info for people who would like to help? Usually we do this in #fedora-qa. The following wiki pages should also be helpful: http://fedoraproject.org/wiki/BugZappers http://fedoraproject.org/wiki/TriagingGuidelines > > This might be a good time to mention the recently-created > > fedora-qa-list: > > http://www.redhat.com/mailman/listinfo/fedora-qa-list > > Another list? :( Is that really needed? or couldn't discussions take > place here? Plenty of discussions *could* take place here - in fact, 10,000 unread emails indicate that plenty of them *do* take place here - but there was nowhere to discuss QA-specific things like bug triaging and bugzilla improvements and regression testing. So yes, it is really needed. -w -------------- 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 j.w.r.degoede at hhs.nl Thu Mar 22 19:34:00 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 22 Mar 2007 20:34:00 +0100 Subject: Which unresolved bugs block a release? In-Reply-To: <20070322130641.78095a25@ghistelwchlohm.scrye.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602C455.8030602@hhs.nl> <1174586820.3518.12.camel@zod.rchland.ibm.com> <1174587799.17842.17.camel@metroid.rdu.redhat.com> <20070322130641.78095a25@ghistelwchlohm.scrye.com> Message-ID: <4602DA28.5090709@hhs.nl> Kevin Fenzi wrote: > On Thu, 22 Mar 2007 14:23:19 -0400 > wwoods at redhat.com (Will Woods) wrote: > >> On Thu, 2007-03-22 at 13:07 -0500, Josh Boyer wrote: >>> On Thu, 2007-03-22 at 19:00 +0100, Hans de Goede wrote: > > ...snipp... > >>>> Most likely a lot of 1) bugs are already solved but never got >>>> closed / retested, others should be taken upstream (and thus >>>> closed in Fedora BZ), etc. >>> If a lot of 1) bugs are already solved, anyone within the >>> 'fedorabugs' group can act as a proxy to close them out. Team >>> effort would be a very good thing I think. >> Well then - let's start friday Bug Days again. This friday (and >> possibly next friday) we can try to work through the FC5 and FC6 test >> release bugs. It's only 380 bugs! Here's the link: >> >> http://rdr.to/W8 >> >> That's (currently) 460 ASSIGNED, MODIFIED, NEEDINFO and NEW bugs >> against all the FC5 and FC6 test releases. > > Sounds like a good idea to me. I would be happy to help. > > What time? I'll be available from 8u00 (CET / GMT +1) till 17u00 and maybe sometime in the evening too. > Coordinate on #fedora-devel irc? +1 > Is there more info for people who would like to help? > Good question, for example what should we do with bugs like: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214864 Assigned by reporter to reporter, no valid summary / description, most likely caused by a messed up install, invalid component. Slam close? >> Next week: FC5, or FC6? > > Possibly. ;) > I say start with the newest bugs first, those contain much more low hanging fruit, so I "vote" to work on this list coming friday: http://rdr.to/W9 > If this is a weekly thing I would also like to see trying to help out > some of the packages that just have way too many bugs for any single > mantainer to deal with... rpm, kernel, etc. > kernel is very hard to help with (I've written and maintain some kernel drivers, and I'm lost in there). Helping rpm starts with getting rpm an active maintainer, I've filed and watched many rpm bugs and comments to the by pnasrat (the current maintainer) are very scarce. I think that choosing one package and then working on it is a good idea, but again low hanging fruit. For example ImagaMagick has quite a few bugs which should be fixable. Also an important question to ask ourselves is triage or fixing or both? I'm quite good at debugging C-code (no race conditions please), and have already fixed quite a few bugs. Now if we could combine a few triagers with a few fixers on friday, that might work very well. >> This might be a good time to mention the recently-created >> fedora-qa-list: >> http://www.redhat.com/mailman/listinfo/fedora-qa-list > > Another list? :( Is that really needed? or couldn't discussions take > place here? > +1 +1 +1 >> Further discussion of this topic should go there. > > ok. I will after this I suppose. > Please don't, -ETOOMANYLISTS. Regards, Hans From davej at redhat.com Thu Mar 22 19:25:27 2007 From: davej at redhat.com (Dave Jones) Date: Thu, 22 Mar 2007 15:25:27 -0400 Subject: Which unresolved bugs block a release? In-Reply-To: <20070322130641.78095a25@ghistelwchlohm.scrye.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602C455.8030602@hhs.nl> <1174586820.3518.12.camel@zod.rchland.ibm.com> <1174587799.17842.17.camel@metroid.rdu.redhat.com> <20070322130641.78095a25@ghistelwchlohm.scrye.com> Message-ID: <20070322192527.GA15147@redhat.com> On Thu, Mar 22, 2007 at 01:06:41PM -0600, Kevin Fenzi wrote: > If this is a weekly thing I would also like to see trying to help out > some of the packages that just have way too many bugs for any single > mantainer to deal with... rpm, kernel, etc. I've been toying with the idea of a 'kernel bug day' thing for a while. Whilst a lot of those bugs are really nasty horrible bugs that you really need to understand kernel code for, there's quite a bit of grunt work that I'd be happy to farm out to eager helpers. Things like .. * marking bugs that have patches in them more prominently, * adding bugs to the 'meta' bugs (cf, the alias 'FCMETA_ACPI'), * making sure relevant people are cc'd/assigned. * going through old bugs and asking reporters to retest with the latest updates * closing out bugs that have been in NEEDINFO forever. * forwarding bug reports upstream to linux-kernel / maintainers / kernel.org bugzilla. It's real painstaking work to do that sort of thing, and I'd rather be actually fixing bugs. The last time I did some stats, the kernel had more bugs assigned against it than any other package. It's constantly inundated with new reports coming in faster than we can close out old ones, so any help on keeping this managable so that we can actually see the bugs that matter would be much appreciated. I'm on pseudo-vacation next week, but I think we should give this a shot when I get back. Dave -- http://www.codemonkey.org.uk From wwoods at redhat.com Thu Mar 22 19:37:51 2007 From: wwoods at redhat.com (Will Woods) Date: Thu, 22 Mar 2007 15:37:51 -0400 Subject: Which unresolved bugs block a release? In-Reply-To: <20070322192527.GA15147@redhat.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602C455.8030602@hhs.nl> <1174586820.3518.12.camel@zod.rchland.ibm.com> <1174587799.17842.17.camel@metroid.rdu.redhat.com> <20070322130641.78095a25@ghistelwchlohm.scrye.com> <20070322192527.GA15147@redhat.com> Message-ID: <1174592271.17842.38.camel@metroid.rdu.redhat.com> On Thu, 2007-03-22 at 15:25 -0400, Dave Jones wrote: > On Thu, Mar 22, 2007 at 01:06:41PM -0600, Kevin Fenzi wrote: > > > If this is a weekly thing I would also like to see trying to help out > > some of the packages that just have way too many bugs for any single > > mantainer to deal with... rpm, kernel, etc. > > I've been toying with the idea of a 'kernel bug day' thing for a while. > Whilst a lot of those bugs are really nasty horrible bugs that you > really need to understand kernel code for, there's quite a bit of > grunt work that I'd be happy to farm out to eager helpers. > > Things like .. > * marking bugs that have patches in them more prominently, > * adding bugs to the 'meta' bugs (cf, the alias 'FCMETA_ACPI'), > * making sure relevant people are cc'd/assigned. > * going through old bugs and asking reporters to retest with > the latest updates > * closing out bugs that have been in NEEDINFO forever. > * forwarding bug reports upstream to linux-kernel / maintainers / kernel.org > bugzilla. > > It's real painstaking work to do that sort of thing, and I'd rather > be actually fixing bugs. We've got plenty of eager helpers (myself included!). We'll just need some guidance to know which bucket to put stuff in. > I'm on pseudo-vacation next week, but I think we should give > this a shot when I get back. Absolutely! I dunno which time zone you're in at the moment, so pick a time next Friday (or whatever day works for you). We'll get the word out. Hopefully we can do this regularly. -w -------------- 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 hackman at venus.dti.ne.jp Thu Mar 22 19:44:06 2007 From: hackman at venus.dti.ne.jp (Hiroaki Kondo) Date: Fri, 23 Mar 2007 04:44:06 +0900 Subject: 802.1ag&802.1ah on embedded linux Message-ID: <00f301c76cba$7442a4f0$1a101fac@NEUROMANCER> Hi list! Please let me know the information of packages about 802.1ag&802.1ah on embedded linux. I want to build the environment for NGN of ITU-T. And I want to know where the paper's there about NGN security. Best Regards, Hiroaki Kondo Security Consultant in Japan. hackman a venus.dti.ne.jp hkondo a wnet.co.jp From linville at redhat.com Thu Mar 22 19:49:07 2007 From: linville at redhat.com (John W. Linville) Date: Thu, 22 Mar 2007 15:49:07 -0400 Subject: 802.1ag&802.1ah on embedded linux In-Reply-To: <00f301c76cba$7442a4f0$1a101fac@NEUROMANCER> References: <00f301c76cba$7442a4f0$1a101fac@NEUROMANCER> Message-ID: <20070322194907.GD22068@redhat.com> On Fri, Mar 23, 2007 at 04:44:06AM +0900, Hiroaki Kondo wrote: > Please let me know the information of packages about 802.1ag&802.1ah on > embedded linux. > I want to build the environment for NGN of ITU-T. > And I want to know where the paper's there about NGN security. This list is for Fedora, which is not normally associated with embedded systems except as a development host. Beyond that, I'm not aware of any 802.1ag or .1ah development for the upstream kernel. In fact, I had never heard of either prior to your email. Hth! John -- John W. Linville linville at redhat.com From wwoods at redhat.com Thu Mar 22 19:50:34 2007 From: wwoods at redhat.com (Will Woods) Date: Thu, 22 Mar 2007 15:50:34 -0400 Subject: Which unresolved bugs block a release? In-Reply-To: <4602DA28.5090709@hhs.nl> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602C455.8030602@hhs.nl> <1174586820.3518.12.camel@zod.rchland.ibm.com> <1174587799.17842.17.camel@metroid.rdu.redhat.com> <20070322130641.78095a25@ghistelwchlohm.scrye.com> <4602DA28.5090709@hhs.nl> Message-ID: <1174593034.17842.51.camel@metroid.rdu.redhat.com> On Thu, 2007-03-22 at 20:34 +0100, Hans de Goede wrote: > > What time? > I'll be available from 8u00 (CET / GMT +1) till 17u00 and maybe sometime in > the evening too. > > > Coordinate on #fedora-devel irc? > +1 If you want to keep it on #fedora-devel that's fine - eventually I suspect (hope?) that bug triaging will get too big to stay there without drowning out normal -devel work. At that point, we should move to #fedora-qa. > > > Is there more info for people who would like to help? > > > > Good question, for example what should we do with bugs like: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214864 > Assigned by reporter to reporter, no valid summary / description, most likely > caused by a messed up install, invalid component. Slam close? Very yes. There's nothing to fix, hence the problem is solved. > I say start with the newest bugs first, those contain much more low hanging > fruit, so I "vote" to work on this list coming friday: > http://rdr.to/W9 Noted. > Also an important question to ask ourselves is triage or fixing or both? I'm > quite good at debugging C-code (no race conditions please), and have already > fixed quite a few bugs. Now if we could combine a few triagers with a few > fixers on friday, that might work very well. Triage + fixing is awesome but I can't speak for developers. There will definitely be weekly triage sessions every Friday - at least US Eastern business hours, when I'm around (~1400-2200UTC). If developers come and help fix the low-hanging fruit, so much the better. > >> This might be a good time to mention the recently-created > >> fedora-qa-list: > >> http://www.redhat.com/mailman/listinfo/fedora-qa-list > > > > Another list? :( Is that really needed? or couldn't discussions take > > place here? > > > > +1 +1 +1 > >> Further discussion of this topic should go there. > > > > ok. I will after this I suppose. > > > > Please don't, -ETOOMANYLISTS. Feh. This wasn't just a gratuitous "Hey let's make a new list!!" decision - we decided this in January: http://www.redhat.com/archives/fedora-advisory-board/2007-January/msg00104.html Except nobody seems to be able to agree on whether we need more or less lists, and what they should be named, and so on. I'm sick of discussing whether we need new lists or not. Development is not the same as QA and I refuse to require fedora-devel-list membership for the QA team. That's why they're separate - to reduce apparent signal/noise problems and prevent people who aren't developers from having to pick QA stuff out of 10,000 unread development messages. -w -------------- 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 mclasen at redhat.com Thu Mar 22 20:15:21 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 22 Mar 2007 16:15:21 -0400 Subject: Which unresolved bugs block a release? In-Reply-To: <1174586820.3518.12.camel@zod.rchland.ibm.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602C455.8030602@hhs.nl> <1174586820.3518.12.camel@zod.rchland.ibm.com> Message-ID: <1174594521.3808.2.camel@localhost.localdomain> On Thu, 2007-03-22 at 13:07 -0500, Josh Boyer wrote: > > > > These bugs fall into 2 categories: > > 1) Bugs which are simply being ignored by @redhat.com people who need to be hit > > with the cluebat (repeatedly) > > Don't make statements like that. They aren't helpful in any manner. > You cannot claim that they are intentionally ignoring them. Hitting > people with the "update your bugs" cluebat that have a massive amount of > bugs simply does not work and does not help solve the problem. > If you want to be helpful, add a comment "fixed in x.y.z" if you find bugs that no longer apply. That will make it much easier to quickly close it the next time the package maintainer comes across the bug. From jwilson at redhat.com Thu Mar 22 20:33:45 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 22 Mar 2007 16:33:45 -0400 Subject: Which unresolved bugs block a release? In-Reply-To: <1174592271.17842.38.camel@metroid.rdu.redhat.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602C455.8030602@hhs.nl> <1174586820.3518.12.camel@zod.rchland.ibm.com> <1174587799.17842.17.camel@metroid.rdu.redhat.com> <20070322130641.78095a25@ghistelwchlohm.scrye.com> <20070322192527.GA15147@redhat.com> <1174592271.17842.38.camel@metroid.rdu.redhat.com> Message-ID: <4602E829.3000907@redhat.com> Will Woods wrote: > On Thu, 2007-03-22 at 15:25 -0400, Dave Jones wrote: >> I've been toying with the idea of a 'kernel bug day' thing for a while. >> Whilst a lot of those bugs are really nasty horrible bugs that you >> really need to understand kernel code for, there's quite a bit of >> grunt work that I'd be happy to farm out to eager helpers. >> >> Things like .. >> * marking bugs that have patches in them more prominently, >> * adding bugs to the 'meta' bugs (cf, the alias 'FCMETA_ACPI'), >> * making sure relevant people are cc'd/assigned. >> * going through old bugs and asking reporters to retest with >> the latest updates >> * closing out bugs that have been in NEEDINFO forever. >> * forwarding bug reports upstream to linux-kernel / maintainers / kernel.org >> bugzilla. >> >> It's real painstaking work to do that sort of thing, and I'd rather >> be actually fixing bugs. > > We've got plenty of eager helpers (myself included!). Count me in too. I already try to do whatever I can, sweeping through open bugs from time to time, but would love to do more. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ssorce at redhat.com Thu Mar 22 20:41:00 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 22 Mar 2007 16:41:00 -0400 Subject: Quota per directory In-Reply-To: References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <200703210900.46111.lamont@gurulabs.com> <1174582906.16983.90.camel@willson> <1174583665.16983.92.camel@willson> Message-ID: <1174596060.16983.96.camel@willson> On Thu, 2007-03-22 at 13:23 -0400, Oisin Feeley wrote: > On 3/22/07, Simo Sorce wrote: > > [snip condition which must be true for any quota scheme ;)] > > > > Also broken if you have > 10-20 projects, becomes unmanageable. > > Unmanageable because of the claimed fsck speed issue mentioned by the > OP or unmanageable because the admin would have to keep track of his > large number of logical volumes? Unmanageable because they are too many. Unmanageable because it is a too rigid policy and you don't even have soft quotas Unmanageable because if the needs of some groups change you have to actually resize file systems to give the more space It's a hackish mess :) Group quotas are easier. Simo. From j.w.r.degoede at hhs.nl Thu Mar 22 21:02:40 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 22 Mar 2007 22:02:40 +0100 Subject: Which unresolved bugs block a release? In-Reply-To: <1174594521.3808.2.camel@localhost.localdomain> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602C455.8030602@hhs.nl> <1174586820.3518.12.camel@zod.rchland.ibm.com> <1174594521.3808.2.camel@localhost.localdomain> Message-ID: <4602EEF0.6090401@hhs.nl> Matthias Clasen wrote: > On Thu, 2007-03-22 at 13:07 -0500, Josh Boyer wrote: >>> These bugs fall into 2 categories: >>> 1) Bugs which are simply being ignored by @redhat.com people who need to be hit >>> with the cluebat (repeatedly) >> Don't make statements like that. They aren't helpful in any manner. >> You cannot claim that they are intentionally ignoring them. Hitting >> people with the "update your bugs" cluebat that have a massive amount of >> bugs simply does not work and does not help solve the problem. >> > > If you want to be helpful, add a comment "fixed in x.y.z" if you find > bugs that no longer apply. That will make it much easier to quickly > close it the next time the package maintainer comes across the bug. > I always do that (and close them) for bugs I fixed myself. Matthias, you're one of the @redhat.com people I know to be pretty responsive most of the time. However unfortunately you have colleagues who aren't response to BZ entries, this is not good and someone needs to talk to these people about it. I understand that there are busy times and very busy times @redhat, still I see a huge differences between individual @redhat people in how responsive they are. I can give a list of positive examples (you included), but funny enough not negative examples, because I have so little interaction with these people that I don't know / remember there names! Still I know they exist because some of the bugs I file get assigned to them and then completely disappear of the radar. Regards, Hans From poelstra at redhat.com Thu Mar 22 21:13:01 2007 From: poelstra at redhat.com (John Poelstra) Date: Thu, 22 Mar 2007 14:13:01 -0700 Subject: Which unresolved bugs block a release? In-Reply-To: <200703221310.33829.jkeating@redhat.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> Message-ID: <4602F15D.6070008@redhat.com> Jesse Keating said the following on 03/22/2007 10:10 AM Pacific Time: > On Thursday 22 March 2007 12:29:42 John Poelstra wrote: >> Has the project discussed or determined how we will: >> 1) Close out the approximately 7,000+ open bugs? >> 2) Handle future releases in a way that the backlog doesn't get so high? > > Do you have any ideas? You're part of the projet. > I was trying to be polite by not rehashing or pushing something that had already been discussed. If work has already been done I thought it would better build on it instead starting from scratch. I'm still trying to understand exactly what processes and decisions go into creating a Fedora release... from the planning process all the way to GA and maintenance. I'd like to think that eventually we could have a document explaining this entire process, including how bugs are handled. I think this is an important aspect of being transparent as a project. John From jkeating at redhat.com Thu Mar 22 21:24:56 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 22 Mar 2007 17:24:56 -0400 Subject: Which unresolved bugs block a release? In-Reply-To: <4602F15D.6070008@redhat.com> References: <4601EF3B.2030108@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602F15D.6070008@redhat.com> Message-ID: <200703221724.59227.jkeating@redhat.com> On Thursday 22 March 2007 17:13:01 John Poelstra wrote: > I'm still trying to understand exactly what processes and decisions go into > creating a Fedora release... from the planning process all the way to GA > and maintenance. ?I'd like to think that eventually we could have a > document explaining this entire process, including how bugs are handled. ?I > think this is an important aspect of being transparent as a project. Absolutely. The horror of it is that there IS no real concrete method to determine this. Isn't it fun? -- 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 david at lovesunix.net Thu Mar 22 21:37:50 2007 From: david at lovesunix.net (David Nielsen) Date: Thu, 22 Mar 2007 22:37:50 +0100 Subject: Which unresolved bugs block a release? In-Reply-To: <4602E829.3000907@redhat.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <4602AEF6.9000307@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602C455.8030602@hhs.nl> <1174586820.3518.12.camel@zod.rchland.ibm.com> <1174587799.17842.17.camel@metroid.rdu.redhat.com> <20070322130641.78095a25@ghistelwchlohm.scrye.com> <20070322192527.GA15147@redhat.com> <1174592271.17842.38.camel@metroid.rdu.redhat.com> <4602E829.3000907@redhat.com> Message-ID: <1174599470.2928.9.camel@dawkins> tor, 22 03 2007 kl. 16:33 -0400, skrev Jarod Wilson: > Will Woods wrote: > > On Thu, 2007-03-22 at 15:25 -0400, Dave Jones wrote: > >> I've been toying with the idea of a 'kernel bug day' thing for a while. > >> Whilst a lot of those bugs are really nasty horrible bugs that you > >> really need to understand kernel code for, there's quite a bit of > >> grunt work that I'd be happy to farm out to eager helpers. > >> > >> Things like .. > >> * marking bugs that have patches in them more prominently, > >> * adding bugs to the 'meta' bugs (cf, the alias 'FCMETA_ACPI'), > >> * making sure relevant people are cc'd/assigned. > >> * going through old bugs and asking reporters to retest with > >> the latest updates > >> * closing out bugs that have been in NEEDINFO forever. > >> * forwarding bug reports upstream to linux-kernel / maintainers / kernel.org > >> bugzilla. > >> > >> It's real painstaking work to do that sort of thing, and I'd rather > >> be actually fixing bugs. > > > > We've got plenty of eager helpers (myself included!). > > Count me in too. I already try to do whatever I can, sweeping through > open bugs from time to time, but would love to do more. Me too, I'd love to have some guidelines to getting better information out of the kernel to say report unworking suspend situations. The kernel is a rather special package and I doubt many of us wield it's strange magic. - 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: This is a digitally signed message part URL: From lamont at gurulabs.com Thu Mar 22 21:42:18 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Thu, 22 Mar 2007 15:42:18 -0600 Subject: Quota per directory In-Reply-To: References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <200703210900.46111.lamont@gurulabs.com> Message-ID: <200703221542.18713.lamont@gurulabs.com> On Thursday 22 March 2007 10:15am, Oisin Feeley wrote: > On 3/21/07, Lamont Peterson wrote: > > On Wednesday 21 March 2007 02:14am, Ahmed Kamal wrote: > > > Coming from a systems administration background, I was very surprised > > > to find out that fedora (well Linux actually) doesn't have a per > > > directory quota. It is very common and needed IMHO to have a quota per > > > directory, as the directory basically represents a project some people > > > are working on. One would want to make sure that a certain project > > > would not consume all disk space. Only XFS seemed to have per "project" > > > quota (I even think the Linux implementation doesn't have that!) > > > > Linux "only" has per-filesystem quota support. You're asking for what's > > called "tree quotas" support. > > What would be wrong with the OP using LVM to set up defined logical > volumes per project? Nothing. I'm not advocating either approach in that small snippet that you quoted. What I was saying is that the feature the OP was asking about is called tree quotas and that Linux doesn't have it. Linux only has per-filesystem. I said nothing of where that filesystem resides. If your intent was to suggest that having to create separate filesystems to set up separate quotas wasn't a problem because LVM makes that so easy, I totally agree with you. > The quota is then enforced, it sits on top of > standard ext3 Or reiserfs or JFS or XFS or JFFS2 or ...; quotas in Linux are not restricted to any filesystem type. > and provides the possibility of expanding/changing the > quotas in the future while bypassing the need to do the tree-quota > stuff. Absolutely. LVM does make this kind of configuration (relatively) easy. The only hard part is managing quotas for 1000 users on 40 per project filesystems. In that case, do group quotas instead for the per-project directories and only set up per user quotas to handle "bad citizens". -- 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 Thu Mar 22 21:45:28 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Thu, 22 Mar 2007 15:45:28 -0600 Subject: Quota per directory In-Reply-To: <1174596060.16983.96.camel@willson> References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <1174596060.16983.96.camel@willson> Message-ID: <200703221545.28532.lamont@gurulabs.com> On Thursday 22 March 2007 02:41pm, Simo Sorce wrote: > On Thu, 2007-03-22 at 13:23 -0400, Oisin Feeley wrote: > > On 3/22/07, Simo Sorce wrote: > > > > [snip condition which must be true for any quota scheme ;)] > > > > > > Also broken if you have > 10-20 projects, becomes unmanageable. > > > > Unmanageable because of the claimed fsck speed issue mentioned by the > > OP or unmanageable because the admin would have to keep track of his > > large number of logical volumes? > > Unmanageable because they are too many. > Unmanageable because it is a too rigid policy and you don't even have > soft quotas No true. Linux quotas support both soft and hard limits, though I never set soft to anything but the same value as hard, personally (some do and it is useful). > Unmanageable because if the needs of some groups change you have to > actually resize file systems to give the more space Which points out that quotas are not needed at all if you just do per-project LVs. When they need space, run lvextend and resize the filesystem. That's it and you don't have to unmount anything. > It's a hackish mess :) > Group quotas are easier. Can be. -- 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 Thu Mar 22 21:46:29 2007 From: lamont at gurulabs.com (Lamont Peterson) Date: Thu, 22 Mar 2007 15:46:29 -0600 Subject: Quota per directory In-Reply-To: <3da3b5b40703220942n52175245sd2ca25ec2935986f@mail.gmail.com> References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <4602AAB2.4070304@gmail.com> <3da3b5b40703220942n52175245sd2ca25ec2935986f@mail.gmail.com> Message-ID: <200703221546.30186.lamont@gurulabs.com> On Thursday 22 March 2007 10:42am, Ahmed Kamal wrote: > replacing each directory with a volume looks like a management nightmare!! > What happens after a power failure! I fsck 100 volumes?! That's why you use journaling filesystems. -- 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 wwoods at redhat.com Thu Mar 22 21:47:43 2007 From: wwoods at redhat.com (Will Woods) Date: Thu, 22 Mar 2007 17:47:43 -0400 Subject: Which unresolved bugs block a release? In-Reply-To: <200703221724.59227.jkeating@redhat.com> References: <4601EF3B.2030108@redhat.com> <200703221310.33829.jkeating@redhat.com> <4602F15D.6070008@redhat.com> <200703221724.59227.jkeating@redhat.com> Message-ID: <1174600063.17842.58.camel@metroid.rdu.redhat.com> On Thu, 2007-03-22 at 17:24 -0400, Jesse Keating wrote: > On Thursday 22 March 2007 17:13:01 John Poelstra wrote: > > I'm still trying to understand exactly what processes and decisions go into > > creating a Fedora release... from the planning process all the way to GA > > and maintenance. I'd like to think that eventually we could have a > > document explaining this entire process, including how bugs are handled. I > > think this is an important aspect of being transparent as a project. > > Absolutely. The horror of it is that there IS no real concrete method to > determine this. Isn't it fun? On the plus side, you can't get much more transparent than "nothing". -w -------------- 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 a.badger at gmail.com Thu Mar 22 22:35:37 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 22 Mar 2007 15:35:37 -0700 Subject: SoC idea: Review Web App In-Reply-To: <20070322173624.GI1511@redhat.com> References: <20070322001446.GA13508@redhat.com> <1174523891.23909.12.camel@localhost.localdomain> <20070322173624.GI1511@redhat.com> Message-ID: <1174602937.5105.12.camel@localhost.localdomain> On Thu, 2007-03-22 at 13:36 -0400, Andrew Overholt wrote: > * Toshio Kuratomi [2007-03-21 20:38]: > > > > Trying to do the whole thing as a SoC project is, I think, overzealous. > > I'd like to see a definition of what we want to achieve and what > > existing systems it will tie into. > > I was envisioning just the review process itself for a SoC project. > Yah. My point is that this ties into a lot of other projects, some finished and some ongoing. What are the goals of the web app? To move away from bugzilla? Which features in particular are not meeting our needs on bugzilla and which does bugzilla do well? What do we want to do with the data from reviews? If we tie this into preapproval builds, do we have to do reviews of untrusted packages before submitting to mock or is mock sufficiently secure to do a build up front? Work done on moinmoin, or backup software in previous iterations of the SoC were largely independent of what we do with the rest of Fedora. A Review Web App sits squarely in the middle of it. The mentor for this project needs to be aware of where they want the application to connect to other Fedora services and how it's supposed to improve on the current experience. Which is not to discourage you from pushing this as a project. Bugzilla has shortcomings as a reviewing location. But there's more to this than a better UI. Defining what the app needs to solve will allow for defining what a successful project will look like rather than sticking some poor student in the middle of a bunch of competing interests with no clear idea of what they need to do to create some software that we'll be able to start using when they're done. -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 giallu at gmail.com Thu Mar 22 23:32:22 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 23 Mar 2007 00:32:22 +0100 Subject: Unable to install firefox add-ons Message-ID: Am I the only one unable to install firefox add-ons with firefox-1.5.0.10-5.fc6 ? For example, trying to install this: https://addons.mozilla.org/firefox/60/ I get: Software installation is currently disabled. Click Edit Options... to enable it and try again. Fact is, I never disabled it nor happen to find where I should activate it in the options... From pemboa at gmail.com Thu Mar 22 23:39:19 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 22 Mar 2007 18:39:19 -0500 Subject: Unable to install firefox add-ons In-Reply-To: References: Message-ID: <16de708d0703221639r894220eo4b09f3d5ed305dee@mail.gmail.com> On 3/22/07, Gianluca Sforna wrote: > Am I the only one unable to install firefox add-ons with > firefox-1.5.0.10-5.fc6 ? > For example, trying to install this: > > https://addons.mozilla.org/firefox/60/ > > I get: Software installation is currently disabled. Click Edit > Options... to enable it and try again. > > Fact is, I never disabled it nor happen to find where I should > activate it in the options... > First I'm hearing of this. If all else fails, live dangerously: run it as root, install the addon, then shut down immediately -- Fedora Core 6 and proud From chitlesh at fedoraproject.org Fri Mar 23 00:00:25 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Fri, 23 Mar 2007 01:00:25 +0100 Subject: Experimental KDE 3.80.3 specfiles In-Reply-To: References: <20070222225108.693e5e73@localhost.localdomain> Message-ID: <13dbfe4f0703221700k4108147csa4b971382d994a82@mail.gmail.com> On 2/23/07, Kevin Kofler wrote: > I'll backport that into my next kdelibs4 spin. Hello, On monday and tuesday, i was at the KDE booth in Cebit. I had a KDE4 of last saturday's snapshot on f7-devel. - http://flickr.com/photo_zoom.gne?id=430839898&size=o - http://flickr.com/photo_zoom.gne?id=430839903&size=o Though it is in still unstable, I could demonstrate kde4 as a fully logged session (with a work around): Here are my srpms and rpms for testing purposes only. http://tux.u-strasbg.fr/~chit/KDE4/ Since I badly needed a snapshot for cebit I didnt have time to tune kevin's patches on my packages. konqueror crashes all the time. dolphin, alt-f2 and kcontrol work without crashing. till now plasma is disabled, but oxygen icons are present :) The work around was to 1)write a script kde4.sh #!/bin/bash export LD_LIBRARY_PATH=/opt/kde4/lib export KDEDIR=/opt/kde4 export PATH=/opt/kde4/bin/:$PATH export KDEHOME=~/.kde4 startkde& kdesktop& 2) Press ctrl+alt+f1 3) logged in as another user (kdedevel) 4) xinit -- :1& 5) ./kde4.sh In the future, I'll be tuning kevin's patches and if i have time I'll package kdenetwork and the rest. regards, Chitlesh -- http://clunixchit.blogspot.com From bernie at develer.com Fri Mar 23 00:07:44 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 23 Mar 2007 01:07:44 +0100 Subject: speed of yum depsolver In-Reply-To: <1173725383.20424.38.camel@cutter> References: <45F483C9.5000008@fedoraproject.org> <1173716340.20424.31.camel@cutter> <34031.192.54.193.51.1173716740.squirrel@rousalka.dyndns.org> <200703121305.36545.jkeating@redhat.com> <1173720460.1633.2.camel@rousalka.dyndns.org> <20070312183922.GA5518@redhat.com> <1173725383.20424.38.camel@cutter> Message-ID: <46031A50.80705@develer.com> seth vidal wrote: > 1. downgrade to yum 3.0.3 from fc6 > 2. put an exclude in for yum in your yum.conf 3. switch to smart -- // Bernardo Innocenti - Develer R&D dept. \X/ http://www.develer.com/ From buildsys at fedoraproject.org Fri Mar 23 00:33:17 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Thu, 22 Mar 2007 20:33:17 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-22 Message-ID: <20070323003317.C7417152130@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 37 NetworkManager-vpnc-0.6.4-3.fc7 NEW SDLmm-0.1.8-3.fc7 Zim-0.19-1.fc7 NEW aspell-hi-0.01-1.fc7 aumix-2.8-14.fc7 bcm43xx-fwcutter-006-1.fc7 NEW compat-flex-2.5.4a-1.fc7 dbmail-2.2.4-2.fc7 eclipse-emf-2.2.2-1.fc7 eclipse-sdk-nls-3.2.1-3.fc7 gdal-1.4.0-18.fc7 glom-1.4.2-1.fc7 gocr-0.44-2.fc7 NEW gscan2pdf-0.9.5-6.fc7 gtk2hs-0.9.11-1.fc7 hyperestraier-1.4.10-1.fc7 isomaster-0.8.1-1.fc7 jd-1.8.8-0.2.cvs070322.fc7 kbibtex-0.1.5-8.fc7 lyx-1.5.0-0.2.beta1.fc7 NEW multiget-1.1.4-7.fc7 nas-1.8a-2.fc7 opencv-1.0.0-3.fc7 pbzip2-1.0.1-1.fc7 perl-Class-MOP-0.37-1.fc7 NEW perl-Class-Observable-1.04-2.fc7 NEW perl-Net-CUPS-0.51-2.fc7 perl-POE-0.9917-1.fc7 perl-POE-API-Peek-1.0802-1.fc7 perl-RRD-Simple-1.43-1.fc7 NEW perl-XML-Filter-BufferText-1.01-2.fc7 NEW perl-XML-SAX-Writer-0.50-2.fc7 qdbm-1.8.75-1.fc7 qt4-4.2.3-5.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.3003.fc7 NEW vym-1.8.1-8.fc7 xpa-2.1.7-0.1.b2.fc7 Packages built and released for Fedora Extras 6: 31 NetworkManager-vpnc-0.6.4-3.fc6 NEW SDLmm-0.1.8-3.fc6 Zim-0.19-1.fc6 aumix-2.8-14.fc6 dbmail-2.2.4-2.fc6 fwbackups-1.42.3a-1.fc6 gdal-1.4.0-18.fc6 NEW gocr-0.44-2.fc6 NEW gscan2pdf-0.9.5-6.fc6 gtk2hs-0.9.11-1.fc6 hddtemp-0.3-0.11.beta15.fc6 hyperestraier-1.4.10-1.fc6 isomaster-0.8.1-1.fc6 kbibtex-0.1.5-7.fc6 NEW multiget-1.1.4-7.fc6 nas-1.8a-2.fc6 opencv-1.0.0-3.fc6 pbzip2-1.0.1-1.fc6 perl-Class-MOP-0.37-1.fc6 NEW perl-Class-Observable-1.04-2.fc6 NEW perl-Net-CUPS-0.51-2.fc6 perl-POE-0.9917-1.fc6 perl-POE-API-Peek-1.0802-1.fc6 perl-RRD-Simple-1.43-1.fc6 NEW perl-XML-Filter-BufferText-1.01-2.fc6 NEW perl-XML-SAX-Writer-0.50-2.fc6 qdbm-1.8.75-1.fc6 NEW vym-1.8.1-8.fc6 NEW xmoto-edit-0.2.4-6.fc6 xpa-2.1.7-0.1.b2.fc6 zope-2.9.6-2.fc6 Packages built and released for Fedora Extras 5: 24 Zim-0.19-1.fc5 aumix-2.8-14.fc5 dbmail-2.2.4-2.fc5 fwbackups-1.42.3a-1.fc5 NEW gscan2pdf-0.9.5-6.fc5 hddtemp-0.3-0.11.beta15.fc5 hyperestraier-1.4.10-1.fc5 isomaster-0.8.1-1.fc5 kbibtex-0.1.5-6.fc5 nas-1.8a-2.fc5 pbzip2-1.0.1-1.fc5 perl-Class-MOP-0.37-1.fc5 NEW perl-Class-Observable-1.04-2.fc5 NEW perl-Net-CUPS-0.51-2.fc5 perl-POE-0.9917-1.fc5 perl-POE-API-Peek-1.0802-1.fc5 perl-RRD-Simple-1.43-1.fc5 NEW perl-XML-Filter-BufferText-1.01-2.fc5 NEW perl-XML-SAX-Writer-0.50-2.fc5 qdbm-1.8.75-1.fc5 NEW vym-1.8.1-8.fc5 NEW xmoto-edit-0.2.4-6.1.fc5 xpa-2.1.7-0.1.b2.fc5 zope-2.9.6-2.fc5 aspell-hi-0.01-1.fc7 -------------------- * Thu Mar 08 2007 Amanpreet Singh Alam 0.01-1 - Initile Release aumix-2.8-14.fc7 ---------------- * Tue Mar 20 2007 Gabriel L. Somlo 2.8-14 - curses-cleanup.patch removes "cruft" such as gtk and system/console mouse - more importantly, it fixes bugzilla ticket # 232828 bcm43xx-fwcutter-006-1.fc7 -------------------------- * Thu Mar 22 2007 David Woodhouse 006-1 - Update to 006 - Remove obsolete modprobe.bcm43xx compat-flex-2.5.4a-1.fc7 ------------------------ dbmail-2.2.4-2.fc7 ------------------ * Tue Mar 20 2007 Bernard Johnson 2.2.4-2 - patch to fix expunge bug eclipse-emf-2.2.2-1.fc7 ----------------------- * Fri Feb 23 2007 Andrew Overholt 2.2.2-1 - 2.2.2 - Remove unnecessary patch for platform javadoc jar name. - Symlink platform doc.isv from %{_libdir}/eclipse/plugins. eclipse-sdk-nls-3.2.1-3.fc7 --------------------------- * Wed Mar 21 2007 Kyu Lee 3.2.1-3 - Added Czech, Hungarian, Polish, Russian, Arabic and Hebrew translations. * Wed Mar 21 2007 Kyu Lee 3.2.1-2 - Added dos2unix BuildRequire. gdal-1.4.0-18.fc7 ----------------- * Wed Mar 21 2007 Balint Cristian 1.4.0-18 - remove system lib path from gdal-config --libs, its implicit glom-1.4.2-1.fc7 ---------------- * Thu Mar 22 2007 Denis Leroy - 1.4.2-1 - Update to 1.4.2 - Removed avahi dependency gocr-0.44-2.fc7 --------------- * Wed Mar 21 2007 - Orion Poplawski - 0.44-2 - Bump release to fix import tag issue gscan2pdf-0.9.5-6.fc7 --------------------- * Wed Mar 21 2007 Bernard Johnson - 0.9.5-6 - now require unpaper and gocr since they are in the extras repo * Tue Mar 20 2007 Bernard Johnson - 0.9.5-5 - patch to fix: a) tiff files that can not be opened b) restrict saving a pdf with no pages * Mon Mar 19 2007 Bernard Johnson - 0.9.5-4 - add Requires: for perl-Gtk2-Ex-PodViewer * Sat Mar 17 2007 Bernard Johnson - 0.9.5-3 - add desktop file the fedora way * Thu Mar 15 2007 Bernard Johnson - 0.9.5-2 - add scriptlets to update icon cache * Wed Mar 14 2007 Bernard Johnson - 0.9.5-1 - initial release gtk2hs-0.9.11-1.fc7 ------------------- * Thu Mar 22 2007 Jens Petersen - 0.9.11-1 - update to 0.9.11 release - disably mozembed for now since the firefox minor version keeps changing (#223880) hyperestraier-1.4.10-1.fc7 -------------------------- * Thu Mar 22 2007 Mamoru Tasaka - 1.4.10-1 - 1.4.10 - Ruby subpackage description change according to Guildlines isomaster-0.8.1-1.fc7 --------------------- * Mon Mar 19 2007 Marcin Zajaczkowski - 0.8.1-1 - updated to 0.8.1 - removed unused patches (merged with upstream) - using desktop file from upstream jd-1.8.8-0.2.cvs070322.fc7 -------------------------- * Thu Mar 22 2007 Mamoru Tasaka - 1.8.8-0.2.cvs070322 - cvs 070322 (24:45 JST) kbibtex-0.1.5-8.fc7 ------------------- * Wed Mar 21 2007 Christian Nolte - 0.1.5-8 - latest patches (storesearchurls, webquerypubmedmultiplequeries, xslhtmlexport) lyx-1.5.0-0.2.beta1.fc7 ----------------------- * Wed Mar 21 2007 Rex Dieter 1.5.0-0.2.beta1 - +Requires: tetex-IEEEtran (#232840) * Mon Mar 05 2007 Rex Dieter 1.5.0-0.1.beta1 - lyx-1.5.0beta1 - tweak lyxrc.dist multiget-1.1.4-7.fc7 -------------------- * Wed Mar 14 2007 Allisson Azevedo 1.1.4-7 - Change patch * Wed Mar 14 2007 Allisson Azevedo 1.1.4-6 - Remove $RPM_OPT_FLAG from .spec * Wed Mar 14 2007 Allisson Azevedo 1.1.4-5 - Patch modified * Mon Mar 12 2007 Allisson Azevedo 1.1.4-4 - Fix .spec * Mon Mar 12 2007 Allisson Azevedo 1.1.4-3 - Include GPL license in doc * Sun Mar 11 2007 Allisson Azevedo 1.1.4-2 - Fix .spec in accordance with the suggestions - Create patch for correct debuginfo package * Sun Mar 11 2007 Allisson Azevedo 1.1.4-1 - Initial RPM release nas-1.8a-2.fc7 -------------- * Thu Mar 22 2007 Frank B?ttner - 1.8a-2.fc7 - use the SVN version of 1.8a * Wed Mar 21 2007 Frank B?ttner - 1.8a-1.fc7 - fix bug 233353 NetworkManager-vpnc-0.6.4-3.fc7 ------------------------------- * Thu Mar 22 2007 Denis Leroy - 1:0.6.4-3 - Added patch to improve configuration GUI, add NAT traversal and single DES options opencv-1.0.0-3.fc7 ------------------ * Thu Mar 22 2007 Ralf Cors?pius - 1.0.0-3 - Fix %{_datadir}/opencv/samples ownership. - Adjust timestamp of cvconfig.h.in to avoid re-running autoheader. * Thu Mar 22 2007 Ralf Cors?pius - 1.0.0-2 - Move all of the python module to pyexecdir (BZ 233128). - Activate the testsuite. pbzip2-1.0.1-1.fc7 ------------------ * Tue Mar 20 2007 Jeff Gilchrist - 1.0.1-1 - Release 1.0.1 perl-Class-MOP-0.37-1.fc7 ------------------------- * Thu Mar 22 2007 Chris Weyl 0.37-1 - update to 0.37 perl-Class-Observable-1.04-2.fc7 -------------------------------- * Sat Mar 17 2007 Andreas Thienemann 1.04-2 - Fixed BuildReq to pull in perl-devel in a portable way * Thu Mar 15 2007 Andreas Thienemann 1.04-1 - Specfile autogenerated by cpanspec 1.69.1. - Cleaned up for FE perl-Net-CUPS-0.51-2.fc7 ------------------------ * Wed Mar 21 2007 Chris Weyl 0.51-2 - bump * Fri Mar 16 2007 Chris Weyl 0.51-1 - Specfile autogenerated by cpanspec 1.70. perl-POE-0.9917-1.fc7 --------------------- * Wed Mar 21 2007 Chris Weyl 0.9917-1 - update to 0.9917. 0.3800-1, below, was never built/released to the wild. * Mon Sep 25 2006 Chris Weyl 0.3800-1 - update to 0.38. 0.37-1, below, was never built/released to the wild. * Mon Sep 11 2006 Chris Weyl 0.3700-1 - update to 0.37 - samples/ is now examples/ - add additional br's: perl(IO::Pty), perl(Test::Pod), perl(Test::Pod::Coverage) perl-POE-API-Peek-1.0802-1.fc7 ------------------------------ * Thu Mar 22 2007 Chris Weyl 1.0802-1 - update to 1.0802 * Tue Oct 10 2006 Chris Weyl 1.0801-1 - update to 1.0801 perl-RRD-Simple-1.43-1.fc7 -------------------------- * Wed Mar 21 2007 Chris Weyl 1.43-1 - update to 1.43 perl-XML-Filter-BufferText-1.01-2.fc7 ------------------------------------- * Sat Mar 17 2007 Andreas Thienemann 1.01-2 - Fixed dependencies * Thu Mar 15 2007 Andreas Thienemann 1.01-1 - Specfile autogenerated by cpanspec 1.69.1. - Cleaned up for FE perl-XML-SAX-Writer-0.50-2.fc7 ------------------------------ * Sat Mar 17 2007 Andreas Thienemann 0.50-2 - Removed hardcoded Reqs in favour of autoreqs - Better conversion to utf-8 * Thu Mar 15 2007 Andreas Thienemann 0.50-1 - Specfile autogenerated by cpanspec 1.69.1. - Cleaned up for FE qdbm-1.8.75-1.fc7 ----------------- * Thu Mar 22 2007 Mamoru Tasaka - 1.8.75-1 - 1.8.75 - Ruby subpackage description change according to Guildlines qt4-4.2.3-5.fc7 --------------- * Wed Mar 21 2007 Rex Dieter 4.2.3-5 - strip (all) glib2 libs from .pc files - prepend _ to rpm macros - drop Obsoletes: qt4-debug SDLmm-0.1.8-3.fc7 ----------------- * Wed Mar 21 2007 Hans de Goede 0.1.8-3 - Advanced Strategic Command (asc), the reason to package this, turns out to use its own private copy of SDLmm. This copy contains a few additional functions and one bug fix. These additional functions are currently not used by asc. Still I have decided to add not only the fix but also the additional functions to be future proof (they do not change the ABI). The asc copy also made some eventhandler prototype changes to make the passed references const, I've not taken over these changes as those do change the API + ABI (and they are not needed for asc). - Fix Source0 URL (bz 233139) * Tue Mar 20 2007 Hans de Goede 0.1.8-2 - Fix a bunch of undefined non weak symbol warnings (bz 233139) - Stop configure from passing -O3 to the compiler * Sun Mar 18 2007 Hans de Goede 0.1.8-1 - Initial Fedora Extras package based on specfile by Che (newrpms) sysprof-kmod-1.0.8-1.2.6.20_1.3003.fc7 -------------------------------------- vym-1.8.1-8.fc7 --------------- * Wed Mar 21 2007 Jon Ciesla - 1.8.1-8 - Converted patches to unified output format. * Wed Mar 21 2007 Jon Ciesla - 1.8.1-7 - Dropped symlink in favor of path patches. * Wed Mar 21 2007 Jon Ciesla - 1.8.1-6 - Fixed Source URL. * Tue Mar 20 2007 Jon Ciesla - 1.8.1-5 - doc link fix, icon fix. * Mon Mar 19 2007 Jon Ciesla - 1.8.1-4 - Fixed Desktop icon path, make copy timestamps, cleaned scripts. - Added symlink to fix PDF location. * Tue Mar 13 2007 Jon Ciesla - 1.8.1-3 - Fixed source url. - added desktop-file-utils,kdelibs BRs. - Fixed desktop file handling. * Tue Mar 13 2007 Jon Ciesla - 1.8.1-2 - Submitting for review. xpa-2.1.7-0.1.b2.fc7 -------------------- * Wed Mar 21 2007 Sergio Pascual 2.1.7-0.1.b2 - New upstream version 2.1.7b2 Zim-0.19-1.fc7 -------------- * Thu Mar 22 2007 Chris Weyl 0.19-1 - and hot on the heels of 0.18 is 0.19! :) For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From caillon at redhat.com Fri Mar 23 02:43:15 2007 From: caillon at redhat.com (Christopher Aillon) Date: Thu, 22 Mar 2007 22:43:15 -0400 Subject: Unable to install firefox add-ons In-Reply-To: References: Message-ID: <46033EC3.1090303@redhat.com> Gianluca Sforna wrote: > Am I the only one unable to install firefox add-ons with > firefox-1.5.0.10-5.fc6 ? > For example, trying to install this: > > https://addons.mozilla.org/firefox/60/ > > I get: Software installation is currently disabled. Click Edit > Options... to enable it and try again. > It should be registering as an extension, not "software" which is reserved for the firefox application itself. Software updating is disabled because we use yum/rpm for installing and updating firefox. Do other extensions work properly? From kevin.kofler at chello.at Fri Mar 23 07:43:18 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 23 Mar 2007 07:43:18 +0000 (UTC) Subject: Experimental KDE 3.80.3 specfiles References: <20070222225108.693e5e73@localhost.localdomain> <13dbfe4f0703221700k4108147csa4b971382d994a82@mail.gmail.com> Message-ID: Chitlesh GOORAH fedoraproject.org> writes: > Though it is in still unstable, I could demonstrate kde4 as a fully > logged session (with a work around) So why does this work and the 3.80.3 doesn't/didn't? Is that a fix which went into KDE SVN between then and now? Or are you doing something special to make it work? > kdesktop& Why does kdesktop have to be launched explicitly? startkde is supposed to run all that's needed already. Is that yet another bug? By the way, kdesktop is being replaced with the new krunner/Plasma infrastructure. Kevin Kofler From giallu at gmail.com Fri Mar 23 08:26:23 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 23 Mar 2007 09:26:23 +0100 Subject: Unable to install firefox add-ons In-Reply-To: <46033EC3.1090303@redhat.com> References: <46033EC3.1090303@redhat.com> Message-ID: On 3/23/07, Christopher Aillon wrote: > Gianluca Sforna wrote: > > Am I the only one unable to install firefox add-ons with > > firefox-1.5.0.10-5.fc6 ? > > For example, trying to install this: > > > > https://addons.mozilla.org/firefox/60/ > > > > I get: Software installation is currently disabled. Click Edit > > Options... to enable it and try again. > > > > It should be registering as an extension, not "software" which is > reserved for the firefox application itself. Software updating is > disabled because we use yum/rpm for installing and updating firefox. Do > other extensions work properly? > No, I get the same messa with each and every extension I try to load. The could be probably related to the fact my home directory is an "ancient" one: I think I will try moving away my .mozilla dir and see if that changes something. Thanks for the info From buildsys at redhat.com Fri Mar 23 09:51:32 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Fri, 23 Mar 2007 05:51:32 -0400 Subject: rawhide report: 20070323 changes Message-ID: <200703230951.l2N9pWXR021914@hs20-bc2-6.build.redhat.com> Updated Packages: anaconda-11.2.0.40-1 -------------------- * Wed Mar 21 2007 Chris Lumens - 11.2.0.40-1 - livecd X fixes (katzj). - Handle mounting errors on the harddrive image method (#124793). - Fix timezone --isUtc for real. - More kickstart RAID10 fixes (#230268). - Fix ip=dhcp command line option (dcantrell, #233152). - Add cdc_ether module for USB networking (dcantrell, #174229). - Fix text mode timezone traceback. fedora-logos-6.0.97-1.fc7 ------------------------- * Thu Mar 22 2007 Than Ngo 6.0.97-1 - Add new Ksplash theme for Fedora 7 fedora-release-notes-6.92-3 --------------------------- * Thu Mar 22 2007 Paul W. Frields - 6.92-3 - Bump release for rebuild * Thu Mar 22 2007 Paul W. Frields - 6.92-2 - Use content from all supplemental modules in Docs CVS * Mon Mar 19 2007 Paul W. Frields - 6.92-1 - Update for Fedora 7 test3 kernel-2.6.20-1.3016.fc7 ------------------------ * Thu Mar 22 2007 Dave Jones - 2.6.21-rc4-git6 * Thu Mar 22 2007 Roland McGrath - Update to latest utrace. - Clean up sparse bits in spec script. * Thu Mar 22 2007 Dave Jones - Check source with sparse during build. kernel-xen-2.6-2.6.20-2925.5.fc7 -------------------------------- * Thu Mar 22 2007 Juan Quintela - disable alternative firewire stack for x86_64, it hangs kernel during boot. * Thu Mar 22 2007 Juan Quintela - Add missing git-geode.patch. - Re-enable Xen and update to 2.6.20-3.0.4 version. - Update to 2.6.20.3. * Mon Feb 12 2007 Kristian H??gsberg - Update firewire patch with latest usptream changes. libvirt-0.2.1-2.fc7 ------------------- * Thu Mar 22 2007 Jeremy Katz - 0.2.1-2.fc7 - don't require xen; we don't need the daemon and can control non-xen now - fix scriptlet error (need to own more directories) - update description text redhat-artwork-5.0.12-1.fc7 --------------------------- * Thu Mar 22 2007 Than Ngo 5.0.12-1 - New release with Fedora 7 kdm theme selinux-policy-2.5.9-5.fc7 -------------------------- * Wed Mar 21 2007 Dan Walsh 2.5.9-5 - Fix labeling on udev.tbl dirs * Tue Mar 20 2007 Dan Walsh 2.5.9-4 - Fixes for logwatch * Tue Mar 20 2007 Dan Walsh 2.5.9-3 - Add fusermount and mount_ntfs policy xorg-x11-drv-i810-1.6.5-14.fc7 ------------------------------ * Thu Mar 22 2007 Adam Jackson 1.6.5-14 - xf86-video-intel 1.9.92 (RC2). yum-3.1.5-1.fc7 --------------- * Thu Mar 22 2007 James Bowes - 3.1.5-1 - update to 3.1.5 * Wed Mar 07 2007 Jeremy Katz - 3.1.4-1 - update to 3.1.4 * Fri Mar 02 2007 Jeremy Katz - 3.1.3-2 - pile of bugfixes committed upstream (#230734, #230771, and others) 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 hughsient at gmail.com Fri Mar 23 10:34:03 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 23 Mar 2007 10:34:03 +0000 Subject: rawhide report: 20070323 changes In-Reply-To: <200703230951.l2N9pWXR021914@hs20-bc2-6.build.redhat.com> References: <200703230951.l2N9pWXR021914@hs20-bc2-6.build.redhat.com> Message-ID: <1174646043.2857.4.camel@localhost.localdomain> On Fri, 2007-03-23 at 05:51 -0400, buildsys at redhat.com wrote: > kernel-2.6.20-1.3016.fc7 > ------------------------ > * Thu Mar 22 2007 Dave Jones > - 2.6.21-rc4-git6 Any chance we can update to the latest snapshot of xf86-video-nouveau and libdrm? Richard. From fedora.lists at burns.me.uk Fri Mar 23 10:57:42 2007 From: fedora.lists at burns.me.uk (Andy Burns) Date: Fri, 23 Mar 2007 10:57:42 +0000 Subject: rawhide report: 20070323 changes In-Reply-To: <200703230951.l2N9pWXR021914@hs20-bc2-6.build.redhat.com> References: <200703230951.l2N9pWXR021914@hs20-bc2-6.build.redhat.com> Message-ID: On 23/03/07, buildsys at redhat.com wrote: > Updated Packages: > kernel-xen-2.6-2.6.20-2925.5.fc7 The previous was kernel-xen-2.6.19-1.2898.2.3.fc7.x86_64.rpm is the "extra" 2.6 in the name desired? From jkeating at redhat.com Fri Mar 23 11:31:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 23 Mar 2007 07:31:15 -0400 Subject: rawhide report: 20070323 changes In-Reply-To: References: <200703230951.l2N9pWXR021914@hs20-bc2-6.build.redhat.com> Message-ID: <200703230731.19092.jkeating@redhat.com> On Friday 23 March 2007 06:57:42 Andy Burns wrote: > The previous was kernel-xen-2.6.19-1.2898.2.3.fc7.x86_64.rpm > is the "extra" 2.6 in the name desired? The package "name" is 'kernel-xen-2.6' I do believe. Ugly yes, but temporary until things sync up again. -- 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 kagesenshi.87 at gmail.com Fri Mar 23 11:53:15 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Fri, 23 Mar 2007 19:53:15 +0800 Subject: rawhide report: 20070323 changes In-Reply-To: <200703230731.19092.jkeating@redhat.com> References: <200703230951.l2N9pWXR021914@hs20-bc2-6.build.redhat.com> <200703230731.19092.jkeating@redhat.com> Message-ID: I'm getting this error when updating --> Processing Dependency: git-core = 1.5.0.3-1.fc7 for package: perl-Git --> Finished Dependency Resolution Error: Missing Dependency: git-core = 1.5.0.3-1.fc7 is needed by package perl-Git -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? Universiti Teknologi PETRONAS ICT 2nd Year 1st Semester mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com ----------------------------------------------- From jwboyer at jdub.homelinux.org Fri Mar 23 12:01:07 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 23 Mar 2007 07:01:07 -0500 Subject: rawhide report: 20070323 changes In-Reply-To: References: <200703230951.l2N9pWXR021914@hs20-bc2-6.build.redhat.com> <200703230731.19092.jkeating@redhat.com> Message-ID: <1174651267.3518.16.camel@zod.rchland.ibm.com> On Fri, 2007-03-23 at 19:53 +0800, Hikaru Amano wrote: > I'm getting this error when updating > > --> Processing Dependency: git-core = 1.5.0.3-1.fc7 for package: perl-Git > --> Finished Dependency Resolution > Error: Missing Dependency: git-core = 1.5.0.3-1.fc7 is needed by > package perl-Git That doesn't make much sense. perl-Git is provided by the same SRPM as git-core so they should have been built together. Also, git-core is now up to 1.5.0.5-1. Perhaps you have a stale mirror. yum clean metadata and try again. josh From chitlesh at fedoraproject.org Fri Mar 23 12:44:49 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Fri, 23 Mar 2007 13:44:49 +0100 Subject: Experimental KDE 3.80.3 specfiles In-Reply-To: References: <20070222225108.693e5e73@localhost.localdomain> <13dbfe4f0703221700k4108147csa4b971382d994a82@mail.gmail.com> Message-ID: <13dbfe4f0703230544g4bb032acq8611324665f55ad@mail.gmail.com> On 3/23/07, Kevin Kofler wrote: > So why does this work and the 3.80.3 doesn't/didn't? Is that a fix which went > into KDE SVN between then and now? Or are you doing something special to make > it work? I don't know in details I didnt have time to have a look at the codes. And since your patch was failing, ive just removed it during the build. > > kdesktop& > > Why does kdesktop have to be launched explicitly? startkde is supposed to run > all that's needed already. Is that yet another bug? By the way, kdesktop is > being replaced with the new krunner/Plasma infrastructure. The wallpaper willnot be accessible. I should dig into it later on to enable plasma. Kevin if you are working on updated specs, I'm ready to host them and their srpms. regards, Chitlesh -- http://clunixchit.blogspot.com From fedora.lists at burns.me.uk Fri Mar 23 16:22:49 2007 From: fedora.lists at burns.me.uk (Andy Burns) Date: Fri, 23 Mar 2007 16:22:49 +0000 Subject: Which unresolved bugs block a release? In-Reply-To: <1174583457.17842.8.camel@metroid.rdu.redhat.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <1174583457.17842.8.camel@metroid.rdu.redhat.com> Message-ID: On 22/03/07, Will Woods wrote: > We do actually have some guidelines for this: > http://fedoraproject.org/wiki/QA/ReleaseCriteria I'm surprised that install to dmraid is classed as MUST, yet install to mdraid isn't even mentioned as SHOULD. Of course I'm biased by the fact that I currently can't achieve a bootable mdraid1 installation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230136 I've never known whether it's a tester's "job" to flag a bug as a blocker, and allow developers to un-flag it where they disagree, or if the developers prefer to triage the bugs themselves and do the flagging. From kevin.kofler at chello.at Fri Mar 23 16:37:41 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 23 Mar 2007 16:37:41 +0000 (UTC) Subject: Experimental KDE 3.80.3 specfiles References: <20070222225108.693e5e73@localhost.localdomain> <13dbfe4f0703221700k4108147csa4b971382d994a82@mail.gmail.com> <13dbfe4f0703230544g4bb032acq8611324665f55ad@mail.gmail.com> Message-ID: Chitlesh GOORAH fedoraproject.org> writes: > I don't know in details I didnt have time to have a look at the codes. > And since your patch was failing, ive just removed it during the > build. It's not really practical to try to merge my patch as a patch. The only really practical solution is to redo it: 1. make a copy of the source directory 2. run KFileReplace on it with the kde4home.kfr file in http://www.tigen.org/kevin.kofler/pcprogs/kde-3.80.3-2-specs.tar.bz2 3. scan the changes for false positives and revert these. 4. create a diff. One way to do step 3 is to take a diff, then open both the original and patched directory in Krusader (hooray for 2 panes), and looking at the diff, copy the original file back to the patched directory if all changes in a file are bad, otherwise use Kompare (select the original file on the left and the patched one on the right in Krusader and pick File/Compare by content from the Krusader menu, this fires up Kompare) to revert the bad changes only. There's some manual work in step 3, but it's the highest amount of automation I could attain. Mechanically replacing things like .kde with .kde4 is not a safe change, I tuned the replacements to avoid false positives as much as it made sense, but there's several ones left I can't easily filter out automatically. Be warned that this also means some understanding of what the code is trying to do is required. > The wallpaper willnot be accessible. > I should dig into it later on to enable plasma. As far as I understood, the situation is this: * Kdesktop has been replaced with krunner. * Kicker has been replaced with Plasma. * The desktop functionality (icons, background) has been moved from kdesktop to Plasma. * They replaced (or are replacing, I'm not sure of the exact status) kdesktop with krunner before replacing Kicker with Plasma in SVN. And all this leads to the desktop functionality being temporarily missing. > Kevin if you are working on updated specs, I'm ready to host them and > their srpms. Well, sorry, but I'm more likely to upload 3.80.3 packages with some backported bugfixes. I collected 2 of them already for bugs which annoyed me, if anyone knows a patch in SVN which fixes an annoying bug (NOT a global source change like Oxygen or shared-mime-info or an API/ABI change!), please give me the revision number. (Note that I don't take patches which are not in the upstream SVN unless you have a really good reason why I should (i.e. it's Fedora-specific or required for safe parallel-installability with KDE 3), please get your fixes upstream first!) My plan is that the next version update for my packages will be when KDE releases the next official snapshot. AFAIK, this will be Alpha 1 around May 1st. Why? For one, I don't want to redo my parallel-installability patches all the time. (As you already noticed, and as explained in the first paragraph, simply updating/merging them isn't really feasible.) Updating them for each official snapshot is already enough work. And secondly, I'm using these packages to develop applications (well, currently one application) against them. I need packages with a well-defined API which doesn't change all the time, so I can specify that my CVS HEAD compiles against KDE 3.80.3, not that it may or may not compile against the current HEAD of the KDE SVN trunk depending on the phase of the moon. ;-) See, this is where our needs differ: I'm a developer, and I need the packages as a development platform. Thus I need full parallel-installability with KDE 3 (in particular seamless integration in a KDE 3 session, I'm not going to try to develop in a KDE 4 session, especially not with something like your script which breaks running all KDE 3 apps in the session). And frankly, I couldn't care less about full KDE 4 sessions at this point. I'm most likely not going to run the KDE 4 workspace before it becomes the default KDE workspace (replacing KDE 3). (The way the KDE and Fedora timelines align, that might be as soon as Fedora 8. It will require a rock solid compat-kdelibs3 though.) I also don't really have a use for modules like kdenetwork4, kdepim4, kdegraphics4 etc. at the moment, except possibly for the packages which are new in KDE 4 (like Okular). (I'm not opposed to someone packaging them though, the framework is there with my base packages.) On the other hand, you want the latest and greatest snapshot in order to show users what's the latest from KDE development. This is an entirely different use case. For example, a script like your startup script works for you because you want to show only KDE 4 apps anyway, not KDE 3 ones. Kevin Kofler From oisin.feeley at gmail.com Fri Mar 23 16:42:19 2007 From: oisin.feeley at gmail.com (Oisin Feeley) Date: Fri, 23 Mar 2007 12:42:19 -0400 Subject: Quota per directory In-Reply-To: <200703221542.18713.lamont@gurulabs.com> References: <3da3b5b40703210114l1777b50eg6f511846a026778e@mail.gmail.com> <200703210900.46111.lamont@gurulabs.com> <200703221542.18713.lamont@gurulabs.com> Message-ID: On 3/22/07, Lamont Peterson wrote: > If your intent was to suggest that having to create separate filesystems to > set up separate quotas wasn't a problem because LVM makes that so easy, I > totally agree with you. Yup, that was all. I wasn't under the impression that you were arguing for tree quotas, just interested to know what you thought. Thanks. Oisin Feeley From kevin.kofler at chello.at Fri Mar 23 16:42:44 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 23 Mar 2007 16:42:44 +0000 (UTC) Subject: [BUG] Mounted partitions are not showing up and CD/DVD link not correct References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> <1174325858.2713.7.camel@zelda.fubar.dk> <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> <6e24a8e80703191327q1a41f0ebnd313b1bc89d7b258@mail.gmail.com> Message-ID: Mark gmail.com> writes: > well.. how i want to run my Linux is in a way that i can just see all my partitions. i don`t want to be limited with that stuff.perhaps making a on/of switch for this? (on = all partitions visable/mounted off = the way it`s currently done) That's what /etc/fstab is for. Kevin Kofler From kevin.kofler at chello.at Fri Mar 23 16:55:03 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 23 Mar 2007 16:55:03 +0000 (UTC) Subject: [BUG] Mounted partitions are not showing up and CD/DVD link not correct References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> <1174325858.2713.7.camel@zelda.fubar.dk> <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> <6e24a8e80703191327q1a41f0ebnd313b1bc89d7b258@mail.gmail.com> Message-ID: Kevin Kofler chello.at> writes: > > well.. how i want to run my Linux is in a way that i can just see all my > partitions. i don`t want to be limited with that stuff.perhaps making a on/of > switch for this? (on = all partitions visable/mounted off = the way it`s > currently done) > > That's what /etc/fstab is for. PS: If you want a GUI tool rather than the trusty old text editor, there's fwfstab. Kevin Kofler From fedora.lists at burns.me.uk Fri Mar 23 17:01:50 2007 From: fedora.lists at burns.me.uk (Andy Burns) Date: Fri, 23 Mar 2007 17:01:50 +0000 Subject: SSH tunnelled X sessions become unresponsive. Message-ID: For several years I've used either Cygwin/X or more recently Xming as an X server for GUI access to Fedora machines from Windows machines, sometimes with XDMCP but mostly with SSH tunnelling using Putty/Plink. Recently I tried the same to an F7t2 machine, and again today with a rawhide machine that must be pretty close to what is going to be F7t3, Initiating the session with plink.exe and starting gnome-session on the Fedora box tunnelled back to windows, the Gnome session starts up OK, the gnome-panel reacts properly to mouse moves/clicks for a few seconds and then starts running like treacle, only accepting one click every 60 seconds or so, I've checked the same to an FC6 machine and it doesn't occur, I've upgraded to the latest Xming version and it doesn't help. I *think* the version of Xorg in F7/rawhide now uses XCB underneath Xlib as the transport, I don't claim to know all of Xorg's internal plumbing, but could this be related, or be causing some weird SSH/Xorg interaction? If I start Xming as a listening X server on the Windows box, then start a command line Putty/ssh connection to the F7 machine, and initiate a Gnome session back to the Windows box, with export DISPLAY=aaa.bbb.ccc.ddd:0.0 gnome-session & it seems to run for longer, before meeting the same fate I realise this problem involves Xming (and windows) as well as Fedora, but it seems to be F7 related, because FC6 and FC3(!) machines still work OK, any other users doing remote X sessions and having problems? From michel.salim at gmail.com Fri Mar 23 17:35:55 2007 From: michel.salim at gmail.com (Michel Salim) Date: Fri, 23 Mar 2007 13:35:55 -0400 Subject: The need to re-detect usb-storage devices (on resume and on-the-fly plugging) Message-ID: <883cfe6d0703231035s29b4ae7cxc5bbdbfdb993c6d2@mail.gmail.com> I use an external hard drive with my laptop, that is detected and mounted fine (unless HAL and selinux-policy are out of sync) if plugged in at boot time. If I plug the drive after boot, or after resuming, the device node is created properly, but gnome-volume-manager does not register the device and has to be mounted manually. Does gnome-volume-manager currently make a distinction between internal and removable devices? It would make sense to assume USB devices are removable -- sometimes I'd forget to manually unmount a drive before suspending, and in an ideal world this should happen automatically (not sure which subsystem's task it is to do so). Right now, the laptop would resume with the device node still there (e.g. sdb, sdb1), and the device still "mounted" but not accessible, and a new device node is created (sdc, sdc1). Which Bugzilla component should this be filed under? Thanks, -- Michel Salim http://hircus.wordpress.com/ From lsof at nodata.co.uk Fri Mar 23 18:07:45 2007 From: lsof at nodata.co.uk (nodata) Date: Fri, 23 Mar 2007 19:07:45 +0100 Subject: SSH tunnelled X sessions become unresponsive. In-Reply-To: References: Message-ID: <1174673265.3185.0.camel@sb-home.lan> Am Freitag, den 23.03.2007, 17:01 +0000 schrieb Andy Burns: > For several years I've used either Cygwin/X or more recently Xming as > an X server for GUI access to Fedora machines from Windows machines, > sometimes with XDMCP but mostly with SSH tunnelling using Putty/Plink. > > Recently I tried the same to an F7t2 machine, and again today with a > rawhide machine that must be pretty close to what is going to be F7t3, > Initiating the session with plink.exe and starting gnome-session on > the Fedora box tunnelled back to windows, the Gnome session starts up > OK, the gnome-panel reacts properly to mouse moves/clicks for a few > seconds and then starts running like treacle, only accepting one click > every 60 seconds or so, I've checked the same to an FC6 machine and it > doesn't occur, I've upgraded to the latest Xming version and it > doesn't help. > > I *think* the version of Xorg in F7/rawhide now uses XCB underneath > Xlib as the transport, I don't claim to know all of Xorg's internal > plumbing, but could this be related, or be causing some weird SSH/Xorg > interaction? > > If I start Xming as a listening X server on the Windows box, then > start a command line Putty/ssh connection to the F7 machine, and > initiate a Gnome session back to the Windows box, with > > export DISPLAY=aaa.bbb.ccc.ddd:0.0 > gnome-session & > > it seems to run for longer, before meeting the same fate > > I realise this problem involves Xming (and windows) as well as Fedora, > but it seems to be F7 related, because FC6 and FC3(!) machines still > work OK, any other users doing remote X sessions and having problems? > I really think you need to ask this question on the Xming board/list, if there is one. From fedora.lists at burns.me.uk Fri Mar 23 18:16:47 2007 From: fedora.lists at burns.me.uk (Andy Burns) Date: Fri, 23 Mar 2007 18:16:47 +0000 Subject: SSH tunnelled X sessions become unresponsive. In-Reply-To: <1174673265.3185.0.camel@sb-home.lan> References: <1174673265.3185.0.camel@sb-home.lan> Message-ID: On 23/03/07, nodata wrote: > I really think you need to ask this question on the Xming board/list, if > there is one. I have already mentioned it to the Xming developer, but as it seems specific to F7 I thought I'd mention it here in case anyone else was doing remote X sessions from F7 to any /other/ X servers and seeing a similar issue. I do realise that it can get a bit awkward when reporting an issue like which involves non-Fedora software, it would be worse of course if it were a proprietary X server on windows. From david at fubar.dk Fri Mar 23 18:22:02 2007 From: david at fubar.dk (David Zeuthen) Date: Fri, 23 Mar 2007 14:22:02 -0400 Subject: The need to re-detect usb-storage devices (on resume and on-the-fly plugging) In-Reply-To: <883cfe6d0703231035s29b4ae7cxc5bbdbfdb993c6d2@mail.gmail.com> References: <883cfe6d0703231035s29b4ae7cxc5bbdbfdb993c6d2@mail.gmail.com> Message-ID: <1174674122.2756.6.camel@zelda.fubar.dk> On Fri, 2007-03-23 at 13:35 -0400, Michel Salim wrote: > I use an external hard drive with my laptop, that is detected and > mounted fine (unless HAL and selinux-policy are out of sync) if > plugged in at boot time. If I plug the drive after boot, or after > resuming, the device node is created properly, but > gnome-volume-manager does not register the device and has to be > mounted manually. That's a bug. It works for me. > Does gnome-volume-manager currently make a distinction between > internal and removable devices? Yes, we track two attributes 'removable' (you can remove media from the drive) and 'hotpluggable' (you can attach/detach the drive). The latter is using a heuristic; only pccard, firewire, usb is marked as these IIRC. > It would make sense to assume USB > devices are removable -- sometimes I'd forget to manually unmount a > drive before suspending, and in an ideal world this should happen > automatically (not sure which subsystem's task it is to do so). Not necessarily; you should see no changes when resuming unless you of course removed the drive. This works for me FWIW. > Right > now, the laptop would resume with the device node still there (e.g. > sdb, sdb1), and the device still "mounted" but not accessible, and a > new device node is created (sdc, sdc1). That sounds like another bug; it works for me fwiw. Are you using the standard pm-utils utils to suspend/resume? Just asking because some 3rd party tools does stupid stuff (like unloading modules, unmount drives) in their hooks. Include this information in your bug reports. > Which Bugzilla component should this be filed under? Start with g-v-m for both bugs and we can reassign as appropriate. Please paste the bug numbers here too. Thanks. David From markg85 at gmail.com Fri Mar 23 18:36:18 2007 From: markg85 at gmail.com (Mark) Date: Fri, 23 Mar 2007 19:36:18 +0100 Subject: [BUG] Mounted partitions are not showing up and CD/DVD link not correct In-Reply-To: References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> <1174325858.2713.7.camel@zelda.fubar.dk> <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> <6e24a8e80703191327q1a41f0ebnd313b1bc89d7b258@mail.gmail.com> Message-ID: <6e24a8e80703231136s738eba3cyf582a63c9144ea@mail.gmail.com> i used fstab but those partitions are still not showing up. if i delete that policy file those partitions are showing up! in my opinion that`s wrong. 2007/3/23, Kevin Kofler : > > Kevin Kofler chello.at> writes: > > > well.. how i want to run my Linux is in a way that i can just see all > my > > partitions. i don`t want to be limited with that stuff.perhaps making a > on/of > > switch for this? (on = all partitions visable/mounted off = the way it`s > > currently done) > > > > That's what /etc/fstab is for. > > PS: If you want a GUI tool rather than the trusty old text editor, there's > fwfstab. > > Kevin Kofler > > -- > 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 tjb at unh.edu Fri Mar 23 19:22:35 2007 From: tjb at unh.edu (Thomas J. Baker) Date: Fri, 23 Mar 2007 15:22:35 -0400 Subject: iwlwifi working for anyone? Message-ID: <1174677755.25173.33.camel@raptor.sr.unh.edu> I'd like to know if anyone has the iwlwifi driver working with the stock rawhide setup? With NetworkManager, I can see different networks but trying to connect to one doesn't work. It always fails with the "association took too long (>20s), failing activation." error. Thanks, tjb -- ======================================================================= | Thomas Baker email: tjb at unh.edu | | Systems Programmer | | Research Computing Center voice: (603) 862-4490 | | University of New Hampshire fax: (603) 862-1761 | | 332 Morse Hall | | Durham, NH 03824 USA http://wintermute.sr.unh.edu/~tjb | ======================================================================= From kevin.kofler at chello.at Fri Mar 23 19:24:24 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 23 Mar 2007 19:24:24 +0000 (UTC) Subject: [BUG] Mounted partitions are not showing up and CD/DVD link not correct References: <6e24a8e80703190658m3a14ad37q844461b626de5f0b@mail.gmail.com> <6e24a8e80703190732l2b312d5ch7efe719ce5e4d028@mail.gmail.com> <1174319726.2635.2.camel@zelda.fubar.dk> <15e53e180703191032w7f1628fbvb6bd17378f728bfa@mail.gmail.com> <1174325858.2713.7.camel@zelda.fubar.dk> <15e53e180703191056hc680d55u75c07f8ebbf44303@mail.gmail.com> <6e24a8e80703191327q1a41f0ebnd313b1bc89d7b258@mail.gmail.com> <6e24a8e80703231136s738eba3cyf582a63c9144ea@mail.gmail.com> Message-ID: Mark gmail.com> writes: > i used fstab but those partitions are still not showing up. if i delete that policy file those partitions are showing up!in my opinion that`s wrong. Oh, I see what you mean. Nautilus only accepting as "drives" those mounted/mountable through gnome-mount is an unfortunate interaction indeed. On the other hand, it technically makes sense, drives inserted in fstab are considered part of the regular directory tree. Though KDE does list fixed drives mounted through fstab in its media:/ list (and no, it won't automount fixed drives, only removable ones). Kevin Kofler From austinf at cetoncorp.com Fri Mar 23 19:36:22 2007 From: austinf at cetoncorp.com (Austin Foxley) Date: Fri, 23 Mar 2007 12:36:22 -0700 Subject: iwlwifi working for anyone? In-Reply-To: <1174677755.25173.33.camel@raptor.sr.unh.edu> References: <1174677755.25173.33.camel@raptor.sr.unh.edu> Message-ID: <46042C36.7080906@cetoncorp.com> Thomas J. Baker wrote: > I'd like to know if anyone has the iwlwifi driver working with the stock > rawhide setup? With NetworkManager, I can see different networks but > trying to connect to one doesn't work. It always fails with the > "association took too long (>20s), failing activation." error. Yeah I'm seeing the same thing here. Also, iwconfig shows that the card is in 802.11a mode. I tried to manually set it to a "g" frequency, but it just changed back to "a" mode. Austin From joe.ammond at edwardjones.com Fri Mar 23 19:38:34 2007 From: joe.ammond at edwardjones.com (Joe Ammond) Date: Fri, 23 Mar 2007 14:38:34 -0500 Subject: iwlwifi working for anyone? In-Reply-To: <1174677755.25173.33.camel@raptor.sr.unh.edu> References: <1174677755.25173.33.camel@raptor.sr.unh.edu> Message-ID: <1174678714.3242.9.camel@mxl64609fz.edwardjones.com> On Fri, 2007-03-23 at 15:22 -0400, Thomas J. Baker wrote: > I'd like to know if anyone has the iwlwifi driver working with the stock > rawhide setup? With NetworkManager, I can see different networks but > trying to connect to one doesn't work. It always fails with the > "association took too long (>20s), failing activation." error. I haven't tried with the kernel from today, but I've never had any luck connecting on my home network (WPA/TKIP). I'm going to rebuild the laptop with a fresh install of F7T2 this weekend, and will bugzilla it if the problem still occurs (I want to eliminate the possibility that it won't connect due to something I've messed up). ja. -- Joe Ammond joe.ammond at edwardjones.com From hughsient at gmail.com Fri Mar 23 19:42:02 2007 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 23 Mar 2007 19:42:02 +0000 Subject: iwlwifi working for anyone? In-Reply-To: <1174677755.25173.33.camel@raptor.sr.unh.edu> References: <1174677755.25173.33.camel@raptor.sr.unh.edu> Message-ID: <1174678922.2859.11.camel@localhost.localdomain> On Fri, 2007-03-23 at 15:22 -0400, Thomas J. Baker wrote: > I'd like to know if anyone has the iwlwifi driver working with the > stock rawhide setup? With NetworkManager, I can see different networks > but trying to connect to one doesn't work. It always fails with the > "association took too long (>20s), failing activation." error. No. I get a rather spectacular null-dereference oops as well: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233374 I'm unable to use any kernel newer than about 2.6.20-1.2960.fc7 Richard. From drago01 at gmail.com Fri Mar 23 19:57:41 2007 From: drago01 at gmail.com (dragoran dragoran) Date: Fri, 23 Mar 2007 20:57:41 +0100 Subject: Which unresolved bugs block a release? In-Reply-To: References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <1174583457.17842.8.camel@metroid.rdu.redhat.com> Message-ID: On 3/23/07, Andy Burns wrote: > > On 22/03/07, Will Woods wrote: > > > We do actually have some guidelines for this: > > http://fedoraproject.org/wiki/QA/ReleaseCriteria > > I'm surprised that install to dmraid is classed as MUST, yet install > to mdraid isn't even mentioned as SHOULD. good point I disagree on some others mentioned on this page too: "Rescue mode SHOULD also be able to detect/mount RAID/LVM/dmraid/mdraid installations" no it MUST else we ship a release with a useless rescue mode for many setups "All other services available in Core SHOULD start as well. " if a service don't even start!! how could we even _think_ of shipping it? and also update without reinstall should be a MUST.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at xelerance.com Fri Mar 23 20:05:08 2007 From: paul at xelerance.com (Paul Wouters) Date: Fri, 23 Mar 2007 21:05:08 +0100 (CET) Subject: Request to please enable VerifyHostKeyDNS for openssh-clients in FC7 Message-ID: I just installed openssh-clients-4.5p1-2.fc7 and noticed that the option to use SSHFP DNS records is still not enabled. From the man page: VerifyHostKeyDNS Specifies whether to verify the remote key using DNS and SSHFP resource records. If this option is set to yes, the client will implicitly trust keys that match a secure fingerprint from DNS. Insecure fingerprints will be handled as if this option was set to ask. If this option is set to ask, information on fingerprint match will be displayed, but the user will still need to confirm new host keys according to the StrictHostKeyChecking option. The argument must be yes, no, or ask. The default is no. Note that this option applies to protocol version 2 only. See also VERIFYING HOST KEYS in ssh(1). The openssh package maintainer has told me in the past he does not want to enable this option due to the "potential harm of an extra DNS lookup". To me that seems like a weak argument against adding more security, especially since the sshd already does plenty of reverse dns lookups on the client to begin with. And with proper dns configuration, even without having an SSHFP record, the delay of one dns lookup in the ssh client is not going to exceed 100ms. I maintain the "sshfp" package to generate these SSHFP records for hosts or domains based on .ssh/known_hosts or ssy-keyscan, amking it trivially easy for anyone who has their own domain to add SSHFP records to their domain to make sure of this additional security feature. SSHFP records are providing real security. It gives you an additional hint on whether or not you can trust the remote host you are connecting to for the first time. It will add some safetey for people who just hit "yes" now to any new fingerprint presented by the ssh client (yeah sure, no one admits to doing it, but everyone does) Xelerance has deployed SSHFP records for over a year now. We do not see any problems or even experience the extra wait time using an ssh client with VerifyHostKeyDNS enabled. It has been active on all openswan/xelerance domains and never prevented a single ssh client from connecting to those servers. We would really like to see this option enabled by default. If we miss enabling this option for FC7, we will go through at least another six months of changing every install of FC manually to enable this in the /etc/ssh/ssh_config file. Note that by now, RIPE's reverse tree is secured by DNSSEC. This covers all IP space in Europe. The first two CC:TLD's (Sweden and Bulgaria) have also enabled DNSSEC. This provides a very strong protection for SSHFP records, though granted this will take some resolver configurations, which is another topic that Fedora should at some point address for the caching-resolver package. So, I really hope that we can enable SSHFP record lookups in the ssh client in its default configuration file. As a sidenote, upgrading to the test2 version, i noticed there is no openssh-askpass package anymore. Will the upgrade from FC6 to FC7 be able to deal with this properly? Paul From johannes at erdfelt.com Fri Mar 23 20:10:26 2007 From: johannes at erdfelt.com (Johannes Erdfelt) Date: Fri, 23 Mar 2007 13:10:26 -0700 Subject: iwlwifi working for anyone? In-Reply-To: <1174677755.25173.33.camel@raptor.sr.unh.edu> References: <1174677755.25173.33.camel@raptor.sr.unh.edu> Message-ID: <20070323201026.GX2406@sventech.com> On Fri, Mar 23, 2007, Thomas J. Baker wrote: > I'd like to know if anyone has the iwlwifi driver working with the stock > rawhide setup? With NetworkManager, I can see different networks but > trying to connect to one doesn't work. It always fails with the > "association took too long (>20s), failing activation." error. I have it working on my laptop. It's a FC6 system running the test FC7 kernel with iwlwifi support. Howerver, I don't use NetworkManager. It never worked for me. I configured wpa_supplicant myself, started it and then configured the interface up and it worked fine. I have had the interface die once in the middle of using the system, but other than that it works great. JE From david at fubar.dk Fri Mar 23 20:28:18 2007 From: david at fubar.dk (David Zeuthen) Date: Fri, 23 Mar 2007 16:28:18 -0400 Subject: The need to re-detect usb-storage devices (on resume and on-the-fly plugging) In-Reply-To: <1174674122.2756.6.camel@zelda.fubar.dk> References: <883cfe6d0703231035s29b4ae7cxc5bbdbfdb993c6d2@mail.gmail.com> <1174674122.2756.6.camel@zelda.fubar.dk> Message-ID: <1174681698.2756.40.camel@zelda.fubar.dk> On Fri, 2007-03-23 at 14:22 -0400, David Zeuthen wrote: > > Right > > now, the laptop would resume with the device node still there (e.g. > > sdb, sdb1), and the device still "mounted" but not accessible, and a > > new device node is created (sdc, sdc1). > > That sounds like another bug; it works for me fwiw. Actually, I must admit, this doesn't work for me - I just tried. Upon resume (from from disk and from RAM), the kernel emits uevents to remove the devices, then adds them again. I don't see other device nodes being used though - my guess is that you have open files on the drive when you tested this? Hmm.. I can only guess that you didn't mount the partitions through HAL (using gnome-mount or GNOME) because if you did, we would have lazy unmounted the file system when we saw the device node going away... Anyway, I submit that this is a bug with the kernel... although I'm sure some people would argue this is how it works (since bus enum and sending out deltas is *hard*) and that it's not a bug. Anyway, I filed this bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233697 David From lsof at nodata.co.uk Fri Mar 23 21:05:43 2007 From: lsof at nodata.co.uk (nodata) Date: Fri, 23 Mar 2007 22:05:43 +0100 Subject: Request to please enable VerifyHostKeyDNS for openssh-clients in FC7 In-Reply-To: References: Message-ID: <1174683943.5464.1.camel@sb-home.lan> Am Freitag, den 23.03.2007, 21:05 +0100 schrieb Paul Wouters: > I just installed openssh-clients-4.5p1-2.fc7 and noticed that the option > to use SSHFP DNS records is still not enabled. From the man page: > > VerifyHostKeyDNS > Specifies whether to verify the remote key using DNS and SSHFP > resource records. If this option is set to yes, the client > will implicitly trust keys that match a secure fingerprint from > DNS. Insecure fingerprints will be handled as if this option was > set to ask. If this option is set to ask, information on > fingerprint match will be displayed, but the user will still need > to confirm new host keys according to the StrictHostKeyChecking > option. The argument must be yes, no, or ask. The default > is no. Note that this option applies to protocol version 2 > only. > > See also VERIFYING HOST KEYS in ssh(1). > > The openssh package maintainer has told me in the past he does not want > to enable this option due to the "potential harm of an extra DNS lookup". > > To me that seems like a weak argument against adding more security, > especially since the sshd already does plenty of reverse dns lookups on > the client to begin with. And with proper dns configuration, even without > having an SSHFP record, the delay of one dns lookup in the ssh client is > not going to exceed 100ms. > > I maintain the "sshfp" package to generate these SSHFP records for hosts > or domains based on .ssh/known_hosts or ssy-keyscan, amking it trivially > easy for anyone who has their own domain to add SSHFP records to their > domain to make sure of this additional security feature. > > SSHFP records are providing real security. It gives you an additional > hint on whether or not you can trust the remote host you are connecting > to for the first time. It will add some safetey for people who just hit > "yes" now to any new fingerprint presented by the ssh client (yeah sure, > no one admits to doing it, but everyone does) > > Xelerance has deployed SSHFP records for over a year now. We do not > see any problems or even experience the extra wait time using an > ssh client with VerifyHostKeyDNS enabled. It has been active on all > openswan/xelerance domains and never prevented a single ssh client from > connecting to those servers. > > We would really like to see this option enabled by default. If we miss > enabling this option for FC7, we will go through at least another six > months of changing every install of FC manually to enable this in the > /etc/ssh/ssh_config file. > > Note that by now, RIPE's reverse tree is secured by DNSSEC. This covers > all IP space in Europe. The first two CC:TLD's (Sweden and Bulgaria) have > also enabled DNSSEC. This provides a very strong protection for SSHFP > records, though granted this will take some resolver configurations, > which is another topic that Fedora should at some point address for the > caching-resolver package. > > So, I really hope that we can enable SSHFP record lookups in the ssh > client in its default configuration file. > > As a sidenote, upgrading to the test2 version, i noticed there is no > openssh-askpass package anymore. Will the upgrade from FC6 to FC7 be > able to deal with this properly? > > Paul > Can I check something? Is SSHFP not useful unless dnssec is on? From wwoods at redhat.com Fri Mar 23 21:49:58 2007 From: wwoods at redhat.com (Will Woods) Date: Fri, 23 Mar 2007 17:49:58 -0400 Subject: Which unresolved bugs block a release? In-Reply-To: References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <1174583457.17842.8.camel@metroid.rdu.redhat.com> Message-ID: <1174686598.17842.81.camel@metroid.rdu.redhat.com> On Fri, 2007-03-23 at 20:57 +0100, dragoran dragoran wrote: > On 3/23/07, Andy Burns wrote: > On 22/03/07, Will Woods wrote: > > > We do actually have some guidelines for this: > > http://fedoraproject.org/wiki/QA/ReleaseCriteria > > I'm surprised that install to dmraid is classed as MUST, yet > install > to mdraid isn't even mentioned as SHOULD. > > good point I disagree on some others mentioned on this page too: > > "Rescue mode SHOULD also be able to detect/mount > RAID/LVM/dmraid/mdraid installations" > > no it MUST else we ship a release with a useless rescue mode for many > setups Did you actually read the big fat warning at the top of the page? "Items described with the word "MUST" are required to work for all releases, including Test releases. Additionally, the items described with the word "SHOULD" are required for all final releases." In short, "SHOULD" means "REQUIRED FOR FINAL RELEASE". > > and also update without reinstall should be a MUST.... > We're looking into it. -w -------------- 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 Fri Mar 23 22:01:28 2007 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 23 Mar 2007 23:01:28 +0100 Subject: rpms/ettercap/FC-5 ettercap.spec,1.13,1.14 In-Reply-To: <200703231606.l2NG66Zg002695@cvs-int.fedora.redhat.com> References: <200703231606.l2NG66Zg002695@cvs-int.fedora.redhat.com> Message-ID: <20070323220128.GC17494@free.fr> On Fri, Mar 23, 2007 at 12:06:06PM -0400, Jon Ciesla wrote: > Index: ettercap.spec > =================================================================== > RCS file: /cvs/extras/rpms/ettercap/FC-5/ettercap.spec,v > retrieving revision 1.13 > retrieving revision 1.14 > diff -u -r1.13 -r1.14 > --- ettercap.spec 23 Mar 2007 14:54:22 -0000 1.13 > +++ ettercap.spec 23 Mar 2007 16:05:33 -0000 1.14 > @@ -96,7 +96,7 @@ > make install DESTDIR=%{buildroot} > install -c -m 755 src/ettercap-gtk %{buildroot}%{_bindir} > mv %{buildroot}%{_bindir}/ettercap %{buildroot}%{_bindir}/ettercap-tui > -#rm %{buildroot}%{_libdir}/ettercap/*.la > +[ -f %{buildroot}%{_libdir}/ettercap/*.la ] && rm %{buildroot}%{_libdir}/ettercap/*.la > mkdir -p %{buildroot}%{_docdir} > install -c -m 644 %{SOURCE2} %{buildroot}%{_docdir} I think that you should either do rm %{buildroot}%{_libdir}/ettercap/*.la to be sure that the build stops when there is no *.la file, or use the simpler: rm -f %{buildroot}%{_libdir}/ettercap/*.la I would personally prefer a build that stop when files are no longer there, but that is only a personal preference. -- Pat From ajackson at redhat.com Fri Mar 23 22:09:36 2007 From: ajackson at redhat.com (Adam Jackson) Date: Fri, 23 Mar 2007 18:09:36 -0400 Subject: SSH tunnelled X sessions become unresponsive. In-Reply-To: References: Message-ID: <1174687776.25634.4.camel@localhost.localdomain> On Fri, 2007-03-23 at 17:01 +0000, Andy Burns wrote: > I *think* the version of Xorg in F7/rawhide now uses XCB underneath > Xlib as the transport, I don't claim to know all of Xorg's internal > plumbing, but could this be related, or be causing some weird SSH/Xorg > interaction? FC7 isn't using XCB yet, still a little sketchy for my taste. I'm aiming for FC8 for it though. > If I start Xming as a listening X server on the Windows box, then > start a command line Putty/ssh connection to the F7 machine, and > initiate a Gnome session back to the Windows box, with > > export DISPLAY=aaa.bbb.ccc.ddd:0.0 > gnome-session & > > it seems to run for longer, before meeting the same fate My usual method for debugging this sort of thing is to use wireshark to see which side's network traffic is stopping. - ajax From buildsys at fedoraproject.org Fri Mar 23 22:58:29 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 23 Mar 2007 18:58:29 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-23 Message-ID: <20070323225829.B9DEA152130@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 39 SDLmm-0.1.8-4.fc7 cobbler-0.4.5-3.fc7 NEW conmux-0.0-5.493svn.fc7 dbmail-2.2.4-4.fc7 eclipse-nlspackager-0.1.4-2.fc7 ettercap-0.7.3-14.fc7 gimmie-0.2.6-1.fc7 itcl-3.3-0.9.RC1.fc7 jd-1.8.8-0.3.beta070324.fc7 koan-0.2.8-2.fc7 NEW livecd-tools-003-1.fc7 nsd-3.0.5-1.fc7 opensc-0.11.2-0.3.rc1.fc7 perl-Alien-wxWidgets-0.30-1.fc7 NEW perl-Class-Std-0.0.8-1.fc7 NEW perl-ConfigReader-0.5-1.fc7 NEW perl-Data-Password-1.07-1.fc7 perl-Email-MIME-1.859-1.fc7 perl-Email-MIME-ContentType-1.014-1.fc7 perl-Email-MIME-Encodings-1.311-1.fc7 perl-Email-MessageID-1.351-1.fc7 perl-Email-Simple-1.999-1.fc7 NEW perl-FileHandle-Fmode-0.09-2.fc7 NEW perl-LockFile-Simple-0.2.5-1.fc7 NEW perl-MD5-2.03-1.fc7 NEW perl-Mail-RFC822-Address-0.3-1.fc7 perl-Moose-0.18-1.fc7 NEW perl-Proc-ProcessTable-0.41-1.fc7 NEW perl-Sys-SigAction-0.10-1.fc7 perl-Wx-0.70-1.fc7 NEW perl-XML-Filter-XInclude-1.0-1.fc7 NEW perl-XML-Validator-Schema-1.08-1.fc7 qt4-4.2.3-6.fc7 srecord-1.30-1.fc7 syslog-ng-2.0.3-0.20070323.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.3016.fc7 NEW telescope-server-0-0.1.20070315.fc7 uim-1.4.1-1.fc7 xmoto-edit-0.2.4-7.fc7 Packages built and released for Fedora Extras 6: 25 SDLmm-0.1.8-4.fc6 cobbler-0.4.5-3.fc6 NEW conmux-0.0-5.493svn.fc6 dbmail-2.2.4-4.fc6 em8300-kmod-0.16.1-3.2.6.20_1.2933.fc6 ettercap-0.7.3-14.fc6 gimmie-0.2.6-1.fc6 jd-1.8.8-0.3.beta070324.fc6 koan-0.2.8-2.fc6 NEW perl-Class-Std-0.0.8-1.fc6 NEW perl-ConfigReader-0.5-1.fc6 NEW perl-Data-Password-1.07-1.fc6 perl-Email-MIME-1.859-1.fc6 perl-Email-Simple-1.999-1.fc6 NEW perl-FileHandle-Fmode-0.09-2.fc6 NEW perl-LockFile-Simple-0.2.5-1.fc6 NEW perl-MD5-2.03-1.fc6 NEW perl-Mail-RFC822-Address-0.3-1.fc6 perl-Moose-0.18-1.fc6 NEW perl-Proc-ProcessTable-0.41-1.fc6 NEW perl-Sys-SigAction-0.10-1.fc6 NEW perl-XML-Filter-XInclude-1.0-1.fc6 NEW perl-XML-Validator-Schema-1.08-1.fc6 srecord-1.30-1.fc6 xmoto-edit-0.2.4-7.fc6 Packages built and released for Fedora Extras 5: 23 cobbler-0.4.5-0.fc5 NEW conmux-0.0-5.493svn.fc5 dbmail-2.2.4-4.fc5 em8300-kmod-0.16.1-0.2.6.20_1.2307.fc5.2 ettercap-0.7.3-14.fc5.3 jd-1.8.8-0.3.beta070324.fc5 koan-0.2.8-2.fc5 NEW perl-Class-Std-0.0.8-1.fc5 NEW perl-ConfigReader-0.5-1.fc5 NEW perl-Data-Password-1.07-1.fc5 perl-Email-MIME-1.859-1.fc5 perl-Email-Simple-1.999-1.fc5 NEW perl-FileHandle-Fmode-0.09-2.fc5 NEW perl-LockFile-Simple-0.2.5-1.fc5 NEW perl-MD5-2.03-1.fc5 NEW perl-Mail-RFC822-Address-0.3-1.fc5 perl-Moose-0.18-1.fc5 NEW perl-Proc-ProcessTable-0.41-1.fc5 NEW perl-Sys-SigAction-0.10-1.fc5 NEW perl-XML-Filter-XInclude-1.0-1.fc5 NEW perl-XML-Validator-Schema-1.08-1.fc5 srecord-1.30-1.fc5 xmoto-edit-0.2.4-7.fc5.1 cobbler-0.4.5-3.fc7 ------------------- * Fri Mar 23 2007 Michael DeHaan - 0.4.5-3 - Upstream changes (see CHANGELOG) - Fix sticky bit on /var/www/cobbler files * Fri Mar 23 2007 Michael DeHaan - 0.4.4-0 - Upstream changes (see CHANGELOG) * Wed Feb 28 2007 Michael DeHaan - 0.4.3-0 - Upstream changes (see CHANGELOG) - Description cleanup conmux-0.0-5.493svn.fc7 ----------------------- * Thu Mar 15 2007 Bill Peck 0.0-5.493svn - fixed Obsoletes/Provides - minor update to init.d/conmux * Wed Mar 14 2007 Bill Peck 0.0-4.493svn - added jarod's init script. Thanks! * Mon Mar 12 2007 Bill Peck 0.0-3.493svn - release really is 0.0 since there is no upstream release yet. - merge client and common into one package. * Mon Mar 05 2007 Bill Peck 0.1-2.493svn - Removed .svn files from tarball. - install logrotate and config files with -p * Mon Mar 05 2007 Bill Peck 0-1.493svn - changed from perl_sitelib to perl_vendorlib. * Fri Mar 02 2007 Bill Peck 0-0.493svn - Update to latest svn. drop upstream patch. * Mon Feb 26 2007 Bill Peck 0-2.484svn - Remove erroneous chmod on config file. - rename conmux to conmuxd and rename console to conmux * Fri Feb 23 2007 Bill Peck 0-1.484svn - Initial build for Fedora Extras dbmail-2.2.4-4.fc7 ------------------ * Fri Mar 23 2007 Bernard Johnson 2.2.4-4 - actually APPLY the short write patch * Thu Mar 22 2007 Bernard Johnson 2.2.4-3 - patch to eliminate short write messages - use /sbin/service instead of running init scripts directly - requires for initscripts because daemon function in initfile requires it - modern tarballs do not require xmlto and asciidoc to build the docs - change conditionals to give everything sqlite support unless it's built in the fedora buildsystem and %{fedora} < 4 eclipse-nlspackager-0.1.4-2.fc7 ------------------------------- * Fri Mar 23 2007 Kyu Lee 0.1.4-2 - Previous version tagged with wrong files. Just updated release number. * Fri Mar 23 2007 Kyu Lee 0.1.4-1 - Version bump for importing 0.1.4. ettercap-0.7.3-14.fc7 --------------------- * Fri Mar 23 2007 Jon Ciesla - 0.7.3-14 - Alternatives fix by Manuel Wolfshant. - re-ununified.spec. - Please run rpm -e ettercap ettercap-gtk --noscripts before upgrading. - Bump to unified FC5 compat. gimmie-0.2.6-1.fc7 ------------------ * Fri Mar 23 2007 Deji Akingunola - 0.2.6-1 - This release fixes a couple of crashes in 0.2.5 itcl-3.3-0.9.RC1.fc7 -------------------- * Thu Mar 22 2007 Orion Poplawski - 3.3-0.9.RC1 - Rebuild for tcl8.4 downgrade jd-1.8.8-0.3.beta070324.fc7 --------------------------- * Fri Mar 23 2007 Mamoru Tasaka - 1.8.8-0.3.beta070324 - 1.8.8 beta 070324 koan-0.2.8-2.fc7 ---------------- * Fri Mar 23 2007 - Michael DeHaan - 0.2.8-2 - release bump for build system * Fri Mar 23 2007 - Michael DeHaan - 0.2.8-1 - Upstream changes (see CHANGELOG) livecd-tools-003-1.fc7 ---------------------- * Fri Mar 23 2007 Jeremy Katz - 003-1 - fix remaining reference to run-init * Thu Mar 22 2007 Jeremy Katz - 002-1 - update for new version nsd-3.0.5-1.fc7 --------------- * Fri Mar 23 2007 Paul Wouters 3.0.5-1 - Upgraded to 3.0.5 opensc-0.11.2-0.3.rc1.fc7 ------------------------- * Fri Mar 23 2007 Ville Skytt? - 0.11.2-0.3.rc1 - 0.11.2-rc1. perl-Alien-wxWidgets-0.30-1.fc7 ------------------------------- * Fri Mar 23 2007 Jose Pedro Oliveira - 0.30-1 - Update to 0.30. perl-Class-Std-0.0.8-1.fc7 -------------------------- * Thu Mar 15 2007 Andreas Thienemann 0.0.8-1 - Specfile autogenerated by cpanspec 1.69.1. - Adapted for FE perl-ConfigReader-0.5-1.fc7 --------------------------- perl-Data-Password-1.07-1.fc7 ----------------------------- * Thu Mar 15 2007 Andreas Thienemann 1.07-1 - Specfile autogenerated by cpanspec 1.69.1. - Cleaned up for FE perl-Email-MessageID-1.351-1.fc7 -------------------------------- * Fri Mar 23 2007 Jose Pedro Oliveira - 1.351-1 - Update to 1.351. perl-Email-MIME-1.859-1.fc7 --------------------------- * Fri Mar 23 2007 Jose Pedro Oliveira - 1.859-1 - Update to 1.859. perl-Email-MIME-ContentType-1.014-1.fc7 --------------------------------------- * Fri Mar 23 2007 Jose Pedro Oliveira - 1.014-1 - Update to 1.014. perl-Email-MIME-Encodings-1.311-1.fc7 ------------------------------------- * Fri Mar 23 2007 Jose Pedro Oliveira - 1.311-1 - Update to 1.311. - New upstream maintainer. perl-Email-Simple-1.999-1.fc7 ----------------------------- * Fri Mar 23 2007 Jose Pedro Oliveira - 1.999-1 - Update to 1.999. perl-FileHandle-Fmode-0.09-2.fc7 -------------------------------- * Thu Mar 22 2007 Andreas Thienemann 0.09-2 - Fixed EOL-encoding in the packages %doc files. * Sat Mar 10 2007 Andreas Thienemann 0.09-1 - Specfile autogenerated by cpanspec 1.69.1. perl-LockFile-Simple-0.2.5-1.fc7 -------------------------------- perl-Mail-RFC822-Address-0.3-1.fc7 ---------------------------------- * Thu Mar 15 2007 Andreas Thienemann 0.3-1 - Specfile autogenerated by cpanspec 1.69.1. - Cleaned up for FE perl-MD5-2.03-1.fc7 ------------------- perl-Moose-0.18-1.fc7 --------------------- * Fri Mar 23 2007 Chris Weyl 0.18-1 - Sub::Name only needed as a br for Moose < 0.18 - update to 0.18 perl-Proc-ProcessTable-0.41-1.fc7 --------------------------------- * Thu Mar 15 2007 Andreas Thienemann 0.41-1 - Specfile autogenerated by cpanspec 1.69.1. - Cleaned up for FE perl-Sys-SigAction-0.10-1.fc7 ----------------------------- * Thu Mar 15 2007 Andreas Thienemann 0.10-1 - Specfile autogenerated by cpanspec 1.69.1. - Cleaned up for FE perl-Wx-0.70-1.fc7 ------------------ * Fri Mar 23 2007 Jose Pedro Oliveira - 0.70-1 - Update to 0.70. perl-XML-Filter-XInclude-1.0-1.fc7 ---------------------------------- * Thu Mar 15 2007 Andreas Thienemann 1.0-1 - Specfile autogenerated by cpanspec 1.69.1. - Cleaned up for FE perl-XML-Validator-Schema-1.08-1.fc7 ------------------------------------ * Thu Mar 15 2007 Andreas Thienemann 1.08-1 - Specfile autogenerated by cpanspec 1.69.1. - Cleaned up for FE qt4-4.2.3-6.fc7 --------------- * Thu Mar 22 2007 Rex Dieter 4.2.3-6 - -system-sqlite, BR: sqlite-devel - drop mysql_config hackery SDLmm-0.1.8-4.fc7 ----------------- * Fri Mar 23 2007 Hans de Goede 0.1.8-4 - Fixed underquired definition warning in /usr/share/aclocal/sdlmm.m4 srecord-1.30-1.fc7 ------------------ * Fri Mar 23 2007 Jose Pedro Oliveira - 1.30-1 - Update to 1.30. syslog-ng-2.0.3-0.20070323.fc7 ------------------------------ * Fri Mar 23 2007 Jose Pedro Oliveira - 2.0.3-0.20070323 - Update to latest snapshot (2007-03-23). sysprof-kmod-1.0.8-1.2.6.20_1.3016.fc7 -------------------------------------- telescope-server-0-0.1.20070315.fc7 ----------------------------------- * Thu Mar 15 2007 Jef Spaleta - 0-0.1.20070315 - Initial RPM release. uim-1.4.1-1.fc7 --------------- * Mon Mar 19 2007 Akira TAGOH - 1.4.1-1 - New upstream release. - add m17n-db-* and gettext to BR. * Tue Jan 30 2007 Akira TAGOH - 1.4.0-1 - New upstream release. xmoto-edit-0.2.4-7.fc7 ---------------------- * Fri Mar 23 2007 Jon Ciesla 0.2.4-7 - EVR Bump. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From fedora.lists at burns.me.uk Fri Mar 23 23:02:57 2007 From: fedora.lists at burns.me.uk (Andy Burns) Date: Fri, 23 Mar 2007 23:02:57 +0000 Subject: SSH tunnelled X sessions become unresponsive. In-Reply-To: <1174687776.25634.4.camel@localhost.localdomain> References: <1174687776.25634.4.camel@localhost.localdomain> Message-ID: On 23/03/07, Adam Jackson wrote: > FC7 isn't using XCB yet, still a little sketchy for my taste. I'm > aiming for FC8 for it though. Ok, thanks for ruling that out at least > My usual method for debugging this sort of thing is to use wireshark to > see which side's network traffic is stopping. that sounds, errm ... fun, I wouldn't recognize good X protocol over the wire if it slapped me, I'll give it a go though, otherwise I can see that I might end up without remote GUI when F7 comes out, I've put an xming bug into fd.o bugzilla just in case too. From ml at deadbabylon.de Fri Mar 23 23:13:22 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sat, 24 Mar 2007 00:13:22 +0100 Subject: KDE-Live-CD (Round 2): testing of included packages In-Reply-To: <200703212232.41623.ml@deadbabylon.de> References: <200703212232.41623.ml@deadbabylon.de> Message-ID: <20070324001322.2195f1c5@localhost.localdomain> Am Wed, 21 Mar 2007 22:32:35 +0100 schrieb Sebastian Vahl : > And the current version has also some problems: > > - When selinux is enabled the system-config-tools are not working. > Booting with enforcing=0 or selinux=0 avoids this. That is a point > where I need some help because I have not much experiences with > selinux. Ok. This one is fixed with newest selinux-policy. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From paul at xelerance.com Sat Mar 24 00:56:55 2007 From: paul at xelerance.com (Paul Wouters) Date: Sat, 24 Mar 2007 01:56:55 +0100 (CET) Subject: Request to please enable VerifyHostKeyDNS for openssh-clients in FC7 In-Reply-To: <1174683943.5464.1.camel@sb-home.lan> References: <1174683943.5464.1.camel@sb-home.lan> Message-ID: On Fri, 23 Mar 2007, nodata wrote: > Can I check something? Is SSHFP not useful unless dnssec is on? It is still very much useful. First of all, in the case of a trusted network, say a big university campus. Using sshfp records, administrators can add new machines to the network and put their sshfp records in DNS. You will be able to trust the keys for those machines if you trust your campus dns server. The only other known alternative to me for such ssh fingerprint deployments is putting the keys into an LDAP server. Or put it on some web page, which is not very useful for automation. As for when you are on an untrusted network, an attacker would now have to both spoof your traffic to the DNS servers and man in the middle your ssh session. If you would use your own DNS, instead of a dhcp assigned one, the attacker would have to spoof more then just ssh. If you would be using a DNS server through a VPN, the attacker just can't spoof it at all. There is not question that SSHFP will become much more useful when combined with DNSSEC. But DNSSEC is already here and deployed. Some CC:TLD's deploy it. Many testbeds exist, and orgnaisations internally are using it. eg, an ssh session where VerifyHostDNS is enabled, would look like: [paul at bofh ]$ ssh paul at www.xelerance.com The authenticity of host 'www.xelerance.com (193.110.157.145)' can't be established. RSA key fingerprint is ae:e2:07:ed:6e:fe:d9:0a:fc:a1:36:b7:ed:62:35:13. Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)? It is still up to the human to make the decision. When a key would change, eg by a sysadmin or a hacker, you would get the additional LOUD warning about the "mismatching host key fingerprint found in DNS" which would clearly bring the point across that the ssh key changed and the admin didn't update the DNS, so therefor it is likely the admin didn't change the key, and your connection is being 'man in the middled'. To me, the important part is, we do not LOSE anything by enabling it. But we do facilitate early adopters of SSHFP and DNSSEC. Paul From ml at deadbabylon.de Sat Mar 24 02:24:43 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sat, 24 Mar 2007 03:24:43 +0100 Subject: Possibility of F7-Test3-KDE? Message-ID: <20070324032443.03b3cf2d@localhost.localdomain> Hi. I just want to ask how do you think about this question: Will it be anyhow possible to create an _official_ version of a kde livecd for test3? If Max's proposal [1] should come true (and assuming that nobody else is working on this that I am not aware of) we really _need_ at least two test versions. With the last changes to livecd-creator I was able to create a working (and installable) livecd for kde (read: working for me). I think it would be essentially to get some some feedback. ATM the feedback could be much better. Sure: I have some issues that could be done better or that are not working at the moment. But for a test1 of a kde-livecd this should be ok. The current kickstart file for F7-Test3-KDE is attached. If you want to create this, have a look at the wiki [2]. Also the current package list must be discussed [3]. Some comments about the kickstart file: > # create /etc/sysconfig/desktop (needed for installation) > cat > /etc/sysconfig/desktop < DESKTOP="KDE" > DISPLAYMANAGER="KDE" > EOF Due to a bug in anaconda [4] (should be fixed in cvs but haven't tried it yet) KDE is not the standard desktop after an installation. It must be choosed manually after first boot. > # /etc/X11/xinit/xinitrc.d/zz-liveinst.sh is confusing kde on login > # so remove it for now > rm -f /etc/X11/xinit/xinitrc.d/zz-liveinst.sh current version breaks livecd-login [5]. This must also be done after installation. So this is just a workaround for this. Just as this one: > # workaround to put liveinst on desktop (should not be needed but > # /etc/X11/xinit/xinitrc.d/zz-liveinst from anaconda doesn't do this > atm) > cat > /home/fedora/.kde/Autostart/liveinst < #! /bin/bash > cp /usr/share/applications/liveinst.desktop /home/fedora/Desktop/ > sed -i > 's/NoDisplay=true/NoDisplay=false/' /home/fedora/Desktop/liveinst.desktop > END > > chmod +x /home/fedora/.kde/Autostart/liveinst If somebody knows a better solution to get an icon for liveinst on the desktop: Please let me know! And also there is the earlier mentioned issue: > - minor issue: messagebus complains about an username "gdm" And for the moment (until kdenetwork is splitted up): - on laptops kwifimanager is also started (besides knetworkmanager) At this point I really want to thank David Zeuthen and especially Jeremy Katz for their great help and their fast responses to my mails and bug reports. Sebastian [1] http://fedoraproject.org/wiki/Releases/7/MustHave#head-7de80c84584ab7eb76a5697641f82b59887f7f38 [2] http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/KDELiveCD [3] http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/KDELiveCD/PackageList [4] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233472 [5] https://www.redhat.com/archives/fedora-livecd-list/2007-March/msg00189.html -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-fedora-kde.ks Type: application/octet-stream Size: 4107 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Sat Mar 24 03:36:14 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 23 Mar 2007 22:36:14 -0500 Subject: Possibility of F7-Test3-KDE? In-Reply-To: <20070324032443.03b3cf2d@localhost.localdomain> References: <20070324032443.03b3cf2d@localhost.localdomain> Message-ID: Sebastian Vahl wrote: > I just want to ask how do you think about this question: Will it be > anyhow possible to create an _official_ version of a kde livecd for > test3? Yes. The more eyes, testers, feedback, the better. I'd even settle for unofficial status if the sucker has to be hosted elsewhere (but I hope it won't come to that). :) -- Rex From drago01 at gmail.com Sat Mar 24 07:48:19 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 24 Mar 2007 08:48:19 +0100 Subject: Which unresolved bugs block a release? In-Reply-To: <1174686598.17842.81.camel@metroid.rdu.redhat.com> References: <4601EF3B.2030108@redhat.com> <200703212304.36498.jkeating@redhat.com> <1174583457.17842.8.camel@metroid.rdu.redhat.com> <1174686598.17842.81.camel@metroid.rdu.redhat.com> Message-ID: <4604D7C3.5010709@gmail.com> Will Woods wrote: > Did you actually read the big fat warning at the top of the page? > "Items described with the word "MUST" are required to work for all > releases, including Test releases. Additionally, the items described > with the word "SHOULD" are required for all final releases." > > In short, "SHOULD" means "REQUIRED FOR FINAL RELEASE". > > oops... sry ; so just ignore this mail please ;) From buildsys at redhat.com Sat Mar 24 09:55:25 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 24 Mar 2007 05:55:25 -0400 Subject: rawhide report: 20070324 changes Message-ID: <200703240955.l2O9tPVs026472@hs20-bc2-6.build.redhat.com> Updated Packages: anaconda-11.2.0.40-2 -------------------- * Fri Mar 23 2007 Jeremy Katz - 11.2.0.40-2 - fix xinit exiting booty-0.83-1 ------------ * Fri Mar 23 2007 Jeremy Katz - 0.83-1 - make driveorder a property to fix autopart screen boot selection with dmraid devhelp-0.13-5.fc7 ------------------ * Fri Mar 23 2007 Christopher Aillon - 0.13-5 - Rebuild against newer gecko epiphany-2.18.0-3.fc7 --------------------- * Fri Mar 23 2007 Christopher Aillon 2.18.0-3 - Rebuild against newer gecko * Fri Mar 16 2007 Bastien Nocera 2.18.0-2 - Have ephy pick up on the 64-bit plugins (#204547) * Tue Feb 27 2007 Matthias Clasen 2.17.92-1 - Update to 2.17.92 fedora-release-notes-6.92-5 --------------------------- * Fri Mar 23 2007 Paul W. Frields - 6.92-5 - Bump release to include fixes in homepage module * Fri Mar 23 2007 Paul W. Frields - 6.92-4 - Add temporary community help notice to Release Notes for F7 test3 firefox-2.0.0.3-1.fc7 --------------------- * Tue Mar 20 2007 Christopher Aillon 2.0.0.3-1 - Update to 2.0.0.3 * Tue Mar 20 2007 Christopher Aillon 2.0.0.2-3 - Default bookmarks no longer live here; use system-bookmarks hunspell-1.1.4-5.fc7 -------------------- * Fri Jan 19 2007 Caolan McNamara - 1.1.4-5 - .pc * Thu Jan 11 2007 Caolan McNamara - 1.1.4-4 - fix out of range * Fri Dec 15 2006 Caolan McNamara - 1.1.4-3 - hunspell#1616353 simple c api for hunspell kernel-2.6.20-1.3017.fc7 ------------------------ libdhcp-1.24-1.fc7 ------------------ * Fri Mar 23 2007 David Cantrell - 1.24-1 - In pumpSetupInterface(), handle dual stack networks rather than defaulting to the value of the 'ip' structure member (#232690) yelp-2.18.0-2.fc7 ----------------- * Fri Mar 23 2007 Christopher Aillon - 2.18.0-2 - Rebuild against newer gecko 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 markg85 at gmail.com Sat Mar 24 13:50:31 2007 From: markg85 at gmail.com (Mark) Date: Sat, 24 Mar 2007 14:50:31 +0100 Subject: Experimental KDE 3.80.3 specfiles In-Reply-To: References: <20070222225108.693e5e73@localhost.localdomain> <13dbfe4f0703221700k4108147csa4b971382d994a82@mail.gmail.com> <13dbfe4f0703230544g4bb032acq8611324665f55ad@mail.gmail.com> Message-ID: <6e24a8e80703240650y1e3665d7h2a3da51e61479641@mail.gmail.com> wonderfull :) i wonder when the first kde 4 live cd`s will start popping up (eg. based on ubuntu or fedora) 2007/3/23, Kevin Kofler : > > Chitlesh GOORAH fedoraproject.org> writes: > > I don't know in details I didnt have time to have a look at the codes. > > And since your patch was failing, ive just removed it during the > > build. > > It's not really practical to try to merge my patch as a patch. The only > really > practical solution is to redo it: > 1. make a copy of the source directory > 2. run KFileReplace on it with the kde4home.kfr file in > http://www.tigen.org/kevin.kofler/pcprogs/kde-3.80.3-2-specs.tar.bz2 > 3. scan the changes for false positives and revert these. > 4. create a diff. > One way to do step 3 is to take a diff, then open both the original and > patched > directory in Krusader (hooray for 2 panes), and looking at the diff, copy > the > original file back to the patched directory if all changes in a file are > bad, > otherwise use Kompare (select the original file on the left and the > patched one > on the right in Krusader and pick File/Compare by content from the > Krusader > menu, this fires up Kompare) to revert the bad changes only. > There's some manual work in step 3, but it's the highest amount of > automation I > could attain. Mechanically replacing things like .kde with .kde4 is not a > safe > change, I tuned the replacements to avoid false positives as much as it > made > sense, but there's several ones left I can't easily filter out > automatically. > Be warned that this also means some understanding of what the code is > trying to > do is required. > > > The wallpaper willnot be accessible. > > I should dig into it later on to enable plasma. > > As far as I understood, the situation is this: > * Kdesktop has been replaced with krunner. > * Kicker has been replaced with Plasma. > * The desktop functionality (icons, background) has been moved from > kdesktop to > Plasma. > * They replaced (or are replacing, I'm not sure of the exact status) > kdesktop > with krunner before replacing Kicker with Plasma in SVN. > And all this leads to the desktop functionality being temporarily missing. > > > Kevin if you are working on updated specs, I'm ready to host them and > > their srpms. > > Well, sorry, but I'm more likely to upload 3.80.3 packages with some > backported > bugfixes. I collected 2 of them already for bugs which annoyed me, if > anyone > knows a patch in SVN which fixes an annoying bug (NOT a global source > change > like Oxygen or shared-mime-info or an API/ABI change!), please give me the > revision number. (Note that I don't take patches which are not in the > upstream > SVN unless you have a really good reason why I should (i.e. it's > Fedora-specific or required for safe parallel-installability with KDE 3), > please get your fixes upstream first!) > > My plan is that the next version update for my packages will be when KDE > releases the next official snapshot. AFAIK, this will be Alpha 1 around > May > 1st. > > Why? For one, I don't want to redo my parallel-installability patches all > the > time. (As you already noticed, and as explained in the first paragraph, > simply > updating/merging them isn't really feasible.) Updating them for each > official > snapshot is already enough work. And secondly, I'm using these packages to > develop applications (well, currently one application) against them. I > need > packages with a well-defined API which doesn't change all the time, so I > can > specify that my CVS HEAD compiles against KDE 3.80.3, not that it may or > may > not compile against the current HEAD of the KDE SVN trunk depending on the > phase of the moon. ;-) See, this is where our needs differ: I'm a > developer, > and I need the packages as a development platform. Thus I need full > parallel-installability with KDE 3 (in particular seamless integration in > a KDE > 3 session, I'm not going to try to develop in a KDE 4 session, especially > not > with something like your script which breaks running all KDE 3 apps in the > session). And frankly, I couldn't care less about full KDE 4 sessions at > this > point. I'm most likely not going to run the KDE 4 workspace before it > becomes > the default KDE workspace (replacing KDE 3). (The way the KDE and Fedora > timelines align, that might be as soon as Fedora 8. It will require a rock > solid compat-kdelibs3 though.) I also don't really have a use for modules > like > kdenetwork4, kdepim4, kdegraphics4 etc. at the moment, except possibly for > the > packages which are new in KDE 4 (like Okular). (I'm not opposed to someone > packaging them though, the framework is there with my base packages.) On > the > other hand, you want the latest and greatest snapshot in order to show > users > what's the latest from KDE development. This is an entirely different use > case. > For example, a script like your startup script works for you because you > want > to show only KDE 4 apps anyway, not KDE 3 ones. > > Kevin Kofler > > -- > 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 mastahnke at gmail.com Sat Mar 24 15:04:05 2007 From: mastahnke at gmail.com (Michael Stahnke) Date: Sat, 24 Mar 2007 10:04:05 -0500 Subject: Request to please enable VerifyHostKeyDNS for openssh-clients in FC7 In-Reply-To: References: <1174683943.5464.1.camel@sb-home.lan> Message-ID: <7874d9dd0703240804i410fa975v5493bf001e8576b7@mail.gmail.com> I would also vote to enable it. It is a great security feature at almost no cost to the end-user. Mike Stahnke On 3/23/07, Paul Wouters wrote: > On Fri, 23 Mar 2007, nodata wrote: > > > Can I check something? Is SSHFP not useful unless dnssec is on? > > It is still very much useful. > > First of all, in the case of a trusted network, say a big university campus. > Using sshfp records, administrators can add new machines to the network and > put their sshfp records in DNS. You will be able to trust the keys for those > machines if you trust your campus dns server. The only other known alternative > to me for such ssh fingerprint deployments is putting the keys into an LDAP > server. Or put it on some web page, which is not very useful for automation. > > As for when you are on an untrusted network, an attacker would now have to > both spoof your traffic to the DNS servers and man in the middle your ssh > session. If you would use your own DNS, instead of a dhcp assigned one, the > attacker would have to spoof more then just ssh. If you would be using a > DNS server through a VPN, the attacker just can't spoof it at all. > > There is not question that SSHFP will become much more useful when combined > with DNSSEC. But DNSSEC is already here and deployed. Some CC:TLD's deploy it. > Many testbeds exist, and orgnaisations internally are using it. > > eg, an ssh session where VerifyHostDNS is enabled, would look like: > > [paul at bofh ]$ ssh paul at www.xelerance.com > The authenticity of host 'www.xelerance.com (193.110.157.145)' can't be established. > RSA key fingerprint is ae:e2:07:ed:6e:fe:d9:0a:fc:a1:36:b7:ed:62:35:13. > Matching host key fingerprint found in DNS. > Are you sure you want to continue connecting (yes/no)? > > It is still up to the human to make the decision. When a key would change, > eg by a sysadmin or a hacker, you would get the additional LOUD warning > about the "mismatching host key fingerprint found in DNS" which would > clearly bring the point across that the ssh key changed and the admin didn't > update the DNS, so therefor it is likely the admin didn't change the key, > and your connection is being 'man in the middled'. > > To me, the important part is, we do not LOSE anything by enabling it. But we > do facilitate early adopters of SSHFP and DNSSEC. > > Paul > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From darth_linux at ameritech.net Sat Mar 24 16:57:10 2007 From: darth_linux at ameritech.net (eah) Date: Sat, 24 Mar 2007 12:57:10 -0400 Subject: Possibility of F7-Test3-KDE? In-Reply-To: References: <20070324032443.03b3cf2d@localhost.localdomain> Message-ID: <200703241257.10714.darth_linux@ameritech.net> On Friday 23 March 2007 23:36:14 Rex Dieter wrote: > Sebastian Vahl wrote: > > I just want to ask how do you think about this question: Will it be > > anyhow possible to create an _official_ version of a kde livecd for > > test3? > > Yes. The more eyes, testers, feedback, the better. > > I'd even settle for unofficial status if the sucker has to be hosted > elsewhere (but I hope it won't come to that). :) > > -- Rex thank you, Rex. I'd appreciate having Fedora-KDE too. eah From sundaram at fedoraproject.org Sat Mar 24 17:23:51 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 24 Mar 2007 22:53:51 +0530 Subject: Possibility of F7-Test3-KDE? In-Reply-To: <20070324032443.03b3cf2d@localhost.localdomain> References: <20070324032443.03b3cf2d@localhost.localdomain> Message-ID: <46055EA7.6000000@fedoraproject.org> Sebastian Vahl wrote: > Hi. > > I just want to ask how do you think about this question: Will it be > anyhow possible to create an _official_ version of a kde livecd for > test3? If Max's proposal [1] should come true (and assuming that nobody > else is working on this that I am not aware of) we really _need_ at > least two test versions. I always thought of what you were doing as "official". We havent really figured out how to classify spins that different folks will do yet but KDE spin (and live CD) it part of the Fedora 7 plan already. Rex, do bring it up in the next board meeting to confirm. Rahul From jdieter at gmail.com Sat Mar 24 18:33:09 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Sat, 24 Mar 2007 20:33:09 +0200 Subject: Yum-presto (deltarpms) ready for testing. Message-ID: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> Ahmed Kamal and I are pleased to report that Presto, a yum plugin that downloads deltarpms when possible, is ready for wider testing (than the two of us). Warning: It may eat your kittens! RPMs are available from http://hosted.fedoraproject.org/projects/presto/wiki/WikiStart Please report bugs on the project page or e-mail them directly to me. As most of you have heard (over and over), deltarpms are essentially binary diffs between two rpms. They can provide significant savings when you update your system. Please note that we only have deltarpms created for FC6 i386 updates and extras. We will try to add Rawhide and/or 64 bit in the near future, though we are constrained by the space required to mirror them all. The Lebanon Evangelical School has graciously agreed to let us (ab)use their bandwidth and disk space for at least the near future, so please don't worry about overloading our bandwidth. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Sat Mar 24 18:38:29 2007 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 24 Mar 2007 10:38:29 -0800 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> Message-ID: <604aa7910703241138g7c65246drfaccb09bf7179203@mail.gmail.com> On 3/24/07, Jonathan Dieter wrote: > Ahmed Kamal and I are pleased to report that Presto, a yum plugin that > downloads deltarpms when possible, is ready for wider testing (than the > two of us). Warning: It may eat your kittens! > > RPMs are available from > http://hosted.fedoraproject.org/projects/presto/wiki/WikiStart > > Please report bugs on the project page or e-mail them directly to me. I'll set it up on one of my fc6 boxes today. -jef From email.ahmedkamal at googlemail.com Sat Mar 24 19:19:15 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 24 Mar 2007 21:19:15 +0200 Subject: Improvement to rescue mode? In-Reply-To: References: <3da3b5b40703200549v5e0bc6adxe4c40417433aac2d@mail.gmail.com> <45FFEB72.40002@BitWagon.com> <1174423828.11172.10.camel@pensja.lam.pl> Message-ID: <3da3b5b40703241219m7b68f449qf5472f3fdd9292de@mail.gmail.com> What other improvements can be added to rescue mode to provide user-friendly common resuce options? 1- grub-install 2- ? On 3/22/07, Tony Nelson wrote: > > At 6:12 AM -0400 3/21/07, Neal Becker wrote: > >Leszek Matok wrote: > > > >> Dnia 20-03-2007, wto o godzinie 07:10 -0700, John Reiser napisa?(a): > >>> > Why don't you install grub on the broken system and boot it? > >>> Because rescue mode cannot install grub via grub-install; reported as: > >>> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198064 > >>> The mechanism that grub-install uses to identify the "hardware" > >>> is incompatible with the "virtualization" provided by chroot > >>> and rescue mode. > >> But it works with grub-install --root-directory, at least in F6 (fully > >> updated F6 and rescue mode from the original install CD - tested > >> yesterday). The chroot has problems related to mtab, which can be > faked, > >> but --root-directory was simpler and it works. > >> > >> And for the original poster: you can make a boot floppy for your > system. > >> I don't remember if Anaconda still has an option for it, though. > >> > >> Lam > > > >My immediate need is this. I have a system with a pair of scsi > disks. It > >also has 1 SATA drive. For some reason I can't understand, the SATA > drive > >is not seen by the BIOS, so I can't boot off it, but Fedora has no > trouble > >understanding that it's there and is happy to install /boot onto it. Of > >course, I have no way to boot it. > > > >I haven't tried to make a boot floppy in years. Any hints? > > Probably just put the grub bootsector into a file on the floppy, similar > to > booting through NTLDR. > -- > ____________________________________________________________________ > TonyN.:' > ' > > -- > 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 steve at silug.org Sat Mar 24 19:30:22 2007 From: steve at silug.org (Steven Pritchard) Date: Sat, 24 Mar 2007 14:30:22 -0500 Subject: Request to please enable VerifyHostKeyDNS for openssh-clients in FC7 In-Reply-To: References: Message-ID: <20070324193022.GA8945@osiris.silug.org> On Fri, Mar 23, 2007 at 09:05:08PM +0100, Paul Wouters wrote: > We would really like to see this option enabled by default. Is there a RFE in bugzilla? 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 kevin.kofler at chello.at Sat Mar 24 20:34:15 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 24 Mar 2007 20:34:15 +0000 (UTC) Subject: Experimental KDE 3.80.3 specfiles References: <20070222225108.693e5e73@localhost.localdomain> <13dbfe4f0703221700k4108147csa4b971382d994a82@mail.gmail.com> Message-ID: Chitlesh GOORAH fedoraproject.org> writes: > Here are my srpms and rpms for testing purposes only. > http://tux.u-strasbg.fr/~chit/KDE4/ Here's my latest packages, which I have just asked Rex to build for the repo: https://sourceforge.net/project/showfiles.php?group_id=65974&package_id=209969 Compared to yours, they're pretty boring, no pretty Oxygen icons, just 3.80.3 (which was pre-Oxygen) and a few bugfixes (backported from the SVN). But Konqueror and KControl now start up without crashing thanks to one of the fixes I backported. And my packages do have the parallel-installability patchsets, I didn't have to adjust them because the packages are still based on the old 3.80.3. Kevin Kofler From paul at xelerance.com Sat Mar 24 23:05:40 2007 From: paul at xelerance.com (Paul Wouters) Date: Sun, 25 Mar 2007 00:05:40 +0100 (CET) Subject: Request to please enable VerifyHostKeyDNS for openssh-clients in FC7 In-Reply-To: <20070324193022.GA8945@osiris.silug.org> References: <20070324193022.GA8945@osiris.silug.org> Message-ID: On Sat, 24 Mar 2007, Steven Pritchard wrote: > On Fri, Mar 23, 2007 at 09:05:08PM +0100, Paul Wouters wrote: > > We would really like to see this option enabled by default. > > Is there a RFE in bugzilla? I once put this request through bugzilla, but the maintainer closed the issue because he did not want to enable it. I was looking for a broader discussion on this topic, hance the use of this discussion list. Paul From steve at silug.org Sat Mar 24 23:56:13 2007 From: steve at silug.org (Steven Pritchard) Date: Sat, 24 Mar 2007 18:56:13 -0500 Subject: Request to please enable VerifyHostKeyDNS for openssh-clients in FC7 In-Reply-To: References: <20070324193022.GA8945@osiris.silug.org> Message-ID: <20070324235613.GB8945@osiris.silug.org> On Sun, Mar 25, 2007 at 12:05:40AM +0100, Paul Wouters wrote: > On Sat, 24 Mar 2007, Steven Pritchard wrote: > > Is there a RFE in bugzilla? > > I once put this request through bugzilla, but the maintainer closed the > issue because he did not want to enable it. I was looking for a > broader discussion on this topic, hance the use of this discussion list. Bugs can be reopened. What's the bug #? FWIW, this sounds like a no-brainer to me... 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 ml at deadbabylon.de Sun Mar 25 00:15:55 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sun, 25 Mar 2007 01:15:55 +0100 Subject: Possibility of F7-Test3-KDE? In-Reply-To: References: <20070324032443.03b3cf2d@localhost.localdomain> Message-ID: <20070325011555.59f3dd4f@localhost.localdomain> Am Fri, 23 Mar 2007 22:36:14 -0500 schrieb Rex Dieter : > Sebastian Vahl wrote: > > > I just want to ask how do you think about this question: Will it be > > anyhow possible to create an _official_ version of a kde livecd for > > test3? > > Yes. The more eyes, testers, feedback, the better. So I think, too. Especially the "look & feel" of KDE needs some testing. > I'd even settle for unofficial status if the sucker has to be hosted > elsewhere (but I hope it won't come to that). :) I would prefer an official created and shipped one. But if this is not possible an unofficial one would be better than no one. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ml at deadbabylon.de Sun Mar 25 00:44:22 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Sun, 25 Mar 2007 01:44:22 +0100 Subject: Possibility of F7-Test3-KDE? In-Reply-To: <46055EA7.6000000@fedoraproject.org> References: <20070324032443.03b3cf2d@localhost.localdomain> <46055EA7.6000000@fedoraproject.org> Message-ID: <20070325014422.6d69044c@localhost.localdomain> Am Sat, 24 Mar 2007 22:53:51 +0530 schrieb Rahul Sundaram : > Sebastian Vahl wrote: > > Hi. > > > > I just want to ask how do you think about this question: Will it be > > anyhow possible to create an _official_ version of a kde livecd for > > test3? If Max's proposal [1] should come true (and assuming that > > nobody else is working on this that I am not aware of) we really > > _need_ at least two test versions. > > I always thought of what you were doing as "official". In the past I was not thinking that my work would be viewed as "official". I myself was thinking that it would only prepare the ground to an official KDE-LiveCD. But this may have changed. I'm glad that I don't have the time atm to worry about that. :) > We havent really figured out how to classify spins that different > folks will do yet but KDE spin (and live CD) it part of the Fedora 7 > plan already. An interesting question here would be if localized versions of the KDE-LiveCD would be official or unofficial ones. The normal version could not include all languages so it's up to the local commnities to create this ones. ATM I'm also working to create a template for this localized versions to make the creation as easy as possible. I myself would create a german version (so I think atm). But this ones would be not really testet (at least for the localized part) so I think they should be unofficial. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From davej at redhat.com Sun Mar 25 01:09:23 2007 From: davej at redhat.com (Dave Jones) Date: Sat, 24 Mar 2007 21:09:23 -0400 Subject: rawhide report: 20070323 changes In-Reply-To: <1174646043.2857.4.camel@localhost.localdomain> References: <200703230951.l2N9pWXR021914@hs20-bc2-6.build.redhat.com> <1174646043.2857.4.camel@localhost.localdomain> Message-ID: <20070325010923.GA27612@redhat.com> On Fri, Mar 23, 2007 at 10:34:03AM +0000, Richard Hughes wrote: > On Fri, 2007-03-23 at 05:51 -0400, buildsys at redhat.com wrote: > > kernel-2.6.20-1.3016.fc7 > > ------------------------ > > * Thu Mar 22 2007 Dave Jones > > - 2.6.21-rc4-git6 > > Any chance we can update to the latest snapshot of xf86-video-nouveau > and libdrm? Probably a good idea, as its been a while. I'll leave that to Ajax to coordinate however. Dave -- http://www.codemonkey.org.uk From paul at xelerance.com Sun Mar 25 02:18:18 2007 From: paul at xelerance.com (Paul Wouters) Date: Sun, 25 Mar 2007 04:18:18 +0200 (CEST) Subject: Request to please enable VerifyHostKeyDNS for openssh-clients in FC7 In-Reply-To: <20070324235613.GB8945@osiris.silug.org> References: <20070324193022.GA8945@osiris.silug.org> <20070324235613.GB8945@osiris.silug.org> Message-ID: On Sat, 24 Mar 2007, Steven Pritchard wrote: > On Sun, Mar 25, 2007 at 12:05:40AM +0100, Paul Wouters wrote: > > On Sat, 24 Mar 2007, Steven Pritchard wrote: > > > Is there a RFE in bugzilla? > > > > I once put this request through bugzilla, but the maintainer closed the > > issue because he did not want to enable it. I was looking for a > > broader discussion on this topic, hance the use of this discussion list. > > Bugs can be reopened. What's the bug #? > > FWIW, this sounds like a no-brainer to me... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180277 Paul From vonbrand at inf.utfsm.cl Sun Mar 25 01:50:47 2007 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sat, 24 Mar 2007 21:50:47 -0400 Subject: iwlwifi working for anyone? In-Reply-To: <1174677755.25173.33.camel@raptor.sr.unh.edu> References: <1174677755.25173.33.camel@raptor.sr.unh.edu> Message-ID: <200703250150.l2P1oloF016001@laptop13.inf.utfsm.cl> Thomas J. Baker wrote: > I'd like to know if anyone has the iwlwifi driver working with the stock > rawhide setup? With NetworkManager, I can see different networks but > trying to connect to one doesn't work. It always fails with the > "association took too long (>20s), failing activation." error. Lucky you, here it doesn't even seem to find the driver. -- 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 Lam at Lam.pl Sun Mar 25 08:56:08 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 25 Mar 2007 10:56:08 +0200 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> Message-ID: <1174812968.6248.4.camel@pensja.lam.pl> Dnia 24-03-2007, sob o godzinie 20:33 +0200, Jonathan Dieter napisa?(a): > RPMs are available from > http://hosted.fedoraproject.org/projects/presto/wiki/WikiStart Error: Missing Dependency: deltarpm >= 3.4 is needed by package yum-presto Am I right that in order to update FC6, I have to have Rawhide instead? :) It would be good to provide dependencies in the "presto" repository, if it really can't be compiled against deltarpm present in FE6. > Please report bugs on the project page or e-mail them directly to me. FC6's Evolution doesn't allow me to reply to author, so I'm writing here in protest. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From email.ahmedkamal at googlemail.com Sun Mar 25 09:32:04 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sun, 25 Mar 2007 11:32:04 +0200 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174812968.6248.4.camel@pensja.lam.pl> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <1174812968.6248.4.camel@pensja.lam.pl> Message-ID: <3da3b5b40703250232t24ef5133yfafe6ae3b0da6a9b@mail.gmail.com> Yes, deltarpm in FE cannot be used (we need fixes from upstream available only in newer versions) The needed new version is available from the presto page http://www.lesbg.com/jdieter/presto/deltarpm-3.4-1.i386.rpm I guess you could also install the rawhide one yum -y --disablerepo=* --enablerepo=extras-development install deltarpm Encouraging everyone to test and report bugs On 3/25/07, Leszek Matok wrote: > > Dnia 24-03-2007, sob o godzinie 20:33 +0200, Jonathan Dieter napisa?(a): > > RPMs are available from > > http://hosted.fedoraproject.org/projects/presto/wiki/WikiStart > Error: Missing Dependency: deltarpm >= 3.4 is needed by package yum-presto > > Am I right that in order to update FC6, I have to have Rawhide > instead? :) It would be good to provide dependencies in the "presto" > repository, if it really can't be compiled against deltarpm present in > FE6. > > > Please report bugs on the project page or e-mail them directly to me. > FC6's Evolution doesn't allow me to reply to author, so I'm writing here > in protest. > > Lam > > -- > 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 buildsys at redhat.com Sun Mar 25 10:04:03 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sun, 25 Mar 2007 06:04:03 -0400 Subject: rawhide report: 20070325 changes Message-ID: <200703251004.l2PA438S019374@hs20-bc2-6.build.redhat.com> Updated Packages: ifd-egate-0.05-17 ----------------- * Fri Mar 23 2007 Jack Magne 0.05-17 - Change to udev rule to get token removals recognized Bug# 232983 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 paul at all-the-johnsons.co.uk Sun Mar 25 10:30:32 2007 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 25 Mar 2007 11:30:32 +0100 Subject: rawhide report: 20070324 changes In-Reply-To: <200703240955.l2O9tPVs026472@hs20-bc2-6.build.redhat.com> References: <200703240955.l2O9tPVs026472@hs20-bc2-6.build.redhat.com> Message-ID: <1174818632.3183.72.camel@T7.Linux> Hi, > Updated Packages: This is really odd. It's 11:29 BST here and these packages don't seem to have been published. yum is updating FireFox to 2.0.0.2-2 for example. Is anyone else seeing this? TTFN Paul -- Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- 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 Sun Mar 25 10:35:46 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Sun, 25 Mar 2007 12:35:46 +0200 Subject: Improvement to rescue mode? In-Reply-To: <3da3b5b40703241219m7b68f449qf5472f3fdd9292de@mail.gmail.com> References: <3da3b5b40703200549v5e0bc6adxe4c40417433aac2d@mail.gmail.com> <45FFEB72.40002@BitWagon.com> <1174423828.11172.10.camel@pensja.lam.pl> <3da3b5b40703241219m7b68f449qf5472f3fdd9292de@mail.gmail.com> Message-ID: <1174818946.16679.6.camel@gilboa-work-dev.localdomain> On Sat, 2007-03-24 at 21:19 +0200, Ahmed Kamal wrote: > What other improvements can be added to rescue mode to provide > user-friendly common resuce options? > 1- grub-install > 2- ? Can we have Xvesa + wm? If so, 1. gparted. 2. system-config-packages, -lvm (and the rest of system-config-xxx) - Gilboa From jdieter at gmail.com Sun Mar 25 11:06:53 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Sun, 25 Mar 2007 14:06:53 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174812968.6248.4.camel@pensja.lam.pl> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <1174812968.6248.4.camel@pensja.lam.pl> Message-ID: <1174820813.19925.1.camel@jndwidescreen.lesbg.loc> On Sun, 2007-03-25 at 10:56 +0200, Leszek Matok wrote: > Am I right that in order to update FC6, I have to have Rawhide > instead? :) It would be good to provide dependencies in the "presto" > repository, if it really can't be compiled against deltarpm present in > FE6. > Fair enough. I've put deltarpm 3.4 into the presto repository, so if you're using yum, you'll get it. Jonathan -------------- 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 tjanouse at redhat.com Sun Mar 25 11:41:17 2007 From: tjanouse at redhat.com (Tomas Janousek) Date: Sun, 25 Mar 2007 13:41:17 +0200 Subject: rawhide report: 20070324 changes In-Reply-To: <1174818632.3183.72.camel@T7.Linux> References: <200703240955.l2O9tPVs026472@hs20-bc2-6.build.redhat.com> <1174818632.3183.72.camel@T7.Linux> Message-ID: <20070325114117.GA2279@redhat.com> Hi, On Sun, Mar 25, 2007 at 11:30:32AM +0100, Paul wrote: > This is really odd. It's 11:29 BST here and these packages don't seem to > have been published. yum is updating FireFox to 2.0.0.2-2 for example. yum list firefox shows 2.0.0.3 here. You must be using some yet unsynced mirror. -- TJ. (Brno, CZ), BaseOS, Red Hat From Lam at Lam.pl Sun Mar 25 12:16:14 2007 From: Lam at Lam.pl (Leszek Matok) Date: Sun, 25 Mar 2007 14:16:14 +0200 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174820813.19925.1.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <1174812968.6248.4.camel@pensja.lam.pl> <1174820813.19925.1.camel@jndwidescreen.lesbg.loc> Message-ID: <1174824974.6248.5.camel@pensja.lam.pl> Dnia 25-03-2007, nie o godzinie 14:06 +0300, Jonathan Dieter napisa?(a): > Fair enough. I've put deltarpm 3.4 into the presto repository, so if > you're using yum, you'll get it. Size of all updates downloaded from Presto-enabled repositories: 78938 bytes Size updates would have been downloaded if Presto wasn't enabled: 19729038 bytes This is a savings of 100 percent It works, thanks! Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From samfw at redhat.com Sun Mar 25 13:27:01 2007 From: samfw at redhat.com (Sam Folk-Williams) Date: Sun, 25 Mar 2007 09:27:01 -0400 Subject: openofice constantly crashing Message-ID: <20070325132700.GL9976@unplugged.rdu.redhat.com> In rawhide... when I open any oo.o document it crashes immediately. When I open a new document, it crashes as soon as i type one character into the document: [sam at localhost ~]$ strace -o oowriter.strace oowriter /usr/lib/openoffice.org/program/swriter.bin: symbol lookup error: /usr/lib/openoffice.org/program/libspell680li.so: undefined symbol: _ZN8Hunspell5spellEPKc strace attached. Known issue? [sam at localhost ~]$ rpm -qa |grep openoffice openoffice.org-core-2.2.0-12.1 openoffice.org-impress-2.2.0-12.1 openoffice.org-graphicfilter-2.2.0-12.1 openoffice.org-writer-2.2.0-12.1 openoffice.org-math-2.2.0-12.1 openoffice.org-xsltfilter-2.2.0-12.1 openoffice.org-calc-2.2.0-12.1 openoffice.org-draw-2.2.0-12.1 Thanks, Sam -- Sam Folk-Williams, RHCE Red Hat Global Support Services Phone: 919/754-4558 GPG ID: 1B0D46BA From paul at all-the-johnsons.co.uk Sun Mar 25 13:39:06 2007 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 25 Mar 2007 14:39:06 +0100 Subject: openofice constantly crashing In-Reply-To: <20070325132700.GL9976@unplugged.rdu.redhat.com> References: <20070325132700.GL9976@unplugged.rdu.redhat.com> Message-ID: <1174829946.3183.93.camel@T7.Linux> Hi, > In rawhide... when I open any oo.o document it crashes immediately. When I open > a new document, it crashes as soon as i type one character into the document: Disable hunspell - just set the check spelling as you type option to be off (though the version from yesterday's rawhide should have fixed the problem). TTFN Paul -- Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- 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 txtoth at gmail.com Sun Mar 25 14:24:41 2007 From: txtoth at gmail.com (Xavier Toth) Date: Sun, 25 Mar 2007 08:24:41 -0600 Subject: VESA driver hsync config problem Message-ID: For awhile now I've been struggling with what is probably a Vesa driver issue related to but different from Fedora Core bug# 10238. I'm running the latest X (7.2) under FC6 in a Parallels VM on a Mac and the server won't start unless I specify the HorizSync in the Monitor section of xorg.conf. I dug around and found references to vesa-1.3.0-range-hack.patch which I applied but this made no difference. My group is putting together a livecd for demo purposes and the xorg.conf generated by system-config-display (FC6) doesn't add a HorizSync so X won't start. Hopefully someone will have an idea how to fix this otherwise I might have to hack the config to add the HorizSync as an interim solution, any thoughts? From buildsys at fedoraproject.org Sun Mar 25 16:04:05 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Sun, 25 Mar 2007 12:04:05 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-25 Message-ID: <20070325160406.01685152130@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 32 Democracy-0.9.5.1-6.fc7 Django-0.96-1.fc7 Terminal-0.2.6-2.fc7 NEW amqp-0.8-2rhm.1.fc7 bittorrent-4.4.0-5.fc7 chmsee-1.0.0-0.12.beta.fc7 epiphany-extensions-2.18.0-2 flow-tools-0.68-16.fc7 NEW g3data-1.5.1-4.fc7 galeon-2.0.3-8.fc7 ganglia-3.0.4-2.fc7 NEW jython-2.2-0.3.Release_2_2beta1.1jpp.2.fc7 kazehakase-0.4.4.1-4.fc7 NEW libedit-2.10-1.20070302cvs.fc7 libmpd-0.13.0-1.fc7 libreadline-java-0.8.0-15.fc7 liferea-1.2.9-1.fc7 NEW mecab-ipadic-2.7.0.20060707-2.fc7 NEW nginx-0.5.15-3.fc7 obexftp-0.22-0.1.pre4 perl-Apache-DBI-1.06-1.fc7 NEW perl-GD-SVG-0.28-1.fc7 NEW perl-Graph-0.81-1.fc7 perl-POE-0.9989-1.fc7 perl-Params-Check-0.26-1.fc7 NEW perl-SVG-2.33-2.fc7 perl-Test-Prereq-1.033-1.fc7 NEW perl-Text-Shellwords-1.08-1.fc7 python-sqlalchemy-0.3.6-1.fc7 NEW ragel-5.19-4.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.3017.fc7 zaptel-1.4.1-3.fc7 Packages built and released for Fedora Extras 6: 19 Terminal-0.2.6-2.fc6 bittorrent-4.4.0-5.fc6 flow-tools-0.68-16.fc6 NEW g3data-1.5.1-4.fc6 lucidlife-0.9.1-2.fc6 NEW mecab-ipadic-2.7.0.20060707-2.fc6 NEW nginx-0.5.15-3.fc6 perl-Apache-DBI-1.06-1.fc6 NEW perl-GD-SVG-0.28-1.fc6 NEW perl-Graph-0.81-1.fc6 perl-POE-0.9989-1.fc6 NEW perl-SVG-2.33-2.fc6 NEW perl-Text-Shellwords-1.08-1.fc6 php-pecl-zip-1.8.8-1.fc6 python-sqlalchemy-0.3.6-1.fc6 NEW ragel-5.19-4.fc6 sysprof-kmod-1.0.8-1.2.6.20_1.2933.fc6 NEW telescope-server-0-0.1.20070315.fc6 zaptel-1.4.1-3.fc6 Packages built and released for Fedora Extras 5: 14 bittorrent-4.4.0-5.fc5 flow-tools-0.68-16.fc5 inkscape-0.45.1-1.fc5 NEW mecab-ipadic-2.7.0.20060707-2.fc5 NEW nginx-0.5.15-3.fc5 perl-Apache-DBI-1.06-1.fc5 NEW perl-GD-SVG-0.28-1.fc5 NEW perl-Graph-0.81-1.fc5 perl-POE-0.9989-1.fc5 NEW perl-SVG-2.33-2.fc5 NEW perl-Text-Shellwords-1.08-1.fc5 php-pecl-zip-1.8.8-1.fc5 NEW ragel-5.19-4.fc5 sysprof-kmod-1.0.8-1.2.6.20_1.2307.fc5 amqp-0.8-2rhm.1.fc7 ------------------- * Thu Mar 22 2007 Nuno Santos - 0.8-2rhm.1 - Comply with Fedora packaging guidelines bittorrent-4.4.0-5.fc7 ---------------------- * Sun Mar 25 2007 Paul Howarth 4.4.0-5 - Own directory /srv/bittorrent (#233824) chmsee-1.0.0-0.12.beta.fc7 -------------------------- * Sat Mar 24 2007 Yijun Yuan - 1.0.0-0.12.beta - update for firefox 2.0.0.3 Democracy-0.9.5.1-6.fc7 ----------------------- * Fri Mar 23 2007 Thorsten Scherf 0.9.5.1-6 - New build for Fedora 7 - moved to Firefox 2 * Thu Mar 01 2007 Thorsten Scherf 0.9.5.1-5 - changed install req to a versioned firefox package Django-0.96-1.fc7 ----------------- * Sat Mar 24 2007 Michel Salim - 0.96-1 - New upstream version epiphany-extensions-2.18.0-2 ---------------------------- * Sat Mar 24 2007 Peter Gordon - 2.18.0-2 - Rebuild against new Gecko release (Firefox 2.0.0.3). flow-tools-0.68-16.fc7 ---------------------- * Sun Mar 25 2007 Paul P Komkoff Jr - 0.68-16 - getopt() is now in unistd.h * Sun Mar 18 2007 Paul P Komkoff Jr - 0.68-15 - Add runtime dependency for python-rrdtool * Fri Dec 15 2006 Paul P. Komkoff Jr - rebuilt g3data-1.5.1-4.fc7 ------------------ * Wed Mar 21 2007 Jef Spaleta 1.5.1-4 - clean up of buildrequires and ensure use of RPM_OPT_FLAGS * Sun Mar 18 2007 Jef Spaleta 1.5.1-3 - Minor pixmap location fix - Updated upstream url locations * Sat Mar 17 2007 Jef Spaleta 1.5.1-2 - Added desktop file and icon * Fri Mar 16 2007 Jef Spaleta 1.5.1-1 - Initial package meant for submission into Fedora Extras galeon-2.0.3-8.fc7 ------------------ * Sun Mar 25 2007 Denis Leroy - 2.0.3-8 - Rebuild with gecko-libs 1.8.1.3 (firefox 2.0.0.3) * Thu Mar 01 2007 Denis Leroy - 2.0.3-7 - Rebuild with gecko-libs 1.8.1.2 (firefox 2.0.0.2) ganglia-3.0.4-2.fc7 ------------------- * Sat Mar 24 2007 Jarod Wilson 3.0.4-2 - Own created directories (#233790) jython-2.2-0.3.Release_2_2beta1.1jpp.2.fc7 ------------------------------------------ * Fri Mar 23 2007 Thomas Fitzsimmons - 2.2-0.3.Release_2_2beta1.1jpp.2 - Fix -Dpython.console.readlinelib=Editline typo. - Fix LICENSE.txt location in jython-nofullbuildpath.patch. - Require libreadline-java-devel. - Check for libJavaEditline.so explicitly in wrapper script. * Wed Feb 28 2007 Andrew Overholt 2.2-0.3.Release_2_2beta1.1jpp.1 - 2.2beta1 - Use 0.z.tag.Xjpp.Y release format - Remove unnecessary copy of python 2.2 library kazehakase-0.4.4.1-4.fc7 ------------------------ * Sat Mar 24 2007 Mamoru Tasaka - 0.4.4.1-4 - gecko engine update * Tue Feb 27 2007 Mamoru Tasaka - 0.4.4.1-3.dist.1 - gecko engine update * Sat Feb 24 2007 Mamoru Tasaka - enable anthy/mecab support (currently disabled) libedit-2.10-1.20070302cvs.fc7 ------------------------------ * Fri Mar 23 2007 Thomas Fitzsimmons - 2.10-1.20070302cvs - Take ownership of libedit package. - Import libedit 2.10 20070302 snapshot. libmpd-0.13.0-1.fc7 ------------------- * Sun Mar 25 2007 Adrian Reber - 0.13.0-1 - update to 0.13.0 libreadline-java-0.8.0-15.fc7 ----------------------------- * Fri Mar 23 2007 Thomas Fitzsimmons - 0.8.0-15 - Fix libJavaEditline.so symlink typo. * Fri Mar 23 2007 Thomas Fitzsimmons - 0.8.0-14 - Rebuild against unorphaned libedit. liferea-1.2.9-1.fc7 ------------------- * Sat Mar 24 2007 Brian Pepple - 1.2.9-1 - Update to 1.2.9. mecab-ipadic-2.7.0.20060707-2.fc7 --------------------------------- * Sat Mar 24 2007 Mamoru Tasaka - 2.7.0.20060707-2 - Fix typo * Thu Mar 08 2007 Mamoru Tasaka - 2.7.0.20060707-1 - Initial packaging, based on mecab-jumandic spec file nginx-0.5.15-3.fc7 ------------------ * Fri Mar 23 2007 Jeremy Hinegardner - 0.5.15-3 - fixed package review bugs (#235222) given by ruben at rubenkerkhof.com * Thu Mar 22 2007 Jeremy Hinegardner - 0.5.15-2 - fixed package review bugs (#233522) given by kevin at tummy.com * Thu Mar 22 2007 Jeremy Hinegardner - 0.5.15-1 - create patches to assist with building for Fedora - initial packaging for Fedora obexftp-0.22-0.1.pre4 --------------------- * Fri Mar 23 2007 Dominik Mierzejewski - 0.22-0.1.pre4 - updated to 0.22-pre4 - updated patches perl-Apache-DBI-1.06-1.fc7 -------------------------- * Sun Mar 25 2007 Remi Collet 1.06-1 - update to 1.06 perl-GD-SVG-0.28-1.fc7 ---------------------- * Wed Mar 14 2007 Alex Lancaster 0.28-1 - Update to 0.28 - Fix rpmlint errors perl-Graph-0.81-1.fc7 --------------------- * Fri Mar 23 2007 Alex Lancaster 0.81-1 - Update to 0.81 perl-Params-Check-0.26-1.fc7 ---------------------------- * Fri Mar 23 2007 Steven Pritchard 0.26-1 - Update to 0.26. - Use fixperms macro instead of our own chmod incantation. - BR ExtUtils::MakeMaker. perl-POE-0.9989-1.fc7 --------------------- * Fri Mar 23 2007 Chris Weyl 0.9989-1 - update to 0.9989 perl-SVG-2.33-2.fc7 ------------------- * Fri Mar 23 2007 Alex Lancaster 2.33-2 - Filter extra non-explicit (SVG::Element) provides * Wed Mar 14 2007 Alex Lancaster 2.33-1 - Update to 2.33 - Fix rpmlint issues perl-Test-Prereq-1.033-1.fc7 ---------------------------- * Fri Mar 23 2007 Steven Pritchard 1.033-1 - Update to 1.033. perl-Text-Shellwords-1.08-1.fc7 ------------------------------- * Fri Mar 23 2007 Alex Lancaster 1.08-1 - Updated to 1.08 - Removed superfluous BR: Perl as per suggestion from Ralf Corsepius python-sqlalchemy-0.3.6-1.fc7 ----------------------------- * Fri Mar 23 2007 Toshio Kuratomi - 0.3.6-1 - Update to new upstream version 0.3.6 ragel-5.19-4.fc7 ---------------- * Sat Mar 24 2007 Jeremy Hinegardner - 5.19-4 - further replacement of rlcodegen - rework patches * Fri Mar 23 2007 Jeremy Hinegardner - 5.19-3 - replace RPM_BUILD_ROOT in spec file with buildroot macro - cleanup rpmlint errors for the src.rpm - add ragel(1) man page patch * Tue Mar 20 2007 Jeremy Hinegardner - 5.19-1 - Creation of spec file sysprof-kmod-1.0.8-1.2.6.20_1.3017.fc7 -------------------------------------- Terminal-0.2.6-2.fc7 -------------------- * Sat Mar 24 2007 Kevin Fenzi - 0.2.6-2 - Fix unowned directories (#233787) zaptel-1.4.1-3.fc7 ------------------ * Fri Mar 23 2007 Jeffrey C. Ollie - 1.4.1-3 - Really, really make it work without the kernel sources... * Fri Mar 23 2007 Jeffrey C. Ollie - 1.4.1-2 - Let's see if we can get this to build without the kernel sources present. * Fri Mar 23 2007 Jeffrey C. Ollie - 1.4.1-1 - Update to 1.4.1 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From tmz at pobox.com Sun Mar 25 17:45:41 2007 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 25 Mar 2007 13:45:41 -0400 Subject: signatures for non-rpm files in $arch/os trees? Message-ID: <20070325174541.GF27119@psilocybe.teonanacatl.org> Hi all, Is there some way to verify the integrity of the non-rpm files included in the $arch/os tree? I'm thinking of the images/ specifically. If I want to kick off an install I could download the rescue disk iso, check the gpg sig on the SHA1SUM file, and then verify the sha1sum for the rescue image. But if I just want to grab boot.iso or diskboot.img and do the same thing, I don't know of a way to verify those images. Is there some way to do this or is there good reason that doing so is pointless? -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== Marriages are made in heaven. But so are thunder, lightning, and hail. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From markg85 at gmail.com Sun Mar 25 20:55:15 2007 From: markg85 at gmail.com (Mark) Date: Sun, 25 Mar 2007 22:55:15 +0200 Subject: PHP + MySQL based Dependency resolver created. things can be so much smaller!!! Message-ID: <6e24a8e80703251355k72755aacta84e66d13b23a551@mail.gmail.com> Hey, i`ve just completed my little php+mysql script that is resolving dependency`s. what i`ve done is: i`ve copied all the rpm files from the FC7 Test 2 DVD to my HDD. than i installed this little program: http://cekirdek.uludag.org.tr/~meren/php_rpm/ and started putting ALL the RPM headers in a MySQL database. the total database is now 96MB but about 92MB of that is plain USELESS for me. so that leaves the full fedora base stuff about 4 MegeBytes when i make a database dump of that with gzipped compression the full size of that is: 563.1 KB (576583 bytes) and that`s with the package description. without the changelog. all things that you than have: PROVIDENAMES PROVIDEVERSION REQUIRENAMES REQUIREVERSION DESCRIPTION rpmname_to_id (i added that to work based on id`s instead of names) this is so small and yet YUM requires about 10MB? for the full base stuff.. now did i found out a new way to do this or what? here is a sample of the output that i get when i tell my script that i want to install the kernel: (stripes are increased by 2 at a time) coreutils grep pcre libgcc -- glibc -- glibc-common -- tzdata ---- basesystem ---- setup ------ filesystem ---- libstdc++ -- libselinux -- libsepol ---- mcstrans ---- libcap ---- pam ---- audit-libs ------ cracklib -------- cracklib-dicts ---------- mktemp ------------ sed -- module-init-tools ---- initscripts ---- udev ---- MAKEDEV ------ ethtool -------- glib2 ---------- net-tools ------------ e2fsprogs ------------ e2fsprogs-libs ------------ device-mapper-libs -------------- device-mapper -------------- mingetty ---------------- util-linux ---------------- ncurses ------------------ zlib -------------------- popt ------------------ sysklogd ------------------ logrotate -------------------- bash -------------------- SysVinit ------ mkinitrd ------ gzip ------ less -------- libdhcp4client ---------- libdhcp6client ---------- openssl ---------- krb5-libs ------------ cpio -------------- dmraid -------------- kpartx ---------------- findutils ------------------ libnl -------------------- parted -------------------- readline ---------------------- lvm2 ------------------------ libdhcp -------------------------- nash ---------------------------- tar ---------------------------- info so a very basic installation should probably only have those packages installed if you want to install the absolute minimal. now for the timings. i`m not quite happy yet about the results because it took about 30 seconds for my computer to compile the list you see above. but than take in mind that the database isn`t optimized, the queries aren`t optimized and i`m doing this recursively with queries. best thing would probable be to fetch all the stuff one time and than let php do the rest. i atleast expect that to be alot faster. perhaps even the fastest dependency checker that`s currently existsing. now why did i posted this stuff here. well.. yum is currently undergoing some work to have those dependency's checked alot faster. and this could perhaps be usefull to them (the yum creators). so if they want to see the code.. just ask me. i also would like to put this online but i don`t have a host to store this stuff on. the default php timeout is far from enough (30 seconds == to little for this dependency checker in it`s current state.) there is also a disadvantage if this system is ever gonna be user for yum. the current header style simply won`t work because it will all needs to be in a gzipped sql file and not in a (extremely big) .XML file. so ehm.. do you guys like this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hughsient at gmail.com Sun Mar 25 21:48:13 2007 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 25 Mar 2007 22:48:13 +0100 Subject: Fedora Extras Package Build Report 2007-03-25 In-Reply-To: <20070325160406.01685152130@buildsys.fedoraproject.org> References: <20070325160406.01685152130@buildsys.fedoraproject.org> Message-ID: <1174859293.15047.5.camel@localhost.localdomain> On Sun, 2007-03-25 at 12:04 -0400, buildsys at fedoraproject.org wrote: > epiphany-extensions-2.18.0-2 ... Cleanup : yelp ####################### [24/32] /var/tmp/rpm-tmp.4683: line 6: syntax error near unexpected token `||' /var/tmp/rpm-tmp.4683: line 6: `||: ' error: %preun(epiphany-extensions-2.17.92-1.i386) scriptlet failed, exit status 2 Cleanup : epiphany-extensions ####################### [25/32] ... Richard. From peter at thecodergeek.com Mon Mar 26 02:27:52 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 25 Mar 2007 19:27:52 -0700 Subject: Fedora Extras Package Build Report 2007-03-25 In-Reply-To: <1174859293.15047.5.camel@localhost.localdomain> References: <20070325160406.01685152130@buildsys.fedoraproject.org> <1174859293.15047.5.camel@localhost.localdomain> Message-ID: <1174876072.3815.4.camel@tuxhugs> On Sun, 2007-03-25 at 22:48 +0100, Richard Hughes wrote: > On Sun, 2007-03-25 at 12:04 -0400, buildsys at fedoraproject.org wrote: > > epiphany-extensions-2.18.0-2 > > ... > Cleanup : yelp ####################### > [24/32] > /var/tmp/rpm-tmp.4683: line 6: syntax error near unexpected token `||' > /var/tmp/rpm-tmp.4683: line 6: `||: ' > error: %preun(epiphany-extensions-2.17.92-1.i386) scriptlet failed, exit > status 2 > Cleanup : epiphany-extensions ####################### > [25/32] > ... > > Richard. > Yeah, sorry about that. I had that fixed in 2.18.0-1 though. A simple `rpm -e --noscripts epiphany-extensions-2.17.92-1` as root should fix it. -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 jdieter at gmail.com Mon Mar 26 08:26:20 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 26 Mar 2007 11:26:20 +0300 Subject: Presto logging Message-ID: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> If any of you are testing Presto, please upgrade to 0.2.4. This version stores a log in /var/log/presto.log that contains two very important numbers for each yum session: * Number of bytes that would have been downloaded for Presto-enabled repository updates * Number of bytes that were downloaded for Presto-enabled repository updates It also contains the percentage saved and total (cumulative) percentage saved. Every week or so, I'd love to get a copy of your logs so I can see what real savings we're getting from Presto. Also, our test server is syncing updates and extras every six hours. Does anyone know if there's a way for the fedoraproject servers to push updates rather than our polling? Thanks, Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From buildsys at redhat.com Mon Mar 26 10:05:25 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Mon, 26 Mar 2007 06:05:25 -0400 Subject: rawhide report: 20070326 changes Message-ID: <200703261005.l2QA5P1f023930@hs20-bc2-6.build.redhat.com> Updated Packages: (none) 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 tmus at tmus.dk Mon Mar 26 11:55:37 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 26 Mar 2007 13:55:37 +0200 Subject: Presto problems In-Reply-To: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> Message-ID: <4607B4B9.6090307@tmus.dk> I noticed something strange, after installing yum-presto. I have a freshrpms repo enabled on my FC6 box. This repo is setup with a mirrorlist, which contains the following, when downloaded: http://ayo.ie.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ http://ayo.uk3.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ http://ayo.us5.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ http://ayo.pt.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ When presto is enabled, the freshrpms repo consistently fails with errors looking like this: http://ayo.pt.freshrpms.net/fedora/linux/6/%24BASEARCH/freshrpms/repodata/repomd.xml: [Errno 14] HTTP Error 404: Date: Mon, 26 Mar 2007 11:51:45 GMT Running yum with --disablepresto makes freshrpms work again. So it seems like presto is screwing up some internal variables or convertions or something. Hope this is useful, if not, please let me know what you need. /Thomas From tmus at tmus.dk Mon Mar 26 11:58:23 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 26 Mar 2007 13:58:23 +0200 Subject: Presto and mirrorlist url problems Message-ID: I noticed something strange, after installing yum-presto. I have a freshrpms repo enabled on my FC6 box. This repo is setup with a mirrorlist, which contains the following, when downloaded: http://ayo.ie.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ http://ayo.uk3.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ http://ayo.us5.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ http://ayo.pt.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ When presto is enabled, the freshrpms repo consistently fails with errors looking like this: http://ayo.pt.freshrpms.net/fedora/linux/6/%24BASEARCH/freshrpms/repodata/repomd.xml: [Errno 14] HTTP Error 404: Date: Mon, 26 Mar 2007 11:51:45 GMT Running yum with --disablepresto makes freshrpms work again. So it seems like presto is screwing up some internal variables or convertions or something. Hope this is useful, if not, please let me know what you need. /Thomas From tmus at tmus.dk Mon Mar 26 12:02:12 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 26 Mar 2007 14:02:12 +0200 Subject: Presto problems In-Reply-To: <4607B4B9.6090307@tmus.dk> References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> <4607B4B9.6090307@tmus.dk> Message-ID: This is a duplicate post - My apologies. If you want to discuss this issue, please do so under the "Presto and mirrorlist url problems" thread instead. /Thomas From katzj at redhat.com Mon Mar 26 12:52:22 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 26 Mar 2007 08:52:22 -0400 Subject: Presto logging In-Reply-To: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> Message-ID: <1174913542.3254.6.camel@aglarond.local> On Mon, 2007-03-26 at 11:26 +0300, Jonathan Dieter wrote: > Also, our test server is syncing updates and extras every six hours. > Does anyone know if there's a way for the fedoraproject servers to push > updates rather than our polling? There's not Jeremy From jdieter at gmail.com Mon Mar 26 13:01:43 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 26 Mar 2007 16:01:43 +0300 Subject: Presto logging In-Reply-To: <1174913542.3254.6.camel@aglarond.local> References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> <1174913542.3254.6.camel@aglarond.local> Message-ID: <1174914103.19925.23.camel@jndwidescreen.lesbg.loc> On Mon, 2007-03-26 at 08:52 -0400, Jeremy Katz wrote: > On Mon, 2007-03-26 at 11:26 +0300, Jonathan Dieter wrote: > > Also, our test server is syncing updates and extras every six hours. > > Does anyone know if there's a way for the fedoraproject servers to push > > updates rather than our polling? > > There's not > > Jeremy > Bummer. I guess we get to work with what we've got then. Is six hours a good mirror timetable? Jonathan -------------- 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 jdieter at gmail.com Mon Mar 26 13:07:44 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 26 Mar 2007 16:07:44 +0300 Subject: Presto and mirrorlist url problems In-Reply-To: References: Message-ID: <1174914464.19925.26.camel@jndwidescreen.lesbg.loc> On Mon, 2007-03-26 at 13:58 +0200, Thomas M Steenholdt wrote: > I noticed something strange, after installing yum-presto. > > I have a freshrpms repo enabled on my FC6 box. This repo is setup with a > mirrorlist, which contains the following, when downloaded: > > http://ayo.ie.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ > http://ayo.uk3.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ > http://ayo.us5.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ > http://ayo.pt.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ > > When presto is enabled, the freshrpms repo consistently fails with > errors looking like this: > > http://ayo.pt.freshrpms.net/fedora/linux/6/%24BASEARCH/freshrpms/repodata/repomd.xml: > [Errno 14] HTTP Error 404: Date: Mon, 26 Mar 2007 11:51:45 GMT > > Running yum with --disablepresto makes freshrpms work again. > > So it seems like presto is screwing up some internal variables or > convertions or something. > > Hope this is useful, if not, please let me know what you need. > > /Thomas > This bug should be fixed in 0.2.5. The problem was that I was setting up the Presto repositories before the regular ones. See if this fixes the problem. Jonathan -------------- 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 tmus at tmus.dk Mon Mar 26 13:21:56 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 26 Mar 2007 15:21:56 +0200 Subject: Presto logging In-Reply-To: <1174914103.19925.23.camel@jndwidescreen.lesbg.loc> References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> <1174913542.3254.6.camel@aglarond.local> <1174914103.19925.23.camel@jndwidescreen.lesbg.loc> Message-ID: Jonathan Dieter wrote: > On Mon, 2007-03-26 at 08:52 -0400, Jeremy Katz wrote: >> On Mon, 2007-03-26 at 11:26 +0300, Jonathan Dieter wrote: >>> Also, our test server is syncing updates and extras every six hours. >>> Does anyone know if there's a way for the fedoraproject servers to push >>> updates rather than our polling? >> There's not >> >> Jeremy >> > Bummer. I guess we get to work with what we've got then. Is six hours > a good mirror timetable? > > Jonathan > This brings up (again) the discussion of whether if would be worth adding sync-flag semantics to the way we mirror (like what debian has been doing for years). That would allow downstream mirrors to monitor for a specific file every hour or so, and when that file exists with an updated timestamp (or something) then we can be sure that the mirror has finished it's own sync. The downstream mirror can then (more) reliably perform it's own sync, sleep for some hours and start all over again. So while we're still polling for updates, the risk of ending with an inconsistent mirror is reduced. If this was implemented on all mirrors, we could effectively and very simply decrease mirroring bandwidth, improve mirror reliability/quality, reduce the number of update problems due to incomplete mirroring etc etc. By now it should not be a big surprise, that I think this could be a good idea. I'll just keep pointing out situations where this could make a positive difference. ;-) /Thomas From tmus at tmus.dk Mon Mar 26 13:51:45 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 26 Mar 2007 15:51:45 +0200 Subject: Presto and mirrorlist url problems In-Reply-To: <1174914464.19925.26.camel@jndwidescreen.lesbg.loc> References: <1174914464.19925.26.camel@jndwidescreen.lesbg.loc> Message-ID: Jonathan Dieter wrote: > On Mon, 2007-03-26 at 13:58 +0200, Thomas M Steenholdt wrote: >> I noticed something strange, after installing yum-presto. >> >> I have a freshrpms repo enabled on my FC6 box. This repo is setup with a >> mirrorlist, which contains the following, when downloaded: >> >> http://ayo.ie.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ >> http://ayo.uk3.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ >> http://ayo.us5.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ >> http://ayo.pt.freshrpms.net/fedora/linux/6/$ARCH/freshrpms/ >> >> When presto is enabled, the freshrpms repo consistently fails with >> errors looking like this: >> >> http://ayo.pt.freshrpms.net/fedora/linux/6/%24BASEARCH/freshrpms/repodata/repomd.xml: >> [Errno 14] HTTP Error 404: Date: Mon, 26 Mar 2007 11:51:45 GMT >> >> Running yum with --disablepresto makes freshrpms work again. >> >> So it seems like presto is screwing up some internal variables or >> convertions or something. >> >> Hope this is useful, if not, please let me know what you need. >> >> /Thomas >> > This bug should be fixed in 0.2.5. The problem was that I was setting > up the Presto repositories before the regular ones. See if this fixes > the problem. > > Jonathan > At first shot it looks better. However I need to wait for the various mirrors to settle (*cough*), since I'm getting all kinds of other errors at the moment. At least the urls listed on the errors do not have the garbled variable names in them now, so it looks like a positive change. I'll let you know if I still see the problem after this settles down. Thanks a lot. /Thomas From sundaram at fedoraproject.org Mon Mar 26 13:53:29 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 26 Mar 2007 19:23:29 +0530 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> Message-ID: <4607D059.50900@fedoraproject.org> Jonathan Dieter wrote: > Ahmed Kamal and I are pleased to report that Presto, a yum plugin that > downloads deltarpms when possible, is ready for wider testing (than the > two of us). Warning: It may eat your kittens! > > RPMs are available from > http://hosted.fedoraproject.org/projects/presto/wiki/WikiStart > > Please report bugs on the project page or e-mail them directly to me. > > As most of you have heard (over and over), deltarpms are essentially > binary diffs between two rpms. They can provide significant savings > when you update your system. > > Please note that we only have deltarpms created for FC6 i386 updates and > extras. We will try to add Rawhide and/or 64 bit in the near future, > though we are constrained by the space required to mirror them all. Fresh default installation of FC6, disabled updates and extras repo. Installed the latest version of deltarpm and yum-presto plugin from the wiki. Ran yum update. This is the end of the output. --> Processing Dependency: perl(LWP::UserAgent) for package: spamassassin --> Processing Dependency: perl(HTTP::Date) for package: spamassassin --> Finished Dependency Resolution Found deltarpm update for util-linux.i386 0:2.13.0.46.fc6 Found deltarpm update for libgcj.i386 0:4.1.1.51.fc6 Found deltarpm update for gjdoc.i386 0:0.7.7.14.fc6 Found deltarpm update for eel2.i386 0:2.16.1.1.fc6 Found deltarpm update for evolution.i386 0:2.8.3.1.fc6 Found deltarpm update for vte.i386 0:0.14.2.1.fc6 Found deltarpm update for kernel.i586 0:2.6.20.1.2933.fc6 Found deltarpm update for gimp-print-utils.i386 0:4.2.7.23.fc6 Found deltarpm update for gnome-desktop.i386 0:2.16.3.1.fc6 Found deltarpm update for at.i386 0:3.1.8.85.fc6 Found deltarpm update for nss.i386 0:3.11.5.0.6.1.fc6 Found deltarpm update for slrn.i386 0:0.9.8.1pl1.2.fc6 Found deltarpm update for xsane-gimp.i386 0:0.991.4.fc6 Found deltarpm update for a2ps.i386 0:4.13b.57.fc6.3 Found deltarpm update for apr-util.i386 0:1.2.8.1.fc6 Found deltarpm update for mono-core.i386 0:1.1.17.1.4.fc6 Traceback (most recent call last): File "/usr/bin/yum", line 29, in ? yummain.main(sys.argv[1:]) File "/usr/share/yum-cli/yummain.py", line 143, in main (result, resultmsgs) = base.buildTransaction() File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 442, in buildTransaction self.plugins.run('postresolve', rescode=rescode, restring=restring) File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 153, in run func(conduitcls(self, self.base, conf, **kwargs)) File "/usr/lib/yum-plugins/presto.py", line 85, in postresolve_hook (chosen_drpm, installed, local) = prestoTransaction.find_available_drpms(conduit, newpkg) File "/usr/share/presto/prestoTransaction.py", line 28, in find_available_drpms p_repo = newpkg.po.repo.p_repo AttributeError: FakeRepository instance has no attribute 'p_repo' Rahul From katzj at redhat.com Mon Mar 26 14:04:25 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 26 Mar 2007 10:04:25 -0400 Subject: Possibility of F7-Test3-KDE? In-Reply-To: <20070324032443.03b3cf2d@localhost.localdomain> References: <20070324032443.03b3cf2d@localhost.localdomain> Message-ID: <1174917865.27762.3.camel@aglarond.local> On Sat, 2007-03-24 at 03:24 +0100, Sebastian Vahl wrote: > I just want to ask how do you think about this question: Will it be > anyhow possible to create an _official_ version of a kde livecd for > test3? If Max's proposal [1] should come true (and assuming that nobody > else is working on this that I am not aware of) we really _need_ at > least two test versions. Definitely seems like the reasonable thing to do and a practical thing as well. For the final, we[1] should probably have a discussion on how to have the spin done and hosted but for the purposes of getting test3 out in a reasonable timeframe, I'll go ahead and add doing the KDE spin to the list of things that I'm doing today. Jeremy [1] The release team in general + probably you and Rex from the KDE side of things. From ajackson at redhat.com Mon Mar 26 13:55:52 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 26 Mar 2007 09:55:52 -0400 Subject: SSH tunnelled X sessions become unresponsive. In-Reply-To: References: <1174687776.25634.4.camel@localhost.localdomain> Message-ID: <1174917352.31911.5.camel@localhost.localdomain> On Fri, 2007-03-23 at 23:02 +0000, Andy Burns wrote: > On 23/03/07, Adam Jackson wrote: > > My usual method for debugging this sort of thing is to use wireshark to > > see which side's network traffic is stopping. > > that sounds, errm ... fun, I wouldn't recognize good X protocol over > the wire if it slapped me, I'll give it a go though, otherwise I can > see that I might end up without remote GUI when F7 comes out, I've put > an xming bug into fd.o bugzilla just in case too. wireshark has a built-in decoder for X. If you filter on port 6000 then you'll only see the X traffic, and examining packet timestamps should be enough to tell you where the stall is happening. - ajax From ajackson at redhat.com Mon Mar 26 14:02:10 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 26 Mar 2007 10:02:10 -0400 Subject: VESA driver hsync config problem In-Reply-To: References: Message-ID: <1174917730.31911.10.camel@localhost.localdomain> On Sun, 2007-03-25 at 08:24 -0600, Xavier Toth wrote: > For awhile now I've been struggling with what is probably a Vesa > driver issue related to but different from Fedora Core bug# 10238. I'm > running the latest X (7.2) under FC6 in a Parallels VM on a Mac and > the server won't start unless I specify the HorizSync in the Monitor > section of xorg.conf. I dug around and found references to > vesa-1.3.0-range-hack.patch which I applied but this made no > difference. > My group is putting together a livecd for demo purposes and the > xorg.conf generated by system-config-display (FC6) doesn't add a > HorizSync so X won't start. Hopefully someone will have an idea how to > fix this otherwise I might have to hack the config to add the > HorizSync as an interim solution, any thoughts? Parallels needs to be taught to emulate DDC as well, it seems. But if you have an X log, and there's an identifying string in the VBE info, then we might be able to hack something up. - ajax From ml at deadbabylon.de Mon Mar 26 14:26:41 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Mon, 26 Mar 2007 16:26:41 +0200 Subject: Possibility of F7-Test3-KDE? In-Reply-To: <1174917865.27762.3.camel@aglarond.local> References: <20070324032443.03b3cf2d@localhost.localdomain> <1174917865.27762.3.camel@aglarond.local> Message-ID: <20070326162641.616bf708@localhost.localdomain> Am Mon, 26 Mar 2007 10:04:25 -0400 schrieb Jeremy Katz : > On Sat, 2007-03-24 at 03:24 +0100, Sebastian Vahl wrote: > > I just want to ask how do you think about this question: Will it be > > anyhow possible to create an _official_ version of a kde livecd for > > test3? If Max's proposal [1] should come true (and assuming that > > nobody else is working on this that I am not aware of) we really > > _need_ at least two test versions. > > Definitely seems like the reasonable thing to do and a practical thing > as well. For the final, we[1] should probably have a discussion on > how to have the spin done and hosted but for the purposes of getting > test3 out in a reasonable timeframe, I'll go ahead and add doing the > KDE spin to the list of things that I'm doing today. > > Jeremy > > [1] The release team in general + probably you and Rex from the KDE > side of things. > Ok. I've attached my last version. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-fedora-kde.ks Type: application/octet-stream Size: 4417 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajackson at redhat.com Mon Mar 26 14:09:43 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 26 Mar 2007 10:09:43 -0400 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174812968.6248.4.camel@pensja.lam.pl> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <1174812968.6248.4.camel@pensja.lam.pl> Message-ID: <1174918183.31911.15.camel@localhost.localdomain> On Sun, 2007-03-25 at 10:56 +0200, Leszek Matok wrote: > Dnia 24-03-2007, sob o godzinie 20:33 +0200, Jonathan Dieter napisa?(a): > > RPMs are available from > > http://hosted.fedoraproject.org/projects/presto/wiki/WikiStart > Error: Missing Dependency: deltarpm >= 3.4 is needed by package yum-presto > > Am I right that in order to update FC6, I have to have Rawhide > instead? :) It would be good to provide dependencies in the "presto" > repository, if it really can't be compiled against deltarpm present in > FE6. I've updated FE6 to have deltarpm 3.4 now. - ajax From markg85 at gmail.com Mon Mar 26 14:52:57 2007 From: markg85 at gmail.com (Mark) Date: Mon, 26 Mar 2007 16:52:57 +0200 Subject: Where did /dev/hda (/dev/hd*) go to? Message-ID: <6e24a8e80703260752x28557c9ob43bfdd3b9167598@mail.gmail.com> Hey, i`m having no problem mounting SD(A) devices but somehow /dev/hda simply doesn`t exist. even stranger. the only h named thing in the /dev folder is hpet (/dev/hpet). /dev should contain hda till hdz and it doesn`t contain any of those. is this a bug? or do i need to install a package first? i`m running rawhile with the latest updates. thanx Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Mon Mar 26 14:57:35 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 26 Mar 2007 15:57:35 +0100 Subject: Where did /dev/hda (/dev/hd*) go to? In-Reply-To: <6e24a8e80703260752x28557c9ob43bfdd3b9167598@mail.gmail.com> References: <6e24a8e80703260752x28557c9ob43bfdd3b9167598@mail.gmail.com> Message-ID: <17927.57183.972521.497023@zebedee.pink> Mark writes: > Hey, > > i`m having no problem mounting SD(A) devices but somehow /dev/hda simply > doesn`t exist. > even stranger. the only h named thing in the /dev folder is hpet > (/dev/hpet). > > /dev should contain hda till hdz and it doesn`t contain any of those. > > is this a bug? or do i need to install a package first? > i`m running rawhile with the latest updates. Have a look for ide messages in the log. From jdieter at gmail.com Mon Mar 26 14:59:49 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 26 Mar 2007 17:59:49 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174918183.31911.15.camel@localhost.localdomain> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <1174812968.6248.4.camel@pensja.lam.pl> <1174918183.31911.15.camel@localhost.localdomain> Message-ID: <1174921189.19925.31.camel@jndwidescreen.lesbg.loc> On Mon, 2007-03-26 at 10:09 -0400, Adam Jackson wrote: > I've updated FE6 to have deltarpm 3.4 now. > > - ajax > Excellent, I'll pull deltarpm out of the presto repository once the mirror has synced up (in two hours). Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From denis at poolshark.org Mon Mar 26 15:00:40 2007 From: denis at poolshark.org (Denis Leroy) Date: Mon, 26 Mar 2007 17:00:40 +0200 Subject: FC-6 NetworkManager needs some love Message-ID: <4607E018.9010809@poolshark.org> I noticed that NetworkManager for FC-6 never got updated. As a matter of fact, the FC-6 core SRPM doesn't even compile anymore. The CVS FC-6 branch seems to contain a number of useful patches, but suffers from the same compilation issues : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220975 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232665 So the current FC-6 RPM is compiled against dbus 0.93 but runs with dbus 1.0.1. Why am I slightly nervous :-) Bug 232665 contains a patch for the dbus 1.0 problem. Can we help ? Do we need some co-maintainers for NM ? -denis From jdieter at gmail.com Mon Mar 26 15:03:47 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 26 Mar 2007 18:03:47 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <4607D059.50900@fedoraproject.org> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> Message-ID: <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> On Mon, 2007-03-26 at 19:23 +0530, Rahul Sundaram wrote: > Fresh default installation of FC6, disabled updates and extras repo. > Installed the latest version of deltarpm and yum-presto plugin from the > wiki. Ran yum update. This is the end of the output. > > > --> Processing Dependency: perl(LWP::UserAgent) for package: spamassassin > --> Processing Dependency: perl(HTTP::Date) for package: spamassassin > --> Finished Dependency Resolution > Found deltarpm update for util-linux.i386 0:2.13.0.46.fc6 > Found deltarpm update for libgcj.i386 0:4.1.1.51.fc6 > Found deltarpm update for gjdoc.i386 0:0.7.7.14.fc6 > Found deltarpm update for eel2.i386 0:2.16.1.1.fc6 > Found deltarpm update for evolution.i386 0:2.8.3.1.fc6 > Found deltarpm update for vte.i386 0:0.14.2.1.fc6 > Found deltarpm update for kernel.i586 0:2.6.20.1.2933.fc6 > Found deltarpm update for gimp-print-utils.i386 0:4.2.7.23.fc6 > Found deltarpm update for gnome-desktop.i386 0:2.16.3.1.fc6 > Found deltarpm update for at.i386 0:3.1.8.85.fc6 > Found deltarpm update for nss.i386 0:3.11.5.0.6.1.fc6 > Found deltarpm update for slrn.i386 0:0.9.8.1pl1.2.fc6 > Found deltarpm update for xsane-gimp.i386 0:0.991.4.fc6 > Found deltarpm update for a2ps.i386 0:4.13b.57.fc6.3 > Found deltarpm update for apr-util.i386 0:1.2.8.1.fc6 > Found deltarpm update for mono-core.i386 0:1.1.17.1.4.fc6 > Traceback (most recent call last): > File "/usr/bin/yum", line 29, in ? > yummain.main(sys.argv[1:]) > File "/usr/share/yum-cli/yummain.py", line 143, in main > (result, resultmsgs) = base.buildTransaction() > File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 442, in > buildTransaction > self.plugins.run('postresolve', rescode=rescode, restring=restring) > File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 153, in run > func(conduitcls(self, self.base, conf, **kwargs)) > File "/usr/lib/yum-plugins/presto.py", line 85, in postresolve_hook > (chosen_drpm, installed, local) = > prestoTransaction.find_available_drpms(conduit, newpkg) > File "/usr/share/presto/prestoTransaction.py", line 28, in > find_available_drpms > p_repo = newpkg.po.repo.p_repo > AttributeError: FakeRepository instance has no attribute 'p_repo' > > > Rahul Okay, I think I've fixed this problem in 0.2.6 (the failing statement is now in a try, except segment), but I'm curious as to why we actually hit this. Do you mind sending me yum's full output (using -d 5) when you run this again? Thanks, Jonathan -------------- 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 samfw at redhat.com Mon Mar 26 15:08:18 2007 From: samfw at redhat.com (Sam Folk-Williams) Date: Mon, 26 Mar 2007 11:08:18 -0400 Subject: openofice constantly crashing In-Reply-To: <1174829946.3183.93.camel@T7.Linux> References: <20070325132700.GL9976@unplugged.rdu.redhat.com> <1174829946.3183.93.camel@T7.Linux> Message-ID: <20070326150817.GD9976@unplugged.rdu.redhat.com> On 03/25/07 14:39 +0100 Paul wrote: > Hi, > > > In rawhide... when I open any oo.o document it crashes immediately. When I open > > a new document, it crashes as soon as i type one character into the document: > > Disable hunspell - just set the check spelling as you type option to be > off (though the version from yesterday's rawhide should have fixed the > problem). Thanks - the workaround does resolve it but I don't see any openoffice update that fixes the issue. Sam > > TTFN > > Paul > -- > Sie k?nnen mich aufreizen und wirklich hei? machen! > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Sam Folk-Williams, RHCE Red Hat Global Support Services Phone: 919/754-4558 GPG ID: 1B0D46BA From wwoods at redhat.com Mon Mar 26 15:13:00 2007 From: wwoods at redhat.com (Will Woods) Date: Mon, 26 Mar 2007 11:13:00 -0400 Subject: Where did /dev/hda (/dev/hd*) go to? In-Reply-To: <6e24a8e80703260752x28557c9ob43bfdd3b9167598@mail.gmail.com> References: <6e24a8e80703260752x28557c9ob43bfdd3b9167598@mail.gmail.com> Message-ID: <1174921980.17842.92.camel@metroid.rdu.redhat.com> On Mon, 2007-03-26 at 16:52 +0200, Mark wrote: > Hey, > > i`m having no problem mounting SD(A) devices but somehow /dev/hda > simply doesn`t exist. > even stranger. the only h named thing in the /dev folder is hpet > (/dev/hpet). > > /dev should contain hda till hdz and it doesn`t contain any of those. > > is this a bug? or do i need to install a package first? > i`m running rawhile with the latest updates. The rawhide kernel uses the new PATA/IDE subsystem, which (like the SATA subsystem) goes through SCSI layer. All disk devices are /dev/sdX now. To sum up: /dev/hdX = old and busted /dev/sdX = new hotness Enjoy, -w -------------- 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 Mon Mar 26 15:13:12 2007 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 26 Mar 2007 17:13:12 +0200 Subject: accounts2/fas/fas .LDAP.py.swp, NONE, 1.1 .test.py.swp, NONE, 1.1 LDAP.pyc, NONE, 1.1 __init__.py, NONE, 1.1 __init__.pyc, NONE, 1.1 controllers.py, NONE, 1.1 controllers.pyc, NONE, 1.1 controllers.py~, NONE, 1.1 fasLDAP.py, NONE, 1.1 fasLDAP.pyc, NONE, 1.1 fasLDAP.py~, NONE, 1.1 json.py, NONE, 1.1 model.py, NONE, 1.1 model.pyc, NONE, 1.1 release.py, NONE, 1.1 t.py, NONE, 1.1 test.py, NONE, 1.1 In-Reply-To: <200703261511.l2QFBJIS027000@cvs-int.fedora.redhat.com> References: <200703261511.l2QFBJIS027000@cvs-int.fedora.redhat.com> Message-ID: <20070326151312.GC2972@free.fr> On Mon, Mar 26, 2007 at 11:11:19AM -0400, Michael Patrick McGrath wrote: > Author: mmcgrath > > Update of /cvs/fedora/accounts2/fas/fas > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv26831/fas/fas > > Added Files: > .LDAP.py.swp .test.py.swp LDAP.pyc __init__.py __init__.pyc > controllers.py controllers.pyc controllers.py~ fasLDAP.py > fasLDAP.pyc fasLDAP.py~ json.py model.py model.pyc release.py > t.py test.py Seems like some unwanted files crept in, like .LDAP.py.swp LDAP.pyc controllers.py~... (not sure about .pyc files). -- Pat From darrellpf at gmail.com Mon Mar 26 15:14:19 2007 From: darrellpf at gmail.com (darrell pfeifer) Date: Mon, 26 Mar 2007 08:14:19 -0700 Subject: openofice constantly crashing In-Reply-To: <20070326150817.GD9976@unplugged.rdu.redhat.com> References: <20070325132700.GL9976@unplugged.rdu.redhat.com> <1174829946.3183.93.camel@T7.Linux> <20070326150817.GD9976@unplugged.rdu.redhat.com> Message-ID: On 3/26/07, Sam Folk-Williams wrote: > On 03/25/07 14:39 +0100 Paul wrote: > > Hi, > > > > > In rawhide... when I open any oo.o document it crashes immediately. When I open > > > a new document, it crashes as soon as i type one character into the document: > > > > Disable hunspell - just set the check spelling as you type option to be > > off (though the version from yesterday's rawhide should have fixed the > > problem). > Thanks - the workaround does resolve it but I don't see any openoffice update > that fixes the issue. > > Sam > > > > > > TTFN > > > > Paul > > -- > > Sie k?nnen mich aufreizen und wirklich hei? machen! > > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > -- > Sam Folk-Williams, RHCE Red Hat Global Support Services > Phone: 919/754-4558 GPG ID: 1B0D46BA > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Sam, The 'update' to hunspell was a presumably temporary downgrade to a previous version, so it wasn't installed by yum. darrell From dwmw2 at infradead.org Mon Mar 26 15:15:45 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 26 Mar 2007 16:15:45 +0100 Subject: FC-6 NetworkManager needs some love In-Reply-To: <4607E018.9010809@poolshark.org> References: <4607E018.9010809@poolshark.org> Message-ID: <1174922145.3277.3.camel@pmac.infradead.org> On Mon, 2007-03-26 at 17:00 +0200, Denis Leroy wrote: > So the current FC-6 RPM is compiled against dbus 0.93 but runs with dbus > 1.0.1. Why am I slightly nervous :-) Bug 232665 contains a patch for the > dbus 1.0 problem. Can we help ? Do we need some co-maintainers for NM ? On that topic, NetworkManager in FC6 is still suffering from the regression which broke it in FC4-updates -- it's asking for a user's password every time it needs the system's WEP key. It's got worse in rawhide -- it's now asking for that password after every suspend/resume cycle. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174467 -- dwmw2 From limb at jcomserv.net Mon Mar 26 15:16:14 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 26 Mar 2007 10:16:14 -0500 (CDT) Subject: rpms/ettercap/FC-5 ettercap.spec,1.13,1.14 In-Reply-To: <20070323220128.GC17494@free.fr> References: <200703231606.l2NG66Zg002695@cvs-int.fedora.redhat.com> <20070323220128.GC17494@free.fr> Message-ID: <17136.65.192.24.190.1174922174.squirrel@mail.jcomserv.net> In addition to other similar suggestions, I'm going to permanently resolve the issue, merging the -plugins package into -common. With the proper BR, the files will always be there. This issue was casued by a BR mistake in the first place. > On Fri, Mar 23, 2007 at 12:06:06PM -0400, Jon Ciesla wrote: >> Index: ettercap.spec >> =================================================================== >> RCS file: /cvs/extras/rpms/ettercap/FC-5/ettercap.spec,v >> retrieving revision 1.13 >> retrieving revision 1.14 >> diff -u -r1.13 -r1.14 >> --- ettercap.spec 23 Mar 2007 14:54:22 -0000 1.13 >> +++ ettercap.spec 23 Mar 2007 16:05:33 -0000 1.14 >> @@ -96,7 +96,7 @@ >> make install DESTDIR=%{buildroot} >> install -c -m 755 src/ettercap-gtk %{buildroot}%{_bindir} >> mv %{buildroot}%{_bindir}/ettercap %{buildroot}%{_bindir}/ettercap-tui >> -#rm %{buildroot}%{_libdir}/ettercap/*.la >> +[ -f %{buildroot}%{_libdir}/ettercap/*.la ] && rm >> %{buildroot}%{_libdir}/ettercap/*.la >> mkdir -p %{buildroot}%{_docdir} >> install -c -m 644 %{SOURCE2} %{buildroot}%{_docdir} > > I think that you should either do > rm %{buildroot}%{_libdir}/ettercap/*.la > to be sure that the build stops when there is no *.la file, or use the > simpler: > rm -f %{buildroot}%{_libdir}/ettercap/*.la > > I would personally prefer a build that stop when files are no longer > there, but that is only a personal preference. > > -- > Pat > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From hughsient at gmail.com Mon Mar 26 15:26:05 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Mar 2007 16:26:05 +0100 Subject: FC-6 NetworkManager needs some love In-Reply-To: <1174922145.3277.3.camel@pmac.infradead.org> References: <4607E018.9010809@poolshark.org> <1174922145.3277.3.camel@pmac.infradead.org> Message-ID: <1174922765.8528.11.camel@localhost.localdomain> On Mon, 2007-03-26 at 16:15 +0100, David Woodhouse wrote: > > It's got worse in rawhide -- it's now asking for that password after > every suspend/resume cycle. No, that's by design. gnome-power-manager tells gnome-keyring to "lock" on suspend for security. See gnome bug #375681. Richard. From sundaram at fedoraproject.org Mon Mar 26 15:32:28 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 26 Mar 2007 21:02:28 +0530 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> Message-ID: <4607E78C.30109@fedoraproject.org> Jonathan Dieter wrote: > Okay, I think I've fixed this problem in 0.2.6 (the failing statement is > now in a try, except segment), but I'm curious as to why we actually hit > this. Do you mind sending me yum's full output (using -d 5) when you > run this again? Sure. Different output with 0.2.6 and yum -d5. Loading "installonlyn" plugin Loading "presto" plugin Running "config" handler for "installonlyn" plugin Running "config" handler for "presto" plugin Yum Version: 3.0 COMMAND: yum -d5 Installroot: / Setting up Update Process Setting up repositories Running "postreposetup" handler for "presto" plugin Setting up Presto Manual url set from presto.conf: ['http://www.lesbg.com/jdieter/updates/fc6/i386/'] Reading Presto metadata in from local files Reading repository metadata in from local files Setting up Package Sacks Reading Local RPMDB Building updates object Resolving Dependencies 1174972558.49 --> Populating transaction set with selected packages. Please wait. Adding Package util-linux - 2.13-0.46.fc6.i386 in mode u ---> Package util-linux.i386 0:2.13-0.46.fc6 set to be updated Adding Package libgcj - 4.1.1-51.fc6.i386 in mode u ---> Package libgcj.i386 0:4.1.1-51.fc6 set to be updated Adding Package gjdoc - 0.7.7-14.fc6.i386 in mode u ---> Package gjdoc.i386 0:0.7.7-14.fc6 set to be updated Adding Package libxslt - 1.1.20-1.fc6.i386 in mode u ---> Package libxslt.i386 0:1.1.20-1.fc6 set to be updated Adding Package eel2 - 2.16.1-1.fc6.i386 in mode u ---> Package eel2.i386 0:2.16.1-1.fc6 set to be updated Adding Package evolution - 2.8.3-1.fc6.i386 in mode u ---> Package evolution.i386 0:2.8.3-1.fc6 set to be updated Adding Package vte - 0.14.2-1.fc6.i386 in mode u ---> Package vte.i386 0:0.14.2-1.fc6 set to be updated kernel - 2.6.20-1.2933.fc6.i586 converted to install Adding Package kernel - 2.6.20-1.2933.fc6.i586 in mode i ---> Package kernel.i586 0:2.6.20-1.2933.fc6 set to be installed Adding Package netpbm - 10.35-8.1.fc6.i386 in mode u ---> Package netpbm.i386 0:10.35-8.1.fc6 set to be updated Adding Package gimp-print-utils - 4.2.7-23.fc6.i386 in mode u ---> Package gimp-print-utils.i386 0:4.2.7-23.fc6 set to be updated Adding Package gnome-desktop - 2.16.3-1.fc6.i386 in mode u ---> Package gnome-desktop.i386 0:2.16.3-1.fc6 set to be updated Adding Package pwlib - 1.10.4-1.fc6.i386 in mode u ---> Package pwlib.i386 0:1.10.4-1.fc6 set to be updated Adding Package python-numeric - 24.2-1.fc6.i386 in mode u ---> Package python-numeric.i386 0:24.2-1.fc6 set to be updated Adding Package at - 3.1.8-85.fc6.i386 in mode u ---> Package at.i386 0:3.1.8-85.fc6 set to be updated Adding Package nss - 3.11.5-0.6.1.fc6.i386 in mode u ---> Package nss.i386 0:3.11.5-0.6.1.fc6 set to be updated Adding Package slrn - 0.9.8.1pl1-2.fc6.i386 in mode u ---> Package slrn.i386 0:0.9.8.1pl1-2.fc6 set to be updated Adding Package xsane-gimp - 0.991-4.fc6.i386 in mode u ---> Package xsane-gimp.i386 0:0.991-4.fc6 set to be updated Adding Package a2ps - 4.13b-57.fc6.3.i386 in mode u ---> Package a2ps.i386 0:4.13b-57.fc6.3 set to be updated Adding Package apr-util - 1.2.8-1.fc6.i386 in mode u ---> Package apr-util.i386 0:1.2.8-1.fc6 set to be updated Adding Package mono-core - 1.1.17.1-4.fc6.i386 in mode u ---> Package mono-core.i386 0:1.1.17.1-4.fc6 set to be updated Adding Package system-config-printer-libs - 0.7.52-1.fc6.i386 in mode u ---> Package system-config-printer-libs.i386 0:0.7.52-1.fc6 set to be updated Adding Package beagle - 0.2.13-1.fc6.i386 in mode u ---> Package beagle.i386 0:0.2.13-1.fc6 set to be updated Adding Package vim-common - 2:7.0.201-1.fc6.i386 in mode u ---> Package vim-common.i386 2:7.0.201-1.fc6 set to be updated Adding Package dbus-x11 - 1.0.1-9.fc6.i386 in mode u ---> Package dbus-x11.i386 0:1.0.1-9.fc6 set to be updated Adding Package gnome-python2-bonobo - 2.16.2-2.fc6.i386 in mode u ---> Package gnome-python2-bonobo.i386 0:2.16.2-2.fc6 set to be updated Adding Package openoffice.org-xsltfilter - 1:2.0.4-5.5.10.i386 in mode u ---> Package openoffice.org-xsltfilter.i386 1:2.0.4-5.5.10 set to be updated Adding Package libdrm - 2.3.0-1.fc6.i386 in mode u ---> Package libdrm.i386 0:2.3.0-1.fc6 set to be updated Adding Package anacron - 2.3-44.fc6.i386 in mode u ---> Package anacron.i386 0:2.3-44.fc6 set to be updated Adding Package libselinux-python - 1.33.4-2.fc6.i386 in mode u ---> Package libselinux-python.i386 0:1.33.4-2.fc6 set to be updated Adding Package htmlview - 3.0.0-15.fc6.noarch in mode u ---> Package htmlview.noarch 0:3.0.0-15.fc6 set to be updated Adding Package iproute - 2.6.19-1.fc6.i386 in mode u ---> Package iproute.i386 0:2.6.19-1.fc6 set to be updated Adding Package bind-utils - 31:9.3.4-3.fc6.i386 in mode u ---> Package bind-utils.i386 31:9.3.4-3.fc6 set to be updated Adding Package gd - 2.0.33-10.fc6.i386 in mode u ---> Package gd.i386 0:2.0.33-10.fc6 set to be updated Adding Package xorg-x11-drv-i810 - 1.6.5-10.fc6.i386 in mode u ---> Package xorg-x11-drv-i810.i386 0:1.6.5-10.fc6 set to be updated Adding Package krb5-libs - 1.5-13.i386 in mode u ---> Package krb5-libs.i386 0:1.5-13 set to be updated Adding Package policycoreutils - 1.34.1-4.fc6.i386 in mode u ---> Package policycoreutils.i386 0:1.34.1-4.fc6 set to be updated Adding Package file-roller - 2.16.3-1.fc6.i386 in mode u ---> Package file-roller.i386 0:2.16.3-1.fc6 set to be updated Adding Package tcpdump - 14:3.9.4-10.fc6.i386 in mode u ---> Package tcpdump.i386 14:3.9.4-10.fc6 set to be updated Adding Package mono-data-sqlite - 1.1.17.1-4.fc6.i386 in mode u ---> Package mono-data-sqlite.i386 0:1.1.17.1-4.fc6 set to be updated Adding Package mesa-libGL - 6.5.1-9.fc6.i386 in mode u ---> Package mesa-libGL.i386 0:6.5.1-9.fc6 set to be updated Adding Package sound-juicer - 2.16.3-1.fc6.i386 in mode u ---> Package sound-juicer.i386 0:2.16.3-1.fc6 set to be updated Adding Package notification-daemon - 0.3.6-1.fc6.i386 in mode u ---> Package notification-daemon.i386 0:0.3.6-1.fc6 set to be updated Adding Package xorg-x11-drv-mga - 1.4.5-2.fc6.i386 in mode u ---> Package xorg-x11-drv-mga.i386 0:1.4.5-2.fc6 set to be updated Adding Package pam - 0.99.6.2-3.16.fc6.i386 in mode u ---> Package pam.i386 0:0.99.6.2-3.16.fc6 set to be updated Adding Package openoffice.org-writer - 1:2.0.4-5.5.10.i386 in mode u ---> Package openoffice.org-writer.i386 1:2.0.4-5.5.10 set to be updated Adding Package samba-client - 3.0.24-1.fc6.i386 in mode u ---> Package samba-client.i386 0:3.0.24-1.fc6 set to be updated Adding Package authconfig - 5.3.12-1.fc6.i386 in mode u ---> Package authconfig.i386 0:5.3.12-1.fc6 set to be updated Adding Package gnome-vfs2-smb - 2.16.2-2.fc6.i386 in mode u ---> Package gnome-vfs2-smb.i386 0:2.16.2-2.fc6 set to be updated Adding Package setup - 2.6.1.1-1.fc6.noarch in mode u ---> Package setup.noarch 0:2.6.1.1-1.fc6 set to be updated Adding Package glx-utils - 6.5.1-9.fc6.i386 in mode u ---> Package glx-utils.i386 0:6.5.1-9.fc6 set to be updated Adding Package yum - 3.0.3-1.fc6.noarch in mode u ---> Package yum.noarch 0:3.0.3-1.fc6 set to be updated Adding Package openoffice.org-graphicfilter - 1:2.0.4-5.5.10.i386 in mode u ---> Package openoffice.org-graphicfilter.i386 1:2.0.4-5.5.10 set to be updated Adding Package shadow-utils - 2:4.0.17-12.fc6.i386 in mode u ---> Package shadow-utils.i386 2:4.0.17-12.fc6 set to be updated Adding Package grep - 2.5.1-54.1.2.fc6.i386 in mode u ---> Package grep.i386 0:2.5.1-54.1.2.fc6 set to be updated Adding Package gstreamer-plugins-base - 0.10.10-1.fc6.i386 in mode u ---> Package gstreamer-plugins-base.i386 0:0.10.10-1.fc6 set to be updated Adding Package gnome-icon-theme - 2.16.0.1-3.fc6.noarch in mode u ---> Package gnome-icon-theme.noarch 0:2.16.0.1-3.fc6 set to be updated Adding Package opal - 2.2.5-1.fc6.i386 in mode u ---> Package opal.i386 0:2.2.5-1.fc6 set to be updated Adding Package pygtk2 - 2.10.4-1.fc6.i386 in mode u ---> Package pygtk2.i386 0:2.10.4-1.fc6 set to be updated Adding Package ImageMagick - 6.2.8.0-3.fc6.1.i386 in mode u ---> Package ImageMagick.i386 0:6.2.8.0-3.fc6.1 set to be updated Adding Package udev - 095-17.fc6.i386 in mode u ---> Package udev.i386 0:095-17.fc6 set to be updated Adding Package gnome-applets - 1:2.16.0.1-12.fc6.i386 in mode u ---> Package gnome-applets.i386 1:2.16.0.1-12.fc6 set to be updated Adding Package nautilus-cd-burner - 2.16.3-1.fc6.i386 in mode u ---> Package nautilus-cd-burner.i386 0:2.16.3-1.fc6 set to be updated Adding Package bind-libs - 31:9.3.4-3.fc6.i386 in mode u ---> Package bind-libs.i386 31:9.3.4-3.fc6 set to be updated Adding Package binutils - 2.17.50.0.6-2.fc6.i386 in mode u ---> Package binutils.i386 0:2.17.50.0.6-2.fc6 set to be updated Adding Package spamassassin - 3.1.8-2.fc6.i386 in mode u ---> Package spamassassin.i386 0:3.1.8-2.fc6 set to be updated Adding Package gnome-vfs2 - 2.16.2-2.fc6.i386 in mode u ---> Package gnome-vfs2.i386 0:2.16.2-2.fc6 set to be updated Adding Package yum-metadata-parser - 1.0.3-1.fc6.i386 in mode u ---> Package yum-metadata-parser.i386 0:1.0.3-1.fc6 set to be updated Adding Package gmp - 4.1.4-9.fc6.i386 in mode u ---> Package gmp.i386 0:4.1.4-9.fc6 set to be updated Adding Package poppler-utils - 0.5.4-5.fc6.i386 in mode u ---> Package poppler-utils.i386 0:0.5.4-5.fc6 set to be updated Adding Package openssh - 4.3p2-18.fc6.i386 in mode u ---> Package openssh.i386 0:4.3p2-18.fc6 set to be updated Adding Package mono-web - 1.1.17.1-4.fc6.i386 in mode u ---> Package mono-web.i386 0:1.1.17.1-4.fc6 set to be updated Adding Package nss-tools - 3.11.5-0.6.1.fc6.i386 in mode u ---> Package nss-tools.i386 0:3.11.5-0.6.1.fc6 set to be updated Adding Package yum-updatesd - 3.0.3-1.fc6.noarch in mode u ---> Package yum-updatesd.noarch 0:3.0.3-1.fc6 set to be updated Adding Package xorg-x11-drv-mouse - 1.2.1-1.fc6.i386 in mode u ---> Package xorg-x11-drv-mouse.i386 0:1.2.1-1.fc6 set to be updated Adding Package krb5-workstation - 1.5-13.i386 in mode u ---> Package krb5-workstation.i386 0:1.5-13 set to be updated Adding Package gnome-python2 - 2.16.2-2.fc6.i386 in mode u ---> Package gnome-python2.i386 0:2.16.2-2.fc6 set to be updated Adding Package gnome-pilot - 2.0.15-1.fc6.i386 in mode u ---> Package gnome-pilot.i386 0:2.0.15-1.fc6 set to be updated Adding Package libgpod - 0.4.2-0.1.fc6.i386 in mode u ---> Package libgpod.i386 0:0.4.2-0.1.fc6 set to be updated Adding Package pycairo - 1.2.6-1.fc6.i386 in mode u ---> Package pycairo.i386 0:1.2.6-1.fc6 set to be updated Adding Package system-config-soundcard - 2.0.5-2.fc6.noarch in mode u ---> Package system-config-soundcard.noarch 0:2.0.5-2.fc6 set to be updated Adding Package hsqldb - 1:1.8.0.7-2jpp.1.i386 in mode u ---> Package hsqldb.i386 1:1.8.0.7-2jpp.1 set to be updated Adding Package libX11 - 1.0.3-6.fc6.i386 in mode u ---> Package libX11.i386 0:1.0.3-6.fc6 set to be updated Adding Package slang - 2.0.7-1.fc6.i386 in mode u ---> Package slang.i386 0:2.0.7-1.fc6 set to be updated Adding Package samba-common - 3.0.24-1.fc6.i386 in mode u ---> Package samba-common.i386 0:3.0.24-1.fc6 set to be updated Adding Package bzip2 - 1.0.3-6.fc6.i386 in mode u ---> Package bzip2.i386 0:1.0.3-6.fc6 set to be updated Adding Package ORBit2 - 2.14.3-4.fc6.i386 in mode u ---> Package ORBit2.i386 0:2.14.3-4.fc6 set to be updated Adding Package lvm2 - 2.02.17-1.fc6.i386 in mode u ---> Package lvm2.i386 0:2.02.17-1.fc6 set to be updated Adding Package mono-data - 1.1.17.1-4.fc6.i386 in mode u ---> Package mono-data.i386 0:1.1.17.1-4.fc6 set to be updated Adding Package enscript - 1.6.4-5.fc6.i386 in mode u ---> Package enscript.i386 0:1.6.4-5.fc6 set to be updated Adding Package wget - 1.10.2-8.fc6.1.i386 in mode u ---> Package wget.i386 0:1.10.2-8.fc6.1 set to be updated Adding Package totem-mozplugin - 2.16.5-1.fc6.i386 in mode u ---> Package totem-mozplugin.i386 0:2.16.5-1.fc6 set to be updated Adding Package dbus - 1.0.1-9.fc6.i386 in mode u ---> Package dbus.i386 0:1.0.1-9.fc6 set to be updated Adding Package pango - 1.14.10-1.fc6.i386 in mode u ---> Package pango.i386 0:1.14.10-1.fc6 set to be updated Adding Package libselinux - 1.33.4-2.fc6.i386 in mode u ---> Package libselinux.i386 0:1.33.4-2.fc6 set to be updated Adding Package parted - 1.8.2-1.fc6.i386 in mode u ---> Package parted.i386 0:1.8.2-1.fc6 set to be updated Adding Package glib2 - 2.12.9-1.fc6.i386 in mode u ---> Package glib2.i386 0:2.12.9-1.fc6 set to be updated Adding Package evince - 0.6.0-6.fc6.i386 in mode u ---> Package evince.i386 0:0.6.0-6.fc6 set to be updated Adding Package wpa_supplicant - 1:0.4.9-1.fc6.i386 in mode u ---> Package wpa_supplicant.i386 1:0.4.9-1.fc6 set to be updated Adding Package gphoto2 - 2.3.1-3.fc6.i386 in mode u ---> Package gphoto2.i386 0:2.3.1-3.fc6 set to be updated Adding Package kudzu - 1.2.57.6-1.i386 in mode u ---> Package kudzu.i386 0:1.2.57.6-1 set to be updated Adding Package gaim - 2:2.0.0-0.26.beta5.fc6.i386 in mode u ---> Package gaim.i386 2:2.0.0-0.26.beta5.fc6 set to be updated Adding Package zenity - 2.16.3-1.fc6.i386 in mode u ---> Package zenity.i386 0:2.16.3-1.fc6 set to be updated Adding Package glibc - 2.5-10.fc6.i686 in mode u ---> Package glibc.i686 0:2.5-10.fc6 set to be updated Adding Package gawk - 3.1.5-14.fc6.i386 in mode u ---> Package gawk.i386 0:3.1.5-14.fc6 set to be updated Adding Package nfs-utils - 1:1.0.10-5.fc6.i386 in mode u ---> Package nfs-utils.i386 1:1.0.10-5.fc6 set to be updated Adding Package man-pages - 2.39-7.fc6.noarch in mode u ---> Package man-pages.noarch 0:2.39-7.fc6 set to be updated Adding Package psacct - 6.3.2-42.fc6.i386 in mode u ---> Package psacct.i386 0:6.3.2-42.fc6 set to be updated Adding Package avahi-glib - 0.6.16-2.fc6.i386 in mode u ---> Package avahi-glib.i386 0:0.6.16-2.fc6 set to be updated Adding Package xorg-x11-drv-tdfx - 1.3.0-2.fc6.i386 in mode u ---> Package xorg-x11-drv-tdfx.i386 0:1.3.0-2.fc6 set to be updated Adding Package gnome-games - 1:2.16.3-2.fc6.i386 in mode u ---> Package gnome-games.i386 1:2.16.3-2.fc6 set to be updated Adding Package dvd+rw-tools - 7.0-0.fc6.4.i386 in mode u ---> Package dvd+rw-tools.i386 0:7.0-0.fc6.4 set to be updated Adding Package vnc-server - 4.1.2-9.fc6.i386 in mode u ---> Package vnc-server.i386 0:4.1.2-9.fc6 set to be updated Adding Package gnome-python2-canvas - 2.16.2-2.fc6.i386 in mode u ---> Package gnome-python2-canvas.i386 0:2.16.2-2.fc6 set to be updated Adding Package alsa-utils - 1.0.14-0.1.rc1.fc6.i386 in mode u ---> Package alsa-utils.i386 0:1.0.14-0.1.rc1.fc6 set to be updated Adding Package openssl - 0.9.8b-8.3.fc6.i686 in mode u ---> Package openssl.i686 0:0.9.8b-8.3.fc6 set to be updated Adding Package pygobject2 - 2.12.3-1.fc6.i386 in mode u ---> Package pygobject2.i386 0:2.12.3-1.fc6 set to be updated Adding Package ekiga - 2.0.5-3.fc6.i386 in mode u ---> Package ekiga.i386 0:2.0.5-3.fc6 set to be updated Adding Package SDL - 1.2.10-8.fc6.i386 in mode u ---> Package SDL.i386 0:1.2.10-8.fc6 set to be updated Adding Package gnome-python2-extras - 2.14.2-9.fc6.i386 in mode u ---> Package gnome-python2-extras.i386 0:2.14.2-9.fc6 set to be updated Adding Package nscd - 2.5-10.fc6.i386 in mode u ---> Package nscd.i386 0:2.5-10.fc6 set to be updated Adding Package cpuspeed - 1:1.2.1-1.46.fc6.i386 in mode u ---> Package cpuspeed.i386 1:1.2.1-1.46.fc6 set to be updated Adding Package libbeagle - 0.2.13-1.fc6.i386 in mode u ---> Package libbeagle.i386 0:0.2.13-1.fc6 set to be updated Adding Package gtkhtml3 - 3.12.3-1.fc6.i386 in mode u ---> Package gtkhtml3.i386 0:3.12.3-1.fc6 set to be updated Adding Package libvolume_id - 095-17.fc6.i386 in mode u ---> Package libvolume_id.i386 0:095-17.fc6 set to be updated Adding Package avahi - 0.6.16-2.fc6.i386 in mode u ---> Package avahi.i386 0:0.6.16-2.fc6 set to be updated Adding Package openssh-server - 4.3p2-18.fc6.i386 in mode u ---> Package openssh-server.i386 0:4.3p2-18.fc6 set to be updated Adding Package beagle-gui - 0.2.13-1.fc6.i386 in mode u ---> Package beagle-gui.i386 0:0.2.13-1.fc6 set to be updated Adding Package librsvg2 - 2.16.1-1.fc6.i386 in mode u ---> Package librsvg2.i386 0:2.16.1-1.fc6 set to be updated Adding Package gstreamer-plugins-good - 0.10.4-3.fc6.i386 in mode u ---> Package gstreamer-plugins-good.i386 0:0.10.4-3.fc6 set to be updated Adding Package alsa-lib - 1.0.14-0.1.rc1.fc6.i386 in mode u ---> Package alsa-lib.i386 0:1.0.14-0.1.rc1.fc6 set to be updated Adding Package pygtk2-libglade - 2.10.4-1.fc6.i386 in mode u ---> Package pygtk2-libglade.i386 0:2.10.4-1.fc6 set to be updated Adding Package evolution-data-server - 1.8.3-4.fc6.i386 in mode u ---> Package evolution-data-server.i386 0:1.8.3-4.fc6 set to be updated Adding Package orca - 1.0.1-1.fc6.i386 in mode u ---> Package orca.i386 0:1.0.1-1.fc6 set to be updated Adding Package xorg-x11-drv-trident - 1.2.3-1.fc6.i386 in mode u ---> Package xorg-x11-drv-trident.i386 0:1.2.3-1.fc6 set to be updated Adding Package gnome-panel - 2.16.3-2.fc6.i386 in mode u ---> Package gnome-panel.i386 0:2.16.3-2.fc6 set to be updated Adding Package openoffice.org-impress - 1:2.0.4-5.5.10.i386 in mode u ---> Package openoffice.org-impress.i386 1:2.0.4-5.5.10 set to be updated Adding Package logwatch - 7.3-7.fc6.noarch in mode u ---> Package logwatch.noarch 0:7.3-7.fc6 set to be updated Adding Package nspr - 4.6.6-0.6.0.fc6.i386 in mode u ---> Package nspr.i386 0:4.6.6-0.6.0.fc6 set to be updated Adding Package net-snmp-libs - 1:5.3.1-13.fc6.i386 in mode u ---> Package net-snmp-libs.i386 1:5.3.1-13.fc6 set to be updated Adding Package file - 4.19-1.fc6.i386 in mode u ---> Package file.i386 0:4.19-1.fc6 set to be updated Adding Package system-config-network-tui - 1.3.96-1.fc6.noarch in mode u ---> Package system-config-network-tui.noarch 0:1.3.96-1.fc6 set to be updated Adding Package gnome-themes - 2.16.3-1.fc6.noarch in mode u ---> Package gnome-themes.noarch 0:2.16.3-1.fc6 set to be updated Adding Package ypbind - 3:1.19-6.fc6.i386 in mode u ---> Package ypbind.i386 3:1.19-6.fc6 set to be updated Adding Package xorg-x11-xinit - 1.0.2-15.fc6.i386 in mode u ---> Package xorg-x11-xinit.i386 0:1.0.2-15.fc6 set to be updated Adding Package vorbis-tools - 1:1.1.1-3.fc6.i386 in mode u ---> Package vorbis-tools.i386 1:1.1.1-3.fc6 set to be updated Adding Package libgnomeprint22 - 2.12.1-9.fc6.i386 in mode u ---> Package libgnomeprint22.i386 0:2.12.1-9.fc6 set to be updated Adding Package cpio - 2.6-21.fc6.i386 in mode u ---> Package cpio.i386 0:2.6-21.fc6 set to be updated Adding Package yelp - 2.16.0-12.fc6.i386 in mode u ---> Package yelp.i386 0:2.16.0-12.fc6 set to be updated Adding Package gnome-bluetooth - 0.7.0-11.fc6.i386 in mode u ---> Package gnome-bluetooth.i386 0:0.7.0-11.fc6 set to be updated Adding Package bluez-utils - 3.7-2.i386 in mode u ---> Package bluez-utils.i386 0:3.7-2 set to be updated Adding Package netpbm-progs - 10.35-8.1.fc6.i386 in mode u ---> Package netpbm-progs.i386 0:10.35-8.1.fc6 set to be updated Adding Package bluez-gnome - 0.6-1.fc6.i386 in mode u ---> Package bluez-gnome.i386 0:0.6-1.fc6 set to be updated Adding Package redhat-artwork - 5.0.8-4.fc6.i386 in mode u ---> Package redhat-artwork.i386 0:5.0.8-4.fc6 set to be updated Adding Package gamin - 0.1.7-8.fc6.i386 in mode u ---> Package gamin.i386 0:0.1.7-8.fc6 set to be updated Adding Package PyQt - 3.17-0.1.fc6.i386 in mode u ---> Package PyQt.i386 0:3.17-0.1.fc6 set to be updated Adding Package gtk2 - 2.10.8-1.fc6.i386 in mode u ---> Package gtk2.i386 0:2.10.8-1.fc6 set to be updated Adding Package xsane - 0.991-4.fc6.i386 in mode u ---> Package xsane.i386 0:0.991-4.fc6 set to be updated Adding Package firefox - 1.5.0.10-5.fc6.i386 in mode u ---> Package firefox.i386 0:1.5.0.10-5.fc6 set to be updated Adding Package initscripts - 8.45.7-1.i386 in mode u ---> Package initscripts.i386 0:8.45.7-1 set to be updated Adding Package gimp-print - 4.2.7-23.fc6.i386 in mode u ---> Package gimp-print.i386 0:4.2.7-23.fc6 set to be updated Adding Package dhcdbd - 2.1-2.fc6.i386 in mode u ---> Package dhcdbd.i386 0:2.1-2.fc6 set to be updated Adding Package xorg-x11-server-Xorg - 1.1.1-47.7.fc6.i386 in mode u ---> Package xorg-x11-server-Xorg.i386 0:1.1.1-47.7.fc6 set to be updated Adding Package system-config-users - 1.2.47-1.fc6.noarch in mode u ---> Package system-config-users.noarch 0:1.2.47-1.fc6 set to be updated Adding Package hplip - 1.6.12-1.fc6.i386 in mode u ---> Package hplip.i386 0:1.6.12-1.fc6 set to be updated Adding Package eog - 2.16.3-1.fc6.i386 in mode u ---> Package eog.i386 0:2.16.3-1.fc6 set to be updated Adding Package openoffice.org-math - 1:2.0.4-5.5.10.i386 in mode u ---> Package openoffice.org-math.i386 1:2.0.4-5.5.10 set to be updated Adding Package tcsh - 6.14-12.i386 in mode u ---> Package tcsh.i386 0:6.14-12 set to be updated Adding Package cups-libs - 1:1.2.7-1.8.fc6.i386 in mode u ---> Package cups-libs.i386 1:1.2.7-1.8.fc6 set to be updated Adding Package vim-enhanced - 2:7.0.201-1.fc6.i386 in mode u ---> Package vim-enhanced.i386 2:7.0.201-1.fc6 set to be updated Adding Package desktop-printing - 0.19-21.fc6.i386 in mode u ---> Package desktop-printing.i386 0:0.19-21.fc6 set to be updated Adding Package cadaver - 0.22.3-4.fc6.i386 in mode u ---> Package cadaver.i386 0:0.22.3-4.fc6 set to be updated Adding Package compiz - 0.3.6-2.fc6.i386 in mode u ---> Package compiz.i386 0:0.3.6-2.fc6 set to be updated Adding Package mkinitrd - 5.1.19.0.3-1.i386 in mode u ---> Package mkinitrd.i386 0:5.1.19.0.3-1 set to be updated Adding Package selinux-policy - 2.4.6-42.fc6.noarch in mode u ---> Package selinux-policy.noarch 0:2.4.6-42.fc6 set to be updated Adding Package gnome-bluetooth-libs - 0.7.0-11.fc6.i386 in mode u ---> Package gnome-bluetooth-libs.i386 0:0.7.0-11.fc6 set to be updated Adding Package elfutils-libelf - 0.126-1.fc6.i386 in mode u ---> Package elfutils-libelf.i386 0:0.126-1.fc6 set to be updated Adding Package postgresql-libs - 8.1.8-1.fc6.i386 in mode u ---> Package postgresql-libs.i386 0:8.1.8-1.fc6 set to be updated Adding Package hal-cups-utils - 0.6.5-1.fc6.i386 in mode u ---> Package hal-cups-utils.i386 0:0.6.5-1.fc6 set to be updated Adding Package e2fsprogs-libs - 1.39-7.fc6.i386 in mode u ---> Package e2fsprogs-libs.i386 0:1.39-7.fc6 set to be updated Adding Package libxklavier - 3.0-2.fc6.i386 in mode u ---> Package libxklavier.i386 0:3.0-2.fc6 set to be updated Adding Package rsync - 2.6.9-2.fc6.i386 in mode u ---> Package rsync.i386 0:2.6.9-2.fc6 set to be updated Adding Package dhclient - 12:3.0.5-3.fc6.i386 in mode u ---> Package dhclient.i386 12:3.0.5-3.fc6 set to be updated Adding Package netdump - 0.7.16-13.i386 in mode u ---> Package netdump.i386 0:0.7.16-13 set to be updated Adding Package libdv - 1.0.0-1.fc6.i386 in mode u ---> Package libdv.i386 0:1.0.0-1.fc6 set to be updated Adding Package autofs - 1:5.0.1-0.rc3.26.i386 in mode u ---> Package autofs.i386 1:5.0.1-0.rc3.26 set to be updated Adding Package gpm - 1.20.1-81.fc6.i386 in mode u ---> Package gpm.i386 0:1.20.1-81.fc6 set to be updated Adding Package crontabs - 1.10-12.fc6.noarch in mode u ---> Package crontabs.noarch 0:1.10-12.fc6 set to be updated Adding Package agg - 2.4-2.2.i386 in mode u ---> Package agg.i386 0:2.4-2.2 set to be updated Adding Package hal - 0.5.8.1-6.fc6.i386 in mode u ---> Package hal.i386 0:0.5.8.1-6.fc6 set to be updated Adding Package gimp-print-plugin - 4.2.7-23.fc6.i386 in mode u ---> Package gimp-print-plugin.i386 0:4.2.7-23.fc6 set to be updated Adding Package vino - 2.13.5-6.fc6.i386 in mode u ---> Package vino.i386 0:2.13.5-6.fc6 set to be updated Adding Package libsane-hpaio - 1.6.12-1.fc6.i386 in mode u ---> Package libsane-hpaio.i386 0:1.6.12-1.fc6 set to be updated Adding Package tar - 2:1.15.1-24.fc6.i386 in mode u ---> Package tar.i386 2:1.15.1-24.fc6 set to be updated Adding Package irqbalance - 2:0.55-2.fc6.i386 in mode u ---> Package irqbalance.i386 2:0.55-2.fc6 set to be updated Adding Package traceroute - 3:2.0.3-1.fc6.i386 in mode u ---> Package traceroute.i386 3:2.0.3-1.fc6 set to be updated Adding Package libsepol - 1.15.3-1.fc6.i386 in mode u ---> Package libsepol.i386 0:1.15.3-1.fc6 set to be updated Adding Package gstreamer-tools - 0.10.10-2.fc6.i386 in mode u ---> Package gstreamer-tools.i386 0:0.10.10-2.fc6 set to be updated Adding Package mlocate - 0.15-0.fc6.1.i386 in mode u ---> Package mlocate.i386 0:0.15-0.fc6.1 set to be updated Adding Package jpackage-utils - 1.7.3-1jpp.2.fc6.noarch in mode u ---> Package jpackage-utils.noarch 0:1.7.3-1jpp.2.fc6 set to be updated Adding Package libwpd - 0.8.9-1.fc6.i386 in mode u ---> Package libwpd.i386 0:0.8.9-1.fc6 set to be updated Adding Package rsh - 0.17-38.fc6.i386 in mode u ---> Package rsh.i386 0:0.17-38.fc6 set to be updated Adding Package vim-minimal - 2:7.0.201-1.fc6.i386 in mode u ---> Package vim-minimal.i386 2:7.0.201-1.fc6 set to be updated Adding Package cups - 1:1.2.7-1.8.fc6.i386 in mode u ---> Package cups.i386 1:1.2.7-1.8.fc6 set to be updated Adding Package glibc-common - 2.5-10.fc6.i386 in mode u ---> Package glibc-common.i386 0:2.5-10.fc6 set to be updated Adding Package cairo - 1.2.6-1.fc6.i386 in mode u ---> Package cairo.i386 0:1.2.6-1.fc6 set to be updated Adding Package metacity - 2.16.5-1.fc6.i386 in mode u ---> Package metacity.i386 0:2.16.5-1.fc6 set to be updated Adding Package selinux-policy-targeted - 2.4.6-42.fc6.noarch in mode u ---> Package selinux-policy-targeted.noarch 0:2.4.6-42.fc6 set to be updated Adding Package mutt - 5:1.4.2.2-5.fc6.i386 in mode u ---> Package mutt.i386 5:1.4.2.2-5.fc6 set to be updated Adding Package libxml2 - 2.6.27-1.FC6.i386 in mode u ---> Package libxml2.i386 0:2.6.27-1.FC6 set to be updated Adding Package poppler - 0.5.4-5.fc6.i386 in mode u ---> Package poppler.i386 0:0.5.4-5.fc6 set to be updated Adding Package gettext - 0.14.6-4.fc6.i386 in mode u ---> Package gettext.i386 0:0.14.6-4.fc6 set to be updated Adding Package rhgb - 0.16.4-3.fc6.i386 in mode u ---> Package rhgb.i386 0:0.16.4-3.fc6 set to be updated Adding Package gnome-volume-manager - 2.15.0-4.fc6.i386 in mode u ---> Package gnome-volume-manager.i386 0:2.15.0-4.fc6 set to be updated Adding Package rhythmbox - 0.9.7-1.fc6.i386 in mode u ---> Package rhythmbox.i386 0:0.9.7-1.fc6 set to be updated Adding Package totem - 2.16.5-1.fc6.i386 in mode u ---> Package totem.i386 0:2.16.5-1.fc6 set to be updated Adding Package libpcap - 14:0.9.4-10.fc6.i386 in mode u ---> Package libpcap.i386 14:0.9.4-10.fc6 set to be updated Adding Package e2fsprogs - 1.39-7.fc6.i386 in mode u ---> Package e2fsprogs.i386 0:1.39-7.fc6 set to be updated Adding Package gnome-power-manager - 2.16.3-1.fc6.i386 in mode u ---> Package gnome-power-manager.i386 0:2.16.3-1.fc6 set to be updated Adding Package gstreamer - 0.10.10-2.fc6.i386 in mode u ---> Package gstreamer.i386 0:0.10.10-2.fc6 set to be updated Adding Package man - 1.6d-2.fc6.i386 in mode u ---> Package man.i386 0:1.6d-2.fc6 set to be updated Adding Package sysklogd - 1.4.1-41.fc6.i386 in mode u ---> Package sysklogd.i386 0:1.4.1-41.fc6 set to be updated Adding Package libwnck - 2.16.3-1.fc6.i386 in mode u ---> Package libwnck.i386 0:2.16.3-1.fc6 set to be updated Adding Package system-config-network - 1.3.96-1.fc6.noarch in mode u ---> Package system-config-network.noarch 0:1.3.96-1.fc6 set to be updated Adding Package beagle-evolution - 0.2.13-1.fc6.i386 in mode u ---> Package beagle-evolution.i386 0:0.2.13-1.fc6 set to be updated Adding Package gcalctool - 5.8.25-1.fc6.i386 in mode u ---> Package gcalctool.i386 0:5.8.25-1.fc6 set to be updated Adding Package audit-libs - 1.4.2-3.fc6.i386 in mode u ---> Package audit-libs.i386 0:1.4.2-3.fc6 set to be updated Adding Package libgcc - 4.1.1-51.fc6.i386 in mode u ---> Package libgcc.i386 0:4.1.1-51.fc6 set to be updated Adding Package vixie-cron - 4:4.1-68.fc6.i386 in mode u ---> Package vixie-cron.i386 4:4.1-68.fc6 set to be updated Adding Package gnome-screensaver - 2.16.1-4.fc6.i386 in mode u ---> Package gnome-screensaver.i386 0:2.16.1-4.fc6 set to be updated Adding Package libstdc++ - 4.1.1-51.fc6.i386 in mode u ---> Package libstdc++.i386 0:4.1.1-51.fc6 set to be updated Adding Package coreutils - 5.97-12.3.fc6.i386 in mode u ---> Package coreutils.i386 0:5.97-12.3.fc6 set to be updated Adding Package paps - 0.6.6-18.fc6.i386 in mode u ---> Package paps.i386 0:0.6.6-18.fc6 set to be updated Adding Package gnome-session - 2.16.3-1.fc6.i386 in mode u ---> Package gnome-session.i386 0:2.16.3-1.fc6 set to be updated Adding Package sip - 4.5-0.1.fc6.i386 in mode u ---> Package sip.i386 0:4.5-0.1.fc6 set to be updated Adding Package eject - 2.1.5-4.1.fc6.i386 in mode u ---> Package eject.i386 0:2.1.5-4.1.fc6 set to be updated Adding Package python - 2.4.4-1.fc6.i386 in mode u ---> Package python.i386 0:2.4.4-1.fc6 set to be updated Adding Package qt - 1:3.3.7-0.1.fc6.i386 in mode u ---> Package qt.i386 1:3.3.7-0.1.fc6 set to be updated Adding Package xorg-x11-drv-s3 - 0.5.0-1.fc6.i386 in mode u ---> Package xorg-x11-drv-s3.i386 0:0.5.0-1.fc6 set to be updated Adding Package libnotify - 0.4.2-5.fc6.i386 in mode u ---> Package libnotify.i386 0:0.4.2-5.fc6 set to be updated Adding Package libgsf - 1.14.1-7.i386 in mode u ---> Package libgsf.i386 0:1.14.1-7 set to be updated Adding Package ntp - 4.2.4p0-1.fc6.i386 in mode u ---> Package ntp.i386 0:4.2.4p0-1.fc6 set to be updated Adding Package dbus-glib - 0.70-6.fc6.i386 in mode u ---> Package dbus-glib.i386 0:0.70-6.fc6 set to be updated Adding Package fetchmail - 6.3.6-2.fc6.i386 in mode u ---> Package fetchmail.i386 0:6.3.6-2.fc6 set to be updated Adding Package bzip2-libs - 1.0.3-6.fc6.i386 in mode u ---> Package bzip2-libs.i386 0:1.0.3-6.fc6 set to be updated Adding Package speex - 1.2-0.1.beta1.fc6.i386 in mode u ---> Package speex.i386 0:1.2-0.1.beta1.fc6 set to be updated Adding Package foomatic - 3.0.2-39.4.fc6.i386 in mode u ---> Package foomatic.i386 0:3.0.2-39.4.fc6 set to be updated Adding Package pinfo - 0.6.9-3.fc6.i386 in mode u ---> Package pinfo.i386 0:0.6.9-3.fc6 set to be updated Adding Package pirut - 1.2.8-1.fc6.noarch in mode u ---> Package pirut.noarch 0:1.2.8-1.fc6 set to be updated Adding Package openoffice.org-calc - 1:2.0.4-5.5.10.i386 in mode u ---> Package openoffice.org-calc.i386 1:2.0.4-5.5.10 set to be updated Adding Package smartmontools - 1:5.36-3.2.fc6.i386 in mode u ---> Package smartmontools.i386 1:5.36-3.2.fc6 set to be updated Adding Package control-center - 1:2.16.3-11.fc6.i386 in mode u ---> Package control-center.i386 1:2.16.3-11.fc6 set to be updated Adding Package gnome-python2-gconf - 2.16.2-2.fc6.i386 in mode u ---> Package gnome-python2-gconf.i386 0:2.16.2-2.fc6 set to be updated Adding Package freetype - 2.2.1-16.fc6.i386 in mode u ---> Package freetype.i386 0:2.2.1-16.fc6 set to be updated Adding Package gdm - 1:2.16.5-1.fc6.i386 in mode u ---> Package gdm.i386 1:2.16.5-1.fc6 set to be updated Adding Package gnome-mag - 0.13.2-1.fc6.i386 in mode u ---> Package gnome-mag.i386 0:0.13.2-1.fc6 set to be updated Adding Package nash - 5.1.19.0.3-1.i386 in mode u ---> Package nash.i386 0:5.1.19.0.3-1 set to be updated Adding Package xterm - 224-1.fc6.i386 in mode u ---> Package xterm.i386 0:224-1.fc6 set to be updated Adding Package libiec61883 - 1.1.0-1.fc6.i386 in mode u ---> Package libiec61883.i386 0:1.1.0-1.fc6 set to be updated Adding Package ppp - 2.4.4-1.fc6.i386 in mode u ---> Package ppp.i386 0:2.4.4-1.fc6 set to be updated Adding Package m4 - 1.4.5-4.i386 in mode u ---> Package m4.i386 0:1.4.5-4 set to be updated Adding Package gnome-python2-libegg - 2.14.2-9.fc6.i386 in mode u ---> Package gnome-python2-libegg.i386 0:2.14.2-9.fc6 set to be updated Adding Package openssh-askpass - 4.3p2-18.fc6.i386 in mode u ---> Package openssh-askpass.i386 0:4.3p2-18.fc6 set to be updated Adding Package audit-libs-python - 1.4.2-3.fc6.i386 in mode u ---> Package audit-libs-python.i386 0:1.4.2-3.fc6 set to be updated Adding Package elinks - 0.11.1-5.1.i386 in mode u ---> Package elinks.i386 0:0.11.1-5.1 set to be updated Adding Package nautilus - 2.16.2-7.fc6.i386 in mode u ---> Package nautilus.i386 0:2.16.2-7.fc6 set to be updated Adding Package system-config-date - 1.8.8-1.fc6.noarch in mode u ---> Package system-config-date.noarch 0:1.8.8-1.fc6 set to be updated Adding Package info - 4.8-14.fc6.i386 in mode u ---> Package info.i386 0:4.8-14.fc6 set to be updated Adding Package openssh-clients - 4.3p2-18.fc6.i386 in mode u ---> Package openssh-clients.i386 0:4.3p2-18.fc6 set to be updated Adding Package ghostscript - 8.15.3-4.fc6.i386 in mode u ---> Package ghostscript.i386 0:8.15.3-4.fc6 set to be updated Adding Package libxml2-python - 2.6.27-1.FC6.i386 in mode u ---> Package libxml2-python.i386 0:2.6.27-1.FC6 set to be updated Adding Package gnupg - 1.4.7-5.i386 in mode u ---> Package gnupg.i386 0:1.4.7-5 set to be updated Adding Package authconfig-gtk - 5.3.12-1.fc6.i386 in mode u ---> Package authconfig-gtk.i386 0:5.3.12-1.fc6 set to be updated Adding Package libsoup - 2.2.99-1.fc6.i386 in mode u ---> Package libsoup.i386 0:2.2.99-1.fc6 set to be updated Adding Package ed - 0.3-0.fc6.i386 in mode u ---> Package ed.i386 0:0.3-0.fc6 set to be updated Adding Package less - 394-5.fc6.i386 in mode u ---> Package less.i386 0:394-5.fc6 set to be updated Adding Package system-config-printer - 0.7.52-1.fc6.i386 in mode u ---> Package system-config-printer.i386 0:0.7.52-1.fc6 set to be updated Adding Package readahead - 1:1.3-7.fc6.i386 in mode u ---> Package readahead.i386 1:1.3-7.fc6 set to be updated Adding Package planner - 0.14.2-1.fc6.i386 in mode u ---> Package planner.i386 0:0.14.2-1.fc6 set to be updated Adding Package gnome-python2-gnomevfs - 2.16.2-2.fc6.i386 in mode u ---> Package gnome-python2-gnomevfs.i386 0:2.16.2-2.fc6 set to be updated Adding Package tzdata - 2007d-1.fc6.noarch in mode u ---> Package tzdata.noarch 0:2007d-1.fc6 set to be updated Adding Package xorg-x11-drv-ati - 6.6.3-1.fc6.i386 in mode u ---> Package xorg-x11-drv-ati.i386 0:6.6.3-1.fc6 set to be updated Adding Package openoffice.org-core - 1:2.0.4-5.5.10.i386 in mode u ---> Package openoffice.org-core.i386 1:2.0.4-5.5.10 set to be updated Adding Package kernel-headers - 2.6.20-1.2933.fc6.i386 in mode u ---> Package kernel-headers.i386 0:2.6.20-1.2933.fc6 set to be updated Adding Package procps - 3.2.7-8.2.fc6.i386 in mode u ---> Package procps.i386 0:3.2.7-8.2.fc6 set to be updated Adding Package logrotate - 3.7.4-12.fc6.i386 in mode u ---> Package logrotate.i386 0:3.7.4-12.fc6 set to be updated Adding Package jwhois - 3.2.3-8.fc6.i386 in mode u ---> Package jwhois.i386 0:3.2.3-8.fc6 set to be updated Adding Package nautilus-extensions - 2.16.2-7.fc6.i386 in mode u ---> Package nautilus-extensions.i386 0:2.16.2-7.fc6 set to be updated Adding Package GConf2 - 2.14.0-8.fc6.i386 in mode u ---> Package GConf2.i386 0:2.14.0-8.fc6 set to be updated Adding Package cpp - 4.1.1-51.fc6.i386 in mode u ---> Package cpp.i386 0:4.1.1-51.fc6 set to be updated Adding Package redhat-menus - 6.7.8-2.fc6.noarch in mode u ---> Package redhat-menus.noarch 0:6.7.8-2.fc6 set to be updated Adding Package device-mapper - 1.02.13-1.fc6.i386 in mode u ---> Package device-mapper.i386 0:1.02.13-1.fc6 set to be updated Adding Package openoffice.org-draw - 1:2.0.4-5.5.10.i386 in mode u ---> Package openoffice.org-draw.i386 1:2.0.4-5.5.10 set to be updated Adding Package hpijs - 1:1.6.12-1.fc6.i386 in mode u ---> Package hpijs.i386 1:1.6.12-1.fc6 set to be updated Adding Package mesa-libGLU - 6.5.1-9.fc6.i386 in mode u ---> Package mesa-libGLU.i386 0:6.5.1-9.fc6 set to be updated --> Running transaction check # of Deps = 3 Dep Number: 1/3 spamassassin requires: perl(LWP::UserAgent) --> Processing Dependency: perl(LWP::UserAgent) for package: spamassassin Requiring package is from transaction set Resolving for requiring package: spamassassin-3.1.8-2.fc6 in state u Resolving for requirement: perl(LWP::UserAgent) Searching pkgSack for dep: perl(LWP::UserAgent) Dep Number: 2/3 spamassassin requires: perl(HTTP::Date) --> Processing Dependency: perl(HTTP::Date) for package: spamassassin Requiring package is from transaction set Resolving for requiring package: spamassassin-3.1.8-2.fc6 in state u Resolving for requirement: perl(HTTP::Date) Searching pkgSack for dep: perl(HTTP::Date) Dep Number: 3/3 gaim requires: cyrus-sasl-md5 --> Processing Dependency: cyrus-sasl-md5 for package: gaim Requiring package is from transaction set Resolving for requiring package: gaim-2.0.0-0.26.beta5.fc6 in state u Resolving for requirement: cyrus-sasl-md5 Searching pkgSack for dep: cyrus-sasl-md5 Potential match for cyrus-sasl-md5 from cyrus-sasl-md5 - 2.1.22-4.i386 Matched cyrus-sasl-md5 - 2.1.22-4.i386 to require for cyrus-sasl-md5 TSINFO: Marking cyrus-sasl-md5 - 2.1.22-4.i386 as install for gaim miss = 2 conf = 0 CheckDeps = 1 --> Restarting Dependency Resolution with new changes. ---> Loop Number: 2 Restarting Loop --> Populating transaction set with selected packages. Please wait. Adding Package cyrus-sasl-md5 - 2.1.22-4.i386 in mode u ---> Package cyrus-sasl-md5.i386 0:2.1.22-4 set to be updated --> Running transaction check # of Deps = 2 Dep Number: 1/2 spamassassin requires: perl(LWP::UserAgent) --> Processing Dependency: perl(LWP::UserAgent) for package: spamassassin Requiring package is from transaction set Resolving for requiring package: spamassassin-3.1.8-2.fc6 in state u Resolving for requirement: perl(LWP::UserAgent) Searching pkgSack for dep: perl(LWP::UserAgent) Dep Number: 2/2 spamassassin requires: perl(HTTP::Date) --> Processing Dependency: perl(HTTP::Date) for package: spamassassin Requiring package is from transaction set Resolving for requiring package: spamassassin-3.1.8-2.fc6 in state u Resolving for requirement: perl(HTTP::Date) Searching pkgSack for dep: perl(HTTP::Date) miss = 4 conf = 0 CheckDeps = 0 --> Finished Dependency Resolution Dependency Process ending Running "postresolve" handler for "installonlyn" plugin Running "postresolve" handler for "presto" plugin Found deltarpm update for util-linux.i386 0:2.13.0.46.fc6 Found deltarpm update for libgcj.i386 0:4.1.1.51.fc6 Found deltarpm update for gjdoc.i386 0:0.7.7.14.fc6 Found deltarpm update for eel2.i386 0:2.16.1.1.fc6 Found deltarpm update for evolution.i386 0:2.8.3.1.fc6 Found deltarpm update for vte.i386 0:0.14.2.1.fc6 Found deltarpm update for kernel.i586 0:2.6.20.1.2933.fc6 Found deltarpm update for gimp-print-utils.i386 0:4.2.7.23.fc6 Found deltarpm update for gnome-desktop.i386 0:2.16.3.1.fc6 Found deltarpm update for at.i386 0:3.1.8.85.fc6 Found deltarpm update for nss.i386 0:3.11.5.0.6.1.fc6 Found deltarpm update for slrn.i386 0:0.9.8.1pl1.2.fc6 Found deltarpm update for xsane-gimp.i386 0:0.991.4.fc6 Found deltarpm update for a2ps.i386 0:4.13b.57.fc6.3 Found deltarpm update for apr-util.i386 0:1.2.8.1.fc6 Found deltarpm update for mono-core.i386 0:1.1.17.1.4.fc6 Traceback (most recent call last): File "/usr/bin/yum", line 29, in ? yummain.main(sys.argv[1:]) File "/usr/share/yum-cli/yummain.py", line 143, in main (result, resultmsgs) = base.buildTransaction() File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 442, in buildTransaction self.plugins.run('postresolve', rescode=rescode, restring=restring) File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 153, in run func(conduitcls(self, self.base, conf, **kwargs)) File "/usr/lib/yum-plugins/presto.py", line 85, in postresolve_hook (chosen_drpm, installed, local) = prestoTransaction.find_available_drpms(conduit, newpkg) File "/usr/share/presto/prestoTransaction.py", line 48, in find_available_drpms if os.path.exists(newpkg.po.localpath): AttributeError: YumInstalledPackage instance has no attribute 'localpath' Rahul From markg85 at gmail.com Mon Mar 26 15:35:37 2007 From: markg85 at gmail.com (Mark) Date: Mon, 26 Mar 2007 17:35:37 +0200 Subject: Where did /dev/hda (/dev/hd*) go to? In-Reply-To: <1174921980.17842.92.camel@metroid.rdu.redhat.com> References: <6e24a8e80703260752x28557c9ob43bfdd3b9167598@mail.gmail.com> <1174921980.17842.92.camel@metroid.rdu.redhat.com> Message-ID: <6e24a8e80703260835v3b739e61t9ab618bbaff1a060@mail.gmail.com> that`s new for me.. sdb did the trick for me. thanx for clearing this up. perhaps a good idea to add this in the fedora core 7 information / readme / faq or whatever is used to provide users with information about fedora. 2007/3/26, Will Woods : > > On Mon, 2007-03-26 at 16:52 +0200, Mark wrote: > > Hey, > > > > i`m having no problem mounting SD(A) devices but somehow /dev/hda > > simply doesn`t exist. > > even stranger. the only h named thing in the /dev folder is hpet > > (/dev/hpet). > > > > /dev should contain hda till hdz and it doesn`t contain any of those. > > > > is this a bug? or do i need to install a package first? > > i`m running rawhile with the latest updates. > > The rawhide kernel uses the new PATA/IDE subsystem, which (like the SATA > subsystem) goes through SCSI layer. All disk devices are /dev/sdX now. > > To sum up: > > /dev/hdX = old and busted > /dev/sdX = new hotness > > Enjoy, > > -w > > -- > 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 wwoods at redhat.com Mon Mar 26 15:37:29 2007 From: wwoods at redhat.com (Will Woods) Date: Mon, 26 Mar 2007 11:37:29 -0400 Subject: FC-6 NetworkManager needs some love In-Reply-To: <1174922765.8528.11.camel@localhost.localdomain> References: <4607E018.9010809@poolshark.org> <1174922145.3277.3.camel@pmac.infradead.org> <1174922765.8528.11.camel@localhost.localdomain> Message-ID: <1174923449.17842.95.camel@metroid.rdu.redhat.com> On Mon, 2007-03-26 at 16:26 +0100, Richard Hughes wrote: > On Mon, 2007-03-26 at 16:15 +0100, David Woodhouse wrote: > > > > It's got worse in rawhide -- it's now asking for that password after > > every suspend/resume cycle. > > No, that's by design. gnome-power-manager tells gnome-keyring to "lock" > on suspend for security. See gnome bug #375681. Ugh. Is that going to be configurable? I personally kind of hate that, and besides - the screen locks when you suspend anyway, so your network session should be plenty secure... (I'd check the bug myself but bugzilla.gnome.org is currently broken) -w -------------- 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 Mar 26 15:43:00 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Mar 2007 16:43:00 +0100 Subject: FC-6 NetworkManager needs some love In-Reply-To: <1174923449.17842.95.camel@metroid.rdu.redhat.com> References: <4607E018.9010809@poolshark.org> <1174922145.3277.3.camel@pmac.infradead.org> <1174922765.8528.11.camel@localhost.localdomain> <1174923449.17842.95.camel@metroid.rdu.redhat.com> Message-ID: <1174923780.8968.3.camel@localhost.localdomain> On Mon, 2007-03-26 at 11:37 -0400, Will Woods wrote: > > Ugh. Is that going to be configurable? I personally kind of hate that, > and besides - the screen locks when you suspend anyway, so your > network session should be plenty secure... Well, it could be - I hadn't thought about it that much. Should we expose this to the user in the UI or just have a gconf configuration bit? Also, are there any security implications from g-p-m /not/ locking the keyring? > (I'd check the bug myself but bugzilla.gnome.org is currently broken) Just tested myself, and I've reported it to the bugmaster. Thanks, Richard. From mmcgrath at redhat.com Mon Mar 26 15:45:49 2007 From: mmcgrath at redhat.com (Mike McGrath) Date: Mon, 26 Mar 2007 10:45:49 -0500 Subject: accounts2/fas/fas .LDAP.py.swp, NONE, 1.1 .test.py.swp, NONE, 1.1 LDAP.pyc, NONE, 1.1 __init__.py, NONE, 1.1 __init__.pyc, NONE, 1.1 controllers.py, NONE, 1.1 controllers.pyc, NONE, 1.1 controllers.py~, NONE, 1.1 fasLDAP.py, NONE, 1.1 fasLDAP.pyc, NONE, 1.1 fasLDAP.py~, NONE, 1.1 json.py, NONE, 1.1 model.py, NONE, 1.1 model.pyc, NONE, 1.1 release.py, NONE, 1.1 t.py, NONE, 1.1 test.py, NONE, 1.1 In-Reply-To: <20070326151312.GC2972@free.fr> References: <200703261511.l2QFBJIS027000@cvs-int.fedora.redhat.com> <20070326151312.GC2972@free.fr> Message-ID: <4607EAAD.9090608@redhat.com> Patrice Dumas wrote: > On Mon, Mar 26, 2007 at 11:11:19AM -0400, Michael Patrick McGrath wrote: > >> Author: mmcgrath >> >> Update of /cvs/fedora/accounts2/fas/fas >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv26831/fas/fas >> >> Added Files: >> .LDAP.py.swp .test.py.swp LDAP.pyc __init__.py __init__.pyc >> controllers.py controllers.pyc controllers.py~ fasLDAP.py >> fasLDAP.pyc fasLDAP.py~ json.py model.py model.pyc release.py >> t.py test.py >> > > Seems like some unwanted files crept in, like .LDAP.py.swp LDAP.pyc > controllers.py~... (not sure about .pyc files). > yep, I'm on it. -Mike From giallu at gmail.com Mon Mar 26 15:45:19 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 26 Mar 2007 17:45:19 +0200 Subject: FC-6 NetworkManager needs some love In-Reply-To: <1174923449.17842.95.camel@metroid.rdu.redhat.com> References: <4607E018.9010809@poolshark.org> <1174922145.3277.3.camel@pmac.infradead.org> <1174922765.8528.11.camel@localhost.localdomain> <1174923449.17842.95.camel@metroid.rdu.redhat.com> Message-ID: On 3/26/07, Will Woods wrote: > On Mon, 2007-03-26 at 16:26 +0100, Richard Hughes wrote: > > On Mon, 2007-03-26 at 16:15 +0100, David Woodhouse wrote: > > > > > > It's got worse in rawhide -- it's now asking for that password after > > > every suspend/resume cycle. > > > > No, that's by design. gnome-power-manager tells gnome-keyring to "lock" > > on suspend for security. See gnome bug #375681. > > Ugh. Is that going to be configurable? +1000... From adellam at sevenseas.org Mon Mar 26 15:48:47 2007 From: adellam at sevenseas.org (Andrea Dell'Amico) Date: Mon, 26 Mar 2007 17:48:47 +0200 Subject: FC-6 NetworkManager needs some love In-Reply-To: <1174923449.17842.95.camel@metroid.rdu.redhat.com> References: <4607E018.9010809@poolshark.org> <1174922145.3277.3.camel@pmac.infradead.org> <1174922765.8528.11.camel@localhost.localdomain> <1174923449.17842.95.camel@metroid.rdu.redhat.com> Message-ID: <1174924127.3924.27.camel@altrove.nowhere.net> On Mon, 2007-03-26 at 11:37 -0400, Will Woods wrote: > On Mon, 2007-03-26 at 16:26 +0100, Richard Hughes wrote: > > On Mon, 2007-03-26 at 16:15 +0100, David Woodhouse wrote: > > > > > > It's got worse in rawhide -- it's now asking for that password after > > > every suspend/resume cycle. > > > > No, that's by design. gnome-power-manager tells gnome-keyring to "lock" > > on suspend for security. See gnome bug #375681. > > Ugh. Is that going to be configurable? I personally kind of hate that, > and besides - the screen locks when you suspend anyway, so your network > session should be plenty secure... Why don't you use pam-keyring? > -w ciao andrea -- "Sotto il sole, sotto la luna, non c'e` certezza alcuna" From jon.nettleton at gmail.com Mon Mar 26 16:23:51 2007 From: jon.nettleton at gmail.com (Jon Nettleton) Date: Mon, 26 Mar 2007 12:23:51 -0400 Subject: FC-6 NetworkManager needs some love In-Reply-To: <1174924127.3924.27.camel@altrove.nowhere.net> References: <4607E018.9010809@poolshark.org> <1174922145.3277.3.camel@pmac.infradead.org> <1174922765.8528.11.camel@localhost.localdomain> <1174923449.17842.95.camel@metroid.rdu.redhat.com> <1174924127.3924.27.camel@altrove.nowhere.net> Message-ID: <1174926232.3008.7.camel@averatec> On Mon, 2007-03-26 at 17:48 +0200, Andrea Dell'Amico wrote: > On Mon, 2007-03-26 at 11:37 -0400, Will Woods wrote: > > On Mon, 2007-03-26 at 16:26 +0100, Richard Hughes wrote: > > > On Mon, 2007-03-26 at 16:15 +0100, David Woodhouse wrote: > > > > > > > > It's got worse in rawhide -- it's now asking for that password after > > > > every suspend/resume cycle. > > > > > > No, that's by design. gnome-power-manager tells gnome-keyring to "lock" > > > on suspend for security. See gnome bug #375681. > > > > Ugh. Is that going to be configurable? I personally kind of hate that, > > and besides - the screen locks when you suspend anyway, so your network > > session should be plenty secure... > > Why don't you use pam-keyring? There are some issues with using pam-keyring for NetworkManager and a Screensaver right now. NetworkManager comes up and tries to connect immediately on resume, and before a password has been input to unlock the screensaver and presumably the keyring. This means that nm-applet has already asked gnome-keyring-daemon for a password and because of this gkd has prompted to input a password. We are working on a better integration of pam-keyring and fedora that should hopefully tie this all into a nice little package. We aren't there yet, but it is on the radar. Jon From jdieter at gmail.com Mon Mar 26 16:26:01 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 26 Mar 2007 19:26:01 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <4607E78C.30109@fedoraproject.org> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> Message-ID: <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> On Mon, 2007-03-26 at 21:02 +0530, Rahul Sundaram wrote: > Sure. Different output with 0.2.6 and yum -d5. > File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 153, in run > func(conduitcls(self, self.base, conf, **kwargs)) > File "/usr/lib/yum-plugins/presto.py", line 85, in postresolve_hook > (chosen_drpm, installed, local) = > prestoTransaction.find_available_drpms(conduit, newpkg) > File "/usr/share/presto/prestoTransaction.py", line 48, in > find_available_drpms > if os.path.exists(newpkg.po.localpath): > AttributeError: YumInstalledPackage instance has no attribute 'localpath' > > > Rahul > Well, at least I've moved the problem forward a few lines of code, worthless as that is. Try 0.2.7 (again with -d 5, please), and let's see if I've finally got it fixed! Thanks, Jonathan -------------- 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 jonathan.underwood at gmail.com Mon Mar 26 16:35:05 2007 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Mon, 26 Mar 2007 17:35:05 +0100 Subject: Bugzilla is unbearable to the point of being unusable Message-ID: <645d17210703260935x3d07c031qfdc09ff8f08be1b2@mail.gmail.com> Hi, Querying bugzilla for Fedora bugs is frequently unbearably slow, and also inprecise. Is there _anything_ that could be done about this situation. I would imagine that this affects workflow quite badly, and leads to many more duplicate bugzilla reports. I wish I had the technical expertise to contribute something, rather than just complaining, but I don't. Best wishes, Jonathan. From buc at odusz.so-cdu.ru Mon Mar 26 16:47:44 2007 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 26 Mar 2007 20:47:44 +0400 Subject: exec bit mess In-Reply-To: <45FE9670.5000303@odu.neva.ru> References: <45FE9670.5000303@odu.neva.ru> Message-ID: <4607F930.2000003@odu.neva.ru> Dmitry Butskoy wrote: > Recently updated tcpdump package has executable bit set (rwxr-xr-x) in > all repositories, which can be visible throw ftp access. > > Something going wrong?... Not wrong? Then describe what does it mean. ;) Some of my users are curious about this... ~buc From gajownik at gmail.com Mon Mar 26 17:04:49 2007 From: gajownik at gmail.com (Dawid Gajownik) Date: Mon, 26 Mar 2007 19:04:49 +0200 Subject: Bugzilla is unbearable to the point of being unusable In-Reply-To: <645d17210703260935x3d07c031qfdc09ff8f08be1b2@mail.gmail.com> References: <645d17210703260935x3d07c031qfdc09ff8f08be1b2@mail.gmail.com> Message-ID: <4607FD31.7050700@gmail.com> Dnia 03/26/2007 06:35 PM, U?ytkownik Jonathan Underwood napisa?: > Hi, Hi :) > Querying bugzilla for Fedora bugs is frequently unbearably slow, and > also inprecise. Is there _anything_ that could be done about this > situation. I would imagine that this affects workflow quite badly, and > leads to many more duplicate bugzilla reports. I also had problems with searching through bugzilla but I have found this page http://fedoraproject.org/wiki/KieranClancy There is attached bookmark file which makes searching much easier (at least for me). HTH, Dawid -- ^_* From orion at cora.nwra.com Mon Mar 26 17:06:07 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 26 Mar 2007 11:06:07 -0600 Subject: /usr/share/java and JNI libraries Message-ID: <4607FD7F.9070007@cora.nwra.com> Two questions: - Who should own /usr/share/java? Currently there is: libidn-devel.i386 jpackage-utils.noarch java-1.5.0-gcj-javadoc.i386 libgcj-src.i386 libgcj.i386 java-1.4.2-gcj-compat-javadoc.i386 kdevelop.i386 db4-java.i386 axis-javadoc.i386 swig.i386 jlex.i386 antlr-javadoc.i386 xdoclet-javadoc.i386 and that's just from core. - Where should JNI libraries be installed? plplot wants to install into /usr/lib/jni, but that doesn't look like it's used by anyone else. Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From aph at redhat.com Mon Mar 26 17:11:57 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 26 Mar 2007 18:11:57 +0100 Subject: /usr/share/java and JNI libraries In-Reply-To: <4607FD7F.9070007@cora.nwra.com> References: <4607FD7F.9070007@cora.nwra.com> Message-ID: <17927.65245.178252.855406@zebedee.pink> Orion Poplawski writes: > Two questions: > > - Who should own /usr/share/java? Currently there is: > > libidn-devel.i386 > jpackage-utils.noarch > java-1.5.0-gcj-javadoc.i386 > libgcj-src.i386 > libgcj.i386 > java-1.4.2-gcj-compat-javadoc.i386 > kdevelop.i386 > db4-java.i386 > axis-javadoc.i386 > swig.i386 > jlex.i386 > antlr-javadoc.i386 > xdoclet-javadoc.i386 > > and that's just from core. What is your problem? Please explain. > - Where should JNI libraries be installed? /usr/lib*/packagename. Andrew. From Lam at Lam.pl Mon Mar 26 17:17:42 2007 From: Lam at Lam.pl (Leszek Matok) Date: Mon, 26 Mar 2007 19:17:42 +0200 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> Message-ID: <1174929462.6065.7.camel@pensja.lam.pl> This one is strange: ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: bittorrent * noarch 4.4.0-5.fc6 extras 59 k bittorrent-gui * noarch 4.4.0-5.fc6 extras 15 k lucidlife * i386 0.9.1-2.fc6 extras 90 k Transaction Summary ============================================================================= Install 0 Package(s) Update 3 Package(s) Remove 0 Package(s) Total download size: 164 k Is this ok [y/N]: y Downloading Packages: (1/3): bittorrent-gui-4.4 100% |=========================| 15 kB 00:00 (2/3): lucidlife-0.9.1_0. 100% |=========================| 90 kB 00:03 (3/3): bittorrent-4.4.0_4 100% |=========================| 59 kB 00:02 Rebuilding full packages from deltas Traceback (most recent call last): File "/usr/bin/yum", line 29, in ? yummain.main(sys.argv[1:]) File "/usr/share/yum-cli/yummain.py", line 172, in main base.doTransaction() File "/usr/share/yum-cli/cli.py", line 419, in doTransaction problems = self.downloadPkgs(downloadpkgs) File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 706, in downloadPkgs self.plugins.run('postdownload', pkglist=pkglist, errors=errors) File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 153, in run func(conduitcls(self, self.base, conf, **kwargs)) File "/usr/lib/yum-plugins/presto.py", line 174, in postdownload_hook raise PluginYumExit("Error rebuilding at least one deltarpm. Please run report this error to\nhttps://hosted.fedoraproject.org/projects/presto/newticket. To bypass this problem, run yum \nwith the --disablepresto option") NameError: global name 'PluginYumExit' is not defined Notice the part "lucidlife-0.9.1_0.". Next time (1 minute later, no repository metadata was updated) it was different: (1/1): lucidlife-0.9.1-2. 100% |=========================| 723 kB 00:24 And the update went okay. It looks to me like a deltarpm repository breakage combined with some strange logic in Presto that made it download a file with another name that it wanted. Oh, and there's no /var/log/presto.log. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From orion at cora.nwra.com Mon Mar 26 17:24:52 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 26 Mar 2007 11:24:52 -0600 Subject: /usr/share/java and JNI libraries In-Reply-To: <17927.65245.178252.855406@zebedee.pink> References: <4607FD7F.9070007@cora.nwra.com> <17927.65245.178252.855406@zebedee.pink> Message-ID: <460801E4.5000405@cora.nwra.com> Andrew Haley wrote: > Orion Poplawski writes: > > Two questions: > > > > - Who should own /usr/share/java? Currently there is: > > > > libidn-devel.i386 > > jpackage-utils.noarch > > java-1.5.0-gcj-javadoc.i386 > > libgcj-src.i386 > > libgcj.i386 > > java-1.4.2-gcj-compat-javadoc.i386 > > kdevelop.i386 > > db4-java.i386 > > axis-javadoc.i386 > > swig.i386 > > jlex.i386 > > antlr-javadoc.i386 > > xdoclet-javadoc.i386 > > > > and that's just from core. > > What is your problem? Please explain. I was under the impression that multiple ownership of directories was a bad thing. > > - Where should JNI libraries be installed? > > /usr/lib*/packagename. thanks. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From nicolas.mailhot at laposte.net Mon Mar 26 17:25:45 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 26 Mar 2007 19:25:45 +0200 Subject: /usr/share/java and JNI libraries In-Reply-To: <4607FD7F.9070007@cora.nwra.com> References: <4607FD7F.9070007@cora.nwra.com> Message-ID: <1174929945.5240.7.camel@rousalka.dyndns.org> Le lundi 26 mars 2007 ? 11:06 -0600, Orion Poplawski a ?crit : > Two questions: > > - Who should own /usr/share/java? jpackage-utils is the master package that owns java-related directories (and other java packaging policy-related files) Policy is open to discussion @fedora and @jpackage, but a central policy package makes managing things easier. > and that's just from core. > > - Where should JNI libraries be installed? plplot wants to install into > /usr/lib/jni, but that doesn't look like it's used by anyone else. %{_jnidir} is the correct place according do jpackage naming conventions (file:///usr/share/doc/jpackage-utils-*/jpackage-1.5-policy.xhtml) It's never seen much use, because packaging basic java classes is hard and jni code is harder. So it could probably be redefined if the current default is found lacking. However because jni classes depend on arch code, it should stay %{_libdir}-based IMHO. 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 orion at cora.nwra.com Mon Mar 26 17:27:09 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 26 Mar 2007 11:27:09 -0600 Subject: /usr/share/java and JNI libraries In-Reply-To: <17927.65245.178252.855406@zebedee.pink> References: <4607FD7F.9070007@cora.nwra.com> <17927.65245.178252.855406@zebedee.pink> Message-ID: <4608026D.8030004@cora.nwra.com> Andrew Haley wrote: > What is your problem? Please explain. I guess my real question is that plplot-java installs: /usr/share/javaj/plplot.jar and I'm wondering what plplot-java should Require:. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From aph at redhat.com Mon Mar 26 17:36:13 2007 From: aph at redhat.com (Andrew Haley) Date: Mon, 26 Mar 2007 18:36:13 +0100 Subject: /usr/share/java and JNI libraries In-Reply-To: <4608026D.8030004@cora.nwra.com> References: <4607FD7F.9070007@cora.nwra.com> <17927.65245.178252.855406@zebedee.pink> <4608026D.8030004@cora.nwra.com> Message-ID: <17928.1165.919798.484974@zebedee.pink> Orion Poplawski writes: > Andrew Haley wrote: > > What is your problem? Please explain. > > I guess my real question is that plplot-java installs: > > /usr/share/javaj/plplot.jar > > and I'm wondering what plplot-java should Require:. Well, I can't know what plplot-java really requires, but java >= 1.4 is probably a good start, depending on the version you really require. And any of the other packages it uses, of course. Andrew. From gilboad at gmail.com Mon Mar 26 17:35:43 2007 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 26 Mar 2007 19:35:43 +0200 Subject: Bugzilla is unbearable to the point of being unusable In-Reply-To: <645d17210703260935x3d07c031qfdc09ff8f08be1b2@mail.gmail.com> References: <645d17210703260935x3d07c031qfdc09ff8f08be1b2@mail.gmail.com> Message-ID: <1174930543.30305.16.camel@gilboa-work-dev.localdomain> On Mon, 2007-03-26 at 17:35 +0100, Jonathan Underwood wrote: > Hi, > > Querying bugzilla for Fedora bugs is frequently unbearably slow, and > also inprecise. Is there _anything_ that could be done about this > situation. I would imagine that this affects workflow quite badly, and > leads to many more duplicate bugzilla reports. > > I wish I had the technical expertise to contribute something, rather > than just complaining, but I don't. > > Best wishes, > Jonathan. > /+1. Someone should take the the poor bugzilla server behind the shed and put it out of its misery. Same goes for the fedoraproject.org one. - Gilboa From jdieter at gmail.com Mon Mar 26 17:43:08 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 26 Mar 2007 20:43:08 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174929462.6065.7.camel@pensja.lam.pl> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> Message-ID: <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> On Mon, 2007-03-26 at 19:17 +0200, Leszek Matok wrote: > This one is strange: > > ============================================================================= > Package Arch Version Repository Size > ============================================================================= > Updating: > bittorrent * noarch 4.4.0-5.fc6 extras 59 k > bittorrent-gui * noarch 4.4.0-5.fc6 extras 15 k > lucidlife * i386 0.9.1-2.fc6 extras 90 k > > Transaction Summary > ============================================================================= > Install 0 Package(s) > Update 3 Package(s) > Remove 0 Package(s) > > Total download size: 164 k > Is this ok [y/N]: y > Downloading Packages: > (1/3): bittorrent-gui-4.4 100% |=========================| 15 kB 00:00 > (2/3): lucidlife-0.9.1_0. 100% |=========================| 90 kB 00:03 > (3/3): bittorrent-4.4.0_4 100% |=========================| 59 kB 00:02 > Rebuilding full packages from deltas > Traceback (most recent call last): > File "/usr/bin/yum", line 29, in ? > yummain.main(sys.argv[1:]) > File "/usr/share/yum-cli/yummain.py", line 172, in main > base.doTransaction() > File "/usr/share/yum-cli/cli.py", line 419, in doTransaction > problems = self.downloadPkgs(downloadpkgs) > File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 706, in downloadPkgs > self.plugins.run('postdownload', pkglist=pkglist, errors=errors) > File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 153, in run > func(conduitcls(self, self.base, conf, **kwargs)) > File "/usr/lib/yum-plugins/presto.py", line 174, in postdownload_hook > raise PluginYumExit("Error rebuilding at least one deltarpm. Please run report this error to\nhttps://hosted.fedoraproject.org/projects/presto/newticket. To bypass this problem, run yum \nwith the --disablepresto option") > NameError: global name 'PluginYumExit' is not defined > > Notice the part "lucidlife-0.9.1_0.". Next time (1 minute later, no > repository metadata was updated) it was different: > (1/1): lucidlife-0.9.1-2. 100% |=========================| 723 kB 00:24 > And the update went okay. It looks to me like a deltarpm repository > breakage combined with some strange logic in Presto that made it > download a file with another name that it wanted. > > Oh, and there's no /var/log/presto.log. > > Lam Okay, first an explanation: Presto works by checking to see if there is a deltarpm update available for each package. When there is a deltarpm available, it then checks what's called the "deltarpm sequence" against your system to see if the deltarpm will apply cleanly. If the deltarpm will apply cleanly, it then changes certain package information, in this case to lucidlife-0.9.1_0.9.1-2.fc6_1.fc6.i386.drpm. Yum then proceeds to download the drpm (thinking it's the rpm). After yum downloads all the packages, presto kicks in again and reassembles the rpm from the drpm, and reverts the package information back to the original. And, finally, at the end, it writes out statistics to /var/log/presto.log. So, what has happened here is that the lucidlife drpm looked like it would apply cleanly the first time around, but, after being downloaded didn't apply cleanly. A bug in the code gave you that ugly error rather than the "nice" error message it was supposed to...I'll fix it in 0.2.8, which should be out in a half-hour or so. The second time your ran it, it realized there was a problem and downloaded the full rpm. I would really love to know if you've done anything with lucidlife, changed any files before upgrading to the latest version? It would help me work out why we hit this error in the first place. Jonathan -------------- 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 email.ahmedkamal at googlemail.com Mon Mar 26 17:54:20 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Mon, 26 Mar 2007 19:54:20 +0200 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> Message-ID: <3da3b5b40703261054h2ff7ebfeq29a317e3fadfd9e7@mail.gmail.com> Manually downloading the drpm, and using applydeltarpm manually might show some useful information as to 'why' reconstruction is failing On 3/26/07, Jonathan Dieter wrote: > > On Mon, 2007-03-26 at 19:17 +0200, Leszek Matok wrote: > > This one is strange: > > > > > ============================================================================= > > Package Arch > Version Repository Size > > > ============================================================================= > > Updating: > > bittorrent * noarch 4.4.0-5.fc6 extras > 59 k > > bittorrent-gui * noarch 4.4.0-5.fc6 extras > 15 k > > lucidlife * i386 0.9.1-2.fc6 extras > 90 k > > > > Transaction Summary > > > ============================================================================= > > Install 0 Package(s) > > Update 3 Package(s) > > Remove 0 Package(s) > > > > Total download size: 164 k > > Is this ok [y/N]: y > > Downloading Packages: > > (1/3): bittorrent-gui-4.4 100% |=========================| 15 > kB 00:00 > > (2/3): lucidlife-0.9.1_0. 100% |=========================| 90 > kB 00:03 > > (3/3): bittorrent-4.4.0_4 100% |=========================| 59 > kB 00:02 > > Rebuilding full packages from deltas > > Traceback (most recent call last): > > File "/usr/bin/yum", line 29, in ? > > yummain.main(sys.argv[1:]) > > File "/usr/share/yum-cli/yummain.py", line 172, in main > > base.doTransaction() > > File "/usr/share/yum-cli/cli.py", line 419, in doTransaction > > problems = self.downloadPkgs(downloadpkgs) > > File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 706, in > downloadPkgs > > self.plugins.run('postdownload', pkglist=pkglist, errors=errors) > > File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 153, in > run > > func(conduitcls(self, self.base, conf, **kwargs)) > > File "/usr/lib/yum-plugins/presto.py", line 174, in postdownload_hook > > raise PluginYumExit("Error rebuilding at least one deltarpm. Please > run report this error > to\nhttps://hosted.fedoraproject.org/projects/presto/newticket. To bypass > this problem, run yum \nwith the --disablepresto option") > > NameError: global name 'PluginYumExit' is not defined > > > > Notice the part "lucidlife-0.9.1_0.". Next time (1 minute later, no > > repository metadata was updated) it was different: > > (1/1): lucidlife-0.9.1-2. 100% |=========================| 723 > kB 00:24 > > And the update went okay. It looks to me like a deltarpm repository > > breakage combined with some strange logic in Presto that made it > > download a file with another name that it wanted. > > > > Oh, and there's no /var/log/presto.log. > > > > Lam > Okay, first an explanation: > Presto works by checking to see if there is a deltarpm update available > for each package. When there is a deltarpm available, it then checks > what's called the "deltarpm sequence" against your system to see if the > deltarpm will apply cleanly. If the deltarpm will apply cleanly, it > then changes certain package information, in this case to > lucidlife-0.9.1_0.9.1-2.fc6_1.fc6.i386.drpm. Yum then proceeds to > download the drpm (thinking it's the rpm). After yum downloads all the > packages, presto kicks in again and reassembles the rpm from the drpm, > and reverts the package information back to the original. And, finally, > at the end, it writes out statistics to /var/log/presto.log. > > So, what has happened here is that the lucidlife drpm looked like it > would apply cleanly the first time around, but, after being downloaded > didn't apply cleanly. A bug in the code gave you that ugly error rather > than the "nice" error message it was supposed to...I'll fix it in 0.2.8, > which should be out in a half-hour or so. The second time your ran it, > it realized there was a problem and downloaded the full rpm. > > I would really love to know if you've done anything with lucidlife, > changed any files before upgrading to the latest version? It would help > me work out why we hit this error in the first place. > > Jonathan > > -- > 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 Lam at Lam.pl Mon Mar 26 17:59:45 2007 From: Lam at Lam.pl (Leszek Matok) Date: Mon, 26 Mar 2007 19:59:45 +0200 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> Message-ID: <1174931985.6065.14.camel@pensja.lam.pl> Dnia 26-03-2007, pon o godzinie 20:43 +0300, Jonathan Dieter napisa?(a): > The second time your ran it, > it realized there was a problem and downloaded the full rpm. Can't it restart the process or simply download the full rpm at the same time it sees an unusable drpm, then proceed with the update as planned? > I would really love to know if you've done anything with lucidlife, > changed any files before upgrading to the latest version? It would help > me work out why we hit this error in the first place. No, I haven't even run it for half a year or so. Also, rpm -V doesn't report anything. Could it be that the drpm was being uploaded/generated that very moment I was trying to download it? Of course that would mean the metadata was uploaded/generated earlier than actual drpms, but who knows? Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From jdieter at gmail.com Mon Mar 26 18:05:20 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 26 Mar 2007 21:05:20 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174929462.6065.7.camel@pensja.lam.pl> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> Message-ID: <1174932321.19925.68.camel@jndwidescreen.lesbg.loc> On Mon, 2007-03-26 at 19:17 +0200, Leszek Matok wrote: > This one is strange: > Notice the part "lucidlife-0.9.1_0.". Next time (1 minute later, no > repository metadata was updated) it was different: > (1/1): lucidlife-0.9.1-2. 100% |=========================| 723 kB 00:24 > And the update went okay. It looks to me like a deltarpm repository > breakage combined with some strange logic in Presto that made it > download a file with another name that it wanted. > > Oh, and there's no /var/log/presto.log. > > Lam Okay, I've found the bug. If you modify a glf file in lucidlife (change a single number), checking the "deltarpm sequence" doesn't catch the change, but applying the deltarpm fails. Ahmed, it looks like you were right about us hitting this error. I'll pass it on to the deltarpm maintainer. Hopefully, we'll get a quick fix. BTW, I've just posted 0.2.8, which has the fix for the ugly yum crash. If you hit this error, you'll get a halfway decent message telling you exactly what to do. Jonathan -------------- 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 jdieter at gmail.com Mon Mar 26 18:07:36 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 26 Mar 2007 21:07:36 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174931985.6065.14.camel@pensja.lam.pl> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> Message-ID: <1174932456.19925.72.camel@jndwidescreen.lesbg.loc> On Mon, 2007-03-26 at 19:59 +0200, Leszek Matok wrote: > Dnia 26-03-2007, pon o godzinie 20:43 +0300, Jonathan Dieter napisa?(a): > > The second time your ran it, > > it realized there was a problem and downloaded the full rpm. > Can't it restart the process or simply download the full rpm at the same > time it sees an unusable drpm, then proceed with the update as planned? Ahmed has been telling me the same thing, but I thought this error would be never happen in the real world. Obviously I was wrong. I will get it to do as you say as part of 0.3.0 (hopefully next few days). Until then, we'll have to have it fail (though gracefully). Jonathan -------------- 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 ville.skytta at iki.fi Mon Mar 26 18:25:30 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Mon, 26 Mar 2007 21:25:30 +0300 Subject: /usr/share/java and JNI libraries In-Reply-To: <1174929945.5240.7.camel@rousalka.dyndns.org> References: <4607FD7F.9070007@cora.nwra.com> <1174929945.5240.7.camel@rousalka.dyndns.org> Message-ID: <200703262125.30724.ville.skytta@iki.fi> On Monday 26 March 2007, Nicolas Mailhot wrote: > %{_jnidir} is the correct place according do jpackage naming conventions > (file:///usr/share/doc/jpackage-utils-*/jpackage-1.5-policy.xhtml) > > It's never seen much use, because packaging basic java classes is hard > and jni code is harder. So it could probably be redefined if the current > default is found lacking. However because jni classes depend on arch > code, it should stay %{_libdir}-based IMHO. s/stay/change to/ %{_jnidir} is defined as %{_prefix}/lib/java; no %{_libdir} there, it's /usr/lib/java on lib64 archs too, ditto the versioned /usr/lib/java-* dirs. I suppose that's a relic/bug from JPackage (whose conventions don't take lib64 into account due to hysterical raisins AFAIK) and should eventually be fixed there as well. jpackage-utils should probably change from noarch to arch dependent if/when this gets fixed. From tonynelson at georgeanelson.com Mon Mar 26 18:30:04 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Mon, 26 Mar 2007 14:30:04 -0400 Subject: Presto logging In-Reply-To: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> Message-ID: At 11:26 AM +0300 3/26/07, Jonathan Dieter wrote: ... >Also, our test server is syncing updates and extras every six hours. >Does anyone know if there's a way for the fedoraproject servers to push >updates rather than our polling? I don't think so, but you could poll just the repomd.xml metadata file pretty quickly. If it is updated, then the repo is probably worth syncing with. You might also check if the filelists.gz is updated as well. -- ____________________________________________________________________ TonyN.:' ' From tonynelson at georgeanelson.com Mon Mar 26 18:29:09 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Mon, 26 Mar 2007 14:29:09 -0400 Subject: Presto logging In-Reply-To: References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> <1174913542.3254.6.camel@aglarond.local> <1174914103.19925.23.camel@jndwidescreen.lesbg.loc> Message-ID: At 3:21 PM +0200 3/26/07, Thomas M Steenholdt wrote: >Jonathan Dieter wrote: >> On Mon, 2007-03-26 at 08:52 -0400, Jeremy Katz wrote: >>> On Mon, 2007-03-26 at 11:26 +0300, Jonathan Dieter wrote: >>>> Also, our test server is syncing updates and extras every six hours. >>>> Does anyone know if there's a way for the fedoraproject servers to push >>>> updates rather than our polling? >>> There's not >>> >>> Jeremy >>> >> Bummer. I guess we get to work with what we've got then. Is six hours >> a good mirror timetable? >> >> Jonathan >> > >This brings up (again) the discussion of whether if would be worth >adding sync-flag semantics to the way we mirror (like what debian has >been doing for years). That would allow downstream mirrors to monitor >for a specific file every hour or so, and when that file exists with an >updated timestamp (or something) then we can be sure that the mirror has >finished it's own sync. The downstream mirror can then (more) reliably >perform it's own sync, sleep for some hours and start all over again. So >while we're still polling for updates, the risk of ending with an >inconsistent mirror is reduced. If the repomd.xml file were guaranteed to be updated last, then it would make a good sentinal. (Actually, all the metadata files should be updated at the same time. Aas they have static names there can't be two versions at a time.) >If this was implemented on all mirrors, we could effectively and very >simply decrease mirroring bandwidth, improve mirror reliability/quality, >reduce the number of update problems due to incomplete mirroring etc etc. > >By now it should not be a big surprise, that I think this could be a >good idea. I'll just keep pointing out situations where this could make >a positive difference. ;-) -- ____________________________________________________________________ TonyN.:' ' From nicolas.mailhot at laposte.net Mon Mar 26 18:46:33 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 26 Mar 2007 20:46:33 +0200 Subject: /usr/share/java and JNI libraries In-Reply-To: <200703262125.30724.ville.skytta@iki.fi> References: <4607FD7F.9070007@cora.nwra.com> <1174929945.5240.7.camel@rousalka.dyndns.org> <200703262125.30724.ville.skytta@iki.fi> Message-ID: <1174934793.6619.1.camel@rousalka.dyndns.org> Le lundi 26 mars 2007 ? 21:25 +0300, Ville Skytt? a ?crit : > On Monday 26 March 2007, Nicolas Mailhot wrote: > > > %{_jnidir} is the correct place according do jpackage naming conventions > > (file:///usr/share/doc/jpackage-utils-*/jpackage-1.5-policy.xhtml) > > > > It's never seen much use, because packaging basic java classes is hard > > and jni code is harder. So it could probably be redefined if the current > > default is found lacking. However because jni classes depend on arch > > code, it should stay %{_libdir}-based IMHO. > > s/stay/change to/ > > %{_jnidir} is defined as %{_prefix}/lib/java; no %{_libdir} there, > it's /usr/lib/java on lib64 archs too, ditto the versioned /usr/lib/java-* > dirs. I suppose that's a relic/bug from JPackage (whose conventions don't > take lib64 into account due to hysterical raisins AFAIK) It's a relic from the first people with x86_64 systems, that changed all the original %{_libdir}/foo macros to {_prefix}/lib/foo ones instead of fixing the script bits that broke on multilib systems (and they didn't even bother to change the doc, so it's still stating %{_libdir} as when I wrote it originally) > and should > eventually be fixed there as well. jpackage-utils should probably change > from noarch to arch dependent if/when this gets fixed. Probably -- 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 jdieter at gmail.com Mon Mar 26 18:51:44 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 26 Mar 2007 21:51:44 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174931985.6065.14.camel@pensja.lam.pl> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> Message-ID: <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> On Mon, 2007-03-26 at 19:59 +0200, Leszek Matok wrote: > Dnia 26-03-2007, pon o godzinie 20:43 +0300, Jonathan Dieter napisa?(a): > > The second time your ran it, > > it realized there was a problem and downloaded the full rpm. > Can't it restart the process or simply download the full rpm at the same > time it sees an unusable drpm, then proceed with the update as planned? > > > I would really love to know if you've done anything with lucidlife, > > changed any files before upgrading to the latest version? It would help > > me work out why we hit this error in the first place. > No, I haven't even run it for half a year or so. Also, rpm -V doesn't > report anything. > > Could it be that the drpm was being uploaded/generated that very moment > I was trying to download it? Of course that would mean the metadata was > uploaded/generated earlier than actual drpms, but who knows? > > Lam Okay, I've finally tracked down where it all went wrong. When Presto wasn't running applydeltarpm with on-disk MD5 checking. It was only checking file sizes. So if a file got one byte changed, it wouldn't catch that the patch wouldn't apply any more. I've fixed this so it does a full (slow) MD5 check when it finds an applicable DRPM in 0.2.9. Please, please let me know if anyone hits the "Error rebuilding at least one deltarpm." error. It shouldn't happen anymore, but I'd like to know if it does. Jonathan -------------- 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 mschwendt.tmp0701.nospam at arcor.de Mon Mar 26 18:53:42 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 26 Mar 2007 20:53:42 +0200 Subject: xfce - unowned directories? Message-ID: <20070326205342.ca2ccacc.mschwendt.tmp0701.nospam@arcor.de> Lost of unowned directories are reported for XFCE packages [1]. If I were familiar with the dependency graph, I would know where to start with suggesting fixes: => libxfce4mcs-devel - 4.4.0-2.fc7.i386 (fedora-extras-development-i386) /usr/include/xfce4 => xfce-mcs-manager - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) /usr/share/xfce4 /usr/share/xfce4/doc => xfce-mcs-plugins - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) /usr/share/xfce4 /usr/share/xfce4/doc /usr/lib/xfce4 /usr/lib/xfce4/mcs-plugins /usr/share/xfce-mcs-plugins /usr/share/xfce-mcs-plugins/shortcuts => xfce-utils - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) /usr/share/apps /usr/share/apps/switchdesk => xfce4-appfinder - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) /usr/share/xfce4 /usr/share/xfce4/doc => xfce4-battery-plugin - 0.5.0-1.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-clipman-plugin - 0.8.0-1.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-cpugraph-plugin - 0.3.0-4.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-dict-plugin - 0.2.1-1.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-diskperf-plugin - 2.1.0-2.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-eyes-plugin - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-fsguard-plugin - 0.3.0-4.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-genmon-plugin - 3.1-1.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-mailwatch-plugin - 1.0.1-5.fc7.i386 (fedora-extras-development-i386) /usr/share/xfce4/doc /usr/libexec/xfce4 => xfce4-mixer - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-mount-plugin - 0.5.1-1.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-netload-plugin - 0.4.0-4.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-notes-plugin - 1.4.1-1.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-panel - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) /usr/share/xfce4/doc /usr/libexec/xfce4 /etc/xdg/xfce4 /etc/xdg/xfce4/panel => xfce4-screenshooter-plugin - 1.0.0-4.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-sensors-plugin - 0.10.0-2.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-session - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) /etc/xdg/xfce4-session /etc/xdg/autostart /usr/share/xfce4 /usr/share/xfce4/doc /usr/share/xfce4/tips /usr/lib/xfce4 /usr/lib/xfce4/splash /usr/lib/xfce4/splash/engines /usr/lib/xfce4/mcs-plugins => xfce4-session-devel - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) /usr/include/xfce4 /usr/include/xfce4/xfce4-session-4.2 /usr/include/xfce4/xfce4-session-4.2/libxfsm => xfce4-session-engines - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) /usr/lib/xfce4 /usr/lib/xfce4/splash /usr/lib/xfce4/splash/engines /usr/share/themes /usr/share/themes/Default/balou => xfce4-systemload-plugin - 0.4.2-1.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-timer-plugin - 0.5.1-1.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-wavelan-plugin - 0.5.4-1.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-weather-plugin - 0.6.0-1.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-xfapplet-plugin - 0.1.0-2.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-xkb-plugin - 0.4.3-1.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfce4-xmms-plugin - 0.5.1-1.fc7.i386 (fedora-extras-development-i386) /usr/libexec/xfce4 => xfdesktop - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) /etc/xdg/xfce4 /usr/lib/xfce4/modules /usr/share/xfce4-menueditor /usr/libexec/xfce4 => xfprint - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) /usr/share/xfce4 /usr/share/xfce4/doc /usr/lib/xfce4 => xfprint-devel - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) /usr/include/xfce4 => xfwm4 - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) /usr/share/xfce4/doc /usr/lib/xfce4 /usr/lib/xfce4/mcs-plugins [1] It looks a bit as some of these packages are missing dependencies. From mschwendt.tmp0701.nospam at arcor.de Mon Mar 26 19:09:14 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Mon, 26 Mar 2007 21:09:14 +0200 Subject: /usr/share/icons/locolor Message-ID: <20070326210914.69ca907c.mschwendt.tmp0701.nospam@arcor.de> Several packages use the "locolor" icon tree. But unlike with the hicolor-icon-theme package, nothing comparable owns the locolor directories. Especially in non-KDE installations, this results in unowned directories. /usr/share/icons/locolor /usr/share/icons/locolor/16x16 /usr/share/icons/locolor/16x16/apps /usr/share/icons/locolor/16x16/mimetypes /usr/share/icons/locolor/32x32 /usr/share/icons/locolor/32x32/apps /usr/share/icons/locolor/32x32/mimetypes From hughsient at gmail.com Mon Mar 26 19:30:44 2007 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 26 Mar 2007 20:30:44 +0100 Subject: FC-6 NetworkManager needs some love In-Reply-To: <1174923449.17842.95.camel@metroid.rdu.redhat.com> References: <4607E018.9010809@poolshark.org> <1174922145.3277.3.camel@pmac.infradead.org> <1174922765.8528.11.camel@localhost.localdomain> <1174923449.17842.95.camel@metroid.rdu.redhat.com> Message-ID: <1174937444.3067.9.camel@localhost.localdomain> On Mon, 2007-03-26 at 11:37 -0400, Will Woods wrote: > > Ugh. Is that going to be configurable? I personally kind of hate that, > and besides - the screen locks when you suspend anyway, so your > network session should be plenty secure... See http://hughsient.livejournal.com/19481.html and add comments there please. I've added a gconf option on trunk (lock/gnome_keyring) and I've also added a configure parameter on the 2-18 branch. Can one of the g-p-m packagers please grab a snapshot of the latest 2-18 branch and stick it in rawhide please? Thanks. Richard From txtoth at gmail.com Mon Mar 26 19:58:43 2007 From: txtoth at gmail.com (Xavier Toth) Date: Mon, 26 Mar 2007 13:58:43 -0600 Subject: VESA driver hsync config problem In-Reply-To: <1174917730.31911.10.camel@localhost.localdomain> References: <1174917730.31911.10.camel@localhost.localdomain> Message-ID: Indeed I do have a log file and I'd greatly appreciate any assistance you can give me. On 3/26/07, Adam Jackson wrote: > On Sun, 2007-03-25 at 08:24 -0600, Xavier Toth wrote: > > For awhile now I've been struggling with what is probably a Vesa > > driver issue related to but different from Fedora Core bug# 10238. I'm > > running the latest X (7.2) under FC6 in a Parallels VM on a Mac and > > the server won't start unless I specify the HorizSync in the Monitor > > section of xorg.conf. I dug around and found references to > > vesa-1.3.0-range-hack.patch which I applied but this made no > > difference. > > My group is putting together a livecd for demo purposes and the > > xorg.conf generated by system-config-display (FC6) doesn't add a > > HorizSync so X won't start. Hopefully someone will have an idea how to > > fix this otherwise I might have to hack the config to add the > > HorizSync as an interim solution, any thoughts? > > Parallels needs to be taught to emulate DDC as well, it seems. > > But if you have an X log, and there's an identifying string in the VBE > info, then we might be able to hack something up. > > - ajax > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: xorg.tar.gz Type: application/x-gzip Size: 7479 bytes Desc: not available URL: From tmus at tmus.dk Mon Mar 26 19:11:34 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 26 Mar 2007 21:11:34 +0200 Subject: Presto logging In-Reply-To: References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> Message-ID: Tony Nelson wrote: > At 11:26 AM +0300 3/26/07, Jonathan Dieter wrote: > ... >> Also, our test server is syncing updates and extras every six hours. >> Does anyone know if there's a way for the fedoraproject servers to push >> updates rather than our polling? > > I don't think so, but you could poll just the repomd.xml metadata file > pretty quickly. If it is updated, then the repo is probably worth syncing > with. You might also check if the filelists.gz is updated as well. Problem with this is, that unless special care is taken to do it this way, we can't rely on the repository metadata to be updated last. I still vote for adopting the debian way - add a if test -f /path/to/mirror/trace/$(hostname); then rm -f path/to/mirror/trace/$(hostname) fi to the start of the sync script, and a date > /path/to/mirror/trace/$(hostname) to the end... (obviously, the code would have to change to reflect the public mirror name, if different from $(hostname) and such, so this is just an example of how easy something like this could be. When syncing against ftp.giantmirrorsite.com, we can check for the "ftp.giantmirrorsite.com" file in the trace directory. If it's there, we can relatively safely assume that the mirror is in sync. The contents of the file would indicate the time of last sync completion and the other contents of the trade/ dir reveals the path the updates has traveled downstream. Very nice. /Thomas From skvidal at linux.duke.edu Mon Mar 26 20:34:21 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 26 Mar 2007 16:34:21 -0400 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> Message-ID: <1174941261.30355.32.camel@cutter> On Mon, 2007-03-26 at 21:51 +0300, Jonathan Dieter wrote: > On Mon, 2007-03-26 at 19:59 +0200, Leszek Matok wrote: > > Dnia 26-03-2007, pon o godzinie 20:43 +0300, Jonathan Dieter napisa?(a): > > > The second time your ran it, > > > it realized there was a problem and downloaded the full rpm. > > Can't it restart the process or simply download the full rpm at the same > > time it sees an unusable drpm, then proceed with the update as planned? > > > > > I would really love to know if you've done anything with lucidlife, > > > changed any files before upgrading to the latest version? It would help > > > me work out why we hit this error in the first place. > > No, I haven't even run it for half a year or so. Also, rpm -V doesn't > > report anything. > > > > Could it be that the drpm was being uploaded/generated that very moment > > I was trying to download it? Of course that would mean the metadata was > > uploaded/generated earlier than actual drpms, but who knows? > > > > Lam > Okay, I've finally tracked down where it all went wrong. When Presto > wasn't running applydeltarpm with on-disk MD5 checking. It was only > checking file sizes. So if a file got one byte changed, it wouldn't > catch that the patch wouldn't apply any more. I've fixed this so it > does a full (slow) MD5 check when it finds an applicable DRPM in 0.2.9. > > Please, please let me know if anyone hits the "Error rebuilding at least > one deltarpm." error. It shouldn't happen anymore, but I'd like to know > if it does. > 1. why are you using md5sum and not sha1sums? 2. what function are you using to do this check? Yum has a checksum function you might be able to just use. -sv From tonynelson at georgeanelson.com Mon Mar 26 20:56:14 2007 From: tonynelson at georgeanelson.com (Tony Nelson) Date: Mon, 26 Mar 2007 16:56:14 -0400 Subject: Presto logging In-Reply-To: References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> Message-ID: At 9:11 PM +0200 3/26/07, Thomas M Steenholdt wrote: >Tony Nelson wrote: >> At 11:26 AM +0300 3/26/07, Jonathan Dieter wrote: >> ... >>> Also, our test server is syncing updates and extras every six hours. >>> Does anyone know if there's a way for the fedoraproject servers to push >>> updates rather than our polling? >> >> I don't think so, but you could poll just the repomd.xml metadata file >> pretty quickly. If it is updated, then the repo is probably worth syncing >> with. You might also check if the filelists.gz is updated as well. > >Problem with this is, that unless special care is taken to do it this >way, we can't rely on the repository metadata to be updated last. ... True, but that's already broken for everybody, so this would be no different. Once the metadata updates, either the other files are there or just about everything doesn't work. It would be a really good idea to fix this, by splitting up the rsync into two lines, so that the metadata is done last. Still, even without that, once the metadata changes one can assume that a repo update is happening. Repomd.xml is a nice small file that is always updated. -- ____________________________________________________________________ TonyN.:' ' From bjohnson-dated-1172832473.ba5e95 at symetrix.com Mon Mar 26 21:27:22 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Mon, 26 Mar 2007 15:27:22 -0600 Subject: hplip: hp-toolbox advertising? Message-ID: I was working on finding/reporting some bugs with the hplip package and noticed that there was no menu entry. Knowing that a graphical program with no menu entry wasn't the norm, I was about to file a bug, except when searching for a duplicate, I came across this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170762 mclasen at redhat.com: "We don't give free ad space to HP on our menus..." I find that to be both an interesting and hypocritical comment. Please someone tell me how: 1) HP provides free GPL software for controlling and printing with their printers. 100% opensource. Yet we remove the menu entry because that would be advertising. (And when I say 100% opensource, I mean there is code, not a binary firmware blob or such b.s.) 2) RealVNC is a company that has a product called VNC. They provide a opensource version of the product that is included in fedora. This program gets free "advertising space" on the menu including the VNC logo, which AFAICS is identical to the company logo except the word "REAL". 3) And the in F7, there will be CodecBuddy (http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy) which will direct users to the Fluendo Webshop (https://shop.fluendo.com/) to purchase proprietary codes when they try to play media that they do not have a code for (http://hadessuk.blogspot.com/2007/03/totem-news.html). Hey, I'm all for these type of convenience settings, but fair is fair, but the hplip: hp-toolbox menu item back on the system menu. From tmus at tmus.dk Mon Mar 26 21:33:21 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 26 Mar 2007 23:33:21 +0200 Subject: Presto logging In-Reply-To: References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> Message-ID: Tony Nelson wrote: > At 9:11 PM +0200 3/26/07, Thomas M Steenholdt wrote: >> Tony Nelson wrote: >>> At 11:26 AM +0300 3/26/07, Jonathan Dieter wrote: >>> ... >>>> Also, our test server is syncing updates and extras every six hours. >>>> Does anyone know if there's a way for the fedoraproject servers to push >>>> updates rather than our polling? >>> I don't think so, but you could poll just the repomd.xml metadata file >>> pretty quickly. If it is updated, then the repo is probably worth syncing >>> with. You might also check if the filelists.gz is updated as well. >> Problem with this is, that unless special care is taken to do it this >> way, we can't rely on the repository metadata to be updated last. > ... > > True, but that's already broken for everybody, so this would be no > different. Once the metadata updates, either the other files are there or > just about everything doesn't work. > > It would be a really good idea to fix this, by splitting up the rsync into > two lines, so that the metadata is done last. Still, even without that, > once the metadata changes one can assume that a repo update is happening. > Repomd.xml is a nice small file that is always updated. I still think implementing this in just another file will be a better solution. Its atomic (for lack of a better term here), in that the flag can always be counted on as being valid. If the flag file is not there, a sync is in progress, if it's there, the mirror is in synced state. The flag file is generated locally so there's no potential loop hole of even tenths of a second, like there would be the other way during the time when the repomd.xml is downloaded. It will not rely on data to actually change but reports whether a sync is in progress. It provides backtracking in case of staleness, errors, package corruption, etc. It lets you know the "age" of the mirrordata and it works without splitting the actual mirroring script. And all in a 30 byte file. /Thomas From Axel.Thimm at ATrpms.net Mon Mar 26 21:34:55 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 26 Mar 2007 23:34:55 +0200 Subject: Mail semantics: mail group, permissions, MTA/MDA suid/sgid and the like Message-ID: <20070326213455.GF16942@neu.nirvana> Hi, Red Hat/Fedora mail delivery is not using the sticky-bit method, but works with the mail group idiom. Does anyone have a good design document of the latter somewhere? I couldn't find anything detailed on the net and some parts I had to try find out experimentally (which, if I'm triggering a bug, may be wrong). So, I'm writing a few bits together and will make that a wiki page out of it, when some open questions are filled out. OK, the basic given is that /var/mail is 0775 root:mail which means that only root and group mail can write into it, which includes dotlocking. The system mbox are owned by the user and are group mail. Furthermore the blessed locking mechanisms are fcntl and dotlock. Questions: a) Does every MDA and MUA need to do both locking mechanisms or is dotlocking the fallback to fcntl? The latter would be an issue, so it should probably be both for every MDA/MUA. b) What are the proper permissions for the system mboxes 0600 or 0660? The latter implies that group mail can do nasty things. c) Under which group should an MDA run as? If the system mbox has not been created yet, it needs to be running as group mail. Also if dotlocking is required the MDA again needs to be running as group mail, or needs to have an external sgid dotlocking program (like procmail does). If the MDA allows external programs like .forward/procmail/maildrop the user can effectively become group mail whenever he wants. If the system mboxes are mode 0660 this is devastating. I think the answers are a) both b) 0600 c) :mail In that case any MTA/MDA using 0660 is broken which includes at least exim. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mclasen at redhat.com Mon Mar 26 21:39:35 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 26 Mar 2007 17:39:35 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: Message-ID: <1174945175.3739.9.camel@localhost.localdomain> On Mon, 2007-03-26 at 15:27 -0600, Bernard Johnson wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170762 > > > mclasen at redhat.com: > "We don't give free ad space to HP on our menus..." > > > I find that to be both an interesting and hypocritical comment. FWIW, the comment was referring to the HP icon in the menus. From jkeating at redhat.com Mon Mar 26 21:53:26 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 26 Mar 2007 17:53:26 -0400 Subject: Presto logging In-Reply-To: References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> Message-ID: <200703261753.26784.jkeating@redhat.com> On Monday 26 March 2007 17:33:21 Thomas M Steenholdt wrote: > I still think implementing this in just another file will be a better > solution. Its atomic (for lack of a better term here), in that the flag > can always be counted on as being valid. If the flag file is not there, > a sync is in progress, if it's there, the mirror is in synced state. The > flag file is generated locally so there's no potential loop hole of even > tenths of a second, like there would be the other way during the time > when the repomd.xml is downloaded. It will not rely on data to actually > change but reports whether a sync is in progress. It provides > backtracking in case of staleness, errors, package corruption, etc. It > lets you know the "age" of the mirrordata and it works without splitting > the actual mirroring script. And all in a 30 byte file. It's relying on mirrors to use OUR script to mirror content though, and we can't count on A) they'd use our script instead of whatever else they're using to sync other data, B) they're even using a host with bash/sh on it. -- 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 christoph.wickert at nurfuerspam.de Mon Mar 26 21:59:47 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Mon, 26 Mar 2007 23:59:47 +0200 Subject: xfce - unowned directories? In-Reply-To: <20070326205342.ca2ccacc.mschwendt.tmp0701.nospam@arcor.de> References: <20070326205342.ca2ccacc.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <1174946387.4024.21.camel@hal9000.oberschlesier.lan> Am Montag, den 26.03.2007, 20:53 +0200 schrieb Michael Schwendt: > Lost of unowned directories are reported for XFCE packages [1]. If I were > familiar with the dependency graph, I would know where to start with > suggesting fixes: I think Kevin can give us more insight, this is only what I see on a quick glance. > => xfce-mcs-plugins - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) > /usr/share/xfce4 > /usr/share/xfce4/doc > /usr/lib/xfce4 > /usr/lib/xfce4/mcs-plugins > /usr/share/xfce-mcs-plugins > /usr/share/xfce-mcs-plugins/shortcuts The last three should be owned by xfce-mcs-manager I think > => xfce4-battery-plugin - 0.5.0-1.fc7.i386 (fedora-extras-development-i386) > /usr/libexec/xfce4 [snipped, same for the all the other panel plugins I'm maintaining] I think xfce4-panel should own %{_libexecdir}/xfce4, because atm this location is only used for panel plugins. > => xfce4-mixer - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) > /usr/libexec/xfce4 xfce4-mixer should depend on xfce4-panel owning %{_libexecdir}/xfce4 since it provides a panel plugin > => xfce4-session - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) > /etc/xdg/xfce4-session > /etc/xdg/autostart > /usr/share/xfce4 > /usr/share/xfce4/doc > /usr/share/xfce4/tips > /usr/lib/xfce4 > /usr/lib/xfce4/splash > /usr/lib/xfce4/splash/engines xfce4-session should own splash and %{_libdir}/xfce4/splash and %{_libdir}/xfce4/splash/engines > /usr/lib/xfce4/mcs-plugins looks like xfce4-session needs to require xfce-mcs-manager (or whatever package we decide to own this dir) > => xfce4-session-devel - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) > /usr/include/xfce4 > /usr/include/xfce4/xfce4-session-4.2 > /usr/include/xfce4/xfce4-session-4.2/libxfsm should own the last two > => xfce4-session-engines - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) > /usr/lib/xfce4 > /usr/lib/xfce4/splash > /usr/lib/xfce4/splash/engines these two would be fixed if xfce-session owned splash and splash/engines. > /usr/share/themes > /usr/share/themes/Default/balou Christoph From david at fubar.dk Mon Mar 26 22:00:04 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 26 Mar 2007 18:00:04 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: Message-ID: <1174946404.2622.98.camel@zelda.fubar.dk> On Mon, 2007-03-26 at 15:27 -0600, Bernard Johnson wrote: > 1) HP provides free GPL software for controlling and printing with their > printers. 100% opensource. Yet we remove the menu entry because that > would be advertising. (And when I say 100% opensource, I mean there is > code, not a binary firmware blob or such b.s.) Now, if only HP would play nicely with the open source community and _just_ provide only drivers instead of reinventing the wheel by - provide a system-wide daemon for handing device access; oh, how nice, this completely bypasses OS security measures; for example, as a user logged in via SSH I can access the scanner. I should actually file that as a security bug. Bad. - Oh, and it's hard to actually change this; it's not like HPLip provides an easy to read list of what devices should get changed to provide access to the console user. To e.g. generate udev rules or HAL fdi files. Bad. - Not only that; starting this daemon is completely useless unless you have HP hardware. We still start it for everyone so everyone have to suffer. That's bad. - Provide their own UI for using the device; just provide the drivers, thank you very much; we don't really need foreign tools to make this harder on the users. Bad. - Try reading the HPLip sources; they provide access to the card reader by using a user-space vfat driver! Oh yeah! - All the HP stuff, since there is a lot of it, pulls in Qt which is not desirable for e.g. live CD. For example, Jeremy just pulled hplip from the test3 live cd because it wouldn't fit [1]. Also python is pulled in although this is less controversial. Good stuff that OLPC is based on Python otherwise they would have a hard time using the HP drivers. Instead, for example, HP should get their scanner drivers into the SANE project. My personal opinion is that with HPLip, HP is paying lip service to the Linux community by treating us as if we were Windows where this sort of "let's throw lots of vendor-specific tools and UI crap at the user" is common. HP: please try to be a good open source citizen. Give us drivers and drivers only. We're not really interested in end-user programs that uses libusb/vfat user space drivers for example. If you really want to contribute to the UI, please start supporting the efforts going on in the GNOME and KDE communities - for example GnomeScan could use more help. Many thanks. Btw, I'd love to be proven wrong and that one can actually build HPLip so only drivers and no silly privilege-escalation system-wide daemon is used. Hey, it's GPL, perhaps someone can just fork it until HP starts getting it. David [1] : http://git.fedoraproject.org/?p=hosted/livecd;a=commitdiff;h=ac05753140cfc281852fde226ef985b6efb43e64 From ajackson at redhat.com Mon Mar 26 21:40:36 2007 From: ajackson at redhat.com (Adam Jackson) Date: Mon, 26 Mar 2007 17:40:36 -0400 Subject: VESA driver hsync config problem In-Reply-To: References: <1174917730.31911.10.camel@localhost.localdomain> Message-ID: <1174945236.1534.2.camel@localhost.localdomain> On Mon, 2007-03-26 at 13:58 -0600, Xavier Toth wrote: > Indeed I do have a log file and I'd greatly appreciate any assistance > you can give me. That log appears to be from a successful startup. Odd. We can definitely tell if we're running under Parallels though: (II) VESA(0): VESA VBE OEM Vendor: Parallels Software International, Inc. The trick is just knowing what we're supposed to do when we detect Parallels. I don't have it, so I don't know. What _should_ we do? - ajax From david at fubar.dk Mon Mar 26 22:03:50 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 26 Mar 2007 18:03:50 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174946404.2622.98.camel@zelda.fubar.dk> References: <1174946404.2622.98.camel@zelda.fubar.dk> Message-ID: <1174946630.2622.101.camel@zelda.fubar.dk> (It's most probably this is needless to say, but these are my own points of view and does not necessarily reflect those of my employer which is Red Hat, Inc.). On Mon, 2007-03-26 at 18:00 -0400, David Zeuthen wrote: > On Mon, 2007-03-26 at 15:27 -0600, Bernard Johnson wrote: > > 1) HP provides free GPL software for controlling and printing with their > > printers. 100% opensource. Yet we remove the menu entry because that > > would be advertising. (And when I say 100% opensource, I mean there is > > code, not a binary firmware blob or such b.s.) > > Now, if only HP would play nicely with the open source community and > _just_ provide only drivers instead of reinventing the wheel by > > - provide a system-wide daemon for handing device access; oh, how nice, > this completely bypasses OS security measures; for example, as a user > logged in via SSH I can access the scanner. I should actually file > that as a security bug. Bad. > > - Oh, and it's hard to actually change this; it's not like HPLip > provides an easy to read list of what devices should get changed > to provide access to the console user. To e.g. generate udev rules > or HAL fdi files. Bad. > > - Not only that; starting this daemon is completely useless unless you > have HP hardware. We still start it for everyone so everyone have > to suffer. That's bad. > > - Provide their own UI for using the device; just provide the drivers, > thank you very much; we don't really need foreign tools to make this > harder on the users. Bad. > > - Try reading the HPLip sources; they provide access to the card reader > by using a user-space vfat driver! Oh yeah! > > - All the HP stuff, since there is a lot of it, pulls in Qt which is > not desirable for e.g. live CD. For example, Jeremy just pulled hplip > from the test3 live cd because it wouldn't fit [1]. Also python > is pulled in although this is less controversial. Good stuff that > OLPC is based on Python otherwise they would have a hard time > using the HP drivers. > > Instead, for example, HP should get their scanner drivers into the SANE > project. My personal opinion is that with HPLip, HP is paying lip > service to the Linux community by treating us as if we were Windows > where this sort of "let's throw lots of vendor-specific tools and UI > crap at the user" is common. > > HP: please try to be a good open source citizen. Give us drivers and > drivers only. We're not really interested in end-user programs that uses > libusb/vfat user space drivers for example. If you really want to > contribute to the UI, please start supporting the efforts going on in > the GNOME and KDE communities - for example GnomeScan could use more > help. Many thanks. > > Btw, I'd love to be proven wrong and that one can actually build HPLip > so only drivers and no silly privilege-escalation system-wide daemon is > used. Hey, it's GPL, perhaps someone can just fork it until HP starts > getting it. > > David > > [1] : > http://git.fedoraproject.org/?p=hosted/livecd;a=commitdiff;h=ac05753140cfc281852fde226ef985b6efb43e64 > > From bjohnson-dated-1172832473.ba5e95 at symetrix.com Mon Mar 26 22:13:01 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Mon, 26 Mar 2007 16:13:01 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174945175.3739.9.camel@localhost.localdomain> References: <1174945175.3739.9.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: > On Mon, 2007-03-26 at 15:27 -0600, Bernard Johnson wrote: >> mclasen at redhat.com: >> "We don't give free ad space to HP on our menus..." >> >> >> I find that to be both an interesting and hypocritical comment. > > FWIW, the comment was referring to the HP icon in the menus. > That was my assumption, but I could have read it any number of other ways as well. Do you still feel the same way given the other examples that I posted? From pemboa at gmail.com Mon Mar 26 22:22:32 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 26 Mar 2007 17:22:32 -0500 Subject: Presto logging In-Reply-To: <200703261753.26784.jkeating@redhat.com> References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> <200703261753.26784.jkeating@redhat.com> Message-ID: <16de708d0703261522r32c073e0r81307477b2296ea5@mail.gmail.com> On 3/26/07, Jesse Keating wrote: > On Monday 26 March 2007 17:33:21 Thomas M Steenholdt wrote: > > I still think implementing this in just another file will be a better > > solution. Its atomic (for lack of a better term here), in that the flag > > can always be counted on as being valid. If the flag file is not there, > > a sync is in progress, if it's there, the mirror is in synced state. The > > flag file is generated locally so there's no potential loop hole of even > > tenths of a second, like there would be the other way during the time > > when the repomd.xml is downloaded. It will not rely on data to actually > > change but reports whether a sync is in progress. It provides > > backtracking in case of staleness, errors, package corruption, etc. It > > lets you know the "age" of the mirrordata and it works without splitting > > the actual mirroring script. And all in a 30 byte file. > > It's relying on mirrors to use OUR script to mirror content though, and we > can't count on A) they'd use our script instead of whatever else they're > using to sync other data, B) they're even using a host with bash/sh on it. > > -- > Jesse Keating > Release Engineer: Fedora > I've been following this thread, and I would just like to ask about combining both methods, and giving a yes/no warning if both factors aren't in place? -- Fedora Core 6 and proud From mclasen at redhat.com Mon Mar 26 22:36:02 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 26 Mar 2007 18:36:02 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174945175.3739.9.camel@localhost.localdomain> Message-ID: <1174948562.3739.27.camel@localhost.localdomain> On Mon, 2007-03-26 at 16:13 -0600, Bernard Johnson wrote: > Matthias Clasen wrote: > > On Mon, 2007-03-26 at 15:27 -0600, Bernard Johnson wrote: > >> mclasen at redhat.com: > >> "We don't give free ad space to HP on our menus..." > >> > >> > >> I find that to be both an interesting and hypocritical comment. > > > > FWIW, the comment was referring to the HP icon in the menus. > > > > That was my assumption, but I could have read it any number of other > ways as well. > > Do you still feel the same way given the other examples that I posted? > David outlined a number of reasons why the hplip stack is really less than ideal from a desktop integration perspective. So yes, I still think that hplip and assorted gui tools are not the solution we want and do not really move us closer to the goal of making printing suck less. Matthias PS And no, I did not do an exhaustive search through all the menus before making the comment about the icon. If the VNC icon is just a company icon in disguise, the same comment applies there too. From twaugh at redhat.com Mon Mar 26 22:38:23 2007 From: twaugh at redhat.com (Tim Waugh) Date: Mon, 26 Mar 2007 23:38:23 +0100 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174948562.3739.27.camel@localhost.localdomain> References: <1174945175.3739.9.camel@localhost.localdomain> <1174948562.3739.27.camel@localhost.localdomain> Message-ID: <1174948703.23700.5.camel@cyberelk.elk> On Mon, 2007-03-26 at 18:36 -0400, Matthias Clasen wrote: > PS And no, I did not do an exhaustive search through all the menus > before making the comment about the icon. If the VNC icon is just a > company icon in disguise, the same comment applies there too. If it's about the icon, I can put a different icon in there if you like. Tim. */ -------------- 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 mclasen at redhat.com Mon Mar 26 22:49:05 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 26 Mar 2007 18:49:05 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174948703.23700.5.camel@cyberelk.elk> References: <1174945175.3739.9.camel@localhost.localdomain> <1174948562.3739.27.camel@localhost.localdomain> <1174948703.23700.5.camel@cyberelk.elk> Message-ID: <1174949345.3739.34.camel@localhost.localdomain> On Mon, 2007-03-26 at 23:38 +0100, Tim Waugh wrote: > On Mon, 2007-03-26 at 18:36 -0400, Matthias Clasen wrote: > > PS And no, I did not do an exhaustive search through all the menus > > before making the comment about the icon. If the VNC icon is just a > > company icon in disguise, the same comment applies there too. > > If it's about the icon, I can put a different icon in there if you like. > No, it is not just about the icon. David gave a somewhat ranty summary of the issues further up in this thread... From mschwendt.tmp0701.nospam at arcor.de Mon Mar 26 23:31:22 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 27 Mar 2007 01:31:22 +0200 Subject: rpms/ettercap/FC-6 ettercap-NG-0.7.3-UI.patch, 1.1, 1.2 ettercap.spec, 1.2, 1.3 In-Reply-To: <200703261817.l2QIHTVC014080@cvs-int.fedora.redhat.com> References: <200703261817.l2QIHTVC014080@cvs-int.fedora.redhat.com> Message-ID: <20070327013122.2dfd35bb.mschwendt.tmp0701.nospam@arcor.de> On Mon, 26 Mar 2007 14:17:29 -0400, Jon Ciesla (limb) wrote: > Author: limb > > Update of /cvs/extras/rpms/ettercap/FC-6 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv14050 > +Obsoletes: ettercap-plugins <= 0.7.3-14 Beware of the %dist tag! Last release was 0.7.3-14%{?dist} with %dist defined, so this "Obsoletes" is not high enough. > +Provides: ettercap-plugins <= %{version} This looks wrong. The broken deps report is not clear, but the following should fix it: Provides: ettercap-plugins = %{version}-%{release} -- Michael Schwendt Fedora release 6.92 (Rawhide) - Linux 2.6.20-1.3017.fc7 loadavg: 1.06 1.19 1.24 From opensource at till.name Mon Mar 26 23:48:43 2007 From: opensource at till.name (Till Maas) Date: Tue, 27 Mar 2007 01:48:43 +0200 Subject: signatures for non-rpm files in $arch/os trees? In-Reply-To: <20070325174541.GF27119@psilocybe.teonanacatl.org> References: <20070325174541.GF27119@psilocybe.teonanacatl.org> Message-ID: <200703270148.51083.opensource@till.name> On So M?rz 25 2007, Todd Zullinger wrote: [verify boot.iso and diskboot.img] The only way I know of, is to download the DVD or maybe the first CD, verify it (there are gpg signed sha1sums available) and then extrac boot.iso and diskboot.img from it. 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 bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 01:56:10 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Mon, 26 Mar 2007 19:56:10 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174949345.3739.34.camel@localhost.localdomain> References: <1174945175.3739.9.camel@localhost.localdomain> <1174948562.3739.27.camel@localhost.localdomain> <1174948703.23700.5.camel@cyberelk.elk> <1174949345.3739.34.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: > On Mon, 2007-03-26 at 23:38 +0100, Tim Waugh wrote: >> On Mon, 2007-03-26 at 18:36 -0400, Matthias Clasen wrote: >>> PS And no, I did not do an exhaustive search through all the menus >>> before making the comment about the icon. If the VNC icon is just a >>> company icon in disguise, the same comment applies there too. >> If it's about the icon, I can put a different icon in there if you like. >> > > No, it is not just about the icon. David gave a somewhat ranty summary > of the issues further up in this thread... > I read this as "so the software suck, let's not add an icon so the users of that software can get to it easily". Which, btw, is fine with me, as I have the 2.5 braincells needed to find it. However, with an attitude like this, the "Fedora on the desktop" idea is a fallacy as long as standard Scenario #1 User: "When I click on a .mp3 file, I get an error, why doesn't this work" Reason: It's not legal to distribute mp3 codecs. Acceptable?: What other choice do we have? (yes CodeBuddy is being worked on but it's not a reality yet) Scenario #2 User: "I could fax/get status/copy with my HP xxx printer in Windows but in Linux it only prints" Reason: We have a vendetta against HP and refuse to put the icon on the menu because in our eyes the software sucks (although it does work). [therefore user has to learn commands like rpm -ql package to find out what is available] Acceptable?: ? I don't think so, but it certainly looks like I'm in the minority. Seriously, you want me to list everything about Fedora that sucks yet gets a place on the menu? No, probably not. Level the playing field, everyone will benefit. From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 01:56:03 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Mon, 26 Mar 2007 19:56:03 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174946404.2622.98.camel@zelda.fubar.dk> References: <1174946404.2622.98.camel@zelda.fubar.dk> Message-ID: David Zeuthen wrote: > Now, if only HP would play nicely with the open source community and > _just_ provide only drivers instead of reinventing the wheel by Well, I'm sure you're just emphatic about "better software" but I think it comes across as looking a gift horse in the mouth. I mean, what do you want, junk the hp software and then I can have the same printing capabilities as when I had this: http://openprinting.org/show_printer.cgi?recnum=HP-LaserJet_3100 Where are your bug reports to them? Your feature requests? Have you even interacted with the hplip guys before? > - Not only that; starting this daemon is completely useless unless you > have HP hardware. We still start it for everyone so everyone have > to suffer. That's bad. and so is: smartd when I don't have a smartd drive bluethooth when I don't have bluetooth etc We have: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222312 Unfortunately, AFAICS, this bug will only solve that for connected devices. What about devices like mine that are on the network? How do you know when to start/stop services then? Are you suggesting that HP upgrade all their printer firmwares with Rendezvous support? It's what we have now [2]. > - Provide their own UI for using the device; just provide the drivers, > thank you very much; we don't really need foreign tools to make this > harder on the users. Bad. Oh? You have tools that work with their printers? No. Their job is to take care of their customers, which they are doing (even with Linux!) by providing software that works. Every issues that I've reported to the hplip guys has been dealt with in a timely manner (sans firmware issues reported to another group). That's a helluva lot more than I can say about reporting bugs to RedHat/Fedora [1]. We are lucky that they are much more business savvy regarding opensource than the idiots running the lightscribe group. If you think hplip is hard to swallow, download their lightscribe software and try not to regurgitate. And as far as complaining, bitching, moaning about HP not being "good opensource citizens"... How far as that gotten you with things like Broadcom wireless firmware? Oh, you're still loading binary blobs. Gotcha. It's nice to sit in your tower and throw rocks, but end then end, some of us work with these products and are held accountable for things working or not, no matter what political or idealogical happenings go on at Fedora/Red Hat. What next, tell me to use Ubuntu? [1] I am generally very happy with Fedora progress, I just have to keep reminding myself "everything takes time" :) [2] Reminds me of when I showed a friend of mine a copy of Linux (fit on two floppies, no login support etc) and was telling him how cool it was. His response was "it looks like it sucks pretty bad to me". :( From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 02:00:35 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Mon, 26 Mar 2007 20:00:35 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174949345.3739.34.camel@localhost.localdomain> References: <1174945175.3739.9.camel@localhost.localdomain> <1174948562.3739.27.camel@localhost.localdomain> <1174948703.23700.5.camel@cyberelk.elk> <1174949345.3739.34.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: > On Mon, 2007-03-26 at 23:38 +0100, Tim Waugh wrote: >> On Mon, 2007-03-26 at 18:36 -0400, Matthias Clasen wrote: >>> PS And no, I did not do an exhaustive search through all the menus >>> before making the comment about the icon. If the VNC icon is just a >>> company icon in disguise, the same comment applies there too. >> If it's about the icon, I can put a different icon in there if you like. >> > > No, it is not just about the icon. David gave a somewhat ranty summary > of the issues further up in this thread... If you can not be persuaded to allow the hp toolbox icon, please change the buzilla report to at least represent the actual cause of removing the desktop icon. From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 02:03:46 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Mon, 26 Mar 2007 20:03:46 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174948562.3739.27.camel@localhost.localdomain> References: <1174945175.3739.9.camel@localhost.localdomain> <1174948562.3739.27.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: > PS And no, I did not do an exhaustive search through all the menus > before making the comment about the icon. If the VNC icon is just a > company icon in disguise, the same comment applies there too. > So would you also say that you are against gstreamer based software directing users towards the Fluendo webshop? That's not just advertising, it's sole-sourcing. (For the record, I'm not against this at all, as long as all vendors have the same access) From limb at jcomserv.net Tue Mar 27 02:21:19 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 26 Mar 2007 21:21:19 -0500 (CDT) Subject: rpms/ettercap/FC-6 ettercap-NG-0.7.3-UI.patch, 1.1, 1.2 ettercap.spec, 1.2, 1.3 In-Reply-To: <20070327013122.2dfd35bb.mschwendt.tmp0701.nospam@arcor.de> References: <200703261817.l2QIHTVC014080@cvs-int.fedora.redhat.com> <20070327013122.2dfd35bb.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <2867.192.168.0.4.1174962079.squirrel@zanoni> Thanks, corrected. I had trouble finding guidance on this in the wiki. Did I miss something? > On Mon, 26 Mar 2007 14:17:29 -0400, Jon Ciesla (limb) wrote: > >> Author: limb >> >> Update of /cvs/extras/rpms/ettercap/FC-6 >> In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv14050 > >> +Obsoletes: ettercap-plugins <= 0.7.3-14 > > Beware of the %dist tag! Last release was 0.7.3-14%{?dist} with > %dist defined, so this "Obsoletes" is not high enough. > >> +Provides: ettercap-plugins <= %{version} > > This looks wrong. The broken deps report is not clear, but the > following should fix it: > > Provides: ettercap-plugins = %{version}-%{release} > > -- > Michael Schwendt > Fedora release 6.92 (Rawhide) - Linux 2.6.20-1.3017.fc7 > loadavg: 1.06 1.19 1.24 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From david at fubar.dk Tue Mar 27 02:33:54 2007 From: david at fubar.dk (David Zeuthen) Date: Mon, 26 Mar 2007 22:33:54 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174946404.2622.98.camel@zelda.fubar.dk> Message-ID: <1174962834.2622.156.camel@zelda.fubar.dk> On Mon, 2007-03-26 at 19:56 -0600, Bernard Johnson wrote: > David Zeuthen wrote: > > Now, if only HP would play nicely with the open source community and > > _just_ provide only drivers instead of reinventing the wheel by > > Well, I'm sure you're just emphatic about "better software" but I think > it comes across as looking a gift horse in the mouth. I mean, what do > you want, junk the hp software and then I can have the same printing > capabilities as when I had this: > http://openprinting.org/show_printer.cgi?recnum=HP-LaserJet_3100 > > Where are your bug reports to them? Your feature requests? Have you > even interacted with the hplip guys before? No, I'm not the hplip package owner in any distribution and I just came across this when looking at doing the ACL support things in HAL for SANE. I'll probably try to talk to them, I was just shocked we actually ship these bits. > > - Not only that; starting this daemon is completely useless unless you > > have HP hardware. We still start it for everyone so everyone have > > to suffer. That's bad. > > and so is: > smartd when I don't have a smartd drive > bluethooth when I don't have bluetooth > etc Two wrongs don't make a right (and, FWIW, I'm actually interacting with the Bluez guys to make HAL start/stop the bluetooth daemons). > It's nice to sit in your tower and throw rocks, but end then end, some > of us work with these products and are held accountable for things > working or not, no matter what political or idealogical happenings go on > at Fedora/Red Hat. I think I said already these are my personal points of view and that I wasn't speaking for Red Hat and obviously not Fedora. So I'm a bit unhappy to see you attribute these points of view to Fedora/Red Hat. Please don't do that. Thanks. For the record, I know plenty of Fedora people (both inside and outside of Red Hat) who, like you, are satisfied (and even excited) about the status quo. Go figure. David From michel.salim at gmail.com Tue Mar 27 02:48:13 2007 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 26 Mar 2007 22:48:13 -0400 Subject: The need to re-detect usb-storage devices (on resume and on-the-fly plugging) In-Reply-To: <1174681698.2756.40.camel@zelda.fubar.dk> References: <883cfe6d0703231035s29b4ae7cxc5bbdbfdb993c6d2@mail.gmail.com> <1174674122.2756.6.camel@zelda.fubar.dk> <1174681698.2756.40.camel@zelda.fubar.dk> Message-ID: <883cfe6d0703261948o281bedccqc28f27143d08d2aa@mail.gmail.com> 2007/3/23, David Zeuthen : > On Fri, 2007-03-23 at 14:22 -0400, David Zeuthen wrote: > > > Right > > > now, the laptop would resume with the device node still there (e.g. > > > sdb, sdb1), and the device still "mounted" but not accessible, and a > > > new device node is created (sdc, sdc1). > > > > That sounds like another bug; it works for me fwiw. > > Actually, I must admit, this doesn't work for me - I just tried. Upon > resume (from from disk and from RAM), the kernel emits uevents to remove > the devices, then adds them again. I don't see other device nodes being > used though - my guess is that you have open files on the drive when you > tested this? Hmm.. I can only guess that you didn't mount the partitions > through HAL (using gnome-mount or GNOME) because if you did, we would > have lazy unmounted the file system when we saw the device node going > away... > Yup; I see extra nodes being created only I manually mounted the removable partition in the first place (e.g. when I forgot to plug the device at boot) > Anyway, I submit that this is a bug with the kernel... although I'm sure > some people would argue this is how it works (since bus enum and sending > out deltas is *hard*) and that it's not a bug. Anyway, I filed this bug > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233697 > Will get Cc:ed on it. Thanks! -- Michel From michel.salim at gmail.com Tue Mar 27 02:55:10 2007 From: michel.salim at gmail.com (Michel Salim) Date: Mon, 26 Mar 2007 22:55:10 -0400 Subject: The need to re-detect usb-storage devices (on resume and on-the-fly plugging) In-Reply-To: <1174674122.2756.6.camel@zelda.fubar.dk> References: <883cfe6d0703231035s29b4ae7cxc5bbdbfdb993c6d2@mail.gmail.com> <1174674122.2756.6.camel@zelda.fubar.dk> Message-ID: <883cfe6d0703261955o641bcd07wbec3ec79c058946a@mail.gmail.com> 2007/3/23, David Zeuthen : > On Fri, 2007-03-23 at 13:35 -0400, Michel Salim wrote: > > I use an external hard drive with my laptop, that is detected and > > mounted fine (unless HAL and selinux-policy are out of sync) if > > plugged in at boot time. If I plug the drive after boot, or after > > resuming, the device node is created properly, but > > gnome-volume-manager does not register the device and has to be > > mounted manually. > > That's a bug. It works for me. > That now works for me as well. Not sure what was the problem previously. Thanks, -- Michel From rdieter at math.unl.edu Tue Mar 27 03:16:10 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 26 Mar 2007 22:16:10 -0500 Subject: hplip: hp-toolbox advertising? References: Message-ID: Bernard Johnson wrote: > I was working on finding/reporting some bugs with the hplip package and > noticed that there was no menu entry. Knowing that a graphical program > with no menu entry wasn't the norm, I was about to file a bug, except > when searching for a duplicate, I came across this: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170762 > mclasen at redhat.com: > "We don't give free ad space to HP on our menus..." > I find that to be both an interesting and hypocritical comment. Bernard has a point. Usability issues (e.g. David's comments) isn't an excuse for half-hearted packaging. If hplip is in fedora, it ought to be packaged properly (.desktop menu, icons, and all). -- Rex From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 03:18:43 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Mon, 26 Mar 2007 21:18:43 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174962834.2622.156.camel@zelda.fubar.dk> References: <1174946404.2622.98.camel@zelda.fubar.dk> <1174962834.2622.156.camel@zelda.fubar.dk> Message-ID: David Zeuthen wrote: >> Where are your bug reports to them? Your feature requests? Have you >> even interacted with the hplip guys before? > > No, I'm not the hplip package owner in any distribution and I just came > across this when looking at doing the ACL support things in HAL for > SANE. I'll probably try to talk to them, I was just shocked we actually > ship these bits. I expect you will be pleased with their openness and responsiveness to making things right. Which is exactly why I queried if you had expressed your concerns to them. "shocked"? Seriously David, I'm "shocked" that we still have these bugs: bz #218568, bz #177373, bz #216766. Which ones do you think more people run into? Or do you think more people dig through hplip and say "this is crap". And these are direct end-user facing bugs, yet no one is saying let's not make xen/gnome/etc. visible to the user. >> > - Not only that; starting this daemon is completely useless unless you >>> have HP hardware. We still start it for everyone so everyone have >>> to suffer. That's bad. >> and so is: >> smartd when I don't have a smartd drive >> bluethooth when I don't have bluetooth >> etc > > Two wrongs don't make a right (and, FWIW, I'm actually interacting with > the Bluez guys to make HAL start/stop the bluetooth daemons). I can't agree more, but let's not set one standard for one piece of software and not apply it evenly to others. I don't see anyone filing bz's to remove my bluetooth icons though. >> It's nice to sit in your tower and throw rocks, but end then end, some >> of us work with these products and are held accountable for things >> working or not, no matter what political or idealogical happenings go on >> at Fedora/Red Hat. > > I think I said already these are my personal points of view and that I > wasn't speaking for Red Hat and obviously not Fedora. So I'm a bit > unhappy to see you attribute these points of view to Fedora/Red Hat. > Please don't do that. Thanks. David, I apologize, this was not at all meant like that. Let me rephrase that as it was not at all meant to be from a concern of your working at RH. Some people are idealistic in this regard. It does not affect their work, performance, etc. regarding the product. I certainly have an idealistic flair, but tend to very much be a realist and very pragmatic when things must get done or must work. RH/Fedora (employees) still tend to be the primary motivators for making these sorts of decisions. IMHO, is the bz # pointed out wrong in a) reason b) motivation c) assessment, etc. (when compared to other pieces of software) yes. Will it get changed? No probably not. Can I point out a dozen or more equally egregious offenders? probably. If I file bz to have their icons or functionality removed, will they get removed? probably not. Seems a bit of a double standard.. no? > For the record, I know plenty of Fedora people (both inside and outside > of Red Hat) who, like you, are satisfied (and even excited) about the > status quo. Go figure. What? Let me repeat: > [1] I am generally very happy with Fedora progress, I just have to keep > reminding myself "everything takes time" :) (emphasis on *progress*) Rinse, lather, repeat. But in the interim, it must be usable. From mclasen at redhat.com Tue Mar 27 03:24:19 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 26 Mar 2007 23:24:19 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: Message-ID: <1174965859.24384.1.camel@localhost.localdomain> On Mon, 2007-03-26 at 22:16 -0500, Rex Dieter wrote: > Bernard Johnson wrote: > > > I was working on finding/reporting some bugs with the hplip package and > > noticed that there was no menu entry. Knowing that a graphical program > > with no menu entry wasn't the norm, I was about to file a bug, except > > when searching for a duplicate, I came across this: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170762 > > mclasen at redhat.com: > > "We don't give free ad space to HP on our menus..." > > > I find that to be both an interesting and hypocritical comment. > > Bernard has a point. Usability issues (e.g. David's comments) isn't an > excuse for half-hearted packaging. If hplip is in fedora, it ought to be > packaged properly (.desktop menu, icons, and all). Blindly following packaging guidelines is not an excuse for poor usability. From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 03:23:02 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Mon, 26 Mar 2007 21:23:02 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: Message-ID: Rex Dieter wrote: > Bernard has a point. Usability issues (e.g. David's comments) isn't an > excuse for half-hearted packaging. If hplip is in fedora, it ought to be > packaged properly (.desktop menu, icons, and all). I really hate it when I rant for paragraphs at a time and someone provides a good three sentence summary :) And for the record, I am *not against* pulling hplip from Fedora if that's the consensus. I am however against inconsistency in packages and application of policies across the distribution. From tmz at pobox.com Tue Mar 27 03:39:00 2007 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 26 Mar 2007 23:39:00 -0400 Subject: signatures for non-rpm files in $arch/os trees? In-Reply-To: <200703270148.51083.opensource@till.name> References: <20070325174541.GF27119@psilocybe.teonanacatl.org> <200703270148.51083.opensource@till.name> Message-ID: <20070327033900.GI27119@psilocybe.teonanacatl.org> Till Maas wrote: > On So M?rz 25 2007, Todd Zullinger wrote: > > [verify boot.iso and diskboot.img] > > The only way I know of, is to download the DVD or maybe the first > CD, verify it (there are gpg signed sha1sums available) and then > extrac boot.iso and diskboot.img from it. :-) True, that is one way. But of course it defeats the purpose of only having to download a tiny file to boot from. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ====================================================================== When crypto is outlawed, AtZoMJJzWM2GwNIxsO6ey1gYcHl4IqItK/kb5ABKzt0= -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 03:40:52 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Mon, 26 Mar 2007 21:40:52 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174965859.24384.1.camel@localhost.localdomain> References: <1174965859.24384.1.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: >>> mclasen at redhat.com: >>> "We don't give free ad space to HP on our menus..." >>> I find that to be both an interesting and hypocritical comment. >> Bernard has a point. Usability issues (e.g. David's comments) isn't an >> excuse for half-hearted packaging. If hplip is in fedora, it ought to be >> packaged properly (.desktop menu, icons, and all). > > Blindly following packaging guidelines is not an excuse for poor > usability. And I repeat "I can't agree more, but let's not set one standard for one piece of software and not apply it evenly to others." Are we willing to apply the same standards to each and every piece of software in Fedora? (*) (*) This is a semi-rhetorical question as a) We all know there are a at least a few "fragile" packages in Fedora yet we understand that there is a tradeoff between "perfect" and "usable/delivered". b) Nobody here is looking for a Debian release cycle :) From jdieter at gmail.com Tue Mar 27 04:13:30 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 27 Mar 2007 07:13:30 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174941261.30355.32.camel@cutter> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> <1174941261.30355.32.camel@cutter> Message-ID: <1174968810.19925.102.camel@jndwidescreen> On Mon, 2007-03-26 at 16:34 -0400, seth vidal wrote: > 1. why are you using md5sum and not sha1sums? Uh, I'm sorry, the line should have read "full (slow) on-disk checksum check". This particular checksum (which may be MD5 or SHA1, I'm not sure) is created by makedeltarpm -s, and tested by applydeltarpm -s, so it's actually completely controlled by deltarpm. > 2. what function are you using to do this check? Yum has a checksum > function you might be able to just use. I've actually "borrowed" *(cough)*stolen*(cough)* a heck of a lot of yum code, including the checksum function, which I do use to validate the presto.xml.gz file (among other things, and I do use sha1sums for this). If you look at prestoRepo.py, it's basically yumRepo.py with a few changes and a lot torn out. > > -sv > Jonathan -------------- 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 david at fubar.dk Tue Mar 27 04:59:35 2007 From: david at fubar.dk (David Zeuthen) Date: Tue, 27 Mar 2007 00:59:35 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174946404.2622.98.camel@zelda.fubar.dk> <1174962834.2622.156.camel@zelda.fubar.dk> Message-ID: <1174971575.2622.192.camel@zelda.fubar.dk> On Mon, 2007-03-26 at 21:18 -0600, Bernard Johnson wrote: > David Zeuthen wrote: > >> Where are your bug reports to them? Your feature requests? Have you > >> even interacted with the hplip guys before? > > > > No, I'm not the hplip package owner in any distribution and I just came > > across this when looking at doing the ACL support things in HAL for > > SANE. I'll probably try to talk to them, I was just shocked we actually > > ship these bits. > > I expect you will be pleased with their openness and responsiveness to > making things right. Which is exactly why I queried if you had > expressed your concerns to them. Good to hear. I'm still not the hplip package maintainer though. > Some people are idealistic in this regard. It does not affect their > work, performance, etc. regarding the product. I certainly have an > idealistic flair, but tend to very much be a realist and very pragmatic > when things must get done or must work. > > RH/Fedora (employees) still tend to be the primary motivators for making > these sorts of decisions. I think it's exactly this difference in point of view that is causing all these heavy flame wars on this and other Fedora lists. In one camp we have idealistic people that likes to address root problems. In the other camp we have pragmatic people who will settle for a "quick fix" even though it means compromising with quality (and not realizing that a "quick fix" is actually causing the root problem to never get fixed). Both groups describe each other as being counterproductive. Both groups knows tricks to get their agenda implemented. So I honestly don't know what the answer for Fedora is, I wish I did, but I'm pretty sure that the current state of affairs is not healthy for the project. And I don't see things getting better, only worse. As Jef said in a thoughtful mail a while back: Fedora is growing up, soon it will have hair in funny places. Or something like that. I can only hope that we can grow a strong contributor base in the Fedora Project, one that is willing to attack really hard problems without compromising / throwing bandaids at the problem at hand. One that doesn't give up even when the flames on fedora-devel gets high. Because we got to have goals. David From tmus at tmus.dk Tue Mar 27 04:59:57 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 27 Mar 2007 06:59:57 +0200 Subject: Presto logging In-Reply-To: <200703261753.26784.jkeating@redhat.com> References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> <200703261753.26784.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > > It's relying on mirrors to use OUR script to mirror content though, and we > can't count on A) they'd use our script instead of whatever else they're > using to sync other data, B) they're even using a host with bash/sh on it. > That's what I find so good about this solution. True, you'd need to do something extra to comply with the "mirroring protocol", but there is NO need for special mirroring scripts. It's all about putting a timestamp in a plain text. No need for special mirror scripts and it's easily doable on every single platform that I can think of. We should not provide any custom tools to perform this sync IMO, but supply a fedora mirroring howto, outlining what should be done. Mirror admins are then free to choose what ever sync tool/protocol he'd like, to perform the actual sync (rsync, ftp, cifs, nfs, ), as long as he remembers to put a simple date in a file, when he's done. /Thomas From a.badger at gmail.com Tue Mar 27 05:30:55 2007 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 26 Mar 2007 22:30:55 -0700 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174965859.24384.1.camel@localhost.localdomain> References: <1174965859.24384.1.camel@localhost.localdomain> Message-ID: <1174973455.9602.32.camel@localhost.localdomain> On Mon, 2007-03-26 at 23:24 -0400, Matthias Clasen wrote: > On Mon, 2007-03-26 at 22:16 -0500, Rex Dieter wrote: > > Bernard Johnson wrote: > > > > > I was working on finding/reporting some bugs with the hplip package and > > > noticed that there was no menu entry. Knowing that a graphical program > > > with no menu entry wasn't the norm, I was about to file a bug, except > > > when searching for a duplicate, I came across this: > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170762 > > > mclasen at redhat.com: > > > "We don't give free ad space to HP on our menus..." > > > > > I find that to be both an interesting and hypocritical comment. > > > > Bernard has a point. Usability issues (e.g. David's comments) isn't an > > excuse for half-hearted packaging. If hplip is in fedora, it ought to be > > packaged properly (.desktop menu, icons, and all). > > Blindly following packaging guidelines is not an excuse for poor > usability. > Do we have an alternative to provide that functionality? If so, sure, get rid of the poorly behaved software and enable something else in its place. If not, then we're robbing the user of functionality. -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 bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 05:38:48 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Mon, 26 Mar 2007 23:38:48 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174971575.2622.192.camel@zelda.fubar.dk> References: <1174946404.2622.98.camel@zelda.fubar.dk> <1174962834.2622.156.camel@zelda.fubar.dk> <1174971575.2622.192.camel@zelda.fubar.dk> Message-ID: David Zeuthen wrote: > On Mon, 2007-03-26 at 21:18 -0600, Bernard Johnson wrote: >> David Zeuthen wrote: >>>> Where are your bug reports to them? Your feature requests? Have you >>>> even interacted with the hplip guys before? >>> No, I'm not the hplip package owner in any distribution and I just came >>> across this when looking at doing the ACL support things in HAL for >>> SANE. I'll probably try to talk to them, I was just shocked we actually >>> ship these bits. >> I expect you will be pleased with their openness and responsiveness to >> making things right. Which is exactly why I queried if you had >> expressed your concerns to them. > > Good to hear. I'm still not the hplip package maintainer though. Well, I'm not either :) But I've had *some* interaction with them. I only mention this because, by your own admission, you will likely end up in the same boat. You might be interested in this thread: http://permalink.gmane.org/gmane.comp.printing.hplip.devel/353 where David Suffield says "... we have learned a lot since we have started the HPLIP project and we have learned what is useful and what is not, so we are looking into the possibility of a daemon-less version of HPLIP." If you feel strongly about the way that hplip /should/ work, I urge you to contact them with your views. From peter at thecodergeek.com Tue Mar 27 05:41:40 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 26 Mar 2007 22:41:40 -0700 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174973455.9602.32.camel@localhost.localdomain> References: <1174965859.24384.1.camel@localhost.localdomain> <1174973455.9602.32.camel@localhost.localdomain> Message-ID: <1174974100.10965.1.camel@tuxhugs> On Mon, 2007-03-26 at 22:30 -0700, Toshio Kuratomi wrote: > Do we have an alternative to provide that functionality? If so, sure, > get rid of the poorly behaved software and enable something else in its > place. If not, then we're robbing the user of functionality. > > -Toshio There is also Stylus-Toolbox [1]. Perhaps we could integrate a lot of that printer-maintenance work in CUPS itself somehow? -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Tue Mar 27 05:46:53 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 26 Mar 2007 22:46:53 -0700 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174974100.10965.1.camel@tuxhugs> References: <1174965859.24384.1.camel@localhost.localdomain> <1174973455.9602.32.camel@localhost.localdomain> <1174974100.10965.1.camel@tuxhugs> Message-ID: <1174974413.10965.2.camel@tuxhugs> On Mon, 2007-03-26 at 22:41 -0700, Peter Gordon wrote: > On Mon, 2007-03-26 at 22:30 -0700, Toshio Kuratomi wrote: > > Do we have an alternative to provide that functionality? If so, sure, > > get rid of the poorly behaved software and enable something else in its > > place. If not, then we're robbing the user of functionality. > > > > -Toshio > > There is also Stylus-Toolbox [1]. > > Perhaps we could integrate a lot of that printer-maintenance work in > CUPS itself somehow? Err, note to self: Always add the footnote if you reference it in your message. >_< [1] http://stylus-toolbox.sourceforge.net/ Sorry for the confusion... -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 05:54:40 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Mon, 26 Mar 2007 23:54:40 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174974100.10965.1.camel@tuxhugs> References: <1174965859.24384.1.camel@localhost.localdomain> <1174973455.9602.32.camel@localhost.localdomain> <1174974100.10965.1.camel@tuxhugs> Message-ID: Peter Gordon wrote: > On Mon, 2007-03-26 at 22:30 -0700, Toshio Kuratomi wrote: >> Do we have an alternative to provide that functionality? If so, sure, >> get rid of the poorly behaved software and enable something else in its >> place. If not, then we're robbing the user of functionality. >> >> -Toshio > > There is also Stylus-Toolbox [1]. > > Perhaps we could integrate a lot of that printer-maintenance work in > CUPS itself somehow? > hplip also has: * faxing on a local/network multi-function printer * setting up copy jobs on a local/network multi-function printer * scanning on a local/network multi-function printer * unloading memory cards on a local/network multi-function printer It appears that Stylus Toolbox does none of this. From peter at thecodergeek.com Tue Mar 27 06:29:33 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 26 Mar 2007 23:29:33 -0700 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174965859.24384.1.camel@localhost.localdomain> <1174973455.9602.32.camel@localhost.localdomain> <1174974100.10965.1.camel@tuxhugs> Message-ID: <1174976973.10965.4.camel@tuxhugs> On Mon, 2007-03-26 at 23:54 -0600, Bernard Johnson wrote: > hplip also has: > > * faxing on a local/network multi-function printer > * setting up copy jobs on a local/network multi-function printer > * scanning on a local/network multi-function printer > * unloading memory cards on a local/network multi-function printer > > > It appears that Stylus Toolbox does none of this. Yeah, but what about the more-generic ink level checking, head alignment/cleaning, et al.? :) -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 spng.yang at gmail.com Tue Mar 27 06:27:52 2007 From: spng.yang at gmail.com (Ken YANG) Date: Tue, 27 Mar 2007 14:27:52 +0800 Subject: where is gedit-plugins? Message-ID: <4608B968.4060002@gmail.com> in gedit 2.18, there is a plugin which can perform bracket automatic completion. i try this plugin in ubuntu, but i can not find in fedora repos. is there any other place to store such programs? From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 06:34:44 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Tue, 27 Mar 2007 00:34:44 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174976973.10965.4.camel@tuxhugs> References: <1174965859.24384.1.camel@localhost.localdomain> <1174973455.9602.32.camel@localhost.localdomain> <1174974100.10965.1.camel@tuxhugs> <1174976973.10965.4.camel@tuxhugs> Message-ID: Peter Gordon wrote: > On Mon, 2007-03-26 at 23:54 -0600, Bernard Johnson wrote: >> hplip also has: >> >> * faxing on a local/network multi-function printer >> * setting up copy jobs on a local/network multi-function printer >> * scanning on a local/network multi-function printer >> * unloading memory cards on a local/network multi-function printer >> >> >> It appears that Stylus Toolbox does none of this. > > Yeah, but what about the more-generic ink level checking, head > alignment/cleaning, et al.? :) > I guess my message was a bit terse. What I should have said was... I'm all for integration and leveraging other products to a unified status/maintenance application, however, hplip does much more that that, such as: :) From peter at thecodergeek.com Tue Mar 27 06:46:14 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 26 Mar 2007 23:46:14 -0700 Subject: where is gedit-plugins? In-Reply-To: <4608B968.4060002@gmail.com> References: <4608B968.4060002@gmail.com> Message-ID: <1174977974.10965.6.camel@tuxhugs> On Tue, 2007-03-27 at 14:27 +0800, Ken YANG wrote: > > in gedit 2.18, there is a plugin which can perform bracket > automatic completion. > > i try this plugin in ubuntu, but i can not find in fedora repos. > > is there any other place to store such programs? It's currently undergoing QA review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225066 -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Tue Mar 27 06:46:46 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 26 Mar 2007 23:46:46 -0700 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174965859.24384.1.camel@localhost.localdomain> <1174973455.9602.32.camel@localhost.localdomain> <1174974100.10965.1.camel@tuxhugs> <1174976973.10965.4.camel@tuxhugs> Message-ID: <1174978006.10965.8.camel@tuxhugs> On Tue, 2007-03-27 at 00:34 -0600, Bernard Johnson wrote: > I guess my message was a bit terse. What I should have said was... I'm > all for integration and leveraging other products to a unified > status/maintenance application, however, hplip does much more that that, > such as: :) I see. Thanks for the clarification. -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 tmus at tmus.dk Tue Mar 27 06:47:51 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 27 Mar 2007 08:47:51 +0200 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174946404.2622.98.camel@zelda.fubar.dk> Message-ID: Bernard Johnson wrote: > David Zeuthen wrote: >> Now, if only HP would play nicely with the open source community and >> _just_ provide only drivers instead of reinventing the wheel by > > Well, I'm sure you're just emphatic about "better software" but I think > it comes across as looking a gift horse in the mouth. I mean, what do > you want, junk the hp software and then I can have the same printing > capabilities as when I had this: > http://openprinting.org/show_printer.cgi?recnum=HP-LaserJet_3100 > (disclaimer: i'm not actually using the hp software...) But, the whole analogy to looking a gift horse in the mouth is somewhat mute here, wouldn't you say? Just because corp XYZ throws a pile of software at the open source community, doesn't mean we have to embrace it if we don't like it. This is not a gift from anyones grandma, but from a manufacturer that just wants an easy to use toolset for linux users. The cause is noble enough, but if the software is less than ideal, which it appears to be in this case, we are free to choose to do whatever we want with it. /Thomas From giallu at gmail.com Tue Mar 27 07:10:57 2007 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 27 Mar 2007 09:10:57 +0200 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174946404.2622.98.camel@zelda.fubar.dk> Message-ID: On 3/27/07, Thomas M Steenholdt wrote: > (disclaimer: i'm not actually using the hp software...) > > But, the whole analogy to looking a gift horse in the mouth is somewhat > mute here, wouldn't you say? Just because corp XYZ throws a pile of > software at the open source community, doesn't mean we have to embrace > it if we don't like it. This is not a gift from anyones grandma, but > from a manufacturer that just wants an easy to use toolset for linux > users. The cause is noble enough, but if the software is less than > ideal, which it appears to be in this case, we are free to choose to do > whatever we want with it. In general I agree with you, but the problem is we lack an alternative package offering the same (or similar) features. In this case, removing hplip results in someone not being able to work OOTB with its multifulction printer, which is not the best thing we could do. I think the best thing is to ship it as is (eventually adding a Fedora specific icon to fix the problem raised by the original poster) and be sure to pester upstream for a more SANE approach... /me goes disabling hplip from each machine in the office From tmus at tmus.dk Tue Mar 27 07:20:02 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 27 Mar 2007 09:20:02 +0200 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174946404.2622.98.camel@zelda.fubar.dk> Message-ID: Gianluca Sforna wrote: > On 3/27/07, Thomas M Steenholdt wrote: >> (disclaimer: i'm not actually using the hp software...) >> >> But, the whole analogy to looking a gift horse in the mouth is somewhat >> mute here, wouldn't you say? Just because corp XYZ throws a pile of >> software at the open source community, doesn't mean we have to embrace >> it if we don't like it. This is not a gift from anyones grandma, but >> from a manufacturer that just wants an easy to use toolset for linux >> users. The cause is noble enough, but if the software is less than >> ideal, which it appears to be in this case, we are free to choose to do >> whatever we want with it. > > In general I agree with you, but the problem is we lack an alternative > package offering the same (or similar) features. In this case, > removing hplip results in someone not being able to work OOTB with its > multifulction printer, which is not the best thing we could do. > > I think the best thing is to ship it as is (eventually adding a Fedora > specific icon to fix the problem raised by the original poster) and be > sure to pester upstream for a more SANE approach... > > /me goes disabling hplip from each machine in the office > Again, I have to state that I don't know this software, so my discussion is from a more generic view. Even if we have no alternative, I'm not sure it's the best thing we can do, to install software with design/implementation security flaws. If that is the case, I'd much rather have people pull this from a third party repository, that installing it by default. The ideal way, seems to be to convince HP and all other device vendors to contribute to some of the standard frameworks, to improve on those, instead of introducing a complete new toolset for every vendor/device combo (windows style). /Thomas From mmarcini at redhat.com Tue Mar 27 07:51:25 2007 From: mmarcini at redhat.com (Michal Marciniszyn) Date: Tue, 27 Mar 2007 09:51:25 +0200 Subject: Initscripts and LSB compliance Message-ID: <4608CCFD.5040600@redhat.com> Hi, due to my recent investigations, nearly none of the initscripts that we have included in RHEL/Fedora are LSB (Linux Standard Base) compliant. I'm not talking about problems with %config stuff, but about the functionality of the scripts. Main problems are constructions like [ -f /etc/service_conffile ] || exit 0 which ends the script with exit code 0 when there is no conf file for the service. Another big issue is wrong functionality of status call of initscript... And of course, the wrong return codes. The LSB compliance is IMHO one of our targets, so we should take care of this one. The LSB definitons can be found on: http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/tocsysinit.html Our first step should be to produce guidelines (we have some for RHEL, but they are not obeyed), then force the developers to obey that. It is no big deal, but having all scripts behaving correctly and in some sense the standard way is definitely good think. --michal marciniszyn mmarcini at redhat.com From jakub at redhat.com Tue Mar 27 08:03:09 2007 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 27 Mar 2007 03:03:09 -0500 Subject: Initscripts and LSB compliance In-Reply-To: <4608CCFD.5040600@redhat.com> References: <4608CCFD.5040600@redhat.com> Message-ID: <20070327080309.GX355@devserv.devel.redhat.com> On Tue, Mar 27, 2007 at 09:51:25AM +0200, Michal Marciniszyn wrote: > due to my recent investigations, nearly none of the initscripts that we > have included in RHEL/Fedora are LSB (Linux Standard Base) compliant. > I'm not talking about problems with %config stuff, but about the > functionality of the scripts. Main problems are constructions like Why does this matter? The init scripts in RHEL/Fedora aren't meant to be run on any LSB compliant distro, they are meant to be run on RHEL/Fedora. All we should care is that you can install a LSB compliant application on our distro and that it's LSB compliant init script will work as required by LSB. > [ -f /etc/service_conffile ] || exit 0 The fewer commands the script runs the shorter is the startup time, something we really care about. Jakub From mmarcini at redhat.com Tue Mar 27 08:07:52 2007 From: mmarcini at redhat.com (Michal Marciniszyn) Date: Tue, 27 Mar 2007 10:07:52 +0200 Subject: Initscripts and LSB compliance In-Reply-To: <20070327080309.GX355@devserv.devel.redhat.com> References: <4608CCFD.5040600@redhat.com> <20070327080309.GX355@devserv.devel.redhat.com> Message-ID: <4608D0D8.9030806@redhat.com> Jakub Jelinek wrote: > On Tue, Mar 27, 2007 at 09:51:25AM +0200, Michal Marciniszyn wrote: > >> due to my recent investigations, nearly none of the initscripts that we >> have included in RHEL/Fedora are LSB (Linux Standard Base) compliant. >> I'm not talking about problems with %config stuff, but about the >> functionality of the scripts. Main problems are constructions like >> > > Why does this matter? The init scripts in RHEL/Fedora aren't meant to be > run on any LSB compliant distro, they are meant to be run on RHEL/Fedora. > All we should care is that you can install a LSB compliant application > on our distro and that it's LSB compliant init script will work as > required by LSB. > What if LSB compliant application needs correct return codes of stripts that initialize the services (if something is broken)? And btw. there are guidelines for initscripts in RHEL that are equivalent to LSB and directly points you to LSB... I can give you link if you're interested. > >> [ -f /etc/service_conffile ] || exit 0 >> > > The fewer commands the script runs the shorter is the startup time, > something we really care about. > > Jakub > That is true, however, previous construction is completely wrong if you think about it... It is just same as if for example ifconfig eth0 up returns code 0 when eth0 does not exist. --mm From mmarcini at redhat.com Tue Mar 27 08:13:05 2007 From: mmarcini at redhat.com (Michal Marciniszyn) Date: Tue, 27 Mar 2007 10:13:05 +0200 Subject: Initscripts and LSB compliance In-Reply-To: <20070327080309.GX355@devserv.devel.redhat.com> References: <4608CCFD.5040600@redhat.com> <20070327080309.GX355@devserv.devel.redhat.com> Message-ID: <4608D211.50404@redhat.com> Jakub Jelinek wrote: > On Tue, Mar 27, 2007 at 09:51:25AM +0200, Michal Marciniszyn wrote: > >> due to my recent investigations, nearly none of the initscripts that we >> have included in RHEL/Fedora are LSB (Linux Standard Base) compliant. >> I'm not talking about problems with %config stuff, but about the >> functionality of the scripts. Main problems are constructions like >> > > Why does this matter? The init scripts in RHEL/Fedora aren't meant to be > run on any LSB compliant distro, they are meant to be run on RHEL/Fedora. > All we should care is that you can install a LSB compliant application > on our distro and that it's LSB compliant init script will work as > required by LSB. > What if LSB compliant application needs correct return codes of stripts that initialize the services (if something is broken)? And btw. there are guidelines for initscripts in RHEL that are equivalent to LSB and directly points you to LSB... I can give you link if you're interested. > >> [ -f /etc/service_conffile ] || exit 0 >> > > The fewer commands the script runs the shorter is the startup time, > something we really care about. > > Jakub > That is true, however, previous construction is completely wrong if you think about it... It is just same as if for example ifconfig eth0 up returns code 0 when eth0 does not exist. --mm From emmanuel.seyman at club-internet.fr Tue Mar 27 08:18:07 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Tue, 27 Mar 2007 10:18:07 +0200 Subject: Initscripts and LSB compliance In-Reply-To: <20070327080309.GX355@devserv.devel.redhat.com> References: <4608CCFD.5040600@redhat.com> <20070327080309.GX355@devserv.devel.redhat.com> Message-ID: <20070327081807.GA4459@orient.maison.lan> * Jakub Jelinek [27/03/2007 10:10] : > > > [ -f /etc/service_conffile ] || exit 0 > > The fewer commands the script runs the shorter is the startup time, > something we really care about. I believe the problem here is that the application returns 0 (service is OK) when it should return 6 (program is not configured). Emmanuel From pertusus at free.fr Tue Mar 27 09:28:10 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 27 Mar 2007 11:28:10 +0200 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> Message-ID: <20070327092810.GB2896@free.fr> On Mon, Mar 26, 2007 at 09:59:35PM -0400, Jon Ciesla wrote: > -Provides: ettercap-plugins <= %{version} > +Obsoletes: ettercap-plugins <= 0.7.3-14%{dist} I suggest hardcoding the %{dist} to what it was when the package was merged (so I guess it is fc7 here). For the fc6 and fc5 packages it is not as clear, but I guess that using fc7 too would be safer. -- Pat From atkac at redhat.com Tue Mar 27 09:48:54 2007 From: atkac at redhat.com (Adam Tkac) Date: Tue, 27 Mar 2007 11:48:54 +0200 Subject: Why nobody uses vnc module to X? Message-ID: <4608E886.3070508@redhat.com> Hi all, I'm really surprised that nobody uses vnc's rawhide module to X. Module was completely unusable since 2nd March (got sigsegv) and no bugreport came to me :( . So looks that no one uses rawhide vnc (unlikely) or all need RANDR support and have national-specific keyboards and for this use vino or krfb (unlikely too). Or vnc module users are disgusted with sometimes nasty bugs and bugreporting and they prefer slower, but sometimes more reliable servers? This isn't sounds good for me :( . I'm really interested in how can I reconquer prestige of vnc module again :) Regards, -A- From fedora.lists at burns.me.uk Tue Mar 27 10:00:50 2007 From: fedora.lists at burns.me.uk (Andy Burns) Date: Tue, 27 Mar 2007 11:00:50 +0100 Subject: Why nobody uses vnc module to X? In-Reply-To: <4608E886.3070508@redhat.com> References: <4608E886.3070508@redhat.com> Message-ID: On 27/03/07, Adam Tkac wrote: > I'm really surprised that nobody uses vnc's rawhide module to X. Module > was completely unusable since 2nd March (got sigsegv) and no bugreport > came to me :( . I do the occasional anaconda/vnc install, but after installation for remote sessions I tend to use X/SSH tunnels for improved security, and less hassle with other people's firewalls. > I'm really interested in how can I reconquer prestige of vnc module again :) Does Fedora include an open version of NX? From buildsys at redhat.com Tue Mar 27 10:03:49 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Tue, 27 Mar 2007 06:03:49 -0400 Subject: rawhide report: 20070327 changes Message-ID: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> Updated Packages: firefox-2.0.0.3-2.fc7 --------------------- * Sun Mar 25 2007 Christopher Aillon 2.0.0.3-2 - Fix the symlink to default bookmarks - Use mktemp for temp dirs hal-0.5.9-0.git20070326.fc7 --------------------------- * Mon Mar 26 2007 David Zeuthen - 0.5.9-0.git20070326 - Update to hal 0.5.9rc2 and hal-info-20070326 - Bring back Fedora eject patch (#231459) - Build docs and put them in new subpackage hal-docs * Sun Mar 25 2007 Matthias Clasen - 0.5.9-0.git20070304.fc7.1 - Fix directory ownership issues (#233840) * Sun Mar 04 2007 David Zeuthen - 0.5.9-0.git20070304 - Update to 0.5.9rc1; notable user visible changes: - New /sbin/umount.hal helper (#188193) - Slow down polling if no session is non-idle (#204969) - Refuse to eject busy devices (#207177) - Don't mount noexec unless requested - Use inotify to watch for new fdi files - Support for new Firewire stack - BT killswitch for Sony laptops (hadess) - Pass suspend quirks to pm-utils (need new pm-utils release to use it) kernel-2.6.20-1.3023.fc7 ------------------------ * Sun Mar 25 2007 Dave Jones - 2.6.21-rc5 * Sun Mar 25 2007 Dave Jones - 2.6.21-rc4-git11 * Sun Mar 25 2007 David Woodhouse - Use /sys/power/state for suspend to RAM on PowerMac policycoreutils-2.0.7-5.fc7 --------------------------- * Fri Mar 23 2007 Dan Walsh 2.0.7-5 - Change location of audit2allow and sepol-ifgen to sbin - Updated version of sepolgen selinux-policy-2.5.10-2.fc7 --------------------------- * Fri Mar 23 2007 Dan Walsh 2.5.10-2 - Allow samba to run groupadd * Thu Mar 22 2007 Dan Walsh 2.5.10-1 - Update to upstream * Thu Mar 22 2007 Dan Walsh 2.5.9-6 - Allow mdadm to access generic scsi devices 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 mls at suse.de Tue Mar 27 10:05:43 2007 From: mls at suse.de (Michael Schroeder) Date: Tue, 27 Mar 2007 12:05:43 +0200 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174941261.30355.32.camel@cutter> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> <1174941261.30355.32.camel@cutter> Message-ID: <20070327100542.GA4814@suse.de> On Mon, Mar 26, 2007 at 04:34:21PM -0400, seth vidal wrote: > 1. why are you using md5sum and not sha1sums? It checks if the md5sum of the file matches the sum from the rpm header. It works basically like this: The "sequence" tells applydeltarpm which of the files from the rpm header were used to create the deltarpm and the order of those files (thus the name "sequence" in case you wondered). makedeltarpm doesn't use all files to create the delta, config files and files that have the "verify" bit off get excluded. If you ask applydeltarpm to check if a deltarpm can be applied it uses this sequence to verify that all used files are unchanged, either by just checking the size (the fast method) or by checking the md5sum (like rpm does). The fast method makes sense if the updater has a fallback to fetch the complete rpm if applydeltarpm failes, as in most cases files are unchanged if the size is the same. Cheers, Michael. -- Michael Schroeder mls at suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} From hughsient at gmail.com Tue Mar 27 10:08:31 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Mar 2007 11:08:31 +0100 Subject: rawhide report: 20070327 changes In-Reply-To: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> Message-ID: <1174990111.13483.3.camel@localhost.localdomain> On Tue, 2007-03-27 at 06:03 -0400, buildsys at redhat.com wrote: > hal-0.5.9-0.git20070326.fc7 > --------------------------- > * Mon Mar 26 2007 David Zeuthen - > 0.5.9-0.git20070326 > - Update to hal 0.5.9rc2 and hal-info-20070326 These *need* to be split into separate SRPMS. I don't mind co-maintaining these if you want, but if we are updating machine quirks once a month or so, then we should be able to update one 100k no-arch package, rather than 4 or 5 multi-megabyte architecture specific packages. Sorry to harp on about this, but F7T3 is getting closer. Richard. From dwmw2 at infradead.org Tue Mar 27 10:12:42 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 27 Mar 2007 11:12:42 +0100 Subject: FC-6 NetworkManager needs some love In-Reply-To: <1174922765.8528.11.camel@localhost.localdomain> References: <4607E018.9010809@poolshark.org> <1174922145.3277.3.camel@pmac.infradead.org> <1174922765.8528.11.camel@localhost.localdomain> Message-ID: <1174990362.3277.19.camel@pmac.infradead.org> On Mon, 2007-03-26 at 16:26 +0100, Richard Hughes wrote: > On Mon, 2007-03-26 at 16:15 +0100, David Woodhouse wrote: > > > > It's got worse in rawhide -- it's now asking for that password after > > every suspend/resume cycle. > > No, that's by design. gnome-power-manager tells gnome-keyring to "lock" > on suspend for security. See gnome bug #375681. Taken holistically, it's a very broken design. The WEP key it's asking for is a system-wide thing; in fact it's even stored in the standard network configuration in /etc/sysconfig/network-scripts/keys-eth1 -- yet although NetworkManager obeys _some_ of the standard network configuration, it ignores the key, and insists on asking mere _users_ about it. And then demands a password before using it. Repeatedly. That's just crap. -- dwmw2 From mschwendt.tmp0701.nospam at arcor.de Tue Mar 27 10:17:02 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 27 Mar 2007 12:17:02 +0200 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: <20070327092810.GB2896@free.fr> References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> Message-ID: <20070327121702.cc573e59.mschwendt.tmp0701.nospam@arcor.de> On Tue, 27 Mar 2007 11:28:10 +0200, Patrice Dumas wrote: > On Mon, Mar 26, 2007 at 09:59:35PM -0400, Jon Ciesla wrote: > > -Provides: ettercap-plugins <= %{version} > > +Obsoletes: ettercap-plugins <= 0.7.3-14%{dist} > > I suggest hardcoding the %{dist} to what it was when the package was > merged (so I guess it is fc7 here). For the fc6 and fc5 packages it > is not as clear, but I guess that using fc7 too would be safer. Questionable, albeit would serve as an ugly work-around. It would defeat the purpose of the dist tag, since if you reused the spec for multiple branches, it would make the fc5 package obsolete an fc7 package. Though, the upgrade path from an updated old dist to a CD/DVD based copy of a newer dist is broken for many packages anyway, as updates for old branches are higher in EVR than the new dist prior to its online updates. From jdieter at gmail.com Tue Mar 27 10:29:51 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 27 Mar 2007 13:29:51 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <20070327100542.GA4814@suse.de> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> <1174941261.30355.32.camel@cutter> <20070327100542.GA4814@suse.de> Message-ID: <1174991391.19925.116.camel@jndwidescreen.lesbg.loc> On Tue, 2007-03-27 at 12:05 +0200, Michael Schroeder wrote: > On Mon, Mar 26, 2007 at 04:34:21PM -0400, seth vidal wrote: > > 1. why are you using md5sum and not sha1sums? > > It checks if the md5sum of the file matches the sum from the rpm > header. > > It works basically like this: The "sequence" tells applydeltarpm > which of the files from the rpm header were used to create the > deltarpm and the order of those files (thus the name "sequence" > in case you wondered). makedeltarpm doesn't use all files to > create the delta, config files and files that have the "verify" > bit off get excluded. If you ask applydeltarpm to check if a > deltarpm can be applied it uses this sequence to verify that all > used files are unchanged, either by just checking the size (the > fast method) or by checking the md5sum (like rpm does). > The fast method makes sense if the updater has a fallback to > fetch the complete rpm if applydeltarpm failes, as in most cases > files are unchanged if the size is the same. > > Cheers, > Michael. > And I changed Presto last night to use the full method, rather than the fast method. Our fallback method is pretty lousy (exiting with an error, working the second time yum is called), at least for the moment. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Tue Mar 27 10:35:49 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 27 Mar 2007 12:35:49 +0200 Subject: rawhide report: 20070327 changes In-Reply-To: <1174990111.13483.3.camel@localhost.localdomain> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <1174990111.13483.3.camel@localhost.localdomain> Message-ID: <4608F385.8070602@leemhuis.info> On 27.03.2007 12:08, Richard Hughes wrote: > On Tue, 2007-03-27 at 06:03 -0400, buildsys at redhat.com wrote: >> hal-0.5.9-0.git20070326.fc7 >> --------------------------- >> * Mon Mar 26 2007 David Zeuthen - >> 0.5.9-0.git20070326 >> - Update to hal 0.5.9rc2 and hal-info-20070326 > These *need* to be split into separate SRPMS. I don't mind > co-maintaining these if you want, but if we are updating machine quirks > once a month or so, [...] BTW regarding all those machine quirks to make suspend "simply work": - is there any coordination with the people behind s2ram? - for the video related quirks: are you differentiating if the systems where those quirks got tested run -- vesa framebuffer -- chip-specific framebuffer driver -- plain vga (vga=0) on the console and -- free X drivers -- proprietary display drivers in X? Especially using plain VGA or framebuffer seems to influence the options that are needed to bring the video device back to work a lot in my experience. Side note: Ubuntu and Suse both use framebuffer, Fedora a plain text console normally; so a quirk that works on Fedora maybe doesn't help on Suse (or the other way around). Just wondering. I like the idea to make suspend "simply work" a lot ;-) CU thl From hughsient at gmail.com Tue Mar 27 10:46:45 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Mar 2007 11:46:45 +0100 Subject: rawhide report: 20070327 changes In-Reply-To: <4608F385.8070602@leemhuis.info> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <1174990111.13483.3.camel@localhost.localdomain> <4608F385.8070602@leemhuis.info> Message-ID: <1174992405.13483.9.camel@localhost.localdomain> On Tue, 2007-03-27 at 12:35 +0200, Thorsten Leemhuis wrote: > On 27.03.2007 12:08, Richard Hughes wrote: > > On Tue, 2007-03-27 at 06:03 -0400, buildsys at redhat.com wrote: > >> hal-0.5.9-0.git20070326.fc7 > >> --------------------------- > >> * Mon Mar 26 2007 David Zeuthen - > >> 0.5.9-0.git20070326 > >> - Update to hal 0.5.9rc2 and hal-info-20070326 > > These *need* to be split into separate SRPMS. I don't mind > > co-maintaining these if you want, but if we are updating machine quirks > > once a month or so, [...] > > BTW regarding all those machine quirks to make suspend "simply work": > > - is there any coordination with the people behind s2ram? Well, the DMI whitelist is based on the s2ram whitelist. We're hoping to standardise on XML descriptions for both s2ram and HAL. > - for the video related quirks: are you differentiating if the systems > where those quirks got tested run > -- vesa framebuffer > -- chip-specific framebuffer driver > -- plain vga (vga=0) > on the console and > -- free X drivers > -- proprietary display drivers Yes we can, as we can match the driver in the HAL fdi. As for the other stuff, I don't know. We can tweak this stuff easily with a hal-info update. > in X? Especially using plain VGA or framebuffer seems to influence the > options that are needed to bring the video device back to work a lot in > my experience. That's the plan. Without X we are sunk. > Side note: Ubuntu and Suse both use framebuffer, Fedora a plain text > console normally; so a quirk that works on Fedora maybe doesn't help on > Suse (or the other way around). Well, all this is very new. The very least we will achieve is to get screens to turn back on when they come back from suspend, i.e. to DPMS on where needed, and to poke vbetool and restore vbestate. Some other odd quirks like radeontool are present, but completely untested. > Just wondering. I like the idea to make suspend "simply work" a lot ;-) You and me both ;-) Richard. From hughsient at gmail.com Tue Mar 27 10:50:23 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Mar 2007 11:50:23 +0100 Subject: FC-6 NetworkManager needs some love In-Reply-To: <1174990362.3277.19.camel@pmac.infradead.org> References: <4607E018.9010809@poolshark.org> <1174922145.3277.3.camel@pmac.infradead.org> <1174922765.8528.11.camel@localhost.localdomain> <1174990362.3277.19.camel@pmac.infradead.org> Message-ID: <1174992623.13483.11.camel@localhost.localdomain> On Tue, 2007-03-27 at 11:12 +0100, David Woodhouse wrote: > > Taken holistically, it's a very broken design. The WEP key it's asking > for is a system-wide thing; in fact it's even stored in the standard > network configuration in /etc/sysconfig/network-scripts/keys-eth1 -- > yet > although NetworkManager obeys _some_ of the standard network > configuration, it ignores the key, and insists on asking mere _users_ > about it. And then demands a password before using it. Repeatedly. > > That's just crap. Well, harsh, but I agree. Pull the latest 2-18 code from gnome svn and that defaults to not locking the keyring. Richard. From fedora at leemhuis.info Tue Mar 27 11:06:09 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 27 Mar 2007 13:06:09 +0200 Subject: rawhide report: 20070327 changes In-Reply-To: <1174992405.13483.9.camel@localhost.localdomain> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <1174990111.13483.3.camel@localhost.localdomain> <4608F385.8070602@leemhuis.info> <1174992405.13483.9.camel@localhost.localdomain> Message-ID: <4608FAA1.9080903@leemhuis.info> On 27.03.2007 12:46, Richard Hughes wrote: > >> in X? Especially using plain VGA or framebuffer seems to influence the >> options that are needed to bring the video device back to work a lot in >> my experience. > That's the plan. Without X we are sunk. /me wonders who'll be the first that says "X is overrated; 80 colums and 24 (25?) lines is more then enough to run irssi" >> Side note: Ubuntu and Suse both use framebuffer, Fedora a plain text >> console normally; so a quirk that works on Fedora maybe doesn't help on >> Suse (or the other way around). > Well, all this is very new. The very least we will achieve is to get > screens to turn back on when they come back from suspend, i.e. to DPMS > on where needed, and to poke vbetool and restore vbestate. Some other > odd quirks like radeontool are present, but completely untested. Well, we'll see how it evolves. Anyway: thx for your great work Richard! > [...] CU thl From pertusus at free.fr Tue Mar 27 11:08:37 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 27 Mar 2007 13:08:37 +0200 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: <20070327121702.cc573e59.mschwendt.tmp0701.nospam@arcor.de> References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <20070327121702.cc573e59.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070327110837.GE2896@free.fr> On Tue, Mar 27, 2007 at 12:17:02PM +0200, Michael Schwendt wrote: > On Tue, 27 Mar 2007 11:28:10 +0200, Patrice Dumas wrote: > > > > I suggest hardcoding the %{dist} to what it was when the package was > > merged (so I guess it is fc7 here). For the fc6 and fc5 packages it > > is not as clear, but I guess that using fc7 too would be safer. > > Questionable, albeit would serve as an ugly work-around. It would defeat > the purpose of the dist tag, since if you reused the spec for multiple > branches, it would make the fc5 package obsolete an fc7 package. Indeed, that's why I think what to do isn't really clear. 2 points if favor of having fc7 in all the specs is that it is really the 'latest' version shipped in fedora, and it can be the same for all the branches. Using %{dist} will get wrong when it becomes fc8. Maybe a solution could be to skip a release and obsolete that release without dist tag. For example: foo-0-4%{?dist} is the latest version with the subpackage foo-sub. next package is foo-0-6%{?dist} and in this package and above there is Obsolete: foo-sub <= 0-5 Maybe another possibility could be to use Obsoletes: ettercap-plugins < 0.7.3-15 Would that work? -- Pat From pertusus at free.fr Tue Mar 27 11:13:32 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 27 Mar 2007 13:13:32 +0200 Subject: rawhide report: 20070327 changes In-Reply-To: <1174990111.13483.3.camel@localhost.localdomain> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <1174990111.13483.3.camel@localhost.localdomain> Message-ID: <20070327111332.GF2896@free.fr> On Tue, Mar 27, 2007 at 11:08:31AM +0100, Richard Hughes wrote: > On Tue, 2007-03-27 at 06:03 -0400, buildsys at redhat.com wrote: > > hal-0.5.9-0.git20070326.fc7 > > --------------------------- > > * Mon Mar 26 2007 David Zeuthen - > > 0.5.9-0.git20070326 > > - Update to hal 0.5.9rc2 and hal-info-20070326 > > These *need* to be split into separate SRPMS. I don't mind > co-maintaining these if you want, but if we are updating machine quirks > once a month or so, then we should be able to update one 100k no-arch > package, rather than 4 or 5 multi-megabyte architecture specific > packages. > > Sorry to harp on about this, but F7T3 is getting closer. I have also asked it in the merge review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225880#c5 -- Pat From hughsient at gmail.com Tue Mar 27 11:14:10 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Mar 2007 12:14:10 +0100 Subject: rawhide report: 20070327 changes In-Reply-To: <4608FAA1.9080903@leemhuis.info> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <1174990111.13483.3.camel@localhost.localdomain> <4608F385.8070602@leemhuis.info> <1174992405.13483.9.camel@localhost.localdomain> <4608FAA1.9080903@leemhuis.info> Message-ID: <1174994050.13483.37.camel@localhost.localdomain> On Tue, 2007-03-27 at 13:06 +0200, Thorsten Leemhuis wrote: > > Well, all this is very new. The very least we will achieve is to get > > screens to turn back on when they come back from suspend, i.e. to > DPMS > > on where needed, and to poke vbetool and restore vbestate. Some > other > > odd quirks like radeontool are present, but completely untested. > > Well, we'll see how it evolves. Anyway: thx for your great work > Richard! No problem. I'm hoping to write a tutorial at some stage (after my finals!) showing how this all works, i.e. adding simple xml file to add stuff like vbestate and vbepost to make resume work. The idea is that people who can't suspend get the systems to work using pm-suspend with the --quirk options, and then send a report (automatically?) so we can add the DMI data in hal-info for the next update. Richard. From jkeating at redhat.com Tue Mar 27 11:22:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Mar 2007 07:22:11 -0400 Subject: Presto logging In-Reply-To: References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> <200703261753.26784.jkeating@redhat.com> Message-ID: <200703270722.16707.jkeating@redhat.com> On Tuesday 27 March 2007 00:59:57 Thomas M Steenholdt wrote: > as long as > he remembers to put a simple date in a file, when he's done. Which calls for special syncing. And there is no guarantee that they'll create the date file before or after the sync, so we'll still have to validate the age of the repomd files. -- 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 Tue Mar 27 11:32:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Mar 2007 07:32:50 -0400 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: <20070327121702.cc573e59.mschwendt.tmp0701.nospam@arcor.de> References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <20070327121702.cc573e59.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200703270732.50642.jkeating@redhat.com> On Tuesday 27 March 2007 06:17:02 Michael Schwendt wrote: > Questionable, albeit would serve as an ugly work-around. It would defeat > the purpose of the dist tag, since if you reused the spec for multiple > branches, it would make the fc5 package obsolete an fc7 package. And the dist tag is just a red herring here. The Version could just have easily been bumped in say FC6 updates after FC7 releases giving you a package in FC6 updates that is nv newer than what which is on the FC7 media. This isn't a new problem, and it isn't an easy problem to fix. Working toward making it easier to do a Fedora install and have it consider the available updates at install time is really the right direction to go, as the update in FC7 should be nvr higher than the same update in FC6. If you can get to it at install/upgrade time it would prevent you from seeing newer packages on your system than what is on the media. -- 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 rdieter at math.unl.edu Tue Mar 27 11:44:32 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Mar 2007 06:44:32 -0500 Subject: hplip: hp-toolbox advertising? References: <1174965859.24384.1.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: > On Mon, 2007-03-26 at 22:16 -0500, Rex Dieter wrote: >> Bernard has a point. Usability issues (e.g. David's comments) isn't an >> excuse for half-hearted packaging. If hplip is in fedora, it ought to be >> packaged properly (.desktop menu, icons, and all). > Blindly following packaging guidelines is not an excuse for poor > usability. David's usability issues have nothing to do with packaging. If you can justify crippling the packaging, fine, but you haven't. -- Rex From buildsys at fedoraproject.org Tue Mar 27 12:03:27 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Tue, 27 Mar 2007 08:03:27 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-27 Message-ID: <20070327120327.EA365152130@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 75 (!) bcm43xx-fwcutter-006-1.fc7 : INVALID rebuild, not published! NEW dirac-0.6.0-9.20070325cvs.fc7 dom4j-1.6.1-2jpp.2.fc7 dvdisaster-0.70.4-2.fc7 NEW elektra-0.6.10-2.fc7 NEW enblend-3.0-4.fc7 ettercap-0.7.3-17.fc7 flac123-0.0.9-6.fc7 gmpc-0.14.0-1.fc7 gnomesword-2.2.3-1.fc7 gourmet-0.13.3-1.fc7 gpodder-0.9.0-1.fc7 gprolog-1.3.0-1.fc7 gscan2pdf-0.9.5-7.fc7 NEW gxine-0.5.11-3.fc7 jaxen-1.1-1jpp.2.fc7 jd-1.8.8-0.3.cvs070326.fc7 NEW keepalived-1.1.13-6.fc7 kerry-0.2.1-2.fc7 kvm-15-2 libburn-0.2.6.3-3.fc7 libhugetlbfs-1.1-1.fc7 libipoddevice-0.5.2-2.fc7 NEW libiptcdata-1.0.1-1.fc7 libmtp-0.1.5-1.fc7 libnetfilter_conntrack-0.0.50-4.fc7 libnfnetlink-0.0.25-2.fc7 libpng10-1.0.21-2.fc7 libreadline-java-0.8.0-17.fc7 libvisual-plugins-0.4.0-3.fc7 livecd-tools-004-1.fc7 NEW macchanger-1.5.0-3.fc7 mailgraph-1.12-5.fc7 maxima-5.11.0-8.fc7 mod_security-2.1.0-2.fc7 muine-0.8.7-3.fc7 nas-1.8b-1.fc7 nginx-0.5.16-1.fc7 ntfs-config-0.5.5-3.fc7 nyquist-2.36-1.fc7 obexftp-0.22-0.2.pre4 openoffice.org-dict-cs_CZ-20060303-5.fc7 openvrml-0.16.3-5.fc7 NEW paragui-1.0.4-3.fc7 NEW perl-Gtk2-Ex-Carp-0.01-3.fc7 perl-Gtk2-Ex-PodViewer-0.17-2.fc7 perl-MIME-Types-1.19-1.fc7 NEW perl-Math-Derivative-0.01-2.fc7 perl-Set-IntSpan-1.11-1.fc7 perl-Text-Wrapper-1.01-1.fc7 NEW perl-XML-Writer-0.602-3.fc7 perl-perlmenu-4.0-4.1.fc7 phpPgAdmin-4.1.1-1.fc7 plplot-5.7.3-1.fc7 pmd-3.6-1jpp.3.fc7 NEW postgresql-dbi-link-2.0.0-3.fc7 pstoedit-3.44-6.fc7 NEW python-html2text-2.26-2.fc7 NEW python-inotify-0.7.0-1.fc7 NEW rss2email-2.60-3.fc7 sbcl-1.0.4-1.fc7 shorewall-3.4.1-2.fc7 squidGuard-1.2.0-15.fc7 suck-4.3.2-14.fc7 syslog-ng-2.0.3-1.fc7 toped-0.8.2-8.fc7 uim-1.4.1-2.fc7 vala-0.0.8-1.fc7 wordpress-2.1.3-0.rc2.fc7 workrave-1.8.4-2.fc7 xdg-user-dirs-0.5-1.fc7 xine-lib-1.1.4-4.fc7 xom-1.0-3jpp.4.fc7 zaptel-1.4.1-4.fc7 zziplib-0.13.49-1.fc7 Packages built and released for Fedora Extras 6: 45 Django-0.96-1.fc6 ctapi-cyberjack-2.0.13-3.fc6 deltarpm-3.4-1.fc6 NEW dirac-0.6.0-9.20070325cvs.fc6 NEW elektra-0.6.10-2.fc6 NEW enblend-3.0-4.fc6 ettercap-0.7.3-17.fc6 gnomesword-2.2.3-1.fc6 gprolog-1.3.0-1.fc6 gscan2pdf-0.9.5-7.fc6 NEW keepalived-1.1.13-6.fc6 kerry-0.2.1-2.fc6 libburn-0.2.6.3-2.fc6 libhugetlbfs-1.1-1.fc6 NEW libiptcdata-1.0.1-1.fc6 libvisual-plugins-0.4.0-3.fc6 NEW macchanger-1.5.0-3.fc6 mailgraph-1.12-5.fc6 maxima-5.11.0-8.fc6 muine-0.8.7-3.fc6 nginx-0.5.16-1.fc6 ntfs-config-0.5.5-3 nyquist-2.36-1.fc6 openvrml-0.16.3-4.fc6 NEW paragui-1.0.4-3.fc6 NEW perl-Gtk2-Ex-Carp-0.01-3.fc6 perl-Gtk2-Ex-PodViewer-0.17-2.fc6 NEW perl-Math-Derivative-0.01-2.fc6 perl-Set-IntSpan-1.11-1.fc6 perl-Text-Wrapper-1.01-1.fc6 NEW perl-XML-Writer-0.602-3.fc6 phpPgAdmin-4.1.1-1.fc6 NEW postgresql-dbi-link-2.0.0-3.fc6 NEW python-html2text-2.26-2.fc6 NEW rss2email-2.60-3.fc6 sbcl-1.0.4-1.fc6 sdcc-2.6.0-9.fc6 shorewall-3.4.1-2.fc6 squidGuard-1.2.0-15.fc6 suck-4.3.2-14.fc6 uim-1.4.1-2.fc6 vala-0.0.8-1.fc6 wordpress-2.1.3-0.rc2.fc6 zaptel-1.4.1-4.fc6 zziplib-0.13.49-1.fc6 Packages built and released for Fedora Extras 5: 27 Django-0.96-1.fc5 ctapi-cyberjack-2.0.13-3.fc5 NEW dirac-0.6.0-9.20070325cvs.fc5 NEW enblend-3.0-4.fc5 ettercap-0.7.3-17.fc5 gnomesword-2.2.3-1.fc5 gprolog-1.3.0-1.fc5 gscan2pdf-0.9.5-7.fc5 NEW keepalived-1.1.13-6.fc5 kerry-0.2.1-2.fc5 NEW libiptcdata-1.0.1-1.fc5 maxima-5.11.0-8.fc5 nginx-0.5.16-1.fc5 NEW perl-Gtk2-Ex-Carp-0.01-3.fc5 perl-Gtk2-Ex-PodViewer-0.17-2.fc5 NEW perl-Math-Derivative-0.01-2.fc5 perl-Text-Wrapper-1.01-1.fc5 NEW perl-XML-Writer-0.602-3.fc5 phpPgAdmin-4.1.1-1.fc5 NEW postgresql-dbi-link-2.0.0-3.fc5 sbcl-1.0.4-1.fc5 shorewall-3.4.1-2.fc5 suck-4.3.2-14.fc5 uim-1.4.1-1.fc5 vala-0.0.8-1.fc5 wordpress-2.1.3-0.rc2.fc5 zziplib-0.13.49-1.fc5 bcm43xx-fwcutter-006-1.fc7 -------------------------- dirac-0.6.0-9.20070325cvs.fc7 ----------------------------- * Sun Mar 25 2007 kwizart < kwizart at gmail.com > - 0.6.0-9.20070325cvs - Update to cvs 20070325 - Remove -Werror for CXXFLAGS and decoder - Fix perms and wrongs end of line encoding * Sun Mar 25 2007 kwizart < kwizart at gmail.com > - 0.6.0-8.20070108cvs - Fix mmx only for x86_64 - Fix ldconfig libs * Sat Mar 24 2007 kwizart < kwizart at gmail.com > - 0.6.0-7.20070108cvs - Cleaned comment - Enabled dirac-libs for multi-libs - Enabled mmx on 64 bit - Fix Perl script create_dirac_testfile.pl dom4j-1.6.1-2jpp.2.fc7 ---------------------- * Mon Mar 26 2007 Nuno Santos - 0:1.6.1-2jpp.2 - fix unowned directory dvdisaster-0.70.4-2.fc7 ----------------------- * Mon Mar 26 2007 Dmitry Butskoy - 0.70.4-2 - own root docdir too (#233832) elektra-0.6.10-2.fc7 -------------------- * Mon Mar 12 2007 kwizart < kwizart at gmail.com > - 0.6.10-2 - Disable static packages * Sat Mar 10 2007 Patrice Dumas 0.6.10-1 - update to 0.6.10 - use canonical scriptlets - minor cleanups - fix kdbd initscript enblend-3.0-4.fc7 ----------------- * Tue Mar 20 2007 Bruno Postle 3.0-4 - patch to build without glew library ettercap-0.7.3-17.fc7 --------------------- * Mon Mar 26 2007 Jon Ciesla - 0.7.3-17 - Provides/obsoletes fixes. * Mon Mar 26 2007 Jon Ciesla - 0.7.3-16 - Merged -plugins into common. - Fixed UI patch from Till Maas. * Sat Mar 24 2007 Manuel Wolfshant - 0.7.3-15 - Unified spec for epel / FC5 / FC6; build for epel is not possible until libnet is made available * Fri Mar 23 2007 Jon Ciesla - 0.7.3-14 - Alternatives fix by Manuel Wolfshant. - Please run rpm -e ettercap ettercap-gtk --noscripts before upgrading. - Bump to unified FC5 compat. flac123-0.0.9-6.fc7 ------------------- * Mon Feb 26 2007 Sindre Pedersen Bj?rdal - 0.0.9-6 - Add fixed patch to really make build work against flac 1.1.3 * Mon Feb 26 2007 Sindre Pedersen Bj?rdal - 0.0.9-3 - Add patch to make build work against flac 1.1.3 * Thu Feb 15 2007 Sindre Pedersen Bj?rdal - 0.0.9-2 - Rebuild against new libflac gmpc-0.14.0-1.fc7 ----------------- * Sun Mar 25 2007 Adrian Reber - 0.14.0-1 - updated to 0.14.0 - added more plugins - fixed #233837 (gmpc-devel: unowned directory) gnomesword-2.2.3-1.fc7 ---------------------- * Sun Mar 25 2007 Deji Akingunola - 2.2.3 - Version 2.2.3 - Configure tweak no longer necesary, gtkhtml38 now in Extras gourmet-0.13.3-1.fc7 -------------------- * Mon Mar 26 2007 Jef Spaleta - 0.13.3-1 - Update to new upstream version gpodder-0.9.0-1.fc7 ------------------- * Mon Mar 26 2007 Jef Spaleta 0.9.0-1 - Update to 0.9.0 release and adjust specfile accordingly gprolog-1.3.0-1.fc7 ------------------- * Sun Mar 25 2007 Jochen Schmitt 1.3.0-1 - New upstream version gscan2pdf-0.9.5-7.fc7 --------------------- * Sun Mar 25 2007 Bernard Johnson - 0.9.5-7 - use perl(...) style requires (bz #233768) - make %{_datadir}/%{name} and owned directory (bz #233839) gxine-0.5.11-3.fc7 ------------------ * Sun Mar 25 2007 Martin Sourada - 0.5.11-3 - fix rpmlint warning * Wed Mar 14 2007 Martin Sourada - 0.5.11-2 - add patch to keep track of window state (backport from 0.6.0 branch) jaxen-1.1-1jpp.2.fc7 -------------------- * Tue Feb 20 2007 Vivek Lakshmanan 0:1.1-1jpp.2.fc7 - Add build-requires on ant-junit jd-1.8.8-0.3.cvs070326.fc7 -------------------------- * Mon Mar 26 2007 Mamoru Tasaka - 1.8.8-0.3.beta070326 - cvs 070326 keepalived-1.1.13-6.fc7 ----------------------- * Mon Mar 26 2007 Matthias Saou 1.1.13-6 - Fix doc/samples/sample.misccheck.smbcheck.sh mode (600 -> 644). * Thu Mar 22 2007 Matthias Saou 1.1.13-5 - Include types patch to fix compile on F7 (David Woodhouse). - Fix up file modes (main binary 700 -> 755 and config 600 -> 640). kerry-0.2.1-2.fc7 ----------------- * Mon Mar 26 2007 Sebastian Vahl 0.2.1-2 - own dir (#233856) - remove some obsolete categories from desktop file kvm-15-2 -------- * Mon Mar 26 2007 Jeremy Katz - 15-2 - add file so that kvm modules get loaded on boot libburn-0.2.6.3-3.fc7 --------------------- * Sun Mar 25 2007 Denis Leroy - 0.2.6.3-3 - Fixed unowned include directory (#233860) libhugetlbfs-1.1-1.fc7 ---------------------- * Mon Mar 26 2007 Steve Fox - 1.1-1 - New release (1.1) - Fix directory ownership libipoddevice-0.5.2-2.fc7 ------------------------- * Sun Mar 25 2007 Christopher Aillon 0.5.2-2 - Own the include directory libiptcdata-1.0.1-1.fc7 ----------------------- * Fri Mar 23 2007 David Moore 1.0.1-1 - New upstream version * Thu Mar 22 2007 David Moore 1.0.0-2 - Fixed URL, removed INSTALL file, fixed python path and timestamps * Wed Mar 21 2007 David Moore 1.0.0-1 - Updated spec file to better match Fedora guidelines libmtp-0.1.5-1.fc7 ------------------ * Mon Mar 26 2007 Linus Walleij 0.1.5-1 - New upstream release. - Candidate for FC5, FC6 backport. - Hopefully API/ABI compatible, testing in devel tree. libnetfilter_conntrack-0.0.50-4.fc7 ----------------------------------- * Sun Mar 25 2007 Paul P. Komkoff Jr - 0.0.50-4 - grab ownership of some directories libnfnetlink-0.0.25-2.fc7 ------------------------- * Sun Mar 25 2007 Paul P. Komkoff Jr - 0.0.25-2 - grab ownership of some directories libpng10-1.0.21-2.fc7 --------------------- * Sun Mar 25 2007 Paul Howarth 1.0.21-2 - Own directory %{_docdir}/%{name}-%{version} (#233869) - Describe license as "zlib/libpng" rather than just "zlib" libreadline-java-0.8.0-17.fc7 ----------------------------- * Mon Mar 26 2007 Thomas Fitzsimmons - 0.8.0-17 - Honor $RPM_OPT_FLAGS. * Mon Mar 26 2007 Thomas Fitzsimmons - 0.8.0-16 - Install jar file and JNI library under libdir. - Group BuildRequires and Requires. - Eliminate devel subpackage. - Remove ldconfig requirements. - Reformat. libvisual-plugins-0.4.0-3.fc7 ----------------------------- * Sun Mar 25 2007 Aurelien Bompard 0.4.0-3 - fix unowned directory (bug 233875) livecd-tools-004-1.fc7 ---------------------- * Mon Mar 26 2007 Jeremy Katz - 004-1 - add livecd-iso-to-disk for setting up the live CD iso image onto a usb stick or similar macchanger-1.5.0-3.fc7 ---------------------- * Sat Mar 24 2007 Damien Durand - 1.5.0-3 - Fix doc section * Sat Mar 24 2007 Damien Durand - 1.5.0-2 - Remove info directory in the install section * Thu Mar 22 2007 Damien Durand - 1.5.0-1 - Initial RPM release mailgraph-1.12-5.fc7 -------------------- * Sun Mar 25 2007 Bernard Johnson - 1.12-5 - require initscripts because initfile uses daemon function - use perl(...) requires (bz #233769) - use /sbin/service instead of invoking initscript directly - one line under %files to own both %{_datadir} and files below it maxima-5.11.0-8.fc7 ------------------- * Mon Mar 26 2007 Rex Dieter 5.11.0-8 - respin for sbcl-1.0.4 mod_security-2.1.0-2.fc7 ------------------------ * Mon Mar 26 2007 Michael Fleming 2.1.0-2 - Fix DSO permissions (bz#233733) mugshot-1.1.39-3.fc7 -------------------- * Mon Mar 26 2007 Owen Taylor - 1.1.39-3 - Fix some minor 64-bit problems * Mon Mar 26 2007 Owen Taylor - 1.1.39-1 - 1.1.39 - Package mugshot.desktop for the menus as well * Fri Mar 23 2007 Owen Taylor - 1.1.38-1 - Create %{_datadir}/mugshot/version at the end of %post to avoid the client prematurely prompting to restart itself * Mon Mar 19 2007 Owen Taylor - 1.1.38-1 - Don't package the .la file for libhippofirefox - Use desktop-file-install to validate mugshot.spec and make the Fedora packaging guidelines happy * Thu Mar 15 2007 Owen Taylor - 1.1.38-1 - Add coments about trademark requirements - 1.1.38 * Thu Mar 01 2007 Owen Taylor - 1.1.37-1 - 1.1.37 * Thu Mar 01 2007 Owen Taylor - 1.1.36-1 - 1.1.36 * Wed Feb 28 2007 Owen Taylor - 1.1.35-1 - 1.1.35 muine-0.8.7-3.fc7 ----------------- * Sun Mar 25 2007 Sindre Pedersen Bj?rdal - 0.8.7-3 - Add unowned directories, fix #233885 nas-1.8b-1.fc7 -------------- * Mon Mar 26 2007 Frank B?ttner - 1.8b-1.fc7 - update to 1.8b nginx-0.5.16-1.fc7 ------------------ * Mon Mar 26 2007 Jeremy Hinegardner - 0.5.16-1 - Update to 0.5.16 - add ownership of /usr/share/nginx/html (#233950) ntfs-config-0.5.5-3.fc7 ----------------------- * Sun Mar 25 2007 Xavier Lamien - 0.5.5-3 - Fixed default permission for executable file. - Updated url source from upstream. nyquist-2.36-1.fc7 ------------------ * Sun Mar 25 2007 Gerard Milmeister - 2.36-1 - new version 2.36 obexftp-0.22-0.2.pre4 --------------------- * Mon Mar 26 2007 Dominik Mierzejewski - 0.22-0.2.pre4 - fix segfault in obexftpd (patch by Jan Kratochvil), closes (#230991) openoffice.org-dict-cs_CZ-20060303-5.fc7 ---------------------------------------- * Tue Mar 27 2007 Tomas Mraz - 20060303-5 - add hunspell-cs subpackage (#232416) - openoffice datadir moved again openvrml-0.16.3-5.fc7 --------------------- * Sun Mar 25 2007 Braden McDaniel - 0.16.3-5 - Updated firefox dependency to 2.0.0.3. paragui-1.0.4-3.fc7 ------------------- * Sat Mar 24 2007 Hans de Goede 1.0.4-3 - Fix building of python bindings when paragui isn't installed already, for example when building under mock (bz 233140) * Sat Mar 24 2007 Hans de Goede 1.0.4-2 - Various specfile improvements (bz 233140) * Sun Mar 18 2007 Hans de Goede 1.0.4-1 - Initial Fedora Extras package based on specfile by Che (newrpms) perl-Gtk2-Ex-Carp-0.01-3.fc7 ---------------------------- * Mon Mar 26 2007 Chris Weyl 0.01-3 - bump * Fri Mar 23 2007 Chris Weyl 0.01-2 - test for $DISPLAY before running make test * Wed Mar 21 2007 Chris Weyl 0.01-1 - Specfile autogenerated by cpanspec 1.70. perl-Gtk2-Ex-PodViewer-0.17-2.fc7 --------------------------------- * Sun Mar 25 2007 Bernard Johnson - 0.17-2 - use perl(...) style requires (bz #233767) perl-Math-Derivative-0.01-2.fc7 ------------------------------- * Sun Mar 25 2007 Alex Lancaster 0.01-2 - Add perl(ExtUtils::MakeMaker) BR as suggested by Chris Weyl in review. * Fri Mar 23 2007 Alex Lancaster 0.01-1 - Specfile autogenerated by cpanspec 1.69.1. perl-MIME-Types-1.19-1.fc7 -------------------------- * Mon Mar 26 2007 Ville Skytt? - 1.19-1 - 1.19. - BuildRequire perl(ExtUtils::MakeMaker). perl-perlmenu-4.0-4.1.fc7 ------------------------- * Fri Jan 26 2007 Parag Nemade - 4.0-4 - Added pactch to enable getcap for perl5 for bug rh#233541 perl-Set-IntSpan-1.11-1.fc7 --------------------------- * Sun Mar 25 2007 Ville Skytt? - 1.11-1 - 1.11. perl-Text-Wrapper-1.01-1.fc7 ---------------------------- * Tue Mar 27 2007 Ralf Cors?pius - 1.01-1 - Upstream update. - BR: perl(Module::Build::Compat). perl-XML-Writer-0.602-3.fc7 --------------------------- * Mon Mar 26 2007 Alex Lancaster 0.602-3 - Fixed %check * Fri Mar 23 2007 Alex Lancaster 0.602-2 - Update BR as per suggestions from review by Ralf Corsepius * Fri Mar 23 2007 Alex Lancaster 0.602-1 - Update to 0.602 phpPgAdmin-4.1.1-1.fc7 ---------------------- * Mon Mar 26 2007 Devrim Gunduz 4.1.1-1 - Update to 4.1.1 - Fix for Red Hat Bugzilla #233902 plplot-5.7.3-1.fc7 ------------------ * Mon Mar 26 2007 - Orion Poplawski - 5.7.3-1 - Update to 5.7.3 - Hack to run itcl examples - Install Java JNI into %{_libdir}/plplot%{_version} - java package requires java (bug #233905) - devel requires main package (bug #233905) - Enable octave api requirement - Enable new ada interface - not installed yet though - Renaable pstex driver * Tue Mar 20 2007 - Orion Poplawski - 5.7.2-4 - Set PREBUILT_DOC so docs are installed * Wed Mar 14 2007 - Orion Poplawski - 5.7.2-3 - Fix up tclIndex files so they are the same on all builds (bug #228172) - Fix up examples/tk/Makefile for multilib (bug #228172) - Install python in arch specific dirs (bug #228173) - Enable itcl - Update to CVS * Fri Feb 09 2007 - Orion Poplawski - 5.7.2-2 - Rebuild for Tcl 8.5 pmd-3.6-1jpp.3.fc7 ------------------ * Mon Mar 26 2007 Matt Wringe - 0:3.6-1jpp.3 - Fix unowned doc directory for pmd postgresql-dbi-link-2.0.0-3.fc7 ------------------------------- pstoedit-3.44-6.fc7 ------------------- * Sun Mar 25 2007 Denis Leroy - 3.44-6 - Added patch to add -quiet option python-html2text-2.26-2.fc7 --------------------------- * Sat Mar 24 2007 Thorsten Leemhuis - 2.26-2 - Use sed instead of dos2unix * Sat Mar 24 2007 Thorsten Leemhuis - 2.26-1 - Initial package python-inotify-0.7.0-1.fc7 -------------------------- * Tue Mar 06 2007 Terje Rosten - 0.7.0-1 - Initial build rss2email-2.60-3.fc7 -------------------- * Sat Mar 24 2007 Thorsten Leemhuis - 2.60-3 - Use sed instead of dos2unix - Some small fixes from review bug #233715 - Apply one patch from Debian that should warn if there are problems with local delivery via sendmail * Sat Mar 24 2007 Thorsten Leemhuis - 2.60-2 - Seperate package for html2text, as it might be useful for other stuff as well - update r2e and make it possible to manage different feed files (optional, use r2e option "--feedext foo" to use it) - add some common used, but-no-so-well documented configuration parameters to config.py template and give a hint where to find docs what they do * Fri Mar 23 2007 Thorsten Leemhuis - 2.60-1 - Initial package sbcl-1.0.4-1.fc7 ---------------- * Mon Mar 26 2007 Rex Dieter 1.0.4-1 - sbcl-1.0.4 shorewall-3.4.1-2.fc7 --------------------- * Mon Mar 26 2007 Robert Marcano - 3.4.1-1 - Update to upstream 3.4.1 squidGuard-1.2.0-15.fc7 ----------------------- * Mon Mar 26 2007 John Berninger 1.2.0-15 - Assert ownership of /var/squidGuard - bz 233915 suck-4.3.2-14.fc7 ----------------- * Sun Mar 25 2007 Jochen Schmitt 4.3.2-14 - Add parallel build putch syslog-ng-2.0.3-1.fc7 --------------------- * Mon Mar 26 2007 Jose Pedro Oliveira - 2.0.3-1 - Update to 2.0.3. toped-0.8.2-8.fc7 ----------------- * Mon Feb 26 2007 Chitlesh Goorah - 0.8.2-8 - fixed for rawhide compat-wxGTK26 * Fri Dec 29 2006 Chitlesh Goorah - 0.8.2-7 - patch for wxWidgets-2.8 * Mon Dec 25 2006 Chitlesh Goorah - 0.8.2-6 - Fixed fedora vendor * Mon Dec 25 2006 Chitlesh Goorah - 0.8.2-5 - Rebuild for development * Mon Dec 25 2006 Chitlesh Goorah - 0.8.2-4 - Fixed kmenu desktop file to science menu * Sun Dec 24 2006 Chitlesh Goorah - 0.8.2-3 - FC6 rebuilt - removed fedora vendor uim-1.4.1-2.fc7 --------------- * Mon Mar 26 2007 Akira TAGOH - 1.4.1-2 - Own %{_libdir}/uim/plugin. (#233817) vala-0.0.8-1.fc7 ---------------- * Sun Mar 25 2007 Michel Salim - 0.0.8-1 - Update to 0.0.8 * Wed Mar 07 2007 Michel Salim - 0.0.7-1 - Update to 0.0.7 * Wed Feb 28 2007 Michel Salim - 0.0.6-1 - Update to 0.0.6 wordpress-2.1.3-0.rc2.fc7 ------------------------- * Mon Mar 26 2007 John Berninger - 2.1.3-rc2 - update to 2.1.3rc2 for bz 233703 workrave-1.8.4-2.fc7 -------------------- * Mon Mar 26 2007 Tomas Mraz - 1.8.4-2 - new upstream version - add datadir/pixmaps/workrave to files (#233815) xdg-user-dirs-0.5-1.fc7 ----------------------- * Mon Mar 26 2007 Alexander Larsson - 0.5-1 - update to 0.5 (more translations) xine-lib-1.1.4-4.fc7 -------------------- * Mon Mar 26 2007 Ville Skytt? - 1.1.4-4 - Add PulseAudio support (in -extras, #234035/Jost Diederichs). - Adjust Samba build dependencies to work for both <= and > FC6. - Add --with freetype and --with antialiasing build time options, default disabled, and an upstream patch for FreeType memory leak (#233194). xom-1.0-3jpp.4.fc7 ------------------ * Mon Mar 26 2007 Nuno Santos 0:1.0-3jpp.4.fc7 - Apply patch from bugs.michael at gmx.net to fix unowned directory zaptel-1.4.1-4.fc7 ------------------ * Mon Mar 26 2007 Jeffrey C. Ollie - 1.4.1-4 - Own /usr/include/zaptel, fixes #233970. zziplib-0.13.49-1.fc7 --------------------- * Mon Mar 26 2007 Matthias Saou 0.13.49-1 - Update to 0.13.49 to fix CVE-2007-1614 (rhbz #233700). - Include new man3 pages to the devel sub-package. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From skvidal at linux.duke.edu Tue Mar 27 12:26:43 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 27 Mar 2007 08:26:43 -0400 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174991391.19925.116.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> <1174941261.30355.32.camel@cutter> <20070327100542.GA4814@suse.de> <1174991391.19925.116.camel@jndwidescreen.lesbg.loc> Message-ID: <1174998403.30355.43.camel@cutter> On Tue, 2007-03-27 at 13:29 +0300, Jonathan Dieter wrote: > On Tue, 2007-03-27 at 12:05 +0200, Michael Schroeder wrote: > > On Mon, Mar 26, 2007 at 04:34:21PM -0400, seth vidal wrote: > > > 1. why are you using md5sum and not sha1sums? > > > > It checks if the md5sum of the file matches the sum from the rpm > > header. > > > > It works basically like this: The "sequence" tells applydeltarpm > > which of the files from the rpm header were used to create the > > deltarpm and the order of those files (thus the name "sequence" > > in case you wondered). makedeltarpm doesn't use all files to > > create the delta, config files and files that have the "verify" > > bit off get excluded. If you ask applydeltarpm to check if a > > deltarpm can be applied it uses this sequence to verify that all > > used files are unchanged, either by just checking the size (the > > fast method) or by checking the md5sum (like rpm does). > > The fast method makes sense if the updater has a fallback to > > fetch the complete rpm if applydeltarpm failes, as in most cases > > files are unchanged if the size is the same. > > > > Cheers, > > Michael. > > > And I changed Presto last night to use the full method, rather than the > fast method. Our fallback method is pretty lousy (exiting with an > error, working the second time yum is called), at least for the moment. > Why is that? I need to take a look at the code but there doesn't seem to be any reason why it shouldn't be able to fall back to downloading the whole package. It knows where it is. -sv From tmus at tmus.dk Tue Mar 27 12:35:46 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 27 Mar 2007 14:35:46 +0200 Subject: Initscripts and LSB compliance In-Reply-To: <20070327080309.GX355@devserv.devel.redhat.com> References: <4608CCFD.5040600@redhat.com> <20070327080309.GX355@devserv.devel.redhat.com> Message-ID: Jakub Jelinek wrote: > On Tue, Mar 27, 2007 at 09:51:25AM +0200, Michal Marciniszyn wrote: >> due to my recent investigations, nearly none of the initscripts that we >> have included in RHEL/Fedora are LSB (Linux Standard Base) compliant. >> I'm not talking about problems with %config stuff, but about the >> functionality of the scripts. Main problems are constructions like > > Why does this matter? The init scripts in RHEL/Fedora aren't meant to be > run on any LSB compliant distro, they are meant to be run on RHEL/Fedora. > All we should care is that you can install a LSB compliant application > on our distro and that it's LSB compliant init script will work as > required by LSB. > LSB is a standard that we should follow as closely as it makes sense (at least). In this case it makes perfect sense to obey the LSB rules, as that would make all our initscripts behave in the same way for the same results. >> [ -f /etc/service_conffile ] || exit 0 > > The fewer commands the script runs the shorter is the startup time, > something we really care about. > Returning the right value for a given error is not something that with hit you with a performance penalty. :o) /Thomas From jkeating at redhat.com Tue Mar 27 12:46:19 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Mar 2007 08:46:19 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174965859.24384.1.camel@localhost.localdomain> Message-ID: <200703270846.19935.jkeating@redhat.com> On Tuesday 27 March 2007 07:44:32 Rex Dieter wrote: > David's usability issues have nothing to do with packaging. ? > If you can justify crippling the packaging, fine, but you haven't. Removing a company logo from the menu is a pretty good reason I think. If a new icon was provided that wasn't advertisement for HP there would be less resistance to having it in the menu. -- 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 buildsys at fedoraproject.org Tue Mar 27 12:49:42 2007 From: buildsys at fedoraproject.org (Fedora Extras repoclosure) Date: Tue, 27 Mar 2007 12:49:42 -0000 Subject: Summary - Broken dependencies in Fedora Extras - 2007-03-27 Message-ID: <20070327124942.17654.49220@extras64.linux.duke.edu> New report for: overholt AT redhat.com package: jython - 2.2-0.3.Release_2_2beta1.1jpp.2.fc7.i386 from fedora-extras-development-i386 unresolved deps: libreadline-java-devel package: jython - 2.2-0.3.Release_2_2beta1.1jpp.2.fc7.ppc from fedora-extras-development-ppc unresolved deps: libreadline-java-devel package: jython - 2.2-0.3.Release_2_2beta1.1jpp.2.fc7.x86_64 from fedora-extras-development-x86_64 unresolved deps: libreadline-java-devel ====================================================================== Summary of broken packages (by owner): Jochen AT herr-schmitt.de pdftk - 1.41-3.fc7.i386 (27 days) pdftk - 1.41-3.fc7.ppc (27 days) pdftk - 1.41-3.fc7.x86_64 (27 days) dcbw AT redhat.com csound - 5.03.0-9.fc7.i386 (109 days) csound - 5.03.0-9.fc7.i386 (109 days) csound - 5.03.0-9.fc7.ppc (109 days) csound - 5.03.0-9.fc7.x86_64 (109 days) csound-python - 5.03.0-9.fc7.i386 (109 days) csound-python - 5.03.0-9.fc7.ppc (109 days) csound-python - 5.03.0-9.fc7.x86_64 (109 days) enrico.scholz AT informatik.tu-chemnitz.de tor-core - 0.1.1.26-3.fc7.i386 (16 days) tor-core - 0.1.1.26-3.fc7.ppc (16 days) tor-core - 0.1.1.26-3.fc7.x86_64 (16 days) giallu AT gmail.com kmod-sysprof - 1.0.8-1.2.6.20_1.3017.fc7.i586 kmod-sysprof - 1.0.8-1.2.6.20_1.3017.fc7.i686 kmod-sysprof - 1.0.8-1.2.6.20_1.3017.fc7.x86_64 kmod-sysprof-PAE - 1.0.8-1.2.6.20_1.3017.fc7.i686 kmod-sysprof-kdump - 1.0.8-1.2.6.20_1.3017.fc7.x86_64 karlthered AT gmail.com gtkmozembedmm - 1.4.2.cvs20060817-9.fc7.i386 (2 days) gtkmozembedmm - 1.4.2.cvs20060817-9.fc7.i386 (2 days) gtkmozembedmm - 1.4.2.cvs20060817-9.fc7.ppc (2 days) gtkmozembedmm - 1.4.2.cvs20060817-9.fc7.x86_64 (2 days) limb AT jcomserv.net ettercap-plugins - 0.7.3-14.fc5.3.i386 ettercap-plugins - 0.7.3-14.fc5.3.ppc ettercap-plugins - 0.7.3-14.fc5.3.x86_64 overholt AT redhat.com jython - 2.2-0.3.Release_2_2beta1.1jpp.2.fc7.i386 jython - 2.2-0.3.Release_2_2beta1.1jpp.2.fc7.ppc jython - 2.2-0.3.Release_2_2beta1.1jpp.2.fc7.x86_64 petersen AT redhat.com ghc66-gtk2hs-mozembed - 0.9.10.2-0.1.fc6.i386 (5 days) ghc66-gtk2hs-mozembed - 0.9.10.2-0.1.fc6.ppc (5 days) ghc66-gtk2hs-mozembed - 0.9.10.2-0.1.fc6.x86_64 (5 days) rdieter AT math.unl.edu k3b-extras - 0.12.17-1.fc6.i386 (38 days) k3b-extras - 0.12.17-1.fc6.ppc (38 days) k3b-extras - 0.12.17-1.fc6.x86_64 (38 days) ryo-dairiki AT users.sourceforge.net libtomoe-gtk - 0.5.1-1.fc7.i386 (14 days) libtomoe-gtk - 0.5.1-1.fc7.i386 (14 days) libtomoe-gtk - 0.5.1-1.fc7.ppc (14 days) libtomoe-gtk - 0.5.1-1.fc7.x86_64 (14 days) steve AT silug.org qtparted - 0.4.5-13.fc7.i386 (6 days) qtparted - 0.4.5-13.fc7.ppc (6 days) qtparted - 0.4.5-13.fc7.x86_64 (6 days) stickster AT gmail.com xmldiff - 0.6.7-12.fc6.i386 (109 days) xmldiff - 0.6.7-12.fc6.ppc (109 days) xmldiff - 0.6.7-12.fc6.x86_64 (109 days) tscherf AT redhat.com Democracy - 0.9.5.1-6.fc7.i386 (2 days) Democracy - 0.9.5.1-6.fc7.ppc (2 days) Democracy - 0.9.5.1-6.fc7.x86_64 (2 days) ville.skytta AT iki.fi kmod-em8300 - 0.16.1-7.2.6.20_1.2997.fc7.i586 (7 days) kmod-em8300 - 0.16.1-7.2.6.20_1.2997.fc7.i686 (7 days) kmod-em8300 - 0.16.1-7.2.6.20_1.2997.fc7.ppc (7 days) kmod-em8300 - 0.16.1-7.2.6.20_1.2997.fc7.x86_64 (7 days) kmod-em8300-PAE - 0.16.1-7.2.6.20_1.2997.fc7.i686 (7 days) kmod-em8300-kdump - 0.16.1-7.2.6.20_1.2997.fc7.x86_64 (7 days) kmod-em8300-smp - 0.16.1-7.2.6.20_1.2997.fc7.ppc (7 days) ====================================================================== Broken packages in fedora-extras-5-i386: ettercap-plugins-0.7.3-14.fc5.3.i386 requires ettercap-common = 0:0.7.3-14.fc5.3 ====================================================================== Broken packages in fedora-extras-5-ppc: ettercap-plugins-0.7.3-14.fc5.3.ppc requires ettercap-common = 0:0.7.3-14.fc5.3 ====================================================================== Broken packages in fedora-extras-5-x86_64: ettercap-plugins-0.7.3-14.fc5.3.x86_64 requires ettercap-common = 0:0.7.3-14.fc5.3 ====================================================================== Broken packages in fedora-extras-6-i386: ghc66-gtk2hs-mozembed-0.9.10.2-0.1.fc6.i386 requires ghc66-gtk2hs = 0:0.9.10.2-0.1.fc6 ====================================================================== Broken packages in fedora-extras-6-ppc: ghc66-gtk2hs-mozembed-0.9.10.2-0.1.fc6.ppc requires ghc66-gtk2hs = 0:0.9.10.2-0.1.fc6 ====================================================================== Broken packages in fedora-extras-6-x86_64: ghc66-gtk2hs-mozembed-0.9.10.2-0.1.fc6.x86_64 requires ghc66-gtk2hs = 0:0.9.10.2-0.1.fc6 ====================================================================== Broken packages in fedora-extras-development-i386: Democracy-0.9.5.1-6.fc7.i386 requires firefox = 0:2.0.0.2 csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.i386 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 gtkmozembedmm-1.4.2.cvs20060817-9.fc7.i386 requires gecko-libs = 0:1.8.1.2 jython-2.2-0.3.Release_2_2beta1.1jpp.2.fc7.i386 requires libreadline-java-devel k3b-extras-0.12.17-1.fc6.i386 requires libk3bdevice.so.2 k3b-extras-0.12.17-1.fc6.i386 requires libk3b.so.2 kmod-em8300-0.16.1-7.2.6.20_1.2997.fc7.i586 requires kernel-i586 = 0:2.6.20-1.2997.fc7 kmod-em8300-0.16.1-7.2.6.20_1.2997.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2997.fc7 kmod-em8300-PAE-0.16.1-7.2.6.20_1.2997.fc7.i686 requires kernel-i686 = 0:2.6.20-1.2997.fc7PAE kmod-sysprof-1.0.8-1.2.6.20_1.3017.fc7.i586 requires kernel-i586 = 0:2.6.20-1.3017.fc7 kmod-sysprof-1.0.8-1.2.6.20_1.3017.fc7.i686 requires kernel-i686 = 0:2.6.20-1.3017.fc7 kmod-sysprof-PAE-1.0.8-1.2.6.20_1.3017.fc7.i686 requires kernel-i686 = 0:2.6.20-1.3017.fc7PAE libtomoe-gtk-0.5.1-1.fc7.i386 requires libgucharmap.so.5 pdftk-1.41-3.fc7.i386 requires libgcj.so.7rh qtparted-0.4.5-13.fc7.i386 requires libparted-1.8.so.5 tor-core-0.1.1.26-3.fc7.i386 requires libevent-1.2a.so.1 xmldiff-0.6.7-12.fc6.i386 requires python(abi) = 0:2.4 xmldiff-0.6.7-12.fc6.i386 requires python-abi = 0:2.4 ====================================================================== Broken packages in fedora-extras-development-ppc: Democracy-0.9.5.1-6.fc7.ppc requires firefox = 0:2.0.0.2 csound-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 csound-python-5.03.0-9.fc7.ppc requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.ppc requires libpython2.4.so.1.0 gtkmozembedmm-1.4.2.cvs20060817-9.fc7.ppc requires gecko-libs = 0:1.8.1.2 jython-2.2-0.3.Release_2_2beta1.1jpp.2.fc7.ppc requires libreadline-java-devel k3b-extras-0.12.17-1.fc6.ppc requires libk3bdevice.so.2 k3b-extras-0.12.17-1.fc6.ppc requires libk3b.so.2 kmod-em8300-0.16.1-7.2.6.20_1.2997.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2997.fc7 kmod-em8300-smp-0.16.1-7.2.6.20_1.2997.fc7.ppc requires kernel-ppc = 0:2.6.20-1.2997.fc7smp libtomoe-gtk-0.5.1-1.fc7.ppc requires libgucharmap.so.5 pdftk-1.41-3.fc7.ppc requires libgcj.so.7rh qtparted-0.4.5-13.fc7.ppc requires libparted-1.8.so.5 tor-core-0.1.1.26-3.fc7.ppc requires libevent-1.2a.so.1 xmldiff-0.6.7-12.fc6.ppc requires python(abi) = 0:2.4 xmldiff-0.6.7-12.fc6.ppc requires python-abi = 0:2.4 ====================================================================== Broken packages in fedora-extras-development-x86_64: Democracy-0.9.5.1-6.fc7.x86_64 requires firefox = 0:2.0.0.2 csound-5.03.0-9.fc7.i386 requires libpython2.4.so.1.0 csound-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) csound-python-5.03.0-9.fc7.x86_64 requires python(abi) = 0:2.4 csound-python-5.03.0-9.fc7.x86_64 requires libpython2.4.so.1.0()(64bit) gtkmozembedmm-1.4.2.cvs20060817-9.fc7.i386 requires gecko-libs = 0:1.8.1.2 gtkmozembedmm-1.4.2.cvs20060817-9.fc7.x86_64 requires gecko-libs = 0:1.8.1.2 jython-2.2-0.3.Release_2_2beta1.1jpp.2.fc7.x86_64 requires libreadline-java-devel k3b-extras-0.12.17-1.fc6.x86_64 requires libk3bdevice.so.2()(64bit) k3b-extras-0.12.17-1.fc6.x86_64 requires libk3b.so.2()(64bit) kmod-em8300-0.16.1-7.2.6.20_1.2997.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2997.fc7 kmod-em8300-kdump-0.16.1-7.2.6.20_1.2997.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.2997.fc7kdump kmod-sysprof-1.0.8-1.2.6.20_1.3017.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.3017.fc7 kmod-sysprof-kdump-1.0.8-1.2.6.20_1.3017.fc7.x86_64 requires kernel-x86_64 = 0:2.6.20-1.3017.fc7kdump libtomoe-gtk-0.5.1-1.fc7.i386 requires libgucharmap.so.5 libtomoe-gtk-0.5.1-1.fc7.x86_64 requires libgucharmap.so.5()(64bit) pdftk-1.41-3.fc7.x86_64 requires libgcj.so.7rh()(64bit) qtparted-0.4.5-13.fc7.x86_64 requires libparted-1.8.so.5()(64bit) tor-core-0.1.1.26-3.fc7.x86_64 requires libevent-1.2a.so.1()(64bit) xmldiff-0.6.7-12.fc6.x86_64 requires python-abi = 0:2.4 xmldiff-0.6.7-12.fc6.x86_64 requires python(abi) = 0:2.4 From twaugh at redhat.com Tue Mar 27 12:51:37 2007 From: twaugh at redhat.com (Tim Waugh) Date: Tue, 27 Mar 2007 13:51:37 +0100 Subject: hplip: hp-toolbox advertising? In-Reply-To: <200703270846.19935.jkeating@redhat.com> References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> Message-ID: <1174999897.7507.25.camel@cyberelk.elk> On Tue, 2007-03-27 at 08:46 -0400, Jesse Keating wrote: > On Tuesday 27 March 2007 07:44:32 Rex Dieter wrote: > > David's usability issues have nothing to do with packaging. > > If you can justify crippling the packaging, fine, but you haven't. > > Removing a company logo from the menu is a pretty good reason I think. If a > new icon was provided that wasn't advertisement for HP there would be less > resistance to having it in the menu. How about /usr/share/hplip/data/images/default_printer.png? Tim. */ -------------- 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 jwboyer at jdub.homelinux.org Tue Mar 27 13:05:11 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 27 Mar 2007 08:05:11 -0500 Subject: hplip: hp-toolbox advertising? In-Reply-To: <200703270846.19935.jkeating@redhat.com> References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> Message-ID: <1175000711.7553.6.camel@zod.rchland.ibm.com> On Tue, 2007-03-27 at 08:46 -0400, Jesse Keating wrote: > On Tuesday 27 March 2007 07:44:32 Rex Dieter wrote: > > David's usability issues have nothing to do with packaging. > > If you can justify crippling the packaging, fine, but you haven't. > > Removing a company logo from the menu is a pretty good reason I think. If a > new icon was provided that wasn't advertisement for HP there would be less > resistance to having it in the menu. I'd like to point out that there is likely a trademark issue involved here as well. Unless the package has an explicit grant to display the HP trademark even if patches are made, I'm sure it'll get sticky. That might be a bit easier to swallow than "free advertisement". josh From rdieter at math.unl.edu Tue Mar 27 13:08:07 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Mar 2007 08:08:07 -0500 Subject: Summary - Broken dependencies in Fedora Extras - 2007-03-27 References: <20070327124942.17654.49220@extras64.linux.duke.edu> Message-ID: Fedora Extras repoclosure wrote: > rdieter AT math.unl.edu > k3b-extras - 0.12.17-1.fc6.i386 (38 days) > k3b-extras - 0.12.17-1.fc6.ppc (38 days) > k3b-extras - 0.12.17-1.fc6.x86_64 (38 days) Should be removed from the repo, posted Mar 22: http://fedoraproject.org/wiki/PackageMaintainers/RepoRequests -- Rex From mschwendt.tmp0701.nospam at arcor.de Tue Mar 27 13:12:30 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 27 Mar 2007 15:12:30 +0200 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: <20070327110837.GE2896@free.fr> References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <20070327121702.cc573e59.mschwendt.tmp0701.nospam@arcor.de> <20070327110837.GE2896@free.fr> Message-ID: <20070327151230.80f56c6a.mschwendt.tmp0701.nospam@arcor.de> On Tue, 27 Mar 2007 13:08:37 +0200, Patrice Dumas wrote: > On Tue, Mar 27, 2007 at 12:17:02PM +0200, Michael Schwendt wrote: > > On Tue, 27 Mar 2007 11:28:10 +0200, Patrice Dumas wrote: > > > > > > I suggest hardcoding the %{dist} to what it was when the package was > > > merged (so I guess it is fc7 here). For the fc6 and fc5 packages it > > > is not as clear, but I guess that using fc7 too would be safer. > > > > Questionable, albeit would serve as an ugly work-around. It would defeat > > the purpose of the dist tag, since if you reused the spec for multiple > > branches, it would make the fc5 package obsolete an fc7 package. > > Indeed, that's why I think what to do isn't really clear. 2 points > if favor of having fc7 in all the specs is that it is really the 'latest' > version shipped in fedora, and it can be the same for all the branches. > Using %{dist} will get wrong when it becomes fc8. > > Maybe a solution could be to skip a release and obsolete that release > without dist tag. For example: > foo-0-4%{?dist} is the latest version with the subpackage foo-sub. > next package is foo-0-6%{?dist} and in this package and above there is > Obsolete: foo-sub <= 0-5 > > Maybe another possibility could be to use > Obsoletes: ettercap-plugins < 0.7.3-15 > Would that work? Yes. It would cover all the minor releases, too, which are > 14%{?dist}: ettercap-plugins - 0.7.3-14.fc5.3.i386 ettercap-plugins - 0.7.3-14.fc5.3.ppc ettercap-plugins - 0.7.3-14.fc5.3.x86_64 From mschwendt.tmp0701.nospam at arcor.de Tue Mar 27 13:15:20 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Tue, 27 Mar 2007 15:15:20 +0200 Subject: k3b-extras (Re: Summary - Broken dependencies in Fedora Extras - 2007-03-27) In-Reply-To: References: <20070327124942.17654.49220@extras64.linux.duke.edu> Message-ID: <20070327151520.2bfaf712.mschwendt.tmp0701.nospam@arcor.de> On Tue, 27 Mar 2007 08:08:07 -0500, Rex Dieter wrote: > Fedora Extras repoclosure wrote: > > > rdieter AT math.unl.edu > > k3b-extras - 0.12.17-1.fc6.i386 (38 days) > > k3b-extras - 0.12.17-1.fc6.ppc (38 days) > > k3b-extras - 0.12.17-1.fc6.x86_64 (38 days) > > Should be removed from the repo, posted Mar 22: > http://fedoraproject.org/wiki/PackageMaintainers/RepoRequests k3b still doesn't contain the corresponding "Obsoletes". From hughsient at gmail.com Tue Mar 27 13:13:15 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Mar 2007 14:13:15 +0100 Subject: rawhide report: 20070327 changes In-Reply-To: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> Message-ID: <1175001195.15998.4.camel@localhost.localdomain> On Tue, 2007-03-27 at 06:03 -0400, buildsys at redhat.com wrote: > Updated Packages: Also, are we going to rebuild dbus without asserts for F7T3? Richard. From tla at rasmil.dk Tue Mar 27 13:25:08 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Tue, 27 Mar 2007 15:25:08 +0200 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174998403.30355.43.camel@cutter> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> <1174941261.30355.32.camel@cutter> <20070327100542.GA4814@suse.de> <1174991391.19925.116.camel@jndwidescreen.lesbg.loc> <1174998403.30355.43.camel@cutter> Message-ID: <46091B34.6070002@rasmil.dk> seth vidal wrote: > On Tue, 2007-03-27 at 13:29 +0300, Jonathan Dieter wrote: > >> On Tue, 2007-03-27 at 12:05 +0200, Michael Schroeder wrote: >> >>> On Mon, Mar 26, 2007 at 04:34:21PM -0400, seth vidal wrote: >>> >>>> 1. why are you using md5sum and not sha1sums? >>>> >>> It checks if the md5sum of the file matches the sum from the rpm >>> header. >>> >>> It works basically like this: The "sequence" tells applydeltarpm >>> which of the files from the rpm header were used to create the >>> deltarpm and the order of those files (thus the name "sequence" >>> in case you wondered). makedeltarpm doesn't use all files to >>> create the delta, config files and files that have the "verify" >>> bit off get excluded. If you ask applydeltarpm to check if a >>> deltarpm can be applied it uses this sequence to verify that all >>> used files are unchanged, either by just checking the size (the >>> fast method) or by checking the md5sum (like rpm does). >>> The fast method makes sense if the updater has a fallback to >>> fetch the complete rpm if applydeltarpm failes, as in most cases >>> files are unchanged if the size is the same. >>> >>> Cheers, >>> Michael. >>> >>> >> And I changed Presto last night to use the full method, rather than the >> fast method. Our fallback method is pretty lousy (exiting with an >> error, working the second time yum is called), at least for the moment. >> >> > > Why is that? I need to take a look at the code but there doesn't seem to > be any reason why it shouldn't be able to fall back to downloading the > whole package. It knows where it is. > > -sv > > I look at the code, it works in the following way: postresolve_hook(conduit): for each po to be install in TransactionSet: check if delta as available. make the po point to the delta insted of the full rpm. normal yum downloading (yum.downloadPkg) postdownload_hook(conduit): for each pkg in the downloadpackages: if pkg is a delta: try: build the full rpm from the delta except: Something is rotten in the state of Denmark, bail out. if could be changed to: predownload_hook(conduit,pkglist): for each po in pkglist: if as delta is available: try: download the delta (copy the download code from yum.downloadPkgs) build the full rpm. set po.pkgtype = 'local' # To make yum skip it in the normal download. except: Something is rotten in the state of Denmark, just leave the po unchanged an yum will handle the download as normal. normal yum downloading (yum.downloadPkg) will download all the packages not processed without error, by the predownload_hook. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.w.r.degoede at hhs.nl Tue Mar 27 13:49:30 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 27 Mar 2007 15:49:30 +0200 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175000711.7553.6.camel@zod.rchland.ibm.com> References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> Message-ID: <460920EA.3030503@hhs.nl> Josh Boyer wrote: > On Tue, 2007-03-27 at 08:46 -0400, Jesse Keating wrote: >> On Tuesday 27 March 2007 07:44:32 Rex Dieter wrote: >>> David's usability issues have nothing to do with packaging. >>> If you can justify crippling the packaging, fine, but you haven't. >> Removing a company logo from the menu is a pretty good reason I think. If a >> new icon was provided that wasn't advertisement for HP there would be less >> resistance to having it in the menu. > > I'd like to point out that there is likely a trademark issue involved > here as well. Unless the package has an explicit grant to display the > HP trademark even if patches are made, I'm sure it'll get sticky. > > That might be a bit easier to swallow than "free advertisement". > And how is not having a menu entry actually solving ANY trademark problem? So its ok to ship gnometris to as long as we don't put it in the menu? Regards, Hans From pertusus at free.fr Tue Mar 27 13:33:02 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 27 Mar 2007 15:33:02 +0200 Subject: Initscripts and LSB compliance In-Reply-To: <4608CCFD.5040600@redhat.com> References: <4608CCFD.5040600@redhat.com> Message-ID: <20070327133302.GA2888@free.fr> On Tue, Mar 27, 2007 at 09:51:25AM +0200, Michal Marciniszyn wrote: > Hi, > > Our first step should be to produce guidelines (we have some for RHEL, > but they are not obeyed), then force the developers to obey that. It is > no big deal, but having all scripts behaving correctly and in some sense > the standard way is definitely good think. I completely agree. Having glanced through the specification there is one point that doesn't seems to be desirable, it is the script naming scheme which seems ugly to me: http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/scrptnames.html Although it could be a SHOULD item that upstream is contacted to register to the lanana. The other points seems right to me. Maybe you could put up a proposal in the wiki and bring it to the packaging commitee on the fedora-packaging list? There are already some items covered in http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?action=show&redirect=ScriptletSnippets#head-b638e19c644263af59762a3154a60554a8303bb3 -- Pat From rdieter at math.unl.edu Tue Mar 27 13:37:35 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Mar 2007 08:37:35 -0500 Subject: hplip: hp-toolbox advertising? References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Tuesday 27 March 2007 07:44:32 Rex Dieter wrote: >> David's usability issues have nothing to do with packaging. >> If you can justify crippling the packaging, fine, but you haven't. > > Removing a company logo from the menu is a pretty good reason I think. Why? The software is from HP afterall. -- Rex From mclasen at redhat.com Tue Mar 27 13:57:49 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 27 Mar 2007 09:57:49 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174965859.24384.1.camel@localhost.localdomain> Message-ID: <1175003869.21714.7.camel@golem.boston.devel.redhat.com> On Tue, 2007-03-27 at 06:44 -0500, Rex Dieter wrote: > Matthias Clasen wrote: > > > On Mon, 2007-03-26 at 22:16 -0500, Rex Dieter wrote: > > >> Bernard has a point. Usability issues (e.g. David's comments) isn't an > >> excuse for half-hearted packaging. If hplip is in fedora, it ought to be > >> packaged properly (.desktop menu, icons, and all). > > > Blindly following packaging guidelines is not an excuse for poor > > usability. > > David's usability issues have nothing to do with packaging. > If you can justify crippling the packaging, fine, but you haven't. > I can see the point of putting things in the menus which are explicitly installed by the user. But to force everything that is in the default install into the menus just because somebody thought it would be a good idea to write in the packaging guideline that "every gui app has to have a desktop file" will quickly lead to unusable menus. I wonder what people will think about this when more vendors see the light of open source and we end up with 10 different "print" menu items, and 10 different system daemons handling some vendors devices (written in python and pulling in Qt, no less). From rdieter at math.unl.edu Tue Mar 27 13:38:47 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Mar 2007 08:38:47 -0500 Subject: hplip: hp-toolbox advertising? References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> Message-ID: Josh Boyer wrote: > I'd like to point out that there is likely a trademark issue involved > here as well. The package is produced by HP-Development, so I think they can use their own logo. :) -- Rex From fedora at camperquake.de Tue Mar 27 13:53:43 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 27 Mar 2007 15:53:43 +0200 Subject: rawhide report: 20070327 changes In-Reply-To: <1174990111.13483.3.camel@localhost.localdomain> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <1174990111.13483.3.camel@localhost.localdomain> Message-ID: <20070327155343.5fcac6bb@banea.int.addix.net> Hi. On Tue, 27 Mar 2007 11:08:31 +0100, Richard Hughes wrote: > These *need* to be split into separate SRPMS. I don't mind > co-maintaining these if you want, but if we are updating machine > quirks once a month or so, then we should be able to update one 100k > no-arch package, rather than 4 or 5 multi-megabyte architecture > specific packages. Errr.. yum tells me that the hal update is 440k. Where does that multi-meg number come from? From jwboyer at jdub.homelinux.org Tue Mar 27 13:53:35 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Tue, 27 Mar 2007 08:53:35 -0500 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> Message-ID: <1175003615.7553.12.camel@zod.rchland.ibm.com> On Tue, 2007-03-27 at 08:38 -0500, Rex Dieter wrote: > Josh Boyer wrote: > > > I'd like to point out that there is likely a trademark issue involved > > here as well. > > The package is produced by HP-Development, so I think they can use their own > logo. :) Firefox is produced by Mozilla, yet we can't use their logo without going through their process when it comes to patching it. (See the whole Debian IceWeasle thing.) Trademarks and open source code don't often play nicely. josh From pertusus at free.fr Tue Mar 27 13:56:11 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 27 Mar 2007 15:56:11 +0200 Subject: rawhide report: 20070327 changes In-Reply-To: <20070327155343.5fcac6bb@banea.int.addix.net> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <1174990111.13483.3.camel@localhost.localdomain> <20070327155343.5fcac6bb@banea.int.addix.net> Message-ID: <20070327135609.GB2888@free.fr> On Tue, Mar 27, 2007 at 03:53:43PM +0200, Ralf Ertzinger wrote: > Hi. > > Errr.. yum tells me that the hal update is 440k. Where does that multi-meg > number come from? >From the future, maybe? Even if it is small today the split makes sense for many reasons. -- Pat From rdieter at math.unl.edu Tue Mar 27 13:58:56 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Mar 2007 08:58:56 -0500 Subject: hplip: hp-toolbox advertising? References: <1174965859.24384.1.camel@localhost.localdomain> <1175003869.21714.7.camel@golem.boston.devel.redhat.com> Message-ID: Matthias Clasen wrote: > On Tue, 2007-03-27 at 06:44 -0500, Rex Dieter wrote: >> David's usability issues have nothing to do with packaging. >> If you can justify crippling the packaging, fine, but you haven't. > I can see the point of putting things in the menus which are explicitly > installed by the user. But to force everything that is in the default > install into the menus just because somebody thought it would be a good > idea to write in the packaging guideline that "every gui app has to have > a desktop file" will quickly lead to unusable menus. See, this is where we apparently disagree. The packaging guideline exists *because* the to-display-where-or-not decision should not be up to individual packages/packagers. This goes beyond packaging policy/guidelines. It is a usability issue, and should be considered carefully(1) when designing future iterations of (gnome|kde|redhat)-menus. (1) Usability a SIG/group would come in handy here, oh maybe something like: http://fedoraproject.org/wiki/Usability -- Rex From hughsient at gmail.com Tue Mar 27 13:58:35 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Mar 2007 14:58:35 +0100 Subject: rawhide report: 20070327 changes In-Reply-To: <20070327155343.5fcac6bb@banea.int.addix.net> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <1174990111.13483.3.camel@localhost.localdomain> <20070327155343.5fcac6bb@banea.int.addix.net> Message-ID: <1175003915.18359.4.camel@localhost.localdomain> On Tue, 2007-03-27 at 15:53 +0200, Ralf Ertzinger wrote: > > Errr.. yum tells me that the hal update is 440k. Where does that > multi-meg number come from? Together, hal + hal-devel + hal-gnome + hal-debuginfo = 1.7Mb For comparison, updating hal-info is 18kb Richard. From rdieter at math.unl.edu Tue Mar 27 14:01:37 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Mar 2007 09:01:37 -0500 Subject: hplip: hp-toolbox advertising? References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> <1175003615.7553.12.camel@zod.rchland.ibm.com> Message-ID: Josh Boyer wrote: > On Tue, 2007-03-27 at 08:38 -0500, Rex Dieter wrote: >> Josh Boyer wrote: >> > I'd like to point out that there is likely a trademark issue involved >> > here as well. >> The package is produced by HP-Development, so I think they can use their >> own logo. :) > Firefox is produced by Mozilla, yet we can't use their logo without > going through their process when it comes to patching it. Firefox isn't GPL'd. The GPL gives us the right to modify and redistribute without limitation. -- Rex From jkeating at redhat.com Tue Mar 27 14:08:27 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Mar 2007 10:08:27 -0400 Subject: rawhide report: 20070327 changes In-Reply-To: <1175001195.15998.4.camel@localhost.localdomain> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <1175001195.15998.4.camel@localhost.localdomain> Message-ID: <200703271008.30567.jkeating@redhat.com> On Tuesday 27 March 2007 09:13:15 Richard Hughes wrote: > Also, are we going to rebuild dbus without asserts for F7T3? no. I hope the golden tree has been spun for Test3. -- 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 denis at poolshark.org Tue Mar 27 14:12:48 2007 From: denis at poolshark.org (Denis Leroy) Date: Tue, 27 Mar 2007 16:12:48 +0200 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175003615.7553.12.camel@zod.rchland.ibm.com> References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> <1175003615.7553.12.camel@zod.rchland.ibm.com> Message-ID: <46092660.2040801@poolshark.org> Josh Boyer wrote: > On Tue, 2007-03-27 at 08:38 -0500, Rex Dieter wrote: >> Josh Boyer wrote: >> >>> I'd like to point out that there is likely a trademark issue involved >>> here as well. >> The package is produced by HP-Development, so I think they can use their own >> logo. :) > > Firefox is produced by Mozilla, yet we can't use their logo without > going through their process when it comes to patching it. (See the > whole Debian IceWeasle thing.) Right so we do already have a menu entry with a trademarked logo (firefox), so how would the HP software be any different ? From david at fubar.dk Tue Mar 27 14:16:10 2007 From: david at fubar.dk (David Zeuthen) Date: Tue, 27 Mar 2007 10:16:10 -0400 Subject: rawhide report: 20070327 changes In-Reply-To: <1174990111.13483.3.camel@localhost.localdomain> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <1174990111.13483.3.camel@localhost.localdomain> Message-ID: <1175004970.2622.201.camel@zelda.fubar.dk> On Tue, 2007-03-27 at 11:08 +0100, Richard Hughes wrote: > On Tue, 2007-03-27 at 06:03 -0400, buildsys at redhat.com wrote: > > hal-0.5.9-0.git20070326.fc7 > > --------------------------- > > * Mon Mar 26 2007 David Zeuthen - > > 0.5.9-0.git20070326 > > - Update to hal 0.5.9rc2 and hal-info-20070326 > > These *need* to be split into separate SRPMS. I don't mind > co-maintaining these if you want, but if we are updating machine quirks > once a month or so, then we should be able to update one 100k no-arch > package, rather than 4 or 5 multi-megabyte architecture specific > packages. > > Sorry to harp on about this, but F7T3 is getting closer. One, this bug is not a feature and that's why I've been punting it since I'd rather spend my time getting features done before feature freeze. Second, the hal and hal-info tarballs needed fixing http://lists.freedesktop.org/archives/hal/2007-March/007799.html to actually sanely do this. Third, I'd be happy to see you co-maintain the hal-info package and I think I even suggested you should submit the hal-info SRPM for Fedora Extras. If it's in Extras already, it's simpler to do the switch once the merge is complete. HAL will need a rebuild _anyway_ to take advantage of libsmbios for backlight and rfkill on Dell laptops. David From hughsient at gmail.com Tue Mar 27 14:16:18 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Mar 2007 15:16:18 +0100 Subject: rawhide report: 20070327 changes In-Reply-To: <200703271008.30567.jkeating@redhat.com> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <1175001195.15998.4.camel@localhost.localdomain> <200703271008.30567.jkeating@redhat.com> Message-ID: <1175004978.18359.8.camel@localhost.localdomain> On Tue, 2007-03-27 at 10:08 -0400, Jesse Keating wrote: > > no. I hope the golden tree has been spun for Test3. Ick. So the crasher bug fixed in gnome-power-manager 2.18.1 isn't going to be included? I cc'd redhat maintainers about a week ago when doing the release announcement. This means I'll continue to get circa 10 bugs a day about crashing gnome-power-statistics. Richard. From nicolas.mailhot at laposte.net Tue Mar 27 14:21:51 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 27 Mar 2007 16:21:51 +0200 (CEST) Subject: hplip: hp-toolbox advertising? In-Reply-To: <46092660.2040801@poolshark.org> References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> <1175003615.7553.12.camel@zod.rchland.ibm.com> <46092660.2040801@poolshark.org> Message-ID: <5813.192.54.193.51.1175005311.squirrel@rousalka.dyndns.org> Le Mar 27 mars 2007 16:12, Denis Leroy a ?crit : > Josh Boyer wrote: >> On Tue, 2007-03-27 at 08:38 -0500, Rex Dieter wrote: >>> Josh Boyer wrote: >>> >>>> I'd like to point out that there is likely a trademark issue involved >>>> here as well. >>> The package is produced by HP-Development, so I think they can use >>> their own >>> logo. :) >> >> Firefox is produced by Mozilla, yet we can't use their logo without >> going through their process when it comes to patching it. (See the >> whole Debian IceWeasle thing.) > > Right so we do already have a menu entry with a trademarked logo > (firefox), so how would the HP software be any different ? On one side you have an application logo (1-1 match). On the other side you have a company logo (1-to-many match). 1st is ok 2nd not. -- Nicolas Mailhot From hughsient at gmail.com Tue Mar 27 14:20:40 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Mar 2007 15:20:40 +0100 Subject: rawhide report: 20070327 changes In-Reply-To: <1175004970.2622.201.camel@zelda.fubar.dk> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <1174990111.13483.3.camel@localhost.localdomain> <1175004970.2622.201.camel@zelda.fubar.dk> Message-ID: <1175005240.18359.12.camel@localhost.localdomain> On Tue, 2007-03-27 at 10:16 -0400, David Zeuthen wrote: > On Tue, 2007-03-27 at 11:08 +0100, Richard Hughes wrote: > > On Tue, 2007-03-27 at 06:03 -0400, buildsys at redhat.com wrote: > > > hal-0.5.9-0.git20070326.fc7 > > > --------------------------- > > > * Mon Mar 26 2007 David Zeuthen - > > > 0.5.9-0.git20070326 > > > - Update to hal 0.5.9rc2 and hal-info-20070326 > > > > These *need* to be split into separate SRPMS. I don't mind > > co-maintaining these if you want, but if we are updating machine quirks > > once a month or so, then we should be able to update one 100k no-arch > > package, rather than 4 or 5 multi-megabyte architecture specific > > packages. > > > > Sorry to harp on about this, but F7T3 is getting closer. > > One, this bug is not a feature and that's why I've been punting it since > I'd rather spend my time getting features done before feature freeze. Ahh, I figured it was a new feature, apologies. > Second, the hal and hal-info tarballs needed fixing > http://lists.freedesktop.org/archives/hal/2007-March/007799.html Yes agreed, cheers for doing this. > to actually sanely do this. Third, I'd be happy to see you co-maintain > the hal-info package and I think I even suggested you should submit the > hal-info SRPM for Fedora Extras. If it's in Extras already, it's simpler > to do the switch once the merge is complete. HAL will need a rebuild > _anyway_ to take advantage of libsmbios for backlight and rfkill on Dell > laptops. Sure, I do enough shouting on this list to put my money where my mouth is... ;-) I'll happily co-maintain hal-info. I'll read up on how to do so tonight. Richard. From jkeating at redhat.com Tue Mar 27 14:28:40 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Mar 2007 10:28:40 -0400 Subject: rawhide report: 20070327 changes In-Reply-To: <1175004978.18359.8.camel@localhost.localdomain> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <200703271008.30567.jkeating@redhat.com> <1175004978.18359.8.camel@localhost.localdomain> Message-ID: <200703271028.40721.jkeating@redhat.com> On Tuesday 27 March 2007 10:16:18 Richard Hughes wrote: > Ick. So the crasher bug fixed in gnome-power-manager 2.18.1 isn't going > to be included? I cc'd redhat maintainers about a week ago when doing > the release announcement. This means I'll continue to get circa 10 bugs > a day about crashing gnome-power-statistics. I'm sorry, nobody asked for a build of it to be included in the test release. The package changelog has nothing more than "Update to 2.18.1" so I don't really have a way of knowing what it fixes or introduces, so I wasn't about to tag it all on my own. Thankfully it'll be available as an update. Also thankfully once we merge you can take over gnome-power-manager and maintain it yourself within Fedora (: -- 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 sundaram at fedoraproject.org Tue Mar 27 14:31:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 27 Mar 2007 20:01:34 +0530 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> <1175003615.7553.12.camel@zod.rchland.ibm.com> Message-ID: <46092AC6.70408@fedoraproject.org> Rex Dieter wrote: > Josh Boyer wrote: >> On Tue, 2007-03-27 at 08:38 -0500, Rex Dieter wrote: >>> Josh Boyer wrote: > >>>> I'd like to point out that there is likely a trademark issue involved >>>> here as well. > >>> The package is produced by HP-Development, so I think they can use their >>> own logo. :) > >> Firefox is produced by Mozilla, yet we can't use their logo without >> going through their process when it comes to patching it. > > Firefox isn't GPL'd. The GPL gives us the right to modify and redistribute > without limitation. Firefox *is* under GPL. The whole codebase is trilicensed under MPL/GPL/LGPL. The license of a software has zero effects on the usage of a logo which maybe protected by a trademark. Rahul From hughsient at gmail.com Tue Mar 27 14:31:16 2007 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 27 Mar 2007 15:31:16 +0100 Subject: rawhide report: 20070327 changes In-Reply-To: <200703271028.40721.jkeating@redhat.com> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <200703271008.30567.jkeating@redhat.com> <1175004978.18359.8.camel@localhost.localdomain> <200703271028.40721.jkeating@redhat.com> Message-ID: <1175005876.24017.1.camel@localhost.localdomain> On Tue, 2007-03-27 at 10:28 -0400, Jesse Keating wrote: > Thankfully it'll be available as an update. Also thankfully once we > merge you can take over gnome-power-manager and maintain it yourself > within Fedora (: Sure, not a problem. :-) Richard. From jdieter at gmail.com Tue Mar 27 14:36:29 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 27 Mar 2007 17:36:29 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174998403.30355.43.camel@cutter> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> <1174941261.30355.32.camel@cutter> <20070327100542.GA4814@suse.de> <1174991391.19925.116.camel@jndwidescreen.lesbg.loc> <1174998403.30355.43.camel@cutter> Message-ID: <1175006189.7752.21.camel@jndwidescreen.lesbg.loc> On Tue, 2007-03-27 at 08:26 -0400, seth vidal wrote: > On Tue, 2007-03-27 at 13:29 +0300, Jonathan Dieter wrote: > > And I changed Presto last night to use the full method, rather than the > > fast method. Our fallback method is pretty lousy (exiting with an > > error, working the second time yum is called), at least for the moment. > > > > Why is that? I need to take a look at the code but there doesn't seem to > be any reason why it shouldn't be able to fall back to downloading the > whole package. It knows where it is. > > -sv > You're obviously the expert in yum, so most of this will be obvious, and I'd definitely appreciate correction on anything I have wrong. I'm going to summarize the steps yum takes and mark how presto interacts with *: 1. Yum gets repomd for each repository - postreposetup_hook called 2. *Presto gets prestomd for each repository (the format of which is cunningly stolen from yum). ;) 3. *Presto gets presto.xml.gz for each presto repository (once again using very slightly modified python code). - end of postreposetup_hook 4. Yum gets primary.xml.gz for each repository. 5. Yum finds what packages are going to be update/installed/removed, resolves dependencies and sets up a transaction. - postresolve_hook called 6. *Presto cycles through packages, sees which are to be installed (like kernel) or updated, and checks for available drpms. 7. *If there is an available drpm, presto then uses applydeltarpm -s to see if the drpm can be applied correctly. 8. *If the drpm can be applied correctly, presto modifies the package information in the transaction sack so that it points to the drpm (storing the original information elsewhere in the PackageObject). - end of postresolve_hook 9. Yum downloads rpms (and drpms where they've been substituted in). - postdownload_hook called 10. *Presto cycles through drpms downloaded and generates rpms from the drpms. It will exit at this point if it is unable to generate the rpm. 11. *Presto reverts all information that it changed in the PackageObject. - end of postdownload_hook 11. Yum installs rpms - posttrans_hook called 12. *Presto displays and logs savings information - end of posttrans_hook 13. Yum exits I chose to leave the heavy lifting of step 9 to yum because it seemed the most elegant solution. However that does leave us with a nasty exit if we are unable to reconstruct the rpms. Two possible solutions: 1. Write a subclass of PackageObject with verifyLocalPackage overloaded to reconstruct the rpm and fail if we are unable to (not sure if this is very feasible or even a good idea). 2. Create a predownload_hook that does step 9, and then let yum download the full package if it fails. Thoughts, comments, hard objects to be thrown at me for lousy design decisions? ;) Jonathan -------------- 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 jdieter at gmail.com Tue Mar 27 14:39:06 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 27 Mar 2007 17:39:06 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <46091B34.6070002@rasmil.dk> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> <1174941261.30355.32.camel@cutter> <20070327100542.GA4814@suse.de> <1174991391.19925.116.camel@jndwidescreen.lesbg.loc> <1174998403.30355.43.camel@cutter> <46091B34.6070002@rasmil.dk> Message-ID: <1175006347.7752.24.camel@jndwidescreen.lesbg.loc> On Tue, 2007-03-27 at 15:25 +0200, Tim Lauridsen wrote: > seth vidal wrote: > > Why is that? I need to take a look at the code but there doesn't seem to > > be any reason why it shouldn't be able to fall back to downloading the > > whole package. It knows where it is. > > > > -sv > > > > > I look at the code, it works in the following way: > > postresolve_hook(conduit): > for each po to be install in TransactionSet: > check if delta as available. > make the po point to the delta insted of the full rpm. > > normal yum downloading (yum.downloadPkg) > > postdownload_hook(conduit): > for each pkg in the downloadpackages: > if pkg is a delta: > try: > build the full rpm from the delta > except: > Something is rotten in the state of Denmark, bail > out. > > if could be changed to: > predownload_hook(conduit,pkglist): > for each po in pkglist: > if as delta is available: > try: > download the delta (copy the download code from > yum.downloadPkgs) > build the full rpm. > set po.pkgtype = 'local' # To make yum skip it in the > normal download. > except: > Something is rotten in the state of Denmark, just > leave the po unchanged an yum will handle the download as normal. > > normal yum downloading (yum.downloadPkg) > will download all the packages not processed without error, by the > predownload_hook. > > Tim If it's agreed that this is the best way, I'm happy to make it work this way. Jonathan -------------- 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 rdieter at math.unl.edu Tue Mar 27 14:41:32 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Mar 2007 09:41:32 -0500 Subject: hplip: hp-toolbox advertising? References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> <1175003615.7553.12.camel@zod.rchland.ibm.com> <46092AC6.70408@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Rex Dieter wrote: >> Firefox isn't GPL'd. The GPL gives us the right to modify and >> redistribute without limitation. > > Firefox *is* under GPL. The whole codebase is trilicensed under > MPL/GPL/LGPL. Interesting, only the MPL is mentioned on: http://www.mozilla.com/en-US/about/licensing.html but digging deeper I find: http://www.mozilla.org/MPL/relicensing-faq.html happy days indeed. > >The license of a software has zero effects on the usage of > a logo which maybe protected by a trademark. Yuck, murky waters. I figured if an icon/logo was included within GPL sources, and the GPL allows for unrestricted modification/redistribution, we were golden. Note, we're not talking about modifying the *trademarked* item in this case (which I would agree not a good idea), only using/displaying it. -- Rex From nicu_fedora at nicubunu.ro Tue Mar 27 14:49:58 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Tue, 27 Mar 2007 17:49:58 +0300 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> <1175003615.7553.12.camel@zod.rchland.ibm.com> <46092AC6.70408@fedoraproject.org> Message-ID: <46092F16.1010608@nicubunu.ro> Rex Dieter wrote: > > Yuck, murky waters. I figured if an icon/logo was included within GPL > sources, and the GPL allows for unrestricted modification/redistribution, > we were golden. Note, we're not talking about modifying the *trademarked* > item in this case (which I would agree not a good idea), only > using/displaying it. Is not like that, consider the Red Hat icons/logos included in the GPL RHEL sources, a derivative distro is required to change them. -- nicu Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From sundaram at fedoraproject.org Tue Mar 27 14:58:27 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 27 Mar 2007 20:28:27 +0530 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> <1175003615.7553.12.camel@zod.rchland.ibm.com> <46092AC6.70408@fedoraproject.org> Message-ID: <46093113.9050308@fedoraproject.org> Rex Dieter wrote: >>> The license of a software has zero effects on the usage of >> a logo which maybe protected by a trademark. > > Yuck, murky waters. I figured if an icon/logo was included within GPL > sources, and the GPL allows for unrestricted modification/redistribution, > we were golden. Note, we're not talking about modifying the *trademarked* > item in this case (which I would agree not a good idea), only > using/displaying it. Even if a logo is included within GPL'ed source code, the trademark can still be protected by separate trademark guidelines. Even use of a trademark in any form can still be restricted. Similar separate restrictions apply for patents in the case where the patent holder is the same entity/people involved in the development of some software although there is some implicit grant under GPLv2 and a more explicit one under GPLv3 (in the future based on the current drafts). In case of other permissive licenses such as revised BSD or MIT X11 license you can be sued by the same people for patent infringement who gave the software under these licenses. Surprised yet? Rahul From rdieter at math.unl.edu Tue Mar 27 15:02:48 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Mar 2007 10:02:48 -0500 Subject: hplip: hp-toolbox advertising? References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> <1175003615.7553.12.camel@zod.rchland.ibm.com> <46092AC6.70408@fedoraproject.org> <46092F16.1010608@nicubunu.ro> Message-ID: Nicu Buculei wrote: > Rex Dieter wrote: >> Yuck, murky waters. I figured if an icon/logo was included within GPL >> sources, and the GPL allows for unrestricted modification/redistribution, >> we were golden. Note, we're not talking about modifying the >> *trademarked* item in this case (which I would agree not a good idea), >> only using/displaying it. > Is not like that, consider the Red Hat icons/logos included in the GPL > RHEL sources, a derivative distro is required to change them. Yuck (again), my simple-minded non-lawyer common sense tells me such items shouldn't be using the GPL then, but that's just me. -- Rex From katzj at redhat.com Tue Mar 27 15:05:09 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 27 Mar 2007 11:05:09 -0400 Subject: Why nobody uses vnc module to X? In-Reply-To: References: <4608E886.3070508@redhat.com> Message-ID: <1175007909.18922.17.camel@erebor.boston.redhat.com> On Tue, 2007-03-27 at 11:00 +0100, Andy Burns wrote: > On 27/03/07, Adam Tkac wrote: > > I'm really surprised that nobody uses vnc's rawhide module to X. Module > > was completely unusable since 2nd March (got sigsegv) and no bugreport > > came to me :( . > > I do the occasional anaconda/vnc install, but after installation for > remote sessions I tend to use X/SSH tunnels for improved security, and > less hassle with other people's firewalls. This uses the stand-alone vncserver, not the vnc X module. Jeremy From alan at redhat.com Tue Mar 27 15:13:02 2007 From: alan at redhat.com (Alan Cox) Date: Tue, 27 Mar 2007 11:13:02 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> <1175003615.7553.12.camel@zod.rchland.ibm.com> <46092AC6.70408@fedoraproject.org> Message-ID: <20070327151302.GA9553@devserv.devel.redhat.com> On Tue, Mar 27, 2007 at 09:41:32AM -0500, Rex Dieter wrote: > Yuck, murky waters. I figured if an icon/logo was included within GPL > sources, and the GPL allows for unrestricted modification/redistribution, > we were golden. Note, we're not talking about modifying the *trademarked* > item in this case (which I would agree not a good idea), only > using/displaying it. You'll find most people don't put the icons under the GPL for things like company logos From skvidal at linux.duke.edu Tue Mar 27 15:20:04 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 27 Mar 2007 11:20:04 -0400 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175006347.7752.24.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> <1174941261.30355.32.camel@cutter> <20070327100542.GA4814@suse.de> <1174991391.19925.116.camel@jndwidescreen.lesbg.loc> <1174998403.30355.43.camel@cutter> <46091B34.6070002@rasmil.dk> <1175006347.7752.24.camel@jndwidescreen.lesbg.loc> Message-ID: <1175008804.30355.64.camel@cutter> On Tue, 2007-03-27 at 17:39 +0300, Jonathan Dieter wrote: > On Tue, 2007-03-27 at 15:25 +0200, Tim Lauridsen wrote: > > seth vidal wrote: > > > Why is that? I need to take a look at the code but there doesn't seem to > > > be any reason why it shouldn't be able to fall back to downloading the > > > whole package. It knows where it is. > > > > > > -sv > > > > > > > > I look at the code, it works in the following way: > > > > postresolve_hook(conduit): > > for each po to be install in TransactionSet: > > check if delta as available. > > make the po point to the delta insted of the full rpm. > > > > normal yum downloading (yum.downloadPkg) > > > > postdownload_hook(conduit): > > for each pkg in the downloadpackages: > > if pkg is a delta: > > try: > > build the full rpm from the delta > > except: > > Something is rotten in the state of Denmark, bail > > out. > > > > if could be changed to: > > predownload_hook(conduit,pkglist): > > for each po in pkglist: > > if as delta is available: > > try: > > download the delta (copy the download code from > > yum.downloadPkgs) > > build the full rpm. > > set po.pkgtype = 'local' # To make yum skip it in the > > normal download. > > except: > > Something is rotten in the state of Denmark, just > > leave the po unchanged an yum will handle the download as normal. > > > > normal yum downloading (yum.downloadPkg) > > will download all the packages not processed without error, by the > > predownload_hook. > > > > Tim > > If it's agreed that this is the best way, I'm happy to make it work this > way. > I think Tim's suggestion makes sense. It makes the delta-rpm portion an optimize-if-possible step which fits in nicely. -sv From sundaram at fedoraproject.org Tue Mar 27 15:22:11 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 27 Mar 2007 20:52:11 +0530 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> <1175003615.7553.12.camel@zod.rchland.ibm.com> <46092AC6.70408@fedoraproject.org> <46092F16.1010608@nicubunu.ro> Message-ID: <460936A3.4070408@fedoraproject.org> Rex Dieter wrote: > Nicu Buculei wrote: > >> Rex Dieter wrote: > >>> Yuck, murky waters. I figured if an icon/logo was included within GPL >>> sources, and the GPL allows for unrestricted modification/redistribution, >>> we were golden. Note, we're not talking about modifying the >>> *trademarked* item in this case (which I would agree not a good idea), >>> only using/displaying it. > >> Is not like that, consider the Red Hat icons/logos included in the GPL >> RHEL sources, a derivative distro is required to change them. > > Yuck (again), my simple-minded non-lawyer common sense tells me such items > shouldn't be using the GPL then, but that's just me. The Red Hat logos are not under GPL. The package license of the two relevant packages and the EULA makes this clear. They are merely part of the distribution which has components under several different licenses. Rahul From rdieter at math.unl.edu Tue Mar 27 15:27:10 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Mar 2007 10:27:10 -0500 Subject: hplip: hp-toolbox advertising? References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> <1175003615.7553.12.camel@zod.rchland.ibm.com> <46092AC6.70408@fedoraproject.org> <46092F16.1010608@nicubunu.ro> <460936A3.4070408@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Rex Dieter wrote: >> Yuck (again), my simple-minded non-lawyer common sense tells me such >> items shouldn't be using the GPL then, but that's just me. > The Red Hat logos are not under GPL. The package license of the two > relevant packages and the EULA makes this clear. Thanks, though I'd argue mixing-n-matching licenses within a (single) package is bad form. -- Rex From ssorce at redhat.com Tue Mar 27 15:30:08 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 27 Mar 2007 11:30:08 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> <1175003615.7553.12.camel@zod.rchland.ibm.com> <46092AC6.70408@fedoraproject.org> <46092F16.1010608@nicubunu.ro> <460936A3.4070408@fedoraproject.org> Message-ID: <1175009409.6100.4.camel@willson> On Tue, 2007-03-27 at 10:27 -0500, Rex Dieter wrote: > Rahul Sundaram wrote: > > > Rex Dieter wrote: > > >> Yuck (again), my simple-minded non-lawyer common sense tells me such > >> items shouldn't be using the GPL then, but that's just me. > > > The Red Hat logos are not under GPL. The package license of the two > > relevant packages and the EULA makes this clear. > > Thanks, though I'd argue mixing-n-matching licenses within a (single) > package is bad form. No, there are countless packages with differently licensed files in them. GPL+LGPL, GPL+(new)BSD, GPL+MIT, MIT+BSD, and on and on and on... From jdieter at gmail.com Tue Mar 27 15:53:23 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Tue, 27 Mar 2007 18:53:23 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175008804.30355.64.camel@cutter> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> <1174941261.30355.32.camel@cutter> <20070327100542.GA4814@suse.de> <1174991391.19925.116.camel@jndwidescreen.lesbg.loc> <1174998403.30355.43.camel@cutter> <46091B34.6070002@rasmil.dk> <1175006347.7752.24.camel@jndwidescreen.lesbg.loc> <1175008804.30355.64.camel@cutter> Message-ID: <1175010803.7752.27.camel@jndwidescreen.lesbg.loc> On Tue, 2007-03-27 at 11:20 -0400, seth vidal wrote: > On Tue, 2007-03-27 at 17:39 +0300, Jonathan Dieter wrote: > > If it's agreed that this is the best way, I'm happy to make it work this > > way. > > > > I think Tim's suggestion makes sense. It makes the delta-rpm portion an > optimize-if-possible step which fits in nicely. > > -sv > Okay. Will implement in next version. It's probably time for a bump to 0.3.0, anyway, so it gives me halfway decent justification, too. ;) Jonathan -------------- 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 david at fubar.dk Tue Mar 27 16:16:05 2007 From: david at fubar.dk (David Zeuthen) Date: Tue, 27 Mar 2007 12:16:05 -0400 Subject: rawhide report: 20070327 changes In-Reply-To: <1175001195.15998.4.camel@localhost.localdomain> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <1175001195.15998.4.camel@localhost.localdomain> Message-ID: <1175012165.3142.6.camel@zelda.fubar.dk> On Tue, 2007-03-27 at 14:13 +0100, Richard Hughes wrote: > On Tue, 2007-03-27 at 06:03 -0400, buildsys at redhat.com wrote: > > Updated Packages: > > Also, are we going to rebuild dbus without asserts for F7T3? To be determined; I'd rather like to see bad apps getting (like HAL; git20070304 had issues that are hopefully resolved by git20070326) fixed before applying a such a band aid. David From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 16:21:35 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Tue, 27 Mar 2007 10:21:35 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175003869.21714.7.camel@golem.boston.devel.redhat.com> References: <1174965859.24384.1.camel@localhost.localdomain> <1175003869.21714.7.camel@golem.boston.devel.redhat.com> Message-ID: Matthias Clasen wrote: > I can see the point of putting things in the menus which are explicitly > installed by the user. But to force everything that is in the default > install into the menus just because somebody thought it would be a good > idea to write in the packaging guideline that "every gui app has to have > a desktop file" will quickly lead to unusable menus. But let's look at why it's in the default install: http://hplip.sourceforge.net/ "The HPLIP project provides printing support for 1,139 printer models, including Deskjet, Officejet, Photosmart, PSC (Print Scan Copy), Business Inkjet, LaserJet, and LaserJet MFP." 1139 is not an insignificant number. Oh, and the fact that we don't have the ability to decide intelligently if it needs to be installed. > I wonder what people will think about this when more vendors see the > light of open source and we end up with 10 different "print" menu > items, and 10 different system daemons handling some vendors devices > (written in python and pulling in Qt, no less). Then this is a failure of the packaging or packaging process. It has nothing to do with the individual package. From txtoth at gmail.com Tue Mar 27 16:23:20 2007 From: txtoth at gmail.com (Xavier Toth) Date: Tue, 27 Mar 2007 10:23:20 -0600 Subject: VESA driver hsync config problem In-Reply-To: <1174945236.1534.2.camel@localhost.localdomain> References: <1174917730.31911.10.camel@localhost.localdomain> <1174945236.1534.2.camel@localhost.localdomain> Message-ID: The error that kills the xserver ends up on stderr. This may be a bug in the xserver or the Xinerama extension and I will pursue that. In the meantime as an interim solution maybe you could direct me as to how I could hack the system-config-display to add a HorizSync line to the xorg.conf file. On 3/26/07, Adam Jackson wrote: > On Mon, 2007-03-26 at 13:58 -0600, Xavier Toth wrote: > > Indeed I do have a log file and I'd greatly appreciate any assistance > > you can give me. > > That log appears to be from a successful startup. Odd. > > We can definitely tell if we're running under Parallels though: > > (II) VESA(0): VESA VBE OEM Vendor: Parallels Software International, > Inc. > > The trick is just knowing what we're supposed to do when we detect > Parallels. I don't have it, so I don't know. What _should_ we do? > > - ajax > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- A non-text attachment was scrubbed... Name: x.log.para Type: application/octet-stream Size: 23692 bytes Desc: not available URL: From mclasen at redhat.com Tue Mar 27 17:03:38 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 27 Mar 2007 13:03:38 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174965859.24384.1.camel@localhost.localdomain> <1175003869.21714.7.camel@golem.boston.devel.redhat.com> Message-ID: <1175015018.23566.2.camel@golem.boston.devel.redhat.com> On Tue, 2007-03-27 at 10:21 -0600, Bernard Johnson wrote: > Matthias Clasen wrote: > > I can see the point of putting things in the menus which are explicitly > > installed by the user. But to force everything that is in the default > > install into the menus just because somebody thought it would be a good > > idea to write in the packaging guideline that "every gui app has to have > > a desktop file" will quickly lead to unusable menus. > > But let's look at why it's in the default install: > > http://hplip.sourceforge.net/ > "The HPLIP project provides printing support for 1,139 printer models, > including Deskjet, Officejet, Photosmart, PSC (Print Scan Copy), > Business Inkjet, LaserJet, and LaserJet MFP." > > 1139 is not an insignificant number. Oh, and the fact that we don't > have the ability to decide intelligently if it needs to be installed. How many of these are not supported by cups/foomatic ? > > I wonder what people will think about this when more vendors see the > > light of open source and we end up with 10 different "print" menu > > items, and 10 different system daemons handling some vendors devices > > (written in python and pulling in Qt, no less). > > Then this is a failure of the packaging or packaging process. It has > nothing to do with the individual package. I don't follow you here. I'm making the argument that this individual package installs a resource hungry system daemon that always runs even if it has nothing to do, and the ui duplicates a good chunk of the printing support in the rest of the desktop. And you say that has nothing to do with the individual package ? From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 16:52:29 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Tue, 27 Mar 2007 10:52:29 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175015018.23566.2.camel@golem.boston.devel.redhat.com> References: <1174965859.24384.1.camel@localhost.localdomain> <1175003869.21714.7.camel@golem.boston.devel.redhat.com> <1175015018.23566.2.camel@golem.boston.devel.redhat.com> Message-ID: Matthias Clasen wrote: > On Tue, 2007-03-27 at 10:21 -0600, Bernard Johnson wrote: >> Matthias Clasen wrote: >>> I can see the point of putting things in the menus which are explicitly >>> installed by the user. But to force everything that is in the default >>> install into the menus just because somebody thought it would be a good >>> idea to write in the packaging guideline that "every gui app has to have >>> a desktop file" will quickly lead to unusable menus. >> But let's look at why it's in the default install: >> >> http://hplip.sourceforge.net/ >> "The HPLIP project provides printing support for 1,139 printer models, >> including Deskjet, Officejet, Photosmart, PSC (Print Scan Copy), >> Business Inkjet, LaserJet, and LaserJet MFP." >> >> 1139 is not an insignificant number. Oh, and the fact that we don't >> have the ability to decide intelligently if it needs to be installed. > > How many of these are not supported by cups/foomatic ? I really get the feeling you would rather punish users because it doesn't work the way you want it to. The fact is that it supports a lot of printers. >>> I wonder what people will think about this when more vendors see the >>> light of open source and we end up with 10 different "print" menu >>> items, and 10 different system daemons handling some vendors devices >>> (written in python and pulling in Qt, no less). >> Then this is a failure of the packaging or packaging process. It has >> nothing to do with the individual package. > > I don't follow you here. I'm making the argument that this individual > package installs a resource hungry system daemon that always runs even > if it has nothing to do, and the ui duplicates a good chunk of the > printing support in the rest of the desktop. And you say that has > nothing to do with the individual package ? Whether or not the software sucks is another issue. If we are installing software for hardware that people do not have, and then multiple instances of programs that have identical functionality, that is a packaging problem. Even if hplip was the best software in the world it would not fix that. Should we talk about the fact that Fedora already has three copies of VNC-type programs without an integrated codebase? From dan at danny.cz Tue Mar 27 16:51:41 2007 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Tue, 27 Mar 2007 18:51:41 +0200 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174965859.24384.1.camel@localhost.localdomain> <1175003869.21714.7.camel@golem.boston.devel.redhat.com> Message-ID: <1175014301.3815.16.camel@eagle.danny.cz> Bernard Johnson p??e v ?t 27. 03. 2007 v 10:21 -0600: > Matthias Clasen wrote: > > I can see the point of putting things in the menus which are explicitly > > installed by the user. But to force everything that is in the default > > install into the menus just because somebody thought it would be a good > > idea to write in the packaging guideline that "every gui app has to have > > a desktop file" will quickly lead to unusable menus. > > But let's look at why it's in the default install: > > http://hplip.sourceforge.net/ > "The HPLIP project provides printing support for 1,139 printer models, > including Deskjet, Officejet, Photosmart, PSC (Print Scan Copy), > Business Inkjet, LaserJet, and LaserJet MFP." > > 1139 is not an insignificant number. Oh, and the fact that we don't > have the ability to decide intelligently if it needs to be installed. But it could be a task for system-config-printer - it detects printers and installs printer specific packages. It could be perhaps some connection between driver name and required packages. Dan From pertusus at free.fr Tue Mar 27 17:14:30 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 27 Mar 2007 19:14:30 +0200 Subject: rawhide report: 20070327 changes In-Reply-To: <1175012165.3142.6.camel@zelda.fubar.dk> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <1175001195.15998.4.camel@localhost.localdomain> <1175012165.3142.6.camel@zelda.fubar.dk> Message-ID: <20070327171430.GD2888@free.fr> On Tue, Mar 27, 2007 at 12:16:05PM -0400, David Zeuthen wrote: > On Tue, 2007-03-27 at 14:13 +0100, Richard Hughes wrote: > > On Tue, 2007-03-27 at 06:03 -0400, buildsys at redhat.com wrote: > > > Updated Packages: > > > > Also, are we going to rebuild dbus without asserts for F7T3? > > To be determined; I'd rather like to see bad apps getting (like HAL; > git20070304 had issues that are hopefully resolved by git20070326) fixed > before applying a such a band aid. Maybe what could be done would be to rebuild dbus without asserts for the final version only? -- Pat From pertusus at free.fr Tue Mar 27 17:17:07 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 27 Mar 2007 19:17:07 +0200 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175009409.6100.4.camel@willson> References: <1175003615.7553.12.camel@zod.rchland.ibm.com> <46092AC6.70408@fedoraproject.org> <46092F16.1010608@nicubunu.ro> <460936A3.4070408@fedoraproject.org> <1175009409.6100.4.camel@willson> Message-ID: <20070327171707.GE2888@free.fr> On Tue, Mar 27, 2007 at 11:30:08AM -0400, Simo Sorce wrote: > > > > Thanks, though I'd argue mixing-n-matching licenses within a (single) > > package is bad form. > > No, there are countless packages with differently licensed files in > them. GPL+LGPL, GPL+(new)BSD, GPL+MIT, MIT+BSD, and on and on and on... In those cases the whole package is under the GPL (and, arguably MIT/BSD are almost the same). When there are other mixes it may be less clear. -- Pat From kevin at scrye.com Tue Mar 27 17:12:55 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 27 Mar 2007 11:12:55 -0600 Subject: xfce - unowned directories? In-Reply-To: <1174946387.4024.21.camel@hal9000.oberschlesier.lan> References: <20070326205342.ca2ccacc.mschwendt.tmp0701.nospam@arcor.de> <1174946387.4024.21.camel@hal9000.oberschlesier.lan> Message-ID: <20070327111255.3352c09c@ghistelwchlohm.scrye.com> On Mon, 26 Mar 2007 23:59:47 +0200 christoph.wickert at nurfuerspam.de (Christoph Wickert) wrote: > Am Montag, den 26.03.2007, 20:53 +0200 schrieb Michael Schwendt: > > Lost of unowned directories are reported for XFCE packages [1]. If > > I were familiar with the dependency graph, I would know where to > > start with suggesting fixes: > > I think Kevin can give us more insight, this is only what I see on a > quick glance. Sorry for the delay in looking at this... been busy. ;( Thanks for checking for Unowned directories. I have tried to fix up the Xfce packages for that as I find them, but as you have found there are more that need fixing. ;( Side note: Michael: would you be able to post your script that you are using to check these somewhere? Perhaps on the wiki? I think it could be nice to use when reviewing packages as well to make sure unowned dirs are not missed... > > > => xfce-mcs-plugins - 4.4.0-1.fc7.i386 > > (fedora-extras-development-i386) /usr/share/xfce4 > > /usr/share/xfce4/doc > > /usr/lib/xfce4 > > /usr/lib/xfce4/mcs-plugins > > /usr/share/xfce-mcs-plugins > > /usr/share/xfce-mcs-plugins/shortcuts > > The last three should be owned by xfce-mcs-manager I think Agreed. > > => xfce4-battery-plugin - 0.5.0-1.fc7.i386 > > (fedora-extras-development-i386) /usr/libexec/xfce4 > > [snipped, same for the all the other panel plugins I'm maintaining] > > I think xfce4-panel should own %{_libexecdir}/xfce4, because atm this > location is only used for panel plugins. Also agreed. > > => xfce4-mixer - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) > > /usr/libexec/xfce4 > > xfce4-mixer should depend on xfce4-panel owning %{_libexecdir}/xfce4 > since it provides a panel plugin Right. It's basically just another plugin... although it's in the "core" Xfce packages. > > => xfce4-session - 4.4.0-1.fc7.i386 (fedora-extras-development-i386) > > /etc/xdg/xfce4-session > > /etc/xdg/autostart > > /usr/share/xfce4 > > /usr/share/xfce4/doc > > /usr/share/xfce4/tips > > /usr/lib/xfce4 > > /usr/lib/xfce4/splash > > /usr/lib/xfce4/splash/engines > > xfce4-session should own splash and %{_libdir}/xfce4/splash and > %{_libdir}/xfce4/splash/engines Yep. > > > /usr/lib/xfce4/mcs-plugins > > looks like xfce4-session needs to require xfce-mcs-manager (or > whatever package we decide to own this dir) mcs-manager I think... yeah. > > => xfce4-session-devel - 4.4.0-1.fc7.i386 > > (fedora-extras-development-i386) /usr/include/xfce4 > > /usr/include/xfce4/xfce4-session-4.2 > > /usr/include/xfce4/xfce4-session-4.2/libxfsm > > should own the last two Agreed. > > => xfce4-session-engines - 4.4.0-1.fc7.i386 > > (fedora-extras-development-i386) /usr/lib/xfce4 > > /usr/lib/xfce4/splash > > /usr/lib/xfce4/splash/engines > > these two would be fixed if xfce-session owned splash and > splash/engines. Right. I will try and go through all this list tonight and see if I can clean all these up. Any additional ideas or issues, let me know. Thanks again for the report! kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajackson at redhat.com Tue Mar 27 17:43:18 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 27 Mar 2007 13:43:18 -0400 Subject: VESA driver hsync config problem In-Reply-To: References: <1174917730.31911.10.camel@localhost.localdomain> <1174945236.1534.2.camel@localhost.localdomain> Message-ID: <1175017398.1534.16.camel@localhost.localdomain> On Tue, 2007-03-27 at 10:23 -0600, Xavier Toth wrote: > The error that kills the xserver ends up on stderr. This may be a bug > in the xserver or the Xinerama extension and I will pursue that. In > the meantime as an interim solution maybe you could direct me as to > how I could hack the system-config-display to add a HorizSync line to > the xorg.conf file. That log is not from any X server we've ever shipped. Neither the FC6 or FC7 X server will try to talk to dbus, or issue any error messages that look like that. - ajax From christoph.wickert at nurfuerspam.de Tue Mar 27 18:21:50 2007 From: christoph.wickert at nurfuerspam.de (Christoph Wickert) Date: Tue, 27 Mar 2007 20:21:50 +0200 Subject: xfce - unowned directories? In-Reply-To: <20070327111255.3352c09c@ghistelwchlohm.scrye.com> References: <20070326205342.ca2ccacc.mschwendt.tmp0701.nospam@arcor.de> <1174946387.4024.21.camel@hal9000.oberschlesier.lan> <20070327111255.3352c09c@ghistelwchlohm.scrye.com> Message-ID: <1175019710.5082.29.camel@hal9000.oberschlesier.lan> Am Dienstag, den 27.03.2007, 11:12 -0600 schrieb Kevin Fenzi: > On Mon, 26 Mar 2007 23:59:47 +0200 > christoph.wickert at nurfuerspam.de (Christoph Wickert) wrote: > > > Am Montag, den 26.03.2007, 20:53 +0200 schrieb Michael Schwendt: > > > Lost of unowned directories are reported for XFCE packages [1]. If > > > I were familiar with the dependency graph, I would know where to > > > start with suggesting fixes: > > > > I think Kevin can give us more insight, this is only what I see on a > > quick glance. > > Sorry for the delay in looking at this... been busy. ;( > [snipped] > > I will try and go through all this list tonight and see if I can clean > all these up. Any additional ideas or issues, let me know. So where does the dependency of the libs start? If I'm correct it's libxfce4util -> libxfcegui4 -> libxfce4mcs. In this case I think we could make the first one in this chain own the "basic" dirs like %{_libdir}/xfce4 %{_datadir}/xfce4 and %{_includedir}/xfce4 for the devel package. Or ist there a better way, especially for %{_datadir}? I still have no idea what to do with %{_datadir}/xfce4/doc. Ideas? Christoph From txtoth at gmail.com Tue Mar 27 18:26:19 2007 From: txtoth at gmail.com (Ted X Toth) Date: Tue, 27 Mar 2007 13:26:19 -0500 Subject: VESA driver hsync config problem In-Reply-To: <1175017398.1534.16.camel@localhost.localdomain> References: <1174917730.31911.10.camel@localhost.localdomain> <1174945236.1534.2.camel@localhost.localdomain> <1175017398.1534.16.camel@localhost.localdomain> Message-ID: <460961CB.7050503@gmail.com> I'm sorry if I didn't make it clear but as I mentioned in my original post I'm building and running the latest (7.2) with the XACE patches because of a requirement to run a trusted X. From what I understand this code base is what may be built in FC8 but you would know better than I. Hopefully you can still help me understand what would need to be done to get a xorg.conf that will function for our livecd :) Ted Adam Jackson wrote: > On Tue, 2007-03-27 at 10:23 -0600, Xavier Toth wrote: > >> The error that kills the xserver ends up on stderr. This may be a bug >> in the xserver or the Xinerama extension and I will pursue that. In >> the meantime as an interim solution maybe you could direct me as to >> how I could hack the system-config-display to add a HorizSync line to >> the xorg.conf file. >> > > That log is not from any X server we've ever shipped. Neither the FC6 > or FC7 X server will try to talk to dbus, or issue any error messages > that look like that. > > - ajax > > From kevin at scrye.com Tue Mar 27 18:42:25 2007 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 27 Mar 2007 12:42:25 -0600 Subject: xfce - unowned directories? In-Reply-To: <1175019710.5082.29.camel@hal9000.oberschlesier.lan> References: <20070326205342.ca2ccacc.mschwendt.tmp0701.nospam@arcor.de> <1174946387.4024.21.camel@hal9000.oberschlesier.lan> <20070327111255.3352c09c@ghistelwchlohm.scrye.com> <1175019710.5082.29.camel@hal9000.oberschlesier.lan> Message-ID: <20070327124225.30b51c9e@ghistelwchlohm.scrye.com> On Tue, 27 Mar 2007 20:21:50 +0200 christoph.wickert at nurfuerspam.de (Christoph Wickert) wrote: > Am Dienstag, den 27.03.2007, 11:12 -0600 schrieb Kevin Fenzi: > > On Mon, 26 Mar 2007 23:59:47 +0200 > > christoph.wickert at nurfuerspam.de (Christoph Wickert) wrote: > > > > > Am Montag, den 26.03.2007, 20:53 +0200 schrieb Michael Schwendt: > > > > Lost of unowned directories are reported for XFCE packages [1]. > > > > If I were familiar with the dependency graph, I would know > > > > where to start with suggesting fixes: > > > > > > I think Kevin can give us more insight, this is only what I see > > > on a quick glance. > > > > Sorry for the delay in looking at this... been busy. ;( > > > [snipped] > > > > I will try and go through all this list tonight and see if I can > > clean all these up. Any additional ideas or issues, let me know. > > So where does the dependency of the libs start? If I'm correct it's > libxfce4util -> libxfcegui4 -> libxfce4mcs. Yep. Thats exactly right. > In this case I think we could make the first one in this chain own the > "basic" dirs like > %{_libdir}/xfce4 > %{_datadir}/xfce4 > and %{_includedir}/xfce4 for the devel package. Or ist there a better > way, especially for %{_datadir}? Not that I can think of off hand. > I still have no idea what to do with %{_datadir}/xfce4/doc. Ideas? Thats owned by xfdesktop currently. Will have to check, but I think perhaps xfce-mcs-manager should own it, since the packages that need that dir I think already require xfce-mcs-manager, but perhaps it should be the panel? Will have to look. FYI, the build order/dependencies are: libxfce4util libxfcegui4 libxfce4mcs xfce-mcs-manager xfce4-panel gtk-xfce-engine exo Thunar Terminal (all the rest can be in any order as long as the above are done) xfce4-appfinder xfce4-icon-theme xfce4-mixer xfce4-session xfce-mcs-plugins xfce-utils xfdesktop xfprint xfwm4 xfwm4-themes orage mousepad > Christoph kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ajackson at redhat.com Tue Mar 27 19:00:26 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 27 Mar 2007 15:00:26 -0400 Subject: VESA driver hsync config problem In-Reply-To: <460961CB.7050503@gmail.com> References: <1174917730.31911.10.camel@localhost.localdomain> <1174945236.1534.2.camel@localhost.localdomain> <1175017398.1534.16.camel@localhost.localdomain> <460961CB.7050503@gmail.com> Message-ID: <1175022026.1534.19.camel@localhost.localdomain> On Tue, 2007-03-27 at 13:26 -0500, Ted X Toth wrote: > I'm sorry if I didn't make it clear but as I mentioned in my original > post I'm building and running the latest (7.2) with the XACE patches > because of a requirement to run a trusted X. From what I understand this > code base is what may be built in FC8 but you would know better than I. > Hopefully you can still help me understand what would need to be done to > get a xorg.conf that will function for our livecd :) X is coming up. GTK is crashing. Run "X -verbose :0" by itself and notice how your X server comes up just fine. Then control-alt-backspace, run startx, and watch the session fall over. The reason GTK is aborting is because the security extension is prohibiting it from doing things that it would normally otherwise do. In other words, you asked for it, and you got it. - ajax From limb at jcomserv.net Tue Mar 27 19:26:10 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 27 Mar 2007 14:26:10 -0500 (CDT) Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: <20070327151230.80f56c6a.mschwendt.tmp0701.nospam@arcor.de> References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <20070327121702.cc573e59.mschwendt.tmp0701.nospam@arcor.de> <20070327110837.GE2896@free.fr> <20070327151230.80f56c6a.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <59323.65.192.24.190.1175023570.squirrel@mail.jcomserv.net> So the consensus is to drop the dist tag from the Obsoletes? Rpmlint wants me to keep the Provides. Will that be a problem? > On Tue, 27 Mar 2007 13:08:37 +0200, Patrice Dumas wrote: > >> On Tue, Mar 27, 2007 at 12:17:02PM +0200, Michael Schwendt wrote: >> > On Tue, 27 Mar 2007 11:28:10 +0200, Patrice Dumas wrote: >> > > >> > > I suggest hardcoding the %{dist} to what it was when the package was >> > > merged (so I guess it is fc7 here). For the fc6 and fc5 packages it >> > > is not as clear, but I guess that using fc7 too would be safer. >> > >> > Questionable, albeit would serve as an ugly work-around. It would >> defeat >> > the purpose of the dist tag, since if you reused the spec for multiple >> > branches, it would make the fc5 package obsolete an fc7 package. >> >> Indeed, that's why I think what to do isn't really clear. 2 points >> if favor of having fc7 in all the specs is that it is really the >> 'latest' >> version shipped in fedora, and it can be the same for all the branches. >> Using %{dist} will get wrong when it becomes fc8. >> >> Maybe a solution could be to skip a release and obsolete that release >> without dist tag. For example: >> foo-0-4%{?dist} is the latest version with the subpackage foo-sub. >> next package is foo-0-6%{?dist} and in this package and above there is >> Obsolete: foo-sub <= 0-5 >> >> Maybe another possibility could be to use >> Obsoletes: ettercap-plugins < 0.7.3-15 >> Would that work? > > Yes. It would cover all the minor releases, too, which are > 14%{?dist}: > > ettercap-plugins - 0.7.3-14.fc5.3.i386 > ettercap-plugins - 0.7.3-14.fc5.3.ppc > ettercap-plugins - 0.7.3-14.fc5.3.x86_64 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From txtoth at gmail.com Tue Mar 27 19:39:39 2007 From: txtoth at gmail.com (Ted X Toth) Date: Tue, 27 Mar 2007 14:39:39 -0500 Subject: VESA driver hsync config problem In-Reply-To: <1175022026.1534.19.camel@localhost.localdomain> References: <1174917730.31911.10.camel@localhost.localdomain> <1174945236.1534.2.camel@localhost.localdomain> <1175017398.1534.16.camel@localhost.localdomain> <460961CB.7050503@gmail.com> <1175022026.1534.19.camel@localhost.localdomain> Message-ID: <460972FB.2040207@gmail.com> I agree that GTK is crashing and bringing down the server but I don't agree that it is doing so because of the XSELinux extension. First of all I'm currently running in permissive mode because the policy for the extension is still being developed so nothing really gets 'prohibited'. And then there's the fact that all I have to do is add a HorizSync line to my xorg.conf file and sure enough the xserver/gnome/... starts and life is good (albeit that the extension generates so many of its' idea of an avc that the log eats up all of my virtual disk space). Ted Adam Jackson wrote: > On Tue, 2007-03-27 at 13:26 -0500, Ted X Toth wrote: > >> I'm sorry if I didn't make it clear but as I mentioned in my original >> post I'm building and running the latest (7.2) with the XACE patches >> because of a requirement to run a trusted X. From what I understand this >> code base is what may be built in FC8 but you would know better than I. >> Hopefully you can still help me understand what would need to be done to >> get a xorg.conf that will function for our livecd :) >> > > X is coming up. GTK is crashing. > > Run "X -verbose :0" by itself and notice how your X server comes up just > fine. Then control-alt-backspace, run startx, and watch the session > fall over. > > The reason GTK is aborting is because the security extension is > prohibiting it from doing things that it would normally otherwise do. > In other words, you asked for it, and you got it. > > - ajax > > From caillon at redhat.com Tue Mar 27 20:03:14 2007 From: caillon at redhat.com (Christopher Aillon) Date: Tue, 27 Mar 2007 16:03:14 -0400 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: <20070327092810.GB2896@free.fr> References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> Message-ID: <46097882.9030802@redhat.com> Patrice Dumas wrote: > On Mon, Mar 26, 2007 at 09:59:35PM -0400, Jon Ciesla wrote: >> -Provides: ettercap-plugins <= %{version} >> +Obsoletes: ettercap-plugins <= 0.7.3-14%{dist} > > I suggest hardcoding the %{dist} to what it was when the package was > merged (so I guess it is fc7 here). For the fc6 and fc5 packages it > is not as clear, but I guess that using fc7 too would be safer. Obsoletes: ettercap-plugins < 0.7.3-15 From kevin.kofler at chello.at Tue Mar 27 20:12:00 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 27 Mar 2007 20:12:00 +0000 (UTC) Subject: hplip: hp-toolbox advertising? References: <1174946404.2622.98.camel@zelda.fubar.dk> Message-ID: David Zeuthen fubar.dk> writes: > - Provide their own UI for using the device; just provide the drivers, > thank you very much; we don't really need foreign tools to make this > harder on the users. Bad. And we (users of HP printers) are supposed to check the ink levels, clean the cartridges etc. how then? Where's the non-"foreign" (i.e. non-vendor) tools to handle this? Oh wait, there aren't any... > - All the HP stuff, since there is a lot of it, pulls in Qt So what? How is it better if it pulls in GTK+ instead? Not all the world uses GNOME... Now they couldn't provide a GUI tool at all, but then see the above paragraph for why that would be a bad idea. > Instead, for example, HP should get their scanner drivers into the SANE > project. My personal opinion is that with HPLip, HP is paying lip > service to the Linux community by treating us as if we were Windows > where this sort of "let's throw lots of vendor-specific tools and UI > crap at the user" is common. My personal opinion is that thanks to hplip, HP printers are the ones which support Free Software the best. > HP: please try to be a good open source citizen. Sure, about the daemon, the user-space vfat driver etc., the implementation of hplip could be less of a mess, but it's all vendor-provided GPL code! There aren't many vendors doing that. So calling HP "not a good open source citizen" just because their GPL code doesn't fit your standards of quality is really unfair IMHO. As for the actual issue in this thread, I have a suggestion: what about making hp-toolbox a separate subpackage of hplip, which is not installed by default, but which (when installed) comes with a menu item? That would solve both the "vendor-specific menu item forced on everyone" and the "hplip requires PyQt" issues. Kevin Kofler From david at fubar.dk Tue Mar 27 20:13:13 2007 From: david at fubar.dk (David Zeuthen) Date: Tue, 27 Mar 2007 16:13:13 -0400 Subject: rawhide report: 20070327 changes In-Reply-To: <20070327171430.GD2888@free.fr> References: <200703271003.l2RA3n8o028666@hs20-bc2-6.build.redhat.com> <1175001195.15998.4.camel@localhost.localdomain> <1175012165.3142.6.camel@zelda.fubar.dk> <20070327171430.GD2888@free.fr> Message-ID: <1175026393.3142.45.camel@zelda.fubar.dk> On Tue, 2007-03-27 at 19:14 +0200, Patrice Dumas wrote: > On Tue, Mar 27, 2007 at 12:16:05PM -0400, David Zeuthen wrote: > > On Tue, 2007-03-27 at 14:13 +0100, Richard Hughes wrote: > > > On Tue, 2007-03-27 at 06:03 -0400, buildsys at redhat.com wrote: > > > > Updated Packages: > > > > > > Also, are we going to rebuild dbus without asserts for F7T3? > > > > To be determined; I'd rather like to see bad apps getting (like HAL; > > git20070304 had issues that are hopefully resolved by git20070326) fixed > > before applying a such a band aid. > > Maybe what could be done would be to rebuild dbus without asserts > for the final version only? Yeah, that was my plan. If it turns out that disabling asserts will improve the quality of the Fedora 7 release, I'll do it. But right now I want to get people to fix their apps and disabling the asserts right now will work against that goal. David From ajackson at redhat.com Tue Mar 27 19:55:51 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 27 Mar 2007 15:55:51 -0400 Subject: VESA driver hsync config problem In-Reply-To: <460972FB.2040207@gmail.com> References: <1174917730.31911.10.camel@localhost.localdomain> <1174945236.1534.2.camel@localhost.localdomain> <1175017398.1534.16.camel@localhost.localdomain> <460961CB.7050503@gmail.com> <1175022026.1534.19.camel@localhost.localdomain> <460972FB.2040207@gmail.com> Message-ID: <1175025351.1534.21.camel@localhost.localdomain> On Tue, 2007-03-27 at 14:39 -0500, Ted X Toth wrote: > I agree that GTK is crashing and bringing down the server but I don't > agree that it is doing so because of the XSELinux extension. First of > all I'm currently running in permissive mode because the policy for the > extension is still being developed so nothing really gets 'prohibited'. > And then there's the fact that all I have to do is add a HorizSync line > to my xorg.conf file and sure enough the xserver/gnome/... starts and > life is good (albeit that the extension generates so many of its' idea > of an avc that the log eats up all of my virtual disk space). The X log you gave earlier from running under Parallels shows it _not_ using any HorizSync line from the config file, and starting up at the perfectly expected 800x600. - ajax From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 20:16:59 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Tue, 27 Mar 2007 14:16:59 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: Message-ID: Bernard Johnson wrote: > I was working on finding/reporting some bugs with the hplip package and > noticed that there was no menu entry. Knowing that a graphical program > with no menu entry wasn't the norm, I was about to file a bug, except > when searching for a duplicate, I came across this: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170762 > > > mclasen at redhat.com: > "We don't give free ad space to HP on our menus..." > > 3) And the in F7, there will be CodecBuddy > (http://fedoraproject.org/wiki/Releases/FeatureCodecBuddy) which will > direct users to the Fluendo Webshop (https://shop.fluendo.com/) to > purchase proprietary codes when they try to play media that they do not > have a code for (http://hadessuk.blogspot.com/2007/03/totem-news.html). Although I originally posted regarding the hp-toolbox bug, I had hoped for a much wider opinion regarding advertising (and the discussion as it turned to trademarks as well). Are we ok with letting CodecBuddy direct users to the Fluendo webstore? Are there going to be providions for equal access for other vendors? Also, for example. CUPS admin page has the "Easy Software Products" logo, and a link to the "Pro" version of the product and the companies home page which has products for sale. Is this ok? From limb at jcomserv.net Tue Mar 27 20:15:07 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 27 Mar 2007 15:15:07 -0500 (CDT) Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: <46097882.9030802@redhat.com> References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <46097882.9030802@redhat.com> Message-ID: <64171.65.192.24.190.1175026507.squirrel@mail.jcomserv.net> Thanks. Got a bit turned around. :) > Patrice Dumas wrote: >> On Mon, Mar 26, 2007 at 09:59:35PM -0400, Jon Ciesla wrote: >>> -Provides: ettercap-plugins <= %{version} >>> +Obsoletes: ettercap-plugins <= 0.7.3-14%{dist} >> >> I suggest hardcoding the %{dist} to what it was when the package was >> merged (so I guess it is fc7 here). For the fc6 and fc5 packages it >> is not as clear, but I guess that using fc7 too would be safer. > > Obsoletes: ettercap-plugins < 0.7.3-15 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From cmadams at hiwaay.net Tue Mar 27 20:28:03 2007 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 27 Mar 2007 15:28:03 -0500 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: Message-ID: <20070327202803.GF1319577@hiwaay.net> Once upon a time, Bernard Johnson said: > Also, for example. CUPS admin page has the "Easy Software Products" > logo, and a link to the "Pro" version of the product and the companies > home page which has products for sale. Is this ok? IIRC the MySQL initial setup script advertises that MySQL.com sells commercial licenses. Is someone going to go through and "audit" for this kind of thing? What are you going to do - remove such messages? That is kind of rude to the people working to provide software freely. I have HP laser printers both at home and at work, and this discussion is the first I had heard of the HP tools. I just checked them out, and they look useful for HP users. What is the objection? Every other app (at least GUI apps) gets a menu entry, and that includes an app-chosen logo/icon. Why is this one any different (as long as the image license is suitable)? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jkeating at redhat.com Tue Mar 27 20:45:24 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Mar 2007 16:45:24 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: Message-ID: <200703271645.24712.jkeating@redhat.com> On Tuesday 27 March 2007 16:16:59 Bernard Johnson wrote: > Are we ok with letting CodecBuddy direct users to the Fluendo webstore? > ?Are there going to be providions for equal access for other vendors? I personally had thought that codecbuddy was going to drive users to a fedoraproject.org page which would give more information and list possible vendors for the codec. If Fluendo is the only possible vendor, that's fine, but we would own the page that codecbuddy drives to and thus own the content listed and could add/remove vendors at our will. Is that not the case? -- 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 txtoth at gmail.com Tue Mar 27 20:45:12 2007 From: txtoth at gmail.com (Ted X Toth) Date: Tue, 27 Mar 2007 15:45:12 -0500 Subject: VESA driver hsync config problem In-Reply-To: <1175025351.1534.21.camel@localhost.localdomain> References: <1174917730.31911.10.camel@localhost.localdomain> <1174945236.1534.2.camel@localhost.localdomain> <1175017398.1534.16.camel@localhost.localdomain> <460961CB.7050503@gmail.com> <1175022026.1534.19.camel@localhost.localdomain> <460972FB.2040207@gmail.com> <1175025351.1534.21.camel@localhost.localdomain> Message-ID: <46098258.8040200@gmail.com> Correct x.log (which is a capture of stdout and stderr and not the real log file, Xorg.0.log) was a capture of the failure mode, no HorizSync in the config file. I sent that because the GTK error message doesn't get written to Xorg.0.log. So the scenario is the server seems to be coming up just fine then the GTK error occurs and the server aborts. The way I originally figured out to add HorizSync to the config file was by debugging through the server and seeing a huge obviously invalid value for the horizontal sync. What I'm going to do is go back and figure out exactly where that value was coming from and hopefully that will shed some light on the root of the problem. Adam Jackson wrote: > On Tue, 2007-03-27 at 14:39 -0500, Ted X Toth wrote: > >> I agree that GTK is crashing and bringing down the server but I don't >> agree that it is doing so because of the XSELinux extension. First of >> all I'm currently running in permissive mode because the policy for the >> extension is still being developed so nothing really gets 'prohibited'. >> And then there's the fact that all I have to do is add a HorizSync line >> to my xorg.conf file and sure enough the xserver/gnome/... starts and >> life is good (albeit that the extension generates so many of its' idea >> of an avc that the log eats up all of my virtual disk space). >> > > The X log you gave earlier from running under Parallels shows it _not_ > using any HorizSync line from the config file, and starting up at the > perfectly expected 800x600. > > - ajax > > From drago01 at gmail.com Tue Mar 27 20:49:34 2007 From: drago01 at gmail.com (dragoran) Date: Tue, 27 Mar 2007 22:49:34 +0200 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: Message-ID: <4609835E.6080602@gmail.com> Bernard Johnson wrote: > > And for the record, I am *not against* pulling hplip from Fedora if > that's the consensus. I am however against inconsistency in packages > and application of policies across the distribution. > > I don't use it myself but removing a software that supports that many devices that else would be useless on fedora is simply wrong. and if we say foo is in the package guidlines but package bar sucks so I won't honour point x is silly. either get the package or the guidlines fixed. From mclasen at redhat.com Tue Mar 27 21:02:35 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 27 Mar 2007 17:02:35 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: <4609835E.6080602@gmail.com> References: <4609835E.6080602@gmail.com> Message-ID: <1175029355.3182.0.camel@localhost.localdomain> On Tue, 2007-03-27 at 22:49 +0200, dragoran wrote: > > I don't use it myself but removing a software that supports that many > devices that else would be useless on fedora is simply wrong. > and if we say foo is in the package guidlines but package bar sucks so I > won't honour point x is silly. > either get the package or the guidlines fixed. > Oh, I have complained about that part of the guidelines before, but without success. From tmus at tmus.dk Tue Mar 27 20:28:30 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 27 Mar 2007 22:28:30 +0200 Subject: Presto logging In-Reply-To: <200703270722.16707.jkeating@redhat.com> References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> <200703261753.26784.jkeating@redhat.com> <200703270722.16707.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Tuesday 27 March 2007 00:59:57 Thomas M Steenholdt wrote: >> as long as >> he remembers to put a simple date in a file, when he's done. > > Which calls for special syncing. And there is no guarantee that they'll > create the date file before or after the sync, so we'll still have to > validate the age of the repomd files. > That's the whole point. We need to specify/document/demand the order in which the sync phases are carried out (remove date file, sync, create date file). The sync part is entirely up to the mirror admin, but the other parts are not. For a mirror to be considered official, they'd have to obey to these rules (I can't imagine, creating a timestamped file would be a huge obstacle for most mirrorsites). The date of the repomd.xml file is really another issue. It'll let you know the age of the repository contents, but it's not suitable for checking mirror sync status since you'd need to remove it for sync, and thus disabling the use of your mirror for updating, while syncing. Various different approaches can be taken to make this better, but IMO, none that I've seen or heard are as simple as the date file method. /Thomas From ajackson at redhat.com Tue Mar 27 20:59:02 2007 From: ajackson at redhat.com (Adam Jackson) Date: Tue, 27 Mar 2007 16:59:02 -0400 Subject: VESA driver hsync config problem In-Reply-To: <46098258.8040200@gmail.com> References: <1174917730.31911.10.camel@localhost.localdomain> <1174945236.1534.2.camel@localhost.localdomain> <1175017398.1534.16.camel@localhost.localdomain> <460961CB.7050503@gmail.com> <1175022026.1534.19.camel@localhost.localdomain> <460972FB.2040207@gmail.com> <1175025351.1534.21.camel@localhost.localdomain> <46098258.8040200@gmail.com> Message-ID: <1175029142.1534.25.camel@localhost.localdomain> On Tue, 2007-03-27 at 15:45 -0500, Ted X Toth wrote: > Correct x.log (which is a capture of stdout and stderr and not the real > log file, Xorg.0.log) was a capture of the failure mode, no HorizSync > in the config file. I sent that because the GTK error message doesn't > get written to Xorg.0.log. So the scenario is the server seems to be > coming up just fine then the GTK error occurs and the server aborts. > The way I originally figured out to add HorizSync to the config file was > by debugging through the server and seeing a huge obviously invalid > value for the horizontal sync. What I'm going to do is go back and > figure out exactly where that value was coming from and hopefully that > will shed some light on the root of the problem. Please don't top post. You're still managing to avoid the original question here, which is "what should the vesa driver do when it notices it's being run under Parallels". Every log I've seen from you is of the server _starting_, and getting far enough that it can actually serve clients. We can easily fix the vesa driver to do something smarter in that situation, which avoids ever screwing with the config file, or with the horror of s-c-d. - ajax From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 21:27:55 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Tue, 27 Mar 2007 15:27:55 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <200703271645.24712.jkeating@redhat.com> References: <200703271645.24712.jkeating@redhat.com> Message-ID: Jesse Keating wrote: > On Tuesday 27 March 2007 16:16:59 Bernard Johnson wrote: >> Are we ok with letting CodecBuddy direct users to the Fluendo webstore? >> Are there going to be providions for equal access for other vendors? > > I personally had thought that codecbuddy was going to drive users to a > fedoraproject.org page which would give more information and list possible > vendors for the codec. If Fluendo is the only possible vendor, that's fine, > but we would own the page that codecbuddy drives to and thus own the content > listed and could add/remove vendors at our will. Is that not the case? Unfortunately, I don't think there is enough in rawhide to preview. You might be right (and your description would probably work great and be fair), but... My assumption was based on http://hadessuk.blogspot.com/2007/03/totem-news.html In this screenshot, it looks like the application is pulling the information directly from the Fluendo webshop (their description, their price). From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 21:28:20 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Tue, 27 Mar 2007 15:28:20 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175029355.3182.0.camel@localhost.localdomain> References: <4609835E.6080602@gmail.com> <1175029355.3182.0.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: > On Tue, 2007-03-27 at 22:49 +0200, dragoran wrote: >> >> I don't use it myself but removing a software that supports that many >> devices that else would be useless on fedora is simply wrong. >> and if we say foo is in the package guidlines but package bar sucks so I >> won't honour point x is silly. >> either get the package or the guidlines fixed. >> > > Oh, I have complained about that part of the guidelines before, but > without success. > And this is primarily where I have a problem. There is packaging guideline. You have tried to get them changed, and couldn't. But that didn't stop you from ignoring them in this particular case. So take your complaint to remove the icon from the menus to the packaging committee for an exception to the policy, or a change to the policy. A heavy handed approach ignoring policy along the way to suit your personal views is not the right answer. From txtoth at gmail.com Tue Mar 27 21:39:54 2007 From: txtoth at gmail.com (Ted X Toth) Date: Tue, 27 Mar 2007 16:39:54 -0500 Subject: VESA driver hsync config problem In-Reply-To: <1175029142.1534.25.camel@localhost.localdomain> References: <1174917730.31911.10.camel@localhost.localdomain> <1174945236.1534.2.camel@localhost.localdomain> <1175017398.1534.16.camel@localhost.localdomain> <460961CB.7050503@gmail.com> <1175022026.1534.19.camel@localhost.localdomain> <460972FB.2040207@gmail.com> <1175025351.1534.21.camel@localhost.localdomain> <46098258.8040200@gmail.com> <1175029142.1534.25.camel@localhost.localdomain> Message-ID: <46098F2A.3010801@gmail.com> Adam Jackson wrote: > On Tue, 2007-03-27 at 15:45 -0500, Ted X Toth wrote: > >> Correct x.log (which is a capture of stdout and stderr and not the real >> log file, Xorg.0.log) was a capture of the failure mode, no HorizSync >> in the config file. I sent that because the GTK error message doesn't >> get written to Xorg.0.log. So the scenario is the server seems to be >> coming up just fine then the GTK error occurs and the server aborts. >> The way I originally figured out to add HorizSync to the config file was >> by debugging through the server and seeing a huge obviously invalid >> value for the horizontal sync. What I'm going to do is go back and >> figure out exactly where that value was coming from and hopefully that >> will shed some light on the root of the problem. >> > > Please don't top post. > > You're still managing to avoid the original question here, which is > "what should the vesa driver do when it notices it's being run under > Parallels". Every log I've seen from you is of the server _starting_, > and getting far enough that it can actually serve clients. > > We can easily fix the vesa driver to do something smarter in that > situation, which avoids ever screwing with the config file, or with the > horror of s-c-d. > > - ajax > > I'm not avoiding the question at this point I just don't know what the right answer is. When I have more information I'll post again. Ted From jkeating at redhat.com Tue Mar 27 21:42:33 2007 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 27 Mar 2007 17:42:33 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <200703271645.24712.jkeating@redhat.com> Message-ID: <200703271742.34119.jkeating@redhat.com> On Tuesday 27 March 2007 17:27:55 Bernard Johnson wrote: > My assumption was based on > http://hadessuk.blogspot.com/2007/03/totem-news.html > > In this screenshot, it looks like the application is pulling the > information directly from the Fluendo webshop (their description, their > price). Surely where a codecbuddy points to would be configurable by the distribution packaging it up. The upstream codecbuddy needs a default place to point to, and that may well be fluendo. However as a downstream, we can choose to point it wherever we as a distribution feel it should go. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available URL: From overholt at redhat.com Tue Mar 27 21:41:44 2007 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 27 Mar 2007 17:41:44 -0400 Subject: SoC idea: Review Web App In-Reply-To: <1174602937.5105.12.camel@localhost.localdomain> References: <20070322001446.GA13508@redhat.com> <1174523891.23909.12.camel@localhost.localdomain> <20070322173624.GI1511@redhat.com> <1174602937.5105.12.camel@localhost.localdomain> Message-ID: <20070327214144.GC4330@redhat.com> Hi, On Thu, 2007-22-03 at 15:35 -0700, Toshio Kuratomi wrote: > What are the goals of the [review] web app? To move > away from bugzilla? Which features in particular are not meeting our > needs on bugzilla and which does bugzilla do well? What do we want to > do with the data from reviews? If we tie this into preapproval builds, > do we have to do reviews of untrusted packages before submitting to mock > or is mock sufficiently secure to do a build up front? These are good questions. I think in my opinion the problems with the review process boil down to: . review requirements spread out over multiple wiki pages . review requirements that are changing . workflow involves too many different websites and bugs I'd love to see a tool that allowed people to upload an SRPM directly and then put it somewhere accessible to others (including the reviewer). We could automate a lot of the rpmlint and build checking as well. Then the requirements that we can't automate can be pulled live and presented to the reviewer in a side-by-side web app with checkboxes and comment fields. Something like the Mondrian code review tool developed at Google [1]. Sorry I didn't get back sooner as I realize this won't make this year's SoC. I'd still like to think about it as it'd be a great project for a Fedora contributor. Andrew [1] http://video.google.com/videoplay?docid=-8502904076440714866 From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 21:46:57 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Tue, 27 Mar 2007 15:46:57 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175000711.7553.6.camel@zod.rchland.ibm.com> References: <1174965859.24384.1.camel@localhost.localdomain> <200703270846.19935.jkeating@redhat.com> <1175000711.7553.6.camel@zod.rchland.ibm.com> Message-ID: Josh Boyer wrote: > I'd like to point out that there is likely a trademark issue involved > here as well. Unless the package has an explicit grant to display the > HP trademark even if patches are made, I'm sure it'll get sticky. > > That might be a bit easier to swallow than "free advertisement". So, I wonder if we also have a grant to the word "bluetooth" since it's a certification mark? I would guess not. http://tess2.uspto.gov/bin/showfield?f=doc&state=stgctl.2.8 "THE CERTIFICATION MARK CERTIFIES THAT GOODS MANUFACTURED AND SERVICES RENDERED BY AUTHORIZED PERSONS COMPLY WITH THE QUALITY AND/OR INTEROPERABILITY STANDARDS ESTABLISHED BY BLUETOOTH SIG, INC." From pertusus at free.fr Tue Mar 27 21:49:01 2007 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 27 Mar 2007 23:49:01 +0200 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: <59323.65.192.24.190.1175023570.squirrel@mail.jcomserv.net> References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <20070327121702.cc573e59.mschwendt.tmp0701.nospam@arcor.de> <20070327110837.GE2896@free.fr> <20070327151230.80f56c6a.mschwendt.tmp0701.nospam@arcor.de> <59323.65.192.24.190.1175023570.squirrel@mail.jcomserv.net> Message-ID: <20070327214901.GC3252@free.fr> On Tue, Mar 27, 2007 at 02:26:10PM -0500, Jon Ciesla wrote: > So the consensus is to drop the dist tag from the Obsoletes? Rpmlint > wants me to keep the Provides. Will that be a problem? No, the Provides is right as it is now. It is right that the sub-package is provided with the current version. -- Pat From kevin.kofler at chello.at Tue Mar 27 21:56:09 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 27 Mar 2007 21:56:09 +0000 (UTC) Subject: hplip: hp-toolbox advertising? References: <4609835E.6080602@gmail.com> <1175029355.3182.0.camel@localhost.localdomain> Message-ID: Bernard Johnson symetrix.com> writes: > So take your complaint to remove the icon from the menus to the > packaging committee for an exception to the policy, or a change to the > policy. A heavy handed approach ignoring policy along the way to suit > your personal views is not the right answer. What about the subpackage solution I suggested? > As for the actual issue in this thread, I have a suggestion: what about > making hp-toolbox a separate subpackage of hplip, which is not installed by > default, but which (when installed) comes with a menu item? That would solve > both the "vendor-specific menu item forced on everyone" and the "hplip > requires PyQt" issues. (Like you, I also think installing GUI programs without a menu entry is bad. They should be either installed or not installed, not installed-but-hidden.) Kevin Kofler From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 22:17:54 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Tue, 27 Mar 2007 16:17:54 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <4609835E.6080602@gmail.com> <1175029355.3182.0.camel@localhost.localdomain> Message-ID: Kevin Kofler wrote: > What about the subpackage solution I suggested? I think it may be possible to split it to a certain extent, but it is more complicated that most think. For example... When you print to the scanner, the hpiod(?) program catches it and stores it until you start the hp-sendfax program. This program then retrieves the fax and take information like phone number and such so that it can be sent. If hp-sendfax is not installed faxing is not functional. It also appears that the underlying functionality of the python code is tied intimately to the gui because the program uses PyQT IPC. You can find the description of that here: http://permalink.gmane.org/gmane.comp.printing.hplip.devel/250 (Call it a design mistake or whatever) So I *think* it might be possible to split the hpio* daemons to a base package (just providing basic printing) and the have all gui and MIO functions (ie. status, fax, clean, copy, etc) in a subpackage. Tim Waugh or maybe David Zeuthen would probably be able to better comment on that. From bernie at develer.com Tue Mar 27 22:21:14 2007 From: bernie at develer.com (Bernardo Innocenti) Date: Wed, 28 Mar 2007 00:21:14 +0200 Subject: dropping autoconf dependency on imake Message-ID: <460998DA.1000407@develer.com> Why does it need imake? Can we get rid of it? -- // Bernardo Innocenti - Develer R&D dept. \X/ http://www.develer.com/ From sundaram at fedoraproject.org Tue Mar 27 22:36:45 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 28 Mar 2007 04:06:45 +0530 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <200703271645.24712.jkeating@redhat.com> Message-ID: <46099C7D.3080008@fedoraproject.org> Bernard Johnson wrote: > Jesse Keating wrote: >> On Tuesday 27 March 2007 16:16:59 Bernard Johnson wrote: >>> Are we ok with letting CodecBuddy direct users to the Fluendo webstore? >>> Are there going to be providions for equal access for other vendors? >> I personally had thought that codecbuddy was going to drive users to a >> fedoraproject.org page which would give more information and list possible >> vendors for the codec. If Fluendo is the only possible vendor, that's fine, >> but we would own the page that codecbuddy drives to and thus own the content >> listed and could add/remove vendors at our will. Is that not the case? > > Unfortunately, I don't think there is enough in rawhide to preview. You > might be right (and your description would probably work great and be > fair), but... > > My assumption was based on > http://hadessuk.blogspot.com/2007/03/totem-news.html > > In this screenshot, it looks like the application is pulling the > information directly from the Fluendo webshop (their description, their > price). The way UI works on the codec buddy is described in the blog is not what will be ultimately in Fedora. I brought this up on Fedora Board meeting today. Here is how it is expected to work. * When the user clicks a mp3 file, instead of missing codec errors there will be a popup where the user can either choose to learn about Free (in both ways) alternatives or click to install the free codec supplied by Fluendo (Fleundo has the necessary patent licenses so this is a legal in US) which is under a MIT X11 license or cancel the whole thing. The user experience here is very similar to what happens when you visit a website which needs Flash plugin the first time in Firefox except that in addition we would explain to them that there are better Free alternatives and the reason why we don't provide these codecs by default in Fedora. This way we get to keep Fedora entirely Free and open source software while solving the usability issue of not being able to play some of the content to a good extend (wont be very helpful folks who dont network access so it is not 100% solved yet). * For the other paid as well as proprietary codecs, the user would be directed to a Fedora Project page where they can again learn about better Free alternatives. In the page we would also list Fluendo as a vendor providing licensed and paid proprietary codecs. If there are vendors who are involved we can very well list them. So there is a level playing field here. Comments? Rahul From bjohnson-dated-1172832473.ba5e95 at symetrix.com Tue Mar 27 23:15:21 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Tue, 27 Mar 2007 17:15:21 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <46099C7D.3080008@fedoraproject.org> References: <200703271645.24712.jkeating@redhat.com> <46099C7D.3080008@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > * When the user clicks a mp3 file, instead of missing codec errors > there will be a popup where the user can either choose to learn about > Free (in both ways) alternatives or click to install the free codec > supplied by Fluendo (Fleundo has the necessary patent licenses so this > is a legal in US) which is under a MIT X11 license or cancel the whole > thing. The user experience here is very similar to what happens when > you visit a website which needs Flash plugin the first time in Firefox > except that in addition we would explain to them that there are better > Free alternatives and the reason why we don't provide these codecs by > default in Fedora. This way we get to keep Fedora entirely Free and open > source software while solving the usability issue of not being able to > play some of the content to a good extend (wont be very helpful folks > who dont network access so it is not 100% solved yet). > > * For the other paid as well as proprietary codecs, the user would be > directed to a Fedora Project page where they can again learn about > better Free alternatives. In the page we would also list Fluendo as a > vendor providing licensed and paid proprietary codecs. If there are > vendors who are involved we can very well list them. So there is a level > playing field here. > > Comments? Thank you for the clarification. The only problem I see, if I understand you, is that the mp3 codec is sole-sourced to Fluendo. I understand that Fluendo is the only vendor to providing a legal alternative today, but we should have the ability to allow multiple vendors at that step. From sundaram at fedoraproject.org Tue Mar 27 23:52:34 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 28 Mar 2007 05:22:34 +0530 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <200703271645.24712.jkeating@redhat.com> <46099C7D.3080008@fedoraproject.org> Message-ID: <4609AE42.8070009@fedoraproject.org> Bernard Johnson wrote: > Thank you for the clarification. The only problem I see, if I > understand you, is that the mp3 codec is sole-sourced to Fluendo. I > understand that Fluendo is the only vendor to providing a legal > alternative today, but we should have the ability to allow multiple > vendors at that step. We do it this way because * Fleundo is the company that employs many (most?) of the gstreamer developers that provides us with a Free multimedia framework. This is one way of acknowledging their efforts. * It is a gratis solution and a commonly requested feature. * If we provide redirects it is just a additional step over making it a click through option which is more usable. Like you said there really isn't any choice of vendors to provide the same feature and providing a theoretical level playing feature for a gratis component does not appear to important as opposed to the usability advantage at this point. If there are other vendors in the future we can reconsider what we need to do. The hooks for codec buddy are already in upstream gstreamer, nothing is hard coded and we can change this very easily. Rahul From bjohnson-dated-1172832473.ba5e95 at symetrix.com Wed Mar 28 01:04:21 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Tue, 27 Mar 2007 19:04:21 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <4609AE42.8070009@fedoraproject.org> References: <200703271645.24712.jkeating@redhat.com> <46099C7D.3080008@fedoraproject.org> <4609AE42.8070009@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Bernard Johnson wrote: > >> Thank you for the clarification. The only problem I see, if I >> understand you, is that the mp3 codec is sole-sourced to Fluendo. I >> understand that Fluendo is the only vendor to providing a legal >> alternative today, but we should have the ability to allow multiple >> vendors at that step. > > We do it this way because > > * Fleundo is the company that employs many (most?) of the gstreamer > developers that provides us with a Free multimedia framework. This is > one way of acknowledging their efforts. For the record, I am not against this at all... but * Hewlett Packard is the company that employs many of the hplip developers that provide the free hplip software. This software supports 1100+ printer models. > * It is a gratis solution and a commonly requested feature. The hplip software is GPL and not intentionally feature-limited in any way. One must assume that if you want to print to your HP printer, it would be a commonly requested feature given the market penetration of HP. (It was important enough to include at FC-4 anyway) > * If we provide redirects it is just a additional step over making it a > click through option which is more usable. Like you said there really > isn't any choice of vendors to provide the same feature and providing a > theoretical level playing feature for a gratis component does not appear > to important as opposed to the usability advantage at this point. There are no vendors that provide the same level of functionality as the hplip software. > If there are other vendors in the future we can reconsider what we need > to do. The hooks for codec buddy are already in upstream gstreamer, > nothing is hard coded and we can change this very easily. Today, we do not allow the hp-toolbox to have an icon on the menu. Now, I do not disagree with the direction taken with CodecBuddy (this I stated in my original email). I very much disagree with lack of impartiality between vendors who are both supporting Linux. Given that the original argument against the hp-toolbox menu item was because it was advertising, the Fluendo agreement goes /far/ beyond that. I should also point that that the "advertising" HP gets has no directly -tied revenue (ie. it doesn't not direct anyone to a website to purchase anything). At the same time, Fluendo will directly profit from the CodecBuddy tie-in. And please, before anyone goes down the "but I don't like the HP software" rant road, get a reality check. Show me software that can be used to get the same functionality. We told HP that we wanted Linux support, and not only did they give us printing support, they supported the whole MIO ball of wax. As far as I understand it, they are also paying for the continued development of the software AND support in the newsgroups. Compare that to Broadcom(wireless)/Nvidia/ATI who we also asked to support Linux. Two companies gave us blobs and said "trust us, it's great software!", while another said "get bent"[1] and the only reason we have support at all today with this vendor is because someone reverse engineered the chip and developed the ability to load a firmware blob. All the "free software zealots" say to vote with your pocketbook. I did. I bought a $1000 SOHO printer BECAUSE THEY HAD LINUX SUPPORT. And not just a blob, real GPL software. Now I hear total bogus arguments like "it's advertising" [but don't look at these other things that are advertising as well that we will let slide] or "yeah, it's free but it's not good enough"[2][3]. This is exactly the attitude that will cause Linux to not get any support by vendors. The fact of the matter is that it takes vendor support to make Fedora/RedHat anything other than a toy operating system for many uses. At many junctures, we have to make conscious trade offs between idealogical beliefs and functionality. That trade off may be a little recognition of the hard work that someone / some company put into the software, and I say that's great, give it to them. But to actually go out of your way to make it harder for the end-user it beyond comprehension. There are already multiple bugs filed on this issue, and I would have filed one too had I not looked at the spec file. It's not like Linux doesn't have enough hurdles (potential patent pitfalls, trademark issues[4], brand recognition, user-base fragmentation, etc), let's not create more problems just for the fun of it. [1] That wasn't the real response, but since they are ignoring the issue, it's clear that they don't care. [2] Where "good enough" seems to be based on idealism and by people who don't even use the software. [3] I can consistently break the bcm43xx stack, but you don't see me screaming that it sucks and we should disable it. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233729 [4] See my response in this thread regarding potential bluetooth problems. From louisg00 at bellsouth.net Tue Mar 27 22:55:16 2007 From: louisg00 at bellsouth.net (Louis E Garcia II) Date: Tue, 27 Mar 2007 18:55:16 -0400 Subject: Wireless question in F7 Message-ID: <1175036116.9405.1.camel@sonlaptop> Are both wireless stacks going to be included in F7? -Louis From davej at redhat.com Wed Mar 28 02:57:03 2007 From: davej at redhat.com (Dave Jones) Date: Tue, 27 Mar 2007 22:57:03 -0400 Subject: Wireless question in F7 In-Reply-To: <1175036116.9405.1.camel@sonlaptop> References: <1175036116.9405.1.camel@sonlaptop> Message-ID: <20070328025703.GA16607@redhat.com> On Tue, Mar 27, 2007 at 06:55:16PM -0400, Louis E Garcia II wrote: > Are both wireless stacks going to be included in F7? mac80211 will be included alongside the existing upstream ieee80211 stuff (which isn't really a 'stack', more a library). Dave -- http://www.codemonkey.org.uk From ssorce at redhat.com Wed Mar 28 03:18:58 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 27 Mar 2007 23:18:58 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: <20070327171707.GE2888@free.fr> References: <1175003615.7553.12.camel@zod.rchland.ibm.com> <46092AC6.70408@fedoraproject.org> <46092F16.1010608@nicubunu.ro> <460936A3.4070408@fedoraproject.org> <1175009409.6100.4.camel@willson> <20070327171707.GE2888@free.fr> Message-ID: <1175051938.32396.3.camel@willson> On Tue, 2007-03-27 at 19:17 +0200, Patrice Dumas wrote: > On Tue, Mar 27, 2007 at 11:30:08AM -0400, Simo Sorce wrote: > > > > > > Thanks, though I'd argue mixing-n-matching licenses within a (single) > > > package is bad form. > > > > No, there are countless packages with differently licensed files in > > them. GPL+LGPL, GPL+(new)BSD, GPL+MIT, MIT+BSD, and on and on and on... > > In those cases the whole package is under the GPL (and, arguably > MIT/BSD are almost the same). When there are other mixes it may be less > clear. No, not really, you can have a package that provide different binaries. For example the samba package is mostly GPL software except for pam_winbind and nss_winbind, which are not under the GPL. The "whole package" does not mean much. It's the single binaries+libraries that count. I can very well see us distributing something like, let's say Xorg, with a little GPLed GUI in the same package, this does not make the whole package GPLed. Simo. From rdieter at math.unl.edu Wed Mar 28 03:42:08 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 27 Mar 2007 22:42:08 -0500 Subject: k3b-extras (Re: Summary - Broken dependencies in Fedora Extras - 2007-03-27) In-Reply-To: <20070327151520.2bfaf712.mschwendt.tmp0701.nospam@arcor.de> References: <20070327124942.17654.49220@extras64.linux.duke.edu> <20070327151520.2bfaf712.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt wrote: > On Tue, 27 Mar 2007 08:08:07 -0500, Rex Dieter wrote: >> Fedora Extras repoclosure wrote: >>> rdieter AT math.unl.edu >>> k3b-extras - 0.12.17-1.fc6.i386 (38 days) >>> k3b-extras - 0.12.17-1.fc6.ppc (38 days) >>> k3b-extras - 0.12.17-1.fc6.x86_64 (38 days) >> Should be removed from the repo, posted Mar 22: >> http://fedoraproject.org/wiki/PackageMaintainers/RepoRequests > k3b still doesn't contain the corresponding "Obsoletes". If you consider that a blocker to removing k3b-extras, so be it. The k3b modifications are pending on it's maintainer and Extras merge. -- Rex From mclasen at redhat.com Wed Mar 28 03:33:01 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 27 Mar 2007 23:33:01 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <4609835E.6080602@gmail.com> <1175029355.3182.0.camel@localhost.localdomain> Message-ID: <1175052781.3192.2.camel@localhost.localdomain> On Tue, 2007-03-27 at 15:28 -0600, Bernard Johnson wrote: > > > > Oh, I have complained about that part of the guidelines before, but > > without success. > > > > And this is primarily where I have a problem. > > There is packaging guideline. > > You have tried to get them changed, and couldn't. > > But that didn't stop you from ignoring them in this particular case. You have your history wrong here. The bug report that you are citing is from long before the packaging guidelines were relevant for core packages. From bjohnson-dated-1172832473.ba5e95 at symetrix.com Wed Mar 28 03:34:02 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Tue, 27 Mar 2007 21:34:02 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175052781.3192.2.camel@localhost.localdomain> References: <4609835E.6080602@gmail.com> <1175029355.3182.0.camel@localhost.localdomain> <1175052781.3192.2.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: > On Tue, 2007-03-27 at 15:28 -0600, Bernard Johnson wrote: > >>> Oh, I have complained about that part of the guidelines before, but >>> without success. >>> >> And this is primarily where I have a problem. >> >> There is packaging guideline. >> >> You have tried to get them changed, and couldn't. >> >> But that didn't stop you from ignoring them in this particular case. > > You have your history wrong here. The bug report that you are citing is > from long before the packaging guidelines were relevant for core > packages. > > Sorry, that wasn't meant to be chronological. But the fact remains that the package is expected to conform to the package guideline, which is why there is a mass review, to bring all core packages into compliance. From mclasen at redhat.com Wed Mar 28 03:44:20 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 27 Mar 2007 23:44:20 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <4609835E.6080602@gmail.com> <1175029355.3182.0.camel@localhost.localdomain> <1175052781.3192.2.camel@localhost.localdomain> Message-ID: <1175053460.3192.9.camel@localhost.localdomain> On Tue, 2007-03-27 at 21:34 -0600, Bernard Johnson wrote: > Sorry, that wasn't meant to be chronological. > > But the fact remains that the package is expected to conform to the > package guideline, which is why there is a mass review, to bring all > core packages into compliance. The packaging committee is not the sole ruler of all things in Fedora, and the packaging guidelines are just a tool that has its limits. If something in the packaging guidelines does not make sense for one of my packages, I will take the freedom to deviate from the guidelines. From ssorce at redhat.com Wed Mar 28 03:47:10 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 27 Mar 2007 23:47:10 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <200703271645.24712.jkeating@redhat.com> <46099C7D.3080008@fedoraproject.org> <4609AE42.8070009@fedoraproject.org> Message-ID: <1175053630.32396.26.camel@willson> Bernard, I can't agree more with what you said, this discussion is silly, it start reminding me some of the more brain-damaged discussions on Debian lists. I hope it is an isolate incident, and is not becoming the norm or next we will declare that Trademarks, documentation, and just everything in the world is software and any license but the GPL is bad. Don't get me wrong, I love the GPL, it is the license I use for my software, but _software_ is the key here. Names, logos, documentation are a different matter. Please let's not get stupid and let's recognize things from what they are. Trademarks, are not good or bad by themselves, it is the use you do of them that can be good or bad. HP's trademark/logo in hp-toolbox is on the side of the "good" way much more than what is the Mozilla's Firefox trademark/logo. On Tue, 2007-03-27 at 19:04 -0600, Bernard Johnson wrote: > All the "free software zealots" say to vote with your pocketbook. I > did. I bought a $1000 SOHO printer BECAUSE THEY HAD LINUX SUPPORT. And > not just a blob, real GPL software. Now I hear total bogus arguments > like "it's advertising" [but don't look at these other things that are > advertising as well that we will let slide] or "yeah, it's free but it's > not good enough"[2][3]. HP People didn't attach any string to the use of that logo for that software, so any discussion about removing it, is just plain silly, IMO. We are beyond "free software zealots" we reached the point of "berserk kamikaze zealots" if we actually go down this road. > This is exactly the attitude that will cause Linux to not get any > support by vendors. Wise words. We need more software not less, there is still a *LOT* of software niches that have no sort of free software of any kind, and pretty big ones. And people here waste time arguing by a trademarked logo in a GPL package that comes with no sort of requirements? Are you insane? Or what? > The fact of the matter is that it takes vendor support to make > Fedora/RedHat anything other than a toy operating system for many uses. > At many junctures, we have to make conscious trade offs between > idealogical beliefs and functionality. That trade off may be a little > recognition of the hard work that someone / some company put into the > software, and I say that's great, give it to them. If only this little "advertising" could be used to make more companies write and distribute GPL software I would ask for MORE of this kind advertising, that would be just great. On the software quality I would really avoid commenting, we have such crap in free software that complaining about the quality of *useful* *free software* is beyond my comprehension. When the people that don't like it, will rewrite and support a better piece of software to cover the same functionality, then they will be entitled to speak about removing others software. Please, I beg you try to use your head and think: a) what is the right thing to do to help users (NOW, not "in 10 years maybe") with *free software* b) what is the right thing to do to spread more *free software* c) what is the right way to get more vendors to help us with *free software* d) what is the right thing to do to avoid waisting time and produce more *free software* To me the answers are pretty clear wrt this case. Simo. From bjohnson-dated-1172832473.ba5e95 at symetrix.com Wed Mar 28 04:22:40 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Tue, 27 Mar 2007 22:22:40 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175053630.32396.26.camel@willson> References: <200703271645.24712.jkeating@redhat.com> <46099C7D.3080008@fedoraproject.org> <4609AE42.8070009@fedoraproject.org> <1175053630.32396.26.camel@willson> Message-ID: Simo Sorce wrote: > Wise words. We need more software not less, there is still a *LOT* of > software niches that have no sort of free software of any kind, and > pretty big ones. If we make Fedora usable, we attract users (not just developers, but users). Users put pressure on vendors. Vendors bring more/better/open software and developers. Making tools that users expect to have hard to use or find, even when they are functional and freely available, moves in exactly the opposite direction. > Please, I beg you try to use your head and think: > > a) what is the right thing to do to help users (NOW, not "in 10 years > maybe") with *free software* And I think you should stress the "maybe". Remember FSF saying "just wait the hurd is coming" lol From Lam at Lam.pl Wed Mar 28 04:48:51 2007 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 28 Mar 2007 06:48:51 +0200 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> Message-ID: <1175057331.3942.4.camel@pensja.lam.pl> This time I try to run "yum install openoffice.org-core" or "yum update openoffice.org-core" and it says: --> Running transaction check Running "postresolve" handler for "presto" plugin Traceback (most recent call last): File "/usr/bin/yum", line 29, in ? yummain.main(sys.argv[1:]) File "/usr/share/yum-cli/yummain.py", line 135, in main (result, resultmsgs) = base.buildTransaction() File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 449, in buildTransaction self.plugins.run('postresolve', rescode=rescode, restring=restring) File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 153, in run func(conduitcls(self, self.base, conf, **kwargs)) File "/usr/lib/yum-plugins/presto.py", line 91, in postresolve_hook rpm_size += int(newpkg.po.simple['packagesize']) KeyError: 'packagesize' "yum update" with no arguments doesn't break (but openoffice.org-core, the 88 MiB beast, doesn't have a drpm - why?). Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From mclasen at redhat.com Wed Mar 28 04:53:46 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 28 Mar 2007 00:53:46 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175056150.6493.190.camel@localhost.localdomain> References: <4609835E.6080602@gmail.com> <1175029355.3182.0.camel@localhost.localdomain> <1175056150.6493.190.camel@localhost.localdomain> Message-ID: <1175057626.3192.18.camel@localhost.localdomain> On Tue, 2007-03-27 at 23:29 -0500, Tom "spot" Callaway wrote: > The Fedora Packaging Guidelines represent the hard work of many > contributors, both those of Red Hat employees and community members. > Honestly, your blatant disrespect for both the guidelines drafted and > approved by the community and the committee which already has a > thankless job makes me sick. If you look at the cvs commits, you will find that I move desktop packages closer to following the guidelines every single day. Saying that I consider the guidelines as just that, guidelines, not a god-given scripture is quite something different than "blatant disrespect". > Attacking, slandering, and refusing to comply with the guidelines when > they don't suit you personally sets a _wonderful_ example for Red Hat > community relations. Can you point out where I have been attacking and slandering, please ? This thread started out with calling my a hypocrite, now I am attacking and slandering. Time to call it a day, I think... From bjohnson-dated-1172832473.ba5e95 at symetrix.com Wed Mar 28 05:02:06 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Tue, 27 Mar 2007 23:02:06 -0600 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175053460.3192.9.camel@localhost.localdomain> References: <4609835E.6080602@gmail.com> <1175029355.3182.0.camel@localhost.localdomain> <1175052781.3192.2.camel@localhost.localdomain> <1175053460.3192.9.camel@localhost.localdomain> Message-ID: Matthias Clasen wrote: > The packaging committee is not the sole ruler of all things in Fedora, > and the packaging guidelines are just a tool that has its limits. If > something in the packaging guidelines does not make sense for one of my > packages, I will take the freedom to deviate from the guidelines. It's clear that you intend to do nothing regarding the "right thing", so this will be my last comment. I don't have the ability to make the change, only comments and recommendations, which I've put forth. I did not realize it was your package, I thought it was Tim's. Regardless, the packaging committee has approved the packaging guidelines with the goal of improving overall packaging. You have chosen to ignore the guidelines [1], without any good /consistent/ reason AFAICS. And I have pointed out several different places where other packages are not treated the equally, which you have also ignored. Fine. But, now it's expected that Fedora packagers apply the guidelines to themselves while ignoring the fact that you are giving yourself special treatment for no particularly good reason.[2] Welcome to hypocrisy and good luck with it. Are you afraid that the packaging committee might disagree with you if you asked if your package /should/ be granted an exception regarding menu entry? Tell you what, I'll do you one even better, let's both write a paragraph (no more than 100 words) each and put it in front of the committee for an opinion of what /should/ be done with this particular package (not what could be done). If they agree that your actions are warranted, by a majority (not regarding what you can do, but what you should do), I'll donate $250 to your favorite free software project. Interested? Email me. [1] And technically, your package does not violate the guidelines, as the guidelines only require that the .desktop file be properly installed, which it is (except for the Category issue I brought up to Tim). I think most would agree that installing it but not displaying it violates the intent of the guideline though. [2] Certainly not the first disagreement from core packages vs. packaging requirements. Although all the other arguments I've see the packagers had a compelling reason. From mclasen at redhat.com Wed Mar 28 05:09:26 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 28 Mar 2007 01:09:26 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <4609835E.6080602@gmail.com> <1175029355.3182.0.camel@localhost.localdomain> <1175052781.3192.2.camel@localhost.localdomain> <1175053460.3192.9.camel@localhost.localdomain> Message-ID: <1175058566.3192.24.camel@localhost.localdomain> On Tue, 2007-03-27 at 23:02 -0600, Bernard Johnson wrote: > I did not realize it was your package, I thought it was Tim's. It is not my package. What gave you the impression it was mine ? From tmus at tmus.dk Wed Mar 28 05:15:26 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 28 Mar 2007 07:15:26 +0200 Subject: Presto logging In-Reply-To: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> Message-ID: Jonathan Dieter wrote: > > Also, our test server is syncing updates and extras every six hours. > Does anyone know if there's a way for the fedoraproject servers to push > updates rather than our polling? > Is there a good site with info on setting up a drpms mirror and other useful info to get one started on the deltarpm era? I'm not thinking about rsync'ing the drpm packages, but rather, i'd like to automatically build the drpms on this system, for use by my internal machines i386,x86_64. Any pointers? Thanks /Thomas From jdieter at gmail.com Wed Mar 28 05:25:20 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 28 Mar 2007 08:25:20 +0300 Subject: Presto logging In-Reply-To: References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> Message-ID: <1175059520.7752.37.camel@jndwidescreen.lesbg.loc> On Wed, 2007-03-28 at 07:15 +0200, Thomas M Steenholdt wrote: > Jonathan Dieter wrote: > > > > Also, our test server is syncing updates and extras every six hours. > > Does anyone know if there's a way for the fedoraproject servers to push > > updates rather than our polling? > > > > Is there a good site with info on setting up a drpms mirror and other > useful info to get one started on the deltarpm era? > > I'm not thinking about rsync'ing the drpm packages, but rather, i'd like > to automatically build the drpms on this system, for use by my internal > machines i386,x86_64. > > Any pointers? > > Thanks > > /Thomas > In the .tar.bz2 and the source rpm is a folder called makerepo that contains a very ugly createprestorepo.py script. The syntax is "/path/to/createprestorepo.py ". For the test server it's something like "~/bin/createprestorepo.py ./ DRPMS/" while in ~/public_html/jdieter/updates/fc6/i386. It will then go and find all rpms, make any applicable deltas (at the moment, it creates any delta it can with 50%+ savings), and save them in the destination folder, and create prestomd, etc in repodata. If the drpms aren't worth saving it deletes them and creates a ".dontdelta" file for the drpm, so the next round it will be ignored. You might want to wait until I push out 0.3.0 later today, as the current version of createprestorepo.py won't try to make deltarpms for packages over 70MB (due to memory constraints on my server). You will need roughly 3x as much RAM as the largest package you want to delta. Jonathan -------------- 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 jdieter at gmail.com Wed Mar 28 05:20:55 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 28 Mar 2007 08:20:55 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175057331.3942.4.camel@pensja.lam.pl> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> <1175057331.3942.4.camel@pensja.lam.pl> Message-ID: <1175059255.7752.32.camel@jndwidescreen.lesbg.loc> On Wed, 2007-03-28 at 06:48 +0200, Leszek Matok wrote: > This time I try to run "yum install openoffice.org-core" or "yum update > openoffice.org-core" and it says: > > --> Running transaction check > Running "postresolve" handler for "presto" plugin > Traceback (most recent call last): > File "/usr/bin/yum", line 29, in ? > yummain.main(sys.argv[1:]) > File "/usr/share/yum-cli/yummain.py", line 135, in main > (result, resultmsgs) = base.buildTransaction() > File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 449, in buildTransaction > self.plugins.run('postresolve', rescode=rescode, restring=restring) > File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 153, in run > func(conduitcls(self, self.base, conf, **kwargs)) > File "/usr/lib/yum-plugins/presto.py", line 91, in postresolve_hook > rpm_size += int(newpkg.po.simple['packagesize']) > KeyError: 'packagesize' > > "yum update" with no arguments doesn't break (but openoffice.org-core, > the 88 MiB beast, doesn't have a drpm - why?). > > Lam Not sure why you're hitting this bug...I'll try to fix it. As for not having a drpm doing a plain yum update, there was a bug in the server code that didn't allow drpms to be made for packages over 70MB in size (because that was the limit on my local server and I didn't like it running out of memory). I've fixed it, and the drpm should now be available. Jonathan -------------- 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 Lam at Lam.pl Wed Mar 28 05:33:10 2007 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 28 Mar 2007 07:33:10 +0200 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175059255.7752.32.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> <1175057331.3942.4.camel@pensja.lam.pl> <1175059255.7752.32.camel@jndwidescreen.lesbg.loc> Message-ID: <1175059990.3942.6.camel@pensja.lam.pl> Dnia 28-03-2007, ?ro o godzinie 08:20 +0300, Jonathan Dieter napisa?(a): > Not sure why you're hitting this bug... I'll try to reproduce it on another machine in few hours. > the drpm should now be available. Thanks, that's another 77 MiB saving! :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From tmus at tmus.dk Wed Mar 28 05:56:22 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 28 Mar 2007 07:56:22 +0200 Subject: Presto logging In-Reply-To: <1175059520.7752.37.camel@jndwidescreen.lesbg.loc> References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> <1175059520.7752.37.camel@jndwidescreen.lesbg.loc> Message-ID: Jonathan Dieter wrote: > In the .tar.bz2 and the source rpm is a folder called makerepo that > contains a very ugly createprestorepo.py script. > > The syntax is "/path/to/createprestorepo.py directory to create drpms in>". For the test server it's something like > "~/bin/createprestorepo.py ./ DRPMS/" while in > ~/public_html/jdieter/updates/fc6/i386. > > It will then go and find all rpms, make any applicable deltas (at the > moment, it creates any delta it can with 50%+ savings), and save them in > the destination folder, and create prestomd, etc in repodata. > > If the drpms aren't worth saving it deletes them and creates a > ".dontdelta" file for the drpm, so the next round it will be ignored. > > You might want to wait until I push out 0.3.0 later today, as the > current version of createprestorepo.py won't try to make deltarpms for > packages over 70MB (due to memory constraints on my server). > > You will need roughly 3x as much RAM as the largest package you want to > delta. > Sounds great, I'll give it a whirl once 0.3.0 hits the server :) But I wonder, since we only specify the updatedir (cwd) and the target DRPMS dir, how does it know what packages to build base the delta on? Does it use whatever is installed or in the core repo or something? And here is a thought-up scenario : - base install includes a package called xxx-1.0.0-1.i386.rpm (100MB) - then an update is released called xxx-1.0.0-2.i386.rpm (100 MB) - then an update is released called xxx-1.0.0-3.i386.rpm (100 MB) - then an update is released called xxx-1.0.1-1.i386.rpm (101 MB) The currently installed systems could be on any one of the 3 previous versions of xxx. So to be able to use drpms for package xxx for any system, we'd need several drpm packages to be able to use drpms for all systems? At least, these drpms would then be required, right? 1.0.0-1 -> 1.0.1-1 1.0.0-2 -> 1.0.1-1 1.0.0-3 -> 1.0.1-1 Or does it work differently? Perhaps I'm just missing an important piece of information here? ;o) Thanks a lot! /Thomas From peter at thecodergeek.com Wed Mar 28 05:57:26 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Tue, 27 Mar 2007 22:57:26 -0700 Subject: rpms/viewvc/devel viewvc.spec,1.2,1.3 In-Reply-To: <200703280543.l2S5hNBt010348@cvs-int.fedora.redhat.com> References: <200703280543.l2S5hNBt010348@cvs-int.fedora.redhat.com> Message-ID: <1175061446.10365.2.camel@tuxhugs> On Wed, 2007-03-28 at 01:43 -0400, Bojan Smojver wrote: > Author: bojan > > Update of /cvs/extras/rpms/viewvc/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv10330 > > Modified Files: > viewvc.spec > Log Message: > Drop selinux package, required context now in official policy. When you drop a subpackage, please remember to add proper Obsoletes/Provides to the main package so that the subpackage is properly removed with the next update. E.g., for your viewvc changes something like the following would suffice: Obsoletes: %{name}-selinux < 1.0.3-12%{?dist} Provides: %{name}-selinux = 1.0.3-12%{?dist} Thanks. -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 jdieter at gmail.com Wed Mar 28 05:58:11 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 28 Mar 2007 08:58:11 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175059990.3942.6.camel@pensja.lam.pl> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> <1175057331.3942.4.camel@pensja.lam.pl> <1175059255.7752.32.camel@jndwidescreen.lesbg.loc> <1175059990.3942.6.camel@pensja.lam.pl> Message-ID: <1175061491.7752.42.camel@jndwidescreen.lesbg.loc> On Wed, 2007-03-28 at 07:33 +0200, Leszek Matok wrote: > Dnia 28-03-2007, ?ro o godzinie 08:20 +0300, Jonathan Dieter napisa?(a): > > Not sure why you're hitting this bug... > I'll try to reproduce it on another machine in few hours. > > > the drpm should now be available. > Thanks, that's another 77 MiB saving! :) > > Lam Actually, I've managed to reproduce it on a test machine here, so don't worry about that. Seth, it seems that yum doesn't get the information for PackageObject.simple['packagesize'] before postresolve_hook is called when yum is called with list of packages to update, but does when yum update is called on it's own. Is there a reason for this? Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at linux.duke.edu Wed Mar 28 06:01:19 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 28 Mar 2007 02:01:19 -0400 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175061491.7752.42.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <1174929462.6065.7.camel@pensja.lam.pl> <1174930988.19925.61.camel@jndwidescreen.lesbg.loc> <1174931985.6065.14.camel@pensja.lam.pl> <1174935104.19925.93.camel@jndwidescreen.lesbg.loc> <1175057331.3942.4.camel@pensja.lam.pl> <1175059255.7752.32.camel@jndwidescreen.lesbg.loc> <1175059990.3942.6.camel@pensja.lam.pl> <1175061491.7752.42.camel@jndwidescreen.lesbg.loc> Message-ID: <1175061679.5762.32.camel@cutter> On Wed, 2007-03-28 at 08:58 +0300, Jonathan Dieter wrote: > On Wed, 2007-03-28 at 07:33 +0200, Leszek Matok wrote: > > Dnia 28-03-2007, ?ro o godzinie 08:20 +0300, Jonathan Dieter napisa?(a): > > > Not sure why you're hitting this bug... > > I'll try to reproduce it on another machine in few hours. > > > > > the drpm should now be available. > > Thanks, that's another 77 MiB saving! :) > > > > Lam > Actually, I've managed to reproduce it on a test machine here, so don't > worry about that. > > Seth, it seems that yum doesn't get the information for > PackageObject.simple['packagesize'] before postresolve_hook is called > when yum is called with list of packages to update, but does when yum > update is called on it's own. Is there a reason for this? what version of yum are you doing this on? -sv From jdieter at gmail.com Wed Mar 28 06:15:08 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 28 Mar 2007 09:15:08 +0300 Subject: Presto logging In-Reply-To: References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> <1175059520.7752.37.camel@jndwidescreen.lesbg.loc> Message-ID: <1175062509.7752.51.camel@jndwidescreen.lesbg.loc> On Wed, 2007-03-28 at 07:56 +0200, Thomas M Steenholdt wrote: > Sounds great, I'll give it a whirl once 0.3.0 hits the server :) > > But I wonder, since we only specify the updatedir (cwd) and the target > DRPMS dir, how does it know what packages to build base the delta on? > Does it use whatever is installed or in the core repo or something? > > And here is a thought-up scenario : > > - base install includes a package called xxx-1.0.0-1.i386.rpm (100MB) > - then an update is released called xxx-1.0.0-2.i386.rpm (100 MB) > - then an update is released called xxx-1.0.0-3.i386.rpm (100 MB) > - then an update is released called xxx-1.0.1-1.i386.rpm (101 MB) > > The currently installed systems could be on any one of the 3 previous > versions of xxx. So to be able to use drpms for package xxx for any > system, we'd need several drpm packages to be able to use drpms for all > systems? > > At least, these drpms would then be required, right? > 1.0.0-1 -> 1.0.1-1 > 1.0.0-2 -> 1.0.1-1 > 1.0.0-3 -> 1.0.1-1 > > Or does it work differently? Perhaps I'm just missing an important piece > of information here? ;o) > > Thanks a lot! > > /Thomas > Okay, I'm going to answer what I *think* you're asking, but I'm not sure. In your scenario (which is what I'm using on the test server), createprestorepo.py would create all three drpms (though some thought needs to go into how we're going to trim them in the future). As for making the drpms for core => updates, I took the lazy way out. I just mirrored core and updates all into the same local directory on the test server. Then, createprestorepo was able to find all the update paths. There are obviously better ways of doing this, but I've been focusing on the client rather than the server at the moment. Jonathan -------------- 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 tmus at tmus.dk Wed Mar 28 06:31:07 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 28 Mar 2007 08:31:07 +0200 Subject: Presto logging In-Reply-To: <1175062509.7752.51.camel@jndwidescreen.lesbg.loc> References: <1174897580.19925.18.camel@jndwidescreen.lesbg.loc> <1175059520.7752.37.camel@jndwidescreen.lesbg.loc> <1175062509.7752.51.camel@jndwidescreen.lesbg.loc> Message-ID: Jonathan Dieter wrote: > Okay, I'm going to answer what I *think* you're asking, but I'm not > sure. In your scenario (which is what I'm using on the test server), > createprestorepo.py would create all three drpms (though some thought > needs to go into how we're going to trim them in the future). > > As for making the drpms for core => updates, I took the lazy way out. I > just mirrored core and updates all into the same local directory on the > test server. Then, createprestorepo was able to find all the update > paths. > This is exactly what I asked :o) Just needed to understand how that was supposed to work. Sure we need to think about a good way to solve this, but for now, I just needed to understand how that was supposed to work. Thanks. /Thomas From ville.skytta at iki.fi Wed Mar 28 06:47:28 2007 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 28 Mar 2007 09:47:28 +0300 Subject: rpms/viewvc/devel viewvc.spec,1.2,1.3 In-Reply-To: <1175061446.10365.2.camel@tuxhugs> References: <200703280543.l2S5hNBt010348@cvs-int.fedora.redhat.com> <1175061446.10365.2.camel@tuxhugs> Message-ID: <200703280947.28406.ville.skytta@iki.fi> On Wednesday 28 March 2007, Peter Gordon wrote: > On Wed, 2007-03-28 at 01:43 -0400, Bojan Smojver wrote: > > > Modified Files: > > viewvc.spec > > Log Message: > > Drop selinux package, required context now in official policy. > > When you drop a subpackage, please remember to add proper > Obsoletes/Provides to the main package so that the subpackage is > properly removed with the next update. > > E.g., for your viewvc changes something like the following would > suffice: > > Obsoletes: %{name}-selinux < 1.0.3-12%{?dist} > Provides: %{name}-selinux = 1.0.3-12%{?dist} I think there's no need to add the Provides in this case. And the Obsoletes should be a disttagless %{name}-selinux < 1.0.3-13. http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-3cfc1ea19d28975faad9d56f70a6ae55661d3c3d From bojan at rexursive.com Wed Mar 28 07:55:34 2007 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 28 Mar 2007 17:55:34 +1000 Subject: Fedora build system broken? Message-ID: <1175068534.3139.42.camel@shrek.rexursive.com> Buildsys is still building some of the jobs I submitted, after about 2 hours of running/prepping. Something broken? -- Bojan From pertusus at free.fr Wed Mar 28 08:10:40 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 28 Mar 2007 10:10:40 +0200 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175051938.32396.3.camel@willson> References: <46092AC6.70408@fedoraproject.org> <46092F16.1010608@nicubunu.ro> <460936A3.4070408@fedoraproject.org> <1175009409.6100.4.camel@willson> <20070327171707.GE2888@free.fr> <1175051938.32396.3.camel@willson> Message-ID: <20070328081040.GA2906@free.fr> On Tue, Mar 27, 2007 at 11:18:58PM -0400, Simo Sorce wrote: > > No, not really, you can have a package that provide different binaries. > For example the samba package is mostly GPL software except for > pam_winbind and nss_winbind, which are not under the GPL. The "whole > package" does not mean much. It's the single binaries+libraries that > count. Indeed single binaries and libraries may be under other licenses, but the src.rpm is GPL. > I can very well see us distributing something like, let's say Xorg, with > a little GPLed GUI in the same package, this does not make the whole > package GPLed. If it is a single .src.rpm, it does. Now, as you said above, if the GPL part can be put in a subpackage, then the remaining subpackages could be under another license. -- Pat From valent.turkovic at gmail.com Wed Mar 28 08:24:07 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Wed, 28 Mar 2007 10:24:07 +0200 Subject: Fedora 7 - features and obvious usability enhancements Message-ID: <64b14b300703280124s6a0c8947uba60d52f57fcfb2c@mail.gmail.com> Hello, first I would like to ask where is the proper place to suggest new features and obvious usability enhancements for fedora. Is there a mailing list or some group of people or someone specific I have to target in order for some really much needed features to be included in fedora releases? First one I see as a really great usability add on to fedora is Deskbar gnome plugin. It is in the repositories, but it is not installed by default and it is not enabled by default. I think that this is a great shame. All new users (and also old ones) would benefit a lot from just including this great widget in default desktop setup for Fedora 7 . Ok, I won't go too much long here if this isn't proper way of getting attention to the right people. I don't mean that you aren't proper or not important but I just don't know if this mailing list is the right way for discussing usability and features. Please tell me if it is and then I'll continue if not point me in the right direction. Thank you all for your time and attention. Valent from Croatia. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241 Skype: valent.turkovic From twaugh at redhat.com Wed Mar 28 08:27:34 2007 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 28 Mar 2007 09:27:34 +0100 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <1174946404.2622.98.camel@zelda.fubar.dk> Message-ID: <1175070454.4710.8.camel@cyberelk.elk> On Tue, 2007-03-27 at 20:12 +0000, Kevin Kofler wrote: > As for the actual issue in this thread, I have a suggestion: what about making > hp-toolbox a separate subpackage of hplip, which is not installed by default, > but which (when installed) comes with a menu item? That would solve both > the "vendor-specific menu item forced on everyone" and the "hplip requires > PyQt" issues. Yes, this is a good idea. Originally it was not possible though: the 'pulls in Qt' problem is due to the fact that the hp-toolbox component could not be separated out from the transport layer without immense pain. When I pointed this out upstream they said they would look at addressing that. Current versions seem to have a '--enable-gui-build', so it might now have been addressed. The Qt problem is on the F7 Target list so when I get some HPLIP time I'll take another look at that. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Wed Mar 28 08:29:03 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 28 Mar 2007 09:29:03 +0100 Subject: kernel config question In-Reply-To: <20070319155656.GB22192@nostromo.devel.redhat.com> References: <1174180224.30317.3.camel@sonlaptop> <1174232436.3461.619.camel@pmac.infradead.org> <20070319145355.GB18278@nostromo.devel.redhat.com> <1174317395.3392.146.camel@pmac.infradead.org> <20070319151344.GA20687@nostromo.devel.redhat.com> <1174318149.3392.153.camel@pmac.infradead.org> <20070319152844.GA22192@nostromo.devel.redhat.com> <1174319679.3392.157.camel@pmac.infradead.org> <20070319155656.GB22192@nostromo.devel.redhat.com> Message-ID: <1175070543.3277.107.camel@pmac.infradead.org> On Mon, 2007-03-19 at 11:56 -0400, Bill Nottingham wrote: > > But changes to environment variables in the hotplug script > > invocations shouldn't hurt, right? > > No, but that's not the reason we have DEPRECATED on. OK, thanks for the information. I've committed a crappy hack which disables those extra environment variables (the ones which CONFIG_SYSFS_DEPRECATED enables). It's those which were crashing the kernel. It's not the _correct_ fix, because the crash is just a _symptom_ of the fact that somewhere in that sysfs mess we have a pointer to freed memory. But at least it prevents the kernel from crashing, which is probably a good thing in the short term. Once I've finished bringing up the PlayStation 3, I'll have time to go back and investigate all the non-ppc-specific bugs I've been finding in my rawhide testing, including this one. -- dwmw2 From twaugh at redhat.com Wed Mar 28 08:29:36 2007 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 28 Mar 2007 09:29:36 +0100 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175014301.3815.16.camel@eagle.danny.cz> References: <1174965859.24384.1.camel@localhost.localdomain> <1175003869.21714.7.camel@golem.boston.devel.redhat.com> <1175014301.3815.16.camel@eagle.danny.cz> Message-ID: <1175070576.4710.11.camel@cyberelk.elk> On Tue, 2007-03-27 at 18:51 +0200, Dan Hor?k wrote: > But it could be a task for system-config-printer - it detects printers > and installs printer specific packages. It could be perhaps some > connection between driver name and required packages. It does in fact already do this. :-) Unfortunately I don't know of a good hook for 'now install this package, prompting the user first', so all it currently does it tell the user the name of the package they should install. Anyone know how to make that better? Tim. */ -------------- 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 Wed Mar 28 08:38:07 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 28 Mar 2007 03:38:07 -0500 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1174948562.3739.27.camel@localhost.localdomain> References: <1174945175.3739.9.camel@localhost.localdomain> <1174948562.3739.27.camel@localhost.localdomain> Message-ID: <16de708d0703280138q46441391ta41671eb60ec59f2@mail.gmail.com> On 3/26/07, Matthias Clasen wrote: > On Mon, 2007-03-26 at 16:13 -0600, Bernard Johnson wrote: > > Matthias Clasen wrote: > > > On Mon, 2007-03-26 at 15:27 -0600, Bernard Johnson wrote: > > >> mclasen at redhat.com: > > >> "We don't give free ad space to HP on our menus..." > > >> > > >> > > >> I find that to be both an interesting and hypocritical comment. > > > > > > FWIW, the comment was referring to the HP icon in the menus. > > > > > > > That was my assumption, but I could have read it any number of other > > ways as well. > > > > Do you still feel the same way given the other examples that I posted? > > > > David outlined a number of reasons why the hplip stack is really less > than ideal from a desktop integration perspective. So yes, I still think > that hplip and assorted gui tools are not the solution we want and do > not really move us closer to the goal of making printing suck less. > > Matthias > > PS And no, I did not do an exhaustive search through all the menus > before making the comment about the icon. If the VNC icon is just a > company icon in disguise, the same comment applies there too. > wow wow wow, I don't know about you guys, but I use the HPLIP stack. And I don't know what is more user-friendly than having it all working "out of the box". The only reason I haven't noticed the menu shortcuts were missing is that it all works so well. Then again, maybe if they were in there I would have noticed my ink was running low a lot earlier. If the software meets Fedora's already strict legal requirements, then it should be packaged like any other package. The reason given for not including the shortcut is plain silly. Or at the very list, if that is going to be a reason used, then all packages need to have generic icons because the whole point of an icon to a program is recognition and advertisement. HP wrote the stack, why can't their icon be used. This is being overly nitpicky about things. Peace. -- Fedora Core 6 and proud From sundaram at fedoraproject.org Wed Mar 28 08:38:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 28 Mar 2007 14:08:16 +0530 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <200703271645.24712.jkeating@redhat.com> <46099C7D.3080008@fedoraproject.org> <4609AE42.8070009@fedoraproject.org> Message-ID: <460A2978.8090309@fedoraproject.org> Bernard Johnson wrote: > I do not disagree with the direction taken with CodecBuddy (this I > stated in my original email). I very much disagree with lack of > impartiality between vendors who are both supporting Linux. You expressed some concerns with codec buddy itself which I hope I have answered. Using that explanation to justify your argument to a desktop icon for a unrelated package is bad form even when your argument is right because it confuses two separate concerns. Please don't do that. Regardless of your technical justifications, name calling and flaming a fellow Fedora contributor with generalized and incorrect claims is not constructive at all. Please don't do that either. Rahul From sundaram at fedoraproject.org Wed Mar 28 08:45:16 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 28 Mar 2007 14:15:16 +0530 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175053460.3192.9.camel@localhost.localdomain> References: <4609835E.6080602@gmail.com> <1175029355.3182.0.camel@localhost.localdomain> <1175052781.3192.2.camel@localhost.localdomain> <1175053460.3192.9.camel@localhost.localdomain> Message-ID: <460A2B1C.3090002@fedoraproject.org> Matthias Clasen wrote: > On Tue, 2007-03-27 at 21:34 -0600, Bernard Johnson wrote: > >> Sorry, that wasn't meant to be chronological. >> >> But the fact remains that the package is expected to conform to the >> package guideline, which is why there is a mass review, to bring all >> core packages into compliance. > > The packaging committee is not the sole ruler of all things in Fedora, > and the packaging guidelines are just a tool that has its limits. If > something in the packaging guidelines does not make sense for one of my > packages, I will take the freedom to deviate from the guidelines. Packaging committee is indeed not the role ruler. The reason why they are called guidelines instead of rules is precisely because there is sometimes a need for exceptions and to give freedom to the package maintainers. However individual package maintainers completely disregarding the guidelines in a arbitrary way is going to be pretty messy. If there is a justification to deviate from the guidelines it should be brought in fedora-maintainers list. The guidelines might need to changed to accommodate requirements the packaging committee hasn't thought of before or in some corner cases a specific package needs to have a exception which should be documented within the spec file itself. Can you do this? Rahul From nicu_fedora at nicubunu.ro Wed Mar 28 10:25:58 2007 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 28 Mar 2007 13:25:58 +0300 Subject: Fedora 7 - features and obvious usability enhancements In-Reply-To: <64b14b300703280124s6a0c8947uba60d52f57fcfb2c@mail.gmail.com> References: <64b14b300703280124s6a0c8947uba60d52f57fcfb2c@mail.gmail.com> Message-ID: <460A42B6.60802@nicubunu.ro> Valent Turkovic wrote: > Hello, > first I would like to ask where is the proper place to suggest new > features and obvious usability enhancements for fedora. > > Is there a mailing list or some group of people or someone specific I > have to target in order for some really much needed features to be > included in fedora releases? Your specific question seems targeted at the desktop, so you may consider the desktop list (but I believe you are not entirely offtopic here, on this general development list): https://www.redhat.com/mailman/listinfo/fedora-desktop-list > First one I see as a really great usability add on to fedora is > Deskbar gnome plugin. It is in the repositories, but it is not > installed by default and it is not enabled by default. I think that > this is a great shame. All new users (and also old ones) would benefit > a lot from just including this great widget in default desktop setup > for Fedora 7 . I have the deskbar applet active on my computer but: - it is a bit of a resource hog, which is not that good for a default; - in my opinion it is not so friendly with new users > Ok, I won't go too much long here if this isn't proper way of getting > attention to the right people. I don't mean that you aren't proper or > not important but I just don't know if this mailing list is the right > way for discussing usability and features. Please tell me if it is and > then I'll continue if not point me in the right direction. About usability, you may look at the Usability SIG page in the wiki: http://fedoraproject.org/wiki/Usability -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From nicolas.mailhot at laposte.net Wed Mar 28 09:26:32 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 28 Mar 2007 11:26:32 +0200 (CEST) Subject: Fedora 7 - features and obvious usability enhancements In-Reply-To: <64b14b300703280124s6a0c8947uba60d52f57fcfb2c@mail.gmail.com> References: <64b14b300703280124s6a0c8947uba60d52f57fcfb2c@mail.gmail.com> Message-ID: <7036.192.54.193.51.1175073992.squirrel@rousalka.dyndns.org> Le Mer 28 mars 2007 10:24, Valent Turkovic a ?crit : > Hello, > first I would like to ask where is the proper place to suggest new > features and obvious usability enhancements for fedora. > > Is there a mailing list or some group of people or someone specific I > have to target in order for some really much needed features to be > included in fedora releases? The proper channel is IIRC the fedora-dekstop ML, plus you have a fedora-XXX usability channel and another for the desktop team. -- Nicolas Mailhot From denis at poolshark.org Wed Mar 28 09:58:36 2007 From: denis at poolshark.org (Denis Leroy) Date: Wed, 28 Mar 2007 11:58:36 +0200 Subject: hplip: hp-toolbox advertising? In-Reply-To: <4609835E.6080602@gmail.com> References: <4609835E.6080602@gmail.com> Message-ID: <460A3C4C.3020404@poolshark.org> dragoran wrote: > Bernard Johnson wrote: >> >> And for the record, I am *not against* pulling hplip from Fedora if >> that's the consensus. I am however against inconsistency in packages >> and application of policies across the distribution. >> >> > I don't use it myself but removing a software that supports that many > devices that else would be useless on fedora is simply wrong. > and if we say foo is in the package guidlines but package bar sucks so I > won't honour point x is silly. > either get the package or the guidlines fixed. Or orphan the package and let a community member pick it up ? From mschwendt.tmp0701.nospam at arcor.de Wed Mar 28 11:28:43 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 28 Mar 2007 13:28:43 +0200 Subject: Fedora build system broken? In-Reply-To: <1175068534.3139.42.camel@shrek.rexursive.com> References: <1175068534.3139.42.camel@shrek.rexursive.com> Message-ID: <20070328132843.d7e7995d.mschwendt.tmp0701.nospam@arcor.de> On Wed, 28 Mar 2007 17:55:34 +1000, Bojan Smojver wrote: > Buildsys is still building some of the jobs I submitted, after about 2 > hours of running/prepping. Something broken? Are you able to plague-client kill these jobs and resubmit them? ppc2 build server was hit hard by all sorts of old processes (including java, maven, beam) from previous build jobs and 100% of the cpu power occupied. From fedora at camperquake.de Wed Mar 28 11:47:12 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 28 Mar 2007 13:47:12 +0200 Subject: Fedora build system broken? In-Reply-To: <20070328132843.d7e7995d.mschwendt.tmp0701.nospam@arcor.de> References: <1175068534.3139.42.camel@shrek.rexursive.com> <20070328132843.d7e7995d.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070328134712.3f21b999@banea.int.addix.net> Hi. On Wed, 28 Mar 2007 13:28:43 +0200, Michael Schwendt wrote: > Are you able to plague-client kill these jobs and resubmit them? > > ppc2 build server was hit hard by all sorts of old processes > (including java, maven, beam) from previous build jobs and 100% of > the cpu power occupied. Just a thought: how fast is a PS3 at cpmpiling? From sundaram at fedoraproject.org Wed Mar 28 11:58:04 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 28 Mar 2007 17:28:04 +0530 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> Message-ID: <460A584C.2060109@fedoraproject.org> Jonathan Dieter wrote: > On Mon, 2007-03-26 at 21:02 +0530, Rahul Sundaram wrote: >> Sure. Different output with 0.2.6 and yum -d5. > >> File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 153, in run >> func(conduitcls(self, self.base, conf, **kwargs)) >> File "/usr/lib/yum-plugins/presto.py", line 85, in postresolve_hook >> (chosen_drpm, installed, local) = >> prestoTransaction.find_available_drpms(conduit, newpkg) >> File "/usr/share/presto/prestoTransaction.py", line 48, in >> find_available_drpms >> if os.path.exists(newpkg.po.localpath): >> AttributeError: YumInstalledPackage instance has no attribute 'localpath' >> >> >> Rahul >> > Well, at least I've moved the problem forward a few lines of code, > worthless as that is. Try 0.2.7 (again with -d 5, please), and let's > see if I've finally got it fixed! Fresh installation of Fedora Core 6 Yum install deltarpm version 3.4-1 from Fedora Extras Install yum-presto version 0.2.9-1 from the wiki page wget the repo file into /etc/yum.repos.d. Verified that it is enabled Disable updates and extras repository. Core repo is left enabled. Here is the output: yum -d10 update Loading "presto" plugin Loading "installonlyn" plugin Running "config" handler for "presto" plugin Running "config" handler for "installonlyn" plugin Yum Version: 3.0 COMMAND: yum -d10 Installroot: / Setting up Update Process Setting up repositories Running "postreposetup" handler for "presto" plugin Setting up Presto Reading Presto metadata in from local files No drpms available for presto No drpms available for core Reading repository metadata in from local files Setting up Package Sacks Reading Local RPMDB Building updates object No Packages marked for Update/Obsoletion If I enable updates and extras yum does starts downloading header files. Rahul From dennis at ausil.us Wed Mar 28 12:03:45 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 28 Mar 2007 07:03:45 -0500 Subject: Fedora build system broken? In-Reply-To: <20070328132843.d7e7995d.mschwendt.tmp0701.nospam@arcor.de> References: <1175068534.3139.42.camel@shrek.rexursive.com> <20070328132843.d7e7995d.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200703280703.57441.dennis@ausil.us> Once upon a time Wednesday 28 March 2007, Michael Schwendt wrote: > On Wed, 28 Mar 2007 17:55:34 +1000, Bojan Smojver wrote: > > Buildsys is still building some of the jobs I submitted, after about 2 > > hours of running/prepping. Something broken? > > Are you able to plague-client kill these jobs and resubmit them? > > ppc2 build server was hit hard by all sorts of old processes (including > java, maven, beam) from previous build jobs and 100% of the cpu power > occupied. Right now the netapps where the repos are stored are being completely unresponsive. I have shut down plague while we work out what is going on with them. Sorry about this. Dennis -------------- 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 Wed Mar 28 12:17:39 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Mar 2007 08:17:39 -0400 Subject: Rawhide will be a bit late today... Message-ID: <200703280817.39433.jkeating@redhat.com> As expected, something blew up a bit in the rawhide compose process now that we've unfroze. However HOW it blew up was completely unexpected, but very easy to recover from. Rawhide is composing again and should see the light of day in a few hours. -- 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 Wed Mar 28 12:34:11 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 28 Mar 2007 08:34:11 -0400 Subject: Rawhide will be a bit late today... In-Reply-To: <200703280817.39433.jkeating@redhat.com> References: <200703280817.39433.jkeating@redhat.com> Message-ID: <20070328123411.GA21250@jadzia.bu.edu> On Wed, Mar 28, 2007 at 08:17:39AM -0400, Jesse Keating wrote: > As expected, something blew up a bit in the rawhide compose process now > that we've unfroze. However HOW it blew up was completely unexpected, but > very easy to recover from. Rawhide is composing again and should see the > light of day in a few hours. If things don't blow up, is there a "normal" time for it to be available? (I'd like to adjust my mirror to be in sync with that.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at redhat.com Wed Mar 28 12:37:34 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Mar 2007 08:37:34 -0400 Subject: Rawhide will be a bit late today... In-Reply-To: <20070328123411.GA21250@jadzia.bu.edu> References: <200703280817.39433.jkeating@redhat.com> <20070328123411.GA21250@jadzia.bu.edu> Message-ID: <200703280837.34760.jkeating@redhat.com> On Wednesday 28 March 2007 08:34:11 Matthew Miller wrote: > If things don't blow up, is there a "normal" time for it to be available? > (I'd like to adjust my mirror to be in sync with that.) Going by past rawhide reports, looks like it generally becomes available around 6am EST. I'd set your mirror to start looking around 6:30~7 since we push to an internal netapp that snapmirrors out to public netapps. -- 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 Wed Mar 28 12:39:18 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 28 Mar 2007 08:39:18 -0400 Subject: Rawhide will be a bit late today... In-Reply-To: <200703280837.34760.jkeating@redhat.com> References: <200703280817.39433.jkeating@redhat.com> <20070328123411.GA21250@jadzia.bu.edu> <200703280837.34760.jkeating@redhat.com> Message-ID: <20070328123918.GA21680@jadzia.bu.edu> On Wed, Mar 28, 2007 at 08:37:34AM -0400, Jesse Keating wrote: > Going by past rawhide reports, looks like it generally becomes available > around 6am EST. I'd set your mirror to start looking around 6:30~7 since we > push to an internal netapp that snapmirrors out to public netapps. Sounds good. Thanks. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From ssorce at redhat.com Wed Mar 28 13:03:18 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 28 Mar 2007 09:03:18 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: <20070328081040.GA2906@free.fr> References: <46092AC6.70408@fedoraproject.org> <46092F16.1010608@nicubunu.ro> <460936A3.4070408@fedoraproject.org> <1175009409.6100.4.camel@willson> <20070327171707.GE2888@free.fr> <1175051938.32396.3.camel@willson> <20070328081040.GA2906@free.fr> Message-ID: <1175086999.32396.31.camel@willson> On Wed, 2007-03-28 at 10:10 +0200, Patrice Dumas wrote: > On Tue, Mar 27, 2007 at 11:18:58PM -0400, Simo Sorce wrote: > > > > No, not really, you can have a package that provide different binaries. > > For example the samba package is mostly GPL software except for > > pam_winbind and nss_winbind, which are not under the GPL. The "whole > > package" does not mean much. It's the single binaries+libraries that > > count. > > Indeed single binaries and libraries may be under other licenses, but > the src.rpm is GPL. No. > > I can very well see us distributing something like, let's say Xorg, with > > a little GPLed GUI in the same package, this does not make the whole > > package GPLed. > > If it is a single .src.rpm, it does. Now, as you said above, if the GPL > part can be put in a subpackage, then the remaining subpackages could be > under another license. It does not, go back and read the GPL, the GPL does not apply to other programs/binaries source even if shipped on the same medium. And a package is a sort of convenience medium you use to ship sources. The distribution under GPL terms applies to all the sources that concur to build a single binary, but does not extend a bit more. So I can put in a src.rpm 2 related utilities that use 2 different file sets as sources (maybe sharing just a MIT licensed library also built as part of the package) and ship them. If one is GPLed the other does not become automatically GPLed (that would be viral! But the GPL is not). Simo. From buildsys at fedoraproject.org Wed Mar 28 13:13:06 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 28 Mar 2007 09:13:06 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-28 Message-ID: <20070328131306.60530152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 22 Canna-3.7p3-18.fc7 cksfv-1.3.10-1.fc7 csync2-1.33-5.fc7 erlang-R11B-2.4.fc7 ettercap-0.7.3-18.fc7 farsight-0.1.15-1.fc7 NEW funtools-1.3.0-0.4.b29.fc7 jd-1.8.8-0.3.cvs070327.fc7 jython-2.2-0.3.Release_2_2beta1.1jpp.3.fc7 kdesvn-0.11.2-1.fc7 libgnomedb-1.9.100-13.fc7 munin-1.2.5-2.fc7 netmask-2.3.9-1.fc7 NEW nfs4-acl-tools-0.3.1-1.fc7.2 openvrml-0.16.3-6.fc7 perl-Smart-Comments-1.000002-4.fc7 python-inotify-0.7.0-2.fc7 NEW queuegraph-1.1-1.fc7 NEW siege-2.65-3.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.3023.fc7 NEW vdr-wapd-0.8-16.fc7 NEW whysynth-dssi-20060122-10.fc7 Packages built and released for Fedora Extras 6: 11 Canna-3.7p3-18.fc6 cksfv-1.3.10-1.fc6 ettercap-0.7.3-18.fc6 NEW funtools-1.3.0-0.4.b29.fc6 munin-1.2.5-2.fc6 perl-Smart-Comments-1.000002-4.fc6 NEW python-inotify-0.7.0-2.fc6 NEW queuegraph-1.1-1.fc6 sqlgrey-1.7.5-1.fc6 NEW vdr-wapd-0.8-16.fc6 NEW whysynth-dssi-20060122-10.fc6 Packages built and released for Fedora Extras 5: 7 cksfv-1.3.10-1.fc5 ettercap-0.7.3-18.fc5 NEW funtools-1.3.0-0.4.b29.fc5 munin-1.2.5-2.fc5 perl-Smart-Comments-1.000002-4.fc5 NEW queuegraph-1.1-1.fc5 sqlgrey-1.7.5-1.fc5 Canna-3.7p3-18.fc7 ------------------ * Tue Mar 27 2007 Akira TAGOH - 3.7p3-18 - Fix missing directory owner. (#233779) cksfv-1.3.10-1.fc7 ------------------ * Tue Mar 27 2007 Christopher Stone 1.3.10-1 - Upstream sync csync2-1.33-5.fc7 ----------------- * Tue Mar 27 2007 1.33-5 - Fix ownership of documentation directory (bz 233954) erlang-R11B-2.4.fc7 ------------------- * Sat Mar 24 2007 Thomas Fitzsimmons - R11B-2.4 - Require java-1.5.0-gcj-devel for build. ettercap-0.7.3-18.fc7 --------------------- * Tue Mar 27 2007 Jon Ciesla - 0.7.3-18 - Obsoletes fix. farsight-0.1.15-1.fc7 --------------------- * Tue Mar 27 2007 Brian Pepple - 0.1.15-1 - Update to 0.1.15. - Update URL & Source to new locations. funtools-1.3.0-0.4.b29.fc7 -------------------------- * Mon Mar 26 2007 Sergio Pascual 1.3.0-0.4.b29 - Funtools Approved - Parallel make does not work - Problem with undefined non weak symbols in libtclfun fixed * Fri Mar 23 2007 Sergio Pascual 1.3.0-0.3.b29 - Removed _smp_mflags * Thu Mar 22 2007 Sergio Pascual 1.3.0-0.2.b29 - Updated funtools-makefile.patch - Added EXTRA_LIBS to compilation step * Tue Mar 20 2007 Sergio Pascual 1.3.0-0.1.b29 - Initial spec file jd-1.8.8-0.3.cvs070327.fc7 -------------------------- * Tue Mar 27 2007 Mamoru Tasaka - 1.8.8-0.3.beta070327 - cvs 070327 (25:55 JST) jython-2.2-0.3.Release_2_2beta1.1jpp.3.fc7 ------------------------------------------ * Mon Mar 26 2007 Thomas Fitzsimmons - 2.2-0.3.Release_2_2beta1.1jpp.3 - Rename doc subpackage "manual". - Require libreadline-java. - Correct python.home property value. - Resolves: rhbz#233949 kdesvn-0.11.2-1.fc7 ------------------- * Mon Mar 26 2007 - Orion Poplawski - 0.11.2-1 - Update to 0.11.2 - Install a prebuilt en_index.cache.bz2 to fix multilib (bug #228370) libgnomedb-1.9.100-13.fc7 ------------------------- * Tue Mar 27 2007 Hans de Goede 1:1.9.100-13 - Fix categories in fedora-database-properties.desktop file (bz 234164) - Fixup packaging of sharp bindings to match the mono packaging guidelines munin-1.2.5-2.fc7 ----------------- * Tue Mar 27 2007 Kevin Fenzi - 1.2.5-2 - Fix directory ownership (fixes #233886) netmask-2.3.9-1.fc7 ------------------- * Mon Mar 26 2007 Ville Skytt? - 2.3.9-1 - 2.3.9. nfs4-acl-tools-0.3.1-1.fc7.2 ---------------------------- * Tue Mar 27 2007 Steve Dickson - 0.3.1-1.2 - Checked in to Fedora CVS * Thu Mar 08 2007 Steve Dickson - 0.3.1-1.1 - Updated to latest upstream version 0.3.1 which eliminated the need for the patches introduced in the previous commit. * Tue Mar 06 2007 Tom "spot" Callaway 0.3.0-1.1 - lose the BR for autotools - Patch in support for destdir - use %configure macro, make DESTDIR= install - add sparc to -fPIE (trivial, but correct) - destdir revealed missing/poorly created symlink, patch fixes it, add nfs4_editfacl to files - LDFLAGS passed to configure/exported were being blindly overwritten, patch fixes * Fri Mar 02 2007 Steve Dickson - 0.3.0-1 - Updated to latest upstream version 0.3.0 - Fixed minor issues in spec file from the package review openvrml-0.16.3-6.fc7 --------------------- * Tue Mar 27 2007 Braden McDaniel - 0.16.3-6 - openvrml-devel: Fixed unowned directories. perl-Smart-Comments-1.000002-4.fc7 ---------------------------------- * Tue Mar 27 2007 Chris Weyl 1.000002-4 - be more explicit with core requires python-inotify-0.7.0-2.fc7 -------------------------- * Tue Mar 27 2007 Terje Rosten - 0.7.0-2 - Fix email address * Tue Mar 06 2007 Terje Rosten - 0.7.0-1 - Initial build queuegraph-1.1-1.fc7 -------------------- * Sun Mar 25 2007 Bernard Johnson - 1.1-1 - initial release siege-2.65-3.fc7 ---------------- * Tue Mar 27 2007 Allisson Azevedo 2.65-3 - Fix .spec * Tue Mar 27 2007 Allisson Azevedo 2.65-2 - Fix .spec * Sun Mar 11 2007 Allisson Azevedo 2.65-1 - Initial RPM release sysprof-kmod-1.0.8-1.2.6.20_1.3023.fc7 -------------------------------------- vdr-wapd-0.8-16.fc7 ------------------- * Sat Mar 24 2007 Ville Skytt? - 0.8-16 - Improvement suggestions from #219097: drop build dependency on sed, improve summary and description. whysynth-dssi-20060122-10.fc7 ----------------------------- * Wed Mar 28 2007 Anthony Green 20060122-10 - Rev -10 to fix cvs problem. * Tue Mar 27 2007 Anthony Green 20060122-9 - Move icon. * Mon Mar 26 2007 Anthony Green 20060122-8 - Tweak .desktop categories. - Remove extra icons. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From katzj at redhat.com Wed Mar 28 13:15:47 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 28 Mar 2007 09:15:47 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175070576.4710.11.camel@cyberelk.elk> References: <1174965859.24384.1.camel@localhost.localdomain> <1175003869.21714.7.camel@golem.boston.devel.redhat.com> <1175014301.3815.16.camel@eagle.danny.cz> <1175070576.4710.11.camel@cyberelk.elk> Message-ID: <1175087747.7042.8.camel@aglarond.local> On Wed, 2007-03-28 at 09:29 +0100, Tim Waugh wrote: > On Tue, 2007-03-27 at 18:51 +0200, Dan Hor?k wrote: > > But it could be a task for system-config-printer - it detects printers > > and installs printer specific packages. It could be perhaps some > > connection between driver name and required packages. > > It does in fact already do this. :-) > > Unfortunately I don't know of a good hook for 'now install this package, > prompting the user first', so all it currently does it tell the user the > name of the package they should install. > > Anyone know how to make that better? The system-install-packages tool included in pirut has support now for just giving package names in addition to local packages. That gives a pretty easy way to launch "install a package named foo" Jeremy From jsacco at gnome.org Wed Mar 28 13:18:55 2007 From: jsacco at gnome.org (Joseph Sacco) Date: Wed, 28 Mar 2007 09:18:55 -0400 Subject: serial port kernel configuration problem for PowerMacs Message-ID: <1175087935.3225.25.camel@rt.jesacco.com> There is a well known device number contention bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155895 that prevents serial ports on PowerMacs from functioning when 8250 support is built directly into the kernel. While we wait [forever???] for LANANA to assign a set of device numbers for pmac_zlog that do not conflict with those assigned to the 8250, there is a simple workaround: build 8250 support as a loadable module: # # Serial drivers # CONFIG_SERIAL_8250=m CONFIG_SERIAL_8250_PCI=m CONFIG_SERIAL_8250_PNP=m I don't know of any platform that has both 8250 and pmac_zilog serial ports so this should be a painless workaround. -Joseph -- jsacco [at] gnome [dot] org From Matt_Domsch at dell.com Wed Mar 28 13:45:26 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 28 Mar 2007 08:45:26 -0500 Subject: Core x86_64 rawhide rebuild in mock status 2007-03-28 Message-ID: <20070328084526.A8548@humbolt.us.dell.com> Core Rawhide-in-Mock Build Results for x86_64 Wed Mar 28 04:21:42 CDT 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 1152 Number failed to build: 49 Number expected to fail due to ExclusiveArch or ExcludeArch: 15 Leaving: 34 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 34 ---------------------------------- alacarte-0.11.3-2.fc7 boost-1.33.1-10.fc7 castor-0.9.5-1jpp.7 compat-gcc-32-3.2.3-61 compat-gcc-34-3.4.6-7 g-wrap-1.9.6-7.1 gnome-sharp-2.16.0-1.fc6 gnome-vfs2-2.18.0.1-1.fc7 grub-0.97-13 jakarta-commons-daemon-1.0.1-6jpp.2.fc7 jgroups-2.2.9.2-3jpp.2 kdebase-3.5.6-3.fc7 kdnssd-avahi-0.1.3-0.1.20060713svn.fc6 libgssapi-0.10-2.fc7 linux-atm-2.5.0-1.20050118cvs memtest86+-1.70-1.fc7 mikmod-3.1.6-39.fc7 mysqlclient10-3.23.58-9.2.1 mysqlclient14-4.1.14-4.2.1 nfs-utils-lib-1.0.8-8.fc7 perl-5.8.8-15.fc7 *ppc64-utils-0.11-1.fc7 prelink-0.3.10-1 readahead-1.3-7.fc6 sgml-common-0.6.3-19 squirrelmail-1.4.8-4.fc6 struts-1.2.9-4jpp.2 syslinux-3.36-1.fc7 systemtap-0.5.10-1.fc7 tetex-3.0-36.fc7 valgrind-3.2.3-2 velocity-1.4-6jpp.1 xen-3.0.4-9.fc7 xferstats-2.16-14.1 * yes, this is ExclusiveArch, but it fails when populating the chroot with a dep on librtas-devel, which is also ExclusiveArch, and my scripts don't follow the whole dep tree looking for earlier ExclusiveArchs yet. -- 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 Matt_Domsch at dell.com Wed Mar 28 13:45:47 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 28 Mar 2007 08:45:47 -0500 Subject: Core i386 rawhide rebuild in mock status 2007-03-28 Message-ID: <20070328084547.A8905@humbolt.us.dell.com> Core Rawhide-in-Mock Build Results for i386 Wed Mar 28 04:24:00 CDT 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 1153 Number failed to build: 34 Number expected to fail due to ExclusiveArch or ExcludeArch: 9 Leaving: 25 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 25 ---------------------------------- castor-0.9.5-1jpp.7 g-wrap-1.9.6-7.1 gnome-sharp-2.16.0-1.fc6 gnome-vfs2-2.18.0.1-1.fc7 grub-0.97-13 jakarta-commons-daemon-1.0.1-6jpp.2.fc7 jgroups-2.2.9.2-3jpp.2 kdnssd-avahi-0.1.3-0.1.20060713svn.fc6 libgssapi-0.10-2.fc7 linux-atm-2.5.0-1.20050118cvs mikmod-3.1.6-39.fc7 mysqlclient10-3.23.58-9.2.1 mysqlclient14-4.1.14-4.2.1 nfs-utils-lib-1.0.8-8.fc7 perl-5.8.8-15.fc7 * ppc64-utils-0.11-1.fc7 prelink-0.3.10-1 readahead-1.3-7.fc6 sgml-common-0.6.3-19 squirrelmail-1.4.8-4.fc6 struts-1.2.9-4jpp.2 systemtap-0.5.10-1.fc7 tetex-3.0-36.fc7 velocity-1.4-6jpp.1 xferstats-2.16-14.1 With bugs filed: 0 ---------------------------------- * See note for x86_64 builds. -- 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 Matt_Domsch at dell.com Wed Mar 28 13:45:54 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 28 Mar 2007 08:45:54 -0500 Subject: Extras x86_64 rawhide rebuild in mock status 2007-03-28 Message-ID: <20070328084554.A8923@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for x86_64 Wed Mar 28 04:31:29 CDT 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2847 Number failed to build: 65 Number expected to fail due to ExclusiveArch or ExcludeArch: 20 Leaving: 45 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 45 ---------------------------------- Democracy-0.9.5.1-6.fc7 tscherf at redhat.com R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de atitvout-0.4-6 andreas.bierfert at lowlatency.de banshee-0.11.5-1.fc7 caillon at redhat.com checkstyle-4.1-4jpp.1.fc7 nsantos at redhat.com compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch csound-5.03.0-9.fc7 dcbw at redhat.com,paul at all-the-johnsons.co.uk em8300-kmod-0.16.1-7.2.6.20_1.2997.fc7 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net flumotion-0.2.1-3.fc6 thomas at apestaart.org gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk gtkmozembedmm-1.4.2.cvs20060817-9.fc7 karlthered at gmail.com jflex-1.3.5-2jpp.1.fc7 mwringe at redhat.com jogl-1.0.0-5.7.beta5.fc6 green at redhat.com kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libnetfilter_conntrack-0.0.50-3.fc7.src.rpm libpaper-1.1.20-5.fc6 tcallawa at redhat.com libpolyxmass-0.9.0-6.fc5 andreas.bierfert at lowlatency.de maven-scm-1.0-0.1.b3.2jpp.1.fc7 dbhole at redhat.com maven-shared-1.0-4jpp.2.fc7 dbhole at redhat.com maven-surefire-1.5.3-2jpp.2.fc7 dbhole at redhat.com mlton-20061107-2.fc7 adam at spicenitz.org nas-1.8a-2.fc7.src.rpm netcdf-3.6.2-1.fc7 ed at eh3.com nomadsync-0.4.2-13.fc6 triad at df.lth.se ntfs-config-0.5.5-2.fc7.src.rpm openvrml-0.16.3-4.fc7.src.rpm orpie-1.4.3-5.fc6 lists at forevermore.net pdftk-1.41-3.fc7 Jochen at herr-schmitt.de php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org prewikka-0.9.8-1.fc7 tscherf at redhat.com python-amara-1.1.9-7.fc7 jamatos at fc.up.pt python-reportlab-2.0-2.fc7 bdpepple at ameritech.net qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com s3switch-0.0-9.20020912.fc6 paul at xelerance.com scipy-0.5.2-1.fc7 jspaleta at gmail.com steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de toped-0.8.2-2.fc6.src.rpm xine-lib-1.1.4-3.fc7.src.rpm xmldiff-0.6.7-12.fc6 stickster at gmail.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- 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 Matt_Domsch at dell.com Wed Mar 28 13:46:10 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 28 Mar 2007 08:46:10 -0500 Subject: Extras i386 rawhide rebuild in mock status 2007-03-28 Message-ID: <20070328084610.A8943@humbolt.us.dell.com> Extras Rawhide-in-Mock Build Results for i386 Wed Mar 28 04:36:43 CDT 2007 Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 2847 Number failed to build: 34 Number expected to fail due to ExclusiveArch or ExcludeArch: 2 Leaving: 32 (there may be some duplicates if rawhide has 2 versions of a package) Of those expected to have worked... Without a bug filed: 32 ---------------------------------- Democracy-0.9.5.1-6.fc7 tscherf at redhat.com R-RScaLAPACK-0.5.1-8.fc6 tcallawa at redhat.com airsnort-0.2.7e-11.fc7 andreas.bierfert at lowlatency.de banshee-0.11.5-1.fc7 caillon at redhat.com checkstyle-4.1-4jpp.1.fc7 nsantos at redhat.com compat-erlang-R10B-10.4.fc6 gemi at bluewin.ch csound-5.03.0-9.fc7 dcbw at redhat.com,paul at all-the-johnsons.co.uk em8300-kmod-0.16.1-7.2.6.20_1.2997.fc7 ville.skytta at iki.fi fakeroot-1.5.10-13.fc7 Axel.Thimm at ATrpms.net flumotion-0.2.1-3.fc6 thomas at apestaart.org gift-0.11.8.1-6.fc7 rdieter at math.unl.edu gtk-sharp-1.0.10-12.fc7 paul at all-the-johnsons.co.uk gtkmozembedmm-1.4.2.cvs20060817-9.fc7 karlthered at gmail.com jflex-1.3.5-2jpp.1.fc7 mwringe at redhat.com jogl-1.0.0-5.7.beta5.fc6 green at redhat.com kooldock-0.3-4.20060720cvs.fc6 mr.ecik at gmail.com kyum-0.7.5-4.fc6 Jochen at herr-schmitt.de libpaper-1.1.20-5.fc6 tcallawa at redhat.com nomadsync-0.4.2-13.fc6 triad at df.lth.se openvrml-0.16.3-4.fc7.src.rpm orpie-1.4.3-5.fc6 lists at forevermore.net pdftk-1.41-3.fc7 Jochen at herr-schmitt.de php-pecl-Fileinfo-1.0.4-1.fc7 fedora at theholbrooks.org qa-assistant-0.4.90.5-2.fc6 toshio at tiki-lounge.com scipy-0.5.2-1.fc7 jspaleta at gmail.com steghide-0.5.1-2.fc6 Jochen at herr-schmitt.de sysprof-kmod-1.0.8-1.2.6.20_1.3017.fc7 giallu at gmail.com toped-0.8.2-2.fc6.src.rpm xine-lib-1.1.4-3.fc7.src.rpm xmldiff-0.6.7-12.fc6 stickster at gmail.com xsupplicant-1.2.8-1.fc7.1 tcallawa at redhat.com zope-2.9.4-2.fc6 jonathansteffan at gmail.com With bugs filed: 0 ---------------------------------- -- 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 jdieter at gmail.com Wed Mar 28 14:08:27 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 28 Mar 2007 17:08:27 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <460A584C.2060109@fedoraproject.org> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> Message-ID: <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> On Wed, 2007-03-28 at 17:28 +0530, Rahul Sundaram wrote: > Jonathan Dieter wrote: > > On Mon, 2007-03-26 at 21:02 +0530, Rahul Sundaram wrote: > >> Sure. Different output with 0.2.6 and yum -d5. > > > >> File "/usr/lib/python2.4/site-packages/yum/plugins.py", line 153, in run > >> func(conduitcls(self, self.base, conf, **kwargs)) > >> File "/usr/lib/yum-plugins/presto.py", line 85, in postresolve_hook > >> (chosen_drpm, installed, local) = > >> prestoTransaction.find_available_drpms(conduit, newpkg) > >> File "/usr/share/presto/prestoTransaction.py", line 48, in > >> find_available_drpms > >> if os.path.exists(newpkg.po.localpath): > >> AttributeError: YumInstalledPackage instance has no attribute 'localpath' > >> > >> > >> Rahul > >> > > Well, at least I've moved the problem forward a few lines of code, > > worthless as that is. Try 0.2.7 (again with -d 5, please), and let's > > see if I've finally got it fixed! > > Fresh installation of Fedora Core 6 > > Yum install deltarpm version 3.4-1 from Fedora Extras > Install yum-presto version 0.2.9-1 from the wiki page > wget the repo file into /etc/yum.repos.d. Verified that it is enabled > Disable updates and extras repository. Core repo is left enabled. > > Here is the output: > > yum -d10 update > Loading "presto" plugin > Loading "installonlyn" plugin > Running "config" handler for "presto" plugin > Running "config" handler for "installonlyn" plugin > Yum Version: 3.0 > COMMAND: yum -d10 > Installroot: / > Setting up Update Process > Setting up repositories > Running "postreposetup" handler for "presto" plugin > Setting up Presto > Reading Presto metadata in from local files > No drpms available for presto > No drpms available for core > Reading repository metadata in from local files > Setting up Package Sacks > Reading Local RPMDB > Building updates object > No Packages marked for Update/Obsoletion > > If I enable updates and extras yum does starts downloading header files. > > Rahul Yeah, that's how it's supposed to work. The presto repository *only* contains yum-presto, so you'll get automatic presto updates. Do a normal yum update with updates and extras. If you want to understand why (and aren't sick of extremely long explanations), read on. Presto works on top of whatever repositories it's been made for (at the moment, only updates and extras). The idea is that livna could set up their own presto repository and so could freshrpms. For people without presto, it would work as a normal repository, while for people with presto, it would be a presto-enhanced respository. There are two ways to tell presto when there's a presto repository: 1. In the repository file (i.e. fedora-updates.repo), add a deltaurl with the presto repository location (should work with deltamirrorlist as well) 2. In the presto.conf file in /etc/yum/pluginconf.d. You make a section with the name of the repository (much like yum does if you use a centralized yum.conf) and add the deltaurl under it. At the moment, we are using the second way because we don't want to mess around with fedora-updates.repo and fedora-extras.repo on people's systems. If a repository was using presto themselves, they would release their .repo file using the first method. Sorry I've been so long-winded. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Wed Mar 28 14:09:16 2007 From: peter at thecodergeek.com (Peter Gordon) Date: Wed, 28 Mar 2007 07:09:16 -0700 Subject: rpms/viewvc/devel viewvc.spec,1.2,1.3 In-Reply-To: <200703280947.28406.ville.skytta@iki.fi> References: <200703280543.l2S5hNBt010348@cvs-int.fedora.redhat.com> <1175061446.10365.2.camel@tuxhugs> <200703280947.28406.ville.skytta@iki.fi> Message-ID: <1175090956.3911.1.camel@tuxhugs> On Wed, 2007-03-28 at 09:47 +0300, Ville Skytt? wrote: > I think there's no need to add the Provides in this case. And the Obsoletes > should be a disttagless %{name}-selinux < 1.0.3-13. > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-3cfc1ea19d28975faad9d56f70a6ae55661d3c3d Ah; I see. That makes it much clearer for me. Thanks! -- Peter Gordon (codergeek42) / FSF & EFF Member GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 Blog: http://thecodergeek.com/blog/ About: http://fedoraproject.org/wiki/PeterGordon -------------- 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 kodis at mail630.gsfc.nasa.gov Wed Mar 28 14:21:12 2007 From: kodis at mail630.gsfc.nasa.gov (kodis at mail630.gsfc.nasa.gov) Date: Wed, 28 Mar 2007 10:21:12 -0400 Subject: dropping autoconf dependency on imake In-Reply-To: <460998DA.1000407@develer.com> References: <460998DA.1000407@develer.com> Message-ID: <20070328142112.GA29731@tux.gsfc.nasa.gov> On Wed, Mar 28, 2007 at 12:21:14AM +0200, Bernardo Innocenti wrote: > Why does [autoconf] need imake? Can we get rid of it? >From the autoconf info file: The following macros check for operating system services or capabilities. - Macro: AC_PATH_X Try to locate the X Window System include files and libraries. If the user gave the command line options `--x-includes=DIR' and `--x-libraries=DIR', use those directories. If either or both were not given, get the missing values by running `xmkmf' on a trivial `Imakefile' and examining the `Makefile' that it produces. If that fails (such as if `xmkmf' is not present), look for the files in several directories where they often reside. If either method is successful, set the shell variables `x_includes' and `x_libraries' to their locations, unless they are in directories the compiler searches by default. From mitr at volny.cz Wed Mar 28 14:24:22 2007 From: mitr at volny.cz (Miloslav Trmac) Date: Wed, 28 Mar 2007 16:24:22 +0200 Subject: dropping autoconf dependency on imake In-Reply-To: <20070328142112.GA29731@tux.gsfc.nasa.gov> References: <460998DA.1000407@develer.com> <20070328142112.GA29731@tux.gsfc.nasa.gov> Message-ID: <460A7A96.7050507@volny.cz> kodis at mail630.gsfc.nasa.gov napsal(a): > On Wed, Mar 28, 2007 at 12:21:14AM +0200, Bernardo Innocenti wrote: >> Why does [autoconf] need imake? Can we get rid of it? > - Macro: AC_PATH_X > Try to locate the X Window System include files and > libraries. If the user gave the command line options > `--x-includes=DIR' and `--x-libraries=DIR', use those > directories. If either or both were not given, get the > missing values by running `xmkmf' on a trivial `Imakefile' > and examining the `Makefile' that it produces. This means that the generated configure file needs imake, not that autoconf needs imake. Mirek From buildsys at redhat.com Wed Mar 28 14:47:32 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 28 Mar 2007 10:47:32 -0400 Subject: rawhide report: 20070328 changes Message-ID: <200703281447.l2SElWg5005693@hs20-bc2-6.build.redhat.com> Updated Packages: (none) Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.13-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.13-1.fc7.s390 requires kernel >= 0:2.6.9-11 From jdieter at gmail.com Wed Mar 28 14:52:44 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 28 Mar 2007 17:52:44 +0300 Subject: Presto 0.3.0 Message-ID: <1175093564.23281.27.camel@jndwidescreen.lesbg.loc> I've just finished yum-presto-0.3.0. The major difference between it and 0.2.9 is that presto will now attempt to download the full rpm if it is unable to rebuild it from the deltarpm. This involved a lot of new code, so you may run into some bugs, but it should be much faster than 0.2.9 when checking deltarpms. Jonathan -------------- 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 Wed Mar 28 14:53:04 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 28 Mar 2007 16:53:04 +0200 Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175086999.32396.31.camel@willson> References: <46092F16.1010608@nicubunu.ro> <460936A3.4070408@fedoraproject.org> <1175009409.6100.4.camel@willson> <20070327171707.GE2888@free.fr> <1175051938.32396.3.camel@willson> <20070328081040.GA2906@free.fr> <1175086999.32396.31.camel@willson> Message-ID: <20070328145304.GB3569@free.fr> On Wed, Mar 28, 2007 at 09:03:18AM -0400, Simo Sorce wrote: > > It does not, go back and read the GPL, the GPL does not apply to other > programs/binaries source even if shipped on the same medium. And a > package is a sort of convenience medium you use to ship sources. That's certainly what is debatable. Is everything in a src.rpm covered by the clause 3.b of the GPL.? I thought so, but I may be wrong. Here is the clause: b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. > part of the package) and ship them. If one is GPLed the other does not > become automatically GPLed (that would be viral! But the GPL is not). The GPL is viral as the above clause shows, the issue is: is a src.rpm 'mere aggregation' or a 'work distributed and published...' I thought that it wasn't mere agregation and that it had to conform to the clause 3.b. I may be wrong. In any case I think that it could only be a court that would definitly settle such issue. -- Pat From sundaram at fedoraproject.org Wed Mar 28 15:09:39 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 28 Mar 2007 20:39:39 +0530 Subject: hplip: hp-toolbox advertising? In-Reply-To: <20070328145304.GB3569@free.fr> References: <46092F16.1010608@nicubunu.ro> <460936A3.4070408@fedoraproject.org> <1175009409.6100.4.camel@willson> <20070327171707.GE2888@free.fr> <1175051938.32396.3.camel@willson> <20070328081040.GA2906@free.fr> <1175086999.32396.31.camel@willson> <20070328145304.GB3569@free.fr> Message-ID: <460A8533.1030202@fedoraproject.org> Patrice Dumas wrote: > On Wed, Mar 28, 2007 at 09:03:18AM -0400, Simo Sorce wrote: >> It does not, go back and read the GPL, the GPL does not apply to other >> programs/binaries source even if shipped on the same medium. And a >> package is a sort of convenience medium you use to ship sources. > > That's certainly what is debatable. Is everything in a src.rpm > covered by the clause 3.b of the GPL.? I thought so, but I may > be wrong. Here is the clause: > > b) You must cause any work that you distribute or publish, that in > whole or in part contains or is derived from the Program or any > part thereof, to be licensed as a whole at no charge to all third > parties under the terms of this License. > > >> part of the package) and ship them. If one is GPLed the other does not >> become automatically GPLed (that would be viral! But the GPL is not). > > The GPL is viral as the above clause shows, the issue is: is > a src.rpm 'mere aggregation' or a 'work distributed and published...' > I thought that it wasn't mere agregation and that it had to conform > to the clause 3.b. I may be wrong. In any case I think that it could > only be a court that would definitly settle such issue. It is mere aggregation since the other parts do not contain or derive from any software licensed under the GPL. If I licensed my software under say MIT X11 license then there is simply no way another license can automatically relicense my software under any different license. That simply does not work under copyright law. You can however produce a derivative work if both components are under compatible licenses. The act of putting distinct packages in the same srpm creates no such derivative work. See if you can find any relatively well known sources agreeing with you. IMO this is not a gray area that requires any court case to clarify. Rahul PS: We really really should not be playing lawyers here. If you have a actual case that would affect Fedora and there is no general consensus we can ask the real lawyers. Otherwise do take this discussion off fedora-devel. From ssorce at redhat.com Wed Mar 28 16:00:43 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 28 Mar 2007 12:00:43 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: <460A8533.1030202@fedoraproject.org> References: <46092F16.1010608@nicubunu.ro> <460936A3.4070408@fedoraproject.org> <1175009409.6100.4.camel@willson> <20070327171707.GE2888@free.fr> <1175051938.32396.3.camel@willson> <20070328081040.GA2906@free.fr> <1175086999.32396.31.camel@willson> <20070328145304.GB3569@free.fr> <460A8533.1030202@fedoraproject.org> Message-ID: <1175097643.32396.33.camel@willson> On Wed, 2007-03-28 at 20:39 +0530, Rahul Sundaram wrote: > It is mere aggregation since the other parts do not contain or derive > from any software licensed under the GPL. If I licensed my software > under say MIT X11 license then there is simply no way another license > can automatically relicense my software under any different license. > That simply does not work under copyright law. You can however produce a > derivative work if both components are under compatible licenses. The > act of putting distinct packages in the same srpm creates no such > derivative work. See if you can find any relatively well known sources > agreeing with you. IMO this is not a gray area that requires any court > case to clarify. +1 > Rahul > > PS: We really really should not be playing lawyers here. If you have a > actual case that would affect Fedora and there is no general consensus > we can ask the real lawyers. Otherwise do take this discussion off > fedora-devel. +10 From jwboyer at jdub.homelinux.org Wed Mar 28 16:05:58 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 28 Mar 2007 11:05:58 -0500 Subject: hplip: hp-toolbox advertising? In-Reply-To: <20070328145304.GB3569@free.fr> References: <46092F16.1010608@nicubunu.ro> <460936A3.4070408@fedoraproject.org> <1175009409.6100.4.camel@willson> <20070327171707.GE2888@free.fr> <1175051938.32396.3.camel@willson> <20070328081040.GA2906@free.fr> <1175086999.32396.31.camel@willson> <20070328145304.GB3569@free.fr> Message-ID: <1175097958.7553.68.camel@zod.rchland.ibm.com> On Wed, 2007-03-28 at 16:53 +0200, Patrice Dumas wrote: > On Wed, Mar 28, 2007 at 09:03:18AM -0400, Simo Sorce wrote: > > > > It does not, go back and read the GPL, the GPL does not apply to other > > programs/binaries source even if shipped on the same medium. And a > > package is a sort of convenience medium you use to ship sources. > > That's certainly what is debatable. Is everything in a src.rpm > covered by the clause 3.b of the GPL.? I thought so, but I may > be wrong. Here is the clause: > > b) You must cause any work that you distribute or publish, that in > whole or in part contains or is derived from the Program or any > part thereof, to be licensed as a whole at no charge to all third > parties under the terms of this License. > > > > part of the package) and ship them. If one is GPLed the other does not > > become automatically GPLed (that would be viral! But the GPL is not). > > The GPL is viral as the above clause shows, the issue is: is > a src.rpm 'mere aggregation' or a 'work distributed and published...' > I thought that it wasn't mere agregation and that it had to conform > to the clause 3.b. I may be wrong. In any case I think that it could > only be a court that would definitly settle such issue. You are wrong. If that theory were true, it means you could take GPLd program A, untar the source to directory A, take non-GPLd program B, untar the source to directory B, and then create a new tarball containing both of those directories and now both programs must be licensed under the GPL. Being in the same tarball, SRPM, CD, DVD, etc. does not make it a derivative work. josh From pertusus at free.fr Wed Mar 28 16:22:10 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 28 Mar 2007 18:22:10 +0200 Subject: hplip: hp-toolbox advertising? In-Reply-To: <460A8533.1030202@fedoraproject.org> References: <460936A3.4070408@fedoraproject.org> <1175009409.6100.4.camel@willson> <20070327171707.GE2888@free.fr> <1175051938.32396.3.camel@willson> <20070328081040.GA2906@free.fr> <1175086999.32396.31.camel@willson> <20070328145304.GB3569@free.fr> <460A8533.1030202@fedoraproject.org> Message-ID: <20070328162210.GB5223@free.fr> On Wed, Mar 28, 2007 at 08:39:39PM +0530, Rahul Sundaram wrote: > > It is mere aggregation since the other parts do not contain or derive > from any software licensed under the GPL. If I licensed my software > under say MIT X11 license then there is simply no way another license > can automatically relicense my software under any different license. > That simply does not work under copyright law. You can however produce a > derivative work if both components are under compatible licenses. The > act of putting distinct packages in the same srpm creates no such > derivative work. See if you can find any relatively well known sources > agreeing with you. IMO this is not a gray area that requires any court > case to clarify. Ok. I don't remember where I saw that, or if I just imagined it myself. > Rahul > > PS: We really really should not be playing lawyers here. If you have a > actual case that would affect Fedora and there is no general consensus > we can ask the real lawyers. Otherwise do take this discussion off > fedora-devel. In my opinion this is for fedora-devel, since it impacts on reviews. I have repeatedly annoyed submitters by saying that a src.rpm as a whole was a derived work of each of the tarballs. Now I stand corrected. Similarly I have argued that all the files in a tarball needed to be GPL compatible if there was a single GPL file in the tarball, this seems to be wrong too, if the 2 files don't have any relationship at link time and no runtime inclusion (say a C program and a script). -- Pat From sundaram at fedoraproject.org Wed Mar 28 16:41:18 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 28 Mar 2007 22:11:18 +0530 Subject: hplip: hp-toolbox advertising? In-Reply-To: <20070328162210.GB5223@free.fr> References: <460936A3.4070408@fedoraproject.org> <1175009409.6100.4.camel@willson> <20070327171707.GE2888@free.fr> <1175051938.32396.3.camel@willson> <20070328081040.GA2906@free.fr> <1175086999.32396.31.camel@willson> <20070328145304.GB3569@free.fr> <460A8533.1030202@fedoraproject.org> <20070328162210.GB5223@free.fr> Message-ID: <460A9AAE.4070507@fedoraproject.org> Patrice Dumas wrote: > In my opinion this is for fedora-devel, since it impacts on reviews. > I have repeatedly annoyed submitters by saying that a src.rpm as a whole > was a derived work of each of the tarballs. Now I stand corrected. > Similarly I have argued that all the files in a tarball needed to be > GPL compatible if there was a single GPL file in the tarball, this seems > to be wrong too, if the 2 files don't have any relationship at link time > and no runtime inclusion (say a C program and a script). I thought you claimed this is one of the reviews and were corrected by someone else. Make sure you clarify any legal issues in fedora-maintainers list before enforcing it on reviewers. At any rate it looks we need a FAQ on common legal issues. If you have a list I can write it up and run it via Red Hat Legal. Rahul From dwmw2 at infradead.org Wed Mar 28 16:46:43 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 28 Mar 2007 17:46:43 +0100 Subject: kernel config question In-Reply-To: <20070328163545.GA23360@kroah.com> References: <1174180224.30317.3.camel@sonlaptop> <1174232436.3461.619.camel@pmac.infradead.org> <20070319145355.GB18278@nostromo.devel.redhat.com> <1174317395.3392.146.camel@pmac.infradead.org> <20070319151344.GA20687@nostromo.devel.redhat.com> <1174318149.3392.153.camel@pmac.infradead.org> <20070319152844.GA22192@nostromo.devel.redhat.com> <1174319679.3392.157.camel@pmac.infradead.org> <20070319155656.GB22192@nostromo.devel.redhat.com> <1175070543.3277.107.camel@pmac.infradead.org> <20070328163545.GA23360@kroah.com> Message-ID: <1175100403.3277.184.camel@pmac.infradead.org> On Wed, 2007-03-28 at 09:35 -0700, Greg KH wrote: > On Wed, Mar 28, 2007 at 09:29:03AM +0100, David Woodhouse wrote: > > On Mon, 2007-03-19 at 11:56 -0400, Bill Nottingham wrote: > > > > But changes to environment variables in the hotplug script > > > > invocations shouldn't hurt, right? > > > > > > No, but that's not the reason we have DEPRECATED on. > > > > OK, thanks for the information. I've committed a crappy hack which > > disables those extra environment variables (the ones which > > CONFIG_SYSFS_DEPRECATED enables). It's those which were crashing the > > kernel. > > Huh? Care to point me to more information about this? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227893 (and a bunch of dupes), and also in your inbox on 19th March, with subject "sysfs use-after-free in 2.6.21-rc" > > It's not the _correct_ fix, because the crash is just a _symptom_ of the > > fact that somewhere in that sysfs mess we have a pointer to freed > > memory. But at least it prevents the kernel from crashing, which is > > probably a good thing in the short term. > > What kernel version are we talking about here? Fedora rawhide -- basically Linus' HEAD. We've been seeing it ever since we enabled CONFIG_SYSFS_DEPRECATED about 2.6.20-rc6-git1. For the moment I've committed a hack to disable the extra variables in uevents, since that wasn't why we turned SYSFS_DEPRECATED on again anyway. It's not a fix though. -- dwmw2 From jdieter at gmail.com Wed Mar 28 17:01:13 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Wed, 28 Mar 2007 20:01:13 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> Message-ID: <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> On Wed, 2007-03-28 at 17:08 +0300, Jonathan Dieter wrote: > On Wed, 2007-03-28 at 17:28 +0530, Rahul Sundaram wrote: > > Fresh installation of Fedora Core 6 > > > > Yum install deltarpm version 3.4-1 from Fedora Extras > > Install yum-presto version 0.2.9-1 from the wiki page > > wget the repo file into /etc/yum.repos.d. Verified that it is enabled > > Disable updates and extras repository. Core repo is left enabled. > > > > Here is the output: > > > > > > If I enable updates and extras yum does starts downloading header files. > > > > Rahul > Yeah, that's how it's supposed to work. The presto repository *only* > contains yum-presto, so you'll get automatic presto updates. > > Do a normal yum update with updates and extras. If you want to > understand why (and aren't sick of extremely long explanations), read > on. > So yeah, I'm curious. Have you managed to do your update yet? If you have, what kind of savings did you see? Jonathan -------------- 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 Wed Mar 28 17:40:18 2007 From: lmacken at redhat.com (Luke Macken) Date: Wed, 28 Mar 2007 13:40:18 -0400 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: <64171.65.192.24.190.1175026507.squirrel@mail.jcomserv.net> References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <46097882.9030802@redhat.com> <64171.65.192.24.190.1175026507.squirrel@mail.jcomserv.net> Message-ID: <20070328174018.GF2483@tomservo.rh.rit.edu> After installing ettercap, nothing owns /usr/bin/ettercap, due to it getting created by alternatives in the %post. luke On Tue, Mar 27, 2007 at 03:15:07PM -0500, Jon Ciesla wrote: > Thanks. Got a bit turned around. :) > > > Patrice Dumas wrote: > >> On Mon, Mar 26, 2007 at 09:59:35PM -0400, Jon Ciesla wrote: > >>> -Provides: ettercap-plugins <= %{version} > >>> +Obsoletes: ettercap-plugins <= 0.7.3-14%{dist} > >> > >> I suggest hardcoding the %{dist} to what it was when the package was > >> merged (so I guess it is fc7 here). For the fc6 and fc5 packages it > >> is not as clear, but I guess that using fc7 too would be safer. > > > > Obsoletes: ettercap-plugins < 0.7.3-15 From limb at jcomserv.net Wed Mar 28 17:46:09 2007 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 28 Mar 2007 12:46:09 -0500 (CDT) Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: <20070328174018.GF2483@tomservo.rh.rit.edu> References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <46097882.9030802@redhat.com> <64171.65.192.24.190.1175026507.squirrel@mail.jcomserv.net> <20070328174018.GF2483@tomservo.rh.rit.edu> Message-ID: <6514.65.192.24.190.1175103969.squirrel@mail.jcomserv.net> If I add it to %files, when I build, it fails, as /usr/bin/ettercap does not exist. Is there a workaround? > After installing ettercap, nothing owns /usr/bin/ettercap, due to it > getting created by alternatives in the %post. > > luke > > On Tue, Mar 27, 2007 at 03:15:07PM -0500, Jon Ciesla wrote: >> Thanks. Got a bit turned around. :) >> >> > Patrice Dumas wrote: >> >> On Mon, Mar 26, 2007 at 09:59:35PM -0400, Jon Ciesla wrote: >> >>> -Provides: ettercap-plugins <= %{version} >> >>> +Obsoletes: ettercap-plugins <= 0.7.3-14%{dist} >> >> >> >> I suggest hardcoding the %{dist} to what it was when the package was >> >> merged (so I guess it is fc7 here). For the fc6 and fc5 packages it >> >> is not as clear, but I guess that using fc7 too would be safer. >> > >> > Obsoletes: ettercap-plugins < 0.7.3-15 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From rdieter at math.unl.edu Wed Mar 28 17:54:51 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 28 Mar 2007 12:54:51 -0500 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <46097882.9030802@redhat.com> <64171.65.192.24.190.1175026507.squirrel@mail.jcomserv.net> <20070328174018.GF2483@tomservo.rh.rit.edu> <6514.65.192.24.190.1175103969.squirrel@mail.jcomserv.net> Message-ID: Jon Ciesla wrote: > If I add it to %files, when I build, it fails, as /usr/bin/ettercap does > not exist. Is there a workaround? in %install, include: touch %{_bindir}/ettercap in %files, include: %ghost %{_bindir}/ettercap -- Rex From list at pceet030.cern.ch Wed Mar 28 19:04:46 2007 From: list at pceet030.cern.ch (Alfredo Ferrari) Date: Wed, 28 Mar 2007 21:04:46 +0200 (CEST) Subject: hplip: hp-toolbox advertising? In-Reply-To: <1175053630.32396.26.camel@willson> References: <200703271645.24712.jkeating@redhat.com> <46099C7D.3080008@fedoraproject.org> <4609AE42.8070009@fedoraproject.org> <1175053630.32396.26.camel@willson> Message-ID: On Tue, 27 Mar 2007, Simo Sorce wrote: > > Bernard, > I can't agree more with what you said, this discussion is silly, it > start reminding me some of the more brain-damaged discussions on Debian > lists. I hope it is an isolate incident, and is not becoming the norm or > next we will declare that Trademarks, documentation, and just everything > in the world is software and any license but the GPL is bad. > > Don't get me wrong, I love the GPL, it is the license I use for my > software, but _software_ is the key here. Names, logos, documentation > are a different matter. Please let's not get stupid and let's recognize > things from what they are. > > Trademarks, are not good or bad by themselves, it is the use you do of > them that can be good or bad. HP's trademark/logo in hp-toolbox is on > the side of the "good" way much more than what is the Mozilla's Firefox > trademark/logo. > > On Tue, 2007-03-27 at 19:04 -0600, Bernard Johnson wrote: >> All the "free software zealots" say to vote with your pocketbook. I >> did. I bought a $1000 SOHO printer BECAUSE THEY HAD LINUX SUPPORT. And >> not just a blob, real GPL software. Now I hear total bogus arguments >> like "it's advertising" [but don't look at these other things that are >> advertising as well that we will let slide] or "yeah, it's free but it's >> not good enough"[2][3]. > > HP People didn't attach any string to the use of that logo for that > software, so any discussion about removing it, is just plain silly, IMO. > > We are beyond "free software zealots" we reached the point of "berserk > kamikaze zealots" if we actually go down this road. > >> This is exactly the attitude that will cause Linux to not get any >> support by vendors. > > Wise words. We need more software not less, there is still a *LOT* of > software niches that have no sort of free software of any kind, and > pretty big ones. > > And people here waste time arguing by a trademarked logo in a GPL > package that comes with no sort of requirements? Are you insane? Or > what? > >> The fact of the matter is that it takes vendor support to make >> Fedora/RedHat anything other than a toy operating system for many uses. >> At many junctures, we have to make conscious trade offs between >> idealogical beliefs and functionality. That trade off may be a little >> recognition of the hard work that someone / some company put into the >> software, and I say that's great, give it to them. > > If only this little "advertising" could be used to make more companies > write and distribute GPL software I would ask for MORE of this kind > advertising, that would be just great. > > On the software quality I would really avoid commenting, we have such > crap in free software that complaining about the quality of *useful* > *free software* is beyond my comprehension. When the people that don't > like it, will rewrite and support a better piece of software to cover > the same functionality, then they will be entitled to speak about > removing others software. > > Please, I beg you try to use your head and think: > > a) what is the right thing to do to help users (NOW, not "in 10 years > maybe") with *free software* > b) what is the right thing to do to spread more *free software* > c) what is the right way to get more vendors to help us with *free > software* > d) what is the right thing to do to avoid waisting time and produce more > *free software* > > To me the answers are pretty clear wrt this case. > > Simo. > > I can't agree more with Bernard and Simo. Rampant masochism is the real enemy of free software. Alfredo BTW I bought a multifunction HP printer/scanner/fax etc JUST BECAUSE it was fully and freely supported in Linux... -- +----------------------------------------------------------------------------+ | 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 markg85 at gmail.com Wed Mar 28 19:55:37 2007 From: markg85 at gmail.com (Mark) Date: Wed, 28 Mar 2007 21:55:37 +0200 Subject: Is it a bug or intentionally done? Message-ID: <6e24a8e80703281255w1cbcedb3ve4edc0b9fa95b600@mail.gmail.com> Hey, i was just trying to make a screenshot of my gnome menu, but somehow the screenhot window simply won`t appear when i press the "Print Screen" button on my keyboard. it`s appearing just fine on other places unless i clicked a menu (so that the menu is expanded) bug? or normal behavior? Thanx, Mark. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mclasen at redhat.com Wed Mar 28 20:01:22 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 28 Mar 2007 16:01:22 -0400 Subject: Is it a bug or intentionally done? In-Reply-To: <6e24a8e80703281255w1cbcedb3ve4edc0b9fa95b600@mail.gmail.com> References: <6e24a8e80703281255w1cbcedb3ve4edc0b9fa95b600@mail.gmail.com> Message-ID: <1175112082.4641.70.camel@localhost.localdomain> On Wed, 2007-03-28 at 21:55 +0200, Mark wrote: > Hey, > > i was just trying to make a screenshot of my gnome menu, but somehow > the screenhot window simply won`t appear when i press the "Print > Screen" button on my keyboard. it`s appearing just fine on other > places unless i clicked a menu (so that the menu is expanded) > > bug? or normal behavior? > Normal. Menus grab the keyboard when they are shown. You can use other tools which allow you to grab a screenshot after a timout, e.g. Gimp. From j.w.r.degoede at hhs.nl Wed Mar 28 20:20:24 2007 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 28 Mar 2007 22:20:24 +0200 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <200703271645.24712.jkeating@redhat.com> <46099C7D.3080008@fedoraproject.org> <4609AE42.8070009@fedoraproject.org> <1175053630.32396.26.camel@willson> Message-ID: <460ACE08.9010205@hhs.nl> Alfredo Ferrari wrote: > > BTW I bought a multifunction HP printer/scanner/fax etc JUST BECAUSE > it was fully and freely supported in Linux... > /me too, Can we please stop the HP bashing, they are doing a great job in providing support for their hardware, if their tools need better integration into the rest of Linux, then work with them, instead of bashing them / their software. Regards, Hans From tmus at tmus.dk Wed Mar 28 18:59:23 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 28 Mar 2007 20:59:23 +0200 Subject: Rawhide will be a bit late today... In-Reply-To: <20070328123411.GA21250@jadzia.bu.edu> References: <200703280817.39433.jkeating@redhat.com> <20070328123411.GA21250@jadzia.bu.edu> Message-ID: Matthew Miller wrote: > On Wed, Mar 28, 2007 at 08:17:39AM -0400, Jesse Keating wrote: >> As expected, something blew up a bit in the rawhide compose process now >> that we've unfroze. However HOW it blew up was completely unexpected, but >> very easy to recover from. Rawhide is composing again and should see the >> light of day in a few hours. > > If things don't blow up, is there a "normal" time for it to be available? > (I'd like to adjust my mirror to be in sync with that.) > Perhaps if we used some kind of mirror sync flag for mirror scripts to check against to learn when an upstream host is in a synced state? Enough said! ;-) /Thomas From mattdm at mattdm.org Wed Mar 28 20:16:10 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 28 Mar 2007 16:16:10 -0400 Subject: Rawhide will be a bit late today... In-Reply-To: References: <200703280817.39433.jkeating@redhat.com> <20070328123411.GA21250@jadzia.bu.edu> Message-ID: <20070328201610.GA29303@jadzia.bu.edu> On Wed, Mar 28, 2007 at 08:59:23PM +0200, Thomas M Steenholdt wrote: > >If things don't blow up, is there a "normal" time for it to be available? > >(I'd like to adjust my mirror to be in sync with that.) > Perhaps if we used some kind of mirror sync flag for mirror scripts to > check against to learn when an upstream host is in a synced state? > Enough said! ;-) Yes, sooner or later. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From pemboa at gmail.com Wed Mar 28 20:19:46 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 28 Mar 2007 15:19:46 -0500 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <200703271645.24712.jkeating@redhat.com> <46099C7D.3080008@fedoraproject.org> <4609AE42.8070009@fedoraproject.org> <1175053630.32396.26.camel@willson> Message-ID: <16de708d0703281319l440a57b1u8d8a50f26c9331e8@mail.gmail.com> On 3/28/07, Alfredo Ferrari wrote: > On Tue, 27 Mar 2007, Simo Sorce wrote: > > > > > Bernard, > > I can't agree more with what you said, this discussion is silly, it > > start reminding me some of the more brain-damaged discussions on Debian > > lists. I hope it is an isolate incident, and is not becoming the norm or > > next we will declare that Trademarks, documentation, and just everything > > in the world is software and any license but the GPL is bad. > > > > Don't get me wrong, I love the GPL, it is the license I use for my > > software, but _software_ is the key here. Names, logos, documentation > > are a different matter. Please let's not get stupid and let's recognize > > things from what they are. > > > > Trademarks, are not good or bad by themselves, it is the use you do of > > them that can be good or bad. HP's trademark/logo in hp-toolbox is on > > the side of the "good" way much more than what is the Mozilla's Firefox > > trademark/logo. > > > > On Tue, 2007-03-27 at 19:04 -0600, Bernard Johnson wrote: > >> All the "free software zealots" say to vote with your pocketbook. I > >> did. I bought a $1000 SOHO printer BECAUSE THEY HAD LINUX SUPPORT. And > >> not just a blob, real GPL software. Now I hear total bogus arguments > >> like "it's advertising" [but don't look at these other things that are > >> advertising as well that we will let slide] or "yeah, it's free but it's > >> not good enough"[2][3]. > > > > HP People didn't attach any string to the use of that logo for that > > software, so any discussion about removing it, is just plain silly, IMO. > > > > We are beyond "free software zealots" we reached the point of "berserk > > kamikaze zealots" if we actually go down this road. > > > >> This is exactly the attitude that will cause Linux to not get any > >> support by vendors. > > > > Wise words. We need more software not less, there is still a *LOT* of > > software niches that have no sort of free software of any kind, and > > pretty big ones. > > > > And people here waste time arguing by a trademarked logo in a GPL > > package that comes with no sort of requirements? Are you insane? Or > > what? > > > >> The fact of the matter is that it takes vendor support to make > >> Fedora/RedHat anything other than a toy operating system for many uses. > >> At many junctures, we have to make conscious trade offs between > >> idealogical beliefs and functionality. That trade off may be a little > >> recognition of the hard work that someone / some company put into the > >> software, and I say that's great, give it to them. > > > > If only this little "advertising" could be used to make more companies > > write and distribute GPL software I would ask for MORE of this kind > > advertising, that would be just great. > > > > On the software quality I would really avoid commenting, we have such > > crap in free software that complaining about the quality of *useful* > > *free software* is beyond my comprehension. When the people that don't > > like it, will rewrite and support a better piece of software to cover > > the same functionality, then they will be entitled to speak about > > removing others software. > > > > Please, I beg you try to use your head and think: > > > > a) what is the right thing to do to help users (NOW, not "in 10 years > > maybe") with *free software* > > b) what is the right thing to do to spread more *free software* > > c) what is the right way to get more vendors to help us with *free > > software* > > d) what is the right thing to do to avoid waisting time and produce more > > *free software* > > > > To me the answers are pretty clear wrt this case. > > > > Simo. > > > > > > I can't agree more with Bernard and Simo. Rampant masochism is the real > enemy of free software. > > Alfredo > > BTW I bought a multifunction HP printer/scanner/fax etc JUST BECAUSE > it was fully and freely supported in Linux... > Me too, I had no idea there was such apparent hatred of the solution. -- Fedora Core 6 and proud From drago01 at gmail.com Wed Mar 28 20:25:00 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 28 Mar 2007 22:25:00 +0200 Subject: fc6 gaim update is BROKEN! Message-ID: <460ACF1C.7070401@gmail.com> FC6 got a gaim update today which was not in updates testing before. Its completly broken... changing status without typing a message -> segfault When logging into icq it shows a message "Could not add buddy 1" Downgrade is also not possible because it somehow changed the contents of .gaim Why has this package made it to updates without any previous testing? From wwoods at redhat.com Wed Mar 28 20:25:41 2007 From: wwoods at redhat.com (Will Woods) Date: Wed, 28 Mar 2007 16:25:41 -0400 Subject: Bug Day this Friday! Message-ID: <1175113541.6884.22.camel@metroid.rdu.redhat.com> We're going to have another Bug Day this Friday! Last week just a couple of us managed to clean out a couple dozen old test-release bugs. This week we're working on rawhide bugs - much more relevant! I'll be around #fedora-devel from 10-6 EDT (that's 1400-2200 UTC) to guide people trying to make sure the bugs are cleaned up. Here's the link to the rawhide bug list for this week: http://rdr.to/W9 Does anyone in a different time zone (or with a different schedule) want to supervise for a different shift? (David Neilsen, I'm looking in your direction.. :) Hope to see you there. -w -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Wed Mar 28 20:28:47 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 28 Mar 2007 22:28:47 +0200 Subject: fc6 gaim update is BROKEN! In-Reply-To: <460ACF1C.7070401@gmail.com> References: <460ACF1C.7070401@gmail.com> Message-ID: <1175113727.21346.0.camel@rousalka.dyndns.org> Le mercredi 28 mars 2007 ? 22:25 +0200, dragoran a ?crit : > When logging into icq it shows a message "Could not add buddy 1" Been doing this for quite a long time in rawhide -- 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 Lam at Lam.pl Wed Mar 28 20:29:08 2007 From: Lam at Lam.pl (Leszek Matok) Date: Wed, 28 Mar 2007 22:29:08 +0200 Subject: fc6 gaim update is BROKEN! In-Reply-To: <460ACF1C.7070401@gmail.com> References: <460ACF1C.7070401@gmail.com> Message-ID: <1175113748.3790.1.camel@pensja.lam.pl> Dnia 28-03-2007, ?ro o godzinie 22:25 +0200, dragoran napisa?(a): > FC6 got a gaim update today which was not in updates testing before. > Its completly broken... SOA#1, but I only use Jabber. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From hughsient at gmail.com Wed Mar 28 20:30:18 2007 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 28 Mar 2007 21:30:18 +0100 Subject: Wireless question in F7 In-Reply-To: <20070328025703.GA16607@redhat.com> References: <1175036116.9405.1.camel@sonlaptop> <20070328025703.GA16607@redhat.com> Message-ID: <1175113818.12486.6.camel@localhost.localdomain> On Tue, 2007-03-27 at 22:57 -0400, Dave Jones wrote: > mac80211 will be included alongside the existing upstream ieee80211 > stuff (which isn't really a 'stack', more a library). Is there a way to turn this off via grub for the anaconda install? I get a NULL dereference in the iwlwifi driver (that gets autoloaded as I have internal ipw3945 wireless hardware) which deadlocks my system. Oops attached for reference, although it's already in bugzilla. Richard. -------------- next part -------------- Mar 28 17:47:05 localhost kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000008 Mar 28 17:47:05 localhost kernel: printing eip: Mar 28 17:47:05 localhost kernel: c043512e Mar 28 17:47:05 localhost kernel: *pde = 5cc60067 Mar 28 17:47:05 localhost kernel: Oops: 0000 [#1] Mar 28 17:47:05 localhost kernel: SMP Mar 28 17:47:05 localhost kernel: last sysfs file: /block/sda/sda6/stat Mar 28 17:47:05 localhost kernel: Modules linked in: cpufreq_ondemand cpufreq_powersave cpufreq_conservative rfcomm l2cap xt_tcpudp ip6t_REJECT ip6table_filter ip6_tables x_tables dm_mirror dm_multipath dm_mod video sbs i2c_ec button dock battery asus_acpi ac ipv6 parport_pc lp parport arc4 ecb blkcipher 8139cp serio_raw rtc_cmos zd1211rw_mac80211 i2c_i801 rtc_core hci_usb rtc_lib 8139too fw_ohci sdhci mmc_core bluetooth i2c_core mii fw_core pcspkr snd_hda_intel snd_hda_codec snd_seq_dummy snd_seq_oss iwlwifi snd_seq_midi_event mac80211 snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm iTCO_wdt snd_timer iTCO_vendor_support cfg80211 snd soundcore snd_page_alloc sr_mod cdrom sg joydev ata_piix ata_generic libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd Mar 28 17:47:05 localhost kernel: CPU: 0 Mar 28 17:47:05 localhost kernel: EIP: 0060:[] Not tainted VLI Mar 28 17:47:05 localhost kernel: EFLAGS: 00010246 (2.6.20-1.3023.fc7 #1) Mar 28 17:47:05 localhost kernel: EIP is at queue_work+0x24/0x4d Mar 28 17:47:05 localhost kernel: eax: 00000008 ebx: 00000000 ecx: 00000000 edx: c2503078 Mar 28 17:47:05 localhost kernel: esi: 00000000 edi: c25002e0 ebp: c2498cfc esp: c2498cf4 Mar 28 17:47:05 localhost NetworkManager: Activation (wlan1/wireless) Stage 2 of 5 (Device Configure) successful. Connected to access point 'x641'. Mar 28 17:47:05 localhost kernel: ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068 Mar 28 17:47:05 localhost NetworkManager: Activation (wlan1) Stage 3 of 5 (IP Configure Start) scheduled. Mar 28 17:47:05 localhost kernel: Process events/0 (pid: 8, ti=c2498000 task=c2494030 task.ti=c2498000) Mar 28 17:47:05 localhost NetworkManager: Activation (wlan1) Stage 3 of 5 (IP Configure Start) started... Mar 28 17:47:05 localhost kernel: Stack: c25011e0 f7f6a13c c2498d1c f8a36d5b f561b654 c2498d1c f8a0d0f2 f75791f8 Mar 28 17:47:05 localhost kernel: f7f6a13c c25002e0 c2498e1c f8a0f85c f7f6a13c f70ab000 f8a17e5e 00000000 Mar 28 17:47:05 localhost kernel: 00000011 00000095 00000019 000000a7 0000004c 00000421 00000000 00000001 Mar 28 17:47:05 localhost kernel: Call Trace: Mar 28 17:47:05 localhost kernel: [] show_trace_log_lvl+0x1a/0x2f Mar 28 17:47:05 localhost kernel: [] show_stack_log_lvl+0x9b/0xa3 Mar 28 17:47:05 localhost kernel: [] show_registers+0x1b8/0x289 Mar 28 17:47:05 localhost kernel: [] die+0x12d/0x242 Mar 28 17:47:05 localhost kernel: [] do_page_fault+0x3ee/0x4ba Mar 28 17:47:05 localhost kernel: [] error_code+0x7c/0x84 Mar 28 17:47:05 localhost kernel: [] ipw_rate_scale_rate_init+0xda/0xe2 [iwlwifi] Mar 28 17:47:05 localhost kernel: [] ieee80211_rx_mgmt_assoc_resp+0x571/0x5cb [mac80211] Mar 28 17:47:05 localhost kernel: [] ieee80211_sta_work+0x99e/0x1482 [mac80211] Mar 28 17:47:05 localhost kernel: [] run_workqueue+0x89/0x14e Mar 28 17:47:05 localhost kernel: [] worker_thread+0xf8/0x124 Mar 28 17:47:05 localhost kernel: [] kthread+0xb3/0xdc Mar 28 17:47:05 localhost kernel: [] kernel_thread_helper+0x7/0x10 Mar 28 17:47:05 localhost kernel: ======================= Mar 28 17:47:05 localhost kernel: Code: 72 ff ff ff 5b 5d c3 55 89 c1 89 e5 56 53 64 8b 35 04 00 00 00 f0 0f ba 2a 00 19 c0 31 db 85 c0 75 2c 8b 1d a8 06 7f c0 8d 41 08 <39> 41 08 8d 42 04 0f 45 de 39 42 04 74 04 0f 0b eb fe 8b 01 f7 Mar 28 17:47:05 localhost kernel: EIP: [] queue_work+0x24/0x4d SS:ESP 0068:c2498cf4 Mar 28 17:47:05 localhost kernel: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready From wtogami at redhat.com Wed Mar 28 20:36:52 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 28 Mar 2007 16:36:52 -0400 Subject: fc6 gaim update is BROKEN! In-Reply-To: <460ACF1C.7070401@gmail.com> References: <460ACF1C.7070401@gmail.com> Message-ID: <460AD1E4.4060405@redhat.com> dragoran wrote: > FC6 got a gaim update today which was not in updates testing before. > Its completly broken... changing status without typing a message -> > segfault > When logging into icq it shows a message "Could not add buddy 1" > Downgrade is also not possible because it somehow changed the contents > of .gaim I'm sorry that this isn't working out for you. It worked very well for me and a few other testers. Nobody complained about these problems about this version sitting in rawhide for quite a while now. I do see the ICQ problem (which seems harmless), but not the segfault. Could you please file Bugzilla reports for problems that you experience? http://gaim.sourceforge.net/gdb.php Please use this guide to get a useful backtrace. > Why has this package made it to updates without any previous testing? This is valid criticism. In this case I thought it was unnecessary. Whatever happened in the past, we cannot undo it, so please focus on filing constructive bugs instead of only criticizing. I fully intend on continuing to upgrade gaim in FC6 toward the gaim 2.0.0 final. If you don't complain about problems, then they might reach 2.0.0 final. If it makes you happier, I'll make more frequent use of updates-testing in the future. Warren Togami wtogami at redhat.com From mschwendt.tmp0701.nospam at arcor.de Wed Mar 28 17:59:28 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Wed, 28 Mar 2007 19:59:28 +0200 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: <6514.65.192.24.190.1175103969.squirrel@mail.jcomserv.net> References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <46097882.9030802@redhat.com> <64171.65.192.24.190.1175026507.squirrel@mail.jcomserv.net> <20070328174018.GF2483@tomservo.rh.rit.edu> <6514.65.192.24.190.1175103969.squirrel@mail.jcomserv.net> Message-ID: <20070328195928.f097f071.mschwendt.tmp0701.nospam@arcor.de> On Wed, 28 Mar 2007 12:46:09 -0500 (CDT), Jon Ciesla wrote: > If I add it to %files, when I build, it fails, as /usr/bin/ettercap does > not exist. Is there a workaround? > > > After installing ettercap, nothing owns /usr/bin/ettercap, due to it > > getting created by alternatives in the %post. "touch" it in %install, include it in %files marked as %ghost, %files ... %ghost %{_bindir}/ettercap then display the files in your test-build (rpm --query --list ...). From markg85 at gmail.com Wed Mar 28 20:51:07 2007 From: markg85 at gmail.com (Mark) Date: Wed, 28 Mar 2007 22:51:07 +0200 Subject: Is it a bug or intentionally done? In-Reply-To: <1175112082.4641.70.camel@localhost.localdomain> References: <6e24a8e80703281255w1cbcedb3ve4edc0b9fa95b600@mail.gmail.com> <1175112082.4641.70.camel@localhost.localdomain> Message-ID: <6e24a8e80703281351i4db5f618g5e87d3f4b02ff891@mail.gmail.com> thanx for clearing that up ^_^ 2007/3/28, Matthias Clasen : > > On Wed, 2007-03-28 at 21:55 +0200, Mark wrote: > > Hey, > > > > i was just trying to make a screenshot of my gnome menu, but somehow > > the screenhot window simply won`t appear when i press the "Print > > Screen" button on my keyboard. it`s appearing just fine on other > > places unless i clicked a menu (so that the menu is expanded) > > > > bug? or normal behavior? > > > > Normal. Menus grab the keyboard when they are shown. You can use other > tools which allow you to grab a screenshot after a timout, e.g. Gimp. > > -- > 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 pertusus at free.fr Wed Mar 28 20:59:01 2007 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 28 Mar 2007 22:59:01 +0200 Subject: hplip: hp-toolbox advertising? In-Reply-To: <460A9AAE.4070507@fedoraproject.org> References: <1175009409.6100.4.camel@willson> <20070327171707.GE2888@free.fr> <1175051938.32396.3.camel@willson> <20070328081040.GA2906@free.fr> <1175086999.32396.31.camel@willson> <20070328145304.GB3569@free.fr> <460A8533.1030202@fedoraproject.org> <20070328162210.GB5223@free.fr> <460A9AAE.4070507@fedoraproject.org> Message-ID: <20070328205901.GA3031@free.fr> On Wed, Mar 28, 2007 at 10:11:18PM +0530, Rahul Sundaram wrote: > > I thought you claimed this is one of the reviews and were corrected by > someone else. The argument was not as clear as your statement. > Make sure you clarify any legal issues in > fedora-maintainers list before enforcing it on reviewers. At any rate it That's not really possible, there are too many issues arising in each review. > looks we need a FAQ on common legal issues. If you have a list I can > write it up and run it via Red Hat Legal. I already asked and Spot responded to most of my issues (especially the files with author and no license). He agreed more or less with the practices I proposed, I'll try to find his response, maybe we could put that, together with the srpm agregation explanation on the wiki. -- Pat From stickster at gmail.com Wed Mar 28 21:10:26 2007 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 28 Mar 2007 17:10:26 -0400 Subject: Extras i386 rawhide rebuild in mock status 2007-03-28 In-Reply-To: <20070328084610.A8943@humbolt.us.dell.com> References: <20070328084610.A8943@humbolt.us.dell.com> Message-ID: <1175116226.7466.35.camel@localhost.localdomain> On Wed, 2007-03-28 at 08:46 -0500, Matt Domsch wrote: > Extras Rawhide-in-Mock Build Results for i386 Wed Mar 28 04:36:43 CDT 2007 > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ [...snip...] > xmldiff-0.6.7-12.fc6 stickster at gmail.com There is an update pending for 0.6.8-1.fc7, but it won't build. To reiterate a post I made to fedora-maintainers, it's only failing on the Xen builders. When I build it on a native i386 or x86_64 host using mock, all the regression tests pass successfully. http://www.redhat.com/archives/fedora-maintainers/2007-February/msg00754.html Earlier I posted similarly on fedora-extras-list, and David Woodhouse was kind enough to lend me ppc build space because originally the problem only manifested for ppc, but as it turns out, that problem looks to have resolved itself. The last build log I looked out on buildsys.fp.o showed that ppc completed successfully, but the other failures nixed the package. I was told by someone (sorry, can't recall who right now) that this problem had also popped up with one or more Perl packages at some point in the past. I've emailed upstream but did not get any assistance from the developer. If I can't get this fixed soon-ish, this package will disappear from FC7 (one way or another, I suppose). -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Project: http://fedoraproject.org/wiki/PaulWFrields irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- 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 drago01 at gmail.com Wed Mar 28 21:34:12 2007 From: drago01 at gmail.com (dragoran) Date: Wed, 28 Mar 2007 23:34:12 +0200 Subject: fc6 gaim update is BROKEN! In-Reply-To: <460AD1E4.4060405@redhat.com> References: <460ACF1C.7070401@gmail.com> <460AD1E4.4060405@redhat.com> Message-ID: <460ADF54.3050206@gmail.com> Warren Togami wrote: > dragoran wrote: >> FC6 got a gaim update today which was not in updates testing before. >> Its completly broken... changing status without typing a message -> >> segfault >> When logging into icq it shows a message "Could not add buddy 1" >> Downgrade is also not possible because it somehow changed the >> contents of .gaim > > I'm sorry that this isn't working out for you. It worked very well > for me and a few other testers. Nobody complained about these > problems about this version sitting in rawhide for quite a while now. > > I do see the ICQ problem (which seems harmless), but not the segfault. > Could you please file Bugzilla reports for problems that you experience? > I did https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234399 > http://gaim.sourceforge.net/gdb.php > Please use this guide to get a useful backtrace. > ok thx for this link, I tryed to create a backtrace but it hangs gdb ... will try again tomorrow and if I can find the problem I will attach a patch to the bugzilla report, else the backtrace >> Why has this package made it to updates without any previous testing? > > This is valid criticism. In this case I thought it was unnecessary. > > Whatever happened in the past, we cannot undo it, so please focus on > filing constructive bugs instead of only criticizing. > sorry if I sounded like this but I was about to get crazy because of the strange things that happend (no text in the ui, unknown account etc.) when I downgraded, but now the downgrade worked (replacing prpl-icq with prpl-oscar in accounts.xml did it) ;) > I fully intend on continuing to upgrade gaim in FC6 toward the gaim > 2.0.0 final. this is a good thing :) If not I would complain about this ;) > If you don't complain about problems, then they might reach 2.0.0 > final.If it makes you happier, I'll make more frequent use of > updates-testing in the future. > yes this is what updates testing is for, please don't throw untested packages at the users. > Warren Togami > wtogami at redhat.com > From bjohnson-dated-1172832473.ba5e95 at symetrix.com Wed Mar 28 21:39:16 2007 From: bjohnson-dated-1172832473.ba5e95 at symetrix.com (Bernard Johnson) Date: Wed, 28 Mar 2007 15:39:16 -0600 Subject: Extras i386 rawhide rebuild in mock status 2007-03-28 In-Reply-To: <1175116226.7466.35.camel@localhost.localdomain> References: <20070328084610.A8943@humbolt.us.dell.com> <1175116226.7466.35.camel@localhost.localdomain> Message-ID: Paul W. Frields wrote: > I was told by someone (sorry, can't recall who right now) that this > problem had also popped up with one or more Perl packages at some point > in the past. I've emailed upstream but did not get any assistance from > the developer. If I can't get this fixed soon-ish, this package will > disappear from FC7 (one way or another, I suppose). When I ran the RHEL-b2 regression tests for mysql in a [not fedoraproject.org] Xen environment, multiple tests would fail as well. Didn't have time to study it, but clearly there is something ugly about Xen. From lists at dresco.co.uk Wed Mar 28 21:54:21 2007 From: lists at dresco.co.uk (Jon Escombe) Date: Wed, 28 Mar 2007 21:54:21 +0000 (UTC) Subject: fc6 gaim update is BROKEN! References: <460ACF1C.7070401@gmail.com> <460AD1E4.4060405@redhat.com> Message-ID: Warren Togami redhat.com> writes: > I'm sorry that this isn't working out for you. It worked very well for > me and a few other testers. Nobody complained about these problems > about this version sitting in rawhide for quite a while now. Just one small issue to add, this update segfaulted for me due to a clash with the beta5 version of gaim-meanwhile that's still in extras. Possibly ought to be a dependancy somewhere that required an update to the plugins too? Appreciate that this would be hard to spot unless you actually use the meanwhile plugin, so not really complaining, just fyi (& hoping for an updated plugin at some point ;) Thanks, Jon. From kmaraas at broadpark.no Wed Mar 28 21:01:44 2007 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Wed, 28 Mar 2007 23:01:44 +0200 Subject: Is it a bug or intentionally done? In-Reply-To: <1175112082.4641.70.camel@localhost.localdomain> References: <6e24a8e80703281255w1cbcedb3ve4edc0b9fa95b600@mail.gmail.com> <1175112082.4641.70.camel@localhost.localdomain> Message-ID: <1175115704.6363.1.camel@localhost.localdomain> ons, 28.03.2007 kl. 16.01 -0400, skrev Matthias Clasen: > On Wed, 2007-03-28 at 21:55 +0200, Mark wrote: > > Hey, > > > > i was just trying to make a screenshot of my gnome menu, but somehow > > the screenhot window simply won`t appear when i press the "Print > > Screen" button on my keyboard. it`s appearing just fine on other > > places unless i clicked a menu (so that the menu is expanded) > > > > bug? or normal behavior? > > > > Normal. Menus grab the keyboard when they are shown. You can use other > tools which allow you to grab a screenshot after a timout, e.g. Gimp. > Or run gnome-screenshot with -d to run it with a delay. Cheers Kjartan From tchung at fedoraproject.org Wed Mar 28 22:14:31 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Wed, 28 Mar 2007 15:14:31 -0700 Subject: Fedora News Project is Looking for Writers Message-ID: <369bce3b0703281514s2547ee7dmc10776d9efc8baad@mail.gmail.com> Currently Fedora News Project[1] is looking for two or more writers for up-coming-issue of Fedora Weekly News. Selected writers are expected to pick out the several major topics discussed in that week from following mailing lists and summarized them in a few paragraph.: * Development Section: fedora-devel-list, fedora-extras-list and fedora-maintainers-list * Documentation Section: fedora-docs-list * Events and Meetings: fedora-ambassadors-list and fedora-marketing-list These paragraphs will be edited by our editors and eventually published in our next issue of Fedora Weekly News. If you're interested in this project, please contact me as soon as possible. Regards, [1] http://fedoraproject.org/wiki/NewsProject -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From jkeating at redhat.com Wed Mar 28 22:17:16 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Mar 2007 18:17:16 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: <460ACE08.9010205@hhs.nl> References: <460ACE08.9010205@hhs.nl> Message-ID: <200703281817.17144.jkeating@redhat.com> On Wednesday 28 March 2007 16:20:24 Hans de Goede wrote: > /me too, > > Can we please stop the HP bashing, they are doing a great job in providing > support for their hardware, if their tools need better integration into the > rest of Linux, then work with them, instead of bashing them / their > software. I'd wager their tools need to be better period. I just unpacked a new HP photosmart C3180 multipurpose thingy. I wanted to print out my flight eticket. After all this discussion I figured I'd give it a try. After powering on and attaching the printer via usb, I ask yum to install hplip. After downloading a 10+ megs of software, I had hplip on my system. I tried to -f2 and typed in hp-toolbox as that would be what the menu called. Nothing. Tried again, nothing. The hell? Try it from a console, HO! A daemon isn't running and so the software just yells about not being able to connect to "HPLIP I/O (hpiod)" whatever the hell that is. Helpful. Being a bit cluefull about these things, I guess it wants the hplip service to be running. So start the daemon, try again, and I get a big screen about no installed HP devices found. Ok, there is a setup device button, click it, nothing detected. Find Manually asks me for a cryptic USB ID which it gives me no clue as how to find it. Helpful. So I give up on this, close it, stop the service. I instead try System -> Administration -> Printing New printer Fill in details about name, description, location Hit next and look at that, it automatically detected I had a USB printer plugged in and even had the right name. Forward again, pick the closest HP driver from the list (HP Photosmart C3100) finalize and boom I can print a test job, and furthermore print my etickets. Yeah, this is great software allright. *sigh* -- 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 Wed Mar 28 22:19:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Mar 2007 18:19:12 -0400 Subject: rawhide report: 20070328 changes In-Reply-To: <200703281447.l2SElWg5005693@hs20-bc2-6.build.redhat.com> References: <200703281447.l2SElWg5005693@hs20-bc2-6.build.redhat.com> Message-ID: <200703281819.12628.jkeating@redhat.com> On Wednesday 28 March 2007 10:47:32 buildsys at redhat.com wrote: > Updated Packages: > > (none) > Broken deps for s390 argh. This is a lie. MANY packages were updated. I'll see if I can get a real report generated. -- 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 wtogami at redhat.com Wed Mar 28 22:19:22 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 28 Mar 2007 18:19:22 -0400 Subject: fc6 gaim update is BROKEN! In-Reply-To: References: <460ACF1C.7070401@gmail.com> <460AD1E4.4060405@redhat.com> Message-ID: <460AE9EA.7090001@redhat.com> Jon Escombe wrote: > Warren Togami redhat.com> writes: > >> I'm sorry that this isn't working out for you. It worked very well for >> me and a few other testers. Nobody complained about these problems >> about this version sitting in rawhide for quite a while now. > > Just one small issue to add, this update segfaulted for me due to a clash with > the beta5 version of gaim-meanwhile that's still in extras. Possibly ought to be > a dependancy somewhere that required an update to the plugins too? > > Appreciate that this would be hard to spot unless you actually use the meanwhile > plugin, so not really complaining, just fyi (& hoping for an updated plugin at > some point ;) > > Thanks, > Jon. > > gaim-meanwhile as a separate package will disappear when the distro merges, because then libmeanwhile will be available for gaim to build against. Warren From davej at redhat.com Wed Mar 28 22:20:04 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 28 Mar 2007 18:20:04 -0400 Subject: Wireless question in F7 In-Reply-To: <1175113818.12486.6.camel@localhost.localdomain> References: <1175036116.9405.1.camel@sonlaptop> <20070328025703.GA16607@redhat.com> <1175113818.12486.6.camel@localhost.localdomain> Message-ID: <20070328222004.GB14737@redhat.com> On Wed, Mar 28, 2007 at 09:30:18PM +0100, Richard Hughes wrote: > On Tue, 2007-03-27 at 22:57 -0400, Dave Jones wrote: > > mac80211 will be included alongside the existing upstream ieee80211 > > stuff (which isn't really a 'stack', more a library). > > Is there a way to turn this off via grub for the anaconda install? I get > a NULL dereference in the iwlwifi driver (that gets autoloaded as I have > internal ipw3945 wireless hardware) which deadlocks my system. booting with 'noprobe' and then selecting your /other/ hardware by hand might work. > Oops attached for reference, although it's already in bugzilla. I think this one got fixed a day or so ago. It looks familiar. The latest build seems to have issues associating with APs though. Dave -- http://www.codemonkey.org.uk From wtogami at redhat.com Wed Mar 28 22:33:57 2007 From: wtogami at redhat.com (Warren Togami) Date: Wed, 28 Mar 2007 18:33:57 -0400 Subject: iwlwifi in rawhide different? Message-ID: <460AED55.2090102@redhat.com> http://people.redhat.com/linville/kernels/fc7/ The iwlwifi driver appears to be in the standard rawhide kernel. Is this the same or older than the driver in Linville's test kernels? Warren Togami wtogami at redhat.com From dominik at greysector.net Wed Mar 28 22:43:07 2007 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 29 Mar 2007 00:43:07 +0200 Subject: iwlwifi in rawhide different? In-Reply-To: <460AED55.2090102@redhat.com> References: <460AED55.2090102@redhat.com> Message-ID: <20070328224307.GC20227@ryvius.pekin.waw.pl> On Thursday, 29 March 2007 at 00:33, Warren Togami wrote: > http://people.redhat.com/linville/kernels/fc7/ > The iwlwifi driver appears to be in the standard rawhide kernel. Is > this the same or older than the driver in Linville's test kernels? While we're on the topic, will this be released as an update for FC6? 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 jwboyer at jdub.homelinux.org Wed Mar 28 22:55:17 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 28 Mar 2007 17:55:17 -0500 Subject: fc6 gaim update is BROKEN! In-Reply-To: <460AE9EA.7090001@redhat.com> References: <460ACF1C.7070401@gmail.com> <460AD1E4.4060405@redhat.com> <460AE9EA.7090001@redhat.com> Message-ID: <1175122518.32658.11.camel@vader.jdub.homelinux.org> On Wed, 2007-03-28 at 18:19 -0400, Warren Togami wrote: > Jon Escombe wrote: > > Warren Togami redhat.com> writes: > > > >> I'm sorry that this isn't working out for you. It worked very well for > >> me and a few other testers. Nobody complained about these problems > >> about this version sitting in rawhide for quite a while now. > > > > Just one small issue to add, this update segfaulted for me due to a clash with > > the beta5 version of gaim-meanwhile that's still in extras. Possibly ought to be > > a dependancy somewhere that required an update to the plugins too? > > > > Appreciate that this would be hard to spot unless you actually use the meanwhile > > plugin, so not really complaining, just fyi (& hoping for an updated plugin at > > some point ;) > > > > Thanks, > > Jon. > > > > > > gaim-meanwhile as a separate package will disappear when the distro > merges, because then libmeanwhile will be available for gaim to build > against. Yes, thank $deity. Jon, the gaim-meanwhile segfault is actually my fault. I noticed it in rawhide where it's fixed, but didn't see the latest FC-6 gaim update. I'll try and get this fixed up ASAP. josh From hughsient at gmail.com Wed Mar 28 23:00:04 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 29 Mar 2007 00:00:04 +0100 Subject: Wireless question in F7 In-Reply-To: <20070328222004.GB14737@redhat.com> References: <1175036116.9405.1.camel@sonlaptop> <20070328025703.GA16607@redhat.com> <1175113818.12486.6.camel@localhost.localdomain> <20070328222004.GB14737@redhat.com> Message-ID: <1175122804.2909.6.camel@localhost.localdomain> On Wed, 2007-03-28 at 18:20 -0400, Dave Jones wrote: > On Wed, Mar 28, 2007 at 09:30:18PM +0100, Richard Hughes wrote: > > On Tue, 2007-03-27 at 22:57 -0400, Dave Jones wrote: > > > mac80211 will be included alongside the existing upstream ieee80211 > > > stuff (which isn't really a 'stack', more a library). > > > > Is there a way to turn this off via grub for the anaconda install? I get > > a NULL dereference in the iwlwifi driver (that gets autoloaded as I have > > internal ipw3945 wireless hardware) which deadlocks my system. > > booting with 'noprobe' and then selecting your /other/ hardware > by hand might work. Ick, but nice to know, thanks. > > Oops attached for reference, although it's already in bugzilla. > > I think this one got fixed a day or so ago. It looks familiar. > The latest build seems to have issues associating with APs though. Yup, we are a little better with todays rawhide. I can now boot with my ipw3945 internal wireless network card detected, without an oops. It won't associate tho, as you mentioned. I then inserted my zd1211rw_mac80211 usb2 network dongle (which has been working with 2960) and got the attached oops (again with iwlwifi oddly enough...) Hard hang, *BOOM*. Maybe something to do with multiple drivers using mac80211? Richard. -------------- next part -------------- Mar 28 23:49:13 localhost kernel: iwlwifi: TODO: Look into long/short preamble change handling. Mar 28 23:49:15 localhost last message repeated 9 times Mar 28 23:49:15 localhost kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000008 Mar 28 23:49:15 localhost kernel: printing eip: Mar 28 23:49:15 localhost kernel: c043512e Mar 28 23:49:15 localhost kernel: *pde = 46a2e067 Mar 28 23:49:15 localhost kernel: Oops: 0000 [#1] Mar 28 23:49:15 localhost kernel: SMP Mar 28 23:49:15 localhost kernel: last sysfs file: /block/sda/sda6/stat Mar 28 23:49:15 localhost kernel: Modules linked in: zd1211rw_mac80211 cpufreq_ondemand cpufreq_powersave cpufreq_conservative rfcomm l2cap xt_tcpudp ip6t_REJECT ip6table_filter ip6_tables x_tables dm_mirror dm_multipath dm_mod video sbs i2c_ec button dock battery asus_acpi ac ipv6 parport_pc lp parport arc4 8139cp ecb blkcipher rtc_cmos serio_raw rtc_core fw_ohci rtc_lib fw_core 8139too mii sdhci mmc_core snd_hda_intel snd_hda_codec snd_seq_dummy snd_seq_oss snd_seq_midi_event i2c_i801 snd_seq iTCO_wdt snd_seq_device iwlwifi pcspkr iTCO_vendor_support i2c_core hci_usb mac80211 snd_pcm_oss bluetooth snd_mixer_oss cfg80211 snd_pcm snd_timer snd soundcore snd_page_alloc sr_mod cdrom joydev sg ata_piix ata_generic libata sd_mod scsi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd Mar 28 23:49:15 localhost kernel: CPU: 0 Mar 28 23:49:15 localhost kernel: EIP: 0060:[] Not tainted VLI Mar 28 23:49:15 localhost kernel: EFLAGS: 00010246 (2.6.20-1.3024.fc7 #1) Mar 28 23:49:15 localhost kernel: EIP is at queue_work+0x24/0x4d Mar 28 23:49:15 localhost NetworkManager: Activation (wlan1/wireless) Stage 2 of 5 (Device Configure) successful. Connected to access point 'x641'. Mar 28 23:49:15 localhost kernel: eax: 00000008 ebx: 00000000 ecx: 00000000 edx: f388b078 Mar 28 23:49:15 localhost NetworkManager: Activation (wlan1) Stage 3 of 5 (IP Configure Start) scheduled. Mar 28 23:49:15 localhost kernel: esi: 00000000 edi: f38882e0 ebp: c2498cfc esp: c2498cf4 Mar 28 23:49:15 localhost NetworkManager: Activation (wlan1) Stage 3 of 5 (IP Configure Start) started... Mar 28 23:49:15 localhost kernel: ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068 Mar 28 23:49:15 localhost kernel: Process events/0 (pid: 8, ti=c2498000 task=c2494030 task.ti=c2498000) Mar 28 23:49:15 localhost kernel: Stack: f38891e0 f392c760 c2498d1c f8a38d5b f4ef6330 c2498d1c f8a0f0f2 f75b11f8 Mar 28 23:49:15 localhost kernel: f392c760 f38882e0 c2498e1c f8a1185c f392c760 f3862000 f8a19e5e 00000000 Mar 28 23:49:15 localhost kernel: 00000011 00000095 00000019 000000a7 0000004c 00000421 00000000 00000001 Mar 28 23:49:15 localhost kernel: Call Trace: Mar 28 23:49:15 localhost kernel: [] show_trace_log_lvl+0x1a/0x2f Mar 28 23:49:15 localhost kernel: [] show_stack_log_lvl+0x9b/0xa3 Mar 28 23:49:15 localhost kernel: [] show_registers+0x1b8/0x289 Mar 28 23:49:15 localhost kernel: [] die+0x12d/0x242 Mar 28 23:49:15 localhost kernel: [] do_page_fault+0x3ee/0x4ba Mar 28 23:49:15 localhost kernel: [] error_code+0x7c/0x84 Mar 28 23:49:15 localhost kernel: [] ipw_rate_scale_rate_init+0xda/0xe2 [iwlwifi] Mar 28 23:49:15 localhost kernel: [] ieee80211_rx_mgmt_assoc_resp+0x571/0x5cb [mac80211] Mar 28 23:49:15 localhost kernel: [] ieee80211_sta_work+0x99e/0x1482 [mac80211] Mar 28 23:49:15 localhost kernel: [] run_workqueue+0x89/0x14e Mar 28 23:49:15 localhost kernel: [] worker_thread+0xf8/0x124 Mar 28 23:49:15 localhost kernel: [] kthread+0xb3/0xdc Mar 28 23:49:15 localhost kernel: [] kernel_thread_helper+0x7/0x10 Mar 28 23:49:15 localhost kernel: ======================= Mar 28 23:49:15 localhost kernel: Code: 72 ff ff ff 5b 5d c3 55 89 c1 89 e5 56 53 64 8b 35 04 00 00 00 f0 0f ba 2a 00 19 c0 31 db 85 c0 75 2c 8b 1d a8 06 7f c0 8d 41 08 <39> 41 08 8d 42 04 0f 45 de 39 42 04 74 04 0f 0b eb fe 8b 01 f7 Mar 28 23:49:15 localhost kernel: EIP: [] queue_work+0x24/0x4d SS:ESP 0068:c2498cf4 From drkludge at cox.net Wed Mar 28 23:08:36 2007 From: drkludge at cox.net (Greg Morgan) Date: Wed, 28 Mar 2007 16:08:36 -0700 Subject: Is it a bug or intentionally done? In-Reply-To: <1175112082.4641.70.camel@localhost.localdomain> References: <6e24a8e80703281255w1cbcedb3ve4edc0b9fa95b600@mail.gmail.com> <1175112082.4641.70.camel@localhost.localdomain> Message-ID: <460AF574.1000102@cox.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthias Clasen wrote: > On Wed, 2007-03-28 at 21:55 +0200, Mark wrote: >> Hey, >> >> i was just trying to make a screenshot of my gnome menu, but somehow >> the screenhot window simply won`t appear when i press the "Print >> Screen" button on my keyboard. it`s appearing just fine on other >> places unless i clicked a menu (so that the menu is expanded) >> >> bug? or normal behavior? >> > > Normal. Menus grab the keyboard when they are shown. You can use other > tools which allow you to grab a screenshot after a timout, e.g. Gimp. > 1.) Or go to Applications > Accessories > Take Screenshot > right click and use either add to panel or add to desktop. The panel may make screen shots easier for menus. 2.) Right click on the new icon> select properties. In the command box after gnome-screenshot add --delay=seconds i.e. gnome-screenshot --delay=3 The idea is to find a long enough delay so that you can click your new screenshot icon and then navigate the menus for the capture. The reason for the delay is noted by Matthias Clasen above. Regards, Greg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGCvV0xyxe5L6mr7IRAu44AJ9vd5bn3yCkZdYkYTCsoZcjCIrXvQCbBYXq MNRZzIJahjcUYS3+wcQYo64= =aIIS -----END PGP SIGNATURE----- From buildsys at redhat.com Wed Mar 28 23:18:24 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Wed, 28 Mar 2007 19:18:24 -0400 Subject: rawhide report: 20070328 changes Message-ID: <200703282318.l2SNIOQf023334@hs20-bc2-6.build.redhat.com> New package libhangul Hangul input library Updated Packages: GConf2-2.18.0.1-2.fc7 --------------------- * Sun Mar 25 2007 Matthias Clasen - 2.18.0.1-2 - Fix a directory ownership issue. (#233756) NetworkManager-1:0.6.5-0.5.svn2474.fc7 -------------------------------------- * Sun Mar 25 2007 Matthias Clasen 1:0.6.5-0.5.svn2474 - Fix a directory ownership issue. (#233763) ORBit2-2.14.7-2.fc7 ------------------- * Sun Mar 25 2007 Matthias Clasen - 2.14.7-2 - Fix a directory ownership issue (#233755) acl-2.2.39-3.1.fc7 ------------------ * Wed Mar 21 2007 Thomas Woerner 2.2.39-3.1 - new improved walk patch with fixed getfacl exit code (rhbz#232884) alacarte-0.11.3-3.fc7 --------------------- * Fri Mar 23 2007 Ray Strode - 0.11.3-3 - change url to gnome.org (bug 233237) antlr-0:2.7.7-1jpp.2 -------------------- * Mon Mar 26 2007 Deepak Bhole 2.7.7-1jpp.2 - Added unowned dir to files list apr-1.2.8-5 ----------- * Thu Mar 22 2007 Joe Orton 1.2.8-5 - drop the doxygen documentation (which causes multilib conflicts) * Thu Feb 15 2007 Joe Orton 1.2.8-4 - add BR for python * Thu Feb 15 2007 Joe Orton 1.2.8-3 - update to pick up new libtool, drop specific gcc requirement apr-util-1.2.8-6 ---------------- * Fri Mar 23 2007 Joe Orton 1.2.8-6 - add DBD DSO lifetime fix (r521327) * Thu Mar 22 2007 Joe Orton 1.2.8-5 - drop doxygen documentation (which caused multilib conflicts) aspell-af-50:0.50-7.fc7 ----------------------- * Wed Mar 28 2007 Ivana Varekova - 50:0.50-7 - variable DESTDIR is set in make command * Tue Mar 27 2007 Ivana Varekova - 50:0.50-6 - use configure script to generate makefile aspell-bg-50:0.50-14.fc7 ------------------------ * Wed Mar 28 2007 Ivana Varekova - 50:0.50-14 - variable DESTDIR is set in make command * Tue Mar 27 2007 Ivana Varekova - 50:0.50-13 - use configure script to generate makefile aspell-br-50:0.50-8.fc7 ----------------------- * Wed Mar 28 2007 Ivana Varekova - 50:0.50-8 - variable DESTDIR is set in make command * Tue Mar 27 2007 Ivana Varekova - 50:0.50-6 - use configure script to generate makefile aspell-ca-50:0.50-6.fc7 ----------------------- * Wed Mar 28 2007 Ivana Varekova - 50:0.50-6 - use configure script to generate makefile at-3.1.10-11.fc7 ---------------- * Tue Mar 27 2007 Marcela Maslanova - 3.1.10-11 - mistake in pam_atd - rhbz#234120 * Mon Mar 05 2007 Marcela Maslanova - 3.1.10-10 - rhbz#224597 * Sat Mar 03 2007 Marcela Maslanova - 3.1.10-9 - review at-spi-1.18.0-2.fc7 ------------------- * Mon Mar 26 2007 Matthias Clasen - 1.18.0-2 - Backport a patch to fix deadlocks in applications automake16-1.6.3-11 ------------------- * Thu Mar 22 2007 Karsten Hopp 1.6.3-11 - more review fixes (#225300) * Thu Mar 22 2007 Florian La Roche 1.6.3-10 - change post/preun code to install info pages awesfx-0.5.0d-4.fc7 ------------------- * Thu Mar 22 2007 Martin Stransky - 0.5.0d-4 - fixed #225359: wrong URL in awesfx package description beagle-0.2.16.2-3.fc7 --------------------- * Tue Mar 27 2007 Matthias Clasen - 0.2.16-2-3 - Add better category to desktop file - Don't autostart the search gui bluez-gnome-0.6-2.fc7 --------------------- * Wed Jan 24 2007 Matthias Clasen 0.6-2 - Add X-GNOME-NetworkSettings to desktop file categories - Use desktop-file-install boost-1.33.1-12.fc7 ------------------- * Mon Mar 26 2007 Benjamin Kosnik 1.33.1-12 - (#233523: libboost_python needs rebuild against python 2.5) Use patch. * Mon Mar 26 2007 Benjamin Kosnik 1.33.1-11 - (#225622: Merge Review: boost) Source to http. BuildRoot to preferred value. PreReq to post/postun -p Clarified BSL as GPL-Compatible, Free Software License. Remove Obsoletes. Add Provides boost-python. Remove mkdir -p $RPM_BUILD_ROOT/usr/share/doc Added periods for decription text. Fix Group field. Remove doc Requires boost. Preserve timestamps on install. Use %defattr(-, root, root, -) Added static package for .a libs. Install static libs with 0644 permissions. Use %doc for doc files. cadaver-0.22.5-2 ---------------- * Fri Mar 23 2007 Joe Orton 0.22.5-2 - update to 0.22.5 - use approved BuildRoot cairo-java-1.0.5-7.fc7 ---------------------- * Tue Mar 27 2007 Stepan Kasal - 1.0.5-7 - BuildRequire java-devel instead of java-1.4.2-gcj-compat-devel. compiz-0.3.6-4.fc7 ------------------ * Tue Mar 27 2007 Kristian H??gsberg 0.3.6-4 - Explicitly disable KDE parts (#234128). * Mon Mar 26 2007 Matthias Clasen 0.3.6-3 - Fix some directory ownership issues (#233825) - Small spec cleanups control-center-1:2.18.0-5.fc7 ----------------------------- * Fri Mar 23 2007 Soren Sandmann - 2.18.0-5 - Remove debug spew from gnome-bg patch * Wed Mar 21 2007 Matthias Clasen - 2.18.0-4 - Try hard to not show the theme installer coreutils-6.9-1.fc7 ------------------- * Mon Mar 26 2007 Tim Waugh 6.9-1 - 6.9. * Fri Mar 09 2007 Tim Waugh - Better install-info scriptlets (bug #225655). * Thu Mar 01 2007 Tim Waugh 6.8-1 - 6.8+, in preparation for 6.9. dbus-1.0.2-1.fc7 ---------------- * Sun Mar 25 2007 Matthias Clasen - 1.0.2-1 - Update to 1.0.2 - Drop obsolete patches - Fix directory ownership issues (#233753) desktop-printing-0.20-6.fc7 --------------------------- * Tue Mar 27 2007 Tim Waugh 0.20-6 - Ship translations for applet desktop file. - Don't ship the eggcups binary. * Wed Mar 21 2007 Tim Waugh 0.20-5 - Provide an autostart desktop file (bug #233261). * Tue Mar 20 2007 Tim Waugh - Removed dependency on system-config-printer's glade file. dhcp-12:3.0.5-26.fc7 -------------------- * Wed Mar 21 2007 David Cantrell - 12:3.0.5-26 - Fix formatting problems in dhclient man page (#233076). * Mon Mar 05 2007 David Cantrell - 12:3.0.5-25 - Man pages need 0644 permissions (#222572) * Thu Mar 01 2007 David Cantrell - 12:3.0.5-24 - Include contrib/ subdirectory in /usr/share/doc (#230476) - Added back Requires for perl since dhcpd-conf-to-ldap needs it (#225691) - Put copies of dhcp-options and dhcp-eval man pages in the dhcp and dhclient packages rather than having the elaborate symlink collection - Explicitly name man pages in the %files listings - Use the %{_sysconfdir} and %{_initrddir} macros (#225691) - Use macros for commands in %build and %install - Split README.ldap, draft-ietf-dhc-ldap-schema-01.txt, and dhcpd-conf-to-ldap.pl out of the LDAP patch - Split linux.dbus-example script out of the extended new option info patch - Remove unnecessary changes from the Makefile patch dhcpv6-0.10-41.fc7 ------------------ * Mon Mar 26 2007 David Cantrell - 0.10-41 - Pass correct sockaddr size for salen parameter to getnameinfo() (#233900) - Spec file cleanups per Fedora Packaging Guidelines diffstat-1.43-5.fc7 ------------------- * Fri Mar 23 2007 Tim Waugh 1.43-5 - Fixed description (bug #225695). dovecot-1.0-8.rc28.fc7 ---------------------- * Fri Mar 23 2007 Tomas Janousek - 1.0-8.rc28 - update to latest upstream echo-icon-theme-0.2-2.20070326wiki.fc7 -------------------------------------- * Tue Mar 27 2007 Matthias Clasen - 0.2-2.20070326wiki - Fix n-v-r ordering problem * Mon Mar 26 2007 Matthias Clasen - 0.2-2.20070326wiki - New snapshot * Fri Feb 23 2007 Matthias Clasen - 0.2-2.20070223wiki - New snapshot - Fix some scriptlet issues - Own the icon cache eclipse-1:3.2.2-7.fc7 --------------------- * Tue Mar 20 2007 Ben Konrath 3.2.2-7 - Remove search and processing for mac encoded files. - Remove BR dos2unix. * Mon Mar 19 2007 Thomas Fitzsimmons 3.2.2-6 - Remove gjdoc build requirement. elinks-0.11.2-1.fc7 ------------------- * Mon Mar 26 2007 Karel Zak 0.11.2-1 - update to new upstream version - cleanup spec file * Wed Oct 11 2006 Karel Zak 0.11.1-5 - fix #210103 - elinks crashes when given bad HTTP_PROXY * Wed Jul 12 2006 Jesse Keating - 0.11.1-4.1 - rebuild evolution-2.10.0-4.fc7 ---------------------- * Mon Mar 26 2007 Matthew Barnes - 2.10.0-4.fc7 - Run gtk-update-icon-cache in %post and %postun (RH bug #234018). * Sat Mar 17 2007 Matthew Barnes - 2.10.0-3.fc7 - Add flag to disable deprecated Camel symbols. - Add patch for GNOME bug #419469 (refactor shell/main.c). - Add patch for GNOME bug #419524 (use GLib's i18n macros). - Add patch for GNOME bug #418971 (drop support for GLib < 2.8). * Wed Mar 14 2007 Matthew Barnes - 2.10.0-2.fc7 - Add patch for GNOME bug #417999 (use ESourceComboBox). evolution-data-server-1.10.0-4.fc7 ---------------------------------- * Tue Mar 27 2007 Matthew Barnes - 1.10.0-4.fc7 - Link to static evolution-openldap library (RH bug #210126). - Require openssl-devel when statically linking against openldap. - Add -Wdeclaration-after-statement to strict build settings. * Thu Mar 22 2007 Matthew Barnes - 1.10.0-3.fc7 - Stop beeping at me! evolution-sharp-0.12.2-2.fc7 ---------------------------- * Sun Mar 25 2007 Matthew Barnes - 0.12.2-2.fc7 - Remove evolution-devel build requirement (RH bug #178661). fast-user-switch-applet-2.17.4-2.fc7 ------------------------------------ * Mon Mar 26 2007 Matthias Clasen 2.17.4-2 - Silently do nothing when gdm is not running - Don't register with the session manager fonts-indic-2.1.5-1.fc7 ----------------------- * Mon Mar 26 2007 Parag Nemade - 2.1.5 - Resolved Bugs from Parag Nemade - Bug 231965: [kn_IN] wrong Conjuct combines during the formation kannada letter [yo] - Bug 233257: [kn_IN] Conjuct combination of U0CAE with U0CCB is rendering wrongly - Bug 233415: [kn_IN] GSUB's combinaing with additional dependent vowel are not rendering correctly - Bug 233554: [kn_IN] GSUB's combinaing with additional dependent vowel U0CC0 are not rendering correctly - Bug 233555: [kn_IN] GSUB's combinaing with additional dependent vowel U0CC7 are not rendering correctly - Bug 233556: [kn_IN] GSUB's combinaing with additional dependent vowel U0CC6 are not rendering correctly - Bug 233557: [kn_IN] GSUB's combinaing with additional dependent vowel U0CC8 are not rendering correctly - Bug 233558: [kn_IN] GSUB's combinaing with additional dependent vowel U0CCBare not rendering correctly - Bug 233559: [kn_IN] GSUB's combinaing with additional dependent vowel U0CBE are not rendering correctly - Bug 233560: [kn_IN] GSUB's combinaing with additional dependent vowel U0CBF are not rendering correctly gail-1.18.0-2.fc7 ----------------- * Fri Mar 23 2007 Matthias Clasen - 1.18.0-2 - Rebuild against atk 1.8.0 to fix ia64 problems (#233687) gaim-2:2.0.0-0.31.beta6.fc7 --------------------------- * Fri Mar 23 2007 Warren Togami - 2:2.0.0-0.31.beta6 - Removed debian-02_gnthistory-in-gtk Removed debian-03_gconf-gstreamer.patch Upstream recommended removing these patches. - Add fix-buggy-fetch-url - Enable type_chat and type_chat_nick in default prefs.xml gcc-4.1.2-6 ----------- * Tue Mar 27 2007 Jakub Jelinek 4.1.2-6 - update from gcc-4_1-branch (-r123011:123245) - PRs fortran/31184, target/31245, tree-optimization/30590 - libjava W^X support (Alexandre Oliva, #202209) - fix gcjh -jni and gjavah -cni (Stepan Kasal, #233349) - fix C++ accepts invalid bug (Mark Mitchell, PR c++/30863) gdb-6.6-8.fc7 ------------- * Sat Mar 24 2007 Jan Kratochvil - 6.6-8 - Use definition of an empty structure as it is not an opaque type (BZ 233716). - Fixed the gdb.base/attachstop.exp testcase false 2 FAILs. * Thu Mar 15 2007 Jan Kratochvil - 6.6-7 - Suggest SELinux permissions problem; no assertion failure anymore (BZ 232371). * Wed Mar 14 2007 Jan Kratochvil - 6.6-6 - Fix occasional dwarf2_read_address: Corrupted DWARF expression (BZ 232353). gdm-1:2.18.0-6.fc7 ------------------ * Tue Mar 27 2007 Matthias Clasen - 1:2.18.0-6 - Hide gdmphotosetup by default, since About Me does the same gedit-1:2.18.0-2.fc7 -------------------- * Tue Mar 27 2007 Matthias Clasen - 1:2.18.0-2 - Reduce the size of the tags files gimp-2:2.2.13-2.fc7 ------------------- * Mon Mar 26 2007 Nils Philippsen - 2:2.2.13-2 - own used directories in gimp-devel (#233794) * Wed Feb 21 2007 Nils Philippsen - s/%redhat/%rhel/g * Wed Feb 07 2007 Nils Philippsen - really change defaults for use of modular X and lcms (#224156) gnome-applets-1:2.18.0-2.fc7 ---------------------------- * Wed Mar 21 2007 Ray Strode - 1:2.18.0-2 - rerun intltoolize to get latest version gnome-desktop-2.18.0-4.fc7 -------------------------- * Fri Mar 23 2007 Soren Sandmann - 2.18.0-4 - Remove debug spew - add file caching - delete totally_obscures function. gnome-games-1:2.18.0-2.fc7 -------------------------- * Fri Mar 23 2007 Matthias Clasen - 1:2.18.0-2 - Fix the icon in the blackjack about dialog (#233649) gnome-mount-0.5-4.fc7 --------------------- * Mon Mar 26 2007 Matthias Clasen - 0.5.0-4 - Fix a directory ownership issue (#233959) - Other spec cleanups gnome-power-manager-2.18.1-1.fc7 -------------------------------- * Fri Mar 23 2007 Ray Strode - 2.18.1-1 - Update to 2.18.1 gnome-session-2.18.0-2.fc7 -------------------------- * Wed Mar 21 2007 Ray Strode - 2.18.0-2 - remove eggcups from default session (bug 233261) gnome-speech-0.4.10-2.fc7 ------------------------- * Tue Mar 20 2007 David Zeuthen - 0.4.10-2 - Drop i386-only requirement (#232517) - Require newer version of festival gnome-user-share-0.11-2.fc7 --------------------------- * Fri Mar 23 2007 Matthias Clasen - 0.11-2 - Don't hardwire invisible char (#233676) gnuplot-4.0.0-18.fc7 -------------------- * Mon Mar 26 2007 Ivana Varekova - 4.0.0-18 - add missing directories (#233838) gpm-1.20.1-81.fc7 ----------------- * Fri Mar 23 2007 Tomas Janousek - 1.20.1-81 - the patch for #168076 caused a strange behaviour with ncurses, fixed it differently gthumb-2.10.0-2.fc7 ------------------- * Fri Mar 23 2007 Matthias Clasen - 2.10.0-2 - Remove a no-longer needed patch (#233350) gtk2-2.10.11-2.fc7 ------------------ * Tue Mar 20 2007 Florian La Roche - 2.10.11-2 - fix Conflicts: libgnomeui line hunspell-1.1.5-2.fc7 -------------------- * Tue Mar 20 2007 Caolan McNamara - 1.1.5-2 - some junk in delivered headers * Tue Mar 20 2007 Caolan McNamara - 1.1.5-1 - next version * Fri Feb 09 2007 Caolan McNamara - 1.1.4-6 - some spec cleanups imake-1.0.2-4.fc7 ----------------- * Mon Mar 26 2007 Adam Jackson 1.0.2-4 - makedepend 1.0.1 intltool-0.35.5-3.fc7 --------------------- * Wed Mar 21 2007 Ray Strode - 0.35.5-3 - don't store a translation if it is equal to the original string iputils-20070202-2.fc7 ---------------------- * Tue Mar 27 2007 Martin Bacovsky - 20070202-2 - Resolves: #234060: [PATCH] IDN (umlaut domains) support for ping and ping6 patch provided by Robert Scheck java-1.5.0-gcj-1.5.0.0-11.fc7 ----------------------------- * Mon Mar 26 2007 Thomas Fitzsimmons - 1.5.0.0-11 - Disable bootstrap mode. * Mon Mar 26 2007 Thomas Fitzsimmons - 1.5.0.0-10 - Import java-gcj-compat 1.0.74. * Mon Mar 26 2007 Thomas Fitzsimmons - 1.5.0.0-9 - Re-add gcj-java build requirement. jwhois-3.2.3-11 --------------- * Fri Mar 23 2007 Vitezslav Crhonek - 3.2.3-11 - Change the server used for .se domains to whois.iis.se (patch by Johan Sare ) Resolves: #233207 kasumi-2.2-2.fc7 ---------------- * Wed Mar 28 2007 Akira TAGOH - 2.2-2 - Add X-GNOME-PersonalSettings to the category. (#234169) kdeartwork-3.5.6-2.fc7 ---------------------- * Wed Mar 21 2007 Than Ngo - 3.5.6-2.fc7 - cleanup specfile kdebase-6:3.5.6-4.fc7 --------------------- * Thu Mar 22 2007 Than Ngo 6:3.5.6-4.fc7 - add new KDM theme for Fedora 7 kernel-2.6.20-1.3024.fc7 ------------------------ * Wed Mar 28 2007 David Woodhouse - Add Efika (mpc52xx) Ethernet driver - Crappy workaround for sysfs/uevent problems (#227893) - Fix IPv6 failure with NetworkManager (#234067) * Sun Mar 25 2007 Dave Jones - 2.6.21-rc5 * Sun Mar 25 2007 Dave Jones - 2.6.21-rc4-git11 kexec-tools-1.101-65.fc7 ------------------------ * Mon Mar 26 2007 Neil Horman - 1.101-65.fc7 - Fix spec to own kexec_tools directory (bz 219035) * Wed Mar 21 2007 Neil Horman - 1.101-64.fc7 - Add fix for ppc memory region computation (bz 233312) kudzu-1.2.66-1 -------------- * Mon Mar 26 2007 Jeremy Katz - 1.2.66-1 - define PROBE_LOADED for python (dcantrell, #233507) * Fri Mar 23 2007 Jeremy Katz - 1.2.65-1 - handle new firewire stack (#231708) - add support for FBA-DASD (#227913, #215423, ) - fix ibmveth. again (notting, #219276) * Wed Nov 29 2006 Bill Nottingham - 1.2.64-1 - treat qla4xxx devices as HBAs, even if their PCI class is network (#216881) - correctly set device for ttyACM USB devices (#217051, ) - don't leak fds in scsi probe (#214878, #191521, #217742) - fix segfault (#217818) lam-2:7.1.2-9.fc7 ----------------- * Thu Mar 22 2007 Florian La Roche - 2:7.1.2-9.fc6 - add alternatives to some more deps libXdamage-1.1.1-1.fc7 ---------------------- * Mon Mar 26 2007 Adam Jackson 1.1.1-1 - libXdamage 1.1.1 libXinerama-1.0.2-1.fc7 ----------------------- * Mon Mar 26 2007 Adam Jackson 1.0.2-1 - libXinerama 1.0.2 libgconf-java-2.12.4-8.fc7 -------------------------- * Wed Mar 21 2007 Stepan Kasal - 2.12.4-8 - BuildRequire java-devel instead of java-1.4.2-gcj-compat-devel. libgsf-1.14.3-4.fc7 ------------------- * Sun Mar 25 2007 Caolan McNamara 1.14.3-4 - Resolves rhbz#233862 unowned directory fix from Michael Schwendt libgssapi-0.10-3.fc7 -------------------- * Mon Mar 26 2007 Steve Dickson - 0.10-3 - Fixed Unowned Directory RPM problem (bz 233863) libnotify-0.4.4-2.fc7 --------------------- * Sun Mar 25 2007 Matthias Clasen - 0.4.4-2 - Require gtk2-devel in the -devel package (#216946) * Fri Mar 23 2007 Matthias Clasen - 0.4.4-1 - Update to 0.4.4, which contains important bug fixes and memory leak fixes - Require pkgconfig in the -devel package libselinux-2.0.8-1.fc7 ---------------------- * Tue Mar 27 2007 Dan Walsh - 2.0.8-1 - Upgrade to upstream * Merged fix for avc.h #include's from Eamon Walsh. * Thu Mar 22 2007 Dan Walsh - 2.0.7-2 - Add stdint.h to avc.h libsemanage-2.0.1-2.fc7 ----------------------- * Sat Mar 17 2007 Dan Walsh - 2.0.1-2 - Add SELinux to Man page Names so man -k will work libtheora-0:1.0alpha7-2.fc7 --------------------------- * Sun Mar 25 2007 Matthias Clasen - 0:1.0alpha7-2 - Fix a directory ownership issue (#233872) - Small spec cleanups libvirt-0.2.1-3.fc7 ------------------- * Mon Mar 26 2007 Daniel Veillard - 2.0.1-3.fc7 - add missing directory ownership fixes rhbz#233874 libwpd-0.8.9-2.fc7 ------------------ * Tue Mar 27 2007 Caolan McNamara - 0.8.9-2 - Resolves: rhbz#233876: add unowned directory fix from Michael Schwendt module-init-tools-3.3-0.pre11.1.0.fc7 ------------------------------------- * Thu Mar 22 2007 Jon Masters - 3.3-0.pre11.1.0 - Rebase to latest upstream release. nautilus-2.18.0.1-2.fc7 ----------------------- * Mon Mar 26 2007 Matthias Clasen - 2.18.0.1-2 - Update icon caches (#234020) * Mon Mar 12 2007 Alexander Larsson - 2.18.0.1-1 - Update to 2.18.0.1 * Tue Mar 06 2007 Alexander Larsson - 2.17.92-3 - Update xdg-user-dirs patch, now handle renaming desktop dir net-tools-1.60-81.fc7 --------------------- * Tue Mar 27 2007 Radek Vok??l - 1.60-81 - fix segfault for empty interface (#234045) nmap-2:4.20-5.fc7 ----------------- * Fri Mar 23 2007 Harald Hoyer - 2:4.20-5 - fixed changelog versions * Thu Mar 15 2007 Karsten Hopp 2:4.20-4 - rebuild with current gtk2 to add png support (#232013) * Tue Feb 27 2007 Harald Hoyer - 2:4.20-3 - specfile cleanup - fixed Florian La Roche's patch notification-daemon-0.3.7-1.fc7 ------------------------------- * Fri Mar 23 2007 Matthias Clasen - 0.3.7-1 - Update to 0.3.7, which contains important bug fixes and theming improvements nss_ldap-254-2 -------------- * Wed Mar 21 2007 Nalin Dahyabhai - 254-2 - resize the supplemental GID array when it gets too large and a size limit isn't set (Gavin Romig-Koch, #232713) nut-2.0.5-3 ----------- * Mon Mar 26 2007 Than Ngo 2.0.5-3 - cleanup openobex-1.3-5.fc7 ------------------ * Fri Mar 23 2007 Harald Hoyer - 1.3-5.fc7 - specfile cleanup openoffice.org-1:2.2.0-14.1 --------------------------- * Sun Mar 25 2007 Caolan McNamara - 1:2.2.0-14.1 - RC4 - follow up on drepper's suggestion of combining startup DSOs into libsoffice + http://people.redhat.com/caolanm/speed/CombinedDSO.ods * Tue Mar 20 2007 Caolan McNamara - 1:2.2.0-13.1 - add tango to the themes UI - yet another rc openswan-2.4.7-3.fc7 -------------------- * Tue Mar 20 2007 Florian La Roche - 2.4.7-3 - do not use epoch macro, it is unset * Wed Feb 28 2007 Harald Hoyer - 2.4.7-2 - specfile review * Fri Jan 26 2007 Harald Hoyer - 2.4.7-1 - removed key generation from install phase - version 2.4.7 oprofile-0.9.2-8.fc7 -------------------- * Wed Mar 21 2007 Will Cohen - 0.9.2-8 - Add AMD family 10 support. Resolves: rhbz#232956. * Wed Mar 21 2007 Will Cohen - 0.9.2-7 - Correct description for package. - Correct backtrace documentation. Resolves: rhbz#214793. - Correct race condition. Resolves: rhbz#220116. pam-0.99.7.1-4.fc7 ------------------ * Fri Mar 23 2007 Tomas Mraz 0.99.7.1-4 - pam_console: always decrement use count (#230823) - pam_namespace: use raw context for poly dir name (#227345) - pam_namespace: truncate long poly dir name (append hash) (#230120) - we don't patch any po files anymore * Wed Feb 21 2007 Tomas Mraz 0.99.7.1-3 - correctly relabel tty in the default case (#229542) - pam_unix: cleanup of bigcrypt support - pam_unix: allow modification of '*' passwords to root * Tue Feb 06 2007 Tomas Mraz 0.99.7.1-2 - more X displays as consoles (#227462) paps-0.6.6-19.fc7 ----------------- * Tue Mar 27 2007 Akira TAGOH - 0.6.6-19 - Fix PostScript breakage following the non-monetary numeric format from current locale. (#231916) parted-1.8.6-2.fc7 ------------------ * Wed Mar 21 2007 David Cantrell - 1.8.6-2 - Do not translate partition name from disk label (#224182) pcmciautils-014-6.fc7 --------------------- * Fri Mar 23 2007 Harald Hoyer - 014-6.fc7 - specfile cleanup php-5.2.1-4 ----------- * Wed Mar 21 2007 Joe Orton 5.2.1-4 - drop mime_magic extension (deprecated by php-pecl-Fileinfo) pm-utils-0.99.3-1.fc7 --------------------- * Mon Mar 26 2007 Peter Jones - 0.99.3-1 - update to 0.99.3 - configure manually in the spec to avoid %_lib as lib64 * Tue Mar 13 2007 Peter Jones - 0.99.2-1 - update to 0.99.2 * Fri Feb 02 2007 Peter Jones - 0.99.1-1 - Fix setsysfont hook to actually hit tty0, not the pty of the current task. policycoreutils-2.0.7-6.fc7 --------------------------- * Fri Mar 23 2007 Dan Walsh 2.0.7-6 - Updated version of sepolgen * Merged patch to discard self from types when generating requires from Karl MacMillan. procmail-3.22-19.fc7 -------------------- * Tue Mar 27 2007 Miroslav Lichvar 3.22-19 - fix description (#234098) - spec cleanup qt-1:3.3.8-2.fc7 ---------------- * Tue Mar 27 2007 Than Ngo 1:3.3.8-2.fc7 - enable tablet support readline-5.2-4.fc7 ------------------ * Thu Mar 22 2007 Miroslav Lichvar 5.2-4 - apply 5.2-002 patch redhat-menus-7.8.12-1.fc7 ------------------------- * Tue Mar 27 2007 Matthias Clasen - 7.8.12-1 - Use System-Tools for Application > System * Wed Mar 21 2007 Matthew Barnes - 7.8.11-2 - Update evolution files, add X-GNOME-Bugzilla-Component (#224199) rhpxl-0.44-1.fc7 ---------------- * Mon Mar 26 2007 Adam Jackson 0.44-1 - Fix mode name splitting. (#213027) rhythmbox-0.9.8-3.fc7 --------------------- * Sun Mar 25 2007 Matthias Clasen - 0.9.8-3 - Fix a directory ownership issue (#233911) samba-0:3.0.24-7.fc7 -------------------- * Fri Mar 23 2007 Simo Sorce 3.0.24-7.fc7 - make winbindd start earlier in the init process, at the same time ypbind is usually started as well - add a sepoarate init script for nmbd called nmb, we need to be able to restart nmbd without dropping al smbd connections unnecessarily * Fri Mar 23 2007 Simo Sorce - add samba.schema to /etc/openldap/schema * Thu Mar 22 2007 Florian La Roche - adjust the Requires: for the scripts, add "chkconfig --add smb" scim-hangul-0.3.1-1.fc7 ----------------------- * Thu Mar 22 2007 Akira TAGOH - 0.3.1-1 - New upstream release. - remove the unnecessary patches: - scim-hangul-0.2.2-help.patch - scim-hangul-0.2.2-ascii-mode.patch - scim-hangul-0.2.2-swap-keybinding.patch - scim-hangul-update-caret.patch screen-4.0.3-5.fc7 ------------------ * Mon Mar 26 2007 Marcela Maslanova - 4.0.3-5 - rebuilt (change in spec file) shadow-utils-2:4.0.18.1-12.fc7 ------------------------------ * Mon Mar 26 2007 Peter Vrabec 2:4.0.18.1-12 - create user's mailbox file by default (#231311) sinjdoc-0.5-3.fc7 ----------------- squid-7:2.6.STABLE12-1.fc7 -------------------------- * Tue Mar 27 2007 Martin Bacovsky - 7:2.6.STABLE12-1 - update to latest upstream 2.6.STABLE12 - Resolves: #233913: squid: unowned directory * Mon Feb 19 2007 Martin Bacovsky - 7:2.6.STABLE9-2 - Resolves: #226431: Merge Review: squid * Mon Jan 29 2007 Martin Bacovsky - 7:2.6.STABLE9-1 - update to the latest upstream struts-0:1.2.9-4jpp.6 --------------------- * Tue Mar 27 2007 Deepak Bhole 1.2.9-4jpp.6 - Rewrote pre/preun/post/postun dependencies - Change Pre[rR]eq -> Requires(pre) - Add unowned directory to folders section. bz# 233821. sysklogd-1.4.2-3.fc7 -------------------- * Mon Mar 26 2007 Peter Vrabec 1.4.2-3 - include priority/facility in message (#223573) sysstat-7.0.4-2.fc7 ------------------- * Fri Mar 23 2007 Ivana Varekova - 7.0.4-2 - fix sa2 problem (sa2 works wrong when the /var/log/sa file is a link to another directory) system-config-boot-0.2.15-1.fc7 ------------------------------- * Fri Mar 23 2007 Harald Hoyer - 0.2.15-1.fc7 - specfile cleanups system-config-date-1.8.93-1.fc7 ------------------------------- * Mon Mar 26 2007 Nils Philippsen 1.8.93 - explain why system-config-date conflicts with old versions of firstboot * Mon Mar 26 2007 Nils Philippsen 1.8.92 - use correct modes when installing, to avoid fixing modes when packaging and to be able to strip down %files - don't ship unneeded regions file * Thu Mar 22 2007 Nils Philippsen 1.8.91 - update URL system-config-display-1.0.49-1.fc7 ---------------------------------- * Thu Mar 22 2007 Adam Jackson 1.0.49-1 - Package review cleanups. * Mon Jan 29 2007 Adam Jackson - Copy instead of rename when doing backup of xorg.conf, in case the user has it as a symlink. (#181965) * Fri Dec 15 2006 Adam Jackson 1.0.48-2 - Rebuild for translations. system-config-printer-0.7.60-1.fc7 ---------------------------------- * Tue Mar 27 2007 Tim Waugh 0.7.60-1 - Updated to pycups-1.9.19. - Avoid %makeinstall. - 0.7.60: - Handle reconnection failure. - New applet name. * Mon Mar 26 2007 Tim Waugh 0.7.59-1 - 0.7.59: - Fixed a translatable string. - Set a window icon (bug #233899). - Handle failure to start the D-Bus service. - Ellipsize the document and printer named (bug #233899). - Removed the status bar (bug #233899). - Added an icon pop-up menu for 'Hide' (bug #233899). * Wed Mar 21 2007 Tim Waugh 0.7.57-1 - Added URL tag. - 0.7.57: - Prevent traceback when removing temporary file (Ubuntu #92914). - Added print applet. system-config-users-1.2.54-1.fc7 -------------------------------- * Mon Mar 26 2007 Nils Philippsen - 1.2.54 - fix plural specification for German (#233781) * Thu Mar 22 2007 Nils Philippsen - update URL * Tue Mar 20 2007 Nils Philippsen - mention that we are upstream - use preferred buildroot - use Category: ... System; ... in desktop file - clean buildroot before installing - fix licensing blurb in PO files - require/BR python >= 2.0 instead of python2 - recode spec file to UTF-8 systemtap-0.5.13-1.fc7 ---------------------- * Mon Mar 26 2007 Frank Ch. Eigler - 0.5.13-1 - An emergency / preliminary refresh, mainly for compatibility with 2.6.21-pre kernels. * Mon Jan 01 2007 Frank Ch. Eigler - 0.5.12-1 - Many changes, see NEWS file. tcl-1:8.4.13-14.fc7 ------------------- * Wed Mar 21 2007 Marcela Maslanova - 1:8.4.13-14 - multilib problem, rhbz#227200 * Tue Feb 27 2007 Marcela Maslanova - 1:8.4.13-12 - review * Wed Feb 21 2007 Marcela Maslanova - 1:8.4.13-11 - review tog-pegasus-2:2.6.0-2.fc7 ------------------------- * Mon Feb 26 2007 Mark Hamzy - 2.6.0-1 - Upgrade to upstream version 2.6.0 * Mon Dec 04 2006 Nalin Dahyabhai - 2:2.5.2-3 - change requires: tog-pegasus to prereq: tog-pegasus so that the pegasus user and group will exist when we go to lay down files for tog-pegasus-devel (#218305) - prereq the current version of openssl so that the right versions of libssl and libcrypto will be available in %post (possible for #208949) tzdata-2007d-1.fc7 ------------------ * Wed Mar 21 2007 Petr Machata - 2007d-1 - Upstream 2007d - Mongolia has abolished DST. - Turkey will use EU rules this year, changing at 01:00 UTC rather than 01:00 standard time. - Cuba observed DST starting Sunday. - Resolute, Nunavut switched from Central to Eastern time last November. units-1.86-5.fc7 ---------------- * Fri Mar 23 2007 Harald Hoyer - 1.86-5.fc7 - more specfile cleanups usermode-1.91-2 --------------- * Tue Mar 27 2007 Matthias Clasen 1.91-2 - Clean up desktop files virt-manager-0.3.2-2.fc7 ------------------------ * Tue Mar 27 2007 Daniel P. Berrange - 0.3.2-2.fc7 - Ensure we own all directories we create (bz 233816) vnc-4.1.2-16.fc7 ---------------- * Tue Mar 27 2007 Adam Tkac 4.1.2-16.fc7 - fixed vnc module crashing (#234124) - vncviewer has been moved from Utility group to Network group (#231765) vsftpd-2.0.5-15.fc7 ------------------- * Tue Mar 20 2007 Florian La Roche - 2.0.5-15 - fix BuildPrereq vte-0.16.0-3.fc7 ---------------- * Mon Mar 26 2007 Matthias Clasen 0.16.0-3 - Add a patch to fix transparency (#232781) * Sat Mar 24 2007 Matthias Clasen 0.16.0-2 - Add a patch to fix redraw problems w3m-0.5.1-19.fc7 ---------------- * Tue Mar 27 2007 Parag Nemade - 0.5.1-19 - and more cleanup. * Tue Mar 27 2007 Parag Nemade - 0.5.1-18.2 - more cleanup. * Mon Mar 26 2007 Parag Nemade - 0.5.1-18 - spec file cleanup. werken-xpath-0:0.9.4-0.beta.12jpp.2 ----------------------------------- * Tue Mar 20 2007 Florian La Roche 0:0.9.4-0.beta.12jpp.2 - change Provides:/Obsoletes: to standard way of epoch:version-release xchat-1:2.6.6-9.fc7 ------------------- * Sat Mar 24 2007 Matthias Clasen - 1:2.6.6-9 - Own /usr/lib/xchat (#166731) * Fri Nov 03 2006 Matthias Clasen - 1:2.6.6-8 - Silence %pre (#213838) * Wed Oct 18 2006 Matthias Clasen - 1:2.6.6-7 - Fix scripts according to packaging guidelines xjavadoc-0:1.1-4jpp.2 --------------------- * Mon Mar 26 2007 Deepak Bhole 1.1-4jpp.2 - Fixed incorrect entry in the files section xorg-x11-drv-i810-1.6.5-15.fc7 ------------------------------ * Tue Mar 27 2007 Jeremy Katz - 1.6.5-15 - fix typo with 945GM pci id from my laptop xorg-x11-drv-nv-2.0.0-3.fc7 --------------------------- * Fri Mar 23 2007 Adam Jackson 2.0.0-3 - nv.xinf: It helps if you spell the driver name correctly. xorg-x11-font-utils-1:7.1-5.fc7 ------------------------------- * Mon Mar 26 2007 Adam Jackson 1:7.1-5 - mkfontdir 1.0.3 * Fri Jan 05 2007 Adam Jackson 1:7.1-4.fc7 - fonttosfnt 1.0.3 * Thu Aug 17 2006 Adam Jackson 1:7.1-3 - Remove X11R6 symlinks. xorg-x11-utils-7.1-4.fc7 ------------------------ * Mon Mar 26 2007 Adam Jackson 7.1-4 - xdpyinfo 1.0.2 xterm-225-1.fc7 --------------- * Tue Mar 27 2007 Miroslav Lichvar 225-1 - update to 225 zisofs-tools-1.0.7-1.fc7 ------------------------ * Fri Mar 23 2007 Harald Hoyer - 1.0.7-1.fc7 - version 1.0.7 * Fri Mar 23 2007 Harald Hoyer - 1.0.6-4.fc7 - specfile cleanup zlib-1.2.3-10.fc7 ----------------- * Fri Mar 23 2007 Ivana Varekova - 1.2.3-10 - remove zlib .so.* packages to /lib * Fri Mar 09 2007 Ivana Varekova - 1.2.3-9 - incorporate package review feedback * Wed Feb 21 2007 Adam Tkac - 1.2.3-8 - fixed broken version of libz Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.13-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.13-1.fc7.s390 requires kernel >= 0:2.6.9-11 From pemboa at gmail.com Wed Mar 28 23:20:29 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 28 Mar 2007 18:20:29 -0500 Subject: hplip: hp-toolbox advertising? In-Reply-To: <200703281817.17144.jkeating@redhat.com> References: <460ACE08.9010205@hhs.nl> <200703281817.17144.jkeating@redhat.com> Message-ID: <16de708d0703281620r3a18d39ata5028045d632086b@mail.gmail.com> On 3/28/07, Jesse Keating wrote: > On Wednesday 28 March 2007 16:20:24 Hans de Goede wrote: > > /me too, > > > > Can we please stop the HP bashing, they are doing a great job in providing > > support for their hardware, if their tools need better integration into the > > rest of Linux, then work with them, instead of bashing them / their > > software. > > I'd wager their tools need to be better period. > > I just unpacked a new HP photosmart C3180 multipurpose thingy. I wanted to > print out my flight eticket. After all this discussion I figured I'd give it > a try. After powering on and attaching the printer via usb, I ask yum to > install hplip. After downloading a 10+ megs of software, I had hplip on my > system. I tried to -f2 and typed in hp-toolbox as that would be what > the menu called. Nothing. Tried again, nothing. The hell? Try it from a > console, HO! A daemon isn't running and so the software just yells about not > being able to connect to "HPLIP I/O (hpiod)" whatever the hell that is. > Helpful. Being a bit cluefull about these things, I guess it wants the hplip > service to be running. So start the daemon, try again, and I get a big > screen about no installed HP devices found. Ok, there is a setup device > button, click it, nothing detected. Find Manually asks me for a cryptic USB > ID which it gives me no clue as how to find it. Helpful. > > So I give up on this, close it, stop the service. > > I instead try System -> Administration -> Printing > > New printer > > Fill in details about name, description, location > > Hit next and look at that, it automatically detected I had a USB printer > plugged in and even had the right name. Forward again, pick the closest HP > driver from the list (HP Photosmart C3100) finalize and boom I can print a > test job, and furthermore print my etickets. > > Yeah, this is great software allright. *sigh* > > -- > Jesse Keating > Release Engineer: Fedora Jesse, If you had the hp daemons in, all you had to do was use CUPS to install it. You don't need to use the HP toolkit at all . -- Fedora Core 6 and proud From jkeating at redhat.com Wed Mar 28 23:26:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Mar 2007 19:26:36 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: <16de708d0703281620r3a18d39ata5028045d632086b@mail.gmail.com> References: <200703281817.17144.jkeating@redhat.com> <16de708d0703281620r3a18d39ata5028045d632086b@mail.gmail.com> Message-ID: <200703281926.37173.jkeating@redhat.com> On Wednesday 28 March 2007 19:20:29 Arthur Pemberton wrote: > Jesse, > > If you had the hp daemons in, all you had to do was use CUPS to > install it. You don't need to use the HP toolkit at all . "use cups". That's helpful. I use the print administration tool found in my menu. I don't care what backend that uses, I just want the printer to work. I did add the printer via this backend, and being cluefull I know it uses cups. However even after added and the daemons running and such, printing working fine, hp-toolbox STILL can't find it at all, and thus I can't even look at all those wizbang features you mentioned where possible. -- 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 Wed Mar 28 23:34:05 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Mar 2007 19:34:05 -0400 Subject: Opinions: Providing "buildsys-macros" in the installed system Message-ID: <200703281934.06162.jkeating@redhat.com> In our buildsystem we use a 'buildsys-macros' package that defines some things during the package builds, like the definition of %{dist}, and of %{fedora} or %{rhel}. Now we're talking about adding even more macros to add convenience for packagers that are packaging the same thing for multiple Fedora releases and RHEL releases (Hurray EPEL!). However, with more of these macros in use, the usage case of rebuilding the srpms on your local system starts to get harder, as these macros will be undefined and you'll have interesting results. Perhaps surprising results. I propose we ship these macros in something like redhat-rpm-config for each release, so that when somebody is rebuilding a package on their system, the macros are defined correctly for whatever release they are running. If they are rebuilding for another release/distribution, they really should be using mock, and having redhat-rpm-config define the right things within their mock chroot. In the past I remember there being resistance to shipping these on the installed system, however my Test3 addled brain is not able to recall what those are. Are there any differing opinions on this matter, anybody that disagrees with me? I'd love to hear it and thought out reasons against taking the step. Thanks! -- 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 fs111 at web.de Wed Mar 28 23:50:33 2007 From: fs111 at web.de (=?ISO-8859-1?Q?Andr=E9_Kelpe?=) Date: Thu, 29 Mar 2007 01:50:33 +0200 Subject: Is it a bug or intentionally done? In-Reply-To: <460AF574.1000102@cox.net> References: <6e24a8e80703281255w1cbcedb3ve4edc0b9fa95b600@mail.gmail.com> <1175112082.4641.70.camel@localhost.localdomain> <460AF574.1000102@cox.net> Message-ID: <460AFF49.7020302@web.de> Greg Morgan schrieb: > 1.) Or go to Applications > Accessories > Take Screenshot > right click > and use either add to panel or add to desktop. The panel may make screen > shots easier for menus. > 2.) Right click on the new icon> select properties. In the command box > after gnome-screenshot add --delay=seconds i.e. > gnome-screenshot --delay=3 Wow, that's a complicated way for doing just a $ sleep 3; import -window root shot.png Andr? From kevin.kofler at chello.at Thu Mar 29 00:08:47 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 29 Mar 2007 00:08:47 +0000 (UTC) Subject: hplip: hp-toolbox advertising? References: <200703281817.17144.jkeating@redhat.com> <16de708d0703281620r3a18d39ata5028045d632086b@mail.gmail.com> <200703281926.37173.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > "use cups". That's helpful. I use the print administration tool found in my > menu. I don't care what backend that uses, I just want the printer to work. > I did add the printer via this backend, and being cluefull I know it uses > cups. However even after added and the daemons running and such, printing > working fine, hp-toolbox STILL can't find it at all, and thus I can't even > look at all those wizbang features you mentioned where possible. HP USB printers can be addressed by 2 ways: * the default CUPS usb:/ transport * the hplip hp:/ transport With the usb:/ transport, printing will work, but anything beyond that won't. (In particular, hp-toolbox doesn't list the printer if it's configured with a usb:/ URI.) So in system-config-printer, look at the device URI and make sure it's set to a hp:/ transport, if it's not, use the Change... button, the hp:/ URI should be listed as one of the options there. I hope this helps. With all the work you are doing in the Fedora Project to help us users, I'd be glad if I was once of help to you. :-) Kevin Kofler From davej at redhat.com Thu Mar 29 00:11:42 2007 From: davej at redhat.com (Dave Jones) Date: Wed, 28 Mar 2007 20:11:42 -0400 Subject: iwlwifi in rawhide different? In-Reply-To: <20070328224307.GC20227@ryvius.pekin.waw.pl> References: <460AED55.2090102@redhat.com> <20070328224307.GC20227@ryvius.pekin.waw.pl> Message-ID: <20070329001142.GA604@redhat.com> On Thu, Mar 29, 2007 at 12:43:07AM +0200, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 29 March 2007 at 00:33, Warren Togami wrote: > > http://people.redhat.com/linville/kernels/fc7/ > > The iwlwifi driver appears to be in the standard rawhide kernel. Is > > this the same or older than the driver in Linville's test kernels? > > While we're on the topic, will this be released as an update for FC6? unlikely, it needs some serious shaking out looking at the current sate of things. Dave -- http://www.codemonkey.org.uk From cr33dog at gmail.com Thu Mar 29 00:35:05 2007 From: cr33dog at gmail.com (Chris Mohler) Date: Wed, 28 Mar 2007 19:35:05 -0500 Subject: hplip: hp-toolbox advertising? In-Reply-To: <200703281926.37173.jkeating@redhat.com> References: <200703281817.17144.jkeating@redhat.com> <16de708d0703281620r3a18d39ata5028045d632086b@mail.gmail.com> <200703281926.37173.jkeating@redhat.com> Message-ID: On 3/28/07, Jesse Keating wrote: [...] > "use cups". That's helpful. I use the print administration tool found in my > menu. I don't care what backend that uses, I just want the printer to work. [...] AFAIK, system-config-printer is (was?) broken, and I've heard the same advice multiple times on the user-list: use CUPS. My memory ain't so hot, but IIRC s-c-p should Just Work in F7. Or maybe that's just a bad memory by now. As a counterpoint to your horror story: I just dug a HP PSC 1210 (multifunction) out of the garbage this very afternoon. Took it home, checked hplip was running, plugged it in, went to the CUPS interface and added the HPLIP variant of the detected printer, and all is well with the world - status, ink levels, scanning, etc. ... I didn't even finish the reply before things went wonky :) Looks like the color cart is fragged. Probably could have worked it out for myself, but the hp-toolkit actually made it much easier. I understand that the program is sub-par (being generous here), but I haven't used anything like it in *nix that can communicate with the device on that level. FWIW, I'm +1 on getting HAL and friends to decide if hplip should be activated, also +1 for putting the icon in the menu, and +1 for pitching a bitch at HP to fix their mess. But since I don't do any work around here, maybe my vote should be +0.02 / +0.02 / +0.02 :) Chris From jkeating at redhat.com Thu Mar 29 00:40:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Mar 2007 20:40:47 -0400 Subject: hplip: hp-toolbox advertising? In-Reply-To: References: <200703281926.37173.jkeating@redhat.com> Message-ID: <200703282040.48082.jkeating@redhat.com> On Wednesday 28 March 2007 20:08:47 Kevin Kofler wrote: > HP USB printers can be addressed by 2 ways: > * the default CUPS usb:/ transport > * the hplip hp:/ transport > With the usb:/ transport, printing will work, but anything beyond that > won't. (In particular, hp-toolbox doesn't list the printer if it's > configured with a usb:/ URI.) I guess my point here is that how is an end user supposed to know this, when it isn't integrated correctly into the tool set we're putting out for managing printers on the desktop. -- 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 sundaram at fedoraproject.org Thu Mar 29 00:43:08 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 29 Mar 2007 06:13:08 +0530 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> Message-ID: <460B0B9C.9090901@fedoraproject.org> Jonathan Dieter wrote: > So yeah, I'm curious. Have you managed to do your update yet? If you > have, what kind of savings did you see? The yum transaction failed with a unsigned gpg key error. Turned off gpg key check and reran yum. Yum showed it was downloading 400+ MB but proceeded to use the rpms build in the cache by presto in the previous run. However it ended up showing now savings at all in the presto log. You might want to check how the plugin is handling failed gpg checks. Did a fresh installation again with the default set of packages. Turned off gpg key. Ran yum install yum first followed by yum update. Here is the presto log. Download Size (without DRPM),Download Size (with DRPM),Percentage Savings,Total Percentage Savings 493372,132236,74,74 509267102,126959924,76,76 Pretty good savings and the system seems to be functioning as expected in my limited testing. At this point it might be useful to put the plugin in the repository atleast in the devel branch and get more mirrors using the drpms for wider testing. We should consider having this plugin enabled and installed by default for Fedora 7 release. Rahul From katzj at redhat.com Thu Mar 29 00:47:33 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 28 Mar 2007 20:47:33 -0400 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <460B0B9C.9090901@fedoraproject.org> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> <460B0B9C.9090901@fedoraproject.org> Message-ID: <1175129253.3034.0.camel@aglarond.local> On Thu, 2007-03-29 at 06:13 +0530, Rahul Sundaram wrote: > Pretty good savings and the system seems to be functioning as expected > in my limited testing. At this point it might be useful to put the > plugin in the repository atleast in the devel branch and get more > mirrors using the drpms for wider testing. We should consider having > this plugin enabled and installed by default for Fedora 7 release. While I'm very much in favor of getting it out and more easily available to people, there's no way we should make this the default for Fedora 7 at this point. Please see the definition of "feature freeze" :-) Jeremy From kevin.kofler at chello.at Thu Mar 29 01:04:19 2007 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 29 Mar 2007 01:04:19 +0000 (UTC) Subject: hplip: hp-toolbox advertising? References: <200703281926.37173.jkeating@redhat.com> <200703282040.48082.jkeating@redhat.com> Message-ID: Jesse Keating redhat.com> writes: > I guess my point here is that how is an end user supposed to know this, when > it isn't integrated correctly into the tool set we're putting out for > managing printers on the desktop. Well, the end user is supposed to get the hp:/ URI automatically, at least since hal-cups-utils-0.6.3-1: * Tue Jan 02 2007 Tim Waugh 0.6.3-1 - 0.6.3: - Applied all patches. - Added syslogging. - Use 'hp:' URIs when appropriate (bug #175555). - Put PPD NickName in info line instead of just 'Added by HAL'. - Don't add/remove new printer if one already exists with a matching URI. The reason you didn't get the hp: URI is probably that hplip wasn't installed when you plugged in the device. Kevin Kofler From sundaram at fedoraproject.org Thu Mar 29 01:11:05 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 29 Mar 2007 06:41:05 +0530 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175129253.3034.0.camel@aglarond.local> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> <460B0B9C.9090901@fedoraproject.org> <1175129253.3034.0.camel@aglarond.local> Message-ID: <460B1229.3050301@fedoraproject.org> Jeremy Katz wrote: > On Thu, 2007-03-29 at 06:13 +0530, Rahul Sundaram wrote: >> Pretty good savings and the system seems to be functioning as expected >> in my limited testing. At this point it might be useful to put the >> plugin in the repository atleast in the devel branch and get more >> mirrors using the drpms for wider testing. We should consider having >> this plugin enabled and installed by default for Fedora 7 release. > > While I'm very much in favor of getting it out and more easily available > to people, there's no way we should make this the default for Fedora 7 > at this point. > > Please see the definition of "feature freeze" :-) I was kind of expecting someone to jump on that. Feature freeze doesn't apply to new packages in Fedora Extras till test 4. If installing a package by default from Fedora Extras requires a exception to the feature freeze please consider this as my exception request to release engineering. Rahul From jkeating at redhat.com Thu Mar 29 01:18:41 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 28 Mar 2007 21:18:41 -0400 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <460B1229.3050301@fedoraproject.org> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <1175129253.3034.0.camel@aglarond.local> <460B1229.3050301@fedoraproject.org> Message-ID: <200703282118.42105.jkeating@redhat.com> On Wednesday 28 March 2007 21:11:05 Rahul Sundaram wrote: > I was kind of expecting someone to jump on that. Feature freeze doesn't > apply to new packages in Fedora Extras till test 4. If installing a > package by default from Fedora Extras requires a exception to the > feature freeze please consider this as my exception request to release > engineering. I for one would not approve this. I feel it would have needed to see full use from at least test1 time frame to be considered for enabled by default for a 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 jwboyer at jdub.homelinux.org Thu Mar 29 01:33:36 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 28 Mar 2007 20:33:36 -0500 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <200703282118.42105.jkeating@redhat.com> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <1175129253.3034.0.camel@aglarond.local> <460B1229.3050301@fedoraproject.org> <200703282118.42105.jkeating@redhat.com> Message-ID: <1175132017.32658.13.camel@vader.jdub.homelinux.org> On Wed, 2007-03-28 at 21:18 -0400, Jesse Keating wrote: > On Wednesday 28 March 2007 21:11:05 Rahul Sundaram wrote: > > I was kind of expecting someone to jump on that. Feature freeze doesn't > > apply to new packages in Fedora Extras till test 4. If installing a > > package by default from Fedora Extras requires a exception to the > > feature freeze please consider this as my exception request to release > > engineering. > > I for one would not approve this. I feel it would have needed to see full use > from at least test1 time frame to be considered for enabled by default for a > release. Agreed. josh From mhw at WittsEnd.com Thu Mar 29 01:44:29 2007 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Wed, 28 Mar 2007 21:44:29 -0400 Subject: fc6 gaim update is BROKEN! In-Reply-To: <460AE9EA.7090001@redhat.com> References: <460ACF1C.7070401@gmail.com> <460AD1E4.4060405@redhat.com> <460AE9EA.7090001@redhat.com> Message-ID: <1175132669.7554.12.camel@canyon.wittsend.com> On Wed, 2007-03-28 at 18:19 -0400, Warren Togami wrote: > Jon Escombe wrote: > > Warren Togami redhat.com> writes: > > > >> I'm sorry that this isn't working out for you. It worked very well for > >> me and a few other testers. Nobody complained about these problems > >> about this version sitting in rawhide for quite a while now. > > > > Just one small issue to add, this update segfaulted for me due to a clash with > > the beta5 version of gaim-meanwhile that's still in extras. Possibly ought to be > > a dependancy somewhere that required an update to the plugins too? > > > > Appreciate that this would be hard to spot unless you actually use the meanwhile > > plugin, so not really complaining, just fyi (& hoping for an updated plugin at > > some point ;) > > > > Thanks, > > Jon. > gaim-meanwhile as a separate package will disappear when the distro > merges, because then libmeanwhile will be available for gaim to build > against. That's nice but, in the meanwhile (gag - sorry), we're screwed? I just suddenly slammed into gaim segfaulting and went searching and found the previous message. I can now confirm that, once I removed gaim-meanwhile and gaim-meanwhile-ibm (some internal configs for IBM people), gaim now comes up clean. But I don't have access to my Sametime accounts, now. Which means I've got to get sanity (a standalone Sametime client) up and configured until this bolux gets shot and straightened out. It's broken right now. I guess it needs to be punted over to the Extras folks to straighten out. I don't see anything on that list as of yet (adding a cross post - sorry). Has this been filed in bugzilla for gaim-meanwhile in the meantime? > Warren Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Thu Mar 29 01:47:48 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 28 Mar 2007 20:47:48 -0500 Subject: fc6 gaim update is BROKEN! In-Reply-To: <1175132669.7554.12.camel@canyon.wittsend.com> References: <460ACF1C.7070401@gmail.com> <460AD1E4.4060405@redhat.com> <460AE9EA.7090001@redhat.com> <1175132669.7554.12.camel@canyon.wittsend.com> Message-ID: <1175132868.32658.15.camel@vader.jdub.homelinux.org> On Wed, 2007-03-28 at 21:44 -0400, Michael H. Warfield wrote: > On Wed, 2007-03-28 at 18:19 -0400, Warren Togami wrote: > > Jon Escombe wrote: > > > Warren Togami redhat.com> writes: > > > > > >> I'm sorry that this isn't working out for you. It worked very well for > > >> me and a few other testers. Nobody complained about these problems > > >> about this version sitting in rawhide for quite a while now. > > > > > > Just one small issue to add, this update segfaulted for me due to a clash with > > > the beta5 version of gaim-meanwhile that's still in extras. Possibly ought to be > > > a dependancy somewhere that required an update to the plugins too? > > > > > > Appreciate that this would be hard to spot unless you actually use the meanwhile > > > plugin, so not really complaining, just fyi (& hoping for an updated plugin at > > > some point ;) > > > > > > Thanks, > > > Jon. > > > gaim-meanwhile as a separate package will disappear when the distro > > merges, because then libmeanwhile will be available for gaim to build > > against. > > That's nice but, in the meanwhile (gag - sorry), we're screwed? I just > suddenly slammed into gaim segfaulting and went searching and found the > previous message. I can now confirm that, once I removed gaim-meanwhile > and gaim-meanwhile-ibm (some internal configs for IBM people), gaim now > comes up clean. But I don't have access to my Sametime accounts, now. > Which means I've got to get sanity (a standalone Sametime client) up and > configured until this bolux gets shot and straightened out. It's broken > right now. I already said I was fixing it. > > I guess it needs to be punted over to the Extras folks to straighten > out. I don't see anything on that list as of yet (adding a cross post - > sorry). Has this been filed in bugzilla for gaim-meanwhile in the > meantime? No, but I'm fixing it. josh From mhw at WittsEnd.com Thu Mar 29 02:02:29 2007 From: mhw at WittsEnd.com (Michael H. Warfield) Date: Wed, 28 Mar 2007 22:02:29 -0400 Subject: fc6 gaim update is BROKEN! In-Reply-To: <1175132868.32658.15.camel@vader.jdub.homelinux.org> References: <460ACF1C.7070401@gmail.com> <460AD1E4.4060405@redhat.com> <460AE9EA.7090001@redhat.com> <1175132669.7554.12.camel@canyon.wittsend.com> <1175132868.32658.15.camel@vader.jdub.homelinux.org> Message-ID: <1175133749.7554.15.camel@canyon.wittsend.com> On Wed, 2007-03-28 at 20:47 -0500, Josh Boyer wrote: : > I already said I was fixing it. Sorry... Messages crossed in the E-Mail and I didn't see it. Thx! > > > > I guess it needs to be punted over to the Extras folks to straighten > > out. I don't see anything on that list as of yet (adding a cross post - > > sorry). Has this been filed in bugzilla for gaim-meanwhile in the > > meantime? > No, but I'm fixing it. Many Thx... > josh Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw at WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Thu Mar 29 02:23:29 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 28 Mar 2007 21:23:29 -0500 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <200703281934.06162.jkeating@redhat.com> References: <200703281934.06162.jkeating@redhat.com> Message-ID: <1175135009.3741.13.camel@localhost.localdomain> On Wed, 2007-03-28 at 19:34 -0400, Jesse Keating wrote: > In our buildsystem we use a 'buildsys-macros' package that defines some things > during the package builds, like the definition of %{dist}, and of %{fedora} > or %{rhel}. Now we're talking about adding even more macros to add > convenience for packagers that are packaging the same thing for multiple > Fedora releases and RHEL releases (Hurray EPEL!). > > However, with more of these macros in use, the usage case of rebuilding the > srpms on your local system starts to get harder, as these macros will be > undefined and you'll have interesting results. Perhaps surprising results. > I propose we ship these macros in something like redhat-rpm-config for each > release, so that when somebody is rebuilding a package on their system, the > macros are defined correctly for whatever release they are running. If they > are rebuilding for another release/distribution, they really should be using > mock, and having redhat-rpm-config define the right things within their mock > chroot. > > In the past I remember there being resistance to shipping these on the > installed system, however my Test3 addled brain is not able to recall what > those are. Are there any differing opinions on this matter, anybody that > disagrees with me? I'd love to hear it and thought out reasons against > taking the step. FWIW, I think this is a good idea. ~spot From jwilson at redhat.com Thu Mar 29 02:29:02 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 28 Mar 2007 22:29:02 -0400 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <1175135009.3741.13.camel@localhost.localdomain> References: <200703281934.06162.jkeating@redhat.com> <1175135009.3741.13.camel@localhost.localdomain> Message-ID: <460B246E.2030200@redhat.com> Tom "spot" Callaway wrote: > On Wed, 2007-03-28 at 19:34 -0400, Jesse Keating wrote: >> In our buildsystem we use a 'buildsys-macros' package that defines some things >> during the package builds, like the definition of %{dist}, and of %{fedora} >> or %{rhel}. Now we're talking about adding even more macros to add >> convenience for packagers that are packaging the same thing for multiple >> Fedora releases and RHEL releases (Hurray EPEL!). >> >> However, with more of these macros in use, the usage case of rebuilding the >> srpms on your local system starts to get harder, as these macros will be >> undefined and you'll have interesting results. Perhaps surprising results. >> I propose we ship these macros in something like redhat-rpm-config for each >> release, so that when somebody is rebuilding a package on their system, the >> macros are defined correctly for whatever release they are running. If they >> are rebuilding for another release/distribution, they really should be using >> mock, and having redhat-rpm-config define the right things within their mock >> chroot. >> >> In the past I remember there being resistance to shipping these on the >> installed system, however my Test3 addled brain is not able to recall what >> those are. Are there any differing opinions on this matter, anybody that >> disagrees with me? I'd love to hear it and thought out reasons against >> taking the step. > > FWIW, I think this is a good idea. I like it too. I can think of at least one popular 3rd-party repo that gets knocked from time to time because people can't rebuild many of its packages w/o hunting down some macros... -- Jarod Wilson jwilson at redhat.com From jwboyer at jdub.homelinux.org Thu Mar 29 02:27:55 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 28 Mar 2007 21:27:55 -0500 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <200703281934.06162.jkeating@redhat.com> References: <200703281934.06162.jkeating@redhat.com> Message-ID: <1175135276.32658.17.camel@vader.jdub.homelinux.org> On Wed, 2007-03-28 at 19:34 -0400, Jesse Keating wrote: > In our buildsystem we use a 'buildsys-macros' package that defines some things > during the package builds, like the definition of %{dist}, and of %{fedora} > or %{rhel}. Now we're talking about adding even more macros to add > convenience for packagers that are packaging the same thing for multiple > Fedora releases and RHEL releases (Hurray EPEL!). > > However, with more of these macros in use, the usage case of rebuilding the > srpms on your local system starts to get harder, as these macros will be > undefined and you'll have interesting results. Perhaps surprising results. > I propose we ship these macros in something like redhat-rpm-config for each > release, so that when somebody is rebuilding a package on their system, the > macros are defined correctly for whatever release they are running. If they > are rebuilding for another release/distribution, they really should be using > mock, and having redhat-rpm-config define the right things within their mock > chroot. > > In the past I remember there being resistance to shipping these on the > installed system, however my Test3 addled brain is not able to recall what > those are. Are there any differing opinions on this matter, anybody that > disagrees with me? I'd love to hear it and thought out reasons against > taking the step. I like this. josh From mattdm at mattdm.org Thu Mar 29 02:36:14 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 28 Mar 2007 22:36:14 -0400 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <200703281934.06162.jkeating@redhat.com> References: <200703281934.06162.jkeating@redhat.com> Message-ID: <20070329023614.GA26314@jadzia.bu.edu> On Wed, Mar 28, 2007 at 07:34:05PM -0400, Jesse Keating wrote: > However, with more of these macros in use, the usage case of rebuilding the > srpms on your local system starts to get harder, as these macros will be > undefined and you'll have interesting results. Perhaps surprising results. > I propose we ship these macros in something like redhat-rpm-config for each > release, so that when somebody is rebuilding a package on their system, the > macros are defined correctly for whatever release they are running. If they > are rebuilding for another release/distribution, they really should be using > mock, and having redhat-rpm-config define the right things within their mock > chroot. How about making them be "fc7.local" or "fc7.$(hostname)"? I find it really convenient to be able to distinguish between locally-built and official packages. I know I can do "rpm -q --qf '%{buildhost}\n'", so it's not that big of a deal, but it's nice to have the information more visible. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From tcallawa at redhat.com Thu Mar 29 02:57:41 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 28 Mar 2007 21:57:41 -0500 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <20070329023614.GA26314@jadzia.bu.edu> References: <200703281934.06162.jkeating@redhat.com> <20070329023614.GA26314@jadzia.bu.edu> Message-ID: <1175137061.3741.18.camel@localhost.localdomain> On Wed, 2007-03-28 at 22:36 -0400, Matthew Miller wrote: > On Wed, Mar 28, 2007 at 07:34:05PM -0400, Jesse Keating wrote: > > However, with more of these macros in use, the usage case of rebuilding the > > srpms on your local system starts to get harder, as these macros will be > > undefined and you'll have interesting results. Perhaps surprising results. > > I propose we ship these macros in something like redhat-rpm-config for each > > release, so that when somebody is rebuilding a package on their system, the > > macros are defined correctly for whatever release they are running. If they > > are rebuilding for another release/distribution, they really should be using > > mock, and having redhat-rpm-config define the right things within their mock > > chroot. > > How about making them be "fc7.local" or "fc7.$(hostname)"? I find it really > convenient to be able to distinguish between locally-built and official > packages. > > I know I can do "rpm -q --qf '%{buildhost}\n'", so it's not that big of a > deal, but it's nice to have the information more visible. Keep in mind that you can always override these locally. :) ~spot From mattdm at mattdm.org Thu Mar 29 03:02:51 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 28 Mar 2007 23:02:51 -0400 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <1175137061.3741.18.camel@localhost.localdomain> References: <200703281934.06162.jkeating@redhat.com> <20070329023614.GA26314@jadzia.bu.edu> <1175137061.3741.18.camel@localhost.localdomain> Message-ID: <20070329030251.GA28855@jadzia.bu.edu> On Wed, Mar 28, 2007 at 09:57:41PM -0500, Tom spot Callaway wrote: > > How about making them be "fc7.local" or "fc7.$(hostname)"? I find it really > > convenient to be able to distinguish between locally-built and official > > packages. > > I know I can do "rpm -q --qf '%{buildhost}\n'", so it's not that big of a > > deal, but it's nice to have the information more visible. > Keep in mind that you can always override these locally. :) I do, and will. :) I'm mostly thinking of it as a handy thing to have in bug reports. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From buildsys at fedoraproject.org Thu Mar 29 03:03:46 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Wed, 28 Mar 2007 23:03:46 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-28 Message-ID: <20070329030346.8C04F152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras 6: 8 aumix-2.8-15.fc6 NEW clutter-0.2.2-4.fc6 ettercap-0.7.3-19.fc6 exaile-0.2.9-1.fc6 gaim-meanwhile-2.0.0-0.7.beta6.fc6 NEW gxine-0.5.11-3.fc6 libsexymm-0.1.9-2.fc6 viewvc-1.0.3-11.fc6 For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From jima at beer.tclug.org Thu Mar 29 03:13:59 2007 From: jima at beer.tclug.org (Jima) Date: Wed, 28 Mar 2007 22:13:59 -0500 (CDT) Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175132017.32658.13.camel@vader.jdub.homelinux.org> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <1175129253.3034.0.camel@aglarond.local> <460B1229.3050301@fedoraproject.org> <200703282118.42105.jkeating@redhat.com> <1175132017.32658.13.camel@vader.jdub.homelinux.org> Message-ID: On Wed, 28 Mar 2007, Josh Boyer wrote: > On Wed, 2007-03-28 at 21:18 -0400, Jesse Keating wrote: >> I for one would not approve this. I feel it would have needed to see full use >> from at least test1 time frame to be considered for enabled by default for a >> release. > > Agreed. I'm going to "me too" this, but add that I don't see any reason this couldn't be enabled by default on F8, assuming it gets polished and formalized in the meantime. IMO (and I suspect I'm not alone), this functionality came into the public eye way too suddenly to ship now, especially with the rather fatal bugs. I certainly do like the concept, though, and in the meanwhile may enable it on networks where I don't maintain a local mirror. Jima From pemboa at gmail.com Thu Mar 29 03:19:10 2007 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 28 Mar 2007 22:19:10 -0500 Subject: hplip: hp-toolbox advertising? In-Reply-To: <200703282040.48082.jkeating@redhat.com> References: <200703281926.37173.jkeating@redhat.com> <200703282040.48082.jkeating@redhat.com> Message-ID: <16de708d0703282019g7f362d7bm8aac65db2e6f6cad@mail.gmail.com> On 3/28/07, Jesse Keating wrote: > On Wednesday 28 March 2007 20:08:47 Kevin Kofler wrote: > > HP USB printers can be addressed by 2 ways: > > * the default CUPS usb:/ transport > > * the hplip hp:/ transport > > With the usb:/ transport, printing will work, but anything beyond that > > won't. (In particular, hp-toolbox doesn't list the printer if it's > > configured with a usb:/ URI.) > > I guess my point here is that how is an end user supposed to know this, when > it isn't integrated correctly into the tool set we're putting out for > managing printers on the desktop. When I said CUPS, i meant that generally, not specially using your browser on port 631. I was assuming that system-congig-printer interacts with CUPS. WIth those assumptions in place, once the daemon detects the printer, all you need to is add a printer, however you feel comfortable, and it should appear in the list of addable printers. No special magic. As I mentioned earler. All this happened for me in FC6 automatically upon installtion. -- Fedora Core 6 and proud From fedora at leemhuis.info Thu Mar 29 05:02:04 2007 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 29 Mar 2007 07:02:04 +0200 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <460B246E.2030200@redhat.com> References: <200703281934.06162.jkeating@redhat.com> <1175135009.3741.13.camel@localhost.localdomain> <460B246E.2030200@redhat.com> Message-ID: <460B484C.5070006@leemhuis.info> On 29.03.2007 04:29, Jarod Wilson wrote: > Tom "spot" Callaway wrote: >> On Wed, 2007-03-28 at 19:34 -0400, Jesse Keating wrote: >>> In our buildsystem we use a 'buildsys-macros' package that defines some things >>> during the package builds, like the definition of %{dist}, and of %{fedora} >>> or %{rhel}. Now we're talking about adding even more macros to add >>> convenience for packagers that are packaging the same thing for multiple >>> Fedora releases and RHEL releases (Hurray EPEL!). >>> >>> However, with more of these macros in use, the usage case of rebuilding the >>> srpms on your local system starts to get harder, as these macros will be >>> undefined and you'll have interesting results. Perhaps surprising results. >>> I propose we ship these macros in something like redhat-rpm-config for each >>> release, so that when somebody is rebuilding a package on their system, the >>> macros are defined correctly for whatever release they are running. If they >>> are rebuilding for another release/distribution, they really should be using >>> mock, and having redhat-rpm-config define the right things within their mock >>> chroot. >>> >>> In the past I remember there being resistance to shipping these on the >>> installed system, however my Test3 addled brain is not able to recall what >>> those are. Are there any differing opinions on this matter, anybody that >>> disagrees with me? I'd love to hear it and thought out reasons against >>> taking the step. >> FWIW, I think this is a good idea. > > I like it too. /me, too, for exactly this reason: > I can think of at least one popular 3rd-party repo that > gets knocked from time to time because people can't rebuild many of its > packages w/o hunting down some macros... CU thl From jdieter at gmail.com Thu Mar 29 05:18:05 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 29 Mar 2007 08:18:05 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <460B0B9C.9090901@fedoraproject.org> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> <460B0B9C.9090901@fedoraproject.org> Message-ID: <1175145485.23281.68.camel@jndwidescreen.lesbg.loc> On Thu, 2007-03-29 at 06:13 +0530, Rahul Sundaram wrote: > Jonathan Dieter wrote: > > > So yeah, I'm curious. Have you managed to do your update yet? If you > > have, what kind of savings did you see? > > The yum transaction failed with a unsigned gpg key error. Turned off gpg > key check and reran yum. Yum showed it was downloading 400+ MB but > proceeded to use the rpms build in the cache by presto in the previous > run. However it ended up showing now savings at all in the presto log. > You might want to check how the plugin is handling failed gpg checks. The plugin actually doesn't touch the gpg keys. By the time we get to the gpg check, the drpm should have already been assembled into the rpm. I'll try to track this down. > Did a fresh installation again with the default set of packages. Turned > off gpg key. Ran yum install yum first followed by yum update. Here is > the presto log. > > Download Size (without DRPM),Download Size (with DRPM),Percentage > Savings,Total Percentage Savings > 493372,132236,74,74 > 509267102,126959924,76,76 > Brilliant! For my connection, that's the difference between over four hours of downloading and just over an hour. > Pretty good savings and the system seems to be functioning as expected > in my limited testing. At this point it might be useful to put the > plugin in the repository atleast in the devel branch and get more > mirrors using the drpms for wider testing. We should consider having > this plugin enabled and installed by default for Fedora 7 release. I'm very honored that you think this is that close to being ready for a full release. I do see a few problems (aside from the obvious ones brought up by Jesse and Jeremy). The biggest one is that the createprestorepo script is very hacky at the moment. I think it will need a good bit of work before I would feel comfortable depending on it, and, as I've said, I'm focusing on the client at the moment. I think our best bet is to get it included into Extras (which may be a bit of a struggle if I'm to maintain it as I don't maintain any other packages). We should then talk with Fedora Infrastructure and see if they're interested in creating Presto repositories. If we don't run into any major problems during the F7/Rawhide timeline, maybe we can get it installed and enabled by default for F8. (Though I will definitely use it during the whole FC6/F7 timeline.) Currently, the drpms for updates use 637MB, while the drpms for extras is only using 65MB (though this would be a highly inaccurate number as I've only been mirroring extras for a week and they don't keep old rpms for very long). > > Rahul > Thanks again for the vote of confidence! Jonathan -------------- 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 Lam at Lam.pl Thu Mar 29 05:38:40 2007 From: Lam at Lam.pl (Leszek Matok) Date: Thu, 29 Mar 2007 07:38:40 +0200 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175145485.23281.68.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> <460B0B9C.9090901@fedoraproject.org> <1175145485.23281.68.camel@jndwidescreen.lesbg.loc> Message-ID: <1175146720.31404.6.camel@pensja.lam.pl> Dnia 29-03-2007, czw o godzinie 08:18 +0300, Jonathan Dieter napisa?(a): > If we don't run > into any major problems during the F7/Rawhide timeline, maybe we can get > it installed and enabled by default for F8. (Though I will definitely > use it during the whole FC6/F7 timeline.) I say make it a yum update in F7's updates-testing, making it easy to use (yum --enablerepo=updates-testing install yum) and making more eyes look at it. In two months from now (F7 GA) it will more than ready for updates-testing. Oh, and by the way, downloading full rpm in case of failed drpm rebuild works (happend to me with SDL-1.2.11-1.fc6). It should rebuild everything and never need a full package, but thanks anyhow! :) Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: To jest cz??? listu podpisana cyfrowo URL: From mschwendt.tmp0701.nospam at arcor.de Thu Mar 29 06:53:04 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 29 Mar 2007 08:53:04 +0200 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <200703281934.06162.jkeating@redhat.com> References: <200703281934.06162.jkeating@redhat.com> Message-ID: <20070329085304.6979ef6c.mschwendt.tmp0701.nospam@arcor.de> On Wed, 28 Mar 2007 19:34:05 -0400, Jesse Keating wrote: > In our buildsystem we use a 'buildsys-macros' package that defines some things > during the package builds, like the definition of %{dist}, and of %{fedora} > or %{rhel}. Now we're talking about adding even more macros to add > convenience for packagers that are packaging the same thing for multiple > Fedora releases and RHEL releases (Hurray EPEL!). > > However, with more of these macros in use, the usage case of rebuilding the > srpms on your local system starts to get harder, as these macros will be > undefined and you'll have interesting results. Perhaps surprising results. > I propose we ship these macros in something like redhat-rpm-config for each > release, so that when somebody is rebuilding a package on their system, the > macros are defined correctly for whatever release they are running. If they > are rebuilding for another release/distribution, they really should be using > mock, and having redhat-rpm-config define the right things within their mock > chroot. > > In the past I remember there being resistance to shipping these on the > installed system, however my Test3 addled brain is not able to recall what > those are. Are there any differing opinions on this matter, anybody that > disagrees with me? I'd love to hear it and thought out reasons against > taking the step. > > Thanks! Adding macro usage without adding the macros to "something like redhat-rpm-config" is not good. Historically, the plan has always been to add the macros to such a package. Hearing about "resistance" is news to me. It is already unexpected and inconvenient enough to need "--define fedora 6" or similar when rebuilding some packages. From valent.turkovic at gmail.com Thu Mar 29 07:15:37 2007 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Thu, 29 Mar 2007 09:15:37 +0200 Subject: Fedora 7 - features and obvious usability enhancements In-Reply-To: <460A42B6.60802@nicubunu.ro> References: <64b14b300703280124s6a0c8947uba60d52f57fcfb2c@mail.gmail.com> <460A42B6.60802@nicubunu.ro> Message-ID: <64b14b300703290015t4693c3cci3e847c3d1ca1f021@mail.gmail.com> First of all, thank you all that have answered. On 3/28/07, Nicu Buculei wrote: > I have the deskbar applet active on my computer but: > - it is a bit of a resource hog, which is not that good for a default; Ok, here I agree - it is a bit of a hog. But at least installing it should be the default, so users can easily enable it. > - in my opinion it is not so friendly with new users I demonstrated it to new users and they loved it. I just said that this is where they do all the they want to do with setting ther new linux desktop. So if they want to setup firewall trey just type "firewall" and as if by magic :) the firewall config shows up. Also for any other task like deskop background - just type "background". Ok, this should be tested more but by my experience it is really fenomenal. > About usability, you may look at the Usability SIG page in the wiki: > http://fedoraproject.org/wiki/Usability > Thank you. From lists at dresco.co.uk Thu Mar 29 05:44:14 2007 From: lists at dresco.co.uk (Jon Escombe) Date: Thu, 29 Mar 2007 05:44:14 +0000 (UTC) Subject: fc6 gaim update is BROKEN! References: <460ACF1C.7070401@gmail.com> <460AD1E4.4060405@redhat.com> <460AE9EA.7090001@redhat.com> <1175122518.32658.11.camel@vader.jdub.homelinux.org> Message-ID: Josh Boyer jdub.homelinux.org> writes: > > gaim-meanwhile as a separate package will disappear when the distro > > merges, because then libmeanwhile will be available for gaim to build > > against. > > Yes, thank $deity. > > Jon, the gaim-meanwhile segfault is actually my fault. I noticed it in > rawhide where it's fixed, but didn't see the latest FC-6 gaim update. > I'll try and get this fixed up ASAP. > > josh Thanks Josh, would be much appreciated. Regards, Jon. From denis at poolshark.org Thu Mar 29 08:10:00 2007 From: denis at poolshark.org (Denis Leroy) Date: Thu, 29 Mar 2007 10:10:00 +0200 Subject: hplip: hp-toolbox advertising? In-Reply-To: <16de708d0703282019g7f362d7bm8aac65db2e6f6cad@mail.gmail.com> References: <200703281926.37173.jkeating@redhat.com> <200703282040.48082.jkeating@redhat.com> <16de708d0703282019g7f362d7bm8aac65db2e6f6cad@mail.gmail.com> Message-ID: <460B7458.5040602@poolshark.org> Arthur Pemberton wrote: > On 3/28/07, Jesse Keating wrote: >> On Wednesday 28 March 2007 20:08:47 Kevin Kofler wrote: >> > HP USB printers can be addressed by 2 ways: >> > * the default CUPS usb:/ transport >> > * the hplip hp:/ transport >> > With the usb:/ transport, printing will work, but anything beyond that >> > won't. (In particular, hp-toolbox doesn't list the printer if it's >> > configured with a usb:/ URI.) >> >> I guess my point here is that how is an end user supposed to know >> this, when >> it isn't integrated correctly into the tool set we're putting out for >> managing printers on the desktop. > > When I said CUPS, i meant that generally, not specially using your > browser on port 631. Going to http://localhost:631/, I can't help but notice that this page contains the trademarked logo of ESP as well as advertisement for their support and pro products :-) From pertusus at free.fr Thu Mar 29 08:23:01 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 29 Mar 2007 10:23:01 +0200 Subject: dropping autoconf dependency on imake In-Reply-To: <460A7A96.7050507@volny.cz> References: <460998DA.1000407@develer.com> <20070328142112.GA29731@tux.gsfc.nasa.gov> <460A7A96.7050507@volny.cz> Message-ID: <20070329082300.GA2830@free.fr> On Wed, Mar 28, 2007 at 04:24:22PM +0200, Miloslav Trmac wrote: > kodis at mail630.gsfc.nasa.gov napsal(a): > > On Wed, Mar 28, 2007 at 12:21:14AM +0200, Bernardo Innocenti wrote: > >> Why does [autoconf] need imake? Can we get rid of it? > > - Macro: AC_PATH_X > > Try to locate the X Window System include files and > > libraries. If the user gave the command line options > > `--x-includes=DIR' and `--x-libraries=DIR', use those > > directories. If either or both were not given, get the > > missing values by running `xmkmf' on a trivial `Imakefile' > > and examining the `Makefile' that it produces. > This means that the generated configure file needs imake, not that > autoconf needs imake. Indeed. Maybe it was needed for the tests? I'll reopen the merge review bug. -- Pat From wolfy at nobugconsulting.ro Thu Mar 29 08:31:03 2007 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 29 Mar 2007 11:31:03 +0300 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: <20070328195928.f097f071.mschwendt.tmp0701.nospam@arcor.de> References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <46097882.9030802@redhat.com> <64171.65.192.24.190.1175026507.squirrel@mail.jcomserv.net> <20070328174018.GF2483@tomservo.rh.rit.edu> <6514.65.192.24.190.1175103969.squirrel@mail.jcomserv.net> <20070328195928.f097f071.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <460B7947.8020505@nobugconsulting.ro> Michael Schwendt wrote: > On Wed, 28 Mar 2007 12:46:09 -0500 (CDT), Jon Ciesla wrote: > > >> If I add it to %files, when I build, it fails, as /usr/bin/ettercap does >> not exist. Is there a workaround? >> >> >>> After installing ettercap, nothing owns /usr/bin/ettercap, due to it >>> getting created by alternatives in the %post. >>> > > "touch" it in %install, include it in %files marked as %ghost, > > %files > ... > %ghost %{_bindir}/ettercap > > then display the files in your test-build (rpm --query --list ...). > > OK, I don't get it: [wolfy at wolfy ~]$ rpm -ql ssmtp --scripts postinstall scriptlet (using /bin/sh): /usr/sbin/alternatives --install /usr/sbin/sendmail mta /usr/sbin/sendmail.ssmtp 30 \ [other slave links removed] [etc stuff removed from paste] /usr/bin/mailq.ssmtp /usr/bin/newaliases.ssmtp /usr/sbin/sendmail.ssmtp /usr/sbin/ssmtp [wolfy at wolfy ~]$ rpm -qf /usr/sbin/sendmail sendmail-8.13.1-3.RHEL4.5.i386 ssmtp-2.61-11.1.el4.i386 There is no %ghost here... where does the difference towards ettercap come from, since I have used the same postinstall scriptlet ? From jacliburn at bellsouth.net Thu Mar 29 01:25:16 2007 From: jacliburn at bellsouth.net (Jay Cliburn) Date: Wed, 28 Mar 2007 20:25:16 -0500 Subject: rawhide report: 20070328 changes In-Reply-To: <200703282318.l2SNIOQf023334@hs20-bc2-6.build.redhat.com> References: <200703282318.l2SNIOQf023334@hs20-bc2-6.build.redhat.com> Message-ID: <20070328202516.753d30bd@osprey.hogchain.net> On Wed, 28 Mar 2007 19:18:24 -0400 buildsys at redhat.com wrote: > kernel-2.6.20-1.3024.fc7 > ------------------------ > * Wed Mar 28 2007 David Woodhouse > - Add Efika (mpc52xx) Ethernet driver > - Crappy workaround for sysfs/uevent problems (#227893) > - Fix IPv6 failure with NetworkManager (#234067) > > * Sun Mar 25 2007 Dave Jones > - 2.6.21-rc5 > > * Sun Mar 25 2007 Dave Jones > - 2.6.21-rc4-git11 I get an oops with this kernel when the r8169 module is modprobed on an x86_64 rawhide system with an Intel-based mainboard. The RTL8169 NIC is PCI card thrown into the system for testing purposes. I thought for sure I'd already seen this reported on lkml, but I can't seem to find it. Unable to handle kernel NULL pointer dereference at [] :r8169:rtl8169_rx_interrupt+0x5d/0x529 PGD 1d6bb067 PUD 1d6b9067 PMD 0 Oops: 0000 [1] SMP last sysfs file: /class/net/eth1/address CPU 1 Modules linked in: r8169 i915 drm w83627ehf hwmon i2c_isa eeprom nf_conntrack_nd Pid: 2689, comm: ip Not tainted 2.6.20-1.3024.fc7 #1 RIP: 0010:[] [] :r8169:rtl8169_rx_interrup9 RSP: 0018:ffff81003f73be10 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff81001d546000 RCX: ffffffff8020cb04 RDX: 0000000000000000 RSI: ffff81001d546900 RDI: ffff81001d546000 RBP: ffff81003f73be60 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: ffffffff80263d40 R12: ffff81001d546900 R13: 0000000000000000 R14: ffff81001d546900 R15: 00000000fffcb85d FS: 00002aaaaaac6820(0000) GS:ffff81003f783d58(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 000000001d623000 CR4: 00000000000006e0 Process ip (pid: 2689, threadinfo ffff81001d65a000, task ffff81001d680080) Stack: ffff81001d6807d8 ffff81001d546000 000000001d680080 0000000000000040 ffff81001d6807a0 ffff81001d546000 ffff81001d546000 ffff8100026281d0 ffff81001d546900 00000000fffcb85d ffff81003f73bec0 ffffffff883b6a10 Call Trace: [] :r8169:rtl8169_poll+0x45/0x203 [] net_rx_action+0xb0/0x1cf [] run_timer_softirq+0x1d0/0x1db [] :r8169:rtl8169_interrupt+0x0/0x207 [] __do_softirq+0x5f/0xe3 [] call_softirq+0x1c/0x28 [] do_softirq+0x3d/0xab [] irq_exit+0x4e/0x50 [] smp_apic_timer_interrupt+0x48/0x5a [] apic_timer_interrupt+0x6b/0x70 [] request_irq+0xb/0x11f [] request_irq+0xe3/0x11f [] :r8169:rtl8169_open+0x56/0x1d9 [] dev_open+0x37/0x79 [] dev_change_flags+0x5d/0x122 [] devinet_ioctl+0x259/0x5e9 [] inet_ioctl+0x71/0x8f [] sock_ioctl+0x1db/0x1fc [] do_ioctl+0x2a/0x77 [] vfs_ioctl+0x260/0x27d [] sys_ioctl+0x5f/0x82 [] tracesys+0xdc/0xe1 Code: 41 8b 5d 00 85 db 0f 88 f7 03 00 00 f7 c3 00 00 20 00 74 60 RIP [] :r8169:rtl8169_rx_interrupt+0x5d/0x529 RSP CR2: 0000000000000000 Kernel panic - not syncing: Aiee, killing interrupt handler! From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Mar 29 08:46:37 2007 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 29 Mar 2007 10:46:37 +0200 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <200703281934.06162.jkeating@redhat.com> References: <200703281934.06162.jkeating@redhat.com> Message-ID: <20070329104637.6163154e@python3.es.egwn.lan> Jesse Keating wrote : > I propose we ship these macros in something like redhat-rpm-config for each > release, so that when somebody is rebuilding a package on their system, the > macros are defined correctly for whatever release they are running. If they > are rebuilding for another release/distribution, they really should be using > mock, and having redhat-rpm-config define the right things within their mock > chroot. I'm all for it too! :-) 1) They'll be harmless for spec files not making any use of them. 2) They'll make the right thing happen for the spec files that do. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 6 (Zod) - Linux kernel 2.6.20-1.2933.fc6 Load : 2.22 1.66 1.08 From pertusus at free.fr Thu Mar 29 08:47:03 2007 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 29 Mar 2007 10:47:03 +0200 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: <460B7947.8020505@nobugconsulting.ro> References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <46097882.9030802@redhat.com> <64171.65.192.24.190.1175026507.squirrel@mail.jcomserv.net> <20070328174018.GF2483@tomservo.rh.rit.edu> <6514.65.192.24.190.1175103969.squirrel@mail.jcomserv.net> <20070328195928.f097f071.mschwendt.tmp0701.nospam@arcor.de> <460B7947.8020505@nobugconsulting.ro> Message-ID: <20070329084703.GB2830@free.fr> On Thu, Mar 29, 2007 at 11:31:03AM +0300, Manuel Wolfshant wrote: > OK, I don't get it: > [wolfy at wolfy ~]$ rpm -ql ssmtp --scripts > postinstall scriptlet (using /bin/sh): > /usr/sbin/alternatives --install /usr/sbin/sendmail mta > /usr/sbin/sendmail.ssmtp 30 \ > [other slave links removed] > [etc stuff removed from paste] > /usr/bin/mailq.ssmtp > /usr/bin/newaliases.ssmtp > /usr/sbin/sendmail.ssmtp > /usr/sbin/ssmtp > > [wolfy at wolfy ~]$ rpm -qf /usr/sbin/sendmail > sendmail-8.13.1-3.RHEL4.5.i386 > ssmtp-2.61-11.1.el4.i386 > > There is no %ghost here... where does the difference towards ettercap > come from, since I have used the same postinstall scriptlet ? Maybe it comes from the explicit Provides: Provides: MTA smtpdaemon %{_sbindir}/sendmail -- Pat From markg85 at gmail.com Thu Mar 29 09:19:12 2007 From: markg85 at gmail.com (Mark) Date: Thu, 29 Mar 2007 11:19:12 +0200 Subject: Is it a bug or intentionally done? In-Reply-To: <460AFF49.7020302@web.de> References: <6e24a8e80703281255w1cbcedb3ve4edc0b9fa95b600@mail.gmail.com> <1175112082.4641.70.camel@localhost.localdomain> <460AF574.1000102@cox.net> <460AFF49.7020302@web.de> Message-ID: <6e24a8e80703290219j650d98c6k2b5a5cd232e4172f@mail.gmail.com> hehe so many ways to make a screenshot :P thanx for all the information. 2007/3/29, Andr? Kelpe : > > Greg Morgan schrieb: > > 1.) Or go to Applications > Accessories > Take Screenshot > right click > > and use either add to panel or add to desktop. The panel may make screen > > shots easier for menus. > > 2.) Right click on the new icon> select properties. In the command box > > after gnome-screenshot add --delay=seconds i.e. > > gnome-screenshot --delay=3 > Wow, that's a complicated way for doing just a > > $ sleep 3; import -window root shot.png > > Andr? > > -- > 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 mschwendt.tmp0701.nospam at arcor.de Thu Mar 29 09:54:07 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 29 Mar 2007 11:54:07 +0200 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: <20070329084703.GB2830@free.fr> References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <46097882.9030802@redhat.com> <64171.65.192.24.190.1175026507.squirrel@mail.jcomserv.net> <20070328174018.GF2483@tomservo.rh.rit.edu> <6514.65.192.24.190.1175103969.squirrel@mail.jcomserv.net> <20070328195928.f097f071.mschwendt.tmp0701.nospam@arcor.de> <460B7947.8020505@nobugconsulting.ro> <20070329084703.GB2830@free.fr> Message-ID: <20070329115407.ae449308.mschwendt.tmp0701.nospam@arcor.de> On Thu, 29 Mar 2007 10:47:03 +0200, Patrice Dumas wrote: > On Thu, Mar 29, 2007 at 11:31:03AM +0300, Manuel Wolfshant wrote: > > OK, I don't get it: > > [wolfy at wolfy ~]$ rpm -ql ssmtp --scripts > > postinstall scriptlet (using /bin/sh): > > /usr/sbin/alternatives --install /usr/sbin/sendmail mta > > /usr/sbin/sendmail.ssmtp 30 \ > > [other slave links removed] > > [etc stuff removed from paste] > > /usr/bin/mailq.ssmtp > > /usr/bin/newaliases.ssmtp > > /usr/sbin/sendmail.ssmtp > > /usr/sbin/ssmtp > > > > [wolfy at wolfy ~]$ rpm -qf /usr/sbin/sendmail > > sendmail-8.13.1-3.RHEL4.5.i386 > > ssmtp-2.61-11.1.el4.i386 > > > > There is no %ghost here... where does the difference towards ettercap > > come from, since I have used the same postinstall scriptlet ? > > Maybe it comes from the explicit Provides: > > Provides: MTA smtpdaemon %{_sbindir}/sendmail Yes, it does. $ rpm -q --whatprovides /usr/bin/mailq sendmail-8.13.8-2 $ rpm -ql sendmail |grep mailq /usr/bin/mailq.sendmail /usr/share/man/man1/mailq.sendmail.1.gz Making a file %ghost, when multiple packages use the alternatives system for a shared set of paths, would be wrong. From buildsys at redhat.com Thu Mar 29 10:25:19 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Thu, 29 Mar 2007 06:25:19 -0400 Subject: rawhide report: 20070329 changes Message-ID: <200703291025.l2TAPJT3026528@hs20-bc2-6.build.redhat.com> Updated Packages: ElectricFence-2.2.2-23 ---------------------- * Wed Mar 28 2007 Petr Machata - 2.2.2-23 - Detect for EF_DISABLE_BANNER env. var before printing out the banner. (Patch adapted from Debian repositories.) - Resolves: #233702 anaconda-11.2.0.41-1 -------------------- * Wed Mar 28 2007 Chris Lumens - 11.2.0.41-1 - Fix partitioning under kickstart when using clearpart (#232936). - Add padding on the device stripe graph (#217294). - Fix probing RAID superblocks (#172648, #208970, #215231). - Support using hal locking on the live CD (katzj, #231201). - Fix text install UI flow (dcantrell). - Add IPv4 address validation for s390 (dcantrell, #234152). - Don't unnecessarily run DHCP on the add repos screen (dcantrell, #232512). - Netlink cache cleanups (dcantrell). - Package installation progress UI cleanups (dcantrell). - Only probe for network devices with loaded modules (dcantrell, #233507). - Better error handling on unprintable filesystem labels (#191679). - Live CD and lowres UI fixes (katzj). - Exit if the close button is clicked (katzj, #231775). - Always display an IP address in the VNC info message (#231934). - Handle dual IP stack manual configuration correctly (dcantrell, #232690). - zlib has moved (katzj). - Write out /etc/sysconfig/desktop file if there's a default (katzj, #233472). aspell-cs-50:20040614-1.fc7 --------------------------- * Wed Mar 28 2007 Ivana Varekova - 50:20040614-1 - update to 20040614 - use configure script to create Makefile aspell-cy-50:0.50-6.fc7 ----------------------- * Wed Mar 28 2007 Ivana Varekova - 50:0.50-6 - use configure script to create Makefile aspell-da-50:1.4.42-1.fc7 ------------------------- * Wed Mar 28 2007 Ivana Varekova - 50:1.4.42-1 - use configure script to create Makefile - update to 1.4.42 autofs-1:5.0.1-6 ---------------- * Thu Mar 29 2007 Ian Kent - 5.0.1-6 - fix directory creation for browse mounts. - fix wildcard map handling and improve nsswitch source map update. dbus-1.0.2-2.fc7 ---------------- * Wed Mar 28 2007 Matthias Clasen - 1.0.2-2 - Require pkgconfig in the -devel package * Sun Mar 25 2007 Matthias Clasen - 1.0.2-1 - Update to 1.0.2 - Drop obsolete patches - Fix directory ownership issues (#233753) * Fri Dec 15 2006 David Zeuthen - 1.0.1-3.fc7 - CVE-2006-6107: D-Bus denial of service fast-user-switch-applet-2.17.4-3.fc7 ------------------------------------ * Wed Mar 28 2007 Matthias Clasen 2.17.4-3 - Fix the startx patch to actually work when gdm is present fedora-logos-6.0.97-2.fc7 ------------------------- * Wed Mar 28 2007 Matthias Clasen 6.0.97-2 - Save some space by linking backgrounds gnome-applets-1:2.18.0-3.fc7 ---------------------------- * Wed Mar 28 2007 Matthias Clasen - 1:2.18.0-3 - Remove non-XKB support files to save space gnome-games-1:2.18.0-3.fc7 -------------------------- * Wed Mar 28 2007 Matthias Clasen - 1:2.18.0-3 - Split of gnome-games-extra-data as a separate package - Correct the License tag gtk2-2.10.11-3.fc7 ------------------ * Wed Mar 28 2007 Matthias Clasen - 1.10.11-3 - Support raw printers kernel-2.6.20-1.3025.fc7 ------------------------ * Wed Mar 28 2007 Dave Jones - Update deferred timer patch. * Wed Mar 28 2007 David Woodhouse - Add Efika (mpc52xx) Ethernet driver - Crappy workaround for sysfs/uevent problems (#227893) - Fix IPv6 failure with NetworkManager (#234067) * Sun Mar 25 2007 Dave Jones - 2.6.21-rc5 libsepol-2.0.1-2.fc7 -------------------- * Wed Mar 28 2007 Dan Walsh 2.0.1-2 * Wed Feb 7 2007 Dan Walsh 2.0.1-1 - Upgrade to latest from NSA * Merged libsepol segfault fix from Stephen Smalley for when sensitivities are required but not present in the base. * Merged patch to add errcodes.h to libsepol by Karl MacMillan. * Fri Jan 19 2007 Dan Walsh 1.16.0-1 - Upgrade to latest from NSA * Updated version for stable branch. * Tue Dec 12 2006 Adam Jackson 1.15.3-1 - Add dist tag and rebuild, fixes 6 to 7 upgrades. libwnck-2.18.0-2.fc7 -------------------- * Wed Mar 28 2007 Kristian H??gsberg - 2.18.0-2 - Add compiz integration patches from GNOME #352383: - libwnck-2.18.0-appearance.patch - libwnck-2.18.0-viewport.patch - libwnck-2.18.0-above.patch lucene-0:1.4.3-1jpp.17 ---------------------- * Tue Mar 27 2007 Deepak Bhole 1.4.3-1jpp.17 - Added unowned directory to files list. bz# 233878. mtx-1.3.11-1.fc7 ---------------- * Wed Mar 28 2007 Jindrich Novy 1.3.11-1 - update to 1.3.11 (adds new scsieject utility, bugfixes) - sync nostrip patch redhat-artwork-5.0.12-2.fc7 --------------------------- * Wed Mar 28 2007 Matthias Clasen 5.0.12-2 - Save some space by linking identical backgrounds rhythmbox-0.9.8-4.fc7 --------------------- * Wed Mar 28 2007 - Bastien Nocera - 0.9.8-4.fc7 - Add upstream patch for bug 234216 ruby-1.8.6-2.fc7 ---------------- * Wed Mar 28 2007 Akira TAGOH - 1.8.6-2 - Fix search path breakage. (#234029) samba-0:3.0.24-8.fc7 -------------------- * Wed Mar 28 2007 Simo Sorce 3.0.24-8.fc7 - fix for bug #176649 * Mon Mar 26 2007 Simo Sorce - remove patch for bug 106483 as it introduces a new bug that prevents the use of a credentials file with the smbclient tar command - move the samba private dir from being the same as the config dir (/etc/samba) to /var/lib/samba/private * Mon Mar 26 2007 Simo Sorce 3.0.24-7.fc7 - make winbindd start earlier in the init process, at the same time ypbind is usually started as well - add a sepoarate init script for nmbd called nmb, we need to be able to restart nmbd without dropping al smbd connections unnecessarily system-config-display-1.0.50-1.fc7 ---------------------------------- * Wed Mar 28 2007 Jeremy Katz - 1.0.50-1 - start X server with a black background; we don't need xsri anymore system-config-soundcard-2.0.6-3.fc7 ----------------------------------- * Wed Mar 28 2007 Jeremy Katz - 2.0.6-3 - sox doesn't get used anymore; don't require it wordtrans-1:1.1-0.2.pre13.fc7 ----------------------------- * Wed Mar 28 2007 Than Ngo - 1:1.1-0.2.pre13.fc7 - apply patch to fix crash in kwordtrans xorg-x11-drv-tseng-1.1.0-5.fc7 ------------------------------ * Wed Mar 28 2007 Adam Jackson 1.1.0-5 - tseng-1.1.0-defaultdepth.patch: Use system default depth. Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.13-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.13-1.fc7.s390 requires kernel >= 0:2.6.9-11 From jwboyer at jdub.homelinux.org Thu Mar 29 10:40:22 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 29 Mar 2007 05:40:22 -0500 Subject: rawhide report: 20070328 changes In-Reply-To: <20070328202516.753d30bd@osprey.hogchain.net> References: <200703282318.l2SNIOQf023334@hs20-bc2-6.build.redhat.com> <20070328202516.753d30bd@osprey.hogchain.net> Message-ID: <1175164822.32658.22.camel@vader.jdub.homelinux.org> On Wed, 2007-03-28 at 20:25 -0500, Jay Cliburn wrote: > On Wed, 28 Mar 2007 19:18:24 -0400 > buildsys at redhat.com wrote: > > > kernel-2.6.20-1.3024.fc7 > > ------------------------ > > * Wed Mar 28 2007 David Woodhouse > > - Add Efika (mpc52xx) Ethernet driver > > - Crappy workaround for sysfs/uevent problems (#227893) > > - Fix IPv6 failure with NetworkManager (#234067) > > > > * Sun Mar 25 2007 Dave Jones > > - 2.6.21-rc5 > > > > * Sun Mar 25 2007 Dave Jones > > - 2.6.21-rc4-git11 > > I get an oops with this kernel when the r8169 module is modprobed on > an x86_64 rawhide system with an Intel-based mainboard. The RTL8169 > NIC is PCI card thrown into the system for testing purposes. > > I thought for sure I'd already seen this reported on lkml, but I can't > seem to find it. Bugzilla it this time so it doesn't get lost again please. josh From jdieter at gmail.com Thu Mar 29 10:41:11 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 29 Mar 2007 13:41:11 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <460B0B9C.9090901@fedoraproject.org> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> <460B0B9C.9090901@fedoraproject.org> Message-ID: <1175164871.23281.75.camel@jndwidescreen.lesbg.loc> On Thu, 2007-03-29 at 06:13 +0530, Rahul Sundaram wrote: > The yum transaction failed with a unsigned gpg key error. Turned off gpg > key check and reran yum. Yum showed it was downloading 400+ MB but > proceeded to use the rpms build in the cache by presto in the previous > run. However it ended up showing now savings at all in the presto log. > You might want to check how the plugin is handling failed gpg checks. Okay, I found the problem. Presto was telling yum the package was local after successfully building the rpm, but yum will not import any gpg keys for local packages. Now presto 0.3.1 doesn't tell yum the package is local, but yum checks the local path anyway and won't redownload an rpm that already exists locally. It will also ask to import the public gpg key, just like it does without presto. Thanks for the bug report. Jonathan -------------- 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 jkeating at redhat.com Thu Mar 29 10:55:53 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 29 Mar 2007 06:55:53 -0400 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <20070329085304.6979ef6c.mschwendt.tmp0701.nospam@arcor.de> References: <200703281934.06162.jkeating@redhat.com> <20070329085304.6979ef6c.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <200703290655.54021.jkeating@redhat.com> On Thursday 29 March 2007 02:53:04 Michael Schwendt wrote: > Adding macro usage without adding the macros to "something like > redhat-rpm-config" is not good. > > Historically, the plan has always been to add the macros to such a > package. Hearing about "resistance" is news to me. > > It is already unexpected and inconvenient enough to need "--define fedora > 6" or similar when rebuilding some packages. I see criticism here for how we use the buildsystem, but I don't see an actual opinion as to making these macros work on the installed system. I assume from your last sentence that you're in favor, but I'd rather not make assumptions. -- 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 kagesenshi.87 at gmail.com Thu Mar 29 11:41:37 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Thu, 29 Mar 2007 19:41:37 +0800 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175164871.23281.75.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> <460B0B9C.9090901@fedoraproject.org> <1175164871.23281.75.camel@jndwidescreen.lesbg.loc> Message-ID: Any chance for presto to be used together with reposync from yum-utils?? I'm maintaining a repository within my university LAN ... the network is "evil" (2MB size limit for http post/get, only post/get port 80 and tcp connect port 443 allowed) ... I managed to get through the size limit and used reposync to sync my local mirror with updates,extras, livna and rawhide for my frens and new users.. having reposync with presto will surely help in this case .. ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? Universiti Teknologi PETRONAS ICT 2nd Year 1st Semester mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com ----------------------------------------------- From rdieter at math.unl.edu Thu Mar 29 11:51:57 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 29 Mar 2007 06:51:57 -0500 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <46097882.9030802@redhat.com> <64171.65.192.24.190.1175026507.squirrel@mail.jcomserv.net> <20070328174018.GF2483@tomservo.rh.rit.edu> <6514.65.192.24.190.1175103969.squirrel@mail.jcomserv.net> <20070328195928.f097f071.mschwendt.tmp0701.nospam@arcor.de> <460B7947.8020505@nobugconsulting.ro> <20070329084703.GB2830@free.fr> <20070329115407.ae449308.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt wrote: > Making a file %ghost, when multiple packages use the alternatives system > for a shared set of paths, would be wrong. I disagree, I've done it, and it works just fine. I've advocated that all alternatives-using-packages (particularly jpackage ones) use this technique. -- Rex From rc040203 at freenet.de Thu Mar 29 12:14:36 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 29 Mar 2007 14:14:36 +0200 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <200703290655.54021.jkeating@redhat.com> References: <200703281934.06162.jkeating@redhat.com> <20070329085304.6979ef6c.mschwendt.tmp0701.nospam@arcor.de> <200703290655.54021.jkeating@redhat.com> Message-ID: <1175170476.24401.133.camel@mccallum.corsepiu.local> On Thu, 2007-03-29 at 06:55 -0400, Jesse Keating wrote: > On Thursday 29 March 2007 02:53:04 Michael Schwendt wrote: > > Adding macro usage without adding the macros to "something like > > redhat-rpm-config" is not good. > > > > Historically, the plan has always been to add the macros to such a > > package. Hearing about "resistance" is news to me. > > > > It is already unexpected and inconvenient enough to need "--define fedora > > 6" or similar when rebuilding some packages. > > I see criticism here for how we use the buildsystem, but I don't see an actual > opinion as to making these macros work on the installed system. OK you want some critical remarks: - in a proper implementation, all "redhat" macros should be encapsulated into "target" files (/usr/lib/rpm/) - whether the build-sys macros are being merged into redhat-rpm-config doesn't matter much, because redhat-rpm-config already kills rpmbuild "--target" - All "vendor" macros are potentially harmful (Once they are in, you almost never can get rid of them). The buildsystem macros add further to this pollution. > I assume from your last sentence that you're in favor, but I'd rather not make > assumptions. Ralf From mschwendt.tmp0701.nospam at arcor.de Thu Mar 29 13:01:39 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 29 Mar 2007 15:01:39 +0200 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <46097882.9030802@redhat.com> <64171.65.192.24.190.1175026507.squirrel@mail.jcomserv.net> <20070328174018.GF2483@tomservo.rh.rit.edu> <6514.65.192.24.190.1175103969.squirrel@mail.jcomserv.net> <20070328195928.f097f071.mschwendt.tmp0701.nospam@arcor.de> <460B7947.8020505@nobugconsulting.ro> <20070329084703.GB2830@free.fr> <20070329115407.ae449308.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070329150139.22710ade.mschwendt.tmp0701.nospam@arcor.de> On Thu, 29 Mar 2007 06:51:57 -0500, Rex Dieter wrote: > Michael Schwendt wrote: > > > Making a file %ghost, when multiple packages use the alternatives system > > for a shared set of paths, would be wrong. > > I disagree, I've done it, and it works just fine. I've advocated that all > alternatives-using-packages (particularly jpackage ones) use this > technique. Now you've got N packages which pretend they own a file/symlink. But none of them does actually, since it's only a symlink that points into the alternatives config space. And it's only one of the packages that owns what the symlink may point to. The alternatives symlink is a configuration value and doesn't belong into any package. The admin could also point the symlink to something in /usr/local, and you don't want to remove his customisation when an rpm is uninstalled. From jwilson at redhat.com Thu Mar 29 13:04:35 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 29 Mar 2007 09:04:35 -0400 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <1175170476.24401.133.camel@mccallum.corsepiu.local> References: <200703281934.06162.jkeating@redhat.com> <20070329085304.6979ef6c.mschwendt.tmp0701.nospam@arcor.de> <200703290655.54021.jkeating@redhat.com> <1175170476.24401.133.camel@mccallum.corsepiu.local> Message-ID: <460BB963.803@redhat.com> Ralf Corsepius wrote: > - whether the build-sys macros are being merged into redhat-rpm-config > doesn't matter much, because redhat-rpm-config already kills rpmbuild > "--target" Huh? Worked just fine for me a few days ago to build i686 kernel rpms on an x86_64 host, using only the following: $ setarch i386 rpmbuild -bb --target i686 kernel-2.6.spec Are you referring to the fact you have to make a call to setarch to get it to fully do the right thing? -- Jarod Wilson jarod at wilsonet.com From rdieter at math.unl.edu Thu Mar 29 13:02:49 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 29 Mar 2007 08:02:49 -0500 Subject: KDE-Live-CD: trim the fat References: <20070314011000.5b0cbcb8@localhost.localdomain> Message-ID: Sebastian Vahl wrote: > I've created a new basic layout for the cd: > http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/KDELiveCD > The size on todays rawhide is about 667 MB. > Please tell me which package should be added or removed. Playing a bit with the F7-test3-KDE-Live, here are some suggestions to consider: http://fedoraproject.org/wiki/RexDieter/F7t3-kde-trim-the-fat -- Rex From mschwendt.tmp0701.nospam at arcor.de Thu Mar 29 13:07:51 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 29 Mar 2007 15:07:51 +0200 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <200703290655.54021.jkeating@redhat.com> References: <200703281934.06162.jkeating@redhat.com> <20070329085304.6979ef6c.mschwendt.tmp0701.nospam@arcor.de> <200703290655.54021.jkeating@redhat.com> Message-ID: <20070329150751.1c57eb38.mschwendt.tmp0701.nospam@arcor.de> On Thu, 29 Mar 2007 06:55:53 -0400, Jesse Keating wrote: > On Thursday 29 March 2007 02:53:04 Michael Schwendt wrote: > > Adding macro usage without adding the macros to "something like > > redhat-rpm-config" is not good. > > > > Historically, the plan has always been to add the macros to such a > > package. Hearing about "resistance" is news to me. > > > > It is already unexpected and inconvenient enough to need "--define fedora > > 6" or similar when rebuilding some packages. > > I see criticism here for how we use the buildsystem, but I don't see an actual > opinion as to making these macros work on the installed system. > > I assume from your last sentence that you're in favor, but I'd rather not make > assumptions. Yes, I'm in favour of adding them. I find it ridiculous that Fedora spec files make use of macros, which are not available after installing the distribution. From rdieter at math.unl.edu Thu Mar 29 13:16:09 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 29 Mar 2007 08:16:09 -0500 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <46097882.9030802@redhat.com> <64171.65.192.24.190.1175026507.squirrel@mail.jcomserv.net> <20070328174018.GF2483@tomservo.rh.rit.edu> <6514.65.192.24.190.1175103969.squirrel@mail.jcomserv.net> <20070328195928.f097f071.mschwendt.tmp0701.nospam@arcor.de> <460B7947.8020505@nobugconsulting.ro> <20070329084703.GB2830@free.fr> <20070329115407.ae449308.mschwendt.tmp0701.nospam@arcor.de> <20070329150139.22710ade.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt wrote: > On Thu, 29 Mar 2007 06:51:57 -0500, Rex Dieter wrote: >> Michael Schwendt wrote: >> > Making a file %ghost, when multiple packages use the alternatives >> > system for a shared set of paths, would be wrong. >> I disagree, I've done it, and it works just fine. I've advocated that >> all alternatives-using-packages (particularly jpackage ones) use this >> technique. > Now you've got N packages which pretend they own a file/symlink. That's as it should be, imo. You would rather the file/symlink be unowned? > The alternatives symlink is a configuration value and doesn't belong into > any package. The admin could also point the symlink to something in > /usr/local, and you don't want to remove his customisation when an rpm is > uninstalled. Stuff done outside of rpm is done by a local admin at their own risk. -- Rex From gianluca.cecchi at gmail.com Thu Mar 29 13:28:11 2007 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 29 Mar 2007 15:28:11 +0200 Subject: Is it a bug or intentionally done? Message-ID: <561c252c0703290628ma7043b2o29260ee73dcee98f@mail.gmail.com> On Thu, 29 Mar 2007 11:19:12 +0200 Mark said: > hehe so many ways to make a screenshot :P > thanx for all the information. Or you can use the old days xwd command (included in xorg-x11-apps)... xwd -root -silent -out screenshot.xwd and then import in gimp or convert in pnm with xwdtopnm (in netpbm-progs) xwdtopnm screenshot.xwd > screenshot.pbm You can also dump other local/remote displays with the -display option.... Gianluca From icon at fedoraproject.org Thu Mar 29 13:45:48 2007 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Thu, 29 Mar 2007 09:45:48 -0400 Subject: Is it a bug or intentionally done? In-Reply-To: <561c252c0703290628ma7043b2o29260ee73dcee98f@mail.gmail.com> References: <561c252c0703290628ma7043b2o29260ee73dcee98f@mail.gmail.com> Message-ID: On 3/29/07, Gianluca Cecchi wrote: > > hehe so many ways to make a screenshot :P > > thanx for all the information. > > Or you can use the old days xwd command (included in xorg-x11-apps)... > > xwd -root -silent -out screenshot.xwd > > and then import in gimp or convert in pnm with xwdtopnm (in netpbm-progs) > > xwdtopnm screenshot.xwd > screenshot.pbm > > You can also dump other local/remote displays with the -display option.... You can also go to ebay, bid on a digital camera, then take pictures of the screen when it arrives. Then take the flash card to the local pharmacy, get them printed out, then take them to a photo processing shop, and ask them to scan it, crop it, remove the flash glare, and save on a CD as a TIFF. Take the CD with you, insert into your computer, do "dd /dev/cdrom0 ~/cd.iso", then "mount -o loop ~/cd.iso /mnt/cdrom". Run "tiff2pdf", and then run "evince image.pdf". In the morning, when evince has stopped rendering the image, click "fullscreen". In the evening, when evince has stopped rendering the image again, you can then press "Print Screen" and save your image as "screenshot.png." Nothing to it, really. Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From sundaram at fedoraproject.org Thu Mar 29 13:52:21 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 29 Mar 2007 19:22:21 +0530 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175145485.23281.68.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> <460B0B9C.9090901@fedoraproject.org> <1175145485.23281.68.camel@jndwidescreen.lesbg.loc> Message-ID: <460BC495.7080606@fedoraproject.org> Jonathan Dieter wrote: >> >> Download Size (without DRPM),Download Size (with DRPM),Percentage >> Savings,Total Percentage Savings >> 493372,132236,74,74 >> 509267102,126959924,76,76 Additional note: This log is being written only at the very end and if the transaction fails in between I suspect nothing will get written at all. Yum does log incrementally which is more useful. Also the format is not easy to read and you should probably switch to something more standard that can be parsed better by logwatch. > I think our best bet is to get it included into Extras (which may be a > bit of a struggle if I'm to maintain it as I don't maintain any other > packages). We should then talk with Fedora Infrastructure and see if > they're interested in creating Presto repositories. If we don't run > into any major problems during the F7/Rawhide timeline, maybe we can get > it installed and enabled by default for F8. (Though I will definitely > use it during the whole FC6/F7 timeline.) Yes, the next step would be to get into Fedora Extras, get mirrors and get more feedback. I am using the plugin on my main FC6 box now. Rahul From dennis at ausil.us Thu Mar 29 14:00:57 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 29 Mar 2007 09:00:57 -0500 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <1175135009.3741.13.camel@localhost.localdomain> References: <200703281934.06162.jkeating@redhat.com> <1175135009.3741.13.camel@localhost.localdomain> Message-ID: <200703290900.58064.dennis@ausil.us> On Wednesday 28 March 2007 09:23:29 pm Tom "spot" Callaway wrote: > On Wed, 2007-03-28 at 19:34 -0400, Jesse Keating wrote: > > In our buildsystem we use a 'buildsys-macros' package that defines some > > things during the package builds, like the definition of %{dist}, and of > > %{fedora} or %{rhel}. Now we're talking about adding even more macros to > > add convenience for packagers that are packaging the same thing for > > multiple Fedora releases and RHEL releases (Hurray EPEL!). > > > > However, with more of these macros in use, the usage case of rebuilding > > the srpms on your local system starts to get harder, as these macros will > > be undefined and you'll have interesting results. Perhaps surprising > > results. I propose we ship these macros in something like > > redhat-rpm-config for each release, so that when somebody is rebuilding a > > package on their system, the macros are defined correctly for whatever > > release they are running. If they are rebuilding for another > > release/distribution, they really should be using mock, and having > > redhat-rpm-config define the right things within their mock chroot. > > > > In the past I remember there being resistance to shipping these on the > > installed system, however my Test3 addled brain is not able to recall > > what those are. Are there any differing opinions on this matter, anybody > > that disagrees with me? I'd love to hear it and thought out reasons > > against taking the step. > > FWIW, I think this is a good idea. > > ~spot FWIW so do I I would like to see "__arch_install_post /usr/lib/rpm/check-buildroot\n" added which we use on the extras buildsys which would require rpmdevtools be installed on every box also. which i don't think is a bad idea. it does some sanity checking on the buildroot. -- Dennis Gilmore, RHCE From rc040203 at freenet.de Thu Mar 29 14:09:11 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 29 Mar 2007 16:09:11 +0200 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <460BB963.803@redhat.com> References: <200703281934.06162.jkeating@redhat.com> <20070329085304.6979ef6c.mschwendt.tmp0701.nospam@arcor.de> <200703290655.54021.jkeating@redhat.com> <1175170476.24401.133.camel@mccallum.corsepiu.local> <460BB963.803@redhat.com> Message-ID: <1175177351.24401.174.camel@mccallum.corsepiu.local> On Thu, 2007-03-29 at 09:04 -0400, Jarod Wilson wrote: > Ralf Corsepius wrote: > > - whether the build-sys macros are being merged into redhat-rpm-config > > doesn't matter much, because redhat-rpm-config already kills rpmbuild > > "--target" > > Huh? Worked just fine for me a few days ago to build i686 kernel rpms on > an x86_64 host, using only the following: > > $ setarch i386 rpmbuild -bb --target i686 kernel-2.6.spec Now, build for a non-rh target or an incompatible arch and examine % _host, %_build, %_target and other %values (eg. CC, or $*FLAGS) > Are you referring to the fact you have to make a call to setarch to > get > it to fully do the right thing? Well, the fact you have to apply setarch is a bug. But ... this is not related to what I am referring to: The more exotic the target are, the more brokenness you'll encounter. E.g. try to implement custom /usr/lib/rpm//macros for an exotic target ... redhat-rpm-config causes this not to be used. rpm -e redhat-rpm-config magically makes this work ... (And this is only the tip of the iceberg :( ). Ralf From jeff at ocjtech.us Thu Mar 29 14:21:33 2007 From: jeff at ocjtech.us (Jeffrey C. Ollie) Date: Thu, 29 Mar 2007 09:21:33 -0500 Subject: Is it a bug or intentionally done? In-Reply-To: References: <561c252c0703290628ma7043b2o29260ee73dcee98f@mail.gmail.com> Message-ID: <1175178093.3961.12.camel@lt21223.campus.dmacc.edu> On Thu, 2007-03-29 at 09:45 -0400, Konstantin Ryabitsev wrote: > Nothing to it, really. Why bother with all of these "new fangled" inventions like photography, etc. They have poor archival properties. What you really want to do is to stare at the screen for a while to make sure that you've memorized every last pixel on the display. Next, go out and mine some red and yellow ochre, hematite, manganese oxide and charcoal. Then find some nice quiet cave and use the minerals that you've just mined to paint your screenshot on the cave walls. Then, in 10,000 years when some scientist rediscovers your screenshot they can wonder what part a "kernel oops" took part in our primitive religious ceremonies. 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 jdieter at gmail.com Thu Mar 29 14:22:42 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 29 Mar 2007 17:22:42 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> <460B0B9C.9090901@fedoraproject.org> <1175164871.23281.75.camel@jndwidescreen.lesbg.loc> Message-ID: <1175178162.23281.78.camel@jndwidescreen.lesbg.loc> On Thu, 2007-03-29 at 19:41 +0800, Hikaru Amano wrote: > Any chance for presto to be used together with reposync from yum-utils?? > > I'm maintaining a repository within my university LAN ... the network > is "evil" (2MB size limit for http post/get, only post/get port 80 and > tcp connect port 443 allowed) ... I managed to get through the size > limit and used reposync to sync my local mirror with updates,extras, > livna and rawhide for my frens and new users.. > > having reposync with presto will surely help in this case .. I've never used reposync, but maybe I should start using it rather than the half-baked script I'm using now. If you're asking about using presto for mirroring rather than updates, I've put a little bit of thought into it and would like to have something up and running soon. We don't have the bandwidth to continually mirror updates+extras, but we can put a few days into the initial mirror and then use drpms for the updates. Jonathan -------------- 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 Thu Mar 29 14:21:59 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 29 Mar 2007 10:21:59 -0400 Subject: Announcing Fedora 7 Test 3 (6.92) Message-ID: <1175178119.3034.12.camel@aglarond.local> Welcome to Fedora 7 Test 3. I am please to announce the third of four test releases for Fedora 7. Downloads ======== DVD and network installation are available. http://torrent.fedoraproject.org/ The recommended method of download is via BitTorrent from this site. http://fedora.redhat.com/Download/mirrors.html HTTP, FTP, and RSYNC downloads are available from Fedora Project mirrors listed above. Note that not all mirrors may be synced at this time. New in Fedora 7 Test 3 ======== This test release includes significant new versions of many key components and technologies. The following sections provide a brief overview of major changes from the last release of Fedora. Merger of Core and Extras ======== * The Fedora Core and Extras software repositories are being merged, resulting in a shared infrastructure and a single repository of packages to which everyone is invited to contribute. * Fedora 7 Test 3 is packaged initially as a Desktop/Development Workstation/Server implementation, called "Prime". This spin is delivered in DVD iso format only as a trial, see https://www.redhat.com/archives/fedora-devel-list/2007-February/msg00993.html for the discussion on this. * Many more packages are available in the development repositories. Live CD ======== * This test release includes an i386 ISO for a Desktop Live CD. This Live CD features the ability to install to a hard disk using the same graphical Anaconda installer as the non-live CD variant. * This test release also includes an x86_64 ISO for a Desktop Live image. Due to size, this will require a DVD. As with the i386 Live image, the ability to install to a hard disk is available. * This test release features a new i386 ISO for a KDE Live CD. Note that as of this writing, this ISO is only available via bittorrent. It should be available via the mirrors in the near future. Desktop ======== * This test release features GNOME 2.18 * A brand new Echo icon theme is included as the default in this release. This icon theme is incomplete, but with appropriate feedback and progress, may become the default in the general release. * Fast User Switching is now available via the fast-user-switch-applet. See http://fedoraproject.org/wiki/Releases/FeatureFastUserSwitching for more details. Performance ======== * System performance is generally slower in the test releases as compared to the general release since we enable several options that help with debugging. System Administration ======== * System administration tools may be modified under the testing process. System Level Changes ======== * Fedora 7 Test 3 features a 2.6.21rc5 based kernel. Current release information is being tracked on the kernel release notes source page. (http://fedoraproject.org/wiki/Docs/Beats/Kernel) Amanda Users who upgrade from older releases need to read the amanda.conf and amanda-client.conf man pages to learn about the the new syntax for calling amandad, as well as edit the /etc/xinetd.d/amanda configuration file to follow the new syntax. Road Map And Release Schedule ======== * http://fedoraproject.org/wiki/Releases/7/ Intended Audience for Test Releases ======== Test 1 is targeted for developers, who use it "at their own risk", and contains many bleeding edge packages. Test 2 is for early adopters. Most things should work and we need to your help to find what is broken. Test 3 is for early adopters. Most things should work and we need to your help to find what is broken. Test 4 is for beta users. This is the time when we must have full community participation. Without this participation both hardware and software functionality suffers. Quality Assurance for Test Releases ======== The Fedora Project has a process in place for ensuring the highest possible quality even in our test releases. Many bugs are identified, prioritized and fixed during the testing process. We also have a list of known bugs in this release. Refer to http://fedoraproject.org/wiki/QA/7/Test3TreeTesting for more details. Translations of Release Notes ======== Due to the rapidly changing nature of test releases, translations of release notes for test releases are not practical. The initial goal is to have a translation of the release notes included in the test4 release and to allow community review and correction before the general release. As always, the general release is translated following the established practices for localization (l10n) and internationalization (i18n) (http://fedoraproject.org/wiki/L10N), which result in comprehensive, high-quality release notes in a variety of languages. About Fedora ======== Fedora is a set of projects sponsored by Red Hat and guided by the contributors. These projects are developed by a large community of people who strive to provide and maintain the very best in free, open source software and standards. The central Fedora project is an operating system and platform based on Linux that is always free for anyone to use, modify, and distribute, now and forever. You can help the Fedora Project community continue to improve Fedora if you file bug reports and enhancement requests. Refer to http://fedoraproject.org/wiki/BugsAndFeatureRequests for more information. Thank you for your participation. To find out more general information about Fedora, refer to the following Web pages: * Fedora Overview (http://fedoraproject.org/wiki/Overview) * Fedora FAQ (http://fedoraproject.org/wiki/FAQ) * Help and Support (http://fedoraproject.org/wiki/Communicate) * Participate in the Fedora Project (http://fedoraproject.org/wiki/HelpWanted) From jdieter at gmail.com Thu Mar 29 14:25:16 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 29 Mar 2007 17:25:16 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <460BC495.7080606@fedoraproject.org> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> <460B0B9C.9090901@fedoraproject.org> <1175145485.23281.68.camel@jndwidescreen.lesbg.loc> <460BC495.7080606@fedoraproject.org> Message-ID: <1175178316.23281.82.camel@jndwidescreen.lesbg.loc> On Thu, 2007-03-29 at 19:22 +0530, Rahul Sundaram wrote: > Jonathan Dieter wrote: > >> > >> Download Size (without DRPM),Download Size (with DRPM),Percentage > >> Savings,Total Percentage Savings > >> 493372,132236,74,74 > >> 509267102,126959924,76,76 > > Additional note: This log is being written only at the very end and if > the transaction fails in between I suspect nothing will get written at > all. Yum does log incrementally which is more useful. Also the format > is not easy to read and you should probably switch to something more > standard that can be parsed better by logwatch. > Okay, what are you thinking? I'd be happy to change the format (I chose csv for easy machine parsing), but I'm not sure what people would like to see. > > I think our best bet is to get it included into Extras (which may be a > > bit of a struggle if I'm to maintain it as I don't maintain any other > > packages). We should then talk with Fedora Infrastructure and see if > > they're interested in creating Presto repositories. If we don't run > > into any major problems during the F7/Rawhide timeline, maybe we can get > > it installed and enabled by default for F8. (Though I will definitely > > use it during the whole FC6/F7 timeline.) > > Yes, the next step would be to get into Fedora Extras, get mirrors and > get more feedback. I am using the plugin on my main FC6 box now. Sweet! Maybe this is the wrong place, but how do I go about getting yum-presto into Fedora Extras? > > Rahul > > Jonathan -------------- 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 mschwendt.tmp0701.nospam at arcor.de Thu Mar 29 14:33:09 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 29 Mar 2007 16:33:09 +0200 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 In-Reply-To: References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <46097882.9030802@redhat.com> <64171.65.192.24.190.1175026507.squirrel@mail.jcomserv.net> <20070328174018.GF2483@tomservo.rh.rit.edu> <6514.65.192.24.190.1175103969.squirrel@mail.jcomserv.net> <20070328195928.f097f071.mschwendt.tmp0701.nospam@arcor.de> <460B7947.8020505@nobugconsulting.ro> <20070329084703.GB2830@free.fr> <20070329115407.ae449308.mschwendt.tmp0701.nospam@arcor.de> <20070329150139.22710ade.mschwendt.tmp0701.nospam@arcor.de> Message-ID: <20070329163309.a097dad5.mschwendt.tmp0701.nospam@arcor.de> On Thu, 29 Mar 2007 08:16:09 -0500, Rex Dieter wrote: > Michael Schwendt wrote: > > > On Thu, 29 Mar 2007 06:51:57 -0500, Rex Dieter wrote: > > >> Michael Schwendt wrote: > > >> > Making a file %ghost, when multiple packages use the alternatives > >> > system for a shared set of paths, would be wrong. > > >> I disagree, I've done it, and it works just fine. I've advocated that > >> all alternatives-using-packages (particularly jpackage ones) use this > >> technique. > > > Now you've got N packages which pretend they own a file/symlink. > > That's as it should be, imo. You would rather the file/symlink be unowned? But sure! The link target does not belong into any package, since it is a configuration value. E.g. $ rpm -qf /etc/alternatives/mta file /etc/alternatives/mta is not owned by any package If packages PKG1 and PKG2 own the link name, none of them owns the link target. And since the link target is a link itself, only either one can own the configured file the final link points to. Hence if the final destination is a file in PKG2, it would be wrong to make PKG1 the owner of the base link. > > The alternatives symlink is a configuration value and doesn't belong into > > any package. The admin could also point the symlink to something in > > /usr/local, and you don't want to remove his customisation when an rpm is > > uninstalled. > > Stuff done outside of rpm is done by a local admin at their own risk. Too bad, since the "alternatives" system is a configuration system outside of RPM: rpm -qf /etc/alternatives/* /var/lib/alternatives/* man alternatives From rdieter at math.unl.edu Thu Mar 29 14:31:30 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 29 Mar 2007 09:31:30 -0500 Subject: Yum-presto (deltarpms) ready for testing. References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> <460B0B9C.9090901@fedoraproject.org> <1175145485.23281.68.camel@jndwidescreen.lesbg.loc> <460BC495.7080606@fedoraproject.org> <1175178316.23281.82.camel@jndwidescreen.lesbg.loc> Message-ID: Jonathan Dieter wrote: > On Thu, 2007-03-29 at 19:22 +0530, Rahul Sundaram wrote: >> Yes, the next step would be to get into Fedora Extras, get mirrors and >> get more feedback. I am using the plugin on my main FC6 box now. > Sweet! Maybe this is the wrong place, but how do I go about getting > yum-presto into Fedora Extras? http://fedoraproject.org/wiki/PackageMaintainers http://fedoraproject.org/wiki/PackageMaintainers/Join -- Rex From sundaram at fedoraproject.org Thu Mar 29 14:34:24 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 29 Mar 2007 20:04:24 +0530 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175178316.23281.82.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> <460B0B9C.9090901@fedoraproject.org> <1175145485.23281.68.camel@jndwidescreen.lesbg.loc> <460BC495.7080606@fedoraproject.org> <1175178316.23281.82.camel@jndwidescreen.lesbg.loc> Message-ID: <460BCE70.9030309@fedoraproject.org> Jonathan Dieter wrote: >> > Okay, what are you thinking? I'd be happy to change the format (I chose > csv for easy machine parsing), but I'm not sure what people would like > to see. I was thinking we need more detailed incremental logging of what drpms are being downloaded, which builds of drpms failed etc for troubleshooting. Maybe a format close to the yum log would make it easier. > Sweet! Maybe this is the wrong place, but how do I go about getting > yum-presto into Fedora Extras? This isn't the wrong place. fedora-extras list is going to be shutdown soon ahead of the merge. To submit a package as a new contributor you need to follow http://fedoraproject.org/wiki/PackageMaintainers/Join Rahul From ml at deadbabylon.de Thu Mar 29 14:50:01 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 29 Mar 2007 16:50:01 +0200 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <1175178119.3034.12.camel@aglarond.local> References: <1175178119.3034.12.camel@aglarond.local> Message-ID: <20070329165001.66aae998@localhost.localdomain> Am Thu, 29 Mar 2007 10:21:59 -0400 schrieb Jeremy Katz : > * This test release features a new i386 ISO for a KDE Live CD. > Note that as of this writing, this ISO is only available via > bittorrent. Actually the torrent for the KDE Live CD is also missing. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at linux.duke.edu Thu Mar 29 14:58:41 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 29 Mar 2007 10:58:41 -0400 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <20070329165001.66aae998@localhost.localdomain> References: <1175178119.3034.12.camel@aglarond.local> <20070329165001.66aae998@localhost.localdomain> Message-ID: <1175180321.12588.23.camel@cutter> On Thu, 2007-03-29 at 16:50 +0200, Sebastian Vahl wrote: > Am Thu, 29 Mar 2007 10:21:59 -0400 > schrieb Jeremy Katz : > > > > * This test release features a new i386 ISO for a KDE Live CD. > > Note that as of this writing, this ISO is only available via > > bittorrent. > > Actually the torrent for the KDE Live CD is also missing. > It was late getting to me, but it's up now. -sv From hughsient at gmail.com Thu Mar 29 15:04:14 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 29 Mar 2007 16:04:14 +0100 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <1175180321.12588.23.camel@cutter> References: <1175178119.3034.12.camel@aglarond.local> <20070329165001.66aae998@localhost.localdomain> <1175180321.12588.23.camel@cutter> Message-ID: <15e53e180703290804i29261bb6re406cdfccac535f6@mail.gmail.com> On 29/03/07, seth vidal wrote: > It was late getting to me, but it's up now. If KDE is f7-test3-kde-live-i386, shouldn't GNOME be f7-test3-gnome-live-i386? Richard. From clumens at redhat.com Thu Mar 29 15:06:22 2007 From: clumens at redhat.com (Chris Lumens) Date: Thu, 29 Mar 2007 11:06:22 -0400 Subject: Bug Day this Friday! In-Reply-To: <1175113541.6884.22.camel@metroid.rdu.redhat.com> References: <1175113541.6884.22.camel@metroid.rdu.redhat.com> Message-ID: <20070329150622.GV16460@exeter.boston.redhat.com> > We're going to have another Bug Day this Friday! > > Last week just a couple of us managed to clean out a couple dozen old > test-release bugs. > > This week we're working on rawhide bugs - much more relevant! > > I'll be around #fedora-devel from 10-6 EDT (that's 1400-2200 UTC) to > guide people trying to make sure the bugs are cleaned up. > > Here's the link to the rawhide bug list for this week: > > http://rdr.to/W9 There are only a handful of anaconda bugs on that list, which is unusual since there's quite a few more in my list. But that's okay. I'll sit around #fedora-devel during this time as well and answer any questions people may have about anaconda testing, debugging, etc. So if you really want to dig into the glamorous world of installer bugs, I'll be around to explain how we wrangle the beast. - Chris From emmanuel.seyman at club-internet.fr Thu Mar 29 15:10:57 2007 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Thu, 29 Mar 2007 17:10:57 +0200 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <15e53e180703290804i29261bb6re406cdfccac535f6@mail.gmail.com> References: <1175178119.3034.12.camel@aglarond.local> <20070329165001.66aae998@localhost.localdomain> <1175180321.12588.23.camel@cutter> <15e53e180703290804i29261bb6re406cdfccac535f6@mail.gmail.com> Message-ID: <20070329151057.GA7920@orient.maison.lan> * Richard Hughes [29/03/2007 17:07] : > > If KDE is f7-test3-kde-live-i386, shouldn't GNOME be > f7-test3-gnome-live-i386? There isn't any Gnome Live CD. Emmanuel From ml at deadbabylon.de Thu Mar 29 15:10:12 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 29 Mar 2007 17:10:12 +0200 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <1175180321.12588.23.camel@cutter> References: <1175178119.3034.12.camel@aglarond.local> <20070329165001.66aae998@localhost.localdomain> <1175180321.12588.23.camel@cutter> Message-ID: <20070329171012.138fc43e@localhost.localdomain> Am Thu, 29 Mar 2007 10:58:41 -0400 schrieb seth vidal : > On Thu, 2007-03-29 at 16:50 +0200, Sebastian Vahl wrote: > > Am Thu, 29 Mar 2007 10:21:59 -0400 > > schrieb Jeremy Katz : > > > > > > > * This test release features a new i386 ISO for a KDE Live CD. > > > Note that as of this writing, this ISO is only available via > > > bittorrent. > > > > Actually the torrent for the KDE Live CD is also missing. > > > > It was late getting to me, but it's up now. Is now there. Thanks. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rdieter at math.unl.edu Thu Mar 29 15:12:16 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 29 Mar 2007 10:12:16 -0500 Subject: rpms/ettercap/devel ettercap.spec,1.4,1.5 References: <200703270159.l2R1xZO6023251@cvs-int.fedora.redhat.com> <20070327092810.GB2896@free.fr> <46097882.9030802@redhat.com> <64171.65.192.24.190.1175026507.squirrel@mail.jcomserv.net> <20070328174018.GF2483@tomservo.rh.rit.edu> <6514.65.192.24.190.1175103969.squirrel@mail.jcomserv.net> <20070328195928.f097f071.mschwendt.tmp0701.nospam@arcor.de> <460B7947.8020505@nobugconsulting.ro> <20070329084703.GB2830@free.fr> <20070329115407.ae449308.mschwendt.tmp0701.nospam@arcor.de> <20070329150139.22710ade.mschwendt.tmp0701.nospam@arcor.de> <20070329163309.a097dad5.mschwendt.tmp0701.nospam@arcor.de> Message-ID: Michael Schwendt wrote: > On Thu, 29 Mar 2007 08:16:09 -0500, Rex Dieter wrote: >> >> I disagree, I've done it, and it works just fine. I've advocated that >> >> all alternatives-using-packages (particularly jpackage ones) use this >> >> technique. >> > Now you've got N packages which pretend they own a file/symlink. >> That's as it should be, imo. You would rather the file/symlink be >> unowned? > But sure! The link target does not belong into any package I guess we'll just have to agree to disagree then, that's ok. :) -- Rex From hughsient at gmail.com Thu Mar 29 15:15:33 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 29 Mar 2007 16:15:33 +0100 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <20070329151057.GA7920@orient.maison.lan> References: <1175178119.3034.12.camel@aglarond.local> <20070329165001.66aae998@localhost.localdomain> <1175180321.12588.23.camel@cutter> <15e53e180703290804i29261bb6re406cdfccac535f6@mail.gmail.com> <20070329151057.GA7920@orient.maison.lan> Message-ID: <15e53e180703290815j7a122f4ah625247e78e099733@mail.gmail.com> On 29/03/07, Emmanuel Seyman wrote: > * Richard Hughes [29/03/2007 17:07] : > > > > If KDE is f7-test3-kde-live-i386, shouldn't GNOME be > > f7-test3-gnome-live-i386? > > There isn't any Gnome Live CD. Maybe I phased it badly, sorry. Maybe rename f7-test3-live-i386 to f7-test3-gnome-live-i386 seeing as by default we are using GNOME stuff. Also, as an aside, http://download.fedora.redhat.com/pub/fedora/linux/core/test/6.92/* doesn't seem to be present. Richard. From nicolas.mailhot at laposte.net Thu Mar 29 15:19:49 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 29 Mar 2007 17:19:49 +0200 (CEST) Subject: Is it a bug or intentionally done? In-Reply-To: <1175178093.3961.12.camel@lt21223.campus.dmacc.edu> References: <561c252c0703290628ma7043b2o29260ee73dcee98f@mail.gmail.com> <1175178093.3961.12.camel@lt21223.campus.dmacc.edu> Message-ID: <14982.192.54.193.51.1175181589.squirrel@rousalka.dyndns.org> Why are you all trying to confuse the man? Just put the screen-thing on a XEROX machine and press the button. Then FAX the result. You've never heard of the modern electronic office, have you? -- Nicolas Mailhot From orion at cora.nwra.com Thu Mar 29 15:22:46 2007 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 29 Mar 2007 09:22:46 -0600 Subject: Bug Day this Friday! In-Reply-To: <20070329150622.GV16460@exeter.boston.redhat.com> References: <1175113541.6884.22.camel@metroid.rdu.redhat.com> <20070329150622.GV16460@exeter.boston.redhat.com> Message-ID: >> >> Here's the link to the rawhide bug list for this week: >> >> http://rdr.to/W9 Is there a way to change the fields displayed in a bug list? I'm more interested in seeing which component was filed against then say who it is assigned to. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From mschwendt.tmp0701.nospam at arcor.de Thu Mar 29 15:32:09 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Thu, 29 Mar 2007 17:32:09 +0200 Subject: rpms/livecd-tools/devel livecd-tools.spec,1.3,1.4 In-Reply-To: <200703291428.l2TESPPB022441@cvs-int.fedora.redhat.com> References: <200703291428.l2TESPPB022441@cvs-int.fedora.redhat.com> Message-ID: <20070329173209.7b1f61bd.mschwendt.tmp0701.nospam@arcor.de> On Thu, 29 Mar 2007 10:28:25 -0400, Jeremy Katz (katzj) wrote: > Author: katzj > > Update of /cvs/extras/rpms/livecd-tools/devel > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv22412 > > Modified Files: > livecd-tools.spec > Log Message: > * Thu Mar 29 2007 Jeremy Katz - 005-2 > - exclusivearch since it only works on x86 and x86_64 for now > +ExclusiveArch: %{ix86} x86_64 Note that in addition to the build error you've got, only ExcludeArch for noarch rpms is supported by the Extras pushscript. ExclusiveArch for noarch rpms looks like a show-stopper to me, as e.g. mock/plague built a src.rpm that contained just this $ rpm -qp --qf %{exclusivearch}\\n livecd-tools-005-2.fc7.src.rpm i386 and no x86_64 in there. When built with ExclusiveArch: %{ix86} x86_64 ppc ppc64 it still doesn't add more than i386 when building on i386. The ExclusiveArch information is lost. It doesn't find its way into the noarch.rpm and neither the src.rpm. From jwilson at redhat.com Thu Mar 29 15:31:24 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 29 Mar 2007 11:31:24 -0400 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <1175177351.24401.174.camel@mccallum.corsepiu.local> References: <200703281934.06162.jkeating@redhat.com> <20070329085304.6979ef6c.mschwendt.tmp0701.nospam@arcor.de> <200703290655.54021.jkeating@redhat.com> <1175170476.24401.133.camel@mccallum.corsepiu.local> <460BB963.803@redhat.com> <1175177351.24401.174.camel@mccallum.corsepiu.local> Message-ID: <460BDBCC.80501@redhat.com> Ralf Corsepius wrote: > On Thu, 2007-03-29 at 09:04 -0400, Jarod Wilson wrote: >> Ralf Corsepius wrote: >>> - whether the build-sys macros are being merged into redhat-rpm-config >>> doesn't matter much, because redhat-rpm-config already kills rpmbuild >>> "--target" >> Huh? Worked just fine for me a few days ago to build i686 kernel rpms on >> an x86_64 host, using only the following: >> >> $ setarch i386 rpmbuild -bb --target i686 kernel-2.6.spec > Now, build for a non-rh target or an incompatible arch and examine % > _host, %_build, %_target and other %values (eg. CC, or $*FLAGS) It seems a bit unreasonable to expect us to support building something like solaris sparc rpms on linux i386... Or really, building any non-rh or incompatible arch target. Even in the non-rh but still linux and a compatible arch case, a build chroot makes a lot more sense to me. Perhaps I don't fully understand what it is you're trying to accomplish. >> Are you referring to the fact you have to make a call to setarch to >> get >> it to fully do the right thing? > Well, the fact you have to apply setarch is a bug. I think that's a valid concern. > But ... this is not related to what I am referring to: > The more exotic the target are, the more brokenness you'll encounter. > > E.g. try to implement custom /usr/lib/rpm//macros for an exotic > target ... redhat-rpm-config causes this not to be used. rpm -e > redhat-rpm-config magically makes this work ... (And this is only the > tip of the iceberg :( ). Like you said, "the more exotic..." I think you're trying to do some things that the vast majority of users don't and shouldn't do. Sounds like you have a work-around already too. Not to say that if it isn't straight-forward enough we shouldn't fix up redhat-rpm-config to play nice in this situation, but I don't think its something that is going to be high-priority on most people's todo list. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From oisin.feeley at gmail.com Thu Mar 29 15:38:19 2007 From: oisin.feeley at gmail.com (Oisin Feeley) Date: Thu, 29 Mar 2007 11:38:19 -0400 Subject: Is it a bug or intentionally done? In-Reply-To: <14982.192.54.193.51.1175181589.squirrel@rousalka.dyndns.org> References: <561c252c0703290628ma7043b2o29260ee73dcee98f@mail.gmail.com> <1175178093.3961.12.camel@lt21223.campus.dmacc.edu> <14982.192.54.193.51.1175181589.squirrel@rousalka.dyndns.org> Message-ID: On 3/29/07, Nicolas Mailhot wrote: > Why are you all trying to confuse the man? Just put the screen-thing on a > XEROX machine and press the button. Then FAX the result. You've never > heard of the modern electronic office, have you? Nonsense. 20 minutes work by a class of diligent 5th-graders armed with rulers and color-charts should provide him with ample information to whip up an implementation of a Cohen-Daubechies-Feauveau wavelet on the back of an envelope which will be a bitrot-proof mathematical description of his screen. This will be trivially understood by anyone without any need for pointless image processing software, or indeed a computer screen. Oisin From nicolas.mailhot at laposte.net Thu Mar 29 15:41:26 2007 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 29 Mar 2007 17:41:26 +0200 (CEST) Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <460BDBCC.80501@redhat.com> References: <200703281934.06162.jkeating@redhat.com> <20070329085304.6979ef6c.mschwendt.tmp0701.nospam@arcor.de> <200703290655.54021.jkeating@redhat.com> <1175170476.24401.133.camel@mccallum.corsepiu.local> <460BB963.803@redhat.com> <1175177351.24401.174.camel@mccallum.corsepiu.local> <460BDBCC.80501@redhat.com> Message-ID: <21687.192.54.193.51.1175182886.squirrel@rousalka.dyndns.org> Le Jeu 29 mars 2007 17:31, Jarod Wilson a ?crit : > Like you said, "the more exotic..." I think you're trying to do some > things that the vast majority of users don't and shouldn't do. Sounds > like you have a work-around already too. Not to say that if it isn't > straight-forward enough we shouldn't fix up redhat-rpm-config to play > nice in this situation, but I don't think its something that is going to > be high-priority on most people's todo list. redhat-rpm-config definitively earned itself a "package from hell" reputation, to remove first when packages from other distros or older releases mysteriously do not rebuild anymore -- Nicolas Mailhot From clumens at redhat.com Thu Mar 29 15:55:28 2007 From: clumens at redhat.com (Chris Lumens) Date: Thu, 29 Mar 2007 11:55:28 -0400 Subject: Bug Day this Friday! In-Reply-To: References: <1175113541.6884.22.camel@metroid.rdu.redhat.com> <20070329150622.GV16460@exeter.boston.redhat.com> Message-ID: <20070329155528.GW16460@exeter.boston.redhat.com> > Is there a way to change the fields displayed in a bug list? I'm more > interested in seeing which component was filed against then say who it > is assigned to. Yeah, just click on "Change Columns" way down at the bottom. - Chris From rc040203 at freenet.de Thu Mar 29 15:58:13 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 29 Mar 2007 17:58:13 +0200 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <460BDBCC.80501@redhat.com> References: <200703281934.06162.jkeating@redhat.com> <20070329085304.6979ef6c.mschwendt.tmp0701.nospam@arcor.de> <200703290655.54021.jkeating@redhat.com> <1175170476.24401.133.camel@mccallum.corsepiu.local> <460BB963.803@redhat.com> <1175177351.24401.174.camel@mccallum.corsepiu.local> <460BDBCC.80501@redhat.com> Message-ID: <1175183893.24401.224.camel@mccallum.corsepiu.local> On Thu, 2007-03-29 at 11:31 -0400, Jarod Wilson wrote: > Ralf Corsepius wrote: > > On Thu, 2007-03-29 at 09:04 -0400, Jarod Wilson wrote: > >> Ralf Corsepius wrote: > >>> - whether the build-sys macros are being merged into redhat-rpm-config > >>> doesn't matter much, because redhat-rpm-config already kills rpmbuild > >>> "--target" > >> Huh? Worked just fine for me a few days ago to build i686 kernel rpms on > >> an x86_64 host, using only the following: > >> > >> $ setarch i386 rpmbuild -bb --target i686 kernel-2.6.spec > > Now, build for a non-rh target or an incompatible arch and examine % > > _host, %_build, %_target and other %values (eg. CC, or $*FLAGS) > > It seems a bit unreasonable to expect us to support building something > like solaris sparc rpms on linux i386... I don't expect Fedora to support such endeavors, but I do think I can expect Fedora/RH not to interfere (In a nutshell, all this can be subsumed as redhat-rpm-config breaks "rpmbuild --target"). Fact is, I am using rpm/rpmbuild to cross-build packages for other OSs but Fedora. rpmbuild (modulo bugs) supports it, but redhat-rpm-config interferes. > Or really, building any non-rh > or incompatible arch target. Even in the non-rh but still linux and a > compatible arch case, a build chroot makes a lot more sense to me. > Perhaps I don't fully understand what it is you're trying to accomplish. > > >> Are you referring to the fact you have to make a call to setarch to > >> get > >> it to fully do the right thing? > > Well, the fact you have to apply setarch is a bug. I should have said "IMO" ;) > I think that's a valid concern. > > But ... this is not related to what I am referring to: > > The more exotic the target are, the more brokenness you'll encounter. > > > > E.g. try to implement custom /usr/lib/rpm//macros for an exotic > > target ... redhat-rpm-config causes this not to be used. rpm -e > > redhat-rpm-config magically makes this work ... (And this is only the > > tip of the iceberg :( ). > > Like you said, "the more exotic..." I think you're trying to do some > things that the vast majority of users don't and shouldn't do. That's the problem "99%" of users don't do ... has led to bugs interfering with the remaining "1%". > Sounds > like you have a work-around already too. Well, I am working on it. So far my work around is to ban redhat-rpm-config from the system I am using to build these rpms. > Not to say that if it isn't > straight-forward enough we shouldn't fix up redhat-rpm-config to play > nice in this situation, but I don't think its something that is going to > be high-priority on most people's todo list. Of cause, I don't expect "immediate" reaction. Fact is, I am complaining about this for years, but NOTHING has happened on RH's part. Instead I am seeing things getting gradually worser with each Fedora release. Ralf From jwilson at redhat.com Thu Mar 29 16:10:57 2007 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 29 Mar 2007 12:10:57 -0400 Subject: Opinions: Providing "buildsys-macros" in the installed system In-Reply-To: <1175183893.24401.224.camel@mccallum.corsepiu.local> References: <200703281934.06162.jkeating@redhat.com> <20070329085304.6979ef6c.mschwendt.tmp0701.nospam@arcor.de> <200703290655.54021.jkeating@redhat.com> <1175170476.24401.133.camel@mccallum.corsepiu.local> <460BB963.803@redhat.com> <1175177351.24401.174.camel@mccallum.corsepiu.local> <460BDBCC.80501@redhat.com> <1175183893.24401.224.camel@mccallum.corsepiu.local> Message-ID: <460BE511.4010809@redhat.com> Ralf Corsepius wrote: > On Thu, 2007-03-29 at 11:31 -0400, Jarod Wilson wrote: >> Ralf Corsepius wrote: [...] >>> E.g. try to implement custom /usr/lib/rpm//macros for an exotic >>> target ... redhat-rpm-config causes this not to be used. rpm -e >>> redhat-rpm-config magically makes this work ... (And this is only the >>> tip of the iceberg :( ). >> Like you said, "the more exotic..." I think you're trying to do some >> things that the vast majority of users don't and shouldn't do. > > That's the problem "99%" of users don't do ... has led to bugs > interfering with the remaining "1%". > >> Sounds like you have a work-around already too. > > Well, I am working on it. So far my work around is to ban > redhat-rpm-config from the system I am using to build these rpms. > >> Not to say that if it isn't >> straight-forward enough we shouldn't fix up redhat-rpm-config to play >> nice in this situation, but I don't think its something that is going to >> be high-priority on most people's todo list. > > Of cause, I don't expect "immediate" reaction. Fact is, I am complaining > about this for years, but NOTHING has happened on RH's part. Instead I > am seeing things getting gradually worser with each Fedora release. I'm not aware of the exact nature of prior complaints, so forgive me if this has already been attempted, but given that this isn't high-priority for most people, I would think submitting patches to fix the situation in a way acceptable to all parties would have a better chance of making headway than simply complaining about it. -- Jarod Wilson jwilson at redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ville.skytta at iki.fi Thu Mar 29 16:20:32 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 29 Mar 2007 19:20:32 +0300 Subject: gimp-print in or out in F7? Message-ID: <200703291920.32820.ville.skytta@iki.fi> Is gimp-print going to be in F7 or not? From ville.skytta at iki.fi Thu Mar 29 16:22:08 2007 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 29 Mar 2007 19:22:08 +0300 Subject: gimp-print in or out in F7? In-Reply-To: <200703291920.32820.ville.skytta@iki.fi> References: <200703291920.32820.ville.skytta@iki.fi> Message-ID: <200703291922.08845.ville.skytta@iki.fi> On Thursday 29 March 2007, Ville Skytt? wrote: > Is gimp-print going to be in F7 or not? Damn, accidentally sent that one prematurely. Meant to add: I've had a bug report closed twice already saying gimp-print won't be in F7, but it's still included in Rawhide and Test3. https://bugzilla.redhat.com/223690 From jdieter at gmail.com Thu Mar 29 16:37:51 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 29 Mar 2007 19:37:51 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <460BCE70.9030309@fedoraproject.org> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607D059.50900@fedoraproject.org> <1174921427.19925.35.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> <460B0B9C.9090901@fedoraproject.org> <1175145485.23281.68.camel@jndwidescreen.lesbg.loc> <460BC495.7080606@fedoraproject.org> <1175178316.23281.82.camel@jndwidescreen.lesbg.loc> <460BCE70.9030309@fedoraproject.org> Message-ID: <1175186271.23281.89.camel@jndwidescreen.lesbg.loc> On Thu, 2007-03-29 at 20:04 +0530, Rahul Sundaram wrote: > This isn't the wrong place. fedora-extras list is going to be shutdown > soon ahead of the merge. To submit a package as a new contributor you > need to follow http://fedoraproject.org/wiki/PackageMaintainers/Join > > Rahul > Okay, I've gone through the steps up to requesting review. Here's a link to the bug request for anyone who's interested: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234488 Jonathan -------------- 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 twaugh at redhat.com Thu Mar 29 16:59:44 2007 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 29 Mar 2007 17:59:44 +0100 Subject: gimp-print in or out in F7? In-Reply-To: <200703291922.08845.ville.skytta@iki.fi> References: <200703291920.32820.ville.skytta@iki.fi> <200703291922.08845.ville.skytta@iki.fi> Message-ID: <1175187584.4814.27.camel@cyberelk.elk> On Thu, 2007-03-29 at 19:22 +0300, Ville Skytt? wrote: > On Thursday 29 March 2007, Ville Skytt? wrote: > > Is gimp-print going to be in F7 or not? > > Damn, accidentally sent that one prematurely. Meant to add: > > I've had a bug report closed twice already saying gimp-print won't be in F7, > but it's still included in Rawhide and Test3. > https://bugzilla.redhat.com/223690 Gimp-print is NOT going to be in F7. I don't know why it's in F7test3. Every time I say not to include it, somehow it never seems to get removed. I've been asking for this since F7test1. :-( Tim. */ -------------- 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 ml at deadbabylon.de Thu Mar 29 17:05:45 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 29 Mar 2007 19:05:45 +0200 Subject: KDE-Live-CD: trim the fat In-Reply-To: References: <20070314011000.5b0cbcb8@localhost.localdomain> Message-ID: <20070329190545.05537ebc@localhost.localdomain> Am Thu, 29 Mar 2007 08:02:49 -0500 schrieb Rex Dieter : > Sebastian Vahl wrote: > > > I've created a new basic layout for the cd: > > http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/KDELiveCD > > The size on todays rawhide is about 667 MB. > > Please tell me which package should be added or removed. > > Playing a bit with the F7-test3-KDE-Live, here are some suggestions to > consider: > http://fedoraproject.org/wiki/RexDieter/F7t3-kde-trim-the-fat If I haven't missed something all of the mentioned gnome-ish bits are dependencies or dependencies of a dependency from anaconda. And anaconda is used for harddisk installation. So If we don't find another way for installation (and I don't think that we should drop this one and fall out with the gnome-cd in this point) we have to live with it. krita, scribus and kdeartwork-extras could be excluded. IMO. twinkle could be a kde-alternative fo ekiga. But not sure, never used it. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mattdm at mattdm.org Thu Mar 29 17:47:46 2007 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 29 Mar 2007 13:47:46 -0400 Subject: any Sinhala-speaking packagers? Message-ID: <20070329174746.GA4923@jadzia.bu.edu> It might be nice to get this new voice packaged for the Festival text-to-speech system. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From rdieter at math.unl.edu Thu Mar 29 17:46:42 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 29 Mar 2007 12:46:42 -0500 Subject: KDE-Live-CD: trim the fat References: <20070314011000.5b0cbcb8@localhost.localdomain> <20070329190545.05537ebc@localhost.localdomain> Message-ID: Sebastian Vahl wrote: > Am Thu, 29 Mar 2007 08:02:49 -0500 > schrieb Rex Dieter : > >> Sebastian Vahl wrote: >> >> > I've created a new basic layout for the cd: >> > http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/KDELiveCD >> > The size on todays rawhide is about 667 MB. >> > Please tell me which package should be added or removed. >> >> Playing a bit with the F7-test3-KDE-Live, here are some suggestions to >> consider: >> http://fedoraproject.org/wiki/RexDieter/F7t3-kde-trim-the-fat > > If I haven't missed something all of the mentioned gnome-ish bits are > dependencies or dependencies of a dependency from anaconda. I don't think so, I checked already trying(1) to remove most of those packages (and they didn't touch anaconda). -- Rex (1) sucessfully, in most cases without odd deps, as noted by ?'s. From wilmer at fedoraproject.org Thu Mar 29 19:45:16 2007 From: wilmer at fedoraproject.org (Wilmer Jaramillo M.) Date: Thu, 29 Mar 2007 15:45:16 -0400 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <1175178119.3034.12.camel@aglarond.local> References: <1175178119.3034.12.camel@aglarond.local> Message-ID: <2b26c4260703291245k659240d2g6d3b2e6279127174@mail.gmail.com> Translate to Spanish Language on http://fedoraproject.org/wiki/es_ES/FC7Test3ReleaseSummary -- Wilmer Jaramillo M. GPG Key Fingerprint = 0666 D0D3 24CE 8935 9C24 BBF1 87DD BEA2 A4B2 1E8A From tmus at tmus.dk Thu Mar 29 19:52:03 2007 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 29 Mar 2007 21:52:03 +0200 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <15e53e180703290815j7a122f4ah625247e78e099733@mail.gmail.com> References: <1175178119.3034.12.camel@aglarond.local> <20070329165001.66aae998@localhost.localdomain> <1175180321.12588.23.camel@cutter> <15e53e180703290804i29261bb6re406cdfccac535f6@mail.gmail.com> <20070329151057.GA7920@orient.maison.lan> <15e53e180703290815j7a122f4ah625247e78e099733@mail.gmail.com> Message-ID: Richard Hughes wrote: > On 29/03/07, Emmanuel Seyman wrote: >> * Richard Hughes [29/03/2007 17:07] : >> > >> > If KDE is f7-test3-kde-live-i386, shouldn't GNOME be >> > f7-test3-gnome-live-i386? >> >> There isn't any Gnome Live CD. > > Maybe I phased it badly, sorry. Maybe rename f7-test3-live-i386 to > f7-test3-gnome-live-i386 seeing as by default we are using GNOME > stuff. > Doesn't "default" say it all? If gnome is there by default, why even mention it? /Thomas From jwboyer at jdub.homelinux.org Thu Mar 29 21:11:59 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 29 Mar 2007 16:11:59 -0500 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: References: <1175178119.3034.12.camel@aglarond.local> <20070329165001.66aae998@localhost.localdomain> <1175180321.12588.23.camel@cutter> <15e53e180703290804i29261bb6re406cdfccac535f6@mail.gmail.com> <20070329151057.GA7920@orient.maison.lan> <15e53e180703290815j7a122f4ah625247e78e099733@mail.gmail.com> Message-ID: <1175202719.7553.150.camel@zod.rchland.ibm.com> On Thu, 2007-03-29 at 21:52 +0200, Thomas M Steenholdt wrote: > Richard Hughes wrote: > > On 29/03/07, Emmanuel Seyman wrote: > >> * Richard Hughes [29/03/2007 17:07] : > >> > > >> > If KDE is f7-test3-kde-live-i386, shouldn't GNOME be > >> > f7-test3-gnome-live-i386? > >> > >> There isn't any Gnome Live CD. > > > > Maybe I phased it badly, sorry. Maybe rename f7-test3-live-i386 to > > f7-test3-gnome-live-i386 seeing as by default we are using GNOME > > stuff. > > > Doesn't "default" say it all? If gnome is there by default, why even > mention it? This was already discussed. A lot. Further discussion will result in an endless post. Again. Please, let's just move on... josh From sundaram at fedoraproject.org Thu Mar 29 21:13:23 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 30 Mar 2007 02:43:23 +0530 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: References: <1175178119.3034.12.camel@aglarond.local> <20070329165001.66aae998@localhost.localdomain> <1175180321.12588.23.camel@cutter> <15e53e180703290804i29261bb6re406cdfccac535f6@mail.gmail.com> <20070329151057.GA7920@orient.maison.lan> <15e53e180703290815j7a122f4ah625247e78e099733@mail.gmail.com> Message-ID: <460C2BF3.2070106@fedoraproject.org> Thomas M Steenholdt wrote: > Richard Hughes wrote: >> On 29/03/07, Emmanuel Seyman wrote: >>> * Richard Hughes [29/03/2007 17:07] : >>> > >>> > If KDE is f7-test3-kde-live-i386, shouldn't GNOME be >>> > f7-test3-gnome-live-i386? >>> >>> There isn't any Gnome Live CD. >> >> Maybe I phased it badly, sorry. Maybe rename f7-test3-live-i386 to >> f7-test3-gnome-live-i386 seeing as by default we are using GNOME >> stuff. >> > Doesn't "default" say it all? If gnome is there by default, why even > mention it? It makes sense to mention GNOME explicitly in parallel to KDE because in the world of multiple spins, there is no one set of defaults fpr Fedora on the whole. GNOME is certainly not the default in the KDE Live CD. All I have been hearing so far is one poor excuse after next for not doing it. Rahul From markg85 at gmail.com Thu Mar 29 21:18:32 2007 From: markg85 at gmail.com (Mark) Date: Thu, 29 Mar 2007 23:18:32 +0200 Subject: Is it a bug or intentionally done? In-Reply-To: References: <561c252c0703290628ma7043b2o29260ee73dcee98f@mail.gmail.com> <1175178093.3961.12.camel@lt21223.campus.dmacc.edu> <14982.192.54.193.51.1175181589.squirrel@rousalka.dyndns.org> Message-ID: <6e24a8e80703291418l6b689804t87807b8101e8bf82@mail.gmail.com> lol to much information ;) i know what i wanted to know.. no need for a expensive digital camera ;) thanx for all the reply`s. 2007/3/29, Oisin Feeley : > > On 3/29/07, Nicolas Mailhot wrote: > > Why are you all trying to confuse the man? Just put the screen-thing on > a > > XEROX machine and press the button. Then FAX the result. You've never > > heard of the modern electronic office, have you? > > Nonsense. 20 minutes work by a class of diligent 5th-graders armed > with rulers and color-charts should provide him with ample information > to whip up an implementation of a Cohen-Daubechies-Feauveau wavelet on > the back of an envelope which will be a bitrot-proof mathematical > description of his screen. This will be trivially understood by > anyone without any need for pointless image processing software, or > indeed a computer screen. > > Oisin > > -- > 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 hughsient at gmail.com Thu Mar 29 21:35:59 2007 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 29 Mar 2007 22:35:59 +0100 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <460C2BF3.2070106@fedoraproject.org> References: <1175178119.3034.12.camel@aglarond.local> <20070329165001.66aae998@localhost.localdomain> <1175180321.12588.23.camel@cutter> <15e53e180703290804i29261bb6re406cdfccac535f6@mail.gmail.com> <20070329151057.GA7920@orient.maison.lan> <15e53e180703290815j7a122f4ah625247e78e099733@mail.gmail.com> <460C2BF3.2070106@fedoraproject.org> Message-ID: <1175204159.6603.5.camel@localhost.localdomain> On Fri, 2007-03-30 at 02:43 +0530, Rahul Sundaram wrote: > > It makes sense to mention GNOME explicitly in parallel to KDE because > in > the world of multiple spins, there is no one set of defaults fpr > Fedora > on the whole. GNOME is certainly not the default in the KDE Live CD. > All > I have been hearing so far is one poor excuse after next for not doing > it. I really didn't intend to troll or provoke a super thread, I just thought it was weird: a) that the KDE torrent was listed first b) that the default (GNOME) version didn't have gnome in the name. Not a big issue for me whatever the final decision is, I just thought I would mention it. Richard. From lsof at nodata.co.uk Thu Mar 29 22:52:56 2007 From: lsof at nodata.co.uk (nodata) Date: Fri, 30 Mar 2007 00:52:56 +0200 Subject: Is it a bug or intentionally done? In-Reply-To: <6e24a8e80703281255w1cbcedb3ve4edc0b9fa95b600@mail.gmail.com> References: <6e24a8e80703281255w1cbcedb3ve4edc0b9fa95b600@mail.gmail.com> Message-ID: <1175208776.3245.2.camel@sb-home.lan> It's a bug. You should be able to take a screenshot irrespecive of whether the menus are open. Bugzilla it, and use the workarounds in the meantime. Am Mittwoch, den 28.03.2007, 21:55 +0200 schrieb Mark: > Hey, > > i was just trying to make a screenshot of my gnome menu, but somehow > the screenhot window simply won`t appear when i press the "Print > Screen" button on my keyboard. it`s appearing just fine on other > places unless i clicked a menu (so that the menu is expanded) > > bug? or normal behavior? > > Thanx, > Mark. > -- > 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 Thu Mar 29 23:41:04 2007 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 29 Mar 2007 19:41:04 -0400 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <1175204159.6603.5.camel@localhost.localdomain> References: <1175178119.3034.12.camel@aglarond.local> <20070329165001.66aae998@localhost.localdomain> <1175180321.12588.23.camel@cutter> <15e53e180703290804i29261bb6re406cdfccac535f6@mail.gmail.com> <20070329151057.GA7920@orient.maison.lan> <15e53e180703290815j7a122f4ah625247e78e099733@mail.gmail.com> <460C2BF3.2070106@fedoraproject.org> <1175204159.6603.5.camel@localhost.localdomain> Message-ID: <1175211664.12588.29.camel@cutter> On Thu, 2007-03-29 at 22:35 +0100, Richard Hughes wrote: > On Fri, 2007-03-30 at 02:43 +0530, Rahul Sundaram wrote: > > > > It makes sense to mention GNOME explicitly in parallel to KDE because > > in > > the world of multiple spins, there is no one set of defaults fpr > > Fedora > > on the whole. GNOME is certainly not the default in the KDE Live CD. > > All > > I have been hearing so far is one poor excuse after next for not doing > > it. > > I really didn't intend to troll or provoke a super thread, I just > thought it was weird: > > a) that the KDE torrent was listed first > b) that the default (GNOME) version didn't have gnome in the name. > > Not a big issue for me whatever the final decision is, I just thought I > would mention it. the torrents are listed most recent to least recent. I got the kde livecd last b/c it didn't go out at the same time as the others did due to a minor mirroring hiccup. So that's why it is listed first. you'll note that olpc is listed above Fedora Core 6 final. That doesn't mean I prefer the olpc image more. ;) -sv From ericm24x7 at gmail.com Fri Mar 30 01:58:11 2007 From: ericm24x7 at gmail.com (eric magaoay) Date: Thu, 29 Mar 2007 21:58:11 -0400 Subject: NTFS-3G just released (3-28-07). inclusion to FC7? Message-ID: <460C6EB3.3070606@gmail.com> NTFS-3G was just released yesterday (3-28-07), stable version 1.328. I'm currently stress testing this version under XEN (x86_64), and so far so good. Just wondering if it is possible to incorporate this latest stable version into FC7. Existing version in repo: ntfs-3g.x86_64 2:1.0-1.fc7 http://ntfs-3g.org/releases.html eric From jkeating at redhat.com Fri Mar 30 04:36:11 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 30 Mar 2007 00:36:11 -0400 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <1175204159.6603.5.camel@localhost.localdomain> References: <1175178119.3034.12.camel@aglarond.local> <460C2BF3.2070106@fedoraproject.org> <1175204159.6603.5.camel@localhost.localdomain> Message-ID: <200703300036.12042.jkeating@redhat.com> On Thursday 29 March 2007 17:35:59 Richard Hughes wrote: > b) that the default (GNOME) version didn't have gnome in the name. That's sort of the point. Our "Default" spin or the one we'd like most people to use doesn't call out any specific software/technology/etc. It's just Fedora, what we the project think is our best foot forward. The KDE spin however is specialized for those that wish to use KDE or wish to see what it's about. -- 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 notting at redhat.com Fri Mar 30 05:03:31 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 30 Mar 2007 01:03:31 -0400 Subject: Mail semantics: mail group, permissions, MTA/MDA suid/sgid and the like In-Reply-To: <20070326213455.GF16942@neu.nirvana> References: <20070326213455.GF16942@neu.nirvana> Message-ID: <20070330050331.GB4538@nostromo.devel.redhat.com> Axel Thimm (Axel.Thimm at ATrpms.net) said: > a) Does every MDA and MUA need to do both locking mechanisms or is > dotlocking the fallback to fcntl? The latter would be an issue, so > it should probably be both for every MDA/MUA. Short answer is use fcntl or die. Bill From andy0579 at aim.com Fri Mar 30 04:46:29 2007 From: andy0579 at aim.com (Andrew Jamison) Date: Fri, 30 Mar 2007 00:46:29 -0400 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <200703300036.12042.jkeating@redhat.com> References: <1175178119.3034.12.camel@aglarond.local> <460C2BF3.2070106@fedoraproject.org> <1175204159.6603.5.camel@localhost.localdomain> <200703300036.12042.jkeating@redhat.com> Message-ID: <460C9625.9030601@aim.com> Jesse Keating wrote: > On Thursday 29 March 2007 17:35:59 Richard Hughes wrote: > >> b) that the default (GNOME) version didn't have gnome in the name. >> > > That's sort of the point. Our "Default" spin or the one we'd like most people > to use doesn't call out any specific software/technology/etc. It's just > Fedora, what we the project think is our best foot forward. The KDE spin > however is specialized for those that wish to use KDE or wish to see what > it's about. > > So the Gnome and KDE versions are going to have their own ISO's ? I am a little confused. I know with prior Fedora relases you just choosed what you wanted at install. Thanks, Andrew Jamison From notting at redhat.com Fri Mar 30 05:04:59 2007 From: notting at redhat.com (Bill Nottingham) Date: Fri, 30 Mar 2007 01:04:59 -0400 Subject: Initscripts and LSB compliance In-Reply-To: <20070327133302.GA2888@free.fr> References: <4608CCFD.5040600@redhat.com> <20070327133302.GA2888@free.fr> Message-ID: <20070330050459.GC4538@nostromo.devel.redhat.com> Patrice Dumas (pertusus at free.fr) said: > > Our first step should be to produce guidelines (we have some for RHEL, > > but they are not obeyed), then force the developers to obey that. It is > > no big deal, but having all scripts behaving correctly and in some sense > > the standard way is definitely good think. > > I completely agree. Having glanced through the specification there is > one point that doesn't seems to be desirable, it is the script naming > scheme which seems ugly to me: > http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/scrptnames.html > Although it could be a SHOULD item that upstream is contacted to > register to the lanana. System init scripts are not required to follow the LSB standards. I suspect that following them for something like return codes should be fine, but renaming them just leads to trouble, and should be avoided. Bill From dennis at ausil.us Fri Mar 30 05:29:31 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 30 Mar 2007 00:29:31 -0500 Subject: rpms/firmware-addon-dell/EL-4 .cvsignore, 1.2, 1.3 firmware-addon-dell.spec, 1.1, 1.2 sources, 1.2, 1.3 In-Reply-To: <200703300519.l2U5JVdE028754@cvs-int.fedora.redhat.com> References: <200703300519.l2U5JVdE028754@cvs-int.fedora.redhat.com> Message-ID: <200703300029.32692.dennis@ausil.us> Once upon a time Friday 30 March 2007, Michael E Brown wrote: > Author: mebrown > > +# Dell only sells Intel-compat systems, so this package doesnt make much > sense +# on, eg. PPC. Also, we rely on libsmbios, which is only avail on > Intel-compat +ExcludeArch: ppc ppc64 s390 Can I suggest you use ExclusiveArch: %{ix86} x86_64 fedora is built by people for other archs than those. with a side effect that these things get built for archs they should not be built for. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kagesenshi.87 at gmail.com Fri Mar 30 05:32:36 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Fri, 30 Mar 2007 13:32:36 +0800 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175178162.23281.78.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> <460B0B9C.9090901@fedoraproject.org> <1175164871.23281.75.camel@jndwidescreen.lesbg.loc> <1175178162.23281.78.camel@jndwidescreen.lesbg.loc> Message-ID: On 3/29/07, Jonathan Dieter wrote: > If you're asking about using presto for mirroring rather than updates, > I've put a little bit of thought into it and would like to have > something up and running soon. We don't have the bandwidth to > continually mirror updates+extras, but we can put a few days into the > initial mirror and then use drpms for the updates. > > Jonathan > if it can regenerate the whole rpm it'll be nicer (something like applying patch to rpm) .. I dont know if this is possible or not .. if not its okay for me .. having deltaRPM in the first place already made me happy :D -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? Universiti Teknologi PETRONAS ICT 2nd Year 1st Semester mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com ----------------------------------------------- From jkeating at redhat.com Fri Mar 30 05:32:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 30 Mar 2007 01:32:47 -0400 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <460C9625.9030601@aim.com> References: <1175178119.3034.12.camel@aglarond.local> <200703300036.12042.jkeating@redhat.com> <460C9625.9030601@aim.com> Message-ID: <200703300132.47376.jkeating@redhat.com> On Friday 30 March 2007 00:46:29 Andrew Jamison wrote: > So the Gnome and KDE versions are going to have their own ISO's ? I am a > little confused. I know with prior Fedora relases you just choosed what > you wanted at install. The Gnome and KDE Live spins have their own isos. What we're currently calling the "Prime" spin has both Gnome and KDE on it and you can choose at install time. -- 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 jdieter at gmail.com Fri Mar 30 06:58:01 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Fri, 30 Mar 2007 09:58:01 +0300 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <4607E78C.30109@fedoraproject.org> <1174926361.19925.47.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> <460B0B9C.9090901@fedoraproject.org> <1175164871.23281.75.camel@jndwidescreen.lesbg.loc> <1175178162.23281.78.camel@jndwidescreen.lesbg.loc> Message-ID: <1175237881.23281.109.camel@jndwidescreen.lesbg.loc> On Fri, 2007-03-30 at 13:32 +0800, Hikaru Amano wrote: > On 3/29/07, Jonathan Dieter wrote: > > If you're asking about using presto for mirroring rather than updates, > > I've put a little bit of thought into it and would like to have > > something up and running soon. We don't have the bandwidth to > > continually mirror updates+extras, but we can put a few days into the > > initial mirror and then use drpms for the updates. > > > > Jonathan > > > > if it can regenerate the whole rpm it'll be nicer (something like > applying patch to rpm) .. I dont know if this is possible or not .. if > not its okay for me .. having deltaRPM in the first place already made > me happy :D > > > -- > ----------------------------------------------- > regards > Hikaru Sorry, I guess I wasn't clear. That's what the plan is. You would download the deltarpm to your mirror and apply it to the older full rpm sitting in your mirror and...presto! You've got the new full rpm! Like I said, though, at the moment this is totally academic. I haven't coded it at all. Jonathan -------------- 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 naoki at valuecommerce.com Fri Mar 30 08:13:25 2007 From: naoki at valuecommerce.com (Naoki) Date: Fri, 30 Mar 2007 17:13:25 +0900 Subject: FC7t3 issue. In-Reply-To: <1175178119.3034.12.camel@aglarond.local> References: <1175178119.3034.12.camel@aglarond.local> Message-ID: <1175242405.4281.13.camel@localhost.localdomain> Maybe it's bad media, doesn't look it at first glance though. I burnt the DVD - Prime x86_64. Booted. Selected "Install or Upgrade". Chose Local CDROM. Had the media pop out and an error - Terminal said "unable to mount loop back". Tried HTTP install pointed at the development tree but it complained about "repo doesn't match the media". Anybody else, known issue? From jdieter at gmail.com Fri Mar 30 08:17:23 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Fri, 30 Mar 2007 11:17:23 +0300 Subject: Yum-presto 0.3.3 update Message-ID: <1175242643.23281.118.camel@jndwidescreen.lesbg.loc> If you are using yum-presto < 0.3.3, please update to 0.3.3. I've had to make a small change in the metadata format, which means all older versions of yum-presto will no longer see *any* available deltarpms. I'm very sorry for the inconvenience. Jonathan -------------- 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 Fri Mar 30 07:16:30 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 30 Mar 2007 09:16:30 +0200 Subject: Announcing Fedora 7 Test 3 (6.92) Message-ID: <016b01c7729b$56f14be0$ba00000a@grecom.local> Welcome to Fedora 7 Test 3. I am please to announce the third of four test releases for Fedora 7. Downloads ======== DVD and network installation are available. http://torrent.fedoraproject.org/ The recommended method of download is via BitTorrent from this site. http://fedora.redhat.com/Download/mirrors.html HTTP, FTP, and RSYNC downloads are available from Fedora Project mirrors listed above. Note that not all mirrors may be synced at this time. New in Fedora 7 Test 3 ======== This test release includes significant new versions of many key components and technologies. The following sections provide a brief overview of major changes from the last release of Fedora. Merger of Core and Extras ======== * The Fedora Core and Extras software repositories are being merged, resulting in a shared infrastructure and a single repository of packages to which everyone is invited to contribute. * Fedora 7 Test 3 is packaged initially as a Desktop/Development Workstation/Server implementation, called "Prime". This spin is delivered in DVD iso format only as a trial, see https://www.redhat.com/archives/fedora-devel-list/2007-February/msg00993.html for the discussion on this. * Many more packages are available in the development repositories. Live CD ======== * This test release includes an i386 ISO for a Desktop Live CD. This Live CD features the ability to install to a hard disk using the same graphical Anaconda installer as the non-live CD variant. * This test release also includes an x86_64 ISO for a Desktop Live image. Due to size, this will require a DVD. As with the i386 Live image, the ability to install to a hard disk is available. * This test release features a new i386 ISO for a KDE Live CD. Note that as of this writing, this ISO is only available via bittorrent. It should be available via the mirrors in the near future. Desktop ======== * This test release features GNOME 2.18 * A brand new Echo icon theme is included as the default in this release. This icon theme is incomplete, but with appropriate feedback and progress, may become the default in the general release. * Fast User Switching is now available via the fast-user-switch-applet. See http://fedoraproject.org/wiki/Releases/FeatureFastUserSwitching for more details. Performance ======== * System performance is generally slower in the test releases as compared to the general release since we enable several options that help with debugging. System Administration ======== * System administration tools may be modified under the testing process. System Level Changes ======== * Fedora 7 Test 3 features a 2.6.21rc5 based kernel. Current release information is being tracked on the kernel release notes source page. (http://fedoraproject.org/wiki/Docs/Beats/Kernel) Amanda Users who upgrade from older releases need to read the amanda.conf and amanda-client.conf man pages to learn about the the new syntax for calling amandad, as well as edit the /etc/xinetd.d/amanda configuration file to follow the new syntax. Road Map And Release Schedule ======== * http://fedoraproject.org/wiki/Releases/7/ Intended Audience for Test Releases ======== Test 1 is targeted for developers, who use it "at their own risk", and contains many bleeding edge packages. Test 2 is for early adopters. Most things should work and we need to your help to find what is broken. Test 3 is for early adopters. Most things should work and we need to your help to find what is broken. Test 4 is for beta users. This is the time when we must have full community participation. Without this participation both hardware and software functionality suffers. Quality Assurance for Test Releases ======== The Fedora Project has a process in place for ensuring the highest possible quality even in our test releases. Many bugs are identified, prioritized and fixed during the testing process. We also have a list of known bugs in this release. Refer to http://fedoraproject.org/wiki/QA/7/Test3TreeTesting for more details. Translations of Release Notes ======== Due to the rapidly changing nature of test releases, translations of release notes for test releases are not practical. The initial goal is to have a translation of the release notes included in the test4 release and to allow community review and correction before the general release. As always, the general release is translated following the established practices for localization (l10n) and internationalization (i18n) (http://fedoraproject.org/wiki/L10N), which result in comprehensive, high-quality release notes in a variety of languages. About Fedora ======== Fedora is a set of projects sponsored by Red Hat and guided by the contributors. These projects are developed by a large community of people who strive to provide and maintain the very best in free, open source software and standards. The central Fedora project is an operating system and platform based on Linux that is always free for anyone to use, modify, and distribute, now and forever. You can help the Fedora Project community continue to improve Fedora if you file bug reports and enhancement requests. Refer to http://fedoraproject.org/wiki/BugsAndFeatureRequests for more information. Thank you for your participation. To find out more general information about Fedora, refer to the following Web pages: * Fedora Overview (http://fedoraproject.org/wiki/Overview) * Fedora FAQ (http://fedoraproject.org/wiki/FAQ) * Help and Support (http://fedoraproject.org/wiki/Communicate) * Participate in the Fedora Project (http://fedoraproject.org/wiki/HelpWanted) -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list From katzj at redhat.com Fri Mar 30 07:16:30 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 30 Mar 2007 09:16:30 +0200 Subject: Announcing Fedora 7 Test 3 (6.92) Message-ID: <016901c7729b$56ec69e0$ba00000a@grecom.local> Welcome to Fedora 7 Test 3. I am please to announce the third of four test releases for Fedora 7. Downloads ======== DVD and network installation are available. http://torrent.fedoraproject.org/ The recommended method of download is via BitTorrent from this site. http://fedora.redhat.com/Download/mirrors.html HTTP, FTP, and RSYNC downloads are available from Fedora Project mirrors listed above. Note that not all mirrors may be synced at this time. New in Fedora 7 Test 3 ======== This test release includes significant new versions of many key components and technologies. The following sections provide a brief overview of major changes from the last release of Fedora. Merger of Core and Extras ======== * The Fedora Core and Extras software repositories are being merged, resulting in a shared infrastructure and a single repository of packages to which everyone is invited to contribute. * Fedora 7 Test 3 is packaged initially as a Desktop/Development Workstation/Server implementation, called "Prime". This spin is delivered in DVD iso format only as a trial, see https://www.redhat.com/archives/fedora-devel-list/2007-February/msg00993.html for the discussion on this. * Many more packages are available in the development repositories. Live CD ======== * This test release includes an i386 ISO for a Desktop Live CD. This Live CD features the ability to install to a hard disk using the same graphical Anaconda installer as the non-live CD variant. * This test release also includes an x86_64 ISO for a Desktop Live image. Due to size, this will require a DVD. As with the i386 Live image, the ability to install to a hard disk is available. * This test release features a new i386 ISO for a KDE Live CD. Note that as of this writing, this ISO is only available via bittorrent. It should be available via the mirrors in the near future. Desktop ======== * This test release features GNOME 2.18 * A brand new Echo icon theme is included as the default in this release. This icon theme is incomplete, but with appropriate feedback and progress, may become the default in the general release. * Fast User Switching is now available via the fast-user-switch-applet. See http://fedoraproject.org/wiki/Releases/FeatureFastUserSwitching for more details. Performance ======== * System performance is generally slower in the test releases as compared to the general release since we enable several options that help with debugging. System Administration ======== * System administration tools may be modified under the testing process. System Level Changes ======== * Fedora 7 Test 3 features a 2.6.21rc5 based kernel. Current release information is being tracked on the kernel release notes source page. (http://fedoraproject.org/wiki/Docs/Beats/Kernel) Amanda Users who upgrade from older releases need to read the amanda.conf and amanda-client.conf man pages to learn about the the new syntax for calling amandad, as well as edit the /etc/xinetd.d/amanda configuration file to follow the new syntax. Road Map And Release Schedule ======== * http://fedoraproject.org/wiki/Releases/7/ Intended Audience for Test Releases ======== Test 1 is targeted for developers, who use it "at their own risk", and contains many bleeding edge packages. Test 2 is for early adopters. Most things should work and we need to your help to find what is broken. Test 3 is for early adopters. Most things should work and we need to your help to find what is broken. Test 4 is for beta users. This is the time when we must have full community participation. Without this participation both hardware and software functionality suffers. Quality Assurance for Test Releases ======== The Fedora Project has a process in place for ensuring the highest possible quality even in our test releases. Many bugs are identified, prioritized and fixed during the testing process. We also have a list of known bugs in this release. Refer to http://fedoraproject.org/wiki/QA/7/Test3TreeTesting for more details. Translations of Release Notes ======== Due to the rapidly changing nature of test releases, translations of release notes for test releases are not practical. The initial goal is to have a translation of the release notes included in the test4 release and to allow community review and correction before the general release. As always, the general release is translated following the established practices for localization (l10n) and internationalization (i18n) (http://fedoraproject.org/wiki/L10N), which result in comprehensive, high-quality release notes in a variety of languages. About Fedora ======== Fedora is a set of projects sponsored by Red Hat and guided by the contributors. These projects are developed by a large community of people who strive to provide and maintain the very best in free, open source software and standards. The central Fedora project is an operating system and platform based on Linux that is always free for anyone to use, modify, and distribute, now and forever. You can help the Fedora Project community continue to improve Fedora if you file bug reports and enhancement requests. Refer to http://fedoraproject.org/wiki/BugsAndFeatureRequests for more information. Thank you for your participation. To find out more general information about Fedora, refer to the following Web pages: * Fedora Overview (http://fedoraproject.org/wiki/Overview) * Fedora FAQ (http://fedoraproject.org/wiki/FAQ) * Help and Support (http://fedoraproject.org/wiki/Communicate) * Participate in the Fedora Project (http://fedoraproject.org/wiki/HelpWanted) -- fedora-announce-list mailing list fedora-announce-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-announce-list From che666 at gmail.com Fri Mar 30 08:55:07 2007 From: che666 at gmail.com (Rudolf Kastl) Date: Fri, 30 Mar 2007 10:55:07 +0200 Subject: Yum-presto 0.3.3 update In-Reply-To: <1175242643.23281.118.camel@jndwidescreen.lesbg.loc> References: <1175242643.23281.118.camel@jndwidescreen.lesbg.loc> Message-ID: could you please sign those packages. thanks, Rudolf Kastl 2007/3/30, Jonathan Dieter : > If you are using yum-presto < 0.3.3, please update to 0.3.3. I've had > to make a small change in the metadata format, which means all older > versions of yum-presto will no longer see *any* available deltarpms. > > I'm very sorry for the inconvenience. > > Jonathan > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From Axel.Thimm at ATrpms.net Fri Mar 30 09:33:17 2007 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 30 Mar 2007 11:33:17 +0200 Subject: Mail semantics: mail group, permissions, MTA/MDA suid/sgid and the like In-Reply-To: <20070330050331.GB4538@nostromo.devel.redhat.com> References: <20070326213455.GF16942@neu.nirvana> <20070330050331.GB4538@nostromo.devel.redhat.com> Message-ID: <20070330093317.GC30970@neu.nirvana> On Fri, Mar 30, 2007 at 01:03:31AM -0400, Bill Nottingham wrote: > Axel Thimm (Axel.Thimm at ATrpms.net) said: > > a) Does every MDA and MUA need to do both locking mechanisms or is > > dotlocking the fallback to fcntl? The latter would be an issue, so > > it should probably be both for every MDA/MUA. > > Short answer is use fcntl or die. OK, then we should remove current dotlock functionality from MTA/MDAs? I'm fine with that, it just needs to be a global and wide known policy so that MTA1 doesn't dotlock while MDA5 fcntl-locks and both think they own the mbox. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From buildsys at redhat.com Fri Mar 30 10:10:54 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Fri, 30 Mar 2007 06:10:54 -0400 Subject: rawhide report: 20070330 changes Message-ID: <200703301010.l2UAAsOR006842@hs20-bc2-6.build.redhat.com> Updated Packages: ImageMagick-6.3.2.9-2.fc7 ------------------------- * Fri Mar 30 2007 Norm Murray 6.3.2.9-2.fc7 - perlmagick build fix (#231259) NetworkManager-1:0.6.5-0.6.svn2474.fc7 -------------------------------------- * Wed Mar 28 2007 Matthew Barnes 1:0.6.5-0.6.svn2474 - Close private D-Bus connections. (#232691) apr-1.2.8-6 ----------- * Fri Mar 30 2007 Joe Orton 1.2.8-6 - merge review (#225253): drop .a archive; drop use of CC/CXX, use BuildRequires; drop old Conflicts; URL reference for Source * Thu Mar 22 2007 Joe Orton 1.2.8-5 - drop the doxygen documentation (which causes multilib conflicts) * Thu Feb 15 2007 Joe Orton 1.2.8-4 - add BR for python aspell-de-50:20030222-3.fc7 --------------------------- * Thu Mar 29 2007 Ivana Varekova - 50:20030222-3 - add documentation * Thu Mar 29 2007 Ivana Varekova - 50:20030222-1 - update to 20030222 - use configure script to create Makefile - update default build root - some minor spec changes aspell-el-50:0.50-6.fc7 ----------------------- * Thu Mar 29 2007 Ivana Varekova - 50:0.50-6 - add documentation * Thu Mar 29 2007 Ivana Varekova - 50:0.50-5 - use dconfigure script to create Makefile - update default build root - some minor spec changes aspell-en-50:6.0-5.fc7 ---------------------- * Thu Mar 29 2007 Ivana Varekova - 50:6.0-5 - add documentation - change license tag * Thu Mar 29 2007 Ivana Varekova - 50:6.0-4 - update default buildroot * Thu Mar 29 2007 Ivana Varekova - 50:6.0-3 - update to aspell6 - use configure script to create Makefile - some minor spec changes aspell-es-50:0.50-16.fc7 ------------------------ * Thu Mar 29 2007 Ivana Varekova - 50:0.50-16 - add documentation * Thu Mar 29 2007 Ivana Varekova - 50:0.50-15 - use configure script to create Makefile - update default buildroot aspell-fo-50:0.51-6.fc7 ----------------------- * Thu Mar 29 2007 Ivana Varekova - 50:0.51-6 - add documentation * Thu Mar 29 2007 Ivana Varekova - 50:0.51-5 - use configure script to create Makefile - update default buildroot - some minor spec changes aspell-fr-50:0.50-11.fc7 ------------------------ * Thu Mar 29 2007 Ivana Varekova - 50:0.50-11 - add documentation * Thu Mar 29 2007 Ivana Varekova - 50:0.50-10 - use configure script to create Makefile - update default buildroot - some minor spec changes aspell-ga-50:0.50-6.fc7 ----------------------- * Thu Mar 29 2007 Ivana Varekova - 50:0.50-6 - add documentation * Thu Mar 29 2007 Ivana Varekova - 50:0.50-5 - use configure script to create Makefile - update default buildroot - some minor spec changes aspell-gd-50:0.50-6.fc7 ----------------------- * Thu Mar 29 2007 Ivana Varekova - 50:0.50-6 - add documentation * Thu Mar 29 2007 Ivana Varekova - 50:0.50-5 - use configure script to create Makefile - update default buildroot - some minor spec changes aspell-gl-50:0.50-5.fc7 ----------------------- * Thu Mar 29 2007 Ivana Varekova - 50:0.50-5 - add documentation - use configure script to create Makefile - update default buildroot - some minor spec changes aspell-hr-50:0.51-5.fc7 ----------------------- * Thu Mar 29 2007 Ivana Varekova - 50:0.51-5 - add documentation - use configure script to create Makefile - update default buildroot - some minor spec changes aspell-id-50:0.50.1-5.fc7 ------------------------- * Thu Mar 29 2007 Ivana Varekova - 50:0.50.1-5 - add documentation - use configure script to create Makefile - update default buildroot - some minor spec changes aspell-is-50:0.51.1-3.fc7 ------------------------- * Thu Mar 29 2007 Ivana Varekova - 50:0.51.1-3 - add documentation - use configure script to create Makefile - update default buildroot - some minor spec changes aspell-it-50:2.2_20050523-1.fc7 ------------------------------- * Thu Mar 29 2007 Ivana Varekova - 50:2.2_20050523-1 - update to 2.2_20050523 - add documentation - use configure script to create Makefile - update default buildroot - some minor spec changes audit-1.5.1-2.fc7 ----------------- * Thu Mar 29 2007 Steve Grubb 1.5.1-2 - Remove requires kernel-headers for python-libs - Apply patch to prevent segfaults on auditd reload beagle-0.2.16.2-4.fc7 --------------------- * Thu Mar 29 2007 Alexander Larsson - 0.2.16.2-4 - Also build on alpha (#232265) checkpolicy-2.0.1-2.fc7 ----------------------- * Wed Mar 28 2007 Dan Walsh - 2.0.1-2 - Rebuild with new libsepol compiz-0.3.6-5.fc7 ------------------ * Wed Mar 28 2007 Kristian H??gsberg - 0.3.6-5 - Update URL (#208214). - Require at least metacity 2.18 (#232831). - Add close-session.patch to deregister from SM when replaced (#229113). cups-1:1.2.10-2.fc7 ------------------- * Thu Mar 29 2007 Tim Waugh 1:1.2.10-2 - LSPP: Updated patch for line-wrapped labels (bug #228107). evolution-2.10.0-5.fc7 ---------------------- * Thu Mar 29 2007 Matthew Barnes - 2.10.0-5.fc7 - CVE-2007-1002 (Shared memo categories format string vulnerability) - Add -Wdeclaration-after-statement to strict build settings. gcc-4.1.2-7 ----------- * Thu Mar 29 2007 Jakub Jelinek 4.1.2-7 - make sure boehm-gc doesn't use PROT_EXEC (#202209) - fix C++ ICE on i ? j : k = (void) 0; (PR c++/30847) gdm-1:2.18.0-7.fc7 ------------------ * Thu Mar 29 2007 Ray Strode - 1:2.18.0-7 - don't strcpy overlapping strings (bug 208181). gtk-doc-1.8-2.fc7 ----------------- * Thu Mar 29 2007 Matthias Clasen - 1.8-2 - Drop a no longer needed patch kudzu-1.2.67-1 -------------- * Thu Mar 29 2007 Jeremy Katz - 1.2.67-1 - try to get the "best" match for a pci device when matching aliases instead of just the first match (#225026) logrotate-3.7.5-2.fc7 --------------------- * Thu Mar 29 2007 Peter Vrabec 3.7.5-2 - fix error hadnling after prerotate, postrotate, firstaction script failure. (http://qa.mandriva.com/show_bug.cgi?id=29979) mono-1.2.3-2.fc7 ---------------- * Thu Mar 29 2007 Alexander Larsson - 1.2.3-2 - Also build on alpha (#232268) mysql-5.0.37-2.fc7 ------------------ * Thu Mar 29 2007 Tom Lane 5.0.37-2 - Use a less hacky method of getting default values in initscript Related: #233771, #194596 - Improve packaging of mysql-libs per suggestions from Remi Collet Resolves: #233731 - Update default /etc/my.cnf ([mysql.server] has been bogus for a long time) netpbm-10.35-12.fc7 ------------------- * Thu Mar 29 2007 Jindrich Novy 10.35-12 - merge review fixes (#226191), thanks to Jason Tibbitts php-5.2.1-5 ----------- * Thu Mar 29 2007 Joe Orton 5.2.1-5 - enable SASL support in LDAP extension (#205772) pkgconfig-1:0.21-5.fc7 ---------------------- * Thu Mar 29 2007 Matthias Clasen - 1:0.21-5 - Fix --exists to ignore Requires.private - Fix Requires.private to operate fully recursive policycoreutils-2.0.7-7.fc7 --------------------------- * Thu Mar 29 2007 Dan Walsh 2.0.7-7 - Many fixes to polgengui quagga-0:0.99.6-1.fc7 --------------------- * Wed Mar 28 2007 Martin Bacovsky - 0.99.6-1 - upgrade to new upstream 0.99.6 - Resolves: #233909: quagga: unowned directory - removed redundant patches (#226352) * Mon Jan 22 2007 Martin Bacovsky - 0.98.6-3 - Resolves: #172548 - quagga.spec defines with_vtysh 1 but vtysh is not enabled in the build * Wed Jul 12 2006 Jesse Keating - 0:0.98.6-2.1 - rebuild redhat-menus-8.9.10-1.fc7 ------------------------- * Sat Mar 29 2008 Ray Strode - 8.9.10-1 - add encoding to all the desktop files that don't have it (bug 105796) rhpxl-0.45-1.fc7 ---------------- * Thu Mar 29 2007 Chris Lumens - 0.45-1 - resolution_from_string should return integers instead of strings. samba-0:3.0.24-9.fc7 -------------------- * Thu Mar 29 2007 Simo Sorce 3.0.24-9.fc7 - integrate most of merge review proposed changes (bug #226387) - remove libsmbclient-devel-static and simply stop shipping the static version of smbclient as it seem this is deprecated and actively discouraged system-config-users-1.2.56-1.fc7 -------------------------------- * Fri Mar 30 2007 Nils Philippsen - 1.2.56 - check whether password and confirmed password match before checking weakness etc. * Fri Mar 30 2007 Nils Philippsen - 1.2.55 - don't check both password and confirmed password to avoid duplicate error dialogs (#234182) Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.13-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.13-1.fc7.s390 requires kernel >= 0:2.6.9-11 From mschwendt.tmp0701.nospam at arcor.de Fri Mar 30 10:35:21 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 30 Mar 2007 12:35:21 +0200 Subject: exaile Message-ID: <20070330123521.0b049a03.mschwendt.tmp0701.nospam@arcor.de> source rpm: exaile-0.2.9-2.fc7.src.rpm package: exaile - 0.2.9-2.fc7.i386 from fedora-extras-needsign-development-i386 unresolved deps: gnome-python2-gtkhtml Same for FC6. It won't be included in the next push. When a fixed updated is available, please get back to me, since exaile is on the blacklist now. From dakingun at gmail.com Fri Mar 30 10:57:34 2007 From: dakingun at gmail.com (Deji Akingunola) Date: Fri, 30 Mar 2007 06:57:34 -0400 Subject: exaile In-Reply-To: <20070330123521.0b049a03.mschwendt.tmp0701.nospam@arcor.de> References: <20070330123521.0b049a03.mschwendt.tmp0701.nospam@arcor.de> Message-ID: On 3/30/07, Michael Schwendt wrote: > source rpm: exaile-0.2.9-2.fc7.src.rpm > package: exaile - 0.2.9-2.fc7.i386 from fedora-extras-needsign-development-i386 > unresolved deps: > gnome-python2-gtkhtml > > > Same for FC6. It won't be included in the next push. When a fixed updated > is available, please get back to me, since exaile is on the blacklist now. > I've corrected the typo. Thanks Deji From jdieter at gmail.com Fri Mar 30 11:06:00 2007 From: jdieter at gmail.com (Jonathan Dieter) Date: Fri, 30 Mar 2007 14:06:00 +0300 Subject: Yum-presto 0.3.3 update In-Reply-To: References: <1175242643.23281.118.camel@jndwidescreen.lesbg.loc> Message-ID: <1175252760.23281.121.camel@jndwidescreen.lesbg.loc> On Fri, 2007-03-30 at 10:55 +0200, Rudolf Kastl wrote: > could you please sign those packages. > > thanks, > Rudolf Kastl The packages are now signed with my personal key (which is available from http://www.lesbg.com/jdieter/jdieter.asc). I've also pushed a new .repo file that will check gpg signatures and automatically download mine. Jonathan -------------- 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 kagesenshi.87 at gmail.com Fri Mar 30 11:39:26 2007 From: kagesenshi.87 at gmail.com (Hikaru Amano) Date: Fri, 30 Mar 2007 19:39:26 +0800 Subject: Yum-presto (deltarpms) ready for testing. In-Reply-To: <1175237881.23281.109.camel@jndwidescreen.lesbg.loc> References: <1174761189.4012.84.camel@jndwidescreen.lesbg.loc> <460A584C.2060109@fedoraproject.org> <1175090907.23281.14.camel@jndwidescreen.lesbg.loc> <1175101273.23281.45.camel@jndwidescreen.lesbg.loc> <460B0B9C.9090901@fedoraproject.org> <1175164871.23281.75.camel@jndwidescreen.lesbg.loc> <1175178162.23281.78.camel@jndwidescreen.lesbg.loc> <1175237881.23281.109.camel@jndwidescreen.lesbg.loc> Message-ID: On 3/30/07, Jonathan Dieter wrote: > Sorry, I guess I wasn't clear. That's what the plan is. You would > download the deltarpm to your mirror and apply it to the older full rpm > sitting in your mirror and...presto! You've got the new full rpm! > > Like I said, though, at the moment this is totally academic. I haven't > coded it at all. > > Jonathan > cool!! .. i'll be looking forward for it :D ... thanks!! -- ----------------------------------------------- regards Hikaru ----------------------------------------------- Mohd Izhar Firdaus Bin Ismail Amano Hikaru ??? ???? ???? Universiti Teknologi PETRONAS ICT 2nd Year 1st Semester mohd.izhar.firdaus at gmail.com ----------------------------------------------- kagesenshi.87 at gmail.com Blog: http://kagesenshi.blogspot.com ----------------------------------------------- From buildsys at fedoraproject.org Fri Mar 30 11:44:57 2007 From: buildsys at fedoraproject.org (buildsys at fedoraproject.org) Date: Fri, 30 Mar 2007 07:44:57 -0400 (EDT) Subject: Fedora Extras Package Build Report 2007-03-30 Message-ID: <20070330114457.DC124152131@buildsys.fedoraproject.org> Packages built and released for Fedora Extras development: 54 advancecomp-1.15-6.fc7 amarokFS-0.5-1.fc7 aumix-2.8-15.fc7 azureus-2.5.0.4-2.fc7 bbkeys-0.9.0-6.fc7 bigloo-2.9a-3.fc7 blackbox-0.70.1-6.fc7 clearsilver-0.10.4-2.fc7 NEW clutter-0.2.2-4.fc7 compat-erlang-R10B-10.7.fc7 curlftpfs-0.9-5.fc7 digikam-doc-0.9.1-1.fc7 ettercap-0.7.3-19.fc7 firmware-addon-dell-1.2.6-1.fc7 gaim-meanwhile-2.0.0-0.7.beta6.fc7 geda-docs-20070216-1.fc7 geda-examples-20070216-1.fc7 geda-gattrib-20070216-1.fc7 geda-gnetlist-20070216-1.fc7 geda-gschem-20070216-1.fc7 geda-gsymcheck-20070216-1.fc7 geda-symbols-20070216-1.fc7 geda-utils-20070216-1.fc7 giggle-0.2-2.fc7 glpk-4.15-1.fc7 gtkmozembedmm-1.4.2.cvs20060817-10.fc7 initng-0.6.10-2.fc7 initng-ifiles-0.1.2-1.fc7 itk-3.3-0.6.RC1.fc7 jasper-1.900.1-1.fc7 jd-1.8.8-0.3.cvs070329.fc7 NEW jokosher-0.9-0.1.20070325svn.fc7 kphotobymail-0.4.1-1.fc7 libcaca-0.99-0.1.beta11.fc7 libgeda-20070216-1.fc7 libsexymm-0.1.9-3.fc7 libsmbios-0.13.5-1.fc7 liferea-1.2.10b-1.fc7 livecd-tools-005-3.fc7 openbabel-2.1.0-0.3.b8.fc7 NEW perl-Data-Stag-0.10-2.fc7 NEW perl-Math-Spline-0.01-1.fc7 NEW perl-XML-DOM-XPath-0.13-1.fc7 NEW perl-XML-XPathEngine-0.08-1.fc7 python-basemap-0.9.5-1.fc7 python-basemap-data-0.9.5-2.fc7 qtparted-0.4.5-14.fc7 NEW ruby-cairo-1.4.1-2.fc7 sysprof-kmod-1.0.8-1.2.6.20_1.3024.fc7 tracker-0.5.4-6.fc7 viewvc-1.0.3-13.fc7 wfut-1.1.0-3.fc7 wormux-0.7.9-3.fc7 NEW zhcon-0.2.6-5.fc7 Packages built and released for Fedora Extras 6: 22 amarokFS-0.5-1.fc6 digikam-doc-0.9.1-1.fc6 firmware-addon-dell-1.2.6-1.fc6 geda-docs-20070216-1.fc6 geda-examples-20070216-1.fc6 geda-gattrib-20070216-1.fc6 geda-gnetlist-20070216-1.fc6 geda-gschem-20070216-1.fc6 geda-gsymcheck-20070216-1.fc6 geda-symbols-20070216-1.fc6 geda-utils-20070216-1.fc6 giggle-0.2-2.fc6 jasper-1.900.1-1.fc6 libgeda-20070216-1.fc6 libsmbios-0.13.5-1.fc6 NEW perl-Data-Stag-0.10-2.fc6 NEW perl-Math-Spline-0.01-1.fc6 NEW perl-XML-DOM-XPath-0.13-1.fc6 NEW perl-XML-XPathEngine-0.08-1.fc6 NEW ruby-cairo-1.4.1-2.fc6 tracker-0.5.4-5.fc6 NEW zhcon-0.2.6-5.fc6 Packages built and released for Fedora Extras 5: 9 amarokFS-0.5-1.fc5 aumix-2.8-15.fc5 digikam-doc-0.9.1-1.fc5 ettercap-0.7.3-19.fc5 jasper-1.900.1-1.fc5 NEW perl-Data-Stag-0.10-2.fc5 NEW perl-Math-Spline-0.01-1.fc5 NEW perl-XML-DOM-XPath-0.13-1.fc5 NEW perl-XML-XPathEngine-0.08-1.fc5 advancecomp-1.15-6.fc7 ---------------------- * Thu Mar 29 2007 Matthias Saou 1.15-6 - Switch to use downloads.sf.net source URL. - Tweak defattr. amarokFS-0.5-1.fc7 ------------------ * Thu Mar 29 2007 Francois Aucamp - 0.5-1 - Update to version 0.5 - Removed "large_cover_images" patch; included upstream - Removed "config_dialog_layout" patch; included upstream - Updated "fedora_paths" patch - Updated "start_amarok" patch - Updated "theme_howto" patch - Updated amarok integration script aumix-2.8-15.fc7 ---------------- * Wed Mar 21 2007 Gabriel L. Somlo 2.8-15 - curses-cleanup.patch now stripping aumix down to cmdline+curses+mixer code - mousemask exception for /usr/bin/screen removed (gpm bug #233488 now fixed) azureus-2.5.0.4-2.fc7 --------------------- * Thu Mar 29 2007 Anthony Green 2.5.0.4-2 - Upgrade to 2.5.0.4. * Wed Mar 28 2007 Thomas Fitzsimmons - 2.5.0.0-12 - Remove gnu-crypto build and runtime requirements. - Do not include gnu-crypto in classpath. bbkeys-0.9.0-6.fc7 ------------------ * Thu Mar 29 2007 Matthias Saou 0.9.0-6 - Override _datadir as _sysconfdir to get config files in /etc. - Mark config files as noreplace. - Rebuild against new shared libbt from blackbox. - Switch to use downloads.sf.net source URL. - Tweak defattr, silence %setup. - Escape macros in %changelog. bigloo-2.9a-3.fc7 ----------------- * Wed Mar 28 2007 Thomas Fitzsimmons - 2.9a-3 - Patch method calls for Java 1.5. * Tue Mar 27 2007 Thomas Fitzsimmons - 2.9a-2 - Require java-1.5.0-gcj-devel for build. blackbox-0.70.1-6.fc7 --------------------- * Mon Aug 28 2006 Matthias Saou 0.70.1-6 - Switch to shared libbt library, so have devel require main and call ldconfig. - Make the GDM session file be a separate source. - Autoreconf to cleanly get rid of the useless rpath. - Add missing libXft-devel build requirement. - Switch to using downloads.sf.net source URL. - Minor spec file tweaks. - Add new libXft-devel devel sub-package requirement. clearsilver-0.10.4-2.fc7 ------------------------ * Wed Mar 28 2007 Jeffrey C. Ollie - 0.10.4-2 - Bump release. * Wed Mar 28 2007 Jeffrey C. Ollie - 0.10.4-1 - Update to 0.10.4 clutter-0.2.2-4.fc7 ------------------- * Wed Mar 28 2007 Allisson Azevedo 0.2.2-4 - Changed buildrequires and requires * Tue Mar 27 2007 Allisson Azevedo 0.2.2-3 - Fix .spec * Sat Mar 24 2007 Allisson Azevedo 0.2.2-2 - Fix .spec * Fri Mar 23 2007 Allisson Azevedo 0.2.2-1 - Initial RPM release compat-erlang-R10B-10.7.fc7 --------------------------- * Wed Mar 28 2007 Thomas Fitzsimmons - R10B-10.7 - Remove buildroot from installed files. * Tue Mar 27 2007 Thomas Fitzsimmons - R10B-10.6 - Update otp-glibc24.patch for glibc 2.5. * Tue Mar 27 2007 Thomas Fitzsimmons - R10B-10.5 - Require java-1.5.0-gcj-devel for build. curlftpfs-0.9-5.fc7 ------------------- * Wed Mar 28 2007 David Anderson 0.9-5 - Explicit dependency on fuse (bz#234349) * Mon Jan 08 2007 David Anderson 0.9-3 - Bump release number digikam-doc-0.9.1-1.fc7 ----------------------- * Thu Mar 29 2007 Marcin Garski 0.9.1-1 - Update to 0.9.1 - Spec tweak up ettercap-0.7.3-19.fc7 --------------------- * Wed Mar 28 2007 Jon Ciesla - 0.7.3-19 - /usr/bin/ettercap ownership fix. firmware-addon-dell-1.2.6-1.fc7 ------------------------------- * Wed Mar 28 2007 Michael E Brown - 1.2.6-1 - Add yum plugins for setting system ID variables. repos can use $sys_ven_id $sys_dev_id in their baseurl= or mirrorlist= arguments. * Sat Mar 17 2007 Michael E Brown - 1.2.5-1 - Add ExcludeArch for s390 - Remove python-abi dep for RHEL3 (it was broken) - fix sitelib path missing /lib/ dir gaim-meanwhile-2.0.0-0.7.beta6.fc7 ---------------------------------- * Wed Mar 28 2007 Josh Boyer 2.0.0-0.7.beta6 - Rebuild against most recent core package geda-docs-20070216-1.fc7 ------------------------ * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - fix ownership of /usr/share/gEDA/docs - #233792 * Sun Sep 10 2006 Chitlesh Goorah - 20061020-1 - New upstream release geda-examples-20070216-1.fc7 ---------------------------- * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 geda-gattrib-20070216-1.fc7 --------------------------- * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 geda-gnetlist-20070216-1.fc7 ---------------------------- * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 - dropped patch geda-gnetlist-20061020-backend-list.patch geda-gschem-20070216-1.fc7 -------------------------- * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 geda-gsymcheck-20070216-1.fc7 ----------------------------- * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 geda-symbols-20070216-1.fc7 --------------------------- * Mon Mar 12 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 geda-utils-20070216-1.fc7 ------------------------- * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 giggle-0.2-2.fc7 ---------------- * Thu Mar 29 2007 James Bowes - 0.2-2 - Add buildrequires for git-core * Thu Mar 29 2007 James Bowes - 0.2-1 - Update to 0.2 glpk-4.15-1.fc7 --------------- * Wed Mar 28 2007 Quentin Spencer 4.15-1 - New release. Shared libraries are now supported. gtkmozembedmm-1.4.2.cvs20060817-10.fc7 -------------------------------------- * Wed Mar 28 2007 Ha?kel Gu?mar - 1.4.2.cvs20060817-10 - rebuild against gecko-libs 1.8.1.3 initng-0.6.10-2.fc7 ------------------- * Thu Mar 29 2007 Daniel Malmgren 0.6.10-2 - Include patch from che to sole console font issue * Tue Mar 27 2007 Daniel Malmgren 0.6.10-1 - New upstreams version initng-ifiles-0.1.2-1.fc7 ------------------------- * Tue Mar 27 2007 Daniel Malmgren 0.1.2-1 - New upstreams version - Fixed up genrunlevel calls in post - Patch to disable broken virtcheck stuff itk-3.3-0.6.RC1.fc7 ------------------- * Wed Mar 28 2007 Wart - 3.3-0.6.RC1 - Rebuild for tcl 8.4 downgrade jasper-1.900.1-1.fc7 -------------------- * Thu Mar 29 2007 Rex Dieter 1.900.1-1 - jasper-1.900.1 jd-1.8.8-0.3.cvs070329.fc7 -------------------------- * Thu Mar 29 2007 Mamoru Tasaka - 1.8.8-0.3.beta070329 - cvs 070329 (23:30 JST) jokosher-0.9-0.1.20070325svn.fc7 -------------------------------- * Mon Mar 26 2007 Christopher Brown - 0.9-0.1.20070325svn - Naming cleanups * Sun Mar 25 2007 Christopher Brown - 0-0.1.20070325svn - naming convention changes - dependency cleanups - macro tidying * Thu Mar 22 2007 Christopher Brown - 0.9-3.20070322svn - updated to r1342 * Fri Mar 16 2007 Christopher Brown - 0.9-2.20070316svn - r1340 - package naming guidelines - desktop file install - file listing and cleansing * Sun Mar 11 2007 Christopher Brown - 0.9-1.20070311svn - add ladspa dependency * Thu Mar 08 2007 Christopher Brown - 0.9-1.20070308svn - omf registration and handling * Wed Mar 07 2007 Christopher Brown - 0.9-1.20070306svn - update to r1337 - add find_lang macro - added scrollkeeper gettext and python-setuptools as dependencies - added post and postun scripts - added svn snapshot comment kphotobymail-0.4.1-1.fc7 ------------------------ * Thu Jan 04 2007 Kushal Das 0.4.1-1 - New release 0.4.1 libcaca-0.99-0.1.beta11.fc7 --------------------------- * Thu Mar 29 2007 Matthias Saou 0.99-0.1.beta11 - Update to 0.99beta11. - We now have a main libcaca package with just the shared lib (built by default now), so make the devel sub-package require it too. Leave static lib for now. - Enable opengl and pango support. - Remove useless rpath. - Remove no longer needed man3 patch. - Remove all configure options, they're autodetected. libgeda-20070216-1.fc7 ---------------------- * Wed Mar 28 2007 Chitlesh Goorah - 20070216-1 - new upstream release on 2007 02 16 - bugfix: #233861 - unowned %{_datadir}/gEDA/ directory libsexymm-0.1.9-3.fc7 --------------------- * Wed Mar 28 2007 Ha?kel Gu?mar - 0.1.9-3 - unowned directory libsmbios-0.13.5-1.fc7 ---------------------- * Tue Mar 20 2007 Michael E Brown - 0.13.5 - rpmlint cleanups - Add dellLEDCtl binary - update AUTHORS file to add credit for dellLEDCtl - update doc/DellToken.txt to add a few more useful tokens. - updated build system to create documentation - skip cppunit dep on .elX builds (not in EPEL yet) liferea-1.2.10b-1.fc7 --------------------- * Thu Mar 29 2007 Brian Pepple - 1.2.10b-1 - Update to 1.2.10b. * Wed Mar 28 2007 Brian Pepple - 1.2.10-2 - Bump. * Wed Mar 28 2007 Brian Pepple - 1.2.10-1 - Update to 1.2.10. livecd-tools-005-3.fc7 ---------------------- * Thu Mar 29 2007 Jeremy Katz - 005-3 - have to use excludearch, not exclusivearch * Thu Mar 29 2007 Jeremy Katz - 005-2 - exclusivearch since it only works on x86 and x86_64 for now * Wed Mar 28 2007 Jeremy Katz - 005-1 - some shell quoting fixes - allow using UUID or LABEL for the fs label of a usb stick - work with ext2 formated usb stick mugshot-1.1.40-1.fc7 -------------------- * Thu Mar 29 2007 Owen Taylor - 1.1.40-1 - 1.1.40 openbabel-2.1.0-0.3.b8.fc7 -------------------------- * Thu Mar 29 2007 Dominik Mierzejewski 2.1.0-0.3.b8 - updated to beta8 - dropped upstream'd patch perl-Data-Stag-0.10-2.fc7 ------------------------- * Thu Mar 29 2007 Alex Lancaster 0.10-2 - Add missing BuildRequires: perl(XML::Parser::PerlSAX), perl(GD), perl(Graph::Directed), perl(Tk) * Fri Mar 23 2007 Alex Lancaster 0.10-1 - Specfile autogenerated by cpanspec 1.69.1. perl-Math-Spline-0.01-1.fc7 --------------------------- * Fri Mar 23 2007 Alex Lancaster 0.01-1 - Add perl(ExtUtils::MakeMaker) BR. - Specfile autogenerated by cpanspec 1.69.1. perl-XML-DOM-XPath-0.13-1.fc7 ----------------------------- * Fri Mar 23 2007 Alex Lancaster 0.13-1 - Specfile autogenerated by cpanspec 1.69.1. perl-XML-XPathEngine-0.08-1.fc7 ------------------------------- * Fri Mar 23 2007 Alex Lancaster 0.08-1 - Add BRs for Test::Pod and Test::Pod::Coverage - Specfile autogenerated by cpanspec 1.69.1. python-basemap-0.9.5-1.fc7 -------------------------- * Fri Mar 23 2007 Orion Poplawski 0.9.5-1 - Update to 0.9.5 - Ship the examples in a separate rpm python-basemap-data-0.9.5-2.fc7 ------------------------------- * Thu Mar 29 2007 Orion Poplawski 0.9.5-2 - Change Requires from /usr/share/basemap to python-basemap * Wed Mar 28 2007 Orion Poplawski 0.9.5-1 - Split into regular and -hires packages - Ship the basemap examples in python-basemap-examples qtparted-0.4.5-14.fc7 --------------------- * Thu Mar 29 2007 Steven Pritchard - 0.4.5-14 - Rebuild again. ruby-cairo-1.4.1-2.fc7 ---------------------- * Wed Mar 28 2007 Allisson Azevedo 1.4.1-2 - Changed license for Ruby License/GPL - Add ruby-devel for devel requires - Changed main group for System Environment/Libraries - Changed install for keep timestamps * Mon Mar 26 2007 Allisson Azevedo 1.4.1-1 - Initial RPM release sysprof-kmod-1.0.8-1.2.6.20_1.3024.fc7 -------------------------------------- tracker-0.5.4-6.fc7 ------------------- * Fri Mar 30 2007 Deji Akingunola - 0.5.4-6 - Ship both autostart desktop files in the main package (BZ #233323) viewvc-1.0.3-13.fc7 ------------------- * Wed Mar 28 2007 Bojan Smojver - 1.0.3-13 - Supply obsoletes/conflicts (suggestions by Peter Gordon, Bernard Johnson and Ville Skytt?) * Thu Mar 22 2007 Bojan Smojver - 1.0.3-12 - Drop selinux package, required context now in official policy wfut-1.1.0-3.fc7 ---------------- * Wed Mar 28 2007 Wart 1.1.0-3 - Enable use of RPM_OPT_FLAGS * Thu Mar 01 2007 Wart 1.1.0-2 - Rebuild for new libgcj .so version wormux-0.7.9-3.fc7 ------------------ * Wed Mar 28 2007 Wart 0.7.9-3 - Enable use of $RPM_OPT_FLAGS zhcon-0.2.6-5.fc7 ----------------- * Thu Mar 29 2007 Hu Zheng - 0.2.6-5 - Fix x86_64 compile error. For more information about the built packages please see the repository or the Fedora Info Feed: http://fedoraproject.org/infofeed/ From drago01 at gmail.com Fri Mar 30 12:29:14 2007 From: drago01 at gmail.com (dragoran) Date: Fri, 30 Mar 2007 14:29:14 +0200 Subject: NTFS-3G just released (3-28-07). inclusion to FC7? In-Reply-To: <460C6EB3.3070606@gmail.com> References: <460C6EB3.3070606@gmail.com> Message-ID: <460D029A.20904@gmail.com> eric magaoay wrote: > NTFS-3G was just released yesterday (3-28-07), stable version 1.328. > I'm currently stress testing this version under XEN (x86_64), and so > far so good. > > Just wondering if it is possible to incorporate this latest stable > version into FC7. > Existing version in repo: ntfs-3g.x86_64 2:1.0-1.fc7 > > http://ntfs-3g.org/releases.html > fill a bug (RFE) against ntfs-3g in bugzilla > eric > From ncorrare at fedoraproject.org Fri Mar 30 13:14:22 2007 From: ncorrare at fedoraproject.org (Nicolas Antonio Corrarello) Date: Fri, 30 Mar 2007 10:14:22 -0300 Subject: NTFS-3G just released (3-28-07). inclusion to FC7? In-Reply-To: <460D029A.20904@gmail.com> References: <460C6EB3.3070606@gmail.com> <460D029A.20904@gmail.com> Message-ID: <460D0D2E.2010001@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I thought ntfs was non-free because there is a patent associated. Remember the good ol' friends, the one from Redmond and Novel dragoran escribi?: > eric magaoay wrote: >> NTFS-3G was just released yesterday (3-28-07), stable version 1.328. >> I'm currently stress testing this version under XEN (x86_64), and so >> far so good. >> >> Just wondering if it is possible to incorporate this latest stable >> version into FC7. >> Existing version in repo: ntfs-3g.x86_64 2:1.0-1.fc7 >> >> http://ntfs-3g.org/releases.html >> > fill a bug (RFE) against ntfs-3g in bugzilla >> eric >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGDQ0t4UWy+d/Ik+4RAphwAJ9eVbwjEZ6fh1FwDqB728I8IpU+7QCgtbBX UHPQU+ickRE9tPH4fM0OkJ8= =czaE -----END PGP SIGNATURE----- From prarit at redhat.com Fri Mar 30 13:55:24 2007 From: prarit at redhat.com (Prarit Bhargava) Date: Fri, 30 Mar 2007 09:55:24 -0400 Subject: [ANNOUNCE]: F7-test3 ia64 ISOs available Message-ID: <460D16CC.7070001@redhat.com> A set of CD ISOs and a DVD ISO based on the Fedora 7 test3 ISOS of the ia64 Fedora development branch (also known as rawhide) are available from: http://oss.sgi.com/projects/fedora 0a743739a587f802d906f74beecd3769ee73a06b F7-test3-ia64-disc1.iso d8c7e30dee1eea08aaeadcd9fc61fbf3bd98bfa0 F7-test3-ia64-disc2.iso 590ed002a3ecaf0d45c93c982fbb2421cb6d9bef F7-test3-ia64-disc3.iso c53d115659f8f7c2fa23a5fc4fc46a56302ed2e3 F7-test3-ia64-disc4.iso 21452de57b0d4c1997a5aeb88e74a78942f34a4b F7-test3-ia64-disc5.iso f624c5eb86e8ae2376fa1515b673c2bf6a98432a F7-test3-ia64-DVD.iso (Click on Download on left-hand side, and then the F7-test3 directory) Please remember that F7 ia64 is _unsupported_ by Fedora. You can file bugs, but be sure to file them against the devel branch of Fedora Core. Also, add "fedora-ia64" to the "blocks" field of the BZ. I am not building an ia64 Live ISO yet either. I am planning to do this in the near future. P. From mmarcini at redhat.com Fri Mar 30 14:50:56 2007 From: mmarcini at redhat.com (Michal Marciniszyn) Date: Fri, 30 Mar 2007 16:50:56 +0200 Subject: Initscripts and LSB compliance In-Reply-To: <20070330050459.GC4538@nostromo.devel.redhat.com> References: <4608CCFD.5040600@redhat.com> <20070327133302.GA2888@free.fr> <20070330050459.GC4538@nostromo.devel.redhat.com> Message-ID: <460D23D0.5080806@redhat.com> Bill Nottingham wrote: > Patrice Dumas (pertusus at free.fr) said: > >>> Our first step should be to produce guidelines (we have some for RHEL, >>> but they are not obeyed), then force the developers to obey that. It is >>> no big deal, but having all scripts behaving correctly and in some sense >>> the standard way is definitely good think. >>> >> I completely agree. Having glanced through the specification there is >> one point that doesn't seems to be desirable, it is the script naming >> scheme which seems ugly to me: >> http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/scrptnames.html >> Although it could be a SHOULD item that upstream is contacted to >> register to the lanana. >> > > System init scripts are not required to follow the LSB standards. I suspect > that following them for something like return codes should be fine, but > renaming them just leads to trouble, and should be avoided. > > Bill > > I totally agree, my main point was avoiding %conf in the script (which is the part of the policy AFAIK) and correct return codes and status call behavior. Michal From katzj at redhat.com Fri Mar 30 15:42:21 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 30 Mar 2007 11:42:21 -0400 Subject: KDE-Live-CD: trim the fat In-Reply-To: References: <20070314011000.5b0cbcb8@localhost.localdomain> <20070329190545.05537ebc@localhost.localdomain> Message-ID: <1175269341.12248.2.camel@erebor.boston.redhat.com> On Thu, 2007-03-29 at 12:46 -0500, Rex Dieter wrote: > Sebastian Vahl wrote: > > Am Thu, 29 Mar 2007 08:02:49 -0500 > > schrieb Rex Dieter : > > > >> Sebastian Vahl wrote: > >> > >> > I've created a new basic layout for the cd: > >> > http://fedoraproject.org/wiki/Releases/FeatureFedoraKDE/KDELiveCD > >> > The size on todays rawhide is about 667 MB. > >> > Please tell me which package should be added or removed. > >> > >> Playing a bit with the F7-test3-KDE-Live, here are some suggestions to > >> consider: > >> http://fedoraproject.org/wiki/RexDieter/F7t3-kde-trim-the-fat > > > > If I haven't missed something all of the mentioned gnome-ish bits are > > dependencies or dependencies of a dependency from anaconda. > > I don't think so, I checked already trying(1) to remove most of those > packages (and they didn't touch anaconda). A shocking amount comes due to pirut requiring gnome-session for the /etc/xdg/autostart directory. I'm unraveling that and putting the directory in the filesystem package. Jeremy From ericm24x7 at gmail.com Fri Mar 30 16:32:10 2007 From: ericm24x7 at gmail.com (eric magaoay) Date: Fri, 30 Mar 2007 12:32:10 -0400 Subject: NTFS-3G just released (3-28-07). inclusion to FC7? In-Reply-To: <460D0D2E.2010001@fedoraproject.org> References: <460C6EB3.3070606@gmail.com> <460D029A.20904@gmail.com> <460D0D2E.2010001@fedoraproject.org> Message-ID: <460D3B8A.6070006@gmail.com> Nicolas Antonio Corrarello wrote: > I thought ntfs was non-free because there is a patent associated. > Remember the good ol' friends, the one from Redmond and Novel > If there is a patent question associated with the latest ntfs-3g sources, MS must declare its patent rights and inform the offending party/parties to be enforceable. I just look at the source codes, and all seem to be released under GNU Public License (GPL). So I assumed nothing there is non-free or it will violate the spirit of GPL. I think as hardware/software virtualization improved and optimized, ntfs-3g will be less significant, if not already. > dragoran escribi?: > >> eric magaoay wrote: >> >>> Just wondering if it is possible to incorporate this latest stable >>> version into FC7. >>> Existing version in repo: ntfs-3g.x86_64 2:1.0-1.fc7 >>> >> fill a bug (RFE) against ntfs-3g in bugzilla OK, I will do it upon completion of my test. eric From Michael_E_Brown at dell.com Fri Mar 30 17:13:40 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 30 Mar 2007 12:13:40 -0500 Subject: rpms/firmware-addon-dell/EL-4 .cvsignore, 1.2, 1.3 firmware-addon-dell.spec, 1.1, 1.2 sources, 1.2, 1.3 In-Reply-To: <200703300029.32692.dennis@ausil.us> References: <200703300519.l2U5JVdE028754@cvs-int.fedora.redhat.com> <200703300029.32692.dennis@ausil.us> Message-ID: <20070330171339.GI10779@humbolt.us.dell.com> On Fri, Mar 30, 2007 at 12:29:31AM -0500, Dennis Gilmore wrote: > Once upon a time Friday 30 March 2007, Michael E Brown wrote: > > Author: mebrown > > > > +# Dell only sells Intel-compat systems, so this package doesnt make much > > sense +# on, eg. PPC. Also, we rely on libsmbios, which is only avail on > > Intel-compat +ExcludeArch: ppc ppc64 s390 > > Can I suggest you use ExclusiveArch: %{ix86} x86_64 fedora is built by people > for other archs than those. with a side effect that these things get built > for archs they should not be built for. Does not work. Sorry. Firmware-addon-dell is a noarch package. So if you use "ExclusiveArch: ...", it fails to build. The reason I put in the ExcludeArch line was to keep the compose scripts from dropping it into the ppc fedora repo. I am perfectly happy to add additional excludearch directives if you send me a patch. -- Michael From jwboyer at jdub.homelinux.org Fri Mar 30 17:20:55 2007 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Fri, 30 Mar 2007 12:20:55 -0500 Subject: NTFS-3G just released (3-28-07). inclusion to FC7? In-Reply-To: <460D3B8A.6070006@gmail.com> References: <460C6EB3.3070606@gmail.com> <460D029A.20904@gmail.com> <460D0D2E.2010001@fedoraproject.org> <460D3B8A.6070006@gmail.com> Message-ID: <1175275255.32658.29.camel@vader.jdub.homelinux.org> On Fri, 2007-03-30 at 12:32 -0400, eric magaoay wrote: > Nicolas Antonio Corrarello wrote: > > I thought ntfs was non-free because there is a patent associated. > > Remember the good ol' friends, the one from Redmond and Novel > > > > If there is a patent question associated with the latest ntfs-3g > sources, MS must declare its patent rights and inform the offending > party/parties to be enforceable. I just look at the source codes, and > all seem to be released under GNU Public License (GPL). So I assumed > nothing there is non-free or it will violate the spirit of GPL. The license of the source code has little to do with patents on the ideas contained within. The only time it really comes into play is if the patent _holder_ releases the source code. josh From dennis at ausil.us Fri Mar 30 17:32:33 2007 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 30 Mar 2007 12:32:33 -0500 Subject: rpms/firmware-addon-dell/EL-4 .cvsignore, 1.2, 1.3 firmware-addon-dell.spec, 1.1, 1.2 sources, 1.2, 1.3 In-Reply-To: <20070330171339.GI10779@humbolt.us.dell.com> References: <200703300519.l2U5JVdE028754@cvs-int.fedora.redhat.com> <200703300029.32692.dennis@ausil.us> <20070330171339.GI10779@humbolt.us.dell.com> Message-ID: <200703301232.34135.dennis@ausil.us> On Friday 30 March 2007 12:13:40 pm Michael E Brown wrote: > On Fri, Mar 30, 2007 at 12:29:31AM -0500, Dennis Gilmore wrote: > > Once upon a time Friday 30 March 2007, Michael E Brown wrote: > > > Author: mebrown > > > > > > +# Dell only sells Intel-compat systems, so this package doesnt make > > > much sense +# on, eg. PPC. Also, we rely on libsmbios, which is only > > > avail on Intel-compat +ExcludeArch: ppc ppc64 s390 > > > > Can I suggest you use ExclusiveArch: %{ix86} x86_64 fedora is built by > > people for other archs than those. with a side effect that these things > > get built for archs they should not be built for. > > Does not work. Sorry. > > Firmware-addon-dell is a noarch package. So if you use "ExclusiveArch: > ...", it fails to build. The reason I put in the ExcludeArch line was to > keep the compose scripts from dropping it into the ppc fedora repo. I am > perfectly happy to add additional excludearch directives if you send me a > patch. Then its not a noarch package. while it does not compile it is arch specific and should be treated as such. -- Dennis Gilmore, RHCE From rdieter at math.unl.edu Fri Mar 30 17:44:41 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 30 Mar 2007 12:44:41 -0500 Subject: rpms/firmware-addon-dell/EL-4 .cvsignore, 1.2, 1.3 firmware-addon-dell.spec, 1.1, 1.2 sources, 1.2, 1.3 In-Reply-To: <200703301232.34135.dennis@ausil.us> References: <200703300519.l2U5JVdE028754@cvs-int.fedora.redhat.com> <200703300029.32692.dennis@ausil.us> <20070330171339.GI10779@humbolt.us.dell.com> <200703301232.34135.dennis@ausil.us> Message-ID: <460D4C89.4090408@math.unl.edu> Dennis Gilmore wrote: > On Friday 30 March 2007 12:13:40 pm Michael E Brown wrote: >> Firmware-addon-dell is a noarch package. So if you use "ExclusiveArch: >> ...", it fails to build. The reason I put in the ExcludeArch line was to >> keep the compose scripts from dropping it into the ppc fedora repo. I am >> perfectly happy to add additional excludearch directives if you send me a >> patch. > > Then its not a noarch package. while it does not compile it is arch specific > and should be treated as such. I recall debating this a bit in the Packaging committee... I think you're right, see, http://fedoraproject.org/wiki/Packaging/GuidelinesTodo "arch-specific script packages" -- Rex From Michael_E_Brown at dell.com Fri Mar 30 18:33:10 2007 From: Michael_E_Brown at dell.com (Michael E Brown) Date: Fri, 30 Mar 2007 13:33:10 -0500 Subject: rpms/firmware-addon-dell/EL-4 .cvsignore, 1.2, 1.3 firmware-addon-dell.spec, 1.1, 1.2 sources, 1.2, 1.3 In-Reply-To: <460D4C89.4090408@math.unl.edu> References: <200703300519.l2U5JVdE028754@cvs-int.fedora.redhat.com> <200703300029.32692.dennis@ausil.us> <20070330171339.GI10779@humbolt.us.dell.com> <200703301232.34135.dennis@ausil.us> <460D4C89.4090408@math.unl.edu> Message-ID: <20070330183310.GA28394@humbolt.us.dell.com> On Fri, Mar 30, 2007 at 12:44:41PM -0500, Rex Dieter wrote: > Dennis Gilmore wrote: > >On Friday 30 March 2007 12:13:40 pm Michael E Brown wrote: > > >>Firmware-addon-dell is a noarch package. So if you use "ExclusiveArch: > >>...", it fails to build. The reason I put in the ExcludeArch line was to > >>keep the compose scripts from dropping it into the ppc fedora repo. I am > >>perfectly happy to add additional excludearch directives if you send me a > >>patch. > > > >Then its not a noarch package. while it does not compile it is arch > >specific and should be treated as such. > > I recall debating this a bit in the Packaging committee... I think > you're right, see, > http://fedoraproject.org/wiki/Packaging/GuidelinesTodo > "arch-specific script packages" umm... note that this section is titled, "Things to be *considered* for Packaging Guidelines". If it was a packaging guideline, it would be filed under /PackagingGuidelines. There have been a couple of recent threads about this, and the answer has always been: add an "ExcludeArch:" line so that the compose scripts skip that pkg for those named repos. There never has been an official ruling or consensus that I have seen to make this official. And at that point, you break my upgrade path, as last time I checked, yum would not upgrade a .noarch pkg to a (eg.) .i386 package or vice-versa. -- Michael From tibbs at math.uh.edu Fri Mar 30 18:49:38 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 Mar 2007 13:49:38 -0500 Subject: NTFS-3G just released (3-28-07). inclusion to FC7? In-Reply-To: <460D0D2E.2010001@fedoraproject.org> References: <460C6EB3.3070606@gmail.com> <460D029A.20904@gmail.com> <460D0D2E.2010001@fedoraproject.org> Message-ID: >>>>> "NAC" == Nicolas Antonio Corrarello writes: NAC> I thought ntfs was non-free because there is a patent NAC> associated. Remember the good ol' friends, the one from Redmond NAC> and Novel Given that ntfs-3g has been in the repository for quite some time now and we went through this entire discussion at the time when it was added, is there any chance you could do a bit of research before attempting to revive the issue? Thanks, - J< From tibbs at math.uh.edu Fri Mar 30 18:51:10 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 30 Mar 2007 13:51:10 -0500 Subject: rpms/firmware-addon-dell/EL-4 .cvsignore, 1.2, 1.3 firmware-addon-dell.spec, 1.1, 1.2 sources, 1.2, 1.3 In-Reply-To: <200703301232.34135.dennis@ausil.us> References: <200703300519.l2U5JVdE028754@cvs-int.fedora.redhat.com> <200703300029.32692.dennis@ausil.us> <20070330171339.GI10779@humbolt.us.dell.com> <200703301232.34135.dennis@ausil.us> Message-ID: >>>>> "DG" == Dennis Gilmore writes: DG> Then its not a noarch package. while it does not compile it is DG> arch specific and should be treated as such. That is open for discussion and indeed has been discussed without resolution by the packaging committee in the past. - J< From rdieter at math.unl.edu Fri Mar 30 18:55:13 2007 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 30 Mar 2007 13:55:13 -0500 Subject: rpms/firmware-addon-dell/EL-4 .cvsignore, 1.2, 1.3 firmware-addon-dell.spec, 1.1, 1.2 sources, 1.2, 1.3 In-Reply-To: <20070330183310.GA28394@humbolt.us.dell.com> References: <200703300519.l2U5JVdE028754@cvs-int.fedora.redhat.com> <200703300029.32692.dennis@ausil.us> <20070330171339.GI10779@humbolt.us.dell.com> <200703301232.34135.dennis@ausil.us> <460D4C89.4090408@math.unl.edu> <20070330183310.GA28394@humbolt.us.dell.com> Message-ID: <460D5D11.2090708@math.unl.edu> Michael E Brown wrote: > On Fri, Mar 30, 2007 at 12:44:41PM -0500, Rex Dieter wrote: >> I recall debating this a bit in the Packaging committee... I think >> you're right, see, >> http://fedoraproject.org/wiki/Packaging/GuidelinesTodo >> "arch-specific script packages" > umm... note that this section is titled, "Things to be *considered* for > Packaging Guidelines". If it was a packaging guideline, it would be > filed under /PackagingGuidelines. good point! This one deserves more discussion. Upon further reflection, I'm not sure the proposed guideline applies in this case anyway, ie, it's not a package containing scripts that use arch-specific tools/packages, or is it? > There have been a couple of recent threads about this, and the answer > has always been: add an "ExcludeArch:" line so that the compose scripts > skip that pkg for those named repos. Right, that's just the (general) method to omit .noarch packages from certain archs. > And at that point, you break my upgrade path, as > last time I checked, yum would not upgrade a .noarch pkg to a (eg.) > .i386 package or vice-versa. Yeah, that gets unfun fast. -- Rex From mschwendt.tmp0701.nospam at arcor.de Fri Mar 30 20:44:13 2007 From: mschwendt.tmp0701.nospam at arcor.de (Michael Schwendt) Date: Fri, 30 Mar 2007 22:44:13 +0200 Subject: rpms/firmware-addon-dell/EL-4 .cvsignore, 1.2, 1.3 firmware-addon-dell.spec, 1.1, 1.2 sources, 1.2, 1.3 In-Reply-To: <20070330183310.GA28394@humbolt.us.dell.com> References: <200703300519.l2U5JVdE028754@cvs-int.fedora.redhat.com> <200703300029.32692.dennis@ausil.us> <20070330171339.GI10779@humbolt.us.dell.com> <200703301232.34135.dennis@ausil.us> <460D4C89.4090408@math.unl.edu> <20070330183310.GA28394@humbolt.us.dell.com> Message-ID: <20070330224413.c805c863.mschwendt.tmp0701.nospam@arcor.de> On Fri, 30 Mar 2007 13:33:10 -0500, Michael E Brown wrote: > There never has been an official ruling or consensus that I have seen to > make this official. And at that point, you break my upgrade path, as > last time I checked, yum would not upgrade a .noarch pkg to a (eg.) > .i386 package or vice-versa. It does for me (with default exactarch=1), and I've verified it regularly everytime it has come up somewhere. Last confirmed as working with yum-3.1.5-1.fc7. What doesn't work well for noarch<->arch switches is that "yum install" would prefer the arch package over the noarch package, but "yum update" would update to the noarch package. From ncorrare at fedoraproject.org Fri Mar 30 20:50:02 2007 From: ncorrare at fedoraproject.org (Nicolas Antonio Corrarello) Date: Fri, 30 Mar 2007 17:50:02 -0300 Subject: NTFS-3G just released (3-28-07). inclusion to FC7? In-Reply-To: References: <460C6EB3.3070606@gmail.com> <460D029A.20904@gmail.com> <460D0D2E.2010001@fedoraproject.org> Message-ID: <460D77FA.709@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry, didn't attempt to offend anyone neither create a discussion, just clearing a doubt Jason L Tibbitts III escribi?: >>>>>> "NAC" == Nicolas Antonio Corrarello writes: > > NAC> I thought ntfs was non-free because there is a patent > NAC> associated. Remember the good ol' friends, the one from Redmond > NAC> and Novel > > Given that ntfs-3g has been in the repository for quite some time now > and we went through this entire discussion at the time when it was > added, is there any chance you could do a bit of research before > attempting to revive the issue? > > Thanks, > > - J< > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD4DBQFGDXf64UWy+d/Ik+4RAi2uAJ4n/Yv7U39Ywp+kdCzMnMjymz2sfgCUCaW1 vf895qRkBPKBKl101zf72g== =CdYN -----END PGP SIGNATURE----- From seg at haxxed.com Fri Mar 30 22:55:49 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri, 30 Mar 2007 17:55:49 -0500 Subject: rpms/firmware-addon-dell/EL-4 .cvsignore, 1.2, 1.3 firmware-addon-dell.spec, 1.1, 1.2 sources, 1.2, 1.3 In-Reply-To: <200703301232.34135.dennis@ausil.us> References: <200703300519.l2U5JVdE028754@cvs-int.fedora.redhat.com> <200703300029.32692.dennis@ausil.us> <20070330171339.GI10779@humbolt.us.dell.com> <200703301232.34135.dennis@ausil.us> Message-ID: <1175295349.6110.143.camel@localhost.localdomain> On Fri, 2007-03-30 at 12:32 -0500, Dennis Gilmore wrote: > Then its not a noarch package. while it does not compile it is arch specific > and should be treated as such. I agree. A clearly arch specific package should not be noarch, that seems like common sense to me. Making it noarch appears to require hacks, a sure sign of doing something wrong... -------------- 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 ericm24x7 at gmail.com Sat Mar 31 03:52:52 2007 From: ericm24x7 at gmail.com (eric magaoay) Date: Fri, 30 Mar 2007 23:52:52 -0400 Subject: NTFS-3G just released (3-28-07). inclusion to FC7? In-Reply-To: <1175275255.32658.29.camel@vader.jdub.homelinux.org> References: <460C6EB3.3070606@gmail.com> <460D029A.20904@gmail.com> <460D0D2E.2010001@fedoraproject.org> <460D3B8A.6070006@gmail.com> <1175275255.32658.29.camel@vader.jdub.homelinux.org> Message-ID: <460DDB14.7030107@gmail.com> Josh Boyer wrote: > The license of the source code has little to do with patents on the > ideas contained within. The only time it really comes into play is if > the patent _holder_ releases the source code. > > josh > You are right, the license simply addressed contract agreements and more or less the copyrights. It is possible that ntfs-3g's current implementation under user level, rather than at the kernel level, and assuming it was developed under the clean environment, merit the idea as distinct and beyond the scope of ntfs patent that has been granted. eric From drago01 at gmail.com Sat Mar 31 08:16:18 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 31 Mar 2007 10:16:18 +0200 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <200703300132.47376.jkeating@redhat.com> References: <1175178119.3034.12.camel@aglarond.local> <200703300036.12042.jkeating@redhat.com> <460C9625.9030601@aim.com> <200703300132.47376.jkeating@redhat.com> Message-ID: <460E18D2.6080807@gmail.com> Jesse Keating wrote: > On Friday 30 March 2007 00:46:29 Andrew Jamison wrote: > >> So the Gnome and KDE versions are going to have their own ISO's ? I am a >> little confused. I know with prior Fedora relases you just choosed what >> you wanted at install. >> > > The Gnome and KDE Live spins have their own isos. What we're currently > calling the "Prime" spin has both Gnome and KDE on it and you can choose at > install time. > > are you sure about this? I have not tested it but last time I saw the package list there was nothing kde related... From buildsys at redhat.com Sat Mar 31 10:05:45 2007 From: buildsys at redhat.com (buildsys at redhat.com) Date: Sat, 31 Mar 2007 06:05:45 -0400 Subject: rawhide report: 20070331 changes Message-ID: <200703311005.l2VA5jBb012694@hs20-bc2-6.build.redhat.com> Updated Packages: anaconda-11.2.0.42-1 -------------------- * Fri Mar 30 2007 David Cantrell - 11.2.0.42-1 - LiveCD fixes (katzj, #230945, #224208, #224213, #230943) - Handle IOErrors if we can't find the kickstart file (clumens) aspell-en-50:6.0-6.fc7 ---------------------- * Fri Mar 30 2007 Ivana Varekova - 50:6.0-6 - remove obstolete flag aspell-gd-51:0.1.1-2.fc7 ------------------------ * Fri Mar 30 2007 Ivana Varekova - 51:0.1.1-2 - increase the epoch * Fri Mar 30 2007 Ivana Varekova - 50:0.1.1-1 - update to 0.1.1 aspell-id-50:1.2-1.fc7 ---------------------- * Fri Mar 30 2007 Ivana Varekova - 50:1.2-1 - update to 1.2 aspell-pl-50:6.0_20061121-1.fc7 ------------------------------- * Fri Mar 30 2007 Ivana Varekova - 50:6.0_20061121-1 - change license tag - update to 6.0_20061121 - add documentation - use configure script to create Makefile - update default buildroot - some minor spec changes aspell-pt-50:0.50-12.fc7 ------------------------ * Fri Mar 30 2007 Ivana Varekova - 50:0.50-12 - add documentation - use configure script to create Makefile - update default buildroot - some minor spec changes aspell-ru-50:0.99f7-3.fc7 ------------------------- * Fri Mar 30 2007 Ivana Varekova - 50:0.99f7-3 - update to 0.99f7-1 - add documentation - use configure script to create Makefile - update default buildroot - some minor spec changes aspell-sl-50:0.50-2.fc7 ----------------------- * Fri Mar 30 2007 Ivana Varekova - 50:0.50-2 - add documentation - use configure script to create Makefile - update default buildroot - some minor spec changes aspell-sr-50:0.02-3.fc7 ----------------------- * Fri Mar 30 2007 Ivana Varekova - 50:0.02-3 - use configure script to create Makefile * Wed Feb 07 2007 Ivana Varekova - 50:0.02-2 - incorporate the first part of package review - spec file cleanup * Wed Jul 12 2006 Jesse Keating - 50:0.02-1.2.1 - rebuild aspell-sv-50:0.51-2.fc7 ----------------------- * Fri Mar 30 2007 Ivana Varekova - 50:0.51-2 - add documentation - use configure script to create Makefile - update default buildroot - some minor spec changes bug-buddy-1:2.18.0-2.fc7 ------------------------ * Fri Mar 30 2007 Matthias Clasen - 1:2.18.0-2 - Make bug-buddy more robust checkpolicy-2.0.1-3.fc7 ----------------------- * Fri Mar 30 2007 Dan Walsh - 2.0.1-3 - Rebuild with new libsepol db4-4.5.20-5.fc7 ---------------- * Sat Mar 24 2007 Thomas Fitzsimmons 4.5.20-5 - Require java-1.5.0-gcj and java-1.5.0-gcj-devel for build. evince-0.8.0-2.fc7 ------------------ * Sat Mar 31 2007 Matthias Clasen - 0.8.0-2 - Add support for xdg-user-dirs fast-user-switch-applet-2.17.4-4.fc7 ------------------------------------ * Fri Mar 30 2007 Matthias Clasen 2.17.4-4 - Add bugzilla information to the .server file - Fix a bug in the gdm socket check filesystem-2.4.4-1.fc7 ---------------------- * Fri Mar 30 2007 Jeremy Katz - 2.4.4-1 - add /etc/xdg/autostart flex-2.5.33-5.fc7 ----------------- * Fri Mar 30 2007 Petr Machata - 2.5.33-5 - Make yy-prefixed variables available to scanner even with -P. foomatic-3.0.2-46.fc7 --------------------- * Fri Mar 30 2007 Tim Waugh 3.0.2-46 - Don't ship old gimp-print data (bug #234388). gnome-applets-1:2.18.0-4.fc7 ---------------------------- * Fri Mar 30 2007 Ray Strode - 1:2.18.0-4 - make gweather applet preferences find feature work slightly better (bug 209488) gnome-panel-2.18.0-4.fc7 ------------------------ * Fri Mar 30 2007 Matthias Clasen - 2.18.0-4 - Fix bug-buddy support in the other applets * Fri Mar 30 2007 Matthias Clasen - 2.18.0-3 - Fix bug-buddy support in the clock applet * Fri Mar 30 2007 Ray Strode - 2.18.0-2 - hide "Lock Screen" menu item when logged in as root gnome-screensaver-2.18.0-2.fc7 ------------------------------ * Fri Mar 30 2007 Matthias Clasen - 2.18.0-2 - Use the PICTURES user dir in the Pictures screensaver gnome-session-2.18.0-3.fc7 -------------------------- * Fri Mar 30 2007 Ray Strode - 2.18.0-3 - remove xdg autostart dir since it's part of filesystem now hwbrowser-0.31-1.fc7 -------------------- * Fri Mar 30 2007 Nils Philippsen - 0.31 - fix summary, don't hash-bang python modules, mark config files (#225892) - remove kontrol-panel icon - pick up updated translations * Fri Nov 24 2006 Nils Philippsen - 0.30 - pick up updated translations (#216597) kernel-2.6.20-1.3036.fc7 ------------------------ * Fri Mar 30 2007 Kristian H??gsberg - Update nouveau patch, add versioned nouveau drm provides. * Fri Mar 30 2007 David Woodhouse - PlayStation 3 storage and Ethernet support, stable bugfixes from ps3-linux-patches.git tree * Fri Mar 30 2007 Jarod Wilson - Overhaul ordering of build/don't build flag setting, such that nothing set at the top gets overridden later in the spec - Add support for --with/--without build flags as an alternative way to disable/enable specific builds - Add %buildid define to make it easier/more obvious how to tag a one-off build libdrm-2.3.0-5.fc7 ------------------ * Fri Mar 30 2007 Kristian H??gsberg - 2.3.0-5 - Update nouveau patch. librtas-1.2.4-3.fc7 ------------------- * Sat Mar 31 2007 David Woodhouse - 1.2.4-3 - Install libraries into /usr/lib64 on PPC64. libsepol-2.0.2-1.fc7 -------------------- * Fri Mar 30 2007 Dan Walsh 2.0.2-1 - Upgrade to latest from NSA * Merged fix from Karl to remap booleans at expand time to avoid holes in the symbol table. * Wed Feb 07 2007 Dan Walsh 2.0.1-1 - Upgrade to latest from NSA * Merged libsepol segfault fix from Stephen Smalley for when sensitivities are required but not present in the base. * Merged patch to add errcodes.h to libsepol by Karl MacMillan. * Fri Jan 19 2007 Dan Walsh 1.16.0-1 - Upgrade to latest from NSA * Updated version for stable branch. libtirpc-0.1.7-5.fc7 -------------------- * Mon Mar 26 2007 Steve Dickson 0.1.7-5 - Fixed Unowned Directory RPM problem (bz 233873) openhpi-2.8.1-1.fc7 ------------------- * Fri Mar 30 2007 Phil Knirsch - 2.8.1-1.fc7 - Update to openhpi-2.8.1 pirut-1.3.4-2.fc7 ----------------- * Fri Mar 30 2007 Jeremy Katz - 1.3.4-2 - don't depend on gnome-session; filesystem should contain that dir policycoreutils-2.0.7-8.fc7 --------------------------- * Fri Mar 30 2007 Dan Walsh 2.0.7-8 - system-config-selinux should be able to run on a disabled system, - at least enough to get it enabled. samba-0:3.0.24-10.fc7 --------------------- * Fri Mar 30 2007 Simo Sorce 3.0.24-10.fc7 - set passdb backend = tdbsam as default in smb.conf - remove samba-docs dependency from swat, that was a mistake - put back COPYING and other files in samba-common - put examples in samba not in samba-docs - leave only stuff under docs/ in samba-doc setools-3.1-4.fc7 ----------------- * Thu Mar 29 2007 Dan Walsh 3.1-4 - Start shipping the rest of the setools command line apps subversion-1.4.3-4 ------------------ * Thu Mar 29 2007 Joe Orton 1.4.3-4 - fix javahl compile failure * Mon Jan 29 2007 Joe Orton 1.4.3-3 - update to 1.4.3 (#228691) - remove trailing dot from Summary - use current preferred standard BuildRoot - add post/postun ldconfig scriptlets for -ruby and -javahl system-config-printer-0.7.61-1.fc7 ---------------------------------- * Fri Mar 30 2007 Tim Waugh 0.7.61-1 - 0.7.61: - Fixed retrieval of SMB authentication details (bug #203539). vim-2:7.0.224-1.fc7 ------------------- * Fri Mar 30 2007 Karsten Hopp 7.0.224-3 - patchlevel 224 xorg-x11-drv-i810-1.6.5-16.fc7 ------------------------------ * Fri Mar 30 2007 Adam Jackson 1.6.5-16 - xf86-video-intel-1.9.93 (RC3). xorg-x11-drv-nv-2.0.1-2.fc7 --------------------------- * Fri Mar 30 2007 Kristian H??gsberg 2.0.1-2 - Update nouveau snapshot. * Fri Mar 30 2007 Adam Jackson 2.0.1-1 - nv 2.0.1 xorg-x11-server-1.2.99.903-2.fc7 -------------------------------- * Fri Mar 30 2007 David Woodhouse 1.2.99.903-2 - Fix regression with PCI domains, but disjoint bus numbers (#207659) * Fri Mar 30 2007 Adam Jackson 1.2.99.903-1 - xserver 1.3 RC3. xsane-0.993-2.fc7 ----------------- * Fri Mar 30 2007 Nils Philippsen - 0.993-2 - fix summaries and buildroot, don't remove buildroot on %prep, mark dirs and config files, don't reference %buildroot in %build, use double-% in changelog entries (#226658) Broken deps for s390 ---------------------------------------------------------- systemtap - 0.5.13-1.fc7.s390 requires kernel >= 0:2.6.9-11 systemtap-runtime - 0.5.13-1.fc7.s390 requires kernel >= 0:2.6.9-11 From jkeating at redhat.com Sat Mar 31 11:38:36 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 31 Mar 2007 07:38:36 -0400 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <460E18D2.6080807@gmail.com> References: <1175178119.3034.12.camel@aglarond.local> <200703300132.47376.jkeating@redhat.com> <460E18D2.6080807@gmail.com> Message-ID: <200703310738.36212.jkeating@redhat.com> On Saturday 31 March 2007 04:16:18 dragoran wrote: > are you sure about this? I have not tested it but last time I saw the > package list there was nothing kde related... Then you're not testing hard enough (: Test2 and Test3 had a large set of KDE packages in the Prime spin. -- 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 drago01 at gmail.com Sat Mar 31 11:52:17 2007 From: drago01 at gmail.com (dragoran) Date: Sat, 31 Mar 2007 13:52:17 +0200 Subject: Announcing Fedora 7 Test 3 (6.92) In-Reply-To: <200703310738.36212.jkeating@redhat.com> References: <1175178119.3034.12.camel@aglarond.local> <200703300132.47376.jkeating@redhat.com> <460E18D2.6080807@gmail.com> <200703310738.36212.jkeating@redhat.com> Message-ID: <460E4B71.7090405@gmail.com> Jesse Keating wrote: > On Saturday 31 March 2007 04:16:18 dragoran wrote: > >> are you sure about this? I have not tested it but last time I saw the >> package list there was nothing kde related... >> > > Then you're not testing hard enough (: Test2 and Test3 had a large set of KDE > packages in the Prime spin. > > let me quote myself "have *not* tested it".. only saw the inital list in the wiki... but everything seems to ok now ;) From selinux at gmail.com Sat Mar 31 16:07:04 2007 From: selinux at gmail.com (Tom London) Date: Sat, 31 Mar 2007 09:07:04 -0700 Subject: rawhide report: 20070331 changes In-Reply-To: <200703311005.l2VA5jBb012694@hs20-bc2-6.build.redhat.com> References: <200703311005.l2VA5jBb012694@hs20-bc2-6.build.redhat.com> Message-ID: <4c4ba1530703310907j4efe86fch53a4315bc85fa4b6@mail.gmail.com> xorg-x11-drv-nv-2.0.1-2.fc7 --------------------------- * Fri Mar 30 2007 Kristian H?gsberg 2.0.1-2 - Update nouveau snapshot. * Fri Mar 30 2007 Adam Jackson 2.0.1-1 - nv 2.0.1 I'm running 'kernel-PAE', but updating this package forces installation of 'kernel' package. That right? tom [root at localhost ~]# yum update xorg-x11-drv-nv Loading "skip-broken" plugin Loading "installonlyn" plugin Setting up Update Process Resolving Dependencies --> Running transaction check Checking deps for xorg-x11-drv-nv.i386 0-2.0.0-3.fc7 - None Checking deps for xorg-x11-drv-nv.i386 0-2.0.1-2.fc7 - u --> Processing Dependency: kernel-drm-nouveau = 6 for package: xorg-x11-drv-nv --> Restarting Dependency Resolution with new changes. --> Running transaction check Checking deps for xorg-x11-drv-nv.i386 0-2.0.0-3.fc7 - None Checking deps for kernel.i686 0-2.6.20-1.3036.fc7 - u Checking deps for xorg-x11-drv-nv.i386 0-2.0.1-2.fc7 - u Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: xorg-x11-drv-nv i386 2.0.1-2.fc7 development 134 k Installing for dependencies: kernel i686 2.6.20-1.3036.fc7 development 16 M Transaction Summary ============================================================================= Install 1 Package(s) Update 1 Package(s) Remove 0 Package(s) Total download size: 17 M Is this ok [y/N]: n Exiting on user Command Complete! [root at localhost ~]# From fedora at camperquake.de Sat Mar 31 16:12:09 2007 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 31 Mar 2007 18:12:09 +0200 Subject: rawhide report: 20070331 changes In-Reply-To: <4c4ba1530703310907j4efe86fch53a4315bc85fa4b6@mail.gmail.com> References: <200703311005.l2VA5jBb012694@hs20-bc2-6.build.redhat.com> <4c4ba1530703310907j4efe86fch53a4315bc85fa4b6@mail.gmail.com> Message-ID: <20070331181209.36027a05@lain.camperquake.de> Hi. On Sat, 31 Mar 2007 09:07:04 -0700, Tom London wrote > I'm running 'kernel-PAE', but updating this package forces > installation of 'kernel' package. > > That right? Probably just a missing Provides: for the PAE subpackage. From krh at redhat.com Sat Mar 31 21:36:25 2007 From: krh at redhat.com (=?ISO-8859-1?Q?Kristian_H=F8gsberg?=) Date: Sat, 31 Mar 2007 17:36:25 -0400 Subject: rawhide report: 20070331 changes In-Reply-To: <20070331181209.36027a05@lain.camperquake.de> References: <200703311005.l2VA5jBb012694@hs20-bc2-6.build.redhat.com> <4c4ba1530703310907j4efe86fch53a4315bc85fa4b6@mail.gmail.com> <20070331181209.36027a05@lain.camperquake.de> Message-ID: <460ED459.9010508@redhat.com> Ralf Ertzinger wrote: > Hi. > > On Sat, 31 Mar 2007 09:07:04 -0700, Tom London wrote > >> I'm running 'kernel-PAE', but updating this package forces >> installation of 'kernel' package. >> >> That right? > > Probably just a missing Provides: for the PAE subpackage. Yup, that's what it was. There's a new build under way with nouveau provides for all subpackages. thanks, Kristian